So, you want to be a game developer?
Having been through the publishing of a game (albeit on a small scale compared to most "AAA" games these days, but the same basic procedure applies), I really look back and wish we had had a guide to the process. Oh, you can read the post-mortems in Game Developer, and I highly recommend that activity. But they often leave out little things here and there, and not every post-mortem covers every aspect of the process. Plus there are a few pieces of lore specific to Dreamcast(tm) homebrew development, so I figured I'd write an article to help you out.
The first thing to realize, before you've gotten started, is that making and pushing it all the way to completion is a soul-sucking, free-time-eating task. This is not to say that it's not fun, but it has its ups and downs, and before the end of it you will most definitely be wondering what you got yourself into. Be prepared to literally spend 4-8 hours of your own time working on the project every day, some times even more than that. That's all in addition to your "day job" of course, since I assume most of us who do homebrew development need a day job to stay afloat as well. That said, there's just nothing to compare with the feeling you get when the first sample ends up in your hands -- here is a piece of gaming history which you created!
The Basics
Well, now that you've decided to go through with it, you need to ask yourself another question: are you writing a game for yourself, or to sell to make money? The optimal answer to this question (and the only one that will really get you anywhere if you aren't making a salary doing it) is "both". If your game idea will not be something you can imagine selling lots of (and really, be honest with yourself here!) then you shouldn't pursue that idea as a commercial homebrew project. I know that is brutal, but it is the simple truth. When you put all this work into it, you will want to get something out of it. Similarly, don't try to take on a project that is just something you think will sell well but that you have no interest in. What little interest you had from the dangling carrot of making money will evaporate very quickly when you actually start work on the game.
You should also consider, as an aspect of sellability, what has already been done previously on the DC. For example, maybe you don't want to write a shooter (*ahem* :) because the DC has a lot of shooters and they are still coming out officially and commercially somehow. That's not an insurmountable problem, but you should definitely give some thought to it. If you want to make a 3D platformer, can you really see yourself going up against $5 copies of Sonic Adventure? If so, then forge ahead! You must have something about your idea that makes it worth people's money, even if it's just "a great homebrew game like Sonic".
At some point you will probably also want to seek out a publisher of some sort. There are really only two choices for this right now: Good Deal Games and GOAT Store Publishing. GOAT is the publisher of our game Feet of Fury, as well as several upcoming titles. Good Deal Games has a great deal of experience publishing games for "dead" platforms, though perhaps not so much the DC. I recommend shopping around and seeing where there is interest. The market is very small, so if you have an idea and a plan, there's a good chance you can get someone interested. On the flip side of the coin, do not expect any sort of development support from the publishers! They will probably be happy to work with you on finalizing the designs and getting it pressed, but they are small themselves. You might also consider self-publishing the game if you have a few thousand dollars to put down for CD pressing costs and contacts for distribution or a lot of time for marketing. Don't expect to self-publish for less than that.
Your Team
The next "reality" question you need to ask yourself is "Do I really have the team I need to go through with this project?" You'll note that I'm spending a lot of time on these sort of weed-out questions. The reason is not to get your spirits down, but to save you a lot of pain later on. The ultimate pain, of course, is having to cancel your game project because you simply can't get it done with the people and resources you have. So this is very important.
The minimum team you can get away with for a simple project like a puzzle game is probably a programmer, a musician, and an artist. Or if you find a very talented person, you can sometimes combine these jobs, but be very wary of over-working someone! A full roster of jobs that will need to be done in the process of publishing your game will include:
- Manager/Producer: This person will guide the development process and make "hard calls". Traditionally with homebrewers, this has been the programmer. If you are reading this, maybe it's you. But it doesn't have to be -- you shouldn't be afraid to delegate responsibility to someone else on your team if they are better at it.
- Programmer: Writes code. This will probably be an important task in your project, depending on the complexity of what you want to do, so don't skimp here. Make sure everyone is honest about their skills and abilities. There are some things you can learn as you go, but don't expect to dive into embedded systems programming (e.g. writing a DC game) when you have just learned VB!
- Artist: Makes visual pieces. This can really easily be subdivided into several other tasks for people who have gone through the experience: designer, graphician, and traditional artist. A designer will do things like lay out screens, choose colors, pick the overall look of the game, etc. A graphician is someone who makes graphics, things like web sites, textures, HUD displays, etc (i.e. a Photoshopper). A traditional artist will do things like draw character artwork, storyboards, and so on.
- Musician: Writes background music for the game. Good musicians are tough to come by so treasure one if you find him/her. Also keep in mind the format you want for your music because some musicians are better at some formats than others. For example, someone who is used to working with pro MIDI software and MP3/OGG audio may not be good at writing MODs, and vice-versa. This is an important place for the programmer(s) to collaborate with the musician(s) to figure out what is possible.
- Sound engineer: This job is often combined with the musician, but this person will be in charge of the overall sound aspects of the game. This is sort of like the art designer. They'll take all the audio pieces and put them together coherently. They sometimes also make sound effects (though this is a task that can be passed around among the audio people). This job is often just called "producer" in the music industry.
- Tester: A tester simply takes builds and runs them through their paces, reporting any bugs in a way that they can be reproduced and fixed. They are also responsible for making sure that bugs they report get fixed in a future build, or are at least noted for future reference by severity.
- Quality Assurance: I separate this out from testing because this is something that happens more and more as you get towards the end of the production cycle. Your QA people need to take the game, play it, and answer questions like "is this actually fun?" and "how well do the difficulty settings match up to the advertised settings?" Your QA people need to take your game and assure its quality, in other words. :) These folks will generally be your last defense against putting out a lemon. Love them and the testers, especially when they tell you to go get bent about something you did!
- Business: Your business people will be in charge of handling all business-related aspects of the game production. This includes things like setting up a corporation (LLC, INC, etc), managing the accounts, registering trademarks and copyrights, dealing with final publishing, etc. May also include going to trade shows and selling. Usually this person won't have much to do until the game is getting towards completion.
- Webmaster/Sysadmin: Manages your web site and any network resources your team needs to get their job done, like email addresses, mailing lists, web forums, etc. May also design the web site. This person is important because they will provide the public face for your company! They better be really competent!
Now imagine the following scenario: You have one person to manage all the audio aspects of the game (an audio-intensive one). You have two people who are contributing some traditional artwork. Every other job is filled by yourself. Sounds crazy, doesn't it? But it's what we did for Feet of Fury! So this is proof that if you have enough determination and free time, it is possible! Just be honest with yourself up front if you think you can really do it.
Get to work!
So you have decided to take the plunge. What do you do next?
Well, this part of the process is well-covered by other articles, so I won't spend a lot of time re-hashing here. But the basic process goes something like this:
- Write out a design document. Discuss it among your team. It doesn't have to be super-detailed, but it needs to give you a good enough idea of the game you want to write that you can visualize yourself playing it. In that visualization, does it still match up to your expectations on the funness of it? Does it still seem salable?
- Make a prototype of the game. This should have awful looking stand-in textures, blocky levels, loose and rough programming, etc. The main thing you want to answer with this phase is, again, does this match up to my expectations? If not, return to the previous step again and repeat until you have a winner. If possible, try to mock up the resource intensiveness of the final game in the prototype to see if your estimates of what the machine can do are realistic. For example, if you are using cubes as player ships but you know you'll eventually aim for 200 polys per ship, make your cubes have 200 polys. It's not perfect, but it helps.
- Main development. This is where you'll actually develop most of the game. I'll leave this process up to you to research, it's highly variable depending on the type of game and team.
- Testing. Ideally this overlaps severely with the last step, but you need to go through and do a very thorough testing pass. I'll talk about this more in a minute. Most developers are really bad about testing because they test it as developers, not end users.
- Shipping. This is the absolute best part of the process. :) It may seem like it will never come, but it will eventually.
Make sure you have a schedule for this whole process. Your schedule will start high-level, with some basic milestones (maybe just the phases above) and be filled in with more detail later. But whatever you do, write out a schedule even if you fully expect it to change. Try to stick to it as much as possible, and be realistic. However long you expect things to take, double or triple it. It will likely be more accurate, but if it is not then you will feel a sense of accomplishment for finishing early. The name of the game here is "plan for the worst and you will never be unpleasantly surprised". You should also plan to be completely finished with a ready-to-ship game at least 2 weeks before any final deadlines (or maybe more). More on this below.
Testing It Out
You've gotten past your protoype phase and have an almost completely developed game. Time to start testing? NO! You need to go back and read the above again! Your testing phase needs to overlap considerably with your development phase. There are design choices that you may make that turn out not to be feasible when they are thoroughly tested. A good example of this is that the original Swap CD format in FoF put about 4-5 files per song on the disc, which produced a loading time of about 2 minutes when someone loaded up a CD. This is why you need to be testing all along.
Ideally when you are a full development company, you will have a full testing/QA department. They will do nothing but test and report bugs. Generally a "build czar" will generate regular builds which are thrown over a mental fence to the testers. The testers test the builds, and file bug reports. The programmers read the reports and fix problems. Testers ensure the problems are fixed and stay fixed.
This is the ideal of course, and developing on a shoestring budget won't allow us to have this luxury! Your currency as a developer is not dollars but offers of game credits and free copies. If you manage to generate sufficient hype around your game before it's released, you may even get people asking to be on your testing team. But what you'll probably want to do as a homebrewer is round up a small group of people who know you (and you also know), who are trustworthy enough not to leak builds, and are themselves gamers. Sometimes it is nice to find a tester who is only peripherally interested in the type of game you are making because they will be harder on it (and you don't want to pigeonhole yourself, do you?). And if you can get that person liking your game by the time the process is done, you've done something to be proud of!
There are four major levels of testing which you will need to perform on your game. These are all essential in my opinion.
- White-box/clear-box testing: This is testing which is done by the developers themselves. It is called white or clear box testing because the developers can "see inside" and know what the game expects them to do. This is important because they can test out specific aspects of the code which they know may be problematic.
- Black-box testing: This testing is performed by people who have no clue what goes on in the innards of the game. The closer they are to an end-user, the better. For example random gaming family members are good black-box testers, assuming you can convince them to tell you all the feedback, good and bad. :)
- Wild monkey testing: Yes, I am serious. This is very important. You want to get a person to sit down with your game and simply pound on the controller and all input devices wildly. They should try their very best to screw up your game. This is especially important if you are using threading because sometimes this type of testing will show up threading bugs better. We have honestly had many, many bugs found this way that would not have otherwise been found!
- Stress testing: Compile in some profiling code to find things like memory leaks and overwritten memory blocks, and leave it running for several days. You want to be able to burn your game to a CD, pop it in a given system, and have it run for a week straight with no problems at all. You should exit the game after that and see no leaked memory (unless it's some fixed amount that is the same no matter how long it runs, but even that should be avoided if possible). Once you've completed this test, try doing the same again, but periodically pick up the controller and play a few rounds. Put it down again and let it cycle on demo mode or whatnot. Remember: you can not issue patches to console games!
The basic idea here is that you need as much diversity in testing environments and subjects as possible, and you need to be very, very hard on the game. Do not baby it, your users won't! This should also explain why it's important to get non-developers to test it -- they will have fixed patterns about how they use the software after a while of developing, and thus will not test very many potential paths.
You should put concrete plans in place to be completely finished with the game and ready to press at least 2 weeks before the real deadline. You should convince yourself that if you miss this deadline, the game is off. Because that is probably true -- you will very likely eat up that 2 weeks like no one's business. It is a most horrible feeling to be making code changes 24 hours before you are sending off the masters. Just trust me here and don't get into that by planning ahead. It's tough, but cut features if you must. We were sad about it, but cut many desired features from FoF to meet the deadline and the result is that we may have a game that's slightly less cool than envisioned, but we have a game. If you don't have a publisher-imposed final deadline, then make one for yourself and stick to it. Otherwise you may never finish.
Finishing
There are some finishing touches you'll want to put in your game. These are really pretty Dreamcast(tm) specific. Some need to be planned for considerably before the actual finishing.
The first thing you want is to make sure that your game flows like a DC game ought to. When you compare it to other DC games (especially ones published by SEGA(tm)), does it "feel" the same? Generally you should have a splash screen, a title screen, a main menu, any supporting menus, and a main gameplay section. You should also have a 50/60Hz selector for PAL users at the beginning which defaults to 50Hz. Is it possible to use any controller on any menu to navigate? Can you use other types of controllers, like keyboards? How do you handle VMU support? You should definitely avoid the "stealth save", opting instead for asking the user which VMU they'd like to save on (or if they'd like to save at all). Your game should ideally be able to handle things like no save game being present, and even corrupted save games if possible.
Does the game "flow"? Are the transitions between sections smooth and clean? Do you have any excessive loading times? If you can't reduce these, can you put something to entertain the user while it's loading? A good example of this is the "pixie" in Phantasy Star Online(tm) while you connect to the server.
Your game is your ambassador in all the places you can't be to sell it: game store kiosks, trade shows, etc. It needs to be proactive about attracting players. So most games include what's called an "attract mode". This is just a loop that cycles through the title screen, demo play sequences, tutorial sequences, etc. It should give the player a taste of the game and make them want to pick up a controller and dive in. The attract mode should exit as close to instantaneously as possible after it detects user interest so that they can dive right in.
All official DC games have at least one audio track, with a warning that the disc contains a DC game and cannot be played on an audio player. If you don't include a soundtrack in your game in the audio session, yours should as well. It is a small thing but it makes it feel more professional. If possible, put the track in several languages -- it will impress people from other regions who buy the disc. You should also "pad" the CD to push the data track towards the outside of the disc because this will make loading much faster (assuming you've correctly designed your code to "stream" data from the CD in large chunks and avoid lots of seeking). I recommend doing this padding by including a very large blank audio track in the last of the audio session. This is better than putting a padding file in the data track, because it avoids head seek wear and tear from having to seek back and forth between the ISO directory and the data. It's also a nice place to hide easter eggs ;)
What will people see if they insert the CD into a PC? You may or may not care about this, but it's worth thinking about.
Whatever you do, DO NOT use official logos unless you have the permissions of the owners of those trademarks!! I can't stress this enough because I have seen so many fan covers break this basic rule. Do not use a SEGA(tm) logo, do not use the DC swirl, do not use the ESRB(tm) logo. You will likely need to use the word "Dreamcast" to declare what kind of game it is, but always put a note somewhere on the case or disc (or both) specifying who the trademarks belong to. You should also disclaim any connection with SEGA(tm). Note that I am not a lawyer and this isn't legal advice, I am just trying to head off some common mistakes at the pass and keep you out of trouble. If in doubt, take a look at what other unlicensed products have done (DC-X, DC-MP3, Bleem!, FoF, etc).
If you are serious about publishing your game and are getting close to designing the case artwork, feel free to contact CA or GOAT Store if you want to make your disc look like the other published DC homebrew. We will be happy to set you up with some templates and help with that process, and it just looks cool to have your game look like the other DC homebrew titles.
Good Luck!
That's about all I have to say on this subject! Good luck with your game, and feel free to direct any questions towards me (preferably on our forums so that others can benefit from the discussion, but on email if it's confidential).
Dan Potter
May 17, 2004
