"Gentlemen, I'm goin' home in my new car."
by Jon Frisby · 09/20/2007 (1:08 am) · 9 comments
Forgive me if this seems a bit rushed, I've actually spent two days working on it now!
Releasing a game has been a bit like this for me.
As of 9/16/2007, I join the ranks of those who have published a game. That date is 3 months to the day since I left my day job to focus exclusively on MrJoy, and naturally I get upstaged by much bigger news. Darn your black heart Josh William!!! Actually, in all seriousness, the IAC thing is great news for indie developers. The web is the best opportunity we have to put our games in peoples' hands, and most of the big portals are pretty skittish about requiring a 3D card right now. Creating a marketplace of people who are all prepared to play games that are more rich, more complex, and take better advantage of what their machines are capable of is a brilliant idea and I look forward to seeing how IA shapes up!
Anyway, I figured now is as good a time as any to post the obligatory post-mortem while I take a brief respite to catch my breath.
Interestingly, this is not my first game. My first game is still in the works, but has taken a bit of a back seat to When Orcs Attack for strategic reasons. Look for Harmonic Convergence to be released soon though.
I suppose I should break this into several pieces: The plan, what went right, what went wrong, and what's next. It's way too early for "conclusions".
The Plan
An entrepreneurial friend of mine laid the seed of what seemed to both of us to be a brilliant idea at the time and I, having wanted to get into game development for a while dove in head first. Ultimately I chose to go it alone; I decided to take almost everything I have and go all-in. From the standpoint of my development as an entrepreneur this was critical. Nothing is quite as effective at encouraging learning and reinforcing lessons as feeling the pain of having your own money -- your own future -- on the line. This is what I have come to refer to as the fear of being Homeless On The Street Giving Handjobs For Crack (apologies to Matt Stone and Trey Parker).
The idea is breathtakingly ambitious in scope, and I had never shipped even a trivial game before. That led to The Plan. The Plan was, and is, to develop the game incrementally. To build four separate games each getting me part of the way to my goal in terms of technology and art assets and allowing me to test assumptions about gameplay and business models along the way.
I decided that I would take precisely three months to develop each game, and scope the games to fit in that time. I would need myself, one more engineer, and an artist plus a little miscellaneous contractor time. Each game would start with a basic concept for the gameplay, and then become whatever I could cram in within 3 months.
To make certain that I would hit the 3 month deadline, I set a deadline two weeks earlier -- 9/1, and aimed hard at that. Sure enough, I missed it.
This has meant I've had to do things a bit differently than the usual project management route. Having a design document is a useful tool in most cases but here it would have just been utter BS. Having never shipped a game before, I cannot say what features are "hard" or what features are "easy". Committing myself to any particular feature becomes a huge risk when I have a very very short window of time and virtually no slack in terms of resources. Instead, I relied on the innate pressures of the situation to guide me in the right direction. For example, it was clear that the more time I had to tweak and polish the gameplay, the better the game I would deliver. This created pressure to get things to a playable state as early as possible. Having only three months ensures that the game must be fairly simple that it not wind up being layered with needless complexity that will only appeal to hardcore gamers at the cost of making it less accessible to my target audience.
Features thus fell into three important categories:
1) Features that must be there in order to ship: These are things that are simply fundamental to the style of game. For WOA, the big one here was A* pathfinding.
2) Features that seem easy to implement: A list prioritized to maximize the fun-factor and replay value while minimizing the amount of time/energy/cost of implementation.
3) Nice-to-have features: In other words, features that just won't make it in.
The trick to making an approach like this work is keeping list #1 as small as possible, and learning to jettison things from list #2 very very quickly if they aren't as easy as you hoped. If you become attached to something that turns out to be hard to implement, you will miss your deadline.
Having come from the world of analytics, this was actually a pretty easy approach for me to take. I've learned a lot about identifying and questioning assumptions. When a game designer from a certain notable studio saw an early prototype of my game and said "their feet are sliding, you'll never sell a game without inverse kinematics" I just pointed out that my audience probably doesn't care about that and if they do I'll find out about it real quick once the game ships, and add it into the next game.
A good example of keeping list #2 under control was foliage. I had a great little foliage system in place that let me put 40 trees and half a dozen rocks on screen with only a small framerate hit on my machine (about 12fps off the 60fps I was getting) but it became instantly apparent that much more work would be required to make things playable on my minspec: It turns out GMA950 is extremely vertex bound, and increasing the vertex count 21x by adding foliage just wasn't gonna fly. So, it moved from list #2 to list #3.
A further key to my plan was having the right tools and the right people. The tool choice wound up being a very short list: The game must be web based, ideally with the possibility of a download version as well, and I wanted it to be 3D for a variety of reasons. My options ultimately came down to jMonkeyEngine and Unity. I chose the latter for the much much smoother art pipeline and prepared a fallback plan for what to do if plugin adoption became a critical bottleneck. Always always ALWAYS have a fallback plan for everything. If you don't have a fallback plan for something, THAT will be the thing that falls through.
As for the people, that's a more complicated -- and far more important -- question. It wasn't enough that they be good. It wasn't enough that they be economical. Their skills had to complement mine, and we had to be able to work together effectively. Basically they needed to be good at everything I'm bad at (an awful long list) and patient enough to not kill me along the way. I went with Magnus Blikstad for the artwork, John Seguin for the sound and music, and I'm still looking for an engineer. That's not to say that the other contributors weren't critical to making the game happen -- they absolutely were; they just didn't have to put up with me for three straight months. Gareth Morgan did in a day what would've taken me at least two weeks on my own. Tom Long made it possible for me to ship my game despite the fact that I got Magnus going way too late in the project and there was simply too much for him to get done in the time allotted.
What Went Right
The people. I have been awe-struck at the results the people I've worked with have produced. I throw them the most frustrating curve-balls, often due to my poor project management skills, and they simply adapt. The plan for game 1 was just on the wrong side of crazy and they made it happen.
The tools. Not having to drop into C++ was crucial for me, especially without a more skilled engineer on board. Being able to use Mono instead of a slow and/or limited script language, or C++ was a HUGE win. Having a smooth art pipeline was even more important. Magnus gave me source art that would lead to a 105MB download version of the game if I used it as-is. Getting this into a 5MB web player would have been a challenge if I had to go into Gimp and resize textures by hand. Unity's ability to control import sizes for textures, adjust mip-mapping, auto-generate normal maps, control what type of compression is used for textures, and so forth with just a couple clicks made it possible for me to carefully tweak and adjust and control where I wanted to sacrifice space for visual quality and where I could get away with trimming things down a notch. As a result of this, the web player hovered in the 4-7MB range throughout the entire development process.
What Went Wrong
The people. The engineers I wanted to hire didn't work out for a variety of reasons (!@#$%^&* immigration policy!!!), so I was left on my own to do business administration, business development, AND coding. I did not get a lot of sleep.
The tools. As amazingly productive as Unity has been, it definitely wasn't problem-free. This was mostly due to it being a beta. I hit a critical show-stopper problem with particle effects where the only effective workaround I could find was "don't use them". This ultimately turned out to be a bug in Mono, but I lost roughly a week to fighting that issue alone. OpenAL wasn't terribly cooperative either. The nature of the game is such that there's a huge variance in polyphony. There may be one or two towers and a handful of enemies or there may be dozens of towers and dozens of enemies. Even if OpenAL hadn't been buggy, this would have quickly become indistinguishable noise. Unfortunately that was made worse by OpenAL trashing heap when it got overloaded. This led to a rather last-minute effort to make a sound manager that would give me explicit control over polyphony so I could "fake" things. Sound effects DO get louder as the number of things that want to play them increases but they do so at a much slower rate than they would if those things each simply called Play() independently, and there's a cap on how MUCH louder they can get. I lost positional audio as a side effect but that's not critical for this game.
On top of the technical hitches, my ignorance of the realities of 3D development made things quite challenging at times. I added point lights to many of the projectiles only to discover that things came to a screeching halt on my relatively high end video card (GeForce 8600M -- laptop card, but much higher end than my target minspec). Turns out that having a few dozen lights casting shadows against a few dozen enemies does terrible terrible things like increase the number of draw calls from ~400 to about ~6,500. *ahem*
QA. I didn't devote nearly enough time to this. I assumed, wrongly, that because the game was very simple and limited in scope that I could do this on the fly. Three point releases in 24 hours were the net result of that. Oops.
What's Next
I'm spending the next two weeks doing the business administration and business development tasks that I should've taken care of along the way and then I dive into game 2. Along the way I'm hoping to hire an engineer (send me a resume if you're interested!). I've got about 4 different distribution opportunities to follow up on, and I need to dig up as many more as I can!
So game 2 starts development on 9/30, with the goal being completion on 12/15 and a hard deadline of 12/30.
I AM CODER, HEAR ME ROAR! *SQUEEK*
Releasing a game has been a bit like this for me.
As of 9/16/2007, I join the ranks of those who have published a game. That date is 3 months to the day since I left my day job to focus exclusively on MrJoy, and naturally I get upstaged by much bigger news. Darn your black heart Josh William!!! Actually, in all seriousness, the IAC thing is great news for indie developers. The web is the best opportunity we have to put our games in peoples' hands, and most of the big portals are pretty skittish about requiring a 3D card right now. Creating a marketplace of people who are all prepared to play games that are more rich, more complex, and take better advantage of what their machines are capable of is a brilliant idea and I look forward to seeing how IA shapes up!
Anyway, I figured now is as good a time as any to post the obligatory post-mortem while I take a brief respite to catch my breath.
Interestingly, this is not my first game. My first game is still in the works, but has taken a bit of a back seat to When Orcs Attack for strategic reasons. Look for Harmonic Convergence to be released soon though.
I suppose I should break this into several pieces: The plan, what went right, what went wrong, and what's next. It's way too early for "conclusions".
The Plan
An entrepreneurial friend of mine laid the seed of what seemed to both of us to be a brilliant idea at the time and I, having wanted to get into game development for a while dove in head first. Ultimately I chose to go it alone; I decided to take almost everything I have and go all-in. From the standpoint of my development as an entrepreneur this was critical. Nothing is quite as effective at encouraging learning and reinforcing lessons as feeling the pain of having your own money -- your own future -- on the line. This is what I have come to refer to as the fear of being Homeless On The Street Giving Handjobs For Crack (apologies to Matt Stone and Trey Parker).
The idea is breathtakingly ambitious in scope, and I had never shipped even a trivial game before. That led to The Plan. The Plan was, and is, to develop the game incrementally. To build four separate games each getting me part of the way to my goal in terms of technology and art assets and allowing me to test assumptions about gameplay and business models along the way.
I decided that I would take precisely three months to develop each game, and scope the games to fit in that time. I would need myself, one more engineer, and an artist plus a little miscellaneous contractor time. Each game would start with a basic concept for the gameplay, and then become whatever I could cram in within 3 months.
To make certain that I would hit the 3 month deadline, I set a deadline two weeks earlier -- 9/1, and aimed hard at that. Sure enough, I missed it.
This has meant I've had to do things a bit differently than the usual project management route. Having a design document is a useful tool in most cases but here it would have just been utter BS. Having never shipped a game before, I cannot say what features are "hard" or what features are "easy". Committing myself to any particular feature becomes a huge risk when I have a very very short window of time and virtually no slack in terms of resources. Instead, I relied on the innate pressures of the situation to guide me in the right direction. For example, it was clear that the more time I had to tweak and polish the gameplay, the better the game I would deliver. This created pressure to get things to a playable state as early as possible. Having only three months ensures that the game must be fairly simple that it not wind up being layered with needless complexity that will only appeal to hardcore gamers at the cost of making it less accessible to my target audience.
Features thus fell into three important categories:
1) Features that must be there in order to ship: These are things that are simply fundamental to the style of game. For WOA, the big one here was A* pathfinding.
2) Features that seem easy to implement: A list prioritized to maximize the fun-factor and replay value while minimizing the amount of time/energy/cost of implementation.
3) Nice-to-have features: In other words, features that just won't make it in.
The trick to making an approach like this work is keeping list #1 as small as possible, and learning to jettison things from list #2 very very quickly if they aren't as easy as you hoped. If you become attached to something that turns out to be hard to implement, you will miss your deadline.
Having come from the world of analytics, this was actually a pretty easy approach for me to take. I've learned a lot about identifying and questioning assumptions. When a game designer from a certain notable studio saw an early prototype of my game and said "their feet are sliding, you'll never sell a game without inverse kinematics" I just pointed out that my audience probably doesn't care about that and if they do I'll find out about it real quick once the game ships, and add it into the next game.
A good example of keeping list #2 under control was foliage. I had a great little foliage system in place that let me put 40 trees and half a dozen rocks on screen with only a small framerate hit on my machine (about 12fps off the 60fps I was getting) but it became instantly apparent that much more work would be required to make things playable on my minspec: It turns out GMA950 is extremely vertex bound, and increasing the vertex count 21x by adding foliage just wasn't gonna fly. So, it moved from list #2 to list #3.
A further key to my plan was having the right tools and the right people. The tool choice wound up being a very short list: The game must be web based, ideally with the possibility of a download version as well, and I wanted it to be 3D for a variety of reasons. My options ultimately came down to jMonkeyEngine and Unity. I chose the latter for the much much smoother art pipeline and prepared a fallback plan for what to do if plugin adoption became a critical bottleneck. Always always ALWAYS have a fallback plan for everything. If you don't have a fallback plan for something, THAT will be the thing that falls through.
As for the people, that's a more complicated -- and far more important -- question. It wasn't enough that they be good. It wasn't enough that they be economical. Their skills had to complement mine, and we had to be able to work together effectively. Basically they needed to be good at everything I'm bad at (an awful long list) and patient enough to not kill me along the way. I went with Magnus Blikstad for the artwork, John Seguin for the sound and music, and I'm still looking for an engineer. That's not to say that the other contributors weren't critical to making the game happen -- they absolutely were; they just didn't have to put up with me for three straight months. Gareth Morgan did in a day what would've taken me at least two weeks on my own. Tom Long made it possible for me to ship my game despite the fact that I got Magnus going way too late in the project and there was simply too much for him to get done in the time allotted.
What Went Right
The people. I have been awe-struck at the results the people I've worked with have produced. I throw them the most frustrating curve-balls, often due to my poor project management skills, and they simply adapt. The plan for game 1 was just on the wrong side of crazy and they made it happen.
The tools. Not having to drop into C++ was crucial for me, especially without a more skilled engineer on board. Being able to use Mono instead of a slow and/or limited script language, or C++ was a HUGE win. Having a smooth art pipeline was even more important. Magnus gave me source art that would lead to a 105MB download version of the game if I used it as-is. Getting this into a 5MB web player would have been a challenge if I had to go into Gimp and resize textures by hand. Unity's ability to control import sizes for textures, adjust mip-mapping, auto-generate normal maps, control what type of compression is used for textures, and so forth with just a couple clicks made it possible for me to carefully tweak and adjust and control where I wanted to sacrifice space for visual quality and where I could get away with trimming things down a notch. As a result of this, the web player hovered in the 4-7MB range throughout the entire development process.
What Went Wrong
The people. The engineers I wanted to hire didn't work out for a variety of reasons (!@#$%^&* immigration policy!!!), so I was left on my own to do business administration, business development, AND coding. I did not get a lot of sleep.
The tools. As amazingly productive as Unity has been, it definitely wasn't problem-free. This was mostly due to it being a beta. I hit a critical show-stopper problem with particle effects where the only effective workaround I could find was "don't use them". This ultimately turned out to be a bug in Mono, but I lost roughly a week to fighting that issue alone. OpenAL wasn't terribly cooperative either. The nature of the game is such that there's a huge variance in polyphony. There may be one or two towers and a handful of enemies or there may be dozens of towers and dozens of enemies. Even if OpenAL hadn't been buggy, this would have quickly become indistinguishable noise. Unfortunately that was made worse by OpenAL trashing heap when it got overloaded. This led to a rather last-minute effort to make a sound manager that would give me explicit control over polyphony so I could "fake" things. Sound effects DO get louder as the number of things that want to play them increases but they do so at a much slower rate than they would if those things each simply called Play() independently, and there's a cap on how MUCH louder they can get. I lost positional audio as a side effect but that's not critical for this game.
On top of the technical hitches, my ignorance of the realities of 3D development made things quite challenging at times. I added point lights to many of the projectiles only to discover that things came to a screeching halt on my relatively high end video card (GeForce 8600M -- laptop card, but much higher end than my target minspec). Turns out that having a few dozen lights casting shadows against a few dozen enemies does terrible terrible things like increase the number of draw calls from ~400 to about ~6,500. *ahem*
QA. I didn't devote nearly enough time to this. I assumed, wrongly, that because the game was very simple and limited in scope that I could do this on the fly. Three point releases in 24 hours were the net result of that. Oops.
What's Next
I'm spending the next two weeks doing the business administration and business development tasks that I should've taken care of along the way and then I dive into game 2. Along the way I'm hoping to hire an engineer (send me a resume if you're interested!). I've got about 4 different distribution opportunities to follow up on, and I need to dig up as many more as I can!
So game 2 starts development on 9/30, with the goal being completion on 12/15 and a hard deadline of 12/30.
I AM CODER, HEAR ME ROAR! *SQUEEK*
#2
No screenshots or pictures of you dying at the computer?
Actually, awesome work and write-up! Good luck with the next one!
09/20/2007 (1:55 am)
I'm disappointed.No screenshots or pictures of you dying at the computer?
Actually, awesome work and write-up! Good luck with the next one!
#4
09/20/2007 (2:14 am)
That'll do, sir, that'll do. 
#5
good job.. :)
TomFeni
09/20/2007 (4:40 am)
you should look at spending some of that hard earned dough on a new razor :)good job.. :)
TomFeni
#6
The second one will be easier!
Christophe
09/20/2007 (7:08 am)
once again, congratulation for released your first game.The second one will be easier!
Christophe
#7
The unity texture import sounds like a neat idea. Having just one high quality version of your artwork with the ability to easily re-target a distribution size could be a real time saver.
09/20/2007 (11:02 am)
Congratulations, and a nice post-mortem to boot, although a bit more eye-candy to break the text up wouldn't have gone amiss :)The unity texture import sounds like a neat idea. Having just one high quality version of your artwork with the ability to easily re-target a distribution size could be a real time saver.
#8
09/20/2007 (4:56 pm)
Congrats, a really nice blog. It's also nice to see someone who has used Unity to complete a game. I've always been impressed with it. 
Associate Paul Dana