You have finally made it. You have finished your game and you want to publish it. Now you can read the following pages for some advice on how you can do it. Here is a breakdown of the major topics in this chapter:
Whose door should you knock on?
Understanding contracts
Meeting milestones
Before you seek a publisher, you must evaluate your game. Be honest with yourself, and also ask friends, family, and even strangers to play your game and give you some feedback. Put yourself in the position of the buyer—would you buy your own game if you saw it in the stores? And if so, how much would you pay for it? These are very important questions to ask yourself when you are thinking about approaching a publisher. In this section, I'll go over a few steps you can follow to see whether your game is worth publishing. Please note that these aren't strict rules.
Probably the most important thing to evaluate in your game is whether it is graphically attractive. Don't get me wrong; I play my old Spectrum games (the good old days) more often than the new 3D perspective mumbo jumbo out there. But unfortunately, only a small group of people do so. Users want their $250 video cards to be stretched to the last polygon. They want to see an infinite number of lights, models, and huge maps, and unfortunately, games of that size require much time from many people.
Don't despair! There is still room for 2D games out there, but they must be very good to beat the new 3D ones. A nice user interface, friendly graphics, and some tricks can do the job, but understand that this is difficult to do. So, your game is fascinating? It has nice graphics and animations and even plays smoothly? Great, move on to the next topic.
Not so important but still a consideration is the sound. Does the sound match the actions? Is it immersive? One good way to test this would be to play the game and have a friend sit with his back to the computer and try to describe what the sounds depict to him. If he says that it sounds like a machine gun when you have exploded a mine, it isn't a good sign. You should also pay extra attention to the music. Music should immerse the player into the game, not make him deaf. Make sure the music is pleasing to the ears but still contains the mood of the game. An example of a bad soundtrack would be if you were doing a horror game and your soundtrack consisted of the Bee Gees and the Spice Girls. The music shouldn't force the user to turn it off; rather, it should make him feel he is in the game itself.
One thing to be critical about when evaluating your game is, does it have a beginning, a middle, and an end? Does the player progress through various parts of the game feeling as if he has achieved something? Nowadays, you can't just throw a game to the player and expect him to play if you don't reward him for accomplishing something, or if you don't explain why he should do things. Don't overlook this part of the game, because it's ten times more important than having cool alpha blend effects. The era of games that consisted of putting a player in a dungeon with a pistol and just letting him play are long gone, my friend.
You should also be concerned with whether the game pulls the player back to play. Is it attractive? Will it make the player be late to his job because he had the desire to kill the boss in level seven? If he does, then you have probably done your job well.
To see whether your game is worth publishing, you can finally determine whether it fits into any hardcore genre. For example, if your game isn't very pretty or doesn't have nice sound but it has a million and one options to run an army, it will probably be interesting to a small hardcore group. The people in these groups tend to buy the game that fits their genre (even if it isn't very impressive graphically) if it excels at simulating a subject in that genre or hobby. There are many types of games that fall into the sub-genres and niche product categories, like war games, strategy games, and puzzle games.
Whose door you should knock on depends much on the type of game and its quality. You can't expect Codemasters to pick your Pac-Man clone. Nor should you expect a company that is strictly into the strategy genres to pick your shooter. Knowing what type of game genres publishers are more interested in could help you immensely.
If you have no previous game published, it might be hard to find a publisher even if you have a very good game. You should start at the bottom and build up. Do some small games and sell them online or through budget publishers. Then start more complex games and try to get some small publisher to take it. As you build a name for yourself or for your company, make a lot of contacts along the way, and it will be easier to get to publishers and work out some deals.
Another suggestion is to attend conferences, such as E3 (Electronic Entertainment Expo) and GDC (Game Developers Conference), and try to get the latest scoop about what publishers are looking for. You can even make some contacts and exchange business cards with some of them.
One of the worst errors new developers make is to get too excited about their games and bombard almost every publisher 20 times about their game. Learning to go through the correct channels to submit a game can help you greatly.
First, check the publisher's website and try to find information on how to submit games to them. If you can't find any information, such as a phone number or e-mail address, then e-mail the webmaster and politely ask for whom you should contact to talk about publishing opportunities. This usually works. If you know a publisher's phone number, you can call to get this information and take a chance to do some scouting.
When you have your contact, it's time to let him know you have a game. Send an e-mail to the person and say you have a game of a certain genre, give a two- to three-line description of the game, and explain that you would be interested in working some deal with them. If you have a website for the game, send the person a URL for the game's demo and/or screenshots. If the publisher is interested in your game, he will probably send an NDA (non-disclosure agreement) and give you the guidelines to submit the game.
Now it's up to you to convince the publisher that your game is worth publishing and that they should be the ones publishing it. Don't ever disrespect or attack the publisher even if they refuse your game. They might not want this game, but they might be interested in another one, and if you do anything to make them angry, you can forget about trying to go to that publisher again.
You couldn't get any publisher to take your game? Don't despair, because it isn't over yet. You can still sell the game yourself. Start a website, find a host that can handle credit card purchases (or pay for a payment service), and do a lot of advertising. You might still have a chance to profit from your game.
The most important advice I can give you when you start dealing with a contract is: get a lawyer. Get a good lawyer. If possible, try to find a lawyer who has experience negotiating publishing contracts. The ideal one, of course, has experience in the game industry.
Getting a lawyer to analyze the contract for you, check for any loopholes, and see whether it is profitable for you is a must if you plan to publish your games. Don't count on only common sense when you are reading a contract. There are many paragraphs we law-impaired people might think we understand, but we don't. Again, get a good lawyer.
Also, make sure you put everything in writing. Don't count on oral agreements. If they promise you something, make sure it is documented in writing. Now that I gave you my advice, here's an overview of the types of papers you will need to sign.
The NDA is probably the first thing the publisher will ask you to sign, even before any negotiation is made. This legally bound paper works as a protection for both you and the publisher. Some people think the NDA is sort of a joke; beware, it isn't. A breach of any paragraph in the NDA can, and probably will, get you into trouble. NDAs are usually safe to sign without much hassle, but you should still check with a lawyer or someone with expertise in the field just to be safe.
The main objective of the NDA is to protect the confidentiality of all talks, papers, files, or other information shared between the publisher and the developer. Some NDAs also include some legal protection (mostly for the publisher) about future disputes that might arise from working together. Some topics the typical NDA covers are
Confidentiality
Protection of material submitted by either party
The fact that all materials submitted by either party will not breach any existing law
Damage liability
Time of execution
The actual publishing contract is what you are looking for. The NDA doesn't give you any assurance on the part of the publisher that they will even take your game for review, but the actual contract ensures that you and the publisher have to execute all the paragraphs implied. There isn't much general information I can give you on this one because these contracts change depending on publisher, game type, and game budget. My main advice is to run the contract by a lawyer because he will be able to help you more than I will. Just be sure to analyze dates and numbers yourself because your lawyer doesn't know how much time you need and how much money you want. Some of the typical topics a normal agreement covers are
Distribution rights
Modifications to the original game
Schedule for milestones
Royalties
Confidentiality
Dates for publishing
So, you finally got the contract signed; it's time to lay back and expect the money to pour into your pocket, right? Wrong! You are now at the publisher's mercy. You have to make all the changes in your game that you agreed to in the contract, fix bugs that for some reason don't occur on your computer but happen on others, include the publisher's messages and splash images (including their logos), build demos, and do just about everything stated in the contract. It's a time-consuming task for sure. There are generally three main milestones in the development of a game: the alpha prototype (where most artwork and programming is complete), the beta version (where all artwork is final, but programming bugs are still being worked out), and finally the gold release (all artwork and programming is finished, and a master CD-ROM is sent to the publisher).
You thought you were finished with debugging and bug fixing until the publisher sent you a list with 50-plus bugs? Don't worry; it's natural! When you get a bug report from the publisher, there are usually three types of bugs—critical, normal, and minimal (by order of importance). Some publishers require that you fix all the bugs; others only force you to fix the first two types. My advice is to fix them all! If it becomes public that your game has bugs, it will be a disaster!
Nothing better than a little insider input from the ones in the business, is there? Paul Urbanis of Urbonix, Inc, and Niels Bauer from Niels Bauer Software Design were kind enough to answer the following questions about game publishing.
Paul Urbanis is a longtime video game programmer whose experience goes back to the golden age of the video game industry (the 1970s and 1980s), when he was involved in designing both the hardware and software of early game machines.
Thank you for agreeing to be interviewed for this book. Care to give our readers a little background about yourself and your experience? | |
I'm a former video game programmer. When I was in school for my electrical engineering degree, I took a cooperative education [co-op] job in the Home Computer Division of Texas Instruments in Lubbock, Texas. At that time, Texas Instruments was manufacturing and selling the TI 99/4. The 99/4 was enhanced in 1981 by adding another graphics mode and a more typewriter-like keyboard, and was called the TI 99/4A, which replaced the 99/4. I had two co-op phases with TI, and when I returned to school after my first co-op phase, I had a single board TMS9900 [the TI 16-bit micro used in the 99/4A] computer with an instant assembler, a dumb terminal, a 99/4A system, and a complete listing of the monitor ROM. I spent way too much time understanding that machine and too little time on school. I didn't flunk out, but that system for me was like a light bulb for a moth—I was mesmerized and on a quest for knowledge. My ultimate use for this knowledge—to write a video game, since I also spent time playing video games that would have been better spent in homework. When I returned to TI for my second co-op stint after a year in school, I was much more knowledgeable about the TI-99 architecture. TI was about to introduce their improved machine, the 99/4A. My first assignment was to generate a pass/fail matrix of video chip supply voltage versus temperature. So, I would put the 99/4A into a temperature chamber, set the voltage, wait for the temperature to stabilize, and then log the pass/fail result for all of the voltages. As you can imagine, this was B-O-R-I-N-G, but exactly the kind of work that was pushed off to a co-op student. And I couldn't complain, because I was making good money [$7 per hour in 1982]. | |
What was it like having an electronics degree, working for a computer hardware company, and then finding yourself working on games? | |
Well, when I returned to TI, I discovered that they were working on an editor/assembler package. I was very excited because up to that point, all of my 9900 assembly language programming had been on the single-board computer, and there was no source code storage except for the thermal printer on my dumb terminal. The editor/assembler was in the internal testing phase. This is where the video chip testing re-enters the picture. While waiting for the temperature chamber to stabilize, I would be playing around/testing the new editor/assembler package. How cool was this—you could type in code for an hour, and it wasn't lost when the computer was turned off? Soon, I was reading about the new graphics mode and had some assembly-language eye candy (screensaver-like stuff) on the screen. This bit of eye candy dramatically changed my co-op job in the Home Computer Division. Because a few days later the head of the HC division, Don Bynum, was walking around, just visiting with everyone—as was his practice—and he saw my graphics experimentation and asked questions such as, “Who are you and what do you have running here?” I explained that I was testing the new graphics chip and the editor/assembler package, and wanted to play with the new graphics mode because no one in the software development group was doing anything with it. He nodded in acknowledgement and continued his visit with the troops. Later that day, I was called into Don's office, and he told me that I was being reassigned from the Hardware Development group to the Advanced Development group. Now, the real fun started. The first thing I did was get the source code to the assembler on the TI single-board computer I had used to learn TMS9900 assembly language, and port this code to a new cartridge we were working on. I also included my “Lines” eye-candy demo in source and object format so buyers of this cartridge would have an example of using the new graphics mode. After I finished this project, Don Bynum called me and Jim Dramis into his office and told us he wanted us to work on a game together. He suggested a space game, but told us that wasn't written in stone. And we had carte blanche to do whatever we wanted. There was no storyboard, script, or anything else. Just collaborate and write a game. Wow! Life couldn't get any better unless I could get the royal treatment at the Playboy Mansion. By the way, Jim Dramis was responsible for developing TI's best-selling games, Car Wars and Munchman (a Pac-Man clone). Eventually, we wrote a space game and it was named (not by us) Parsec. | |
Believe it or not, I actually owned a TI-44/Plus computer and jury-rigged a tape recorder to save/load programs! What else can you tell us about this space game? | |
Parsec was a horizontal scroller, somewhat similar to Defender. Unfortunately, due to the architecture of the 99/4A, the graphics memory was not directly in the memory map of the CPU, but instead was accessible only through some video chip control registers. Mainly, there was a 14-bit address register (two consecutive writes to the same 8-bit address) and an 8-bit data register. So the sequence to read/write one or more bytes of graphics memory was
As you can see, random access of graphics memory to do bit-blitting was painfully slow and a real competitive disadvantage when using the 99/4A for gaming. And, in the early 1980s, video games were hot! Of course, that whole market crashed big in 1983/1984 and Nintendo stepped in to fill the void, but that's another story entirely. Back to Parsec. In writing Parsec, Jim did most of the game flow and incorporated my suggestions. I contributed two technical breakthroughs to allow Parsec to do things that hadn't been possible before—and both of these contributions were directly attributable to my background as a hardware guy and reading the chip specs in detail. I was able to use a small amount of SRAM that only required two clock cycles to cache both the code and scroll buffer for the horizontal scrolling routine. This increased the speed about two times (my best recollection) and made scrolling feasible. The other thing I did was figure out how to use a new user hook [added in the /4A version] into the 60-Hz vertical interrupt to allow speech synthesis [when the speech module was connected] data to be transferred during the vertical interrupt. Prior to this, when any speech was needed the application stopped completely while the speech synthesizer was spoon-fed in a polled loop. I also did the graphics for the asteroid belt. These were actually done using TI LOGO, a LISP-like language enhanced with direct support of the 99/4A graphics. The LOGO files were converted to assembler DATA statements using a utility I wrote. | |
LOGO! Now that brings back some fond memories, doesn't it? I actually did a lot of “Turtle Graphics” programming when I was just starting to learn how to program. | |
I've been told that TI actually produced around one million Parsec games. Of course, after they exited the home computer business at the end of 1983, many of these may have been buried in a landfill somewhere. Also, Parsec was the first TI game where the programmers’ names were allowed to be included in the manual—at the beginning, no less. | |
What did you do after that game was completed? | |
After Parsec, it was time for me to go back to school, which was New Mexico State University in Las Cruces. I was in school for the fall semester of 1982, and at that time I began to have conversations with two ex-TIers who had opened a computer store in Lubbock, where the Home Computer Division was located. We talked about forming a video gaming company patterned after Activision. The company would initially consist of the two business/marketing guys and the three top TI game programmers—myself, Jim Dramis, and Garth Dollahite. Garth had written TI-Invaders, an improved Space Invaders knockoff, while he was a co-op student and was hired by TI after he completed his degree. At that time, the home computer video game market was extremely hot. So, in January of 1983, I moved to Lubbock. But Jim and Garth hadn't quit TI yet, even though they had agreed they would do so. And I was sharing an apartment with Garth, as we were both single. In February, they both resigned and Sofmachine was born. | |
How was the company organized? | |
The stock in Sofmachine was evenly divided between the five principals. The plan was for the business types to raise money by selling shares in a limited partnership, and we programmers would each write a game. As it turned out, I ended up doing lots of work making development tools, since I was the hardware guy. I designed and built emulator cartridges [not much different in principle than GBA flash carts], as well as an eprom programmer for the 99/4A. I also modified the TI debugger so all I/O was through the serial port because our games were too hooked into the video system to share it with the debugger. I also added a disassembler to the TI debugger. | |
So your new company focused mainly on the TI-99? | |
Our games were progressing fine, although mine was behind because of all of the support development I needed to do. However, the business guys weren't having much success. In fact, by mid-summer they had raised exactly zero dollars. Keep in mind, they had income from a computer store they were running, while we had quit our jobs. Their only additional expense was to install a phone line in their store that they answered as “Sofmachine.” Of course, there was expense for preparing and printing up the limited partnership prospectus. Needless to say, we were getting nervous. Jim was married with two kids, so he was burning through his savings at a high rate. And I had taken out a personal loan, co-signed with my dad, and it wasn't going to float me too much longer. In the middle of the summer, Sofmachine was contacted by Atarisoft. Atarisoft had been buying the rights to port the popular full-size arcade games to game consoles and home computers of the day. And Atarisoft wanted us to convert three games: Jungle Hunt, Pole Position, and Vangard. We agreed to do so, at $35,000 for each game—except for Pole Position, which we managed to get $50,000 to do. So we started coding in earnest. Meanwhile, absolutely no funding of Sofmachine was happening. So Jim Damis and I decided that the business guys needed to be out of the corporation because it would be unfair for them to get 40 percent of the Atarisoft revenue for doing nothing. We had delivered 99/4A games to be manufactured and marketed, but they hadn't delivered the means to manufacture and market them. This was complicated even more because Garth was a former high school student of one of the business people, whose name was Bill Games. In fact, Bill had recruited Garth to TI as a co-op student. Garth didn't think we should kick out the business types, but eventually he relented. We had a meeting and we agreed to pay all expenses incurred in the limited partnership offering, as well as other tangible expenses—phone and copy costs—plus five percent of the Atarisoft contract. Everyone agreed, and they signed their shares over to us programmers. | |
I played those games quite a bit as a kid. It must have been fun working on arcade ports. How did that go? | |
We finished both Jungle Hunt and Pole Position at the end of 1983. About midway through the Vangard project, which I was doing, Atarisoft cancelled the project and agreed to pay half of the $35,000. When Jim finished Jungle Hunt, he accepted a job with IBM in Florida. Meanwhile, Garth and I were waiting on Atarisoft to decide whether they wanted us to port Pole Position to the ColecoVision game console. We really wanted that because we knew the game and already had the graphics. And, while the ColecoVision used a Z80 CPU, it had a TMS9918A video chip—the same as the TI 99/4A. I had already reverse-engineered the ColecoVision and generated a schematic. In fact, I designed a TMS9900-based single-board computer [SBC] that attached to the ColecoVision expansion bus, and used DMA to access the ColecoVision memory space. That way, we were able to use a slightly modified version of our 99/4A debugger that was ported to the SBC. In fact, Garth even modified the 9900 disassembler so it would disassemble the Z80 code in a ColecoVision cartridge. We were all set to make some easy money on the Pole Position conversion. But the video game industry was in the midst of imploding, so Atarisoft decided they didn't want to do this project. Garth moved back to California and took a job with a defense contractor, and I used my Home Computer connections to get a job back at TI in their Central Research Laboratories [CRL]. | |
At TI's CRL, I joined the Optical Processing branch, which was researching and developing the DMD. This is a light modulator technology along the lines of an LCD. It uses an array of small mirrors—17 microns on a side originally, now 14 microns—to display an image. This image is magnified by projection optics. TI now refers to this technology as DLP [Digital Light Processing], and it is used in over 50 percent of the conference room portable projectors and almost all of the digital cinema installations. In 1990, this technology was moved out of CRL and spun into its own operating group. While in CRL, I was the systems engineer for DMD, even though I didn't actually have a degree. In 1989, thirteen years after graduating high school, I received my BSEE from the University of Texas at Dallas. Of course, TI paid for my books and tuition while I worked on my degree. I worked at TI as an employee until 1995. When I left, I had a project lined up with Cyrix, which was making X86 clone products at the time. This project lasted about a year, and just after it was completed, I got a call from the DLP guys, and they needed some help for about six months. I ended up doing contract engineering for them for five years. Then, they decided I either needed to become an employee or leave. So I left. | |
Now tell me a little something about the company you founded and are still involved with at this time. | |
I formed Urbonix, Inc. (http://www.urbonix.com), which in reality had existed as a DBA [Doing Business As] since 1995. Before I cut the cord with TI, I was contacted by a company on the East coast, Dimensional Media Associates, who was getting ready to produce a 3D display using TI's DLP. This company, now LightSpace Technologies (http://www.lightspacetech.com), is still developing and marketing this product. Urbonix designed and built the first prototypes for the DMD display boards, as well as the image processor/formatter board that is used is in the Z|1024 product that you see on the LightSpace Technologies website. My company, Urbonix, currently has a contract with Texas Instruments, where I am developing and supporting FPGA-based boards and peripherals for ASIC emulation. | |
Thank you very much for your time. | |
Through all of this, I'm still interested in game design. It's been a pleasure; thank you. |
Niels Bauer has been programming since he was 10 years old. He owns Niels Bauer Software Design and is studying law at the University of Freiburg in Germany. Niels Bauer Software Design (http://www.nbsd.de), located in Germany, has concentrated on complex (but still easy to learn) games. One of their best games, Smugglers 2, is an elite-like game from a strategic point of view. It features a lot of new ideas, such as crew management, boarding enemy ships, attacking planets, treasure hunting, and smuggling. If you want to make a game in the Smugglers universe under the loose guidance of this company, give them a call. You can reach them via the website.
You have been through a crash course in software publishing, and this was just the tip of the iceberg. There are many options, many contracts, and many publishers you need to check, and that's just the beginning. As you get more experience, you will start to easily recognize the good and bad contracts, as well as the good and bad publishers. So what are you waiting for? Finish the game and start looking!
Below are some URLs of publishing companies and conferences. Please note that neither I nor Thomson Course PTR recommend any one publisher over another; the list is alphabetical.
Codemasters: http://www.codemasters.com
eGames: http://www.egames.com
Garage Games: http://www.garagegames.com
On Deck Interactive: http://www.odigames.com
RealArcade Games: http://realguide.real.com/games
Game Developers Conference: http://www.gdconf.com
ECTS: http://www.ects.com
Well, this concludes the final chapter of the book. I hope you have found this to be a valuable book that will remain in your reference library for many years to come, and that you have enjoyed it as well as learned a great deal from it. I sure was thrilled to have the opportunity to revise the book for this third edition. The second edition was a complete rewrite from the first, and was a bold move into a new realm of cross-platform and open-source software. This third edition strengthens the support of Allegro by making it more accessible and easier to install and use, so that just about any competent C++ programmer can get into this great game library. Allegro is truly a fun library to use and makes game development enjoyable.
I normally don't have time for one-on-one help due to my busy schedule, but if you run into any problems with the code in this book, I would encourage you to visit the game programming forums at http://www.jharbour.com, where most solutions to problems are resolved and posted within a month or two after a book is released (at least, that was the case with the second edition). If there are any glaring errors in the third edition, then I will post information about any errata and fixes on the forum.
Good luck with your game development career. If this is just a hobby for you, then I look forward to seeing what interesting games you come up with over time. If you are a professional game developer, then I am also eager to hear from you as well.
Tank War was a difficult project because it was enhanced throughout the book. Making notes of what changes occurred each step of the way was a significant challenge. Therefore, I decided to exclude the final version of Tank War from the actual text of the book because so much of the code had changed, and I was certain that it would be nearly impossible to take the last revision (from Chapter 18) and note the changes to assemble the final version. Instead, a complete source listing would have been required, and that would have been a huge listing. Therefore, I am simply going to show you what the final version of the game looks like and encourage you to take a look at the game located on the CD-ROM. Project files have been provided for all versions of Visual C++ as well as Dev-C++ as usual.
One of the most significant changes to Tank War is the use of game state now in the main function. There is a title screen (shown in Figure 22.1) when you start up the game now. Tank War now has a full assortment of sound effects and music.
Normal gameplay is still similar to previous versions of Tank War, but the game now features fully dynamic rotating sprites that are not bound by the eight directions of movement in earlier versions of the game. As you can see in Figure 22.2, the tanks can rotate at any angle and fire their cannons at any angle. There is also a new, highly animated explosion sprite that looks much better than the old one. The map has also been redone, and significantly enlarged over the previous “demo” map file.
The tanks are now represented with 3D rendered models which are shown at the top of the screen with health bars showing the damage level for each tank. These rendered models are also shown when a player wins, as you can see in Figure 22.3.
There are still so many things I would have liked to do with this fun little game. For one thing, it seriously needs some obstacles in the map so that there's more of a challenge at locating and hitting your opponent. Another feature I wanted to add was a main menu with the option of playing in single-player or two-player mode. The single-player mode would require computer-controlled tanks. Ideally, I wanted to cover this subject in the A.I. chapter, but that didn't work out due to publishing deadlines. And lastly, when rewriting the tank drawing routines to implement angular velocity, the radar was disabled and I did not complete work on getting it back up again. You can see there's a spot reserved at the top of the window for the radar, but it needs to be completed.
It is my sincere hope that you take this game, replete with missing pieces and potential bugs, and take it to the next level with all of these features and more! You have available to you here a nearly complete game that is totally functional at this stage, but needs some tender loving care to polish it up. There's so much potential for this game that goes way beyond my suggestions here. Are you up to the challenge? If you do something great with Tank War, I'd love to see it!