Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
The post-mortem of Skejo Studios' Operation: Eradicate, an iOS turn based strategy game. Slides included at the bottom.
For four or the five months, I have been working on Operation: Eradicate, an iOS turn based strategy game. With my graphics designer, we at Skejo Studios have revisited the last few months, and wanted to write about the highs and lows, and lessons learned for next time.
First I wanted to start with our initial hoped for timeline:
* Sept 2011 - Start
* Oct 2011 - Code fleshed out and Art assets started, first round done
* Nov 2011 - Dev and art near finish, start beta testing
* Dec 2011 - Wrap up loose ends, ship by Christmas
* Oct 2011 - Started full-time on the first project with part time UI graphics guy, and contract artist
* Late Oct - Basic gameplay with dev art done, still hoping for Xmas release. Yeah right!
* Late Oct - First hard-drawn art assets issued
* Early Nov - Save/resume games implemented, iOS 5 turn based games (a selling point, to Apple more than anyone).
* Late Nov - Wife got a new job, moved new city little dev done. Art still slowly making progress.
* Early Dec - Final non-colorized artwork done. We were advised the game needed a full event driven tutorial to on-ramp players to game. Ugh! - Moved goal for launch to end of Jan.
* Late Dec - All game mechanics done, first beta test sent out to 5 players.
* Mid Jan - Many UI redesigns occur, plus tons of polishing adjustments.
* Late Jan - Finalized, full color artwork delivered. Pushed launch to Feb. Another round of play testing, polishing, tweaking.
* Early Feb more weeks of polishing.
* Submitted to Apple, Tuesday Feb 14.
* Approved by Apple, Mon Feb 20 (on my birthday)!!! Massive Marketing push ensues.
* Released set for Sunday Feb 26 (to get in front of GDC)
I will also be writing a Marketing Post Mortem to trace and dissect the good, bad and lessons learned from the launch.
The first lessons we learned is to be flexible with due dates, but still have them in place. As I was the only full time person, I was pushing hard because I could, but it is difficult to push part time contractors to speed up. I now will factor in slips in the timeline for artists. But even missed deadlines serve the function of putting a mark on the calendar and pushing for it. Motivation sometimes can be lacking, and that date keep things in focus. Just don't use missed deadlines as a source of depression, just learn to estimate better. Deadlines also help you look back and realize how much you did get done before that date passed.
One way to help contractors (of any stripe, not just artists) create deadlines they will really try to hit, is to incentivize the deadline. Maybe add a 5% bonus for each delivery deadline hit, or maybe a lump bonus if 75% of delivery deadlines were hit. This will help them suggest dates they can hit, and gives them reason to hit them more accurately.
As already mentioned, this was my first time working so closely with artists directly, and a few false starts, and all deadlines missed made me realize I was working with people different that me (an analytical engineering type). We are all different minds, and that is all good. For me, I felt the artist delivered more than I asked for, but took longer than I wanted. But how do you direct them to do less to hit the deadline, when they are working on hand drawn artwork. Especially when the artist insists that he won't charge. Again, this is where the incentivized deadlines can come in handy
The other deadline item is setting realistic timelines for part time contributors. Rarely did their contributions come in smooth, predictable chucks. More likely they came in spurts, sometimes unpredictable. We will keep that in mind on our next projects, and as we develop updates for this game.
The last huge mistake is that we didn't add a zoom to the playing map for iPhones and iPod Touches. During one UI redesign, we took it out, and none of our play testers complained so we thought we were good. Except all of our play testers were experienced gamers, and had used the controls so much they didn't notice (or didn't report) issues with the map on smaller devices.
But we were nailed in the reviews w/ numerous 1 star reviews, and many emails asking for a zoom to be added. Thankfully we already had the code generally working, so it only took a couple hours to get an update to our testers, and wrapped up a submission to Apple in two days (numerous other typos, small fixes and enlargement of other buttons included).
Two things we learned from this issue is to specifically ask the impressions of a change you make if you are using the same testes. Them not reporting that the disliked a change, doesn't mean they liked it, just that they didn't report it. Second, use more new testers each time you have a test release. Otherwise they might be too familiar with the and attuned to the rough spot, thus not reporting them.
We allowed enough time for UI rework. We didn't kid ourselves into thinking that we were going to get it all right the first time. I worked on a first pass developer UI just to get the game to a playable state. This I pushed to the UI designer while I worked on other behind the scene stuff like turn based games, Game Center integrations and other items. Then I implemented his design and we through it to some testers. Their feedback, and more time to imagine gave the designer more inspiration, which eventually lead to a good interface.
You can see the map and UI progressions here: http://www.tech-wanderings.com/eradicate-week-16-game-mapui-progression
* Send stuff to publishers. They may reject you, say mean things about your progress, but they might also give you hints on how to improve. They did for us.
* Fix bugs/broken stuff when you see it, don't add toa todo list. Fix it NOW!
* Biting off too much is very easy to do!
Fear 1: What will other people think of it? Maybe I will wait until I get more done.
No, the earlier you get feedback the better. Test users and honest feedback gets you off wrong paths and deadens, and spot glaring issues sooner. Polish added to a feature you remove later is a waste of time. Don't polish anything until you know you have nothing more to cut out.
Fear 2: We are done, but I don't want to send the game to reviewers because they might be critical.
If you think your game doesn't blow away the competition, or that the reviewers will hate it, then why did you make the game? If you aren't proud of it, send it back for more polish or rework. If you are proud of it, send it out, get as much talk about your game. Anything is better than silence. This last point is more for a marketing post-mortem, but it felt like it fit here.
Web site: http://www.skejo.com/eradicate
Release date: February 26th, 2012 (iPad and iPhone/iPod touch)
Development time: 4 months
Team size: 1 full time, 1 part time, 1 contractor part time
Development cost: Cost of living for 4 months + about $2500 (art, marketing, resources)
Primary tools: Xcode, git, SpriteHelper
Raw asset size: 391 MB
Total app size: 13.9 MB
Coffee Consumed: 500+ shots of espresso
Finally, we do have the first week's worth of sales data, and we must have done a few things right. We landed in the #4 iPad Strategy spot and the #5 iPad Board game spot at launch. We didn't write down targets for launch, but this would have exceed anything we would have written.
Vertical Scrolling story telling platformer, to be official announced shortly.
With a side scrolling indirect platformer using same artwork/world/back story.
Very high concept resource management, mini-game, character advancement game.
Operation: Eradicate on iTunes.
Comment below, or with Twitter,
SLIDES from my CSU Fullerton Video Game Design Meetup:
Operation: Eradicate Post Mortem View more presentations from Greg @ Skejo Studios.
Read more about:
Featured BlogsYou May Also Like
