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.
