March 2019

Recently, some friends sent this video my way:

Not only do I love game development “behind the scenes” videos (especially when the creator is obviously passionate about what he’s made), but I love Dead Space, so this video was right up my alley. It went into surprising detail about the technical aspects of the scene in question, and even just the design philosophy behind Dead Space as a generality. Watching things like this always gets me pumped up and excited to work on my own game.

The main problem, at the moment, is that I’m still a long ways from being able to work on the “creative” parts. Right now I’m still working my way though the combat system. On one hand, I don’t want to sink too much time and effort into this aspect of the game, since I’m not planning on combat sequences being that frequent (off the top of my head, I’d say about a dozen over the course of the entire game, maybe even fewer). But on the other hand, I want to make sure I avoid the combats feeling like “throwaways” – they need to feel just as unique as the rest of the game.

I’m having a hard time coming up with things to make combat seem special, like more than just a standard JRPG-clone’s battle. The mechanics will be loosely based on AntiPaladin’s Mini Six tabletop roleplaying system, and I’ll be adding in a few “special abilities” that can hopefully add a little flavor. Outside of that, the only thing I can really think of to spice up combat is to add dialogue to try and bring it back into the plot. If I go that route, I need to make sure the dialogue doesn’t get too repetitive, and is interesting enough that people won’t just “click to make it go away” and focus on finishing the battle instead.

Even implementing that, though, is still “mechanical” in nature, rather than creative. I’ve come to recognize these motivation slumps throughout my process, but I don’t really have any surefire way of getting through them. Mostly I just have to rely on knowing that once I get this stuff taken care of, I’ll be able to work on parts of the game that will actually be more fun.

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.

Per usual, work got in the way of my programming time more than I was counting on, but even given that I still managed to make some decent progress in Construct 3. The new Construct interface is entirely web-based, and integrates very well with Google Drive so my entire project is stored in the cloud (which comes in handy when I want to work on it during my lunch break, and also at home on a different PC).

Construct has a lot of pre-defined behaviors that are commonly-used in game development, and they cut out a lot of the time it would have taken me to program those behaviors myself- click-to-move and pathfinding, for example. However, I started running into the limitations of a game engine designed to be “code-free” when I started working on the combat system. Trying to access and manipulate data that’s better-suited for something structurally object-oriented was… extremely frustrating from within the Construct engine. I spent probably five or six hours trying put together the equivalent of a serialization/spreadsheet hybrid in Construct, while doing the same thing in any C- or Java-based language would have been a nearly effortless endeavor. So finally, after attempting the programming equivalent of painting a masterpiece with an etch-a-sketch, I gave up on Construct.

Back to Unity it was. I originally discounted Unity because of the amount of effort it would take to go 2D in a system that was designed for 3D. However, that was 6 years ago, and Unity has evolved a lot in the meantime. I’ve had to program a lot from scratch, but it’s only taken me a few days of work to reproduce (and improve on) the click-to-move, pathfinding, and dialogue-imported-from-XML systems I had working in Construct. Unity seems to have quite an active community of 2D developers, so there are lots of forum posts and discussions out there when it comes to trying to find a solution for a problem I’m having. After just these last few days, I’m already more-than-satisfied with the preliminary engine I’ve cobbled together, and I think Unity is going to be the most efficient path forward.

Another advantage (well, disadvantage that I’ve found a silver lining in, anyways) to using Unity is that it’s forced me to embrace source control in a more professional manner. I’ve had *very* minimal experience with true source control in the past, and now that I don’t have access to Construct’s Google Drive integration, I’m using a SourceTree/BitBucket combination for a true Git source control solution (as opposed to the method I use at work, which is basically a buttload of windows folders on the share drive named things like “version 1.0,” “version 1.1,” and “version 1.1 backup”).

So now I’m about to get started on the combat portion of the engine, which will likely take me a significant amount of time. From there, I’ll need to work on some sort of character stat/level up screen, and then the “down time” screen (for between “missions,” that will incorporate all the time-management stuff in it). Once I’ve got those finished, I can get started on the actual meat of the game itself. I’m sure I’ll run into other aspects of the engine that will need to be fleshed out as I start digging in, but once I have the Scene, Combat, Menu, and Home-Base portions finished, the engine will be at a prototype-ready state, and I might finally have something worth showing off.