Featured Blog

Take Arms - A Post-Mortem

Detailed Post-Mortem of the XBLIG title Take Arms, featured in the Indie Games Summer Uprising.

Trainyard Screenshot


It has been about 2 weeks since the re-launch of Take Arms for Xbox Live Indie Games, so I figured now is a good time to get down my thoughts on what happened over the past 2 years of development. I think we made a lot of good decisions, and of course an equal number of bad ones. So without further ado, here is the Take Arms post-mortem.

What Went Right

Concept & Gameplay

Out of all the things that went right in Take Arms, I think the most important is the good gameplay. It’s not the most original concept ever, but it’s a genre that hasn’t been overdone, especially on the Xbox. After we prototyped it out, it was clear that it would be really fun once we got it all together. And truth be told, I think it actually turned out way more fun online than we ever anticipated with 8 people battling it out and trash talking each other. There are some similar games Take Arms regularly gets compared to like Soldat, ZP2K9, and Crash Commando. We wanted to approach it a little differently with a more realistic, cover-based combat style, and I think it worked out pretty well.

Design Document & Scope

The final product of Take Arms is incredibly close to what we wrote down before we even started prototyping. I know a lot of people don’t follow a strict design document, but I think it was the best decision we could have made at the time. We had a bad habit of not nailing down fun core mechanics and then inflating the scope to make up for that, which predictably led to a string of failures. After revisiting the design document almost 2 years later, the only major changes I can see were dropping a couple of maps and a game mode. We added a few small things that weren’t in there, but they are relatively minor features. We tried to focus more on the interplay of mechanics instead of continually adding more, and I believe that led to a solid game in the end. We could have taken another 6 months to keep adding features, but I don’t think it would have helped that much.

Game Engine & Tools

If you ask any game developer for their advice on game development, one of the first things they will tell you is to not re-invent the wheel (and understandably so). For beginners and hobbyists it’s very easy to get caught up in the idea of the “ultimate game engine” that will work for any possible game idea you can come up with. We realized this was a trap pretty early on, and made sure to make tools for exactly what we needed and nothing more. While we might have been able to save several months of development time by using pre-existing components, we both felt it was important to learn as much as possible this time around. The engine and tools we ended up with are very lean, and we didn’t dress it up more than it needed to be. To my knowledge, there’s not a single unused feature in any of the editors (level, particle & skeletal).

Map Design & Production

In order for the game mechanics to work properly, you need environments that make them useful. We identified the settings very early in the development process (they are in the original design document), but we didn’t actually get them mapped out until close to the end. One of the biggest changes we made towards the end of the project was dropping tile maps, and going with a free placement system like Aquaria or Braid’s. While ours isn’t quite as powerful or fast, it gets the job done and it was a good decision to make.

The map designs themselves were iterated over several times. It became pretty clear we needed some verticality in them to make up for the 2d limitation. It’s impossible to flank someone in 2d unless you can go above or below them, so a lot of thought was put into making 2-3 stacked paths that don’t feel contrived. We wanted the game to be grounded in some realism, so we tried to avoid making random floating platforms and such. The other major difficulty was blocking gun fire so it didn’t go straight across the map. To prevent that, each route either has shift in it’s level or objects placed at gun height to block fire.

What Went Wrong

Mishandling Contract Artists

A continual point of failure during development was our mishandling of contract artists. By the final game art, we were on our third contract artist. One of the major problems was bringing artists in too early, and relying on them too much for the design portion. This was mainly just due to inexperience. The idea was to bring in someone with the same passion as us, and hope they would work just as hard and long. The truth is that no one is going to be as passionate about your game as you are, especially if they have other contracts to worry about. The right thing to do was to have all the content in-game and ready for an artist to redo (which is what finally happened in the end).

Community Building & Social Networking

Another major failure on our part was not building a community during the development process. The thought in the back of our minds was that we would release a trailer, word would spread itself, and that’s that. Unfortunately, we couldn’t have been further from the truth.

Our biggest media impact was in June 2011 when we revealed the Teaser trailer featuring narration by Jon St. John. Kotaku and most of the major indie game sites picked up the story, and it spread quickly. We ended up with over 20,000 views on Youtube in just a matter of days. So, what’s wrong with that you ask? Well, we had absolutely no social media presence (Facebook, Twitter, etc.) or forums for prospective fans to congregate on, so we basically lost all those people. They saw the trailer, said it looked cool, and then just forgot about it over the summer. We missed a huge opportunity to get people attached and keep them coming back.

Lasty, I think we really goofed in not getting involved more with the XBLIG community. Honestly, neither one of us were on Twitter til just about the very end of development, and we only visited the App Hub forums when we desperately needed help. We finally managed to get on Twitter and met a really cool group of people via the Uprising just recently.

Online Testing & Game Launch

So there we are, the night before our “launch day”. We held our breath, and pushed the button to release the game around 6PM. By 8PM it was out on the Marketplace, and I jumped into my very first online Take Arms match. The map loaded up, I picked a class, and started playing. Within a minute, the game started stuttering and then died with a Code 4. What the hell happened?

Remember how I told you earlier we weren’t involved with a community? Well, that’s a large part of what went wrong. One of the absolute worst things about XNA is the locked down Networking API. It’s not included in the XNA runtime redistributable, so the only way to get it is to install the entire XNA Game Studio package along with Visual Studio. On top of that, to test over the Internet you need an AppHub membership AND Xbox Live Gold. This combination of factors narrows down your possible testers to a ridiculously small percentage of the population. So 99% of our testing consisted of Tim and I, and a couple of close friends. Testing with four players out of a possible eight doesn’t sound too bad, right?

As it turns out, somewhere along the development process we commented out the while loop that iterated through all the packets received for the frame (most likely to help debug an issue). We were effectively only processing one packet in the buffer per frame. Apparently, around 4-5 people was the max you could have in a session, and not have any visible side-effects. Once you went above that, the packets would quickly build up and eventually overflow the buffer causing a Code 4.

After discovering the problem, we felt there was no choice but to pull the game from the Marketplace. It seemed unfair to put people through that after spending their money on it, and the reviews would have suffered terribly as well. As a result, we lost our coveted “New Release” spot on the Marketplace, and missed all the buzz for our day in the Uprising Promotion. In the end, I still feel like we did the right thing by pulling it, but we should have been more heavily involved in the XNA community and found help to pack out sessions before release.

Platform Choice

This may sound like I’m trying to pass the buck, but please bear with me. I really believe we picked a bad platform. Nearly two years ago when we started, the XBLIG Marketplace wasn’t necessarily thriving, but it wasn’t anything near what it has declined to today. And I don’t think its because there are no good titles coming out for it, but rather because of the deluge of crappy massage games trying to make a buck, the frequent reminders in the press that sales are terrible (Cthulu/Steam Sales story anyone?), and the pervading mindset that there MUST be a reason it’s not on Arcade. The common mantra seems to be: “XBLIG isn’t a place to make money, but it’s a good place to get your name out there.” After what we’ve seen, I’d say that’s a crock of shit.

In my opinion, we just went through the best possible scenario for an XBLIG: the Uprising got a lot of press by mainstream sites (Kotaku, GamePro, Game Informer, etc.), Microsoft provided a full Dashboard promotion, and we had a lot of other good games come out right along with us. Yet every single day we struggled to reach even 1,000 trial downloads. Taking an average conversion ratio of around 10%, you’re looking at 100 sales a day during a period with the most promotion we will probably ever see on the Indie Games Marketplace.

You may be quick to say: “Dude, your game must really suck!” While you may be right, I can confirm that none of the 240 Point games were too far from each other numbers wise. I know Take Arms isn’t earth shattering in content and gameplay variety, but with a touted 22 million Live subscribers staring at a promotion on the dashboard for a week you’d hope to get more than 10,000 trial downloads.

As a side-note, since the promotion has ended we’ve seen a massive drop-off in both trials and sales. We are now at roughly 20% of what we were during the promotion, which is leading me to believe we will be lucky to break even on the game. If we had to do it over again, I think we’d lower the price to 80 Points on launch, and then deal with raising the price later if we went over the 50MB limit (we managed to ship at 48MB).

Final Thoughts

In the end, I’m definitely proud of what we accomplished. We had a good idea, developed the engine and tools to make it possible, worked with some really talented people, and finally got it out there and made it a reality. The learning experience has been invaluable to us without a doubt. A big thanks goes out to everyone who helped us along the way, including artist Jianran Pan of Creative IG, Jon St. John for the teaser trailer narration, TRS-80 for the launch trailer music, all the awesome AppHub devs that helped us properly test after our failed launch, and finally Dave Voyles, Kris Steele and everyone else involved in the Uprising promotion.

So what’s next for Discord Games? We’ll continue supporting Take Arms with updates, fix any bugs that crop up, and eventually start working on our next title. If we learn from our mistakes, I believe it will be more successful and a better game overall.

Latest Jobs

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Programmer

The Pyramid Watch

Game Designer (RTS/MOBA)

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Technical Combat Designer

Digital Extremes

Lead AI Programmer
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more