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 :wink:.

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 :mellow: ?!).
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!!! :D). 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 :mellow:), 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 :D. 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 :wacko:).
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.
Best regards.