Whew, what a month it’s been!!
I’ve made a number of fundamental rewrites to the code in the project. It’s leaner, cleaner, and more extensible than it was a month ago! Here are some of the highlights:
- The first change I should mention is that the entire thing has been ported to Unity 2019! The process involved re-importing every asset and effectively reassembling it all, piece by piece. I also rewrote several classes that I wasn’t happy with, and many now use Events instead of Update() so there’s a pretty significant performance savings here. Honestly, the fact that I had to reassemble it means it was built incorrectly in the first place. Oops.
- I’m now rendering everything using Unity’s shiny new Lightweight Render Pipeline. This will allow me to create complex animated shaders using the Shader Graph, which I very much plan to do. 😁 It also future-proofs the project in an important way — after all, Unity doesn’t plan to stop supporting their new rendering pipelines any time soon.
- Play mode’s Game Manager has been completely rewritten and is now far more usable. Previously, it was a glorified switch statement in an Update loop. Now, it’s an fully blown state machine where each state is its own class that is properly hooked in so that the turn queue relies upon it to progress — I now control the flow of the game. The class is also able to load and unload itself properly in the event the user goes back and forth between it and the main menu. With this system, I have far more control over when methods fire and I can now easily write events that are context-sensitive.
- As a result of the Game Manager being rewritten, I was able to implement a Turn Order and Phase window. Within it, users can see which player’s turn it is, as well as what the current phase is. This makes it easy to see, at a glance, how close the game is to being your turn. It’s also a great debugging tool so I can know if there is ever an issue with the turn queue….which there hasn’t been since the rewrite. Boom.
- Edit mode’s save function now auto-flattens floating point errors from the Y values of tile transforms. No more random player hopping! The best part is that it simply clamps the number, so you can still increment Y values by steps of 1 and the Player’s Jump move will continue to work. More on that later maybe.
- A number of scripts which both Edit and Play mode rely upon (I know, that’s bad) are now being embraced lovingly by my fancy new encapsulation code. Gone are the days of “null errors that I’m ignoring for now” simply because I was too lazy to write a system to check it against.
- I removed like forty gazillion Debug.Log statements that I no longer need….or rather, I commented them out in case I need them again because I’m super noncommittal like that. Either way, the Console is usable again and holy crap Debug statements use a lot of CPU for what they do.
- Finally, I’ve packed five maps into the build this time! Honestly, it was a challenge not to pack more now that the bugs are all fixed. When this thing works, it’s actually really fun to build maps, then load them into Play mode, even considering that the main mechanics of the game haven’t been built yet!
I’m really happy with where the game stands right now. It’s a misnomer to call it ‘stable’ but the code is the most solid it has been so far. I feel confident that I now have a good base of code to build and test additional mechanics with.
I’m leaving for Vegas for a week on Thursday, so I will be away from the project for a little while. When I get back, I’m thinking of getting into Substance Designer so I can learn how to build out high quality materials for this and future projects. It seems to me that this would be a great way to differentiate the tile types – perhaps a ‘shop’ could be represented by bricks (like brick-and-mortar) where a ‘vacant plot’ might be, well, a concrete plot. You can see where this goes.
That’s it for now! See you all in the next update!!