I am overburdened, back among the living

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 😀 . 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 😮 .



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

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 😀 . 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 🙂 😉 !

Stay tuned.

I am overburdened, monsters and mods.

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?! 😮 🙂 😛 , 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 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!

Magic Item Tech, honesty and shame…

Haven’t written in a while about what is up with Operation KREEP or my next game, not even game-tech related posts, and I think it needs a little explanation ( at least me, myself, are in desperate need of some honesty towards myself 😦 ).
After I finish my rambling about “life and stuff”, there will be some tech talk too in the topic because I dislike not showing anything fancy, so if you are only interested in that part, scroll down a couple paragraphs 😉 .

So why isn’t the next game announced, I’ve already mentioned it twice before, that it is close to being playable, and in the upcoming weeks I may even distribute an open alpha build…
It is still not ready for that (no kidding 😐 ?!).
The last month was somewhat “wasted” from a gamedev perspective. Wasted is a harsh word for it, but the truth is I feel a bit ashamed of how the last few weeks played out (development wise), so it kind-of fits. Instead of mostly spending my time with the development of the new game, I’ve mostly spent my time with “engine-tech”. The worst part is, that it got a tiny bit out of control, since if I’m going to be really honest with myself, at least a week worth of development was 100% unnecessary for this upcoming game.

A little back-story:

As many of you may already know, I’m developing my games using C# and the framework of my choice is XNA/MonoGame. This goes way back in time (almost 10 years): Unity did not exist and XNA was a hot new tech (in BETA or 1.0 which was extremely bare-bones can’t remember) when I started learning programing ( University + the ultimate purpose of being able to make GAMES!!! 😀 ). Back than it was a natural choice and worked wondrously. Fast forward to today and MonoGame is still a great choice, if you have professional programing experience (or want to learn programing) and you are ready for some game-system/engine development compared to Unity, but for a more complex game, lots of stuff has to be coded (no physics, no advanced rendering system, no UI system etc…).
I actually like this level, I feel comfy working this way + I’ve been building and growing my own “framework” (or whatever it should be called) on top of XNA/MonoGame for years now. I have a keen eye for software quality and I’m especially proud of it’s feature level and stability, and I’m really productive when using it to develop a game.
I think, that last one (productivity) is the most important part when it comes to “choice” regarding your language/framework/engine/tech!
But, and here comes the BIG BUT:
It is still only a light-weight game development framework. Not, that there is a problem with that 🙂 , but if I would take the time to get proficient in Unity, most probably I could be just as much, or even more productive, especially looking at the current situation when I go in to game-tech feature creep craze 😦 .

Nowadays, I’m trying to make more out of working on games (living / business), so this becomes an increasingly important question, whether my time is spent well working on this framework. The answer is probably no, but my current level of productivity and emotional attachment ( I don’t know what else to call years of hobby development 😐 ), keeps me working on it. Of course I have more rational reasons than that, but the post would be humongous and it is already big 😀 . From now on, I have to be brutally honest with myself when it comes to this question and be more self-aware when it comes to tech development decisions.

A little more detail about the current project/situation:

I wanted to upgrade my testing framework for this upcoming project which went surprisingly well and happened pretty fast, but this game I started working on required numerous other features which were lacking from the framework too. I decided, that I’m going to spend approximately two weeks on development of these features in isolation, not really jumping into coding the game beforehand (just only the basics), so I can focus on delivering clean and stable code for starting production.
This became four weeks, due to various “common” reasons: underestimation (only a little), forgotten pretty important framework related developments ( these were not even estimated in my backlog 😦 ) and a week amount of feature creep.
The only conclusion here is the same I mentioned before, I need to re-think how much energy I pour into this code-base, and whether it is going to be “worth it”.
Now, that I have everything in place (and got out of this spiraling feature-creep menace), the development of the game is advancing, but it is still far from a presentable state 😦 .

Here comes the technical part, what I’ve been working (wasting my time) on:

The major part of the tech development was a proper UI/Widgets system. For Operation KREEP I used a simple approach, where each UI element was a simple graphic object positioned relative to it’s parent UI element. Nothing fancy just a simple base class with a position and an attachable graphic (e.g.: sprite, text etc…) arranged in a tree-like hierarchy, lean and clean.
No built-in serialization logic, no scaling, no anchoring, no alignments, no padding or margins, even mouse input handling and a good event system was missing! For the most part it was OK for KREEP (not much UI and pretty simple), but it was certainly an insufficient solution, and a lot of stuff had to be done in the project code-base and hard-coded while working with it. Yep, pretty ugly 😦 .

The current strategy game I’m working on is much more UI heavy and will have a pretty different look (not pixel graphics + different resolutions), so the before mentioned “problems” had to be resolved. I heavily extended the old system, and implemented a two-pass layout engine (measure the elements of the hierarchy first, than arrange them based on their requested size), with some fancy additions (e.g.: nine-patch sprites).

This is how it looks now:

And, than it hit me, I forgot about auto-tiling 😦 …

Yep, I pretty much forgot to estimate and put this feature into my backlog when designing the game. And no, it is not some fancy tooling stuff, which I don’t really require, but plays a kind-of an important role in the game. It plays a big role in the looks of it, which IS important, so I had to implement a run-time auto-tiling feature. This is how it looks in action:

It only handles one type of surrounding tiles (supporting multiple ones is ridiculously difficult + the game did not need it) and supports both four-way and eight-way rule sets.

And, while working on auto-tiling I made a performance bug…

It was a mistake I did not discover while testing my code. The internal data-structures were handled incorrectly, and with an imperfect stop condition, from time-to-time the auto-tiling took more milliseconds than a frame should at 60 fps, so I sat down to hunt for the reason of these frame-spikes. Needless to say, that I already had a vague idea how to approach the problem and where to look + an existing .NET profiler would have revealed the exact issue in mere minutes (if not seconds), but somehow I felt this is the sign of the “NEED” for a visual profiler ( I don’t know what pills I took that morning 😐 ).
I was already way out of my frame-work development time budget but still the creep emerged from the dark depths of the unknown and engulfed me. I took the time (few days) to develop my own visual profiler integrated into the framework…

This is how I imagine that mental state from now on. I can’t exactly remember or picture it, so this will do 🙂 .

After this point, I’m still not over the feature creep, but starting to grasp reality!
Took a couple more days to wake up from the refactoring madness too…

That is enough from the wall of shame of Spidi. Next week will finally be about my upcoming game.
Best regards.

Magic Item Tech, testing – part 3.

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 😉 ) 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 😀 ). I knew, that after a while this is going to happen, worked before with similar frameworks, but also already had some ideas in the back of my mind to fight it if it may become a problem. Obviously this was not a big irritation yet, but for a larger game it may become a certain source of frustration.


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

            Match Pause Restart

2016_07_17_Categories_1  2016_07_17_Categories_2

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

Take a look:

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

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

            Toggle Fullscreen

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!

Magic Item Tech, achievement unlocked.

Hello there!

It looks like I fail to stick to my plans regarding this development blog, and sadly overall to becoming a bit more organized 😦 . Instead of listing the well known and common indie dev. distractions which bog me down too I jump onto this months “achievement”: the achievement system 😛 .

When I designed the Steam update for KREEP and selected the features that will make the cut ( self imposed time constraints, that I already ran out of 😦 ) Steam achievements were no. 1 on my priority list. So I knew, achievements have to happen, but when I sat down to design the software changes required, I came to the conclusion, that simply implementing the whole thing in the game project would be messy and foolish, and the bulk of the achievement system could be implemented as a “low level” service in my framework code!

I wrote down the following points, as the design guidelines and requirements for this lower level service:

  • An achievement is not much more than a boolean flag (state) whether it’s unlocked or not, and some accompanying rules about unlocking circumstances and presentation (description).
  • The game logic itself already implements fine details regarding when and how something relevant to achievements occur and it only needs to signal these events to the system (this is the only thing that has to be added to an otherwise complete game code for fully working achievements).
  • The game code shouldn’t need to know or care about whether the achievement state is read from a file or downloaded from a network back-end, or gathered using the SteamAPI. This logic is especially irrelevant for the part of the code where certain events unlock achievements, but at the meantime the service should support multiple persistency modes, since not everyone is a Steam user and achievements would be a nice addition to non-Steam buyers too!

This is what I came up with and implemented:

A little more description:

  • The API user interacts with the AchivementSystem class almost exclusively.
  • For unlocking achievements “events” (string or integer IDs) have to be fired/signaled to the system, e.g.: “XYZKilled”, “Level1Complete”, “BossDead” etc…
  • For finer control of some achievements, time-frames (again string or integer IDs) can be started and stopped on demand, e.g.: “First10SecondsOfRound”, “JustRespawned” etc…
  • The AchievementDescription instances are shipped as a game asset, the AchievementState instances are gathered using the persistency manager, and they are matched with their correct description using a string ID (external reference). The API user can not directly influence or change the state of these objects. It must be done ( for the sake of clean code and my sanity 😛 ) through the AchivementSystem using “events”.
  • Achievements can have a counter (optional), for “collection” based achievements, e.g.: “Kill 1000 zombies”, “Respawn a 100 times in one match”
    These counters can be accumulative (“Achieve 100 kills”) or they can be connected to time-frames and reset immediately upon a stopped time-frame (“Achieve 100 kills within the first 10 minutes of a match”).
  • State persistency management is automatic and almost entirely hidden from the game logic, only configuration and implementation selection required: instantiating the wanted AchievementPersistencyManager implementation e.g: File, Network, SteamAPI. Persistency handling is “session” based, so unlocked/progressed/reset achievements can be collected and flushed together (but it is optional), which is usually useful for both file and network based serialization.

A small video footage of a sample built using the system:

Here is an achievement description from the sample in XML format:

    <Name>Back out seconds</Name>
    <Description>Hold down backspace for 10 seconds!</Description>
        <Format>{1,2}/{0} ({2})</Format>

It describes the “Backspace” achievement, keeping state using a counter (10 seconds), progressing for every “HoldBackspace” event fired (this is fired in the sample every second if the backspace key is down), and resetting if the “BackspaceDown” time-frame is stopped (this is started when backspace key is pressed, and stopped when it is released).

There are other useful features in the system, which I didn’t mention yet, and a lot of planned ideas to extend it (like multiple named counters for achievements) but I often end up with a huge writing so I’m calling it a day at this point 🙂 .

Hopefully the next writing will be about concrete new features in KREEP and maybe about a release date on Steam 😉 .
Stay tuned!

Magic Item Tech, testing – part 2.

Hi everyone!

It’s been a while since my last post. Lately I had to focus on a lot of things (KREEP, Steam, paperwork, framework development, day-job, health issues, new cat 🙂 !!!), and I wound up not being able to actually focus on any of it…
Now I’m trying to catch my breath, doing the best I can to organize my time better, and I’m going to restore the habit of telling the story of my progress in game-development land (getting back to posting every week or two). Starting it, by delivering a long ago promised follow-up for the game software testing topic 😉 !

In the last post I summarized the design goals of the (halfway-)developed framework. The main purpose was to create an automatic testing system which provides a trivial way to create and extend high level (integration/functional) test cases for my game projects. Since then, I finalized most of the features and inner workings, and made a regression set for KREEP with a pretty decent code and functionality coverage.

The testing system and work-flow is based on “capture and replay”. This means, that for creating a test case you actually play the game, trying out various facets of the program, and the engine captures events (e.g.: input events, key and game-pad presses, etc…) while doing so. These events are than saved to a file, and the engine itself can run in “replay” mode, to replay these events later on. This alone would not allow things to be validated in an automatic fashion, but a special event type serves the role of replay based checks. These “Check” events implement the same interface as other common events, so replaying them can be done right before a given “Update” call, and they define specific assertions for game objects in the running game. Since components have a string identifier tag, a check can search for given entities (like the player, or a map element, or any enemy monster etc…), and with a little reflection magic, assert on any of the properties of these components. Filling the replay files with these checks to be done before given “Update” calls creates the actual validating automatic test cases.

Here is the class diagram (simplified) showing the architecture. It’s clearly visible, that the record & replay systems and their building blocks are mirrored (as their functionality/goal) and it is easy to extend both systems with introducing new leaf implementations (recorders and events):

I’m already experimenting with other “Check” event types. Screen-shot compare check compares the state of the back buffer to a given reference image. This approach has both great advantages (e.g.: sanity checks for rendering/graphics code + validates huge amount of the functionality leading to a given state of the game) and disadvantages too, since it is quite unstable (changing a sprite or a model a little can cause the comparison to fail, but smart comparison algorithms, like histogram or color-channel-distance based comparisons can help) + they are not really helpful until the game is (or at least larger parts of it are) in a quasi finished state. This is why I haven’t based the validation aspect around this approach, and why it is still not a fully flashed out part of the test framework. Game-object hash value checks will be a somewhat similar beast. They are just like the standard property checks, but instead of asserting on scalar values/properties, the hash-code of a game-object (Object.GetHashCode) is recorded and checked when replaying. This is also quite fragile, because adding a new component or a new property to a game-object could break a test, so it is a type of check which is more useful when larger parts of the code approaches the finished status, but it can validate a huge part of the game state too! At least it is not hard to update broken but not actually failing tests with new hash values and screen-shots…

For achieving deterministic playback (at least supporting it in the lower level systems), the events are captured and replayed on a specific “step” of the game-loop instead of using timestamps, so a space-bar press polled on the 15th call of the “Update” function is played back right before the 15th “Update” call. For this to work as intended a “fixed delta time” game-loop is ~required, but it is not a hard-coded limitation, since both the record and replay systems support extensions (as seen on the UML diagram), and optionally a delta time can be saved for each step and replayed again as the delta time since the last “Update” call (viola, deterministic replay for “variable delta time” game-loops). Another aid to reliably test stochastic parts of the code, is seed events, usable to capture the seed of a random number generator and reset a given generator to the recorded seed when replaying right before the set game-loop step. Later on if a game or some parts of a game become non-deterministic, I hope, that due to the events are actually being a higher level abstraction, not tied at all specifically to input devices and input events, could be used for replaying non-deterministic game sessions with special game events instead of capturing input (e.g.: disabling a non-deterministic physics system upon replay and relying on “PhysicsDiagnosticEvent” instances).

As I mentioned, the events are serialized to a file for later replay. I chose XML (but could be anything similar) since I already have a lot of code, helpers and tools built for working with this format + I find it quite comfortable (+ a natural choice for .NET). Here is a simple replay file containing only a few key press events:


To be able to better organize test cases (extract common parts), and to aid the creation of test cases by hand instead of capturing game-play footage (really useful for UI/menu tests), I’ve implemented an “include” attribute for the “EventStrip” type, so that the contents of a replay can be defined in multiple files. Event strips are actually specific event implementations containing a list of “relative” events which can be replayed/started at a given frame relative to the starting frame of the strip itself. This way multiple events can be replayed “parallel”, and it is easy to capture multiple separate event footage and play them combined simultaneously:


To be as compact as possible, both memory, disk-space and mental-health wise :D, the basic building block, the “DiagnosticEvent” class is not defined and implemented as a “once-only” event like in most event architectures. It has a duration, and any concrete event implementing it’s interface can decide to span over and be played for multiple “Update” calls. The most common example is a key-press. There are multiple ways to capture and replay a user pressing a key, than later on releasing it. Most common approaches are with their cons. against them:

  1. Save keys in pressed state every single frame as a distinct event. This takes an awful lot of memory and disk-space, and it is close to impossible to edit by hand…
  2. Save two events for each press, an event for pressing and an event for releasing. This is a much much better approach than the first one, but I still hated it’s concept, since any time you wold like to edit an actual key-press, for example make it happen a couple of frames earlier you have to modify two events, and you have to make sure they align well, the frame numbers are correct, the release event is not missing etc… since you may accidentally end up with a replay which presses a key and never releases as a bad example.

The third approach, which I used, and I think is the most feasible solution, is one event which can define how many frames it spans over. As an example a player presses fire (e.g.: left mouse button) and holds it down for 30 frames. That is one event that should be replayed for 30 frames from it’s defined relative starting frame. This way it is easy to make a press take longer or shorter. Also to move around a button press within a test-case, e.g.: to make it happen earlier or later on, only one number has to be modified 😉 !


Here is the last XML example, a simple check used in the test suite for KREEP, requiring, that the first player (Red) is alive. The game-object for this player is tagged “Player One”, the players are contained within a game-object composition tagged “Players”, and the root component of the game is the “ScreenManager” which doesn’t need more explanation 🙂 .


If this check is included for a given frame, and while replaying, on that frame the value of the “IsAlive” boolean property of the game-object is false, or the game-object is not found an exception is generated. That is how I validate things, and hopefully discover early if I mess stuff up with my modifications.

The last big magic trick I added to this whole mix is a test-case runner system. I’m a big “fan” of one-click stuff ( who isn’t 😛 😉 ? ). I’ve looked around how to do this, and since I’ve been using NUnit for a while now, it was my first trial/choice. Thankfully NUnit has both a command line and a gui based test-execution application, proper result reporting, and a built-in way to programmatically generate test cases runtime! So I’ve built a simple ~application thingy which generates test cases for the NUnit harness from replay files and some meta data ( again in an XML file 😀 ). When these tests are executed by NUnit, the glue app simply launches a pre-defined application linking my engine, e.g.: KREEP, starting it in “replay” mode and feeding the path of the replay XML file to be loaded and run ( achieved with huge amount of reflection magic and some extra inter-process naughtiness 😀 ). If no exception occurs during the replay, it shuts down the game, nice and clean, than advances; otherwise the un-handled exception propagates to the application domain border, and the glue app fetches it with some inter-process serialization magic (again) to make NUnit know about the failure situation and cause. All in all the glue app is pretty small, has no dependencies at all besides NUnit, it utilizes some tricks ( a.k.a hacks 😛 ), but nothing out of the ordinary (actually pretty “common” stuff for core .NET programmers), and as the last and best addition, it will work out of the box without any modifications for any game project which is built upon my framework (no special implementation/preparation is required from the game application either!).

I recorded a little footage with Bandicam to show how this looks like in action. In the first part of the video, I execute three selected test-cases, all passing. Than I edit the third case to add a deliberate failure. This modified case checks the “Energy shield” mutator. It expects, that when a match starts with this mutator set, all players have an active shield, and a laser shot hitting the second player will not score a kill, but the shield will be disabled right afterwards. This expected boolean property (ShieldActive) is changed to “true”, which is obviously wrong, as the shield do wear-off right after the shot, and the test runner signals the failed assertion:

This way, I just have to press a button, and within a couple minutes I know whether a new/modified version of KREEP is ready to be released or not.

Lessons learned, conclusions, plans for the future:
It exceeded my expectations. I know it’s my brain-child and stuff :D, so who else would be pleased if not me, but I do believe it is going to make my life much easier with game releases and patches in the future, and probably will help a lot mid production phase too. It took approximately two work days, recording and creating test-cases, to reach an 80% code coverage on the KREEP code base. This framework is a pretty decent result and I’m happy for making and having it 🙂 ! Also there are a lot of handy utility features already built-in, since I upgraded some parts while I was using it to make it more comfy, but this post is already enormous to talk about all those stuff 😀 …
A “limitation” which I’m going to fix for my next project is the time it takes to run a full test. It is not yet unbearable or anything ( it takes approximately 5 minutes for KREEP, so a coffee and/or a cup of tea 🙂 ), but for a project with a lengthy single player campaign it could take “too” long, and parallel test-case execution (which NUnit supports) would not help too much (though with save-games it could be helped). A simple antidote to this, on which I’m already working on, is a special game-loop, which “fakes” a fixed 60 times-per-second update rate, passing down 16.66 elapsed milliseconds to game-objects, but actually steps the simulation as fast as possible ( poor CPU 😀 😛 ), so to speak achieving a fast-forward speed-up mode.

This post became pretty lengthy and heavily technical, but I wanted to share my latest big achievement in detail (yes, I love tech-talk…).
Meanwhile the work on the Steam release for KREEP is ongoing. It goes much slower than I expected, so the early march release is in danger currently, but I’m doing the best I can. Not all is lost yet. The paperwork is done, I’m a Steamworks partner, it’s official :), and I’m working on integrating the SteamApi. Also working hard to add extra content for the release (achievements yeah!!!). I hope it’s going to be cool.

Next time I’ll do a more detailed status report on KREEP+Steam…
Stay tuned!

Magic Item Tech, testing – part 1.

Hello all!

Haven’t written for a long time, but I’ve been busy working on my “tech”, mostly preparing for my upcoming project. When I started to think through what I would like to write about, I’ve realized, that it is going to be a rather long one, hence the “part 1” in the title, as I’m planning to continue this topic in a week or two.

Now onto some tech talk, but before I go on, I have to tell you, that I’m a BIIIIIG software testing advocate, and this topic will mostly be about it. If you think, that thing is gibberish, do not continue 😉 !
So, I’ve been working in the last few weeks on improving my testing work-flow and the tech supporting it. As I’ve probably mentioned before, I have a small but really STABLE code-base, which I nicknamed “Magic Item” (lets call it framework from now on). I use this framework to build games. It is based on XNA, but mostly uses it for rendering, sound and input handling, and provides a bit higher level services, like a game-object framework, animated sprites, collision handling etc., that are common to all games regardless of their type.
I’ve emphasized stable for a good reason. Every single function, that gets into this framework is unit tested and documented. I’m confident, that it is close to impossible to develop software (especially big ones) in a long run without a proper automated regression and sufficient documentation. The way to achieve it, can be argued upon and is somewhat a personal preference (some like unit tests, some do not and prefer more focus on module/functional tests, some like api docs, some do not and prefer more of a feature based high-level documentation not tied to the code), but I hope many agrees, that it is a must (yes I’m being naive, I know).

I love the look of green test results in the morning :D.

This means I’m pretty thorough :P.

I’ve tried to create a lot of games before, from which many failed due to being too ambitious ideas or me not being persistent enough, but usually I could at least salvage some code from these projects, and build it into this little framework of mine. I’ve been developing the framework this way for years now, and every time I stumbled upon a feature, which could be useful for many games, I properly integrated it, by designing, implementing, testing and documenting the code. It is a small library, since this has always been more of a hobby endeavor, but due to it’s level of polish, working on it or with it to create a game cheers me up!

KREEP Banner

Then came Operation KREEP. This was my second completed game project, but I’ve realized something really important during the development. I had to write a lot of code, specific only to this game, and I think this is pretty shameful, but I had no proper regression to back it up. In the last weeks of development I’ve been doing hours of manual testing just to make sure I did not break anything accidentally. I considered this a failure from a developer perspective, since I perfectly knew what I was doing and still did not prepare, wasting a lot of time. Though I also thought, that unit testing only just a small part of the high-level code in KREEP was not such a bad idea, since it is not the type of testing method which is able to cover a lot of functionality with a small time investment. So in the meantime, I’ve realized, that I have to find a cheap/smart way of testing the actual games I make, in an automatic fashion.

I’ve decided, that unit testing works perfectly for the framework code, but I have to reach a much higher test level for the game projects. My other requirements were, that it has to be stable (as deterministic as possible), simple to automatize, and really easy to create or extend test cases which are able to cover a lot of ground. Yep no worries, this is a trivial task 😀 !
I’ve been working on this testing method in the last three to four weeks, and I believe I’ve arrived at a really good compromise. I’m not going to go into too much detail in this post (I want to leave some stuff to talk about for next time 🙂 ), but here goes the overall design:
The testing system and work-flow is based on “capture and replay”. The framework provides an extensible system to capture events while you are playing and a mirror construct for replaying them (e.g.: like input device events, key presses, mouse moves etc…, but the client can define event types and capture+replay mechanisms). Other than replaying input events, replay files themselves can be extended to be filled with various checks to be done at a certain time or frame, and with some reflection magic, even tiny details can be checked in the game-world. This way, you can capture game-play footage as you are playing with the game, it can be replayed any time later, and it is easy to create test cases and to build a regression out of your recordings by adding various asserts and checks at certain points in them. I did my homework, I know all the positives and short-comings of “capture and replay” based testing. I worked my ass off to come up with a good solution for most of the problems, or at least to make the system work for me, instead of against me.

Most of the implementation is done. I’ve already hooked it up into NUnit, so replay based test cases can be executed with the NUnit runner (I use NUnit for unit testing too, so it was a natural choice), and the whole concept seem to work surprisingly well! I’m really proud of the result :). Testing the final build of my next game will be a breeze :).

In my next post (probably sometime around next week) I’m going to talk about details of my implementation and how I’ve approached the design of the system to achieve my requirements.
Until then, I wish you and your family a merry Christmas, and if I happen to be too busy (or lazy 😀 ) during the holiday and postpone the next post, a happy new year too!