Blogs - Spidi777

Hello everyone!

Even though a lot of indie game developers put together a "year in review" posts by the end of December, I haven't written in a while. Sorry for that, but the last few months of 2016 were a bit busy and chaotic, that is why I wasn't in a mood of writing down my version and why I needed some vacation time badly.

For two weeks I was off-line, not touching any social media, spending all the holidays and some extra spare time with family, friends and games (Factorio, Risk of Rain and Torchlight 2, lots of fun :) !!!).

I'm ready now to write down my thoughts about last year and to plot my plans for the upcoming one which is full of possibilities :) . I separated various topics into their own paragraphs with their own header if someone is only interested in specific aspects (and for tldr reasons :D ).

Last year, pros and cons

2016 was a game changer for me (pun intended). I started working full time on my games (huge decision), had my first Steam release and also made an update for Operation KREEP (well received by existing players), participated in a Steam sale (again, first time for me), and haven't made much money :D . I was prepared for this, since I already read a lot and knew about the financial realities of indie games + Operation KREEP was already on Steam when I made the shift, so I planned out my indie venture in a way that more than a full year is available (due to lots of savings) to release multiple games, so no biggie.


A lovely Christmas present I've got from my wife to celebrate and remember my achievements as a game developer, much love :) (sorry for the bad quality, these are framed pictures of Memorynth and Operation KREEP).

There was a bad part though which made me pretty sad. It is my progress as a game developer and my latest endeavor, Unified Theory. I hoped, that by finishing two games and releasing one on Steam I'll be able to pull this off again and again. I feel like I learned an astonishing amount about game development during the production and the after life of Operation KREEP, but I failed to apply this knowledge on this project and failed to expand it ever since. At least this is how I feel about the last couple of months. The project is a mess and I came to serious conclusions and made an important decision in the last two weeks which I'm going to unfold in the next sections.

Operation KREEP

This game has a special place in my heart :) by now . I know it is not a big thing and commercially it did not break even, but it wasn't it's ultimate goal in the first place (most of it was developed while I had a day job). I released it last summer on Steam, and so far with the other stores, sales and bundles combined at least it made some pocket money. As I mentioned, I learned an awful lot about planning, production, pr, marketing, publishing and further maintaining a game (so the whole gamedev package).

During autumn, I made and released a small update for it and experienced the black magic of traffic analysis, visibilities, the wishlist, the discovery queue and the like on Steam first hand. KREEP was also discounted during the winter sale. Together these two events netted as much as the Steam release, which wasn't much but it is still nice. May be an important bit of info to all indies out there: there is a tracked average conversion rate of all wishlists on the whole Steam service (which is kind-of a low percentage for real :| ). Do not expect a bigger number than that for your game, even if you discount or update your game (you know, DOOM and XCOM2 is also discounted all the time :P ). Maybe in the long run it can be better with multiple discounts and updates.

A small announcement regarding the game:
It is currently taking part in an Indie Gala bundle. If you are interested in trying it out, now you can get a Steam key for it dirt cheep + keys for 11 other indie titles on Steam ;) .
I know bundles have a rather bad reputation these days, but they sort-of allowed me to get the game on Steam in the first place + it is now in the Steam library of thousands of players, which probably would have never happened otherwise. I know bundling your game probably means, that it is not selling well (heck it usually is an equivalent of a 75%-90% discount), but you get some word out about your game and you get a lot of new players, even if it only yields a tiny revenue.



I'm also working on a Linux/Mac port. There have been multiple requests for both builds + having cross-platform development experience and a build pipeline in place is valuable in the long run (I know, that both users combined are still less than 10% of all desktop gamers), though I'm still fighting with the Linux build :D :( , but slowly getting there.

Unified Theory

A mess. I'm going to expand on this, but I have to explain what type of development process worked well for my previous two games. Growing up, I was always a tad bit disorganized. So when I finally decided to pursue my dream of becoming a game developer, I knew I had to get myself together and become more disciplined. I picked up some management know-how during my half-decade long career as a software developer and decided to apply the fundamentals and pick up a management hat too (besides the programmer, designer, artist etc. hats) while I work. It worked wondrous, so much so, that I considered it my best decision and one of the most important factors for shipping a project. I divided my projects into phases like planning, pre-production, production (and this one into smaller chunks like alpha, beta and final as milestones, due to being a big phase), release and post-production. Estimated both the possible time requirements and risks of various tasks during the planning phase and sliced up tasks until they took only a small manageable amount of time (maximum a day or two). Writing a quasi detailed game design document during planning and extending it in pre-production helped a lot to have a clear vision, and also documented all the possible extra design ideas I may want explore during production if I have the time/drive. During production I tracked the time I spent working on the project on an hourly basis, and kept a small TODO list too to have a prioritized list of tasks to focus on during the next couple of weeks for reaching each consecutive milestone. I also adjusted my estimations when closing a phase or reaching a milestone to have an up to date educated guess what is coming up and how far I'm actually from finishing and releasing the game. Everyone works differently, but if you are having a hard time with budgeting your game, or always over-scoping it, or ending up in a constant spiral of "it will be finished in two months maximum!", I highly recommend you try out these things. Seriously.

Now this proposal concerns me too :( . Even though, these steps helped me to ship two games before, I pretty much neglected them while developing Unified Theory. I did do an estimation, I tried to cut some features (but did not do it properly), I kind-of divided the whole thing into phases, but never checked nor readjusted my numbers, and never tracked my time rigorously. Slowly, I took off the management hat. I was aware of it while it was happening, still I tricked myself into believing it is not a necessity, because I already shipped a game before + I have a huge drive now, even bigger than with my previous games (I loved the concept of the game + not earning money currently :D ). Thankfully I realized the horrible mistake I've done and I can act upon it now.

These are the estimation numbers and the real work hours spent on Memorynth and Operation KREEP (+ Steam release and updates). For Unified Theory the spent hours are just an approximation based on the days spent working on the project, since I only tracked about the third of the work time I spent on the game. It is kind-of clear on the readjustments too, that I did not put enough effort into my estimations of Unified Theory. The frightening part is, that I only have approximately 50% of the tasks completed and almost as much time spent as the original scope, so I pretty much underestimated the project, did not cut out enough low-yielding high-risk features and never took the time to get my numbers together. This really bugs me. I don't really have a clear picture about what is and what isn't done, how much time it took to get here, what could I cut if the game turns out to be too big of an effort (which is already the case) and I especially can not make an educated guess about when could I complete and release the game.

A simple "okay, from now on I'm going to do it right!" will not do justice. I have to practice these skills again and I have to rebuild Unified Theory project wise when I reacquired the necessary attitude. For this to happen I'm going to put the project on the back burner, meaning from now on it is not a full-time project! Yep this is a harsh move, but I think this has to be done. I'm afraid of stopping it, since it would be the direct road to forgetting the project which would be a ridiculous waste of time and energy. So I'm thinking about working one or two days every week on it, to keep the momentum and the ideas alive, while I'm doing a short game project parallel to reinvigorate myself and to practice before resuming Unified Theory full-time. I think this is pretty sad in one way, but I'm confident, that this move will help me in the long run and will ensure, that the game will see the light of day in the best possible shape, only I will release it later than I originally "planned" :( ...

I'm overburdened

The header is pretty misleading :P . I'm not overburdened, actually I'm currently enjoying a "healing" time-frame both physically and mentally, but this is the title of the game I started working on last week parallel to Unified Theory. I have the core concept ready, working on the detailed game design document and the prototype currently. It is in an early state, so I'm not going to talk at great length about it, but here goes nothing:
It will be a really simple "arcadey" roguelike game, with some interesting/funny? twists to the common formula and I'm going to re-apply and practice all what I've learned during the development of Operation KREEP. Based on my initial plans and numbers it will be a really good project for this goal, because it's scope (even with a greenlight campaign and a potential Steam release which would be nice :) ) is smaller than the final scope of the original 1.0 KREEP release (before KREEP got onto Steam). This means, that it can be accomplished and published in less than three months by working on it approximately four days a week. These numbers may change during the planning and pre-production phases, but the scope will not be increased (instead features will be cut aggressively), since it is crucial to finish this project in a short amount of time, otherwise it may endanger the development of Unified Theory which I would steer clear of at all costs.

Website

Small news as closing remarks. I've updated my website a little. Made a new logo for my gamedev "formation" + added some new short stories and pictures. Also there is an official Magic Item Tech newsletter! Experts tell it is an effective way to build an engaged community :P , be sure to subscribe ;) .



Next week, I'll be able to tell (and show!) more about my roguelike pet project "I'm overburdened".
As always I'm open for critique, comments and suggestions.

Stay tuned!

Hi all!

I'm just posting a blog entry this time, to note that I'm reorganizing my blog (or my blogging practices), and switching to a blog + article setup. So far I only posted my writings about game development and dev-log entries of my game(s) into the personal blog section of indie db. I realized, that this is not too efficient nor a common practice on indie db (usually everyone posts game related news and features into the article section of the game page) and especially it is not too orderly.

So my next dev-log entry for Operation KREEP will be available under the articles section of the game page. It is already awaiting approval :).

See you soon!
Br.

Hi there!

The last two weeks were full of bad luck (health issues, disapproval from Valve, visit at a local veterinarian all kinds of things :( ), and as a result my productivity approached zero. Actually it did reach it when it comes to Unified Theory my upcoming game, but thankfully I could pull myself together to complete and release the 1.2 update for Operation KREEP.

The 1.2 update:

I've written a lengthy post about the contents and details of this update and not much has changed on this front, but I made some extra fluff for the game since.

A new box art kind-a thingy:

A new announcement trailer for the update:

I added trading cards to the steam build as it was mentioned (and requested) by many as a good value addition for steam games, because many players go crazy for collecting them. It was not a big deal to create them, but took surprisingly many tries to get every related content right and up for the requested quality bar (though descriptions and requirement docs. were decent).

The game itself hasn't been modified much. I found a few minor bugs and fixed them, some were new ones related to the new fine-tunings and modifications, few were old ones hiding for a while now, but nothing major. And as a last minute unmissable colossal modification which happens with every single software close to a dead-line :D , I enhanced the input buffering capabilities of the game and successfully incorporated a "buffered direction change tap" detection logic to make "tile lane changing maneuvers" possible. Seems to be working well, made the keyboard and dpad controls even more responsive and pleasant. It isn't actually that complicated, but sort-of interesting (I guess :|), so I'm thinking about writing a short post dedicated to the topic instead of delivering an inadequate explanation now.

I'm currently trying to promote the update and the game (press, youtubers, streamers etc...), but probably it isn't going to yield much results. I mentioned before this is not a big deal, I consider this an "experiment", so even if it does not show any return, the update was a rather small one to begin with.

Soon I'm going to have all my time devoted to my next game.

Next stop is the finalized look and the alpha release of Unified Theory which I've been neglecting for far too long now.
Stay tuned!

Hello everyone.

As I mentioned last time, I decided to do a small update for Operation KREEP and to change the "scenery" a little, last week I took a little more than two days off from the development of Unified Theory and made it happen. Thankfully my estimations were correct and the updated builds are ready to be delivered to various stores (and yes it is indeed a tiny update only). Preparing all the marketing materials for this update (trailer, announcement texts etc...) is going to take a few days so I'm guesstimating, the release will happen somewhere around this weekend or early next week. Until than, I'm going to continue working on the Alpha build of Unified Theory too parallel since I've made significant progress on the visual presentation of it in the last couple of days (a post with fancy pictures coming in a few days ;) ), but the focus currently is definitely the "marketing experiment" of the KREEP 1.2 update.

This time I'm going to dive into the technical details of the update, its design and the reasons why I decided to create it even though imposing serious time and scope constraints on myself.

Level design

The 1.0 version of Operation KREEP featured 13 levels and the 1.1 update increased it to 17 arenas. With this update I'm bumping that number up to 20, so adding in 3 extra. Even though this sounds like a relatively small number, from the beginning I went for quality over quantity with the design of the maps. My goal was to make both mechanically and visually distinctive levels delivering the possibility of varying tactics and play-styles on a per-level basis. Adhering to this goal made each consecutive level harder and harder to design and thanks to it I made various mistakes too, but I think I succeeded and with this update I'm also delivering refinements and fixes to the old levels.

Just look at the first few levels how blunt and simple they were, but the overall picture is vivid, lively and seems to be full of surprises and varied tactics :) .

A little about the level fixes:
The most common mistake I discovered is choke-points and too enclosed larger rooms "favoring" the KREEP. If the players get close to defeating the KREEP but it ends up within a larger room with low number of entry points, it becomes close to impossible to purge it. There is a "solution" where the players let the KREEP spread out of the room/choke-point and can destroy it more easily when it is spread thin, but obviously this was a mistake from my side either by not making this obvious to the players or by allowing a situation like this to happen...
Here is an example of where the map named "Vessel" was modified to be more fair (sometimes less obtrusive modifications were enough tough):

6 previous maps were modified with various fixes while making the 1.2 update.

Fine-tuning

A couple of small modification got into the update related to accessibility and difficulty. These are changes which are not immediately obvious or visible for the end user but they do make the game better, more balanced and a much less hassle to play (e.g.: UI streamlining). A short list of what this covers:

• Two new options on the "game-over" screen. Previously you could restart the match on the same level, with the same player setup and the same mutators (rule settings), or you could go back to the main menu to start a new match with a different setup. Now the new options allow to keep the player setup (because in a couch co-op you usually play with the same number of people after you first configured) and change the mutators or the level too for the upcoming match.
• I modified the KREEP power levels just a tiny little, to make the last couple of seconds of a match even more easier/harder based on the outcome, so if the players are close to victory it is now easier to score, and if the KREEP is close to eat the whole map it becomes even faster.
• I tried to make the "sudden death" mechanic play a bigger role in the game because I discovered, that some plays end up in a quasi stalemate situation, where players can not kill the KREEP effectively enough to destroy it (due to a lack of good tactic or PvP). Previously the KREEP got a speed/power boost when it reached 60% occupation of the level, but these stalemate situations kept the KREEP size just under it for long minutes easily, so I introduced a 2.5 minute timer to boost the speed/power regardless of the KREEP size, so a "stuck" situation will result in KREEP victory (yep I'm evil) instead of a long, grueling and probably boring match. I'm not really afraid of the negative implications of this modification since most matches tend to be between 0.5 to 1.0 minute and I feel 2.0 minutes is already a pretty lengthy play in this game (it is pretty intense and action packed). Of course the "No Sudden Death" mutator setting will disable this timer too!

Marketing

I talked multiple times about this update being a "marketing experiment". This means I'm going try to promote the game (or this update + the game) with close to as much time investment as with the Steam release. Besides the usual key mailing, I will try some new stuff too, focusing on the dark humor within it (funny poster, new logo/splash screen and Steam trading cards!). If it does not yield good returns it will not be a devastating blow on me, since both the update and the pr + marketing effort totals not much more than a week worth of work, so it is no biggie, but I really wanted to give a little more love + chance for the game to succeed, hence the phrase.

P.S.
While I was testing the new levels, my fiancée found one of the test cases fun to look at so I decided to record it as a bonus for this entry, because it is indeed fun to watch the KREEP sped up overtaking the levels :D . Enjoy:


Br. and take care!

Hi there!

Only a handful of tiny news this time about Magic Item Tech.

Domain

Now my game development blog and contact information can be reached at: Magicitemtech.wordpress.com
I've reserved this domain long ago, but forgot about it a little. Now it's set up to forward to my blog and feels a tad bit more professional. I'm already working on beefing up the graphics design of the site and preparing to have a newsletter service too for upcoming blog entries and game development news.
Soon...

Unified Theory not ready for Alpha

I'm preparing for the alpha release of the game, but it still needs a week worth of tasks to be done + some accompanying materials need to be created and organized to be ready (e.g.: a feedback form, some marketing media, maybe analytics too ?!). If you've already been expecting the open alpha, I'm sorry. I really don't want to rush it, since I would like to get feedback about the design and overall feeling of the game, instead of reports about minor bugs, glitches and the incompleteness of the user interface. So probably another week of extra work it is...

Operation KREEP let's play

James Kacer and his friends tried out Operation KREEP and they had a blast. So they made a let's play video about it, for which I'm extremely thankful. This is the first let's play of the game (at least the first one I know of), so I watched it with great excitement and it seemed they had fun while playing + I had fun while watching it, so I'm super happy about it!!!
Here it is for you to enjoy:

Hooray for James and his friends!

Operation KREEP 1.2 update plan

I really wanted to put some minor extras into the game for a long time now, but due to the prolonged development of the Steam release I didn't want to work on it (took too long and got pretty tired of it the last time). I decided to give it another try, but only make an extremely small patch. The design doc is ready and it is indeed humble. It will only take a few days of work (a week at maximum) with marketing and release, so no overtime, no delays, only a tiny update under a week during this month. Due to its scale constraint it will be more of a marketing experiment than a huge update like the 1.1 version, but a few new cool stuff will find its way into the game. Will see how it turns out.

That's all folks this time.
Take care!

Hi everyone, long time no see!

It's been a while since my last post (more than two months), and back than I sort of hinted that in a week or two I'll be ready to present the next game I'm working on :D...

Here is what happened:

I've been working on the prototype of this project of mine, coding the core features zealously, filling my design doc with cool ideas, but the mechanics simply did not add up. The concept on paper sounded really cool and straightforward, but the actual fine-detail design and implementation was nightmarish. I hit a lot of roadblocks during the formalization of the rules and I had to redesign some mechanics and re-implement parts of the prototype a couple of times :(.

Takeaway:
What sounds as a nice and simple concept on paper may bite you in the a$$ during realization...
"The devil is in the details!"

Okay, so the prototype is ready now (playable and feels good) and I'm ready to present it. I took some pictures and some game-play footage, but keep in mind, that the game is filled with placeholder art and is heavily work-in-progress currently!

Unified Theory

A real-time strategy puzzle game which plays with the idea that the workings of the whole universe could actually be described by one formula, one grand rule.

A little about how it works and how it looks currently:





The core concept is simple. Take a real-time strategy game like Starcraft, but remove all the units except for the worker one. Unified Theory will contain only one "unit", but will feature all the common tasks of arcade RTS games like: mining, building, research, upgrades, tech-trees and battles. Another BIG gotcha, is that you have no direct control over your units, but they march blindly towards the direction they started out when they were created! You will only be able to place buildings on the levels to interact with your units, and to actually solve logistic and management problems (and later to battle enemies) by controlling your "army" indirectly. Due to these rules, the game is probably more closer in controls and feel to a Tower-defense game or a management game focusing on base building, than to an arcade RTS.

To better showcase how this works in action I've captured a little footage of me playing with the current prototype build:


And why is this a puzzle game? Well, in its current state it is not, but the "campaign" levels of the game will focus more on solving puzzles related to level traversal, logistics and management of your base with serious constrains (resources and/or technology), so the final version will feature equal parts strategy and puzzle solving.

What is this "one formula" technobabble story?! Well, the core of the game is a really really really simple discrete math construct (cellular automaton), but it can actually be used for really complex stuff (like programming/calculating anything :)). I'm being constantly amazed by these seemingly simple but infinitely deep systems and the intricate connections of math and nature. This fueled me to choose this theme as the "story", to tell about the beauty of this phenomenon instead of having a classical plot where faction A fights faction B for glory and whatnot...
I still have to work out the detailed structure and presentation of this "narrative". Will see how this goes, fingers crossed :).

The plan, whats next:

In the upcoming week or two I will work on the look and feel of the game and make it more appealing and accessible. When this is done and the game more closely resembles my final vision, I will release an open alpha version. The goal with this build is to gather feedback on the core mechanic and the accessibility of the game. Plus I'm hoping it will start building some "traction" for the siege of the gates of castle Steam, the holy battle to acquire the legendary green-light :). Most probably I will keep it updated and re-release it with the final version as a demo.

This alpha build is the next big step, but afterwards I will focus on building an engaging campaign full of puzzles and strategic levels.

Stay tuned!

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!!! :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 :|), 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 :|).
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.

Hi all!

It is time for some software testing framework talk again :)!

As you know, I'm a big quality/testing advocate (especially when it comes to software!!!), and I've been working for a while now, in my "lab", on a high-level testing and automation framework, since I've reached the limits of usefulness of unit testing my game projects.

I'm going to showcase the newest addition to this testing framework, so if you completely missed it and interested, here are the two older posts summarizing the design and some implementation details (with showcase videos ;)) about it:
Testing - part 1.
Testing - part 2.
A quick recap, if you would not like to read through the usual pile of text :), but still interested in this dev. log. entry:
It is a "capture and replay" based framework, where you can record (or edit/create) input events (or special ones, e.g.: network, debug events etc...) from the game to replay them later. For checking certain functionality, the replay files can be filled with assertions targeting the properties of any game-object within the game world at any given frame of the replay.

So the system served me well while developing the Operation KREEP update. It took less than two work days to reach a pretty high coverage of game-play features and the UI work-flow (around 80% code coverage in 12 hours). This test-suite helped me a lot while releasing the Steam version, besides keeping my sanity by covering and assuring, that most of the high level features work, it saved me from introducing a few pesky bugs while coding the new features!

After a while though, execution times grow as it is to be expected. The 67 replays for the final Steam build(s) which checked the UI work-flow, completed the tutorial, played till getting most of the achievements and so on and so on, requires around 11 minutes to fully execute (more than a cup of hot beverage takes from inception to getting it into the belly :D). I knew, that after a while this is going to happen, worked before with similar frameworks, but also already had some ideas in the back of my mind to fight it if it may become a problem. Obviously this was not a big irritation yet, but for a larger game it may become a certain source of frustration.



The most simple and obvious solution was categorizing test-cases within a suite (UI, Options, Graphics, Tutorial etc...) and only execute immediately required categories. This took only a short time to develop and configure as NUnit already had support for it. I just had to put some extra properties here and there.
This was nice and worked well, taking less to test the crucial/modified parts faster, but of-course there was a much smarter idea there from where this one came from (a full test still required 10+ minutes :), no way I could not improve on that ;))!

<ReplayTestSuite>
    <!-- Test-suite options -->
    <ReplayTestCases>
        <!-- ... -->
        <ReplayTestCase>
            <TestName>Match Pause Restart</TestName>
            <ReplayPath>Tests\ReplayMatchPauseRestart.xml</ReplayPath>
            <Categories>
                <!-- Each string represents a category the test-case is part of -->
                <string>Match</string>
                <string>Pause</string>
            </Categories>
        </ReplayTestCase>
        <!-- ... -->
    </ReplayTestCases>
</ReplayTestSuite>

So I investigated two common solutions to this problem (actually there is a third one which is manual: modify test-cases to make them simpler and shorter, but that is not a general solution, takes time and the gains are small), and I went with the "speeding up test-case execution" route. I haven't find any good/common name for it, although it is a known solution, so I called it the "unlocked" game-loop. The concept is simple: when replaying the test-cases a different game-loop is used, which runs as fast as it can (no vsync no sleep nothing like that, exercising the CPU/GPU like a mad man :D), but the elapsed, total and accumulated time calculated and passed to the systems and game-objects of the game is mimicking the normal game-loop, so the game "believes" it is running at normal speed with the target 30 or 60 frames per second. I was certain that it is going to speed up execution, and at least cutting execution time in half with a simple game. I was wrong, it became much much faster :D. After the new game-loop, the full test set took not much more than 2 minutes instead of 11...

Take a look:

Note: the first two minutes show the normal execution of 6 test-cases and the rest of the video show the same tests executed with the "unlocked" game-loop.

The approach has some down-sides (as with every route in software development), e.g.: the game may use system time for certain features (although I think this should be avoided, since the game-loop provides an elapsed total time of the game execution handled the same way as the elapsed/accumulated time) and another one is full-screen/windowed mode toggling which is not supported by this feature at all (maybe in the future, I guess it could be done, just it would require some hacks, don't know yet). For these problems I "cleverly" introduced a per-test-case setting to override the game-loop-unlocked configuration, so the execution speed-up can be disabled for "unstable" test-cases.

<ReplayTestSuite>
    <!-- Test-suite options -->
    <UnlockGameLoop>true</UnlockGameLoop>
    <ReplayTestCases>
        <!-- ... -->
        <ReplayTestCase>
            <TestName>Toggle Fullscreen</TestName>
            <ReplayPath>Tests\ReplayToggleFullscreen.xml</ReplayPath>
            <!-- Test-case options override the suite options -->
            <UnlockGameLoop>false</UnlockGameLoop>
        </ReplayTestCase>
        <!-- ... -->
    </ReplayTestCases>
</ReplayTestSuite>

Another "I'm not so happy about it" thing is, that it is a bit hackish and fully platform dependent solution currently, but I guess in time I will solve this problem :).

As I mentioned there was another route I could take to speed up test execution. I think it is a somewhat superior solution, but would have taken much more effort both software and hardware wise, so I decided to go with the simple one. NUnit has an open parallel execution engine add-on, and I think it requires no explanation why that route is superior, since the limiting factor would only be the number of machines I could harness, but setup (and stability?!) would be a much more complex issue. In time I may try it out, since I'm interested in the actual setup time it takes + I'm certain with a couple of boxes execution time would match the time it takes to run a unit test set :), but the current solution fully satisfies my needs and my work-flow.

The testing framework is in an extremely stable and usable state for production by now. I'm going to make good use of it for my current game too. In time I'm planning to add more features to it, so a "testing - part 4" entry may happen :), but not anytime soon + most probably I will only focus on smaller, usability enhancements and additions.

I'm still working on some framework-y code from time-to-time (maybe next entry will be similar, mostly technical) and the current game project is not yet ready for announcement, but with this game I'm going to do a more open development. So starting from the working prototype till the finished product, I'm going to post (weekly maybe?) releases with limited content to get feedback and improve on usability, balance and overall features from the first days and to reach more players interested in the game, even before going to greenlight/itch.io/hopefully-Steam etc...
Expect a somewhat playable version soon (I think within weeks).

Take care!

Hi everyone!

Haven’t been around the INTERNETZ lately, sorry for that (been busy with a lot of work and important decisions to make :|).
I promised a postmortem kind-a thingy after the Steam release of Operation KREEP, so here it goes!

Before I jump into numbers, I’m going to describe the project a little, what went well, what didn’t, the usual mortem content…
The Steam update and the release itself for the game was designed, developed and tracked as a project separate from the original game. This was done mainly due to being greenlit only a few months after the release. I already started working on new projects back than and the good news kind-of shocked me. Wasn’t expecting it and I didn’t want to rush it to the market, so I decided to take my time with the Steam release and prepare a "free" update for the game (note: I always referred to this as a free update, since all the original buyers received it on various stores for free…). While working on this update and the Steam release preparation, feature KREEP (pun intended :D) and a smallish burnout (combined with a semi-serious health-issue) almost took the head of this project :(. It took a little longer than six months, but I finished the update and released my first Steam game on the 10th of June, 2016 :) !!!

The good:

I released a game on Steam! That alone is a great reward and a memorable experience!!!
Also while preparing for it, I could revisit a game I made and finished/released already and I could give a little more love and polish to it. In one way, that was really cool. I guess many probably had some bad feelings about finishing a project and still wanting to add some more to it here and there.
+ Steam integration was nice and surprisingly- easy/well documented :).

The bad:

Making the update was a CHORE. The actual procedure got pretty boring fast. I had an existing game of which I made the most out of I could on the first try, and now it did not feel special. I felt, that most of the modifications only added more to the game but did not make it any better (except for the input handling enhancements :), working on that feature was pretty cool!).

And the ugly:

I made the same preparations as with my previous two projects, written down and estimated tasks, and planned important milestones. I also tracked my progress while working on the update the same way, but this time, disciplined and organized work did not save me. I felt a rather big urge to make a better game out of Operation KREEP, because "it is going to be on Steam" :|, so a small feature-creep clouded my sight. Also I had semi-serious health problems with my stomach and duodenal, so I spent the last six months in glum mode :(.

Some numbers to certify these results/problems:
The original game took 430 hours to make, spanning over 6 months, where my original estimations and milestones predicted 300 work hours and somewhere between 4 to 5 months. Not the best probably, but certainly not bad results.
This update also took 6 months, but only required a tiny little less than 190 work hours. This mostly shows my rather bad work ethic regarding this project (and the bad mood :( ), since the estimation was even closer to the end result, than with the original game. I estimated around 150 work hours and around 3 months top to execute it! Based on my results with Operation KREEP, the update with the Steam release could have been done in three months with same amount of weekly work-time spent on the project, but I guess sometimes life just happens :(.

So, mortems have to have some conclusions, on how to do better next time, right?
I think, next time if I feel, that some tasks and features do not really add much to the game overall + I feel like I’m loosing interest in the project, I will re-evaluate my designs and plans, or I will start a tiny pet project parallel, so that I do not fully waste a lot of my gamedev time and efforts. Also I’m certain I will take the mentioned stuff into account regarding milestones.

Did it sell?!

I guess this interests many, so here goes nothing: it did not sell…
Before going any further, I have to mention, that for saying "it did not sell", I’m taking into account, that it is a small and niche game + my marketing efforts took much less time and/or money, than half of the project costs, as it is the case with AAA titles :D. I wasn’t expecting it to sell thousands of units at all in the first place :). Nevertheless, even with this in mind, selling only a few units leaves a rather bad taste in my mouth :(.
The Steam release did not reach 100 units. Based on the wish-list additions, it may reach 500, probably if I drop the price later on, and that number sounds better, but I feel like the price was totally reasonable even for the original release. I guess it is common sense, but this is another example, that a game alone is not going to reach many people, not even on Steam. Real effort has to be poured into pr and marketing to actually get the word out and to find people interested in your game. I guess a more interesting game wouldn’t hurt either, but what can I say, I’m a sucker for retro and pixels :).

Still, I’m thankful for those sites and press people who tried the game, and even more thankful for those who wrote about it. Indie Retro News wrote a really cool review :), especially thankful for that!
+
For my next game, I’m going to work a lot more on the marketing front too, to reach a broader audience, who may enjoy it.

Future plans:

Recently I worked on many cool gamedev stuff and I’m prototyping my next game (not ready to show it yet, but it’s getting there).
+
I made a huge life-changing decision lately, which I’m going to keep as a "secret", no official statement, because I suspect, I would get a lot of "Are you out of your mind?!" responses, and I don’t know how to handle that properly, but I guess it is not hard to figure it out. Here’s a hint:
Still here, writing about game development, the one and only job that keeps popping up in my life no matter where I go and what I do. A profession which I could spend a lifetime practicing, a profession which is intertwined with the person I am.

I tried many times to make a weekly habit out of writing these gamedev related post, but I failed miserably :(.
Now I’m going to have a lot of time to try it again, so expect my next post soon :);)!
Best regards.

Hello there!

Small update but big announcement this time :)!
Operation KREEP is one years old and it is available on Steam!

Here it is, its Steam store page in its full glory:
Store.steampowered.com

Technically speaking, it is a tad bit older than one year. I wrote the first draft of the design doc in 2015. May 22. and the repository + the project files were created in 2015. June 2., but it is pretty close. So it took a year of part-time work (occasionally off and no more than two days any given week) to get it from the concept in my head to the Steam store. So the release today was an appropriate birthday gift :D.

Thanks for all who helped me getting here. From all the praising words to the helpful comments.
Thank you!

Currently I still have a lot to take care of regarding the release but I did not forget about the punctual postmortem this project and I desperately need to write. Next time…

Best regards.