Hey all! Here’s a rundown of things tackled last week:
I’ve begun to notice that code compile time has slowly been crawling up, to the point where it could take 20-25+ seconds for any code change to recompile.
While this might not seem like the worst thing ever, it becomes bothersome any time I need to change one thing in code, or a variable, etc, and then having to wait another 20+ seconds for that to compile, and then roughly another 5-8 more seconds for the game to actually start…
So, in an attempt to reduce this time, I went through all of the existing code and begun reviewing classes and methods that could be simplified, or removed entirely.
While initially daunting, it provided the opportunity to revisit a lot of code I haven’t seen in a while, a chance to rename some of the variables/methods to provide better readability, and came to the realization of how much junk I could actually clear out.
I also ended up sorting a lot of scripts and assets around (some things subject to change):
After doing that, I ended up not only getting rid of a lot of junk, but dropped the compile time down to 11-13 seconds! This ended up taking a bit more time than I expected, but overall, it was worth it for both time save, and improving code quality/maintainability.
- We did some character sheet development on some characters you may or may not see soon ?
- Worked on some keyframes for some of the enemies, as well as for Easton/Weston and another character yet to be seen.
- Updated combat system to include “multi-hits” in frame data.
- Added a new actor state: “Stunned”
- Did a LOT of changes to the cutscene system:
- One of the biggest problems was something a little more mundane: Finding the best way of moving characters in a cutscene.
- Instead of animating characters using a Animation Timeline, I elected to use an Event queue, where you’d pass in an event/command into a list, that event happens, and then that event is cleared from the queue.
- For the movement system, I discovered and realized during testing, that my current “MoveTo” events would cause actors to move one at a time. This would be problematic for situations where multiple characters need to be walking at the same time.
- I ended up (painfully) rewriting this, and now multiple actors can move in one MoveTo event.
Another thing: Animating the actors:
- When the game is not in Cutscene Mode, characters are animated based on the state that they’re in. While the game is in Cutscene Mode, they are only in one state: Cutscene State
- The Cutscene State deliberately doesn’t provide any animations or functions, so that it can act as a blank state.
- This would allow me to do things such as calling an “Animate” event, which would allow me to change the currently playing animation for an actor.
I’ve found that it’s pretty annoying to have to make an Animate Event to get the Walking/Running animations playing anytime I have an actor move. So instead, in the MoveTo event, I have the code toggle between Walking/Running/Idle animations, depending on their velocity.
I also updated the UI/Inspector for making/updating cutscenes. Before, it was not as friendly to deal with:
We’ve also been working on an “NPC Builder” that will automatically create and somewhat configure new characters with all of the base components to get a character working: