I’m approaching this version differently than I have other versions in the past. Namely, I’m trying to handle everything in smaller, more incremental chunks. Before, my plan was always “get it put together as close as possible to the finished product (at least on a per-phase basis), and then spend however much time necessary fixing it.” The reasoning was that I would be less likely to have to go back and redo sections as I found that newly-added features necessitated major changes and alterations to past code.
I’m not sure that’s really the best idea, though- for me, anyways, it always seems to lead to a sort of burnout, as I’m faced with trying to get something functional out of this monumental mess of just screen upon screen of code. This time, I’m breaking it into smaller chunks, even if it means I have to go back and undo/redo parts in order to work on the next chunk, so that I’ll have something to show for even small amounts of work.
For example, I’m currently working on the combat function (WIP showcased below using prototyped graphics). Rather than try to get all of the features in place before I start bugtesting, I started with the entirety of the combat level doing nothing more than reading the data from the necessary XML serializations and then placing the placeholder sprites where they needed to go, all as the “full function” of the level.
Next, I worked on the GUI at the bottom of the screen, making it so the mouse could hover over everything, change the text boldness, and click to select as necessary.
Then, I worked on making the clicks change the text in the GUI, even though that meant going back and adding all sorts of extra variable definitions and functions.
Afterwards, I started working on making just the “Change Position” function work so that it would instantly teleport the characters where they needed to go.
Once that was done, I went back and rewrote the code so they would actually animate and run to the desired location.
Etc, etc, etc…
Obviously there’s still SO much left to do, and it’s a little frustrating knowing that every time I start on a new step, half of what I worked on in the previous step is no longer relevant. But I think doing it this way helps me to stay motivated- instead of having to put weeks of work into just a screen full of code, I get to watch the incremental changes and evolution of the game gradually, a day or two at a time.
The “two steps forward, one step back” method seems more frustrating on the surface, but I think the key is that the frustration is kept at a manageable level, being “cleared away” every time I make measurable progress. If I were more organized and had more time, I’d probably try to do it right: sit down and paper-prototype everything out with flowcharts and design documents so I had more of a plan. But after multiple iterations, I think I’ve finally settled on the “lesser evil” as far as my personal game development methodologies go.
Right now, the main struggle is just trying to overcome the frustration of having to redo everything in Unity that I already had working in the Construct version. Construct really was very well-optimized for simple 2D GUIs and basic sprite movement; it’s taken me a significant amount of time to reproduce some of the effects that were basically single-click-setup in Construct. I’m confident that going with Unity will pay off in the long run, though; I’m already seeing the benefits of working in an actual object-oriented language as far as modularization goes.
So, here’s hoping I can keep it up.
