Lots of progress has been made on multiple fronts.
The combat Scene now properly loads a level(different from a map) and tracks mouse movement. It also Is able to load dialogue once specified conditions are met. I've also got the scaffolding for Adding camera controls and overlays to highlight parts of the map, though it isn't quite presentable.
 |
| Here we see a sample dialogue from dialogue manager playing once the map is loaded |
Then general workflow has the battle load up everything. Data specific to the scenario is pulled from a scenario file and stored in a map node, which has wrapped code to access it. The debug console does not like accessing instantiated nodes, so this allows me to access the map indirectly. I'll likely need to do something similar for when I add units.
The scenario file is a node, so I'll be relying on virtual functions to add in dialogues, victory conditions, and anything else a scripted battle may need.
I've also developed a couple of tools to assist in making sprites. Character sprites(I'm calling them actors as they will also control movement and actions) will be one of two types: component actors and sprite actors.
Sprite actors will be straight forward sprites. They are a single loaded texture that can play animations. ComponentActors are made of multiple sprites in order to facilitate customization. Change armor? The sprite will reflect that.
I am using the Time elements Character Core Set and the expansion, both by FinalBossBlues. The pack does come with a character generator that can generate spritesheets for you, but that would mean I would have to prebake every sprite.
What I've done instead is create the Sprite Slicer too.
It is easy to use. I'm using some of the frame lists that FinalBossBlues uses for his animations. So the walk cycle will look the same as the pre generated one. If I wanted to change a frame, I just need to change the array entry.
Once The animations are done, I then run the script, which will generate each animation in all 4 direction and store them in an animation library. I can then load that animation library into the Actor class and it will have access to all the animations. The actor also already has a premade animation tree to handle transitions.
This is the core logic. It creates the empty animation and creates a track for the sprite sheet.. It then adds each frame, spaced out by a speed variable defined earlier in the code. This means all animations will run at the same rate.
Finally, it adds the animation to the library created previously.
The spritesheets provided by FinalBossBlues each have 4 rows of animations, each one representing the sprite in one direction, so it is easy to just run the code 4 times, once for each row.
I purchased these assets, but I'm not sure if I am allowed to post one as an example.
I've also mostly finished a tool to use these spritesheets to generate sprites.
This one runs in engine and allows me to see a sprite with different pieces from different directions. It does still need a way to actually export the animation and preview animations, but the core of it is working.
This code feels a bit messy, but here is the breakdown
This shows the script where to find the spritesheets.
This is a bit of a monster of a datastructure definition.
The Inner Dictionary correlates Each Sprite type with the different colors it has available. For example, The first type of of hair contains hair1.png, but it also has color variations hair1_c1.png, hair1_c2.png, etc.
The outer dictionary then stores all of the sprite types with its category(hair, weapon, etc.).
After some boiler plate, we then make a spinner setup(I called it a SpriteMakerComponentPicker) for each category. It updates the texture when either picker is changed.
Some components have a 0 item index (bottom0.png), so instead of getting the spritesheet by the value of the spinner directly, I have to use spinner's value to retrieve the key that we need.
At this point, I can likely combine the events into one.
Component is a basic data structure used to help find the spritesheet's filename. everything follows the format
categoryX.png or categoryX_cY.png,
except weapons, which swap category with a weapon type,
I've left a lot of code out, but if you are interested in seeing a more complete version let me know.
Currently I have the following short term goals:
- Make the SpriteMakerTool Export to file and get loaded by the Actor class
- Give functionality to the actor class. Perhaps I'll go back to calling it a sprite and abstract movement code.
