Haven’t written in a while about what is up with Operation KREEP or my next game, not even game-tech related posts, and I think it needs a little explanation ( at least me, myself, are in desperate need of some honesty towards myself 😦 ).
After I finish my rambling about “life and stuff”, there will be some tech talk too in the topic because I dislike not showing anything fancy, so if you are only interested in that part, scroll down a couple paragraphs 😉 .
So why isn’t the next game announced, I’ve already mentioned it twice before, that it is close to being playable, and in the upcoming weeks I may even distribute an open alpha build…
It is still not ready for that (no kidding 😐 ?!).
The last month was somewhat “wasted” from a gamedev perspective. Wasted is a harsh word for it, but the truth is I feel a bit ashamed of how the last few weeks played out (development wise), so it kind-of fits. Instead of mostly spending my time with the development of the new game, I’ve mostly spent my time with “engine-tech”. The worst part is, that it got a tiny bit out of control, since if I’m going to be really honest with myself, at least a week worth of development was 100% unnecessary for this upcoming game.
A little back-story:
As many of you may already know, I’m developing my games using C# and the framework of my choice is XNA/MonoGame. This goes way back in time (almost 10 years): Unity did not exist and XNA was a hot new tech (in BETA or 1.0 which was extremely bare-bones can’t remember) when I started learning programing ( University + the ultimate purpose of being able to make GAMES!!! 😀 ). Back than it was a natural choice and worked wondrously. Fast forward to today and MonoGame is still a great choice, if you have professional programing experience (or want to learn programing) and you are ready for some game-system/engine development compared to Unity, but for a more complex game, lots of stuff has to be coded (no physics, no advanced rendering system, no UI system etc…).
I actually like this level, I feel comfy working this way + I’ve been building and growing my own “framework” (or whatever it should be called) on top of XNA/MonoGame for years now. I have a keen eye for software quality and I’m especially proud of it’s feature level and stability, and I’m really productive when using it to develop a game.
I think, that last one (productivity) is the most important part when it comes to “choice” regarding your language/framework/engine/tech!
But, and here comes the BIG BUT:
It is still only a light-weight game development framework. Not, that there is a problem with that 🙂 , but if I would take the time to get proficient in Unity, most probably I could be just as much, or even more productive, especially looking at the current situation when I go in to game-tech feature creep craze 😦 .
Nowadays, I’m trying to make more out of working on games (living / business), so this becomes an increasingly important question, whether my time is spent well working on this framework. The answer is probably no, but my current level of productivity and emotional attachment ( I don’t know what else to call years of hobby development 😐 ), keeps me working on it. Of course I have more rational reasons than that, but the post would be humongous and it is already big 😀 . From now on, I have to be brutally honest with myself when it comes to this question and be more self-aware when it comes to tech development decisions.
A little more detail about the current project/situation:
I wanted to upgrade my testing framework for this upcoming project which went surprisingly well and happened pretty fast, but this game I started working on required numerous other features which were lacking from the framework too. I decided, that I’m going to spend approximately two weeks on development of these features in isolation, not really jumping into coding the game beforehand (just only the basics), so I can focus on delivering clean and stable code for starting production.
This became four weeks, due to various “common” reasons: underestimation (only a little), forgotten pretty important framework related developments ( these were not even estimated in my backlog 😦 ) and a week amount of feature creep.
The only conclusion here is the same I mentioned before, I need to re-think how much energy I pour into this code-base, and whether it is going to be “worth it”.
Now, that I have everything in place (and got out of this spiraling feature-creep menace), the development of the game is advancing, but it is still far from a presentable state 😦 .
Here comes the technical part, what I’ve been working (wasting my time) on:
The major part of the tech development was a proper UI/Widgets system. For Operation KREEP I used a simple approach, where each UI element was a simple graphic object positioned relative to it’s parent UI element. Nothing fancy just a simple base class with a position and an attachable graphic (e.g.: sprite, text etc…) arranged in a tree-like hierarchy, lean and clean.
No built-in serialization logic, no scaling, no anchoring, no alignments, no padding or margins, even mouse input handling and a good event system was missing! For the most part it was OK for KREEP (not much UI and pretty simple), but it was certainly an insufficient solution, and a lot of stuff had to be done in the project code-base and hard-coded while working with it. Yep, pretty ugly 😦 .
The current strategy game I’m working on is much more UI heavy and will have a pretty different look (not pixel graphics + different resolutions), so the before mentioned “problems” had to be resolved. I heavily extended the old system, and implemented a two-pass layout engine (measure the elements of the hierarchy first, than arrange them based on their requested size), with some fancy additions (e.g.: nine-patch sprites).
This is how it looks now:
And, than it hit me, I forgot about auto-tiling 😦 …
Yep, I pretty much forgot to estimate and put this feature into my backlog when designing the game. And no, it is not some fancy tooling stuff, which I don’t really require, but plays a kind-of an important role in the game. It plays a big role in the looks of it, which IS important, so I had to implement a run-time auto-tiling feature. This is how it looks in action:
It only handles one type of surrounding tiles (supporting multiple ones is ridiculously difficult + the game did not need it) and supports both four-way and eight-way rule sets.
And, while working on auto-tiling I made a performance bug…
It was a mistake I did not discover while testing my code. The internal data-structures were handled incorrectly, and with an imperfect stop condition, from time-to-time the auto-tiling took more milliseconds than a frame should at 60 fps, so I sat down to hunt for the reason of these frame-spikes. Needless to say, that I already had a vague idea how to approach the problem and where to look + an existing .NET profiler would have revealed the exact issue in mere minutes (if not seconds), but somehow I felt this is the sign of the “NEED” for a visual profiler ( I don’t know what pills I took that morning 😐 ).
I was already way out of my frame-work development time budget but still the creep emerged from the dark depths of the unknown and engulfed me. I took the time (few days) to develop my own visual profiler integrated into the framework…
This is how I imagine that mental state from now on. I can’t exactly remember or picture it, so this will do 🙂 .
After this point, I’m still not over the feature creep, but starting to grasp reality!
Took a couple more days to wake up from the refactoring madness too…
That is enough from the wall of shame of Spidi. Next week will finally be about my upcoming game.