This list is getting unusually long, and it’s beginning to get a little overwhelming.
Thankfully it’s close to content mode, since the core engine branch stuff is nearing a “basic foundations” state, which is good enough to do a lot of stuff with.
The save format needs to be canned
Simply because if I were to do a hardware accelerated release it would be easiest that way.
This is mostly cause I want to do this in order to make the UI hot-reloadable.
The game script system suffers from a lot of naming inconsistencies because of the fact that the language follows my C style of explicitly stating types, but that’s not helpful for a scripting language.
I want it to be unified so that each sub-variation of gamescript and it’s dataformats share as much common “procedures”, as possible.
A more retro style resolution. The game runs way better at the resolution, and also everything might actually look correct…
Redesigning the UI for lower resolution is going to be very difficult and time consuming, but I need to be able to do it.
- [X] Pause Menus
- [X] Editor UI (maybe?) Editor should preferably be a higher resolution
- [X] Save UI
- [X] Main Menu
- [X] Options Menu (partial)
- [X] Message Boxes
- [X] Notification messages
- [ ] Post-Battle UI (this is being rewritten anyways…)
- [X] Storyboard
- [X] Equipment Screen
- [X] Item Screen
- [-] Dialogue UI
- [X] Main
- [ ] Choice Selection
- [ ] Battle UI
- [ ] Main Part
- [ ] Ability Select
- [ ] Target Select
Projectiles have omni directional art, and can be animated if they are so wished to. But generally may not be. Projectiles have two types: ON-HIT for arrows or impact projectiles, only works by hitting entities. ON-PLACE can be hit on a location
Projectiles can delay their effects until after a certain amount of turns (there is no visual indicator for this unless you use the LOOK command.)
- This might require portrait art?
It’s a more robust way of solving my stupid cutscene problem.
Roof Tiles should hide themselves whenever an actor gets too close to them :)
For cutscene funnies
easy fix but requires more UI work.
Have to carefully adjust everything to be kb/mouse UI friendly (making actual widget objects…)
- [X] Main Menu
- [X] Options UI
- [ ] Shopping UI
- [ ] Dialogue UI
- [ ] Equipment UI
- [-] Battle UI
Item usage not included because that needs to be changed anyways
- [X] Main Part
- [ ] Ability Selection
- [ ] Target Selection
- [ ] Save UI
[??] Temporary allocation of certain assets and unloaded state (Okay this might not work too much.) @maybetoday
it now occurs to me it is possible to minimize asset memory usage by also loading level assets along with the level.
I can reduce the amount of permenant assets that need to be kept in active memory at all times, and simply load things on demand. This tends to be incredibly quick as there is still a decent amount of permenant assets.
This requires some odd changes that a are a bit low level but it shouldn’t be something that’s unusually difficult.
This is a fancier UI that I want to do.
Or at least allow the editor to run in super resolution mode since it needs view space…
Sprite objects can be animated if they so wish. A lot of these properties are mostly edited through script files… They are only placed through the editor and given some basic state “what they look like”, the rest is determined through scripts.
- [ ] Level Area
- [ ] World Map
These things are going to have to be hardcoded mostly since a lot of these things are pretty difficult to make into data objects…
With a few prompt types (go-out, leave, etc.)
These things should have some scripting capacity though for some reason they don’t.
These entities cannot die. Maybe I can use this for certain quest flags.
I want to be able to hook to more events in the scripting engine and having the ability to hook into battle completions would be incredibly useful.
Also allows arbitrarily ending battles as well.
This is used to help coordinate AI efforts (for strategy settings)
Not important I suppose
- [ ] World Map Compass
- [ ] UI Item Icons!
These are the most important things to hotreload, so they’ll be the only things I allow hotreloading for. The other stuff I don’t care too much about hot reloading for
These are for “faking” baked lights, since it’s easy to make these lights look good. Might be usable for “volumetric” lights
I want these to work in more different ways. I want them to also be able to hook into certain events and impact things if necessary (this is so I can use them in items as special effects sometimes)
Need to make a quick Excel spreadsheet for this stuff
There are a few minigames I would like to have initiated. Some of them require special drawing procedures. Unlike Chrono Trigger I don’t have a good script format to allow that.
Thankfully this is generally pretty easy to do, and is an extension of the cutscene system.
The tutorial system is heavily game specific. And might be a little weird to handle.
I’ll do it the disgaea way and have a lot of game script commands to handle stuff…
As the tutorial is heavily game specific, I’m probably just going to hard code this without exposing it to the script system other than
“Tutorials will tend not to work outside the level they’re in, so I need to make a World Stack system to get this to work. So cutscenes can setup their ideal world system” (START_TUTORIAL (TUTORIALID))
It’s polish, but most of hte UI is highly unlikely to change since it’s nice looking and utilitarian. So I can afford to polish this.
(STRDAMAGE SCALE ADDFACTOR ADDFACTORMAX) (AGIDAMAGE SCALE ADDFACTOR ADDFACTORMAX) (LCKDAMAGE SCALE ADDFACTOR ADDFACTORMAX) (INTDAMAGE SCALE ADDFACTOR ADDFACTORMAX) (FIXEDDAMAGE A B)
And stuff like that. I can’t support a lisp parser so this is the best I’m really allowed to do.
This is a callback system for the scripting language, (it’s really a function call…), but this is a better way to handle this.
Signals can also query their amount of activations to simplify some things. If they have to. (It’s kind of like a function actually…)
The save record will always produce the “best” version of a character.
Unless the level editor explicitly disallows this.
(PARTY-MEMBERS) => List of party members (NTH) => Lisp nth (PARTY-LEADER) => Party leader (IS-PARTY-MEMBER “BASENAMESTRING”)
stuff like that.
This is a block (like progn), which allows all actions within it to be executed at once, when awaiting, we wait for every action in the block to finish.
Parallel blocks can await for other parallel blocks if they want (practically this is limited but it should be okay.) #+BEGIN (parallel (progn (move-path “miguel” (get-position “abcdefghijklmnopqrstv”)) (hop “miguel”)) (move-path “yoshua” (get–path “abcdefghijklmnopqrstv”)) ) #+END
In theory this behavior should make miguel move. Then hop. Then move-path
For crates / barrels primarily.
Normal entities will roll to fight back when they are picked up automatically at the start of a turn. If they get out, they can do an attack worth 75% of their max attack, and are moved to a valid adjacent spot next to the person carrying them if they can.
If entities are unable to dismount themselves, they will do a fixed 30% of their maximum attack.
Chest / Barrels or otherwise throwable “prop” entities, are not combatants. They are basically just living props that you can attack.
Rules:
- If BREAK_ON_DESTRUCTION, EXPLODE_ON_DESTRUCTION
- Entity immediately dies when landing, and will do the aforementioned things.
- If Normal Entity
- Thrown onto another Entity
(Act as if the thrown entity did an attack on itself and the thrown), it is an attack about
50% of their maximum normal attack. (so that way it is deterministic).
They will bounce off the entity they got thrown on top off.
- Thrown on a valid tile, they will just land there.
- Thrown onto another Entity
(Act as if the thrown entity did an attack on itself and the thrown), it is an attack about
50% of their maximum normal attack. (so that way it is deterministic).
(For self spells! Not that we need those per say?)
This isn’t complicated but requires a lot of parsing work so this isn’t happening today.
As of right now, it is possible to “noclip” attack entities even though you probably shouldn’t be able to. So we’ll have to do another floodfill style system… again!