KREEP, apples and penguins.

Hi everyone!

Haven’t written for months now about Operation KREEP. It is time to revisit this old buddy bud bud of mine!

Yes, as the title suggest, it is cross-platform time πŸ˜‰ …


Not official, but soon…

Nope, sadly no official release yet 😦 , but the Linux build is ready and tested (at least on my Nix machines) and the MAC build is ready for testing too. This means, that in a week or two an official release can happen, although a little piece of the puzzle is missing.

I require additional pylons!

I have two PCs, so I tested the Linux version of the game on two Ubuntu versions, but more would be nice (zillion distros 😦 ) + I HAVE NO MAC MACHINE 😦 …

This means, that the MAC build essentially never ever been started! I would really love to release the cross-platform builds, players already asked for them, but without sufficient testing it is not going to happen. Buying a MAC would be a somewhat logical investment at this point, but Operation KREEP (and my whole game development venture for that matter) is on an extremely tight budget as it is not profitable so far, so I will try to postpone that a little.

Feedback, results, “compensation”

Based on the differences between the builds (almost 0 code change, only packaging varies), I think a few simple checks would suffice. Whether installation works (files copied, icons set etc…), whether the game starts and basic configuration settings checks (settings work and are saved to correct application data folders) + a short test play round just for fun πŸ˜‰ .

I know it is shady to ask for free QA for a product, but this is the reality of the situation I’m in 😐 . If you would like to help out I thought about sharing a limited amount of Steam/ keys for the full game as a “payment”.

I put together a short form to ease reporting results: KREEP, apples and penguins

If you dislike sharing any personal information, but still would like to help out, please simply post results as comments here or contact me by e-mail:

I guess contact info of a cheap&used MAC reseller in Hungary could help too if you know any πŸ™‚ .

Demo builds

2017_03_24_logo_mac 2017_03_24_logo_nix

Porting tech stuff

Just a little tech talk as closing words. The windows version of the game was made in C# using XNA. Two really cool projects were born to both preserve and enhance XNA in the last few years. MonoGame and FNA. Both are great and well established/tested at this point, but I choose FNA for porting Operation KREEP to Linux and MAC. My reasoning was the following:

  • Around a year or two ago when I was using MonoGame to work on my Linux machines I encountered some difficulties. MonoGame on Nix platform was using OpenTK for window, input and OpenGL context management and as I know, that library had it’s fair share of bugs and there was no real support/contribution/fixes for it for a long while.

    Remark: as I know the MonoGame team changed to SDL2 lately, the same library FNA uses under the hood so it is probably not the case by now. 

  • MonoGame favors a per-platform build approach, which looking at all the possible target platforms (desktop, mobile, consoles) is a logical choice, but requires managing and building multiple executables for each target. FNA from the get go approached this with a common desktop runtime, so one build works on all major desktop platforms (only packaging has to be taken care of per target).
    Remark: if I’m not mistaken, last year a “common desktop” build was introduced for MonoGame too, so technically it could work the same way as FNA for desktop.

  • The FNA developer Ethan Lee had laser focus on cross-platform desktop XNA development and delivery, and the wiki for FNA had a really nice documentation about both working with FNA (differences and extras compared to XNA) and packaging + delivering games using it for Windows, MAC OS X and Linux. This documentation seemed really helpful and complete.

All in all I suspect both libraries could work perfectly for publishing your games to the three major desktop platforms, but I wanted to give FNA a try too. I was pleasantly surprised, most things worked like a snap without much fiddling.

That is it for today, in a few days I’ll post a new video & blog entry for I am overburdened. If you decide to help MUCH LOVE, SUCH WOW πŸ™‚ and thanks awfully!

Take care!

Magic Item Tech, persistent.

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 πŸ˜€ ).

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 πŸ˜€ . 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. This 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 πŸ˜› ). 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 πŸ˜€ 😦 , 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 πŸ˜€ ). 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 πŸ˜› . 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.


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 πŸ˜› , 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!

KREEP, missed tap.

Hello everyone!

In my last post about Operation KREEP, I mentioned that for the 1.2 update of the game I made some improvements to the input handling logic and hinted a near future deep-dive into this topic. Quite a while ago, right before releasing the Steam version, I wrote a similar post describing the input handling enhancements I made back than. Although it is a bit lengthy, if you are interested in the technical details of high level input handling logic I highly recommend it. Not a requirement though, since I’m continuing this post with its summary to level up your knowledge for easier digesting of the upcoming technical details.

Short recap

The game plays on a grid and all entities move complete tiles (no standing in between two tiles). Each “move” action by a player will actually take multiple frames to complete (precisely 12 which is 200 milliseconds under 60 fps). The players usually do not feel this (it does not feel laggy/bugging), since it is a quite fast and action packed game + 200 ms is not much and the overall rules/design of the game is deeply intertwined with grid based movement.

The initial movement handling logic was utterly simplistic. If a direction button is pressed the player moves towards that direction, with a silly hard coded priority for handling cases when multiple direction buttons are down: “Up” beats “Down” beats “Left” beats “Right”. When a player is already moving and the corresponding direction button is held down it will be handled with highest priority, so continuing movement forward is considered “important/intentional”.

Warning, warning incoming pseudo code:

void handleIdle() {
    if input.isPressed("up") {
    } else if input.isPressed("down") {
    } else if input.isPressed("left") {
    } else if input.isPressed("right") {

First pass of input handling in “Idle” character state.

void handleMoving() {
    if (input.isPressed(currentDirection)) {
    } else if (input.nonePressed) {
    } else {
        // this will handle direction change
        // the same way as in "Idle" state

First pass of input handling in “Moving” character state.

That is it. This simple control mechanism was really easy to code certainly but it wasn’t intuitive nor responsive, and clearly intentional actions were missed out from time to time. It took me some time to realize that it was bugging many players and it could be improved a lot.

Around the 1.1 (Steam) release, I made significant changes to this system, by introducing some smart checks to figure out the intentions of a player as best as possible. These rules included:

  • Checking the surroundings of the player character.
  • Taking non-walkable target tiles into consideration (making them a less preferred choice).
  • Taking dynamic blockers like other players, props or the KREEP, into consideration (just as important targets as walkable tiles).
  • Saving the elapsed time since the last press of each direction button to use it for prioritization (presses closer to the direction change in time considered more important/intentional).

These modification made a huge difference back than. At least the “testing committee” (a.k.a. friends) had an immediate positive reaction, although I still had some ideas for improvement I was thrilled by the results. For more details about these enhancements, please check the old post. I’m jumping onto new stuff now!

The missed tap

One thing that was still bugging me related to these movement controls and the overall responsiveness of the game is the “missed tap”. Due to one move action taking 12 frames, the direction change evaluation logic runs “rarely” and it is easy to miss it by a frame or two. An occasional maneuver is trying to change “lanes”, by moving one tile perpendicular to our current direction, but continuing in the original direction right afterwards.

Operation KREEP lane change maneuver GIF

Some players (including me), try to achieve “lane changing” by holding down the main direction button and tapping the perpendicular direction button. The perpendicular direction gets bigger priority, due to the press occurring closer to direction evaluation in time, so it would be selected as the new direction for the player.

Operation KREEP lane change maneuver input handling GIF

But being a short tap the button state may be released one or two frames early and usually the following happens:

Operation KREEP missed lane change maneuver input handling GIF

Based on my guesswork, trying to achieve “lane changing” with a tap fails 3 out of 4 times (may be even worse). This is not hard to detect and sort-of can be made sure to be not mixed up with different intentions, so here comes my solution.

Implementation details

Instead of saving only one elapsed time since the press of a direction button, two timers are saved for the last two states (regardless whether it is pressed or released currently). This way we can buffer the most recent changes and the preceding actions of the players related to movement (buffering input events and their timings).

struct BufferedInput
    bool pressed;
    float currentElapsed;
    float previousElapsed;

    void update(bool state, float dt)
        if (pressed == state)
            currentElapsed += dt;
            previousElapsed = currentElapsed;
            currentElapsed = dt;
            pressed = state; // pressed changed, timers swapped, current restarted...

That is the most crucial part of the solution. From now on we can detect the “missed taps” when evaluating the player movement, since we have all the required data. I think each game needs a little fine-tuning / trial and error regarding this part as timings and speed wildly varies between them, but my logic and my numbers may be useful:

const float FrameTime = 1f / 60f; // frame time in case of 60 fps
const float MovementTime = 12 * FrameTime;

bool detectBufferedTap(BufferedInput input)
    if (!input.pressed)
        var tapTime = input.currentElapsed + input.previousElapsed;
        if (tapTime <= (MovementTime - 2 * FrameTime))
            if (input.currentElapsed &amp;lt;= input.previousElapsed)
                return true
    return false;

This means that the game considers a situation a missed tap, when a direction button is released during evaluation, a press occurred at least 2 frames after leaving the last tile (last direction evaluation) and the button was in a pressed state for at least as much time as it was released during these x <= 10 frames.

Input buffering technique frame-by-frame depiction

Taking these “missed taps” into account with just as much priority as a pressed input button, while the player is moving and a direction evaluation occurs, reverses the 3 out of 4 failures, so approximately 3 out of 4 times (maybe even better) a short tap is enough for a tile lane change. Tried tweaking this logic and the numbers, but could not really improve the consistency further. I’m happy with these results though. And again, after this update, controlling the game felt much better than before!

Probably there won’t be updates for (nor posts about) Operation KREEP for a long while, since despite my efforts the game could only reach a miniscule audience + I’m getting fully occupied by my upcoming game Unified Theory, but who knows what the future holds…

Take care!

KREEP, tales of low productivity.

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:
Operation KREEP box art

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).
Operation KREEP Steam Trading Cards

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 πŸ˜€ , 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!

KREEP, designing an update.

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.
Montage of all the maps in Operation KREEP 1.2
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):
Showcase of the map-fix of the
6 previous maps were modified with various fixes while making the 1.2 update.


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!


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.

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 πŸ˜€ . Enjoy:

Br. and take care!

KREEP, post Steam.

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 πŸ˜€ ) 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.

KREEP, birthday.

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:

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 πŸ˜€ .

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.