A beautiful, sunny day and I am inside refactoring code, to point to my new StageManager script.
When I began working on the prototype, the goal was just about getting one stage of the game working. Confident that I know how the game will operate, I am returning to areas such as the Stages system, and ensuring related data is in one easy to locate place, for ease of game balancing.
Last week, I did some game design, using paper-planning to explore how I would design and implement the StageManager script. I have a day-job, so over a few evenings I designed functions that would allow easy expansion of my previously single-stage game, to multiple stages. Setting up some new data structures in my StageManager, I opted for a list to display my ‘stages’, then a struct array for the numerous ‘targets’ the system could randomly choose from, and then some integers inside the struct, to contain target meta-data.
I chose to use a list, rather than a nested array, because it allowed me to bundle additional stage-related data together, in the inspector, which meant the data was easier to manage for tweaking values at a later date. While it’s good practice to try and limit use of structs to immutable data, I am using a struct to contain several integer variables, generated at the start of each stage, and these values don’t change during game-play, so it shouldn’t impact on performance.
I also did some webdev, updating this wordpress site, to add a DevBlog, so I could stop spamming my friends and family with confusing game-dev updates, on my personal FaceBook page.