David Grace

Bay Area, California

Programmer, SysAdmin, Artist

Legend of Kalevala: Post Mortem

The History of Legend Of Kalevala

The history of LoK can be traced back to a prototype design called simply, “Wolfgame.” I started work on Wolfgame in October of 2010.

Wolfgame Screenshot

The concept was to have been a software-construct wolf running around in a procedural generated digital world. My inspiration was the minimalist story-telling 2D platformers such as the Knytt Stories series. I enjoyed how the creator was able to construct an entire world that felt alien at first but became increasingly alive and familiar to the player, from a very simple semi-abstract style. It’s been compared to Another World (aka Out of this World to us Americans), which is something I enjoy. In the end, the only attention Wolfgame received from me was a tiny bit of artistic concept sketches.

I started work on the procedural world generator, but scrapped the idea as too nebulous. I wanted to tell an intricate story along with providing engaging game play, but the dynamic content mechanics for Wolfgame didn’t fit for that sort of game. I knew I would have to abandon the abstract style and flesh out the world.

In December of 2010, it was time for Ludum Dare #19. Ludum Dare is a for-fun contest by a group of professional and indie game developers where you have exactly forty-eight hours to create a game entirely from scratch. I highly recommend contests such as Ludum Dare, especially if your skill level ranges from intermediate to advanced. While you might not win or even finish a game, you will generate tons of ideas and inspiration, plus it’s a chance to hang around a lot of really cool, awesome people. Not all of my Ludum Dare games have won, but I’ve had lots of fun and feel that I walk away a stronger game developer and designer with each attempt. Every Ludum Dare has a theme, which you must adhere to with your game concept.

Themes for Ludum Dare are not picked in advance; Dozens of themes are suggested to form a pool which then is voted upon. The results are not known until the very hour that a Ludum Dare starts, to prevent advanced planning. For #19, the theme that won was Discovery. I paged through my mental file of game ideas and decided that Wolfgame matched this theme perfectly. I named my game Introspect and just barely managed to “finish” it at the forty-eight hour deadline. The game started from a sketch that I made early in the weekend that was later used as the title screen for Introspect.

The progationist

This is the first view of the strange alien beast that inhabits LoK. As you can see, the design stayed until the very release of LoK. It was strange and unusual and I can’t claim I had any particular sort of influence for it. Why did I pick an alien beast instead of re-using the concept of a wolf? The story idea I had in mind didn’t fit the concept of wild wolves roaming a forest, digital or otherwise. I wanted a mysterious protagonist that had no familiar shape or form, so that the player would literally start with a blank slate. He or she could fill the protagonist with their own motives until the real purpose was revealed as part of the story. I also wanted different endings, so that the player would have a chance to fulfill part of their own initial perceptions about the alien creature; They could make it the villain or the hero as they chose. Unfortunately, this is quite a lot to cram into a single weekend. I barely finished Introspect in time.

Early Introspect screenshot.

Introspect didn’t do so well in LD’s post-weekend voting. It placed 49th (out of 242 entries), my lowest Ludum Dare entry yet. It had an unfinished, bare world and dodgy player controls, plus poor platformer physics. But I finished it, and from the comments I received about the game, I felt that it deserved to be re-visited. The story itself intrigued me and I wanted to see what turns and twists I could take with it in the course of fleshing it out. So in January of 2011 I picked the project up again. Five months later and Legend of Kalevala was the result.

What Went Wrong

Major Features Added Post-Beta Test

LoK had a small beta test team. I felt that this would be sufficient as I had put the game through a lot of private testing with two friends. All went well and many were happy with version 1.5.0, which was the first publicly-shown version. However, during beta-test I received a lot of really good suggestions about how to improve the game. I also received a number of complaints that the game was too hard. Unfortunately, this complaint would never be completely squashed. Part of the reason for this is that often people mistake “hard” for different things. It took me a while to sort out the parts of the game which were literally too hard in a difficulty sense and the parts which were just simply annoying or blocked the player’s enjoyment of the game. While the revisions were needed, they would eventually cause problems down the road. I made a lot of changes between 1.5.0 and the first Kongregate version. These changes ultimately made for a better game, but they would eventually catch up to me. That brings me to…

Important Bugs Missed Between the Beta Test and Release Period

Version 1.6.0 was a significant re-write of LoK, in particularly the early game portion. Initially, the player started out with no weapon and an open choice for which path to take. This lead to the most complaints from the beta-testers about the game being too hard; They simply were bewildered and felt lost. So as a way to combat this, I re-organized a lot of the early game parts of LoK and made them more linear. I also added a way point system which would guide you exactly where you needed to go. Several beta testers requested a map, but I wanted to avoid such a blatant system. More on this later. This is the version that I released on

Double-level loading bug in LoK beta.

Unfortunately, something slipped through my testing. The way point system couldn’t handle deviations. Some players would end up in certain locations in the live version which had no proper path-finding solution. Combine the previous fact with half-finished debugging code which emitted exceptions whenever this occurred, and I had a number of bug reports. People were getting black screens (a sign that Flash Player has crashed) and couldn’t even resume a loaded save game. (Because their location was still causing the “exceptions on failed paths” bug.) This was bad! Couple this with other late-game changes to LoK and the initial versions of the game were rather unstable. Worse, a critical crash bug was missed by all of the beta testers. It was such a subtle bug that it didn’t appear easily but enough managed to trigger it in the live version that I received a fair amount of complaints. As a few days passed after going live and I rushed to fix these severe problems, the game earned a reputation of being buggy that it hasn’t quite managed to shake since. So take it from me: Don’t do major changes between your beta run and final release. Not unless you are willing to put the game through another rigorous beta test period. I didn’t, as I felt the project had run over its original allotted time frame. (Two months, bloating out to become five in the end.) Let me speak quickly on releasing a game: As a single indie developer, it can be hard to let go of a project when it has reached an advanced stage. There is always the temptation to change this or polish that. I wanted to get the game out to the public in order to counter-act that “just one more improvement” inertia. But had I waited another week or two, I would have caught the crash bugs and LoK’s initial reputation probably would have been much stronger.

Generalized and Complicated Engine

LoK has a very sophisticated 2D platformer engine behind it. In fact, I would say that it is too sophisticated for the scale of game that LoK eventually ended up as! The engine uses a lot of Actionscript 3.0’s more advanced abilities, primarily in the form of reflection and run time data structure modification. This allowed LoK level format to dynamically load and run parts of the engine as it needed it. But this complicated design ultimately resulted in little gains and lots of head-aches in the final phase of LoK’s preparation. In particular, obfuscation systems are unable to deal with such techniques easily. I had a lot of trouble with the final public build, such as local state for function closures being disrupted by out-of-order/function call parameter modifications. The engine was also driven by a lot of XML. While this made editing levels easy and let me spent more time tweaking levels versus writing code, it also caused problems when more complicated levels were loaded by the engine as parsing time went up linearly. Initially, all level loading was done in a single frame, but this caused music stutters for larger levels and so it was split across 10 frames while rendering was disabled. This was aggravated when the code had been run through an obfuscation pass, as certain techniques such as control flow swapping will slow down your raw AS3. I could have avoided the loading problems if I had pre-processed much of the in-level scripting and control logic, but it worked as-is and in the final analysis realized the added complexity of an intermediary format for levels wasn’t worth it. There is a great talk by the creator of Braid, Johnathan Blow, about premature optimization and over-generalized designs. The generalized level format resulted in what I consider excessive loading times (200ms or more), but nobody complained about it either during beta testing or after the game was released. I could have easily added another month to LoK’s development time in order to implement a system that would have gained little in terms of user experience.

Level Design Block Diagram.

Another factor that over-ran LoK’s development time was that only 2/3rds of what I implemented actually ended up being used in the final game. There’s a lot of extra functionality for all kinds of interwoven scripted events and triggers, some of which came in handy in the late phase, but for the most part these situations could have been handled by custom one-off AS3 code instead of a generalized framework. I tried to envision all the possible ways I would build levels for LoK, but in reality my time for doing level design was limited. Having a clear list of requirements as part of your design is important. But even more important is knowing when to cut features to meet those requirements, so as not to dilute your overall attention span.

What Went Right

Receiving Early Feedback and Tailoring the Game To Fit

I cannot stress enough how valuable it is to receive feedback on your game before it is completed. Friends and family work in a pinch, but try to get unbiased input from semi- or total strangers. LoK has been compared to Metroid. And in a way, the early version was very much like the NES Metroid There was no clear indication of where to go or what to do. It was expected that you would explore on your own and make a mental map along the way. I felt that this wasn’t a problem because LoK was divided into a small number of levels and some parts were fairly linear. You went from point A to point B and then returned back to point A when done. But during testing, one of the most frequent complaints made was a lack of map or clear indicator of where to go. So a lot of the early game was re-designed to be linear, and I added the way point system (which later evolved into the mini map). You also did not start with a weapon in the initial test version of LoK. Early game was rather more difficult as you had to avoid most enemies or trick them into self-destructing. I decided to change this so that you gained a weapon at the beginning, but it required I re-design the shooting ability to prevent early access to parts of the game world. It was split into two types; One that allowed you to shoot enemies, and another that strengthened the base shot and also allowed you to break walls. Another point where I changed LoK over the initial version was jumping physics. This wasn’t necessarily broken in the initial game, but it worked in a manner that wasn’t typical for most 2D Flash platformers. In 1.5.0, momentum was very important. Jumping from a stand-still resulted in very little arcing and mid-air control was nearly non-existent. The run ability was more useful in the 1.5.0 versions, because the faster you were moving meant you could jump farther. But testers complained about the jumping physics and in general hated the entire system (calling it unpredictable and finicky), so extensive re-tuning was done for 1.6.0. All in all, I am very glad I listened to the advice given by my testers. While LoK morphed into quite a different game from my initial concept, I think that the final product was much stronger than my initial offering.

Of Mini Maps and Radars: Philosophical Differences

I wasn’t a fan of a mini map/radar system. As I mentioned above, I felt the game was too small to warrant such extensive hand holding. I wanted to encourage exploration and sequence breaking, as the game was initially very non-linear at the beginning. In version 1.5.0, you started out with four possible paths to take but testing showed that this was far too confusing to early players. In the end I simplified the early game. In fact, the game is now entirely on rails up the point where you acquire all of your base abilities. Beyond that, however, you are left to your own devices. You are given the location on the mini map of where to go to beat the game, but you can choose to ignore it and search for all the extra secrets. The mini map is a bit odd in implementation but serviceable, as it is a hybridization between the way point system and a simple grid-based map. If I had designed LoK from the start with having a map in mind, my layout of the levels would have more closely fit such a system. (In particular, the combined upper/lower levels were hard to translate into a simple mapping system. It would have been better to split them into two completely separate levels or use a non-grid map, but that would have required more implementation time.) But judging from the feedback I have received so far, the mini map was a very welcome addition to the game. So in this case, my instinct of leaving the player to fend for his/herself was wrong.

Streamlined Build and Distribution Process, plus Debug Tools

Creating a build process with debug support for a Flash game was initially quite a challenge for me. While it is easy to push a game out for testing, doing so in a manner that lets you trace bugs or performance information in the wild can be a chore. Initially the debug tools for LoK were very cumbersome, using a text console with little feedback. Later versions added a streamlined GUI that made it much easier to run back and forth in the game world and change the state of that world. These were invaluable for tweaking the game without requiring recompilation, but they came too late to really do LoK much good during beta testing. I could see from analytic sources that some parts of LoK weren’t tested as thoroughly as they should have been, simply because the testers had no easy way to access these more difficult, hidden parts of the game. I had a unified deployment process for both debug and release builds, further enhanced by Mochi Media’s Live Updates which allowed me to push out changes to LoK in a very rapid manner.

Built-in Debug Console.

I recommend spending time on automating your build and deploy processes. I’m sure some of you are thinking “duh” for that kind of advice, but it really does make a difference when you can just push a button and not worry about fine-tuning things along the way. The initial build process for LoK was messy and quite a pain, so I didn’t send out updates as fast as I should have during beta testing. As an aside, I use Windows as my primary development environment, but for tasks like automatic building and encrypting of Flash SWFs assets or pushing them to websites, I use a host of open source tools. I have Python and Bash scripts that run under the Cygwin environment which do most of the heavy lifting.

Appealing to the Explorer While Telling a Good Story

As a way to offset the more linear nature of LoK’s early game, I decided to add more secrets for the player to ferret out. Many enjoyed this, including the factoids that I hid in the levels which revealed information about me and LoK’s development history. It is also necessary to explore every part of the game in order to unlock the second, more difficult ending. This gave players a good reason to try to poke their noses into every corner of the game world, looking either for extra secrets, more health, additional rewards, or gems required for the difficult ending. Writing the story for LoK was challenging because the game doesn’t require you pick up every bit of the story along the way, so all of the story text can be encountered in no particular order.

I managed to do this by breaking the overall arc into different segments, and assigning them to sets of levels. This is why each level has a theme that is revealed as part of exploring that level. Therefore, earlier levels only reveal incidental parts of the back story, but later levels have larger and larger chunks of exposition. Eventually, this culminates to what I called “The Big Reveal” during development, which worked quite well. My goal wasn’t to make a completely linear game which was just a lackluster vehicle for advancing the story. I wanted exploration and discovery to be an integral part of the player’s reason for piecing together the mystery presented by the game story. Better yet, I want them to have fun while they are delving into this alien world. Managing all of this was time consuming and required frequent re-writes of the story. It is doable, but you should keep good notes and be ready to re-factor.

Real-time Music System

All of the music for Legend of Kalevala was composed by the very talented Hukka. I wanted to approach Kalevala in a manner very different from most Flash games, which use ordinary MP3s to store and replay music. In LoK, nearly all music is generated in real time by utilizing a simplistic sequencing system called tracked music (aka MOD music). While this increases the processing power required by LoK, it gave the game a very unique retro aural feel. The music was composed on an Amiga tracker for an Amiga module replayer. (I use the MOD library from Christian Corti.) Originally, LoK was going to support a more advanced tracked format which allowed up to 64 sound channels and many more forms of sequencing and waveform manipulations. However, the system chosen to play the tracked modules wasn’t very sponsor friendly and required far more processing power than the simpler Amiga format. Not only was it more difficult to mix more sound channels in real time, but processing the samples required more memory and time.

Unfortunately, this decision to stick to classic Amiga mods came midway through the point where Hukka was working on the music. It required extensive retooling on his part to adapt some of the tunes he had already composed into the 4-track format. This why the main theme for LoK is stored as an MP3 asset in the game and actually takes up a lion’s share of the game’s overall SWF size: Neither Hukka or I wanted to ditch his excellent tune or convert it to the limited Amiga 4-track format. I am no musician but judging from comments Hukka made during this retooling process, he felt like his hands were tied behind his back with the decision to stick to the pure Amiga 4-track format. So I think he was exceptionally professional and did an excellent job composing music that captured the mood of the game under such strenuous limitations. With that said, I will admit I am glad that we don’t live within driving distance of each other, as I am sure he wanted to strangle me when I told him that we had to ditch some of his beautiful XM tracked tunes. :) I’ve received many compliments about the music and I think Hukka’s tunes do a great job of giving LoK a unique sound scape.

It was initially more trouble to pursue this form of tracked music versus simple MP3s stored as assets in the game, but the rewards were much greater. The music loops seamlessly and it allowed Hukka to cram nearly 15 minutes of unique music into a mere 3.6 megabyte SWF. Finally, the sound effects in LoK were composed by me using a simple software synth program. The original sound effects were created during the 48-hour Ludum Dare version and were composed with SXFR, but I created the new effects as I wanted more than simple sine or square waves. Since then, alternatives to SFXR such as bSXFR are available which have extra generators and mixers which allow for more complicated sounds.

Amusing ground-alignment bug in beta version.

Protecting Against Piracy

One last topic and the most painful so far. Thirty-six hours after release, LoK was pirated. This completely caught me off guard. LoK’s site-locking code was defeated and the game was copied across several popular Chinese gaming websites. It started to generate hundreds of thousands of plays on these sites, eventually culminating into millions of plays. The game wasn’t modified in any other way by the pirates and so the analytical parts of the game still functioned. I know exactly how much ad revenue I made on these pirated copies: Zilch. It’s unfortunate that this occurred, but it underscores the need for several things when you release a Flash game:

  • SWF obfuscation is a requirement if your Flash game that has open distribution of any kind. I originally felt that obfuscation tools were just a waste of money and a case of security theater, but they do have their place. They are no barrier against the truly determined pirate, but if I had used stricter obfuscation on the original LoK version I wouldn’t have ended up being pirated so easily. But, due to the dynamic nature of how LoK loaded its levels, a large part of the game engine could only be lightly obfuscated. I use the professional version of SecureSWF by KindiSoft.

  • Defense in depth. Never assume that one piece of obfuscated code will stop pirates. Combine this with the above point, and LoK’s defenses were defeated relatively easily.

  • Utilize a black list if possible. Andy Moore wrote a very in depth article about black lists.

  • Always have a Plan B. LoK was a Kongregate exclusive game, but MochiMedia and Kongregate have a deal where MochiAds will automatically black-list and deactivate when the game is played from If I had put MochiAds in my game from the start, it is possible I would have generated some ad revenue from the pirated copies. (It’s also possible that the Mochi specific code would have been stripped out along with the site locking, but now you’re making the pirate’s job that much more difficult.)

  • These are just delaying tactics. I expected LoK to be pirated but not quite so rapidly. Eventually your game will be pirated, and there’s not much you can do about it. But if you are releasing your game viral or in the case of LoK, as an exclusive to one or two websites, is important to maximize your revenue while the game is on everybody’s buzz list. Focusing attention on your game and its branded/exclusive websites is important during this time period. So the above methods can delay piracy until after your game has already become established.

  • Be vocal. If you’re new and relatively unknown, then you are extremely vulnerable to piracy. Nobody knows your game. They don’t know who you are, or what your website is. I am sure this is why LoK was such a juicy target; LoK was an unknown but recognized as well-crafted game that was going to be popular. Make sure you post as much information and if you catch anyone pirating your game, don’t be afraid to speak up.

Note that I mentioned Chinese piracy in particular because I want to point out that while the China is a huge market for Flash games, it is also an ocean filled with many large, hungry sharks. I would have no problem targeting this market if I could be assured of at least some return from my investment. Since LoK has risen in popularity, I have since been contacted about legitimately licensing the game for Chinese portals. But at this point the cat is out of the bag and my incentive to work with the legit offerings not all that great. I hope the Chinese Flash game portal community will continue to try to clean up their act so that it will encourage more non-Chinese to enter it willingly.


Legend of Kalevala was a bumpy five month ride, filled with lots of elbow grease and none too few expletives, but the final product has been worth it. I’ve been wanting to scratch a double creative itch; First, to create a game that told a rich, detailed story of my own devising, and secondly to create a game that was simply fun to play. From the reactions I have received since LoK went public, I feel that I have met both goals. I have learned a lot over these last five months and my next game will certainly address much of the problems that I have mentioned during my development process. I will be more aware of these pitfalls at the start, and save time by not having to re-factor large parts of my game or clean up initial bad decisions. To those who make games or are learning how to make games, keep doing what you love. And to those who play games (in particular Legend of Kalevala), then keep supporting the ones who do make games! We need your praise and attention. It reminds us exactly why we frequently neglect loved ones and basic necessities in order to complete our projects. :)