Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: 11 Bit Studios' Anomaly Warzone Earth
View All     RSS
August 2, 2014
arrowPress Releases
August 2, 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 Previous Page 4 of 4
 

4. PC Version Balance (a.k.a. "Bloody Difficult Mission 11")

For some reason -- no one wants to take responsibility for this decision today -- we changed the initial version of the 11th level, feeling that it was too easy for this part of the game. The entire story campaign mode has 14 levels, and the difficulty curve initially was kept correct -- the last two levels were the biggest challenges, and in the last one, of course, the toughest was the mega-boss.

In the 11th mission, we introduce a new enemy -- the Energizer -- which is capable of respawning destroyed enemies. So it's a pretty tough enemy, but one is able to beat it fairly easily by bombarding with an airstrike. Beating this mission with airstrikes is still properly challenging for a later level.

And suddenly -- oops! -- we took airstrike from the player, and Mission 11 become extremely difficult. We didn't notice that, because we knew the game mechanics so well that we knew how to beat this mission easily, and we thought that the 11th level should be more difficult to maintain a proper difficulty curve.

Players, on the other hand, had problems with it. Some stopped playing on that level, because they could not beat it. A part of those who finished entire game have admitted that the 11th level was the toughest. It's a solid mistake, perhaps caused by the fact that the final tests were done by people who knew the game too well. The conclusion is simple -- until the very end, you need to involve some people in testing who are completely fresh and new to the game.

5. Bad Start on Google Play

We totally didn't have any experience, nor were we properly prepared to launch a game on Android Market (now Google Play). We learnt everything from scratch on the back of our own mistakes. It began with a not-so-good toolset - we used Visual Studios and the VS_Android plugin. Unfortunately, we could not conjure up a debugger. Eventually we used the console log.

Secondly, many devices heavily utilized bugged graphics drivers. Overcoming those bugs required blind guessing. Unfortunately there is no any easy way to communicate to a user to install the latest drivers. Thirdly, it's impossible to test the game on all possible devices. There are over 1,000 listed on Google Play. Quite often -- and only from players -- we received feedback about problems on various devices. We don't have any idea about testing these devices other than to just buy the most popular ones and learn through feedback from users whether bugs disappear on their devices too.

Furthermore, we had isseus with the limitation for APK size. Anomaly consists of about 150MB of data. The market limits APK size to 50MB. To solve this, one has to arrange hosting of additional data. This approach completely kills the point of refunding money to user within 15 minutes if they're not satisfied with the application. Within 15 minutes, many people were unable to download all the game data, especially when they connect to the internet via mobile network.

Finally, an interesting fact -- Google Play did not allow you to sell apps from Poland. In Poland, there are several hundred developers of apps for mobile devices. We had to get around this by cooperating with a foreign company. However, a little later, the store expanded to allow apps from Poland and the Czech Republic.


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

Conclusion

Despite numerous iterations, we couldn't avoid mistakes in balancing and testing. The gameplay came out fantastically, but the story and dialogue could have been better. In future projects, we're going to put more attention toward these elements.

At an early stage, we quickly managed to create our own engine, which we constantly improved with new tools. Now we have our own toolset adjusted to our needs and to multiplatform development. We expect to have slightly faster tempo for future projects; however, the "no crunch time" rule is still in force!

Anomaly Warzone Earth did a good job on PC and Android (10,000 downloads were reached in about a week and 50,000 in a bit more than one month). On Mac and iOS it did terrific. The Linux version was launched with a Humble Bundle, which sold 150,000 bundles.

The Xbox version, though, had a serious problem at the start. During first two weeks, the game page on XBLA was missing trailers, screenshots, and artwork -- almost everything except the description. So if anyone was looking for the game to buy and download, they were able to see only the text and nothing else. We and the team on Microsoft side struggled with this system bug for two weeks before it was fixed; the initial sales was rather bad, but in the end the console version paid off -- however things didn't go as well as the PC or mobile version. For us, the console market is the toughest one, and we rather recommend hitting Steam or Google Play unless you already have a Minecraft-size brand on your hand.

Let me sum it up. We created a new studio, in which the experience of veterans of the Polish game industry, and the creativity of new members gave birth to a game that gained respect from young strategy fans and old hardcore gamers as well. Often it was praised for its uniqueness of gameplay, originality of the concept and high level of polish. Now, we want to keep this level in future games -- gamers expect this from us, and we expect this from ourselves!


Article Start Previous Page 4 of 4

Related Jobs

Nix Hydra
Nix Hydra — Los Angeles, California, United States
[08.01.14]

Programmer
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[08.01.14]

Game Designer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

DevOps Engineer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

Animation Programmer






Comments


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

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.

WHAT WENT RIGHT

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.

WHAT WENT WRONG

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.
thanks!

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

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

Tulio Soria
profile image
Hi Pawel!

Very nice postmortem. We are creating an indie Tower Defense as well. The name is Tank Invaders https://www.facebook.com/tankinvaders

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.

Best!
Tulio Soria
m.gaia studio - www.mgaia.com.br

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

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?

Thanks

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.

Thanks

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 info@evolve-pr.com and maybe you'll find what you need.

Thanks!


none
 
Comment: