It’s been over a month since I got back from Borneo, and there’s been a lot of catch-up at work and around the house. Plus, I seem to have picked up a new hobby (macro photography of local bugs), so I have a plethora of excuses for not getting back to work on the game right away.
Excuses, but not reasons. I think, in reality, I’m hesitant to jump back into it because I finally got it to a state where it actually looked presentable. I mean, not as a game, but at least as a work in progress. As soon as I recommence work on it, I’m going to have to take it apart again, and that means making a mess that I *just* got finished cleaning up, that might not be “clean” again for months.
I realize that’s all nonsense, but that’s where my mind is right now. I’ve been putting it off for too long, though, and so I’m upgrading Unity (looks like there was a major version update recently) and biting the bullet: time to get serious again.
So where are my priorities?
Fix all of the inevitable broken bits that come with upgrading to a newer version of Unity
Implement some sort of in-combat dialogue system (along with a way of determining which dialogue to use when; I want the combat scene to be completely modular)
Bring up some sort of character stat screen from within combat (in case you want to check stats/weapon specs/etc; I think in order to keep it simple I’ll be preventing the ability to swap weapons/armor mid-combat)
Start working on the “full version” of the character stat screen, to allow you to level abilities, swap out gear, and view other information. This will be used during the “down time” scene, which should be the next major phase of the project after combat.
Well, not entirely. But over the last few days I’ve had to completely reorganize and redo huge chunks of code, and each time it’s started as just a minor “well, I need these two animations to be able to play at the same time” sort of thing, and turned into a “861 compiler errors? How is that even possible?” sort of thing.
I’ve got it back to a (mostly) working state, but I think I’m about to do it all over again, because I just realized there are no animations or health bars when it comes to the “happen every turn” status effects (like bleed damage, for instance). The function I created that runs the “start a new turn” function basically resets everything back to normal as far as things like “currently playing an animation,” “waiting on the user to select a target,” and “selecting a weapon to attack with” statuses, but it also runs the upkeep functions for each special status in effect. Some of them are pretty minor, like the one that boosts an ally’s defense, but for something like “on fire,” I need to be able to play a burning animation, show the affected unit’s health bar, change their sprite over to the “just took damage” animation, decrease their health, and then check and see if I need to kill them off or not. And then if they died I need to figure out what to do if it was about to be their turn (or was already their turn).
And again, like usual, this is sort of a mixed bag- on one hand it’s super-frustrating having to keep going back and redo stuff I’ve already done over and over.
On the other hand, it’s really forced me to optimize my code a lot more than I normally would have by now. Optimization is something I’ve typically saved for last, after I know everything actually works, even though I know that goes against every list of “best practices” in the book. But getting rid of superfluous loops and awkwardly-named variables earlier in the process definitely makes the later-on-down-the-road steps a whole lot easier, so I’ll count it as a net gain.
So what do I have left to work on?
I’m still tweaking stuff with the “special abilities” in combat, mostly because I’m trying to get them to share code with the “use item” function- they both do exactly the same thing, except the specials have cooldowns per person, and the items are dependent on how many are left in your inventory.
I need to refine all the concurrent animation stuff- I thought I had it worked out, but after realizing that I forgot to account for things that happen right at the start of a new turn, I can see that there’s still plenty left to do.
I need to implement some sort of in-combat dialogue; I’m hoping I’ll be able to re-use most of the dialogue code I set up in the non-combat scenes. I’m not sure how often I’ll actually use dialogue during a combat sequence, but at the very least it will be necessary during some of the “boss battles.”
At the moment, none of the weapons have pop-up descriptions (well, they do, but they’re all blank), only two of the items have names (and only placeholder descriptions), and only a few of the specials actually have any code associated with their DoStart(), DoUpkeep(), and DoEnd() functions. I can’t decide if I want to go ahead and get all the “fleshing out” of the combat stuff done now, or save that for later once I have a better idea of what sorts of weapons, specials, and items will be necessary throughout the course of the game.
And, you know, the whole rest of the game, of course. But for now, I’m just looking forward to getting the combat stuff out of the way so I can start working on the “fun” parts. Next week my wife and I are headed to Borneo for the honeymoon we never got the chance for; I think it will be good to have that forced distance from my game and the obligation to work on it, so long as I can get it to a good stopping point before we leave. There’s nothing worse then having to pick something back up that was in the middle of a major mess.
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.
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.
It’s been five and a half years, almost to the day. I haven’t forgotten about the game or this site, but game development has definitely taken a backseat to a lot of things going on in my life. Not shuttered, just… given a heavy dose of tranquilizers and tucked away.
In the last five and a half years I still haven’t completed any just-for-me projects, but I’ve started and stalled a few different iterations of the game; each time the story changes and evolves, and I feel like it’s finally where it needs to be, story-wise and conceptually. I turned it into a tabletop RPG campaign that I’ve played (and also stalled on) with a group, and that helped to give the story more shape and substance than any amount of daydreaming and storyboarding I’ve done in the past.
I’ve experimented with a bunch of different game engines, and a bunch of different styles. I keep falling back towards something simple, though- I don’t want to spend years trying to develop just a basic structure to try and build everything around. Isn’t that the entire point of using a pre-built game engine? I went full-3D for a while, but after the amount of effort it took just to build what would only end up being the first few seconds of gameplay, I think I’m going to de-volve towards a classic point-and-click adventure game, with a couple gimmicks to give it some flavor outside of the old Sierra or JRPG styles.
And so, having finally finished the last of my schoolwork (just waiting on the degree conferral process, now) I think it’s time to dive back into development in a more serious way. Way back in the day, I used Construct 2 to build the beginning of my game, and I was pleased with the results. I think that’s what I’ll head back to- Construct 3 has been out for a while now, and looks to be the next best thing. Maybe I’ll take a little bit of time and see how much work it is to build the first level in Construct; if it’s not too bad, I can stop searching for something new and finally commit to making this work. Again.