Games   

   Candy Cruncher   
   Fruit Frolic   
   Letter Linker   
   NingPo MahJong   
News   
   Latest News   
   Archive   
Services   
   Artwork   
   Programming   
Support   
   Lost Your Code?   
   Support Main   
   Message Forums   
About   
   Dev's Diary   
   Contact   
   Bios   
   Jobs   
   About Us   
   Links   
 
 

 

2/6/2002 -- Being an Indie Developer Doesn't Always Suck

It's no big secret that Pyrogon is a small developer. We have two full time “employees”, living off savings, and we have a couple contractors that do the odd porting work for us. We're a far cry from the teams you might see at big companies such as Electronic Arts or Sony On-line.

While being small and under-funded does kind of suck at times, it has its advantages. For example, we can work on whatever the hell we feel like. We don't have to worry about appeasing a publisher or senior manager that has their own idea of what's “hot”. And because we're small, we don't have to sell nearly as many copies of something in order to break even. If we ever sold ten thousand copies of anything, we'd be dancing little jigs of joy in the streets of Rancho Bernardo.

Point being: if we want to do a puzzle game, we'll write a puzzle game. If we want to do an MMOG, well, we'll write an MMOG.

Oh, wait. That seems stupid. Teams of thirty people are having problems shipping MMOGs after three or more years of development, so how is a self-funded team of two people supposed to make a cool, on-line game in less time?

First, a little background – Rosie and I are neither naïve nor ignorant of the perils that commercial game development encounters. I've worked on some fairly successful titles, and Rosie was the art director on Everquest, so she's not exactly clueless about this kind of thing either.

Second – and this is the key – is that there's a big secret that publishers and developers don't want you to know about: writing games is easy. Seriously. Sitting down and developing a game really isn't that difficult. Writing code, making art, designing stuff, no big deal.

It's the mundane crap that kicks a game's ass. While it's nice to think that most of a game's development time is spent making cool art, lots of content and mind-boggling technology, that's just not the cold reality of it.

Most of the time spent making a game is wasted, no two ways about it. Mismanagement, aimless wandering, lack of vision, making pointless milestone demos or, sadly enough, just screwing off, all contribute to the alarming delays we see in games. But developers whitewash this aspect of the development process because they can't martyr themselves nearly as effectively when their 90 hours “at work” last week were spent...playing Dark Ages of Camelot.

Entire days, weeks and months can be spent arguing about game design, system requirements, technology, box art, operating systems, and whether the company you work for is screwed up because they don't provide free bagels anymore. For every hour some programmer claims he spent “working late at night”, you can go ahead and assume he spent another two hours playing Everquest, M:TG or hanging out in IRC/cruising Web forums.

So now that the cat's out of the bag, how does it help us? Rosie and I don't work long hours, primarily because we don't feel a need to compensate for screwing off all day long. In addition, we spend close to zero percent of our time arguing about “stuff”. When we want to do something, we just do it. We don't call a meeting and run it by a staff of twenty people, reach consensus, then get the idea shot down by someone above us. If we don't want to implement a feature, we don't do it. We don't have feature requests shoved down our throats by a manager two layers above the product. We don't have to make a cost justification for porting to the Macintosh or Linux or PocketPC, we can just do it because it's cool.

Having only two people working on a project greatly reduces the inefficiency of “decision friction”, which basically affects any project with more than one person – it just gets worse the more people you have on a project.

Stellar Deep, our on-line science fiction RPG, benefits from this lack of decision friction. We can implement features and ideas very quickly, and we can avoid implementing stuff just because someone else is doing it. Because we have such a low headcount, we don't have to make a game that will sell 100K copies or have at least 50K subscribers to break even.

Because we have a certain degree of self-determination, Stellar Deep can be a much simpler game than something that would cost $49.95 at retail and that would be expected to use the latest and greatest pixel and vertex shader doo hickeys in the latest graphics cards. In other words, we can compete on gameplay – not number of CDs and graphics gee whiz effects.

In addition to concentrating on gameplay, we're going to architect things from the ground up so that we don't have to have a staff of forty artists cranking out every pixel for the world. We'll design broad swaths of the universe, such as the races, home worlds, and basic equipment, but we'll use procedural generation to fill in the blanks. Because maintaining a minimal download size is also important, procedural generation helps us out quite a bit by removing the requirement of a CD distribution or, even worse, a 600MB download.

We know this can be done, because we've seen other companies doing it – companies like Ambrosia Software, Pangaea and StarDock have made great games that do well without competing on technology and content size. They concentrate on making things fun, not huge. But on-line? Sure -- there is a small but successful industry of text MUDS (the inspiration for games like UO and Everquest) run by two or three people. We're modeling Stellar Deep more as a "text MUD with graphics" than "Earth and Beyond made by two people". The latter is insane, the former makes a lot of sense.

Finally, we're going to release the game in pieces. I hesitate to call it “episodic”, because that implies that you're seeing episodes in a story. For Stellar Deep we're going to add functionality every month or two. The first release might be real simple and sparse, but each new release should add a major feature. For example, the initial release may not have trade skills, but the second or third update may add that system. Some players will balk at this on the grounds that they're paying for an unfinished game – and that's a completely valid stance. But what we hope to do is find gamers that are really into this game genre, and as we build the game we'll take their suggestions and try to make Stellar Deep into something that its hardcore following will just love. They'll have a sense of belonging that would be difficult to achieve just by being in the universe – they will have participated in its construction as well.

So being an independent gaming company isn't quite as horrible as some people might imagine. Sure, lack of steady income is always something to be concerned about, but getting to make any game you want is worth a lot, especially when you're a developer that's already had a hand in many successful titles. 

Next Installment: The Whys and Hows of Porting Software

 

Copyright © 2002 Pyrogon, Inc. Site by John Krane. All rights reserved.