Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 27, 2017
arrowPress Releases






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


 
Post-Mortem: Lair of the Evildoer
by Ben Kane on 08/18/11 12:32:00 pm   Expert Blogs   Featured Blogs

3 comments Share on Twitter Share on Facebook    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Now that Lair of the Evildoer has celebrated its two month anniversary (and dropped off all lists on the dashboard), it's time for a post-mortem! I haven't done a sales post yet, but suffice to say that they have been a tad disappointing. Nevertheless, the conversion rate is promising and I'm consequently polishing up the PC version of the game.

This post-mortem is a bit long, but it seems fitting given the length project. Enjoy!

(Cross-posted to my blog. You can find my games at goingloudstudios.com)

What Went Right:

Making the game I wanted to make

First and foremost, this is the reason why I consider Lair of the Evildoer to be a success. I started out with a relatively vague set of features I wanted to include, and built the game iteratively according to what I felt would be fun. It meant I got to include things that I wanted to see in a game of this type. It also meant cutting things after they had been implemented simply because they didn't end up being fun. The game may not have turned out perfectly, but it's a game I am proud to have made.

Avoiding feature creep

With roughly 2 months left to go in the project, I started using PivotalTracker to maintain a list of work items and try to get a schedule under control. Doing so allowed me to easily see how over-ambitious I was being and make some hard cuts to features. Without this self-control, I would still be working on new features with no end in sight. It's great to have a lot of ideas, but they mean nothing if you never ship.

Iterative playtestings

I experimented using the playtesting feature of AppHub to post weekly new builds of the game roughly two months before I planned on shipping. This gave me some great early feedback, as well as some priceless testers who tried multiple versions of the game. I feel there's still some work to do here in order to get the most out of playtesting though - much of the later areas of the game were tested infrequently or else ignored completely. You have to be careful not to overstay your welcome and use up the goodwill of those helping you. I think some incentives, cheats to skip sections, and more focused testing (such as only including one specific level at a time) could improve results here.

Entering Dream Build Play

I finally entered the Dream.Build.Play. contest. This was more of a personal goal, but it was satisifying to be able to submit my completed, polished game by the deadline.

Winging it

The first month of development was filled with wild prototyping as I experimented with procedural generation, read up on loot systems, and tinkered with GPU shadows. Even for the next three months, aside from a few key features, much of my development was guided by spur-of-the-moment inspiration on what I felt would be a cool or fun addition. While this almost certainly ate into my development time, it was great to be able to code by the seat of my pants.

More press releases

For my first game, Zombie Accountant, I sent out a press release on the day the game launched. No matter how good your game is, it's going to be tough to get any sort of attention that way. This time around, I sent a press release announcing the game, another a month later to announce the release date (and more details) and then a final "Go get it!" press release on launch day. This might not be the right balance, but it certainly felt like there was more "buzz" generated this way.

Peer review in 48 hours

Lair of the Evildoer passed peer review within 48 hours, which is the minimum amount of time that a game can spend in that process. I attribute this partly to having a greater presence in the AppHub forums as well as a better relationship with other devs on Twitter. The longer time in playtest may also have helped.

Doing everything myself (or else getting it for free)

Aside from some the music, which was provided for next to nothing by one of my talented and generous friends, everything in the game was created by me or else was used with a permissive commercial license for free. Total cost for the project, other than my existing AppHub membership and my time, was about $100.

Making dev videos

For a few weeks in late development, when features were coming fast and hard, I made weekly videos about progress on the game. They didn't garner a huge amount of attention, but hearing even just a little feedback was enough to spur me on. [Youtube]

Coverage Get!

More press releases, emails, trailers and Twittering earned me quite a few reviews, articles, giveaways and "picks" on a fair number of indie gaming sites. My "big" breaks include getting picked for "Kotaku's Favorites" (which came with a spot on an Xbox dashboard list for two weeks) and even a brief spot on Attack of the Show. Seeing my game on TV was a pretty awesome feeling.

What Went Wrong:

Development time

Nice feelings and satisfaction aside, spending 6 months on a project to see this kind of a return is simply not sustainable.

No co-op

The lack of co-op play was not mentioned as frequently as I expected, but I still feel this is the largest omission from the game. It was not an easy feature to decide to cut, and perhaps better planning could have prevented that.

Planning release for E3

Once I got a handle on the remaining work and polish that I decided I wanted to put into the game, I pieced together a schedule for announcements, trailers, peer review, and finally a release date. It took a while to settle on something realistic. It took a further two days for me to notice that my announcements coincided with the pre-E3 conferences by Microsoft and Sony, with the release date itself falling just as E3 ended. Whoops. Back to the drawing board.

Art takes a long time and requires direction

All of the art in the game was created by me. I had no real direction or style in mind when I started creating it. The result is a collection of half-hearted temporary art mixed with haphazard rushed art to fill in the gaps created by overzealous data creation. It's really easy to add a new monster type to a spreadsheet when you don't consider the art that needs to go along with it. In the end, graphics ended up being probably the weakest area of my game. Had I recognized this earlier on, I would have opted for higher quality and lower quantity - focus on a cohesive art direction and don't skip "petty" things like animation due to time constraints.

Boxart + Name = No Trials!

I'm still a bit unclear as to how to avoid this next time, but I do know that my combination of boxart, title, description and screenshots were quite unsuccessful. I have some theories, but the important part is the result: gamers browsing the indie games market were not enticed by what I was selling. Zombie Accountant pulled in over 15000 trial downloads in its first 10 days. Lair of the Evildoer earned just over 5000.

Making dev videos

Making development videos takes a lot of time! I found that a good chunk of my Friday ended up being spent recording footage, making a voiceover, piecing together a video, uploading it and then making a blog post/tweeting about it. Considering the only viewers were other devs, the return for this effort was rather minimal.

Git (and 200mb of hosting)

Having cut my teeth on Perforce in the industry, I was using Git to store both my code and game assets. Towards the end of the project, I ran into issues with disk space and came to realize the horror that is storing large binary files with Git (and expecting to keep disk usage reasonable). It was a gotcha that I managed to avoid having to throw money at to solve (i.e. buy more hosted space), but it did take me about a day to learn more about Git's internals and resolve it with my provider. On the plus side, the distributed nature of Git allowed me to keep developing while I did so.

What Went ????:

Releasing on a Friday

The Xbox Indie Game marketplace is governed by lists. Stay on the lists and you stay visible, getting downloads and making sales. One of those lists is "New Releases". Ideally, you will be at the front of that list during the peak period of Friday-Saturday. I scheduled my release for Friday, which guaranteed me a decent position on that list. The downside is that the press tends to go home on weekends and thus you don't necessarily get the attention you hope for. Press releases go unread, trailers go unwatched and emails go unreturned. If you're lucky, you'll be picked up the next week. But when dealing with the press, you don't want to give yourself any unnecessary disadvantages.

Designing the trial experience

Lair of the Evildoer has a slightly modified "campaign" for players who start the game in trial mode. The dialogue is different, reflecting the fact that you have not purchased the game yet, and the balance is weighted in the player's favor to prevent dying and wasting time. There's even a special ending to deal with the player who manages to race through the limited content of the demo. All of this took time to develop. There's also no way to tell if it made any difference at all to players and their decision to purchase (or not).

Not waiting for DBP or Summer Uprising

I chose to release Lair of the Evildoer when I had completed the features I decided I wanted to include, and once they were polished. Had I waited another two months, I could have been sure that I wasn't affecting my chances in Dream.Build.Play. by releasing the game on XBLIG before the winners are announced. Officially you are allowed to do so, and the competition is steep this year anyway, so I don't regret my decision. I also could have entered into the Summer Uprising, though inclusion in that promotion would have been a tough fight too.

Focusing entirely on one project

Like most developers, I have a habit of wandering off with ideas to make prototypes and leaving behind a mess of unfinished games. I decided early on that this game was going to require a significant investment of time and thus I should focus my efforts entirely on this one project in order to minimize delays. While this was probably the fastest way to finish the game, it's also the slowest way to finish the next game (provided I don't make a sequel immediately). I think I'll be attempting a few projects simultaneously this time around to prevent fatigue on any given idea and hopefully have more frequent releases on average.


Related Jobs

Visual Concepts
Visual Concepts — Los Angeles, California, United States
[07.27.17]

AI Software Engineer
Visual Concepts
Visual Concepts — Los Angeles, California, United States
[07.27.17]

Tools Software Engineer
Pulseworks
Pulseworks — Smyrna, Georgia, United States
[07.27.17]

Unreal Technical Artist (VR)
Visual Concepts
Visual Concepts — Los Angeles, California, United States
[07.27.17]

Software Engineer





Loading Comments

loader image