In support of Steam

I'll admit it; I'm a Mac guy in exile. I've used Macs for many years, enjoyed their interface and OS hooks, and generally respected their designs. However, I'm also a primary Windows user and Debian fan. I use the Mac because I don't have to think about the interface, I use Windows because everything is written for windows, and I use Debian for Apt-Get. Combining these three things would be gaming nirvana.

If you're new to Debian (or other Linux Distros like Mandrake which include the functionality), Apt-Get is a way to download and install any free software you may want. If someone sends you an office document, you can type "apt-get install abiword" to read it. Need e-mail? "Apt-get install kmail". Nearly any open-source free application that you can get for Linux can be found, downloaded, and installed, with all dependencies automatically resolved, with a single line. Does kmail require KDE, which requires QT, which requires 100 other things? Don't worry; all such dependencies are automatically (and invisibly) resolved. Basically every piece of software written for the platform is available in a format that is so trivially easy to use it puts the Mac to shame. And all of this because the software is free. Right?

Or is it? Despite what most people think, the reason why you can download and install anything you like on Debian is not because it is free, but because it is software. There is nothing to physically move. Furthermore, it is completely integrated within the environment. Any software you might want is already cataloged. If any piece of software needs another piece of software, it can ask apt-get to get it for them. It is that fingertip accessibility where the power comes from. That it is free is secondary.

Modern cell phones have a similar system to apt-get, but without free software. If you want a game on a cellular phone, you go to the games menu of your phone and click "Get new game." The game is purchased, downloaded, and installed. No trip to the store required, no box, no messy shareware registrations. If the cell-phone user has a craving to play Tetris, they can satisfy that craving right then and there.

This "impulse buy" is a powerful force in sales and marketing. How can you sell a game to a person who has just one hour to play a game, if driving to the nearest game boutique and back would take up two hours? You could sell in Target and other nearby superstores, a generally successful strategy. But by selling directly in their hardware, you can reduce travel time to 0 and lower the cost of entry a lot more than by just lowering the price. How can you expand that advantage to be system-wide on Windows?

As I see it, the primary way to do this would be to have Steam gain such, if you'll excuse the expression, steam that they become a potential threat in publishing. This should be enough to rouse Microsoft into either licensing steam for Windows, or releasing their own version. Let's look at this possibility.

1. Valve should partner with OEM sellers to get Steam put on all new computers. They will have to offer one of their back titles in exchange for this, but it would be a good use of Half Life 1 or Day of Defeat. Most OEM's would jump at the opportunity to get another game on their machines for free, and judging by the amount of AOL slimeware most machines ship with they won't mind the phoning home parts of steam one bit. Valve gets a real platform from which to sell their wares directly to the consumer, the OEM manufacturers get a free selling bullet point.

2. Once on OEM machines, Valve should transition to or spin off an online retail division. This division would work with publishers for a small cut to sell to the public. Valve handles any sales problems, publishers handle technical difficulties. Ten dollars per sale should handle the technical side of things, and should leave the publishers with a lot more profit than in the traditional model. Cut the overthrow-the-publishers attitude that Steam currently embodies and promote it to publishers as a replacement for retail stores. Get more and more of them onboard as an alternative distribution method, while they remain firmly in creative and financial control.

3. Provide enough congregated content to draw players back into steam. Demos would be automagically downloaded and awaiting any player who many want to try one (with games being available to purchase, of course). Promote Steam to end users as a doorway application to a gaming world, similar to an internet browser but more fun.

4. Spin off a division to release a Mac version. Apple frequently buys up developers of promising applications, and an iStore would fit their corporate philosophy pretty well. Promote it to them, try to sell them on the idea of partnering with Steam, show them the games that have been released through Steam on the PC, and imply that a well-supported centralized location for buying games and software on the MAC would go a long way to combating the image that there aren't any games or software for the MAC.

5. With Apple about to be in your cap, it is time to go to Microsoft and attempt to get either bought or partnered. If you've played your cards right up until this point, you won't really need Microsoft's help. However, the point is to be beneficial to the platform, so contact them anyway. Point out the other computer systems that benefit from similar distribution systems, and offer them a good cut of profits... it will pay off in the long run. Imply that the technology could do wonders for the Xbox 360, or could be the perfect distribution system for the following generation of system. By this time you should have a ton of ammunition with which to sell yourself, so sell like mad.

With all of the above steps, Steam (or a steam-like application) could have a tremendous influence on the future of the OS, creating an alternative revenue stream for products which could quickly become the primary one. In other words, more games could get into the hands of consumers quickly, which should make everyone in the industry sleep a little easier.

The 6 Indie mistakes

If you spend much time in this industry, you start to see patterns. I was browsing around the David Perry designer forums, and came across quite a few interesting people and designs. One particular one caught my eye, though. It sounded interesting. It sounded exciting. It sounded like an epic so grand it would put Cleopatra to shame. And it sounded utterly, utterly impossible to make. I won’t single out the budding designer here for ridicule, but he had created a story so grand, a world so rich, that it would take a team of thousands several years to create. He, of course, had only himself, and no idea what to do to start.

This will not be an article on how to make games. Nobody knows how to make games… being in the game industry has made that abundantly clear. This will be an article on how to fail to make a game. Or, rather, the 6 most common reasons why people who are about to embark on the great journey for the first time fall flat on their face with their first step. While these may contain the extremes of archetypes, chances are they all, in one way or another, apply to your project.

1: “I’m going to make an RPG with 3,000 enemy types, real-time combat, and a first-person shooter mode. And dancing, lots of dancing.”

You have 2 designers, one coder, and a part time artist. You have the staff, in other words, to make Tetris. Be realistic about how much you can accomplish. Take your most basic game ideas, and make them smaller and smaller until they can’t physically get any smaller. 3,000 enemy types? More like 3. An FPS RPG with an all-new engine? Make a top-down shooter in Flash. 100 hours of content? How about a game you can beat in 30 minutes?

These “kitchen sink” game designers don’t take into account that the reason current games don’t do those things is largely because any single genre game is amazingly time intensive to make. Making 4 different games simultaneously, and making them all integrated together, is a task so Hurclean as to be Syssophean. Multi-genre games almost always come out like The Adventures of Bayou Billy: three main courses so totally undercooked as to be inedible.

The fact of the matter is it takes a team of 50 people working full-time for a year to make the average game. The really stand out games, like Half-Life or Zelda, take teams of a hundred people 3 years to make. Anything remotely close to that, or beyond that, is way out of scope for your first project.

There are a few things you have to watch out for in a design. Any time a story is being told in a non-linear fashion with a multitude of possible outcomes, a red flag should go up. Any time two or more genres are being mixed, consider cutting large portions of one or both. If you ever want to see sunlight again, and you will, make one game instead of three.

2: “I’ve got my design in my head, and now I just have to make it.”

Believe it or not, Game developers don’t make games. We don’t slave away for 10 months so that a game can pop into existence. No, what game develoers make is milestones. The first milestone might just be some little code for a salmon swimming around in the water, the next milestone might add a player-controlled rod and reel, and the third milestone might have the fish biting the bait off the rod and reel if you wiggle the joystick just right.

No game gets out the door without this series of plateaus, the last of which happens to be something a publisher can sell (sometimes). People have said that game development is the process of hacking out a demo to entice a publisher, polishing the demo for E3, then polishing the E3 demo for sale. It’s a series of little and big milestones, and deadlines where everything has to work perfectly.

If you don’t set your milestones, and you don’t develop your system, you just aren’t going to get anywhere. You’re not making a game. That’s too big of a hurdle for any team. You’re making a 5 - 10 pre-determined steps, all of which lead up to whatever want to make. Take the time to figure out how long each part of your development will take, breaking it down further and further until you are at about week-sized chunks. Your development map may be completely wrong, but if you don’t have a map of some sort you can’t know if you’re making progress.

3: “It’ll be finished when it’s done.”

There have been two games this has famously been said about… Warcraft 3, and Daikatana. Guess which one you’re developing?

The fact of the matter is that sometimes games just don’t work out. You plan a great story, you designed great gameplay, the artists created great artwork, the programmers wrote great code, and when everything comes together somehow it’s far, far less than the sum of it’s parts. It’s ok, but not as great as it should be. Or maybe you feel your game will be finished when it’s done because it’s so truly bad, and the development so messed up, that nobody can realistically say when your team will be out of the bog you found yourself in.

There is a saying in the industry. “Ship it!” You can tweak and adjust a game forever, slightly improving graphics and creating more gameplay, but at some point you really need to put whatever you have in a box and shove it out the door. You have to move onto other projects, and the only way you can do that is if you finish the one you’re on, or salvage what you can of it. I’ve never shipped a game that I didn’t still want to work on and make changes to. I’ve never shipped a game that was perfect. Nobody has ever done such a thing, and nobody every will.

Your first game most certainly won’t be perfect. But what are your goals? When I ship a game, my goal usually is to entertain people, and maybe get them thinking about gaming in a new way. Your goal for your first game is probably to get street cred in the game development industry, a feather-in-your-cap if you will. Always keep that goal in mind when developing your game. You needent make a 100 hour monstrosity if your target is going to be someone who is reading your resume and will have a grand total of 10 minutes to play. A single-level tech demo will more than suffice. You don’t need to write a cinematic engine if you only have one cinematic in the game. Can you cut the cinematic, or is it key to how your trying to get your cred? Can you cut the network multiplayer, or is it key to your cred? Always keep your goals in mind when developing your game, and always be thinking about what your next project will be.

It’s better to have a good finished game than a great game that will never be done. This will also not be your magnum opus, nor the only project you ever make. Get it done.

4: “I don’t understand this. I’ll figure this part out as I go along.”

Some things are self-evident. Some things are so self-evident that you feel you needn’t describe them ahead of time… How your revolutionary natural-language parser is going to work, how “getting an education” will effect your character’s stats, or how role playing elements in a multiplayer game will affect actual gameplay. “Clearly it will work.” Yes, but how exactly? If you can’t answer that question about fundamental or key gameplay properties, you’re not ready to start making your game.

Despite my sarcasm, some things really are self-evident. You’ll figure out about how many power-ups to sprinkle around a level. You can design side-scroller boss mosters once you hammer out how many levels you are going to have. But never let a thorny issue of an original design sit unexplored. How are you going to give phone conversations gameplay value? How do you get the board game to interact with the videogame component? If you can’t figure out how to make the “revolutionary” component of your design work as a game, maybe that’s why nobody else has either.

We fell into this trap on a little side project I helped out with called The Story Game Initiative. Our revolutionary aspect was to give story gameplay value. it wasn’t until a three months into the project that we had to push everything aside and think long and hard about exactly what it was this meant. Years later we’re still sitting and thinking, and one of us has since gone off to get his masters degree in figuring it out.

5: “I have a binder full of 300 pages of design documentation meticulously pieced together over many, many years.”

Ironically, one of the worst things you can do to a design is to get too detailed too quickly. There is a flexibility of design that you really need to create an experience as parts of it come online. “The hero is a heavily armed mouse” is a good one-line description for the beginning of a project. “The hero is a mouse with a shotgun, rocket launcher, and whip, who gets 5 shots of ammo per pack” is not. Until you have your gameplay more fleshed out, you won’t know exactly what weaponry you will need to balance play, and you certainly won’t know how much ammuntion your player will need. A lot of what goes into the game does so based on good ideas from across the length of the project.

You may think this is harmless, but the fact is that besides wasting time you’re creating a structure that won’t fit the final game, and anything built on that structure won’t fit the final game. Design may be king, but a king has to dynamically respond to the situation he finds himself in. Your design too must be flexible enough not just to change and adapt, but to grow in the proper direction. And to do that it needs to be a little amorphous and undefined in places.

Keep your initial design doc a skeleton framework. As your team grows, add walls and a celing. Try not to design everything too early, or you will be left with a design that doesn’t fit your game. Anything that is “Fun” (or whatever emotion you’re attempting to evoke) gets attention and expanded upon. Anthing that isn’t gets cut. Have your programmers create general systems for movement, rather than specific systems for moving characters whose designs aren’t final. Have your artists start by sketching out “visions” of the world, rather than specific power-ups. Try not to throw final polish onto things that haven’t been tried in-game: nothing discourages like throwing out weeks of work.

6: “I’ll just do the music for the game myself. And the art. And the programming. I’ll schedule it. I’ll then promote it, I’ll do bug fixes, I’ll handle customer support…”

Laboring alone, or with the wrong people, is the greatest killer of independent projects. You might be OK with a compiler, a midi synth, and a pen and piece of paper, but it will take you forever to do everything yourself. Not only will it take you much longer to do something than someone who specializes, you won’t be as happy with the results. A competent artist might churn out a 3D object every day in their spare time, while a week later you’re still trying to make a chair using the lathe tool. You may be able to use a compiler, but you may spend two weeks writing and optimizing a custom binary search tree while a programmer might just call a prewritten hash table function and be done in five minutes.

The only commercial art form that has a single author anymore is books. Everything else is a team effort. Games are no exception.

People management, especially in small projects, is an interesting thing. You don’t want to bring people in too soon, or their enthusiasm will wane with nothing to do. You don’t want to bring people in on an emergency basis, because they’ll still need time to ramp up. The key is geting a good, clear overview of your project’s lifespan, and building from there. Since it’s your project, it’s your responsibility to find people and let them know what you’re relying on them to do to make the project work. Don’t be afraid to tell people what needs to get done to get the project done.

Game development is a fun and interesting adventure, but it is a much bigger mountain to climb than many people realize. It involves a lot of factors that need to come together just right to be successful. Build your plan, build your team, and build your game. Just be aware of the paths treaded before you, and the reasons why people wound up skeletons by the side of the road.

To you budding indie developers: I salute you. Good Luck! …You’re gonna need it.

Coping with post-partum depression in the gaming industry

You’re building up a show that you’ll never see. There is a lot of grinding and anticipation that ends not by some blinding flash of light, but by simply running out of things to do. It’s kind of hollow. What now? Your baby has been born, filled with your hopes and molded with the creaks in your back, and has left to fulfill that which you have taught it but you will never know what it did.

Shipping a game is a strange feeling. On the one hand, you build up and up and up to the moment of perfection. And just as you achieve that moment of perfection, where the development effort crescendos, it disappears out of your life forever. No amount of ship parties will cover the hollow feeling that your child is gone, has left not with brilliant flash of light, but quietly in the middle of the night. Sure, you may get postcards back every now and then… You may even know what kinds of grades the child is getting in college. But the fact remains, your baby is no longer your baby. Your baby belongs to everyone else in the world but you. Your baby is gone to strike it’s fortune, taking all of your hopes and dreams with it and leaving you an empty shell to be filled up again.

While working at one am just days earlier you had craved the moment it would be out the door, now your idle hands cry back at you, begging to be used. You fill the hours by “testing” out the games you had missed… The latest console adventure game from Nintendo. The most recent mindless driving smash-em-up. That movie-licensed Star Wars game that this time won’t be terrible. You start brainstorming ideas for ways to improve the game, even though you don’t have the publisher’s approval for a sequal yet. What do you do with yourself now that the goal you worked so hard for all of these months is complete? To the game developer, the pursuit of perfection is more important than the posession of perfection: We work hard to make games perfect, not to have a perfect game ourselves. What do you do now?

I don’t have an answer to that question. All developers deal with this problem differently. Some write. Some drink. Some dive towards their next project. Once I moved across the country. But I have found that the following steps do help.

1. Don’t just ignore it, do something different. Take a vacation. Take up cooking. Try to fix your car. Anything you can do to wedge some activity between you and your last project is helpful. It may be ackward to suddenly have actual time to fill, but don’t worry: a little like an updated resume website can quickly balloon to a full-time endeavor.
2. Try to put things into perspective: It’s difficult to know what you have done when you’re sweating fine details of a project for months on end. What are other people going to say? How does the game fit into the timeline and progression of gaming in general? What games are going to be better, and why? Questions like this help you to stop thinking in terms of the little details, and start thinking of global issues.
3. Read the reviews, especially the bad ones. Outside perspective can be really helpful, especially in letting go.
4. Grow it. If you’re still emotionally attached to your previous project, stop sweating the tiny implementation details you may have passed up in your rush and start planning ways to make a sequal that is twice as good in the same development timeframe. That way you are lending your energy to a potential next project, not your last one.

Project attachment is an interesting subject, deserving of studies of it’s own. But at some point every developer has got to let things go. You can’t make the next great game if you’re obsessing over your ex.