Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: 11 Bit Studios' Anomaly Warzone Earth
View All     RSS
October 22, 2014
arrowPress Releases
October 22, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: 11 Bit Studios' Anomaly Warzone Earth

January 28, 2013 Article Start Page 1 of 4 Next

The popular "inverted tower defense" game was the first created by 11 Bit Studios, a team of Polish veteran developers. Here, Paweł Miechowski, the studio's senior writer, talks about the difficulties and successes of booting up and building a game at the same time.

Anyone who has ever worked on a project in the entertainment industry -- whether it's a movie, a music album, or a game -- knows well the feeling of being proud when the moment of finalizing the project arrives. This pride is some unique mixture of the joy of finishing the work and something that parents feel when their kid has learned to walk or has been given their first A in school. Of course, parents (usually) don't celebrate this moment with barrels of beer, as often happens in the game development industry.

If this comparison is applied to the game industry model, then our kid has a teacher or a supervisor (the publisher), who has his own ideas for teaching the kid to walk. Sometimes it works fine, but sometimes the kid falls over on its own feet, much to frustration of the parents. Sometimes the teacher takes care of teaching the child how to walk as well as the parents, but later, in kindergarten, he doesn't pay much attention at all, and our kid is left on his own, not integrating with the others, and no one is interested in him.

And sometimes the teacher is flat broke or mean as a Scrooge, and he doesn't even get the kid a bus ticket to the kindergarten (well, that's what parents should do, but this is the hypothetical model, right?) Then no one will befriend with the kid, he'll fade into obscurity and end up as abandonware. While we want him to have a lot of friends and not only be given As in school, but also win competitions and awards. (Sometimes the teacher really takes care of a kid, but that's something for a different story.)

That's why one day we decided to quit the jobs we had at the time and found a new studio to be -- from that point -- completely independent. Awareness of the future difficulties or a lack thereof did not matter.

We wanted to become parents, who are the only people responsible for their kid, because we believed -- and still believe -- that no one would take care of the project better. We wanted to make absolutely personal games, completely in our own way, and use the blessed opportunity of digital distribution, where the creator is also a publisher. That's how 11 Bit Studios was born.

Apart from business independence, several thoughts were fundamental when the studio was created:

- The leading theme of the first game will be gameplay. We won't make a story-driven game, because it's not our strong point. Experience prompted us to make a gameplay-driven game.

- The concept has to be original, innovative, and fresh.

- In the past we used to work pretty efficiently on our own engines, so at the start we decided to create the base fundaments for a new proprietary engine chiefly adapted to our needs.

Anomaly Warzone Earth (prototype, top; final game, bottom)

What Went Right

1. Multiplatform Development on Our Own Engine

The Liquid Engine has been in development by the lead programmer Bartek Brzostek, in consultation with the designer Michal Drozdowski (back then, the only designer, now design director) and with artist Przemek Marszał (back then, the only one, now art director) since December 2009.

In April 2010, the base allowed us to build the first raw level. Fast? At the time, Bartek had over 10 years of experience in engine and advanced tools creation for building graphics and the logic of a game, so the decision to build our own engine was pretty natural -- let the guy do the engine if he's been making engines for years. He needed only time to prepare the fundaments of the new engine.

Indies are often advised to not waste time on the creation of proprietary tools and just quickly go into production on some external engine. This, however, has some serious drawbacks we wanted to avoid.

Firstly, no engine supports all platforms. For us, it was extremely important to port the game to as many of them as possible to enable multiple revenue streams. Secondly, using a third-party engine provides you with certain tools and features but no more. If you need something really custom, you're screwed; the engine developer won't deliver custom features for a small indie startup. Sometimes there is an option to acquire the source code and develop these features on your own; however, in most cases, it's not free. In essence, by using an engine out of the box, you give up a lot of flexibility and involve third-party risk. Most startups have no real alternative to this. We, however, did.

From the outset, our team was very strong in the field of technology (frankly speaking, it was very strong in all areas). We had a lead programmer with deep knowledge of PC and Xbox 360, including both high-level engine design and down-to-the-metal optimization. We had one of the best Polish GPU programmers with PlayStation 3 experience as a contractor. We had an extremely experienced gameplay programmer. And all those people had worked together for a couple of years in the past. This was a real asset, and we decided to use it to our advantage.

We limited the feature and tool lists to the absolutely necessary -- locations created out of XSI prefabs, top-down view, game logic created in Lua scripts, single player only, with a light pre-pass renderer for the sake of simplicity.

Everything that remained, however, we implemented at a state of the art level. We implemented a scene preprocessor to combine prefabs and optimize draw call count. We developed a smart multithreading architecture with one thread designed to do barely anything but feed GPU with data, and the other one processing game logic and nothing more -- the two most CPU-heavy tasks.

We optimized our pre-pass renderer extensively, fighting for the last shader instructions and GPU memory bandwidth. We implemented our math library with the use of vector units of all CPUs we supported. We designed a nice resource system with overlapped data loading, decompression, uploading to the GPU memory, and dealing with console memory fragmentation. We implemented a proprietary RTTI system to deal with serialization and developed a localization system with full support for Unicode.

The key to quick and efficient development was to enable gameplay programmers to work on the actual game almost from the start. So Lua integration came online as soon as the engine was capable of displaying a simple wireframe mesh. This way, while the engine was being developed, the game prototyping went on.

In terms of tools, we went with level editor, material editor, particle editor, sfx editor and localization editor -- mostly the tools supporting the visual side of the project. What we decided to skip were gameplay-related tools. So all game logic, cutscenes, UI flow was programmed in Lua scripts. It was enough to create a good game; however, it was a bit tiresome at the end. When the project went gold, we decided to work on additional tools to make gameplay flow creation more efficient.

Looking back, our decision to develop our own engine was 100 percent right. When we wanted to add PlayStation support, we could. iOS, Android, Linux, Blackberry -- same story. Sure, it was a lot of work. Each platform was a challenge. However it was also extremely rewarding. And it left us in total control. If one day we decide to develop Anomaly Warzone Earth for a mind-controlled refrigerator -- we will be able to.

Article Start Page 1 of 4 Next

Related Jobs

Bohemia Interactive Simulations
Bohemia Interactive Simulations — ORLANDO, Florida, United States

Game Designer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Game Designer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Gameplay Animation Engineer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Producer - Infinity Ward


Jose Resines
profile image
This postmortem seems to be a bit incomplete. It seems like point 6 is missing in what went wrong:

6. Checkpoint system is broken, you can play a mission almost completely and due to very bad checkpoint placement lose it with no way to go back.

Also, point 7:

7. Fixing this was as easy as letting the player go back more than ONE checkpoint. This should be easy and was "promised" several times (by the end of *2011* if I remember correctly), but we're still waiting. Look at how Defense Grid does it, guys. Not that hard.

I love the game, but 6&7 made me lose a lot of progress, so much that I refuse to play the game anymore. There's nothing worse for a game than having to repeat the exact same half hour of play THREE times!

It's sad, but I had to stop recommending it, and I'll think hard before I buy another 11 bit game.

PS. Sorry if I'm repeating the comment, but it didn't appear the three times I tried using Firefox. Thank god for the Lazarus add-on.

Pawel Miechowski
profile image
Hi Jose,
I agree. The checkpoint system did not work well in certain situations - like the moment when your damaged squad got to a checkpoint overwriting previous state where it's been not-that-damaged...
Unfortunately we had no enough powers and time while changing of the save system was actually a bigger work. However, we won't be using this model anymore.

Jay OToole
profile image
Thank you for an excellent postmortem. I thought I would offer a few questions and comments that remained with me after reading your postmortem. Feedback from you or other readers welcomed.


1. Why specifically was having a team of people who worked together for a couple of years in the past a “real asset?”

I can infer some reasons, but would love to hear more about your thoughts. You reiterate this benefit in section 2, point 2 but do not offer additional insights. I read about how important having a good team is in most postmortems, but most also lack detail that might answer the “why” certain characteristics of the team are important. Sometimes I chalk it up to a type of writing I would describe as “it should be self-evident,” but if it should be self-evident, then why even write about it?

Additionally, were there any times when having worked together in the past made development more difficult? Answering this question might also help me and other readers understand potential pitfalls of working with the same people for a long period of time.

2. I thought your comment “the key to quick and efficient development was to enable gameplay programmers to work on the actual game almost from the start” as very informative and helpful. Thanks.

3. Adding slack (buffers) to your plan makes a lot of sense. Is that something you have figured out over the years? Have you seen other studios include “buffers” too?

4. Also, having a devil’s advocate (full time pessimist) seems to be great advice.

5. You choose your PR based on a couple of beers with a personal connection. Not all start-up studios have the luxury of those personal connections. Besides your friendship with Tom Ohle, what did Evolve PR specifically offer you that helped you feel comfortable deciding on them?

6. Love your recommendation at the end of section 4 on gameplay innovation: difficult to accomplish, but very true.


1. I was left wondering what you would have done differently. Every project includes choices because of the constraints placed on them whether through budgets, time, or personnel. The things that went wrong seemed to mostly reflect outcomes because of your choices to devote most of your time to the things that “went right.”

You acknowledged at the beginning of the article that you focused on gameplay rather than story because “it’s not our strong point.” However, in your conclusion your write “in future projects, we’re going to put more attention toward these (story and dialogue) elements.” There is an obvious risk in doing so—other parts of the game may suffer because you are bounded by your resources. I suppose one answer is 11 Bit Studio will have more resources for future projects and thus can attend to gameplay at the same level as Anomaly while also attending to story. I guess I am just curious if your concluding comments were simply a reflection of what could have gone better or a genuine interest and belief that the cost-benefit calculation of actually investing more in story and dialogue would generate a net positive.

Really enjoyed the postmortem. Thanks.

Pawel Miechowski
profile image
Hi Jay,

Let me share some thoughts and put more light but first of all excuse me for grammar and language flaws.

What went right:

1. Basically, the team that has been working together for several years has some proven schemes or procedures (or even I'd say behaviors) and solutions to certain problems. For example - when designing the renederer lead programmers already knows what techniques would be used by the lead artist to achieve certain visual feel of a game and what shaders and tools should be given to him at his disposal. And the lead artist knows how to prepare graphical assets in order to make a scene being rendered efficiently. The amount of necessary discussions / communications drops down, people understand each other "without speaking", the amount of misunderstandings drops down, the efficiency of the work goes up.

There's something that just came to my mind when thinking about certain characteristics of the team. I'm sort of affraid it may not answer your question well but I'll try. There's this story about Gilmour and Waters from Pink Floyd that they have been struggling all the time to make each one's vision of the music dominant (progressive rock operas vs classic hard rock). And this conflict actually has had a positive influence on the music because each of those creative minds has added an element both have believed would be the unique one while the uniqueness came from joining 2 elements. Now, what I mean is that this probably would ruin a game development process, becuase it is technically far more complicated project and the team needs to have one common goal and one creative vision. If the team is made of people who have trust one for another and they like each other enough to go for a beer after hours, then probably the work would go really faster. And that also means (referring to your question how it was in the past) that sometimes you need to "divorce" some creative person just because he/she might be a conflict triggering one, because he/she has a different vision.

3. & 4. Every developer adds buffers to the plan, but the key is I guess very cleverly named - devil's advocate. Double the buffers because you're gonna slip. Always :) That's what devil's advocate says.

5. Simply the trust we have for Evolve PR is based on their record of good pr campaigns.

What went wrong:

1. Feeling strong in doing gameplay-driven games we will be still focusing on it but that does not mean a simplified story should not be improved. Better story/dialogues would strenghten the feeling of immersion. But is there a risk other parts of the game would suffer? Always, but you made the point right - we have more resources now. The team grew up - PC/Mac version of Anomaly was made by 12 men. Now we're almost 30. 29? I need to count :)

Hope this gives you wider spectrum of this post mortem.

Jay OToole
profile image
Thanks Pawel! I found your additional insights extremely helpful. Thanks for taking the time to write the postmortem in the first place and taking the extra time address some of my questions. Good luck with your future projects!

Jannis Froese
profile image
Hi Pawel,
first I have to say it's great that you take so much time answering questions.
Now that tha't out of the way: You mention the importance of prototyping your game multiple times. As you were also building the engine from ground up, I'm interested how exactly your prototyping process worked.
Did you build a prototype and then start over from scratch with the real thing, or did you incrementally exchange prototype code with real code? Or did you keep the prototype code and improve and extend from there?

Also, the postmortem was great and just three days ago I started playing your game the second time.

Pawel Miechowski
profile image
Hi Jannis,

At the beginning the engine was capable only of rendering flat "dots" that served as any objects in the game prototype and it was operated by lua scripts. So the gameplay programmer was coding the system for controlling and moving the "dots" squad. In the meantime the engine programmer has added the possibility to use meshes instead of those dots. And so on and so on.
This way the prototype fluently evolved into the game.

Tulio Soria
profile image
Hi Pawel!

Very nice postmortem. We are creating an indie Tower Defense as well. The name is Tank Invaders

I have one doubt about your launch on mobile devices. Do you release the game with Chillingo? What you could say about them?

Thank you so much in share these informations.

Tulio Soria
m.gaia studio -

Pawel Miechowski
profile image
Hi Tulio,

The game was released on iOS App Store with Chillingo and the guys are good at things like QA process or on-release marketing. I'd recommend Chillingo to work with unless you want to do everything on your own. Please remember that in the end the game is the key value but it'll need certain activities like getting press visibility etc.

Jane Castle
profile image
H thanks for writing this postmortem. Was the engine also multi-threaded as you describe in the DirectX9 version as well? If so, this is VERY impressive as the Direct3D API as I recall does not work well multi-threaded. That in itself is an incredible achievement.

Also, based on your descriptions, is all game logic, animation skinning, scripting etc. running on the windows main execution thread and then you have a separate thread for the rendering?

Or is it that you have the main execution thread, another thread to run game logic jobs and another thread to do the rendering?


Pawel Miechowski
profile image
Hi Jane,

Different tasks were divided into different threads. Separate one for rendering, separate one for game's logic, separate one for sound, separate one for reading files and another one for decompression of the files. All threads were set up in the pipeline. That was multi-threaded way. But indeed DX is single threaded and we couldn't make much about it.


Javier Sanchez
profile image
Hi Pawel,

Very good read indeed!

I am specifically interested in the PR part, as I've read here in gamasutra tons of advices about self-promotion. The thing is, was the external PR a costly investment, or could it fit into a small indie budget?

Thanks for sharing such a good postmortem!

Pawel Miechowski
profile image
Hi Javier,

(let me note first that this is my subjective point of view)

I think there are really good hints and tips about self-promotion or low-cost promotion here but this way needs (maybe not a full-time but still) lot of time to execute. Hiring external folks for pr will save your time but it will cost you money. I wouldn't recommend any pr agency. Instead of this I recommended one I have trust for. The rest is totally up to you. Costs are also dependant on the range of services you will need. So just ping the guys at and maybe you'll find what you need.