• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

Entries in this blog


Hi there!

Where was I for a month again and what’s up with the title?! Many friends already asked this and other difficult questions like “I planned to finish this game in 4 months and I’ve been working on it for 6 now” or “Last month you kind-of promised to have an open beta and a complete game by now” and the title was the best answer I gave. Actually I really believe in what I’m doing and the way I’m doing it. I know it is madness, game development is about risk management and this project is becoming more and more risky day by day (risk of losing a lot of money and losing the ability to continue full-time game making :( ).

The thing is the game was NOT GOOD two months ago. I could have rushed it to market, I really could, but my ghost whispered to me and I had to follow its lead. I’m in this for the love of it and for the love of the craft as a whole. I want to make games and continue making games as a living, but at the same time I want to be good at it and be proud of what I make.

Now with this out of the way let’s jump onto the progress in the last four weeks :) !


Few people said to me, based on my last entry, that the game starts to look really polished. I felt really happy about that, because I haven’t actually started on my planned polishing tasks. Besides composing the sound track and working on finalizing and balancing game systems, the last few weeks were spent on polishing the look and feel of the game :) .


First I added some sprite effects to the player movement which fades out over time. This is a great visual cue to show the direction and the old positions of the player and also makes the “dusty & old” dungeon image more believable :) .


Then a subtle bounce was put on top of the original player movement transition. It does not seem like a big addition but it does make it feel more like walking than the old moon-walker dance move :D .


The last movement tweak was configurable sprite and sound effects for levels. Now there is splashing in the caverns instead of dust puffs as an example.


Animated health-bar

This is something which is absolutely not a necessity for a game, but once you saw the Diablo 3 health globe it cannot be unseen :D . Back to reality. I wanted to add a subtle sliding animation to better signal the player about the significance of the health change. I think it turned out wondrous :) !



One nice touch I really like is atmospheric sound effects. In many games if you mute the music you can easily hear a lot of background effects which do not come from entities in the world but from the environment itself. Examples include crackling fire, rats squeaking, stuff like that. I Am Overburdened is not a gothic themed nor a horror game, far from it actually, but I wanted to achieve a “spooky” overall feeling so I added something similar. Dripping water in the caves, rattling chains in the dungeons etc…



Monster skills

This was a feature which was missing from the game for so long. I actually implemented the underlying system while working on the prototype (so really really long ago), but I had no time to actually add unique skills to the monsters :( . Now each and every one has it’s own “thing” which makes them memorable and really stand out. Not just attribute differentiation, like :o careful this one is “strong”, this one is “fast”, bla bla, but instead something like this: careful this can dodge your attacks, or that one can interrupt you and cancel your hit, or that pesky beast can resurrect so it is a real damage sponge!


There are some neat ones which I will not spoil because they are really fun, powerful and buy the game once it’s out :P (there is no fun in spoiling everything) !

The Black Raven Market

During a play-testing round I realized there is a huge problem with the pacing of the game. The game-play did not change enough during a full play-through regardless of the changing environments, monsters and increasing power levels. Another problem a lengthy game usually had is RNG (those infuriating random numbers :D ). It felt a little boring and a bit too random (not enough control over the outcome). I realized a shop could solve these issues, but not a typical buy whatever you want when ever you want type, but more like a rogue-like shop ;) , that allows more player control but it also presents another hard choice (as many things in rogue-likes).


Welcome to the Black Raven Market. Every first shop level sells random pickups (health potions, attributes etc…) and every second shop level sells random magic items, but you can only buy one stuff on each level! I’m evil, I know it :D MUWHAHA. In a full play-through you will encounter 10 shop levels which gives some extra space for player choice and nicely breaks up the “kill some monsters defending important loot and run to the next level” game-play loop.

Music makes the world go around!

I’m not a musician and the following sneak-peek into the official soundtrack of the game is proof of that. Regardless of it being pretty amateurish I’m still really proud of it :) . Instead of trying to make AWESOME music (which I simply can’t :( ) I focused on adhering to some fundamentals I settled on before jumping onto composing:

  • Retro sound, match the looks of the game.
  • Leave a spooky and mysterious impression.
  • Be consistent using similar patterns and tunes.
  • Gradually get more intense and chaotic.

I hope it isn’t grating at least :| .

The full OST is around 15 minutes so its my longest work in this regard yet + it is long and varies enough to not get too repetitive during a full play-through :) .

I should also mention, that I used the wonderful Bosca Ceoil tool for composing. It’s quite limited, but it is really really easy to use. You should definitely check it out if you would like to make some chip tunes. It is free and works in the browser too!


Thanks for reading!
Stay tuned.


Hello everyone!

I've been pretty silent for a while again...
I really dislike this, because I'm usually open and post a lot about my progress, but sometimes it just slows down and I end up in a spiral of "awkwardness", when I'm not progressing too much and I really don't want to talk about that :mellow: .

Oh well, I'm preparing for the beta, some tiny fine-tuning left before I'm ready to upload a build, but before that, I share this update with a teaser.

Menus, menus everywhere!

I completed most of the menus. Some minor stuff (few more characters) are still missing but I will finish those during June. I included myself as the inn keeper :) . Interacting with the guy brings up the help screen and he also tells the "story" of the game in the teaser.


Your journal

I went for a journal look for the classic focus driven menus and your inventory. I think it turned out good looking and it fits the game well.




For item pickup notifications I made a fancy scroll too.


Animated box-art

While preparing the trailer and other marketing materials, I had this urge to animate something related to the game :) . The in-game sprites are all static and I wanted to keep it this way, so I made an animated box-art. Some say it's a better attention grabber on storefront pages :wink: .


Dungeon templates

I made a bunch of new dungeon templates for the generator. Not enough for the final build, but there are already plenty and they provide good variety for a full beta play-through.


Progress, balance

First balancing pass over the item, monster and pickup power levels is also done. Nothing major, but you can complete the full 30 level deep dungeon now, encountering a new set of monsters and a new tile-set after every 3 or 4 levels and generally fighting stronger enemies as you progress. It is going to take days of tweaking to make it engaging though. I'm planning to devote a full entry to this topic soon.

Teaser trailer teaser

Yes, the following is just a teaser for the teaser trailer :D , a sneak-peek so to say. I'm working on a lengthier one which showcases gameplay features too with music, flashy texts and everything one would expect from a proper game trailer. So this is just the first 20 seconds of the real teaser, but I thought I should share it in this form and ask for some feedback/opinions about it...

Thanks for reading!
Take care.


Hi there, long time no see!

Last month was rather chaotic for me. After a lengthy Easter vacation a nasty flu forced me to spend almost a week in bed, and overall the progress on "I am overburdened" was dreadfully slow up until last week. That is why I had no energy and not much drive to write new posts or to create video log entries, but it is time to break the silence.

Really, no progress?

There was a lot actually, but the development entered its last stage where there are a zillion small tasks left to be done but no modifications are substantial. The notorious last 10% which takes 90% of the development time :D . I go through all the changes made during last month in a few sentences, than I'll adumbrate when and how am I planning to push this game through its finish line.


I completed all the monsters from the easiest pawns up until the final boss. Their attributes are not balanced yet, but all their names, sprites and basic settings are done. Now each and every one has its own corpse graphic and unique sound effect too. This last bit was originally flagged as a nice-to-have addition, but after trying out the game with a few monsters having its own sound and carcass, there was no turning back :) .



Attack and skill effects

The battles and item skills were lacking visually, so I decided to apply some cosmetics. I Implemented a simple system to flash in and out various sprites at given coordinates in the dungeon on top of the entities. I was pleasantly surprised with the effectiveness of the initial results. Since than, I added configurable opacity easing- in and out and timings. Now item usage and battles are really shiny :o .



Another set of crucial visual queues missing from the game were notifications. Many pickups and events yield varying results in a roguelike and yes a player can figure out how much gold was picked up, but it is so much nicer if the game helps a little with these, especially when important changes occur. Clearly when it does not fit the style its not necessary, but I am overburdened is not a "super serious" game. Of course these can be overdone, but I tried making them not too obtrusive. Both the effect system and the notification system is accessible by the item skills, so various "spells" can trigger these too.



Items, items, items

103 unique items, each and every one having a unique sprite. All the graphics are done with around 50% of the item lore finalized and it was a hell of a lot of work. Sadly something I underestimated again. Making the graphics was not difficult but coming up with unique, interesting or funny concepts, skills and short descriptions after having around 75 piece already, was tough. The last mile became a grueling, laborious crawl! When a lot of great content is already in place and almost every single archetype is taken, it becomes ridiculously hard to come up with new ideas hitting the same quality bar :( .

After all I think I achieved my goal in creating intriguing hand crafted loot what may serve as a strong hook for the game, so I'm proud of the end result. I don't want to spoil too much so I'll only show a small selection of sprites. Sorry, you have to play the game for more :) .



In Operation KREEP I hard-coded some strings, rendering the game impossible to be fully localized without code modification. Some buyers actually asked about how they could do translations. I felt really ashamed while answering those mails :( . For I am overburdened I've built a system which allows to bind assets for specific cultures and all the strings are read from asset files too. There are no major limiting factors now, so technically the game could be localized to any language without modifying the application. I know some languages are super hard to handle, e.g.: right-to-left ones or the ones with huge glyph sets, but the point is, that it is feasible now.

Since I don't have the budget to pay for professional translations, only English and Hungarian will be done for release, but if the game does well, this is something, that is high on my list :wink: .

In-game UI

The user interface for the game is pretty much complete. Some finishing touches are missing here and there, but it is already pleasant looking and almost fully functional from the health-bar all the way to the item pickup pop-ups.




The main menu

I dislike making menus because they are usually boring to design and program. For Operation KREEP I came up with the idea of creating a "screen in the screen" look, to make it more interesting and alleviate this feeling while working on it. You navigated the menus of a retro-looking computer and the whole frame of the machine was drawn. It blitted the maps on the level selection screen in awful 4 colors and all the cozy stuff like that :) . It worked for me and for the game too.

I tried a non-traditional approach again, but menus are still boring :D . Since it is a classic trope to have a city in action RPG-s and roguelikes where you return to from time-to-time, I thought about including one in I am overburdened. The idea did not align well with its mechanics, so I decided to make it the main menu! You move around in an inn, interacting with people and objects there to enter specific parts of the game. Talking with the inn-keeper lands you on a help screen, poking a bookshelf shows the settings, leaving the inn exits the game and the trap-door starts the actual dungeon crawling... If a player gets lost, escape will bring-up an ordinary focus driven menu. It is far from complete, but the skeleton is there and some parts already work.



Open beta, plans

I've been talking about this open version thingy for ages and I still haven't released it. In my original plans I wanted to have the full game completed by now :( . For the most part it is, but some planned content and finalization (+polish) is missing. There comes a time when I have to say stop and I think it is here, so from now on I will only focus on wrapping the whole thing up and this starts with putting out a beta version. Will prepare some marketing materials beforehand, like store page graphics and texts, maybe even a teaser trailer, so it may take a few days, but will share a download link for it in the next post :) :wink: !

Stay tuned.


Hello everyone!

Tiny post with lot of pics this time. Last week I worked on the original sprites of the game and progressed steadily. Far from finished with every piece but a huge portion is done!

Missing pieces

In the last log I showcased the tile graphics, but one final adjustment was missing back then. All the tile-sets shared a single stair sprite which wasn't fitting well, so I made a separate sprite for each one.


Entity sprites

The next stop was entities. I started out with defining clear goals for the looks and creating a palette serving these goals. The idea was to select contrasting, vivid colors to make entities pop from the environment and on contrary to the looks of the dungeons make them lively (browns and yellows are still pretty strong still :D )!

Not yet finalized!


I really liked the design I came up with before for the player character so I reused my concept which was a failed attempt at the box art of the game. Two sprite states exists, since in the planned "story" scenes the player will have his sword in its scabbard.



The first apparent visual choice here are the light borders. I decided to add a colored one to every interactive entity type, so the player can not miss which tiles poses a threat and which ones provide bonuses. I made four chests with various costs/functions but I'm keeping the last one as a secret for the final version :wink: .



Pickups come in many flavors. Permanent attribute bonuses (Meat = +Strength, Frying pan = +Armor, Carrot = +Vitality, Coffee = +Speed, Clover = +Luck), gold, potions, random items etc... Here are a few:




I settled on a style after a few tries where the monsters are pictured from the same angle as the player. I plan to have around 15-20 unique monsters and a boss, which will provide a good variety for the 30 dungeon levels. They were divided into four groups based on the story when designing the looks: were/giant animals, goblinoids, undead and the allies of the boss. Almost all of them is ready (currently at 16).



Some screenshots from the current version of the game:




This week will be spent on completing the missing sprites (e.g.: items, some monsters) and overall visual improvements and polish, so I'm guessing the next entry will be similar. A kind-of "news" is my plans for an alpha demo. Before I complete and release the game I really want to do a open build (which will become the demo later) to gather feedback. I think wrapping this version up sometime next week is perfectly viable, so by the end of this week I'll post a finished plan for this too.

Thanks for reading.
Take care.


Hi there!

Short entry, a bit tutorial-ish, about the tile graphics of the game.

Art direction, ideas

I really liked the style of the open art assets I used for prototyping. Pixel art, huge value differences between the wall and the floor tiles and a little noise to make it a little grimy & wrecked.


Though I liked it's looks and simplicity, I wanted to try some other ideas before settling on anything so I went ahead and made mockups.

False positive

The most interesting and furthest developed one was a tile-set and look with an oblique top-down view effect. I think this looks really good in many games, but sometimes it can get too exaggerated covering too much of the entity sprites.


I came up with this, but I decided to scrap the idea. I liked it sort-of, but making multiple varied sets for the 30 to 60 minute long campaign and fully fleshing them out in this style would require and immense amount of work. I choose the original simple style with a decent amount of variation instead.

Goals, final looks

So I returned to the looks of the prototype. Easily distinguishable wall and floor tiles, noisy and grimy places (it is an old dungeon after all) and good variations (many sets and small randomization within each set too) so it does not become boring during a full play-through. I needed a cool palette. Something murky. While picking colors I naturally deviated towards the looks of a game I always cherished for its atmosphere :) .


Colors were picked carefully for supporting the look of the entity sprites, as they will use a marginally different palette full of contrasting colors instead of saturated ones to make them pop from the terrain (again just like in the prototype).

Here goes some shots about the results:




I have 10 different tile sets ready which I suspect will provide a good variety :) . With 30-ish level deep dungeons a set change will happen after every 3 levels.


For creating a lot of pixel art tiles, like the ones I made, you are going to need a frame so to say. Some rules and patterns how you start pixeling each tile and afterwards patience for experimentation. That is all to it actually. I walk through the creation of one.

I use GIMP, a free and cross-platform image editor, but pixel art can be done just as well in a lot of paint programs (even in paint, but I advise you to choose a better one which supports layers). A graphics tool which can work with tiles or a hot-reload engine feature (because GIMP as an example does not support tile graphics) also helps, since you can check while you are drawing, whether your graphics work well when tiled instantly.


First I usually start with selecting values for the whole set. This is a handy technique for defining an overall lightness/darkness balance for each tile.

Than I "sketch" a simple pattern for a tile using the values, usually with a light-source residing in a North-West direction.

I add a little variation, like cracks, missing bricks, mixing up the pattern etc... Detail like wines or stains can be added after coloring is done but this step alone makes enough differences between tiles.

I know simply selecting the same hue for the given values feels easy, but it makes the outcome look kind-of boring. Try to make colors interesting by selecting at least two different hues and by playing with saturation a little. It will make a huge difference!

Now you have a nice looking tile. The next step is optional. Adding noise was a deliberate style choice in my case. You simply add an extra set of values with only slight changes relative to the originally used ones. Select the noise colors the same way as the "normal" colors. Generate a noise pattern and overlay the noise colors on top of the tile using it as a mask.

A screenshot with the final tiles:

Thanks for reading.
Stay tuned!


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


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

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/itch.io/IndieGameStand 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: [email="spidi@magicitemtech.com?subject=KREEP,%20apples%20and%20penguins"]spidi@magicitemtech.com[/email]

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.png 2017_03_24_logo_nix.png

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!


Hello there!

Took most of last week off for vacation == no entries, sorry about that, but this week I'm going to make multiple videos and blog posts :) ! This first one is about the box-art of the game.

Backstory, requirements

For previous projects I did not spend too much energy on the promotional art. That was obviously a mistake, because usually it is the first thing both the players and the press comes across when checking your game, so it needs to have a good teaser, but it is easy to forget the importance of it and miss allocating time for it...

I planned to make a difference this time, but I significantly underestimated the needed efforts :( . I wanted to capture the plot of the game in an image, suggesting the core mechanic, which is trying to collect a lot of loot and having a huge inventory, but still not being enough. All in all I think I succeeded but it took two tries :) .

First try

My first idea was to focus on the protagonist of the game, who is a tomb raider kind-a guy (the not so morally OK one). Not being a typical hero or warrior, I wanted to present him as a bit of a simpleton and not someone who would kill a bunch of monsters with a single slash, since you won't be able to do that in the game either.

Concepting and direction

I started out with some concept sketches in my notebook, portraying a bandit/pirate figure carrying huge bags...

I continued with flashing out this character with a composition I thought I like:


I wanted to create a pixel art end result, because I dislike box-arts with totally disconnected style from the game (except if it is top-notch quality + it adds to the lore of the game) but from my experiences with Operation KREEP, I knew I'm going to need a s#!tload of image sizes for promotional art (especially true if you plan to sell the game on multiple storefronts). Steam alone requests 5+ marginally different aspect ratios. So I decided to go with vector art as a base, and fix various sized renders instead of manually doing 3 to 4 different setups pixel by pixel.

Inking, results and confession

I use Inkscape for vector art. It is a free and cross-platform vector graphics editor, and has a convenient user interface . Perfect for line-art, icons etc...


First batch of line-art and shading work was pretty promising, I grown to quite like the character...

I tried out rendering the character in various sizes and fixing them up in GIMP using color reduction and manual pixel pushing. I still had "hope" at this point :D .

Then I throw together a "placeholder" pixel art title text.

The only thing left, was composition, fine-tuning and polish, so putting together an actual art piece which I could use as the promotional material for the game. Here are my attempts:


Of course I made close to a dozen of these, to try out various text sizes, backgrounds etc...

I don't know if anyone likes them, but I sure felt like they simply aren't working. I liked the character, I liked the colors, but the image was lacking detail, a good looking title-text, a correct composition and most importantly somehow it was lacking life :| . After days of fiddling on-and-off with it I decided, that no amount of polish is going the fix these problems, so I scraped it and started over!

Second try

I wanted to approach the next trial smarter. So instead of jumping in I looked at a lot of reference pictures and lay down much clearer goals and concepts before jumping into producing the picture.

Reference material

Looking at some images made for other games helped a lot! It made me realize, that I have to focus a lot more on the text first and foremost, and a more clever use of both color and space is required for the image as a whole.


I came up with the following concept afterwards which I really liked:

I followed a similar approach for scalability, using Inkscape to create the outline and work from the renders, manually pixeling the final image:

Final, final, final, final!

Funny thing about the final image is, that it took much less time and effort than my first attempt and I think it turned out to be a good deal better looking :) .


The takeaway is if you feel even a tiny bit stuck, sit back to the drawing board and spend some more time on your concepts, it will probably yield better results !

The upcoming entries will be about the linux and mac ports of my previous game Operation KREEP and the tile graphics of I am overburdened. Here is a little sneak-peek of the last one:

Stay tuned!


Hi everyone!

This post is going to be more like a tutorial, than a journal entry. I highly recommend checking out the video version, as it is heavily audio oriented + it contains some recent game-play footage :wink: .

I missed out creating an entry last week. I juggled between projects and tasks a lot, which led to me feeling a bit weary + no significant progress was visible on any front due to working just a tiny little on many aspects, so I decided to postpone it a little. Nevertheless, I've spent the last few days on finalizing the audio and sounding of I am overburdened.

Chip tune or not?!

My two completed games used pixel graphics and as a natural fit they were armed with 8-bit style sound effects. This is a really economical approach since making matching effects with a tool like sfxr takes only a few hours tops. From the get-go I wanted to try something different for I am overburdened, both for personal development and because some pixel games with realistic sounds (Canabalt) made me want to experiment with this style. I'm even less qualified as a sound engineer than as an artist :D so take my words with a grain of salt! All my mumblings here are based solely on tutorials scattered around the INTERNETZ + some fiddling with tools...


I decided to record and process as many effects of the game as I can. Last week almost a day was spent clowning with common household items to create noises :) . If you are thinking about a similar approach, start by throwing together a DIY "recording studio" (sponge box). Even if you have a decent microphone it will help immensely with canceling noise and reverberation. Some sponge (check the boxes of your PC parts :wink: ) or a curtain can do the job. Otherwise you may end up with really echoing results (noise can be helped with software!).



Audacity to the rescue

First things first, download Audacity. It's GIMP for sounds so to speak. Its interface is relatively straight forward (all what you would expect: select, copy, cut, paste, new track, the 'z' key ?! for clean cut selection etc...), but Youtube is filled with video tutorials (even with advanced tips and tricks) if you get stuck.


The following is a good repertoire to familiarize yourself with from the "Effect" menu:

  • "Noise Removal": for sampling noise profiles (noisy but otherwise silent segments of a track) and noise canceling.
  • "Change Speed/Tempo/Pitch" and "Bass and Treble": for mixing and changing effects (e.g.: making them play slower/faster or higher/lower etc...).
  • "Echo" and "Reverb": for making sounds feel more spatial, and for creating some fancy voice effects (e.g.: making yourself sound like a ghost, demon or a robot etc...).
  • "Fade-In/Out" for correctly starting and cutting off sounds, especially alongside cuts.
    My approach, which helped me out learning the ins and outs of effects, is to change back sliders to default positions (0Db, 0% +/-0) and experiment a lot, gradually trying out various modifiers, to see how something affects a sound.



    Here is a short reel of what I was able to record and mix for the game: Sound_Reel.wav

    Public domain

    For I am overburdened approximately 50% of the final audio were recorded (some stuff is just hard to record in your room :( ), the other half came from OpenGameArt.org and Freesound.org. Both of them are wonderful sites full of really good content, many even final production quality. After listening to an hour worth of sound effects I selected the best matching ones based on my list of requirements and remixed many of them using Audacity for even better results.



    One thing to be aware of before browsing around these sites is licensing. Keep in mind, just like code, various assets like pictures and sound effects can only be used under strict terms. Some only require author attribution, but some permit fully free modification or commercial use. If you don't really want to dig into the topic, simply make sure you search for and use assets under CC0. This means the asset is essentially public domain, you can do what ever you want with it, even for commercial purposes!


    Runtime tricks

    You should be applying effects runtime too, to make the sounding of your game more dynamic. I constantly need to remind myself of this practice, I tend to forget about it. Few simple examples are: dynamic pitch, panning and volume control. If a sound effect is played a lot (e.g.: footstep, attack, shoot, hit) and your API of choice allows to set the pitch value (e.g.: XNA SoundEffectInstance) throw in some minor, but random changes! This will make it feel more varying. If your API does not allow this, have no fear! Pre-generate some good sounding variations for the often played effects and randomly select between them.

    Example walking cycle in I am overburdened:

    • Without any runtime modifications: Walk_Normal.wav
    • With dynamic random pitch modifications: Walk_Random.wav
      If you are not really into the video series but want to hear the difference between the placeholder sounds and the final sounds of the game, here is a timed link: Sound effects comparison

      That is all for this post. I already cranked-out tiles and some sprites for the game, so I'm guessing the next entry will be kind of similar, but focusing on the art side.

      Take care!


Hello everyone!

This entry turned out to be lengthy and pretty technical. Sorry about that, but last week was spent only on "under the hood" stuff. I did my best to make it interesting though :wink: ! So the agenda is the item system which became really sophisticated, especially compared to the size of the game + the difficulty and pacing management.
I settled on the video format of the last entry, because EP 3 was the most pleasant recording experience and in my eyes it was the most enjoyable video so far. So from now on, I'm going for condensed and "scripted" logs focusing on the features and development of the game.

Items, loot

The plan for the game is to have a wast and diverse set of unique items (approx 100). Since no leveling will take place, the player will have to risk collecting as much loot as possible during the journey and focus on customizing the play-style by carefully picking which items to wear. So the technology behind the game has to support a great number of skills and excessive customization of the items, but also has to allow lightning fast iteration times, since I will be spending a significant amount of time during the upcoming 2 to 4 weeks with designing and balancing the possible loot.

Attribute bonuses


The easiest development was attribute bonuses on items. Adding the following piece to the descriptor of an item in the loot configuration file will provide the given bonus attributes to the player while equipped:
1 2 3 4 5
I highly recommend calculating most of the final modifiers and attributes of a character in RPGs every time one is needed. The more caching you introduce into these systems, the more groundwork you lay for pesky bugs to occur, so keep it low! Usually these calculations are pretty simple (will never be a performance hit) and the hard-coded constant formulas will be really straight-forward to follow.

public class Attributes{ public int Attack; public int Defense; public int Vitality; public int Speed; public int Luck; // events ...}public class Player{ public Attributes Attributes; // handle pick-ups and other logic related to permanent attributes...}public class Inventory{ public Attributes Attributes; // handle item pick-ups and other logic related to item attribute bonuses...}
The player data holds the permanent attributes of the character (starting attributes + permanent power-ups) and the inventory holds the sum of the attribute bonuses from the equipped items (only a tiny bit of caching) recalculated every time it is changed (e.g.: item pick-up, item swap etc...). The final value of an attribute is the sum from these two structures and the modifiers queried from the extra skills of the equipped items applied to it.

Skills, event system

For a high level of flexibility and to have a varied set of special skills I implemented an event system. I followed a similar but a bit more dynamic approach as the built-in event language feature of C#. Essentially an event is a string (the name of the occurred event) and a context holding additional data related to it and a skill is an event handler implementation.
Event systems can be implemented a number of ways each having their strengths and weaknesses, but all-in-all the following is pretty close to the my solution:
WARNING pseudo code incoming!
// Actual skills need implement this class:public abstract class Skill{ public void HandleEvent(string name, EventContext context) { if (this.EventsHandled.Contains(name)) { // Additional checks related to the context... TakeEffect(name, context); } } protected abstract void TakeEffect(string name, EventContext context); // Some helper methods... public HashSet HandledEvents; // Additional requirements for the event & context...}// Special events extend this structure to "add" extra data to the event context:public class EventContext{ // The creature whose action lead to the event: public Entity Creature;}
The execution of the "TakeEffect" method can also be chance based (luck of event firing creature is taken into account). so a skill may only take effect with a given chance (e.g.: 10% chance to "XYZ" types).
An item can have a list of skills listening for events when equipped by a creature. Some events pass in an extension of the "EventContext" class with extra information, like the damage dealt, or the target creature attacked etc...

Few of the most common events in the game:

  • NextDungeonReached: the player reached the next level.
  • Attacking: a creature starts attacking.
  • OpenChest: the player just opened a chest.
  • Pickup: the player picks up a bonus item (e.g.: health potion, gold sack etc...)
    Some of the existing skill implementations:

    • Attribute: grants a "bonus" for the upcoming trial (e.g.: +10 luck for the next luck trial).
    • Cripple: interrupts the next attack of the target.
    • Thorns: reflects a "bonus" amount of damage to the attacker.
    • Vampiric: a "bonus" amount of the damage dealt is healed to the attacker.
      "bonus" == modifier applied to an integer value. Can be an integer like +/- 5 or a percentage like +/- 5%. The integer bonuses are applied first and the percentage modifiers afterwards.
      Most of these events and skills took only a few lines of code to integrate and I have several more ready and working. Combing and configuring them to take effect on specific events with various chances is already an immensely versatile system to build items :) !


      String tags can be added to a creature when describing it in a configuration file, like: undead, deamon, boss etc... The event system allows to define tag requirements for targets before a skill can take effect. A creature meets a given a requirement if it does not have any tags from its "can not have" set of tags and has all the tags from its "must have" set of tags. It is as simple as that.



      This tiny addition allows skills which have real "character" to be made. Some cool examples would be monsters tagged as "undead" and a life-steal granting sword which does not work on them (pictured in the GIF), or a holy shield which grants enormous extra defense, but only when attacked by monsters tagged as "deamon". This also allows to disable certain skills against bosses which could make them too overpowered otherwise.
      I'm still at the beginning when it comes to designing the concrete items, but with these systems in place I hope I'll have a pleasant experience while implementing the actual artifacts. As closing words for the loot topic, here is a rather complicated item description just to show how this is all put together in configuration files:

      Forearms Vambraces Item22 1 1 InflictDamage true 20 Boneless

      Difficulty, pacing

      It's important to constantly introduce new content and to increase the difficulty curve so the player always finds a challenge while progressing deeper into the depths of the dungeon. I achieve this with a construct called "dungeon profile". For each level of the story (currently planning to have around 30) a profile will specify which tile-set to use, what kind of monsters can be spawned and what type of pick-ups, treasures and chests can be placed. Of course this data is read from asset files and it is fed into the dungeon generator after constructing the layout for a level. This gives fine control over the length, the pacing and the minute to minute difficulty changes of the whole game without modifying a single line of code.
      Yep, last week was rather busy, though I'm behind my schedules once again :( . A little more than a week ago I was confident I will have some (even if not many) art assets done for the game by now. Sadly slipped a little. This is the next step though, so the following entry will have pretty sprites and screenshots :wink: !

      Stay tuned!


Hi there!

Small update this time. Been working on wrapping up all the remaining core features, but got a bit sidetracked so I'm going to write a little about level editing too besides monsters + I'm trying out yet another video setup.

This video is the most condensed so far, focusing exclusively on last week's development and showcasing gameplay features. I thought making a third video using this form will result in a diverse and easily comparable set and will help to draw my final conclusions about the series.

So it is short (3 minutes), maximally to the point and heavily "scripted" :) :



During this week, I pretty much completed all the logic related to the monsters of the game. From their type description (sprites, attributes, inventory?! :o :) :P , database of monster types etc...), all the way to battling with them. Also filled the game with a bunch of placeholder monster sprites/types to test it out, and now it feels like a real rogue-like with character advancement, treasures and risk of death :) .

Battle system

Once you try to move to a tile occupied by a monster a "battle" starts. Both entities will take their turns to attack, the faster one (speed attribute) will start or it will be decided with luck trials if there is a match. If both contestants survive the first attack the slower/unlucky entity strikes back, and shortly after the player gets back input control.

Levels and modding

Official mod support is sadly out of the scope of this project, but I still managed to come up with a clean solution for a "half-offical" way :) . Since all the configuration files (monster/pickup/chest types, starting attributes, spawn profiles, item skills) will be shipped as plain XML files, huge part of the game can be tweaked with a plain old text editor, but for a pleasant level editing experience that will not suffice...




I decided to ship the game with built-in support for the Tiled editor. Now the game can read plain tmx files. Never made a run-time parser for it before, but I used this editor multiple times so it was a natural choice. The final package will also feature a pre-built tile set for Tiled map files (placeholder one pictured) and a written guide on specific map properties related to the game.


By the next entry I will have all the missing bits and pieces of the game-play loop implemented (difficulty management and item skills) and the game will be pretty much fully playable albeit lacking content or balance. As always, open for questions, comments and critique.

Take care!


Hello everyone!

I worked on a lot of stuff since my last post:

  • Thought a lot about the content/format of my blog and my freshly started video series, and made some decisions about their future.
  • Worked on the linux/mac port of KREEP, but still no announcements yet (but not far).
  • Lot of progress on the development of "I am overburdened", although not as much as I hoped :mellow: ...


    Both the last video and blog entry were huge in length and quite empty (video was okay? I guess as the first one). My goal with the series is to have a little introspection of the development process and to showcase the games I'm working on + to gather some interest for them. Of course with dreadfully uninteresting videos this is not going to happen :D . Cooked up these rules and goals to try to fix this:

    • Cut short the videos or fill them with more "action" (50+% game/feature showcase sounds about right).
    • From now on measure word-count and aim for 500 to 600 word long written entries.
    • Made an introduction video. This allows omitting the silly "greeting and explanation" section from the upcoming entries.
    • Embrace "freestyle" recording to act more naturally (+ to cut down the time it takes to prepare an entry).
    • Increase recording quality.

      So here it is, in it's full glory, episode two:

      As always, open for critique and comments both for the video and the blog entry. Please leave them here or below the video, so I can make better follow-ups.


      Steady, but a tad bit slow. I hoped I could complete all the core features by now, but failed to implement monsters. It is starting to become a real game though, but I'm still in the "prototyping" phase, hence the title. Here goes last weeks progress in GIFs:

      RPG layer


      The RPG design and its implementation is mostly complete. Our hero has health points (damage, healing and death when reaching 0 works), and the main attributes are done (most of it is integrated and takes effect on certain events).

      • Attack: damage output.
      • Defense: damage reduction.
      • Vitality: maximum health points.
      • Speed: who attacks first.
      • Luck: luck trial influence (item find chance, potion efficiency etc...)



        Treasures scattered around the dungeon floor are fully functional. There are various types (e.g.: gold sacks, health potions, permanent attribute bonuses, random artifacts), with varying probabilities to be spawn. The system is data driven, so without modifying the game a lot of pickups (and types) can be added to the mix easily.



        Chests, the most valuable targets, are working. Again large part of the system is data driven (sprites, cost to open, probabilities etc...) and I have some "okay" default chest settings added to the game already.

        Items and inventory


        The inventory system and the basic item logic is in place. Items don't have their bonuses and skills implemented yet, but I'm already working on it :) . The plan is to have an event system "fueling" the skills, so the bonuses can be configured in tiny "scripts" (e.g.: [+X] ["Attack"] when [attacking "undead"] or [+Z permanent] ["Health points"] when [reaching "stairs"]). It has to carry the weight of 100+ unique items, so I hope this approach will be adequate.


        As the next step, I have to complete the monster and battle logic. I put down the skeleton code for this too but it is going to take a few days to finish. Once that is done, the game will be pretty much playable, but lacking content and original assets. So the next post will focus on the monsters, finalization of the RPG layer and the item system. Maybe it will have plans for an open alpha release too :) ?!

        Stay tuned!


Hi there!

This entry is the first one for the new game I'm working on called "I am overburdened" and the first one when I publish a video log entry too! I decided to try this format due to the following reasons:

  • I'm writing pretty lengthy posts (I know I'm a blabbermouth) and at this day and age many dislike to read even if the topic is interesting. I can totally understand that, since a video log or a pod-cast can be listened to while doing something else, it is usually more content rich and it takes much less concentration/effort to mentally digest.
  • I also like to consume this type of content myself, besides following and reading blogs of many indie developers, I subscribed to (or watch occasionally) a number of developer/designer video logs.

    Content wise it essentially matches this entry, but has much more live stuff presented. I would like to continue creating these videos too (and would love to make them as frequently as the blog entries) as I had fun recording it, so I encourage you to leave a comment/critique here or under the video on youtube to help me make it even better (or fix annoying things about it) for the upcoming episodes.
    So, here goes nothing:

    The project.

    If you followed my devlog, you probably know by now, that the new game I'm working is a small project, with the goal to complete it and take it to market in a short period of time, focusing first and foremost on practicing my skills. Currently I'm at a point where the design documentation (and the feature set) is finalized and parts of the prototype is up and running. The estimation was readjusted once already (the first version of the design was too big) and I imposed a hard scope limit on myself for this project to achieve it's personal improvement related targets.

    3 months + I'm not going to work full-time on it (only approximately 32 hours per week), so in less than 400 work hours the game has to reach a ready to be packaged and published state. That is the ultimate goal this time and for this to work out well I really had to cut corners and accept a design and feature set which fits into 300 hours (say no to dream features, innovative grand ideas etc...). The rest is there for overhead, "nice-to-have" features and because humans estimate time effort rather badly.

    I have to say, designing a game with this tiny scope itself, which I still would be proud to take to market, was a challenge in an off itself and it took some time to pull off, but I feel like I succeeded. I'm confident, that I can deliver this game in time and I can make a fun experience out of it's core idea.


    Current project numbers (containing a possible Steam release work too) relative to the numbers of Operation KREEP. It shows, that the first draft turned out to be too big, so I cut features (a lot) + I gave myself a big enough buffer this time (nice-to-have) if I'm running over my estimates. I think a project with this scope should have been my next project after KREEP instead of Unified Theory.

    The idea.

    So the game is going to be a small "arcadey" rogue-like with a fun twist to the tried and true formula. The core idea driving the design were artifacts/loot and a huge and messy inventory :). Every single item in this game is going to be unique with mostly unique skills and abilities (or a unique combination of them) on contrary to the procedural item design of many action RPGs. Around a 100 items are planned currently, will see if I can create those in time. The other "weirdness" is the number of slots in your inventory, which is 20 :D :P . So from feet to head gears, everything, literally! * Mystical zombie blood tainted socks of the necromancer *. Nope this one is not actually planned, but you get the idea. Since there will be an armada of items and item abilities + a huge number of slots and thus items to wear parallel, all of the character customization will be done by gear. No leveling, no extra maximum life received after killing a bunch of monsters. You have to get more "powerful", by collecting lots of magical artifacts and selecting your preferred bonuses.

    A vertical slice of the features to convey a better idea for the final product:

    • Turn based rogue-like with perma-death.
    • Huge inventory (20 slots) with a great number of artifacts to find.
    • Carefully crafted RPG system with complex customization possibilities thanks to your inventory, but no leveling!
    • Semi-procedurally generated dungeons using hand authored layouts.
    • Run focused campaign, playable in short bursts with lots of deaths/retries :) , full of intense battles all the way.
    • A funny story, packed with a vicious evil, puns, jokes and a hero with a surprisingly large carrying capacity.
    • Hall of fame for remembering your best playthroughs.

      It is pretty early to show screenshots but I decided to share how the prototype looks at current stage. Important to note that nearly 100% of what you will see now is composed of open art assets, so the look is fully subject to change!




      So there you have it, I am overburdened. During this week I'll complete the final prototype which will have all the core features working. Afterwards I'm going to move onto mostly producing content for the game (dungeon layouts, monsters, items and abilities etc...), but probably by next week it will still look kind-of the same, as I'm planning to work on the graphics only at a later phase, when the game is already in a solid playable state.

      Important news: you can follow the daily progress of the game too on it's Trello board.

      I could go on about this game for pages (as always :D ), but this should be enough for this week.
      Take care!


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 :mellow: ). 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.


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!


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") { startMovement("up"); } else if input.isPressed("down") { startMovement("down"); } else if input.isPressed("left") { startMovement("left"); } else if input.isPressed("right") { startMovement("right"); }}
First pass of input handling in "Idle" character state.
void handleMoving() { if (input.isPressed(currentDirection)) { continueMovement(); } else if (input.nonePressed) { stopMovement(); } else { // this will handle direction change // the same way as in "Idle" state handleIdle(); }}
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.


    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.


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


    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; } else { 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 fpsconst 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 <= 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.


    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!


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


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 fiancee 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!


Magic Item Tech, news.

Hi there!

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


Now my game development blog and contact information can be reached at: https://magicitemtech.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.

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

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

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


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 video :wink:) 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 :mellow:, no way I could not improve on that :wink:)!
Match Pause Restart Tests\ReplayMatchPauseRestart.xml Match Pause

2016_07_17_categories_1.png?w=316 2016_07_17_categories_2.png?w=316

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 :lol:), 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 :cool:. After the new game-loop, the full test set took not much more than 2 minutes instead of 11...

Take a look:

[color=#808080]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.[/color]

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.
true Toggle Fullscreen Tests\ReplayToggleFullscreen.xml false

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!


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 :mellow:).
I promised a postmortem 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 [color=#999999](note: I always referred to this as a free update, since all the original buyers received it on various stores for free...)[/color]. 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" :mellow:, 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 :lol:. 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 :unsure:.
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 :rolleyes:.
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 [color=#808080]"secret"[/color], 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 :) :wink:!
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 :lol:.

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.


KREEP, 1.1.

Hi all!

Small update (~announcement) this time. Operation KREEP 1.1 is available:



Now if you buy or re-download the game on one of these store-fronts you get the latest version :wink:.

I made a little teaser too this week for the update:

Still working on releasing it on Steam but based on the tasks left, it is only a matter of days. I didn't really wanted to set a fixed date, like next Friday or something like that, but it is safe to say, that by the end of next week it will be ready.

I will write a "mini-mortem" for this 1.1 update and the Steam release once the whole thing is behind me, since a lot can be learned from these summary goodies + compared to the development of the original game I feel like my level of discipline and the overall organization of the project was a mess :unsure:, so I have to draw my conclusions and keep this lesson in my mind.

Take care!


Hi there!

I'm not going to go into a big yakking this time about the obvious again. Summarizing: still not advancing as planned and my online presence is still far from adequate, but the update I've been working on is "finished". Finished in the sense, that I've added all the features, fixes and fine-tunings I really wanted to add, but it is not yet released, so a final test and a last big "marketing" push is ahead of me...

This time I would like to talk about the last feature I've implemented, and as the title suggests, it is input handling related. I feel like it was bit of a daring act, but in the final stage of the development I've decided to rewrite most of the input handling logic of KREEP as the finishing step. Yep, it was kind of a bald move, and took some serious effort, both design and implementation wise, at least compared to other features I've been working on lately, but it made such a huge difference, that I'm really glad I made it!

A while ago I had a rather lengthy test session with some friends and colleagues. They told me they had a blast, but I could squeeze out some constructive (negative :)) criticism too. It was targeting the input handling, notedly the movement of the player characters. While I was observing my peers playing, I noticed this sentence come up a couple of times: "it's not moving in the direction I want it to move". It wasn't angry/bad, but heard it enough to start thinking about it, but when I asked around, no one could actually pinpoint the problem, or describe it in more detail, only there was "something annoying" about the feel of the player control.

Some other developer friends, actually praised the controls before, stating, that it is really tight, and feels like older Pac-Man or Bomberman games, so it took me some time to figure out the problem, but approximately two weeks ago I had an "a-ha" moment while playing and realized what was bugging my buddies. The game indeed feels like old Pac-Man or Bomberman games, but I discovered some problems with this scheme (at least with my implementation). The movement is discrete as in the mentioned games, so by pressing a direction key, your character will not stop until it reaches the next tile and the game is pretty fast. It takes 0.2 seconds, so 12 frames (with 60 fps fixed loop), for a player character to move a full-tile distance. When trying to do tight "maneuvers", so turning around a corner, or entering a door, or simply changing your direction at the right moment, you have to be spot on, otherwise you can miss the corner/door! Based on what I've found, this 0.2 seconds is already lower than the average reaction time for humans to a visual stimulus (which is 0.25 seconds by the way). This is pretty common in games, so reducing game speed was not something I planned to change though, especially because it would modify the design and game-feel a lot. I went further down the rabbit hole and found, that not only you have to be spot on in KREEP, but the logic I've implemented for deciding which direction to "prefer", when multiple keys/buttons are pressed in a given frame, does not "aid" the player. It is pretty much stupid (simplistic) and fails utterly in a sense, because in the before mentioned situations (maneuvering), you usually have two buttons pressed...

Here it is what I'm talking about, what the user intends to do is on the first GIF, and the second and third GIF shows what happens from time to time:

2016_05_09_gif_1.gif?w=630 2016_05_09_gif_2.gif?w=630 2016_05_09_gif_3.gif?w=630

In the first "failure" case, the player is holding down "Right" and "Down" together for a split second and releases "Right" too late, and in the second case "Down" is pressed too late. The latter problem is really hard to battle, but can be done to some degree (still experimenting with that, more on it a little later), but the first one is actually not "fair" (at least the players feel that way: "it's not moving in the direction I want it to move") and it can be fixed using a simple idea + a full rewrite of my previous input handling logic :lol:.

So previously I used a pretty simple input handling logic for controlling the player character movement (warning, warning incoming pseudo code):[code=nocode:0]void handleIdle() { if input.isPressed("up") { startMovement("up") } else if input.isPressed("down") { startMovement("down") } else if input.isPressed("left") { startMovement("left") } else if input.isPressed("right") { startMovement("right") }}
Input handling in "Idle" character state.[code=:0]void handleMoving() { if input.isPressed(currentDirection) { continueMovement() } else if input.nonePressed { stopMovement() } else { // this will handle direction change // the same way as in "Idle" state handleIdle() }}
Input handling in "Moving" character state.

There is a huge problem in both parts. One is that a direction "preference" is hard-coded, so "Up" beats "Down" beats "Left" beats "Right" and the other is that while "Moving" the current direction is again "preferred" over other directions, for no real obvious reasons (except for it is easy to code :P).

Both problems and the previously mentioned "multiple buttons pressed" issue can be eliminated easily by adding time-stamps to button presses! Instead of simply checking one button after the other, we always check each direction and the later a button was pressed the more "preferred" it is, due to a simple logic which is: the last button pressed by the player is most probably is the "intended" new direction. This logic off-course can be further enhanced with another trick. It is most probably isn't the "intention" of a player to face a wall when multiple direction buttons are pressed and some of them would mean simply trying to move into concrete, so besides time-stamps, possible directions are checked also.

Here it is, the further enhanced "smart" input handling algorithm (warning, warning incoming pseudo code again):[code=nocode:0]bool canMoveTodirection targettime pressedvoid handleIdle() { canMoveTo = false target = null pressed = time.min detectTarget() if canMoveTo { startMoving(target) } else if (target != null) { changeDirection(target) }}void detectTarget() { foreach direction { if input.isPressed(direction) { if canMove(direction) { // prefer movement over hitting a wall // if no walkable target is detected yet use this one! if pressed < input.pressedTime(direction) or not canMoveTo { targetDetected(direction) } canMoveTo = true } else not canMoveTo { if pressed < input.pressedTime(direction) { targetDetected(direction) } } } }}void targetDetected(t) { target = t pressed = input.pressedTime(t)}
New input handling in "Idle" character state.[code=nocode:0]bool canMoveTodirection targettime pressedvoid handleMoving() { canMoveTo = false target = null pressed = time.min detectTarget() if canMoveTo and target == currentDirection { continueMovement() } else { if canMoveTo { changeDirection(target) } else if (target != null) { changeDirection(target) stopMovement() } else { stopMovement() } }}
New input handling in "Moving" character state.

And here is the representation of the inner workings of the new algorithm in action:


The direction arrows represent the pressed direction buttons by the player and the lighter color means the most recent button press. Both possible directions hold an orange question mark until the decision about the direction is made (this is not actually checked or saved anywhere until the respective frame). The frame in which the decision happens is "frozen" for a tad bit in the GIF so the choice is clearly visible.
It worked wondrously :)!!! The movement become a bit easier using the keyboard, the multi-press problem disappeared, but the gamepad + thumbstick based control feel got a real "level up" due to this modification! It is really cool. After completing and trying it, I felt that all the updates I've added to the game (new maps, new mutators and achievements) are simple gimmicks compared to this modification. It really makes a difference and I'm really happy I made it.

After a lot of testing, I've found a situation where the new logic was kind of detrimental, and I felt like it may not actually follow the players intention. When a corridor gets blocked by a dynamic entity (a player or the KREEP), the new logic actually "tries" to move the player in a different direction, like in the following situation:

2016_05_09_gif_51.gif?w=630 2016_05_09_gif_6.gif?w=630

Here the player presses "Down" than a bit later "Left" in both cases, but in the second case another player blocks the corridor. Since "Down" is still pressed, due to the new logic, the player starts to move downwards as there is nothing in the way. I felt like in most cases this could be counter intuitive, since the player usually tries to move towards these "dynamic blockers" (due to the game rules this is the most logical goal), so I introduced some extra code, which separates dynamic and static blockers (collidable map tiles) and handles dynamically blocked tiles just as much "preferred" as walkable tiles, so that only the button-press time-stamp makes the difference in these cases. Again this worked like a charm, but all-in-all it is pretty ugly and "duct-taped" (so no pseudo code this time :rolleyes:) + the whole thing took a long time to experiment, implement and test thoroughly.

What I'm still fiddling with, but is not going to be in the upcoming Steam release, is the second issue from the original "perceived" control problems: pressing the intended direction too late. This is much trickier and it is much more a player fault than the first one, but can be helped a little with an "input window". For one or two frames, you buffer specific situations where different input state would have ended in a different direction. Than later you reposition the player, if still possible / makes sense, and it is much more likely, that the given direction is only a late press (e.g.: in the new position it would be blocked by a wall and no other directions are pressed at the current "late" frame). Most probably in these situations a one or two frame continuation in the same direction will not be noticeable by players, but will extinguish almost all late-press annoyances. Here it is, a little animation showing the inner workings of the "input window" algorithm in action:

2016_05_09_gif_7_1.gif?w=630 2016_05_09_gif_7_2.gif?w=630

In the GIF there is a one frame "window" represented. This frame in which the decision and reposition happens is "frozen" for a tad bit so the choice is clearly visible. The second GIF shows the animation sped up to the same level as the characters move in the game. Even on this GIF with rectangles and lines, the one frame "window" and repositioning is barely visible so I have high hopes, but the implementation is tricky, so it's going to take some time + I'm already in a "I really want to release this game on Steam" mood :)!

Overall working on this problem was a wonderful experience, because it taught me how much difference good input handling makes (input IS king :wink:), and that it is worth putting energy into seemingly miniscule issues/ideas too, since they may end up awarding huge benefits (+ I F'ING LOVE GAME DEVELOPMENT :D).

I'm planning to release the update in two separate turns. First giving it out to those who already bought the game on itch.io and IndieGameStand within a week or two, than releasing the game on Steam a week or two afterwards.

Sorry for the long write again, stay tuned for more :wink:!
Best regards.


Hello everyone!

Yep, I know it is not the first week of March :), but I think a little irony never hurts + it is helpful to make one remember, that "man proposes god disposes"!
The first week of March was the planned finish (maybe even release!) date for the Steam update for Operation KREEP. Albeit it was a vague plan, still, here I'm close to three weeks after and I'm not even finished with the extra content.
Planning is hard, keeping yourself to your plans is even harder :(...
Oh well, at least huge progress this week :)! Here they are, the new goody goodies I've added to Operation KREEP:
Three new mutators made it into the update and they are fun as hell :D.

Chaos KREEP in action. This is what I call "hard" mode, or "really chaotic" mode. The KREEP not only spawns it's "KREEP-lings" every second or so, but moves around the map too.

Slow missiles is really weird :D, players can race their projectiles :P.

I suspect Explosive vandalism is going to be a real game changer but only in case of short matches, or it will enforce careful play, so players don't blow the whole map up in an instance by shooting at large group of props accidentally :).

Besides implementing the new mutators, I made some subtle modifications on the user interface. Since I plan to add a few new levels next week, the number of levels are going to be close to twenty, and I realized, that navigating a rather lengthy list with only the arrow keys is going to be cumbersome...
I didn't want to overhaul the whole UI, so instead of adding mouse control or redesigning to have a grid based level selection, I've implemented page-up/down, home, and end key support. While I was at it, I added entry number indicators to make the scroll-bars more useful.

That's a wrap for this week. I think it's still too early to declare a finish date, especially based on my progress during the last two months, but I'm getting close now, so I think by the end of next month, the new content and the Steam build is going to be mature enough to release it.

As always, I'm open for critique and suggestions, and stay tuned for the next update!

Sign in to follow this  
Followers 0