Failing to Finish, or Failing to Start?
Just finished reading GBGames’ latest blog entry, Facing Reality. In it, he speaks about his guilt for once again having nothing to enter into the IGF, and in general laments the fact that he’s accomplished so much less than he expected in regards to indie gamedev (though he has gotten a real, full-time job in gamedev, so he’s obviously been doing something right).
I see myself in a similar situation. I’ve been a judge for the IGF for the last four years, and will be returning as one again this year. Every year I have told myself, “next year I will submit something.” And each year passes with nothing to show.
I call myself a “game developer” or “game programmer” because that’s what I do professionally, and it’s what I pretend to do as a hobby. In fact, professionally, I don’t spend any time developing games. I work on game technology (RenderWare, et al). But I don’t even develop technology, I support it. So, in reality, I’m a “game technology debugger,” practically nothing more than a post-release QA specialist. Sure, I’ve got a spiffy title (Solution Architect), but that just reveals that I do even less programming and more planning, which just serves to move me ever further from actually making games!
So, while GBGames is lamenting his inability to finish a game, I find myself reminded of how I have utterly failed to start one.
In fact, I used to be more in GBGames’ shoes… I started many a game that never was finished. And much like GBGames, what I really was doing was starting a game engine, not a game. I think this is a problem affecting the majority of our community, i.e. indie gamedev, amateur gamedev, hobbyists, etc. In a community largely dominated and driven by programmers the goals (and their solutions) are often framed in terms of technology. I guess it’s simply a matter of having a hammer and seeing only nails.
I’ve tried to break myself from this technology focus as evidenced by my recent forays into Flash and Game Maker. I’ve forced myself to step away from the 3D that I stare at all day (and arguably have the most expertise in) and limit myself to 2D technology. Even before then, I accepted the fact that I personally was not going to be crafting the next Doom or Source engine, so why participate in that age old arms race? I’ve also long accepted (and been very vocal about) the fact that technology really means zilch at the end of the day if the game isn’t finished. In other words, I am more impressed by a finished game running at 5fps than a tech demo running at 60fps.
Like GBGames, we all underestimate the time requirements. He’s made a huge step forward by tracking his personal time with the detail of a professional game producer. At first glance, the 170 hours devoted to his personal gamedev project sounds like an admirable accomplishment. “If only I had devoted that much time to my projects…” But when you break the numbers down, it works out to a little over 3 hours a week. In other words, it’s very likely that myself (and most others) are already spending that much time on this hobby of ours (if not much, much more, for those without family obligations — I’m looking at you, students!). Besides, many decent titles have come out of less time than that, and given the out-of-the-box tech we have to leverage these days, many “classic” titles could be recreated in that amount of time.
One comment in particular hits the nail on the head: “the biggest issue is you’re still working on an engine, not a game.” Programming is hard enough when the end result is an executable that someone runs. Programming is even harder when the end result is something you have to turn around and use to do more programming. Most people who call themselves “game developers” or even “game programmers” are neither; they are “game technologists.” If you pick up a book on gamedev, 9 times out of 10 the end result after completing the entire book and working through all of the sample projects is a half-assed 3D game engine that would have been crap 5 years ago and will always look crap. While this may be an accurate representation of the work of many in the professional game development circles, it certainly does not represent the ideal (or even the good).
In my book, if you’re working on a game engine you’ve not yet started making a game. You’re making middleware. And, as someone who has had their bread buttered by the middleware industry for the last five years, I can say that’s there’s absolutely nothing wrong with making middleware. It’s needed, by everyone in the game industry, and by everyone in the indie scene, and there needs to be more of it. But, don’t tell yourself that you’re making a game — at least not yet — or you’re simply going to be disappointed.
A few days ago, EA announced that they were adopting Unreal Engine 3.0 for several titles. Now, that is someone wanting to make a game and not wanting to make game technology. It’s the best decision they could have made, and honestly, they probably should have made it a year ago (or two). If you’re making a shooter (first- or third-person, the tech is essentially the same these days), you should not be writing the tech. You should be using Source, Unreal or Crysis. They’re all cutting edge, and they’re all better than anything your team will be able to produce given any amount of time. The same goes for indies: go out and grab Torque, or Ogre3D, or CrystalSpace, or whatever… there are plenty of groups whose only goal is to produce game tech. If your goal is to make a game, then don’t make tech.
I’m tired of tech. I tired of fighting it. I’m tired of writing it. I’m tired of debugging it. I’m tired of finishing a piece of tech and having no actual finished product because all I did was build a better hammer (or more likely, a worse one that only works on brass nails and not steel ones, and no, it can’t pull nails out, only hammer them in). I’m tired of failing to finish my tech when all I’m really doing is failing to start my game.
[...] Isso me fez lembrar um artigo excelente que li no blog do Troy Gilbert, desenvolvedor da EA Games, chamado Failing to finish or failing to start?. Ele diz que a maioria dos produtores independentes não conclui seus projetos porque passam a maior parte do tempo escrevendo tecnologia para criar jogos e não os jogos propriamente ditos. Se o XNA cumprir o que promete vejo que pequenos grupos de 3 ou 4 pessoas poderão escrever jogos casuais para Windows com uma facilidade que não existia antes. [...]
[...] Isso me fez lembrar um artigo excelente que li no blog do Troy Gilbert, desenvolvedor da EA Games, chamado Failing to finish or failing to start?. Ele diz que a maioria dos produtores independentes não conclui seus projetos porque passam a maior parte do tempo escrevendo tecnologia para criar jogos e não os jogos propriamente ditos. Se o XNA cumprir o que promete vejo que pequenos grupos de 3 ou 4 pessoas poderão escrever jogos casuais para Windows com uma facilidade que não existia antes. [...]