The truth behind game development
2007, December 20th 11:32 AM
I've had a few people ask me why this journal spends so much time talking about minutae of business (like server setup and mailing lists) and so little about, you know, actually writing games.
This journal is fundamentally about starting a game studio. Sometimes that's game design. Sometimes that's coding. Lately, it's been about setting up a server and getting some people reading this journal (yes, this one that you're reading right here) so that people actually play the game when it comes out.
So that's what I've been doing lately. The server's working and (finally) is requiring no tweaking. The mailing list is up and works as well. And now, I even have a company logo. It's a lot of small things, but it's small things that have to get done, and nobody is going to do them besides me. The next step, from a non-coding perspective, is PR – and I'm going to have a lot to say about that as well, because PR is a horrible pit of morality issues.
The reason I haven't been posting about what I've been coding is rather complicated and entirely uninteresting. I've been on a vacation for the last week, and now we're moving into the holidays, and so I haven't been getting as much work done as usual. On top of that, I've been coding things which are about as dull as it gets – interfaces. And not even interesting interfaces. For example, now you can hit Escape and get a popup menu allowing you to quit the game, return to the main menu, or change the resolution. Necessary? Absolutely. Interesting? Not in the least.
Unfortunately I've got a lot more uninteresting before I can get back to the interesting. What I'm trying to do is release a stripped-down demo version of the game for all to enjoy (and, for those of you who don't run Windows, I'm hoping to do a Windows/OSX/Linux cross-release. We'll see how well this works.) The game right now suffers from a few major flaws, however, such as essentially requiring someone who's played before to navigate the menus. This is pretty bad. It works great when your goal is "make sure the gameplay is fun and balance things", but it needs to be fixed, and it needs to be fixed now.
I'd love for game development to consist entirely of designing giant guns and aliens and making explosions look awesome. Unfortunately, that's just not the case, and I've got a long, long slog before I can get back to that.
Ming
2008, January 16th 2:18 PMHaving started a game studio, and having been in the game industry for a decade and a half, I can tell you that starting a game studio has quite a lot of business detail to take care of. Even as you get larger, to the size of EA, the business stuff arguably becomes larger than the development issues.
However, for a small studio, this should not be the case. Although you may be grinding valuable business XP, you might want to re-examine your priorities if you want to put out a game. There are several hidden costs to not hiring expert people to take care of things such as server issues, PR, web design, and yes, even programming and *designing* interfaces.
One large hidden cost is the quality of the game suffers when the primary creators are distracted from the job of creating the game to the job of maintaining the business. Game quality largely resolves around how quickly and easily you can turn around changes. Consider this the "inner loop" of game development. Like all critical routines that need to be fast, you focus your software and engineering talent on tightening this inner loop so that content creators can make as many polishing passes as possible in a small amount of time.
Parts of the game that are largely not core gameplay can have their non-inner-loops outsourced or otherwise created less efficiently. These include shell screens, interface screens, interface code, localization issues, and screen resolution issues. While these must be in the game, they are not critical to whether the game is fun or not. So, in general, it makes sense to create these at a slower pace, in parallel with the actual game development.
A second hidden cost is the constantly moving window of progress. You don't see it, because you are isolated, but you have competitors. In the case of the IGF, I have seen the quality of student works improve dramatically year after year. The collaboration efforts and free-source engines available keep improving. As this progress increases, you run the risk of your project becoming *trivialized* because you are building so much of it yourself, rather than in collaboration. For example, a game with the complexity of Breakout might have taken a team of 3, a full 9 months when it was first invented, simply because the tools did not exist to create a novel game. However, our gamesmithing group could probably whip it together on our spare time over a couple of weekends.
A third consideration is that arguably your strength, the very uniqueness of your tools and approach, will be a barrier when you try to attract a publisher. The reason for this is that you will need to hire a full team in order to complete your game. Already, you are coming up against several inefficiencies— the interface could have been designed before it was implemented, thus saving YOU, the critical bottleneck, lots of rework time. Eventually, you will want a designer to save you this kind of time. And then you will want artists. And maybe another programmer. Or two. Or four.
However, hiring professional game development talent will be difficult if your suite of tools is unique and you are the principal architect and programmer. The reason for this is that young game developers will want to work on professional tools that are commonly used in the industry in order to improve their skills and resumes— they are grinding XPs for skillsets they can use in other companies. A unique development environment doesn't help that goal. Secondly, expert developers are likely to already have tools and skills that they have developed using standard industry programs and tools. They will not want to learn anything new, and would not want to work on something that is less efficient than the approach that they're used to.
A fourth and final consideration, perhaps the most insidious, is personal opportunity cost. Although you may have a wealth of time, money, and enthusiasm now, that does not mean that you will still have enough of all three to do this another time. For me, personally, my enthusiasm on a project erodes with time. There is a time window in which I will be interested in a project, and beyond that window, I will lose interest unless there is significant progress. I must commend you for having stuck through this for even this long since to me, it seems like things are moving at a glacial pace.
Anyway, I am just offering my insights into the development of your game studio. You have a great opportunity here— one that many of us don't have since we lack some of the critical elements (time, money, or enthusiasm/attention span). So I'm just outlining some dangers so that you have a better chance of success.
I wish you all the luck in the world. But keep in mind that actions or inactions can bring about that luck or cancel it all the same.
-Ming