Take a look at classic console games for inspiration, and you will have no trouble coming up with an idea for a cool new game. Any time I am bug-eyed and brain-dead from a long coding session, I take a walk outside and then return for a gaming session (preferably with a friend). Consoles are great because they are usually fast paced and they are often based on arcade machines.

PC games, on the other hand, can be quite slow and even boring in comparison because they have so much more depth. If you are in a hurry and just want to have a little fun, go with a console. Video games are full of creativity and interesting technology that PC gamers usually fail to notice.

The feasibility of a game is difficult to judge because so much is possible once you get started, and it is easy to underestimate your own capabilities (especially if you have a few people helping you). One thing that you must be careful about when designing a new game is scope. How big will the game be? You also don't want to bite off more than you can chew, to use the familiar expression.

Feasibility is the process of deciding how far you will go with the game and at what point you will stop adding new features. But at the very least, feasibility is a study of whether the game can be created in the first place. Once you are certain that you have the capability to create a certain type of game and you have narrowed the scope of the game to a manageable level, work can begin.

As a general rule, you should get the game up and running before you work on new features (the bells and whistles). Never spend more than a day working on code without testing it! This is critical. Any time you change a major part of the game, you must completely recompile the game and run it to make sure you haven't broken any part of it in the process.

I can't tell you how many times I have thought up a new way to do something and gone through all the source code for a game, making changes here and there, with the result being that the game won't compile or won't run. Every change you make during the development of the game should be small and easy to undo if it doesn't work.

My personal preference is to keep the game running throughout the day. Every time I make even a minor change, I test the game to make sure it works before I move on to a new section of code. This is really where object-oriented coding pays off. By moving tried-and-tested code into a class, it is relatively safe to assume the code works as expected because you are not modifying it as often.

It really helps to eliminate bugs when you have put the startup and shutdown code inside a class (or within the Allegro library, where the library handles these routines automatically). There is also another tremendous benefit to wrapping code inside a library—information overload.

There is a point at which we humans simply can't handle any more information, and our memory starts to fail. If you try to keep track of too many loose ends in a game, you are bound to make a mistake! By putting common code in classes (or in a separate library file altogether), you reduce the amount of information that you must remember. It is such a relief when you need to do something quickly and you realize that all the code is ready to do your bidding at a moment's notice. The alternative (and old-school) method of copying sections of code and pasting them into your project is error-prone and will introduce bugs into your game.

Follow this simple advice or learn the hard way: Back up your work several times a day! If you don't, you are going to make a significant change to the game code that completely breaks it and you will not be able to figure out how to get the game back up and running. This is the point at which you return to a backup and start again. Even if the backup is a few hours old, it is better than spending half a day figuring out the problem with the changes you made.

I have an informal method of backing up my work. I use an archive program to zip the entire project directory for a game—including all the graphics, sounds, and source code—into a file with the date and time stamped into the filename, such as Game_070206_1030.zip.

The backup file might be huge, but what is disk space today? You don't always need to back up the entire project directory if you haven't made any changes to the graphics or sound files for the game (which can be quite large). If you are working on source code for days at a time without making any changes to media files, you might just make a complete backup once a day, and then make smaller backups during the day for code changes. As a general rule, I don't use the incremental backup feature available with many compression programs because I prefer to create an entirely new backup file each time.

If you get into the habit of backing up your files every hour or two, you will not be faced with the nightmare of losing a whole day's work if you mess up the source code or if something happens to your hard drive. For this reason, I recommend that you copy all backup files directly to CD (using packet-writing technology, which provides drag and drop capability from Windows Explorer). CD-RW drives are very affordable and indispensable when it comes to saving your work, giving you the ability to quickly erase and save your work repeatedly. DVD burners are also very affordable now, and they offer enough storage space to easily back up everything in an entire game project.

In the end, how much is your time worth? Making regular backups is the smart thing to do.

The gaming press seems to differentiate between console and PC games, but the line that separates the two is diminishing as games are ported back and forth. I tend to group console and PC games together in shared genres, although some genres do not work well on both platforms. The following sections detail a number of game genres; they contain a description of each genre and a list of sample games within that genre. It is important to consider the target genre for your game because this affects your target audience. Some gamers are absolutely fanatical about first-person shooters, while others prefer real-time strategy, and so on. It is a good idea to at least identify the type of game you are working on, even if it is a unique game.

The initial design for a game is usually a hand-drawn figure showing what the game screen will look like, with the game's user interface or game elements shown in roughly the right places on the sketched screen. You can also use a program such as Visio to create your initial design screens.

The initial design should also include a few pages with an overview of the components needed by the game, such as the DirectX components or any third-party software libraries. You should include a description of how the game will be played and what forms of user input will be supported, and you should describe how the graphics will be rendered (in 2D or 3D).

Once you have an initial design for the game down on paper, you can get started on the game engine. This will usually be the most complicated core component of the game, such as the graphics renderer.

In the case of a 2D sprite-based game, the game engine will be a simple game loop with a double buffer, a static or rendered background, and a few sprites moving around for good measure. If the game runs in real time, you will want to develop the collision detection routine and start working on the physics for the game.

By the end of this phase in development—before you get started on a real prototype—you should try to anticipate (based on the initial design) some of the possible graphics and miscellaneous routines you will need later. Obviously, you will not know in advance all of the functionality the game will need, but you should at least code the core routines up front.

After you have developed the engine that will power your game, the next natural step in development is to create a prototype of the game. This phase is really a natural result of testing the game engine, so the two phases are often seamless. But if you treat the prototype as a single complete program without the need for modification, then you will have recognized this phase of the game development.

Once you have finished the prototype, I recommend you compile and save it as an individual program or demo. At this point, you might want to send it to a few friends to get some feedback on general gameplay. This version of the game will not even remotely look as if it is complete. Bitmaps will be incomplete, and there might not even be any sound or music in the prototype.

However, one thing that the multiplayer prototype must have from the start is network capabilities. If you are developing a multiplayer game, you must code the networking along with the graphics and the game engine early in development. It is a mistake to start adding multiplayer code to the game after it is half finished, because most likely you will have written routines that are not suited for multiple players and you will have to rewrite a lot of code.

The game development phase is clearly the longest phase of work done on a game. It consists of taking the prototype code base—along with feedback received by those who ran the demo—and building the game. Since this phase is the most important one, there are many different ways that you can accomplish it. First, you will most likely be building on the prototype that you developed in the previous phase because it usually does not make sense to start over from scratch unless there are some serious design flaws in the prototype.

You might want to stub out all of the functionality needed to complete the game so there is at least some sort of minimal response from the game when certain things happen or when a chain of events occurs. For instance, if you plan to support a high-score server on the Internet, you might code the high-score server with a simple response message so you can send a request to the server and then display the reply. This way, there is at least some sort of response from this part of the game, even if you do not intend to complete it until later.

Another positive note for stubbing out functionality is that you get to see the entire game as it will eventually appear when completed. This allows you to go back to the initial design phase and make some changes before you are half finished with the game. Stubbing out nonessential functionality lets you see an overview of the entire game. You can then freeze the design and complete each piece of the game individually until the game is finished.

Individuals like you who are working on a game alone might be tempted to skip some of the phases of development, since the formality of it might seem humorous. But even if you are working on a game by yourself, it is a good practice to get into the habit of going through the motions of the formal game development life cycle as if you have a team of people working with you on the game. Some day, you might find yourself working on a professional game with others, and the professionalism that you learned early on will pay off later.

Quality control is the formal testing process that is required to correct bugs in a game. Because the lead developers of a game have been staring at the code and the game screens for months or years, a fresh set of eyes is needed to properly test a game. If you are working solo, you need to recruit one or more friends to help you test the game. I guarantee that they will be able to find problems that you have overlooked or missed completely. Because this is your pet project, you are very likely to develop habits when playing the game, while anyone else might find your machinations rather strange. Goofy keyboard shortcuts or strange user interface decisions might seem like the greatest thing since ketchup to you, but to someone else the game might not even be fun to play.

Consider quality control as an audit of your game. You need an objective person to point out flaws and gameplay issues that might not have been present in the prototype. It is a critical step when you think about it. After all the work you have put into a game, you certainly don't want a simple and easily correctable bug to tarnish the impression you want your game to have on others.

Beta testing is a phase that follows the completion of the game's development phase, and it should be recognized as significantly separate from the previous quality control phase. The beta version of a game absolutely should not be released if the game has known bugs. Any time you send out a game for beta testing and you know there are bugs, you should recognize that you are really still in the quality control phase. Only when you have expunged every conceivable bug in the game should you release it to a wider audience for beta testing.

At this point in the game's life cycle, the game is complete and 100 percent functional, and you are only looking for a larger group of users to identify bugs that might have slipped past quality control. Before you release a game to beta testers, make absolutely certain that all of the graphics, sound effects, and music are completely ready to go, as if the game is ready to be sent out to stores. If you do not feel confident that the game is ready to sit on a retail shelf, then that is a sure sign that it is not yet out of the quality control phase. When you identify bugs during the beta test phase, you should collect them at regular time intervals and send out new releases—whether your schedule is daily or weekly.

When users stop thinking of the game as a beta version and they actually start to play it to have fun (with general trust in the game's stability), and when no new bugs have been identified for a length of time (such as a couple weeks or a month), then you can consider the game complete.

Once you have a complete package ready to go, burn the complete game installer with everything you need to play the game to a CD and give it to a few people who were not involved in the beta testing process. If you feel that the game is ready for prime time, you might send out copies of it to online and printed magazine editors for review.

One thing is for certain: When you work on a game project for an employer who knows nothing about software development, you can count on having marketing run the show, which is not always good. Some of the best studios in the world are run by a small group of individuals who actually work on games but know very little about how to run a business or advertise a game to the general public. Far too often, those award-winning game designers and developers will turn over the reins of their small company to a fulltime manager (or president) because the pressure of running the business becomes too much for developers (who would rather write code than balance the accounts).

The manager of a game studio might have learned the strategies to make a retail or wholesale company succeed. These strategies include concepts such as just-in-time inventory, employee management, cost control, and customer relationship management—all very good things to know when running a grocery store or sales department. The problem is, many managers fail to realize that software development is not a business, and programmers should not be treated like factory workers; rather, they should be treated like members of a research and development team.

Consider the infamous Bell Laboratories (or Bell Labs), an R&D center that has come up with hundreds of patents and innovations that have directly affected the computer industry (not the least of which was the transistor). A couple of intelligent guys might have invented the microprocessor, but the transistor was a revolutionary step that made the microprocessor possible. Now imagine if someone had treated Bell Labs like a factory, demanding results on a regular basis. Is that how human creativity works, through schedules and deadlines?

The case might be made that true genius is both creative and timely. Along that same train of thought, it might be said that genius is nothing but an extraordinary amount of hard work with a dash of inspiration here and there.

There are some really terrific game publishers that give development teams the leeway to add every last bell and whistle to a game, and those publishers should be applauded! But—you knew that was coming, didn't you?—far too often, publishers simply want results without regard for the quality of a game. When shareholders become more important than developers in a game company, it's time to find a new job.

What is the best way to work with game developers or the best way to work with management? The goal, after all, is to produce a successful game. Learn the meaning behind the buzzwords. If you are a developer, try to explain the technology behind your game throughout the development life cycle and provide options to managers. By offering several technical solutions to any given problem and then allowing the decision makers to decide which path to follow, you will succeed in completing the game on time and within budget.

The accusations and jibes actually go both ways! Management is often faced with developers who are competing with other developers in the industry. The goal might be a sound one; high-end game engines are often so difficult to develop that many companies would rather license an existing engine than build their own. Quite often a game is nothing more than a technology demo for the engine, because licensing might provide even more income than actual game sales (especially if royalties are involved). When a game is nearing completion and a competitor's game comes out with some fancy new feature, such as a software renderer with full anisotropic filtering (okay, that is impossible, but you get the point), the tendency is to cram a similar new feature into the game at the last minute for bragging rights. However, the new feature will have absolutely no bearing on the playability or fun factor of the game, and it might even reduce game stability.

This tendency is something that managers must deal with on a daily basis in a struggle to keep developers from modifying the game's design (resulting in a game that is never finished). Rather than constantly modify the design, developers should be promised work on a sequel or a new game so they can use all the new things they learned while working on the current game.

Consider the game Unreal, by Epic Games. (As an aside, Epic Games was once called Epic Megagames, and they produced some very cool shareware games.) The Unreal engine was touted as a Quake II killer, with unbelievable graphics, all rendered in software. Of course, 3D acceleration made Unreal even more impressive. But the problem with Unreal was not the technology behind the mesmerizing graphics in the game, but rather the gameplay. Gamers were playing tournament-style games, a trend that was somewhat missed by the developers, publishers, and gaming media at the time. In contrast, Quake II had a large and engaging single-player game in addition to multiplayer support that spawned a cult following and put the game at the top of the charts.

Unreal was developed from the start as a multiplayer game, since the game was in development for several years. Epic Games released Unreal Tournament about two years later, and it was simply awesome—a perfect example of putting additional efforts into a second game, rather than delaying the first. The only single-player component of Unreal Tournament is a game mode in which you can play against computer-controlled bots; it is undeniably a multiplayer game throughout.

Blizzard was once a company that set the industry standard for creating extremely high-quality games, such as Warcraft II, Starcraft, and Diablo. These games alone have outsold the entire lineup from some publishers, with multiple millions of copies sold worldwide. Why was Blizzard so successful with these early games? In a word: quality. From the installer to the end of the game, Blizzard exuded quality in every respect. Then something happened. The company announced a new game, and then cancelled it. A new installment of Warcraft was announced (Warcraft Adventures: Lord of the Clans, a cartoon-style game that had the potential to supercede the coming “cell shading” trend pioneered by Jet Set Radio for the Dreamcast, not to mention that Blizzard missed out on the resurgence of the adventure game genre), and then forgotten for several years. Diablo II came out in 2001, and many scratched their heads, wondering why it took three years to develop a sequel that looked so much like the original.

As an aspiring game designer, what is the solution to the technology/trend problem? My advice is to play every game you can get your hands on (if you are not already an avid gamer). Play games that don't interest you to get a feel for a variety of games. Download and play every demo that comes out, regardless of the type of game. Demos are a great way for marketing to promote a game before it is finished, but they are also a great way for competitors to see what you have planned. As with most things in business or leisure, there is a tradeoff. It is great to have some fun while you play games, but try to determine how the game works and what is under the hood. If the game is based on a licensed engine rather than custom code, you might try to identify which engine powers the game.

Half-Life is probably one of the oldest games in the industry that is still being improved upon and packaged for sale on retail shelves. One of the most significant reasons for the success of Half-Life (along with the compelling story and game-play) is the Half-Life SDK. This software development kit for the Half-Life engine is available for free download. While hundreds of third-party modifications (MODs) have been created for Half-Life, by far the most popular is Counter-Strike (which was finally packaged for retail sale after more than a year in beta, and then ported to Xbox).

Regardless of the good intentions of developers, many games are rushed and sent out to stores before they are 100 percent complete. This is a result of a game that went over budget, a publisher that decided to drop the game but was convinced to complete it, or a publisher that is interested only in a first run of sales, without regard to quality.

A common trap that publishers have fallen into is the belief that they can rush a game and then release a downloadable patch for it. The reasoning is that customers are already used to downloading new versions and updates to software, so there is nothing wrong with getting a game out the door a week before Christmas to make it for the holiday season. The flaw behind this reasoning is that games are largely advertised by word of mouth, not by marketing schemes. Due to the huge number of newsgroups and discussion lists (such as Yahoo! Groups) that allow millions of members to share information, ideas, and stories, it is impossible for a killer new game to be released without a few hundred thousand gamers knowing about it.

But now you see the trap. The same gamers who swap war stories online about their favorite games will rip apart a shoddy game that was released prematurely. This is a sign of sure death for a game. Only rarely will a downloadable patch be acceptable for a game that is released before it is complete.

Most successful games are followed by an expansion pack of some sort, whether it is a map pack or complete conversion to a new theme. One of my favorite games of all time is Homeworld, which was created by Relic and published by Sierra. Homeworld is an extraordinary game of epic proportions, and it is possibly the most engaging and realistic game I have ever played. (The same applies to Homeworld 2, the excellent sequel.)

When the expansion game Homeworld: Cataclysm was released, I found that not only was there a new theme to the game (in fact, it takes place a number of years after the events in the original game), but the developers had actually added some significant new features to the game engine. The new technologies and ships in Cataclysm were enough to warrant buying the game, but Cataclysm is also a standalone expansion game that does not require the original to run.

Expansion packs and enhanced sequels allow developers to complete a game on schedule while still exercising their creative and technical skill on an additional product based on the same game. This is a great idea from a marketing perspective because the original game has already been completed, so the amount of work required to create an expansion game is significantly less and allows for some fine-tuning of the game.

A solid understanding of game development usually precedes work on a game library for a particular platform, and this usually takes place during the initial design and prototype phases of game development. It is becoming more common for publishers to contract with developers for multiple platforms. Whether the developers build an entirely new game library for each platform or develop a multi-platform game library is usually irrelevant to the publisher, who is only interested in a finished product. You can see now why Allegro is such a powerful ally and why I selected it for this book!

A development studio is likely to reap incredible rewards by developing a multi-platform game library that can be easily recompiled for any of the supported computer platforms. It is not unheard of to develop a library that supports PC and next-gen consoles such as Xbox 360, all with the same code base. In the case of this book, you are able to write games directly for Windows or Linux without much effort, and for Mac and a few other systems with a little work. Allegro takes care of the details within the library.

Game engines are far overrated in the media and online discussion groups as complete solutions to a developer's needs. Not true! Game engines are based on game libraries for one or more platforms, and the game engine is likely optimized to an incredible degree for a particular game. Common engines today include the Half-Life SDK, the Unreal engine, and the Quake III engine. These game engines can be used to create a completely new game, but that game is really just a total conversion for the existing engine. Some studios are up to the challenge of modifying the existing engine for their own needs, but far more often, developers will use the existing engine as is and simply customize it for their own game project.

Examples of games based on an existing engine include Star Trek Voyager: Elite Force II, Counter-Strike, and even Quake IV (which is based on the Doom III engine). Half-Life 2 is promising to be a strong contender in the engine business, pushing the envelope of realism to an even higher level than has been seen to date.

You can do the mini design in about a week or so. It features a complete but general description of the game. A mini design document should be enough that any team member can pick it up, read it, and get the same idea of the game as the designer—but be allowed to include a little bit of his own ideas for the game (such as the artist designing the main character or the programmer adding a couple of features, such as cloud movement or parallax scrolling). Mini designs are useful when you are creating a small game or one that is heavily based on another game or a very well-known genre. Some distinctive aspects of a mini design document are

The complete design document looks like the script from Titanic. It features every possible aspect of the game, from the menu button color to the number of hit points the barbarian can have. It is usually designed by various people, with help from external people such as lead programmers or lead artists.

The complete design takes too much time to make to be ignored or misinterpreted. Anyone reading it should see exactly the same game, colors, and backgrounds as the designer(s). This kind of design is reserved for big companies that have much money to spare. Small teams or lone developers should stay away from this type of design because most of the time they don't have the resources to do it. Some of the aspects a complete design should have are

This is usually a paragraph or two describing the game very generally. It should briefly describe the game genre and basic theme, as well as the objectives of the player. It is a summary of the game.

This should include the target system—Windows, Macintosh, or any other system, such as consoles—and a list of requirements for the game.

Come on, this isn't any mind breaker—it is the game story. This covers what happened in the past (before the game started), what is happening when the player starts the game, and possibly what will happen while the game progresses.

This section describes the overall theme of the game, whether it is set in ancient times in a land of fantasy or two thousand years in the future on planet Neptune. It should also contain descriptions or at least hints of the scenery and sound to be used.

This section should contain a short description and the objectives of the main menus, such as Start Game or the Options menu.

This is probably the trickier section. It should describe what happens from the time the user starts the game to when he starts to play—what usually happens, and how it ends. This should be set up as if you were describing what you would see on the screen if you were playing the game yourself.

This section should describe the characters and the NPCs as thoroughly as possible. This description should include their names, backgrounds, attributes, special attacks, and so on.

There are two options for this section. You can give an all-around general description of the game AI (Artificial Intelligence) and let the programmers develop their own set of rules, or you can describe almost every possible reaction and action an NPC can have.

The conclusion is usually a short paragraph covering—obviously—a conclusion to the game. It might feature your motivation in creating the game or some explanation of why the game is the way it is. They basically say the same thing, so just pick the one you prefer.

The user interface of Trek will be divided into three windows on the screen. The main window, or Main Display, is where the action is—where the ships move around and shoot and interact in the galaxy. This display is also used to display the galaxy in map mode.

The Information window, on the right side of the screen, displays key information about selected objects, including the player's starship. The ship's status (damage, shields, weapons, etc.) is always visible in the bottom half of this window. In the upper half, information about selected enemy ships, bases, and other objects is displayed.

The Control window, at the bottom, will include buttons and other UI controls to allow the player to do things, such as arm weapons and raise/lower shields. In Map mode, for instance, selecting a new star system will enable a button in the Control window called “Warp,” and the ship will then warp to the new system.

The Control window will include controls that are always visible (such as ship controls) as well as transient controls that change based on the type of object selected in the main display. For instance, you will be able to click an object on the grid (such as an enemy ship or starbase or planet) and scan it. The information about that object will then appear in the Information window.

The galaxy will be very large. In reality it is 100,000 light years in diameter. The grid for a single screen will display a single zoom level, while a map of the galaxy can also be displayed in the main window. The galaxy map will show the contents of each quadrant, sector, and zone of the galaxy that has been explored.

As you know, the original series (“TOS”) took place entirely in the Alpha and Beta quadrants. The galaxy in Star Trek is made up of four quadrants:

But this will make the game too complicated, so the galaxy will be broken down into square sectors instead; otherwise, it will be too difficult to manage. There are 9 rings and 36 pie-slices that make up these sectors, for a total of 324 sectors. Instead, we can divide this up into a square by creating a grid that is 18 × 18 sectors in size. Each sector in the image below is roughly 5,555 light years square, which is roughly the average sector size from the circular sectored galaxy. The square sectors occupy a lot of empty space outside the galaxy, but this is an easy way to divide it up. This is actually what the map mode will look like at maximum zoom out. The image was rendered by NASA, and is representative of the actual Milky Way. Thanks to R. Hurt (SSC) for the rendering.

The center of the galaxy, where all four quadrants meet, is at sector 10,10. Thus, the quadrants occupy the following sectors:

Barred Spiral Milky Way Illustration Credit: R. Hurt (SSC), JPL-Caltech, NASA.

The player must explore sectors to reveal their contents. The galaxy will be randomized to improve replay value, but there will always be large sections of the galaxy where alien races occupy it, such as the Klingons, Romulans, Gorn, Tholians, Borg, etc. The trick will be to locate friendly sectors to gain allies (with friendly planets) and scout for the borders of the enemy races. The enemies will never explore beyond their boundaries, but they will rebuild ships and bases if they occupy a planet in a sector.

If you attack a sector and do not conquer the planet, then it will rebuild forces over time. Conquering a planet actually means occupying it for a while and then adding it to the United Federation of Planets as a member world. You must then protect that planet (by building a starbase) or it could be liberated. Some planets require much longer occupation times depending on the race (such as a Klingon world).

Sectors are very simplified in this game. There will either be a star or empty space. If there is a star, then there could also be a planet. If there is a planet, we'll always assume it is habitable. To simplify things, no inhospitable planets will be shown, as we assume they are just ignored. Only the important worlds are shown in the game.

Gameplay will be simple, and it will be possible to play the entire game in less than an hour. We may expand on features in a later version and make the settings change so that you can specify conquering a percentage of the galaxy in order to win instead of wiping out the enemy. The goal is to add a certain number of planets to the Federation, and that will be determined by the difficulty level:

The reason for this type of victory condition is that the game will feature many races with large portions of space to occupy. I don't want this to be a genocidal game. It's also unrealistic to expect a single starship to conquer the entire galaxy even though this is how original Trek was played!

The starship will be able to move throughout the entire galaxy, but will be limited by available fuel. So technically the player will be able to explore the whole galaxy, but fuel limitation will make that impossible. In reality, you know from Voyager it would take 70 years traveling at maximum warp to cross the galaxy, which is 1,000 light years per year. If each sector is 5,000 light years across, wouldn't it take 5 years to cross it? Star Trek is very inconsistent about it. One week, Enterprise is on the Romulan neutral zone, the next week they're back at Earth. But according to the galaxy map, the Romulans are thousands of light years from Earth. My suggestion is that the Romulans and Klingons (original enemies) are actually very close to the Federation.

If the player can find fuel along the way, it would be possible to explore the entire galaxy, but it would be time consuming. The game's goal is basically to expand the Federation in the Alpha-Beta quadrants.

Since each sector is so large (5,555 light years), they must be divided further into a smaller region of space, and this small region is where the tactical displays will take place, showing the ships, bases, planets, etc. These smaller regions will be called zones. This is still roughly following Star Trek canon, but adjusted to make the game simpler. There are 100 zones in each sector. Zooming in on the galaxy map by quadrant (and Alpha and Beta will be where players spend most of their time) will bring up a closer view of that quadrant, containing a 9 × 9 grid of sectors. The player will then click on a sector to open it up, revealing 10 × 10 zones in each sector. Here is Beta Quadrant.

Due to the scales involved here, the starship can only move one zone at a time, not cross entire sectors. The full-galaxy view will show the player what portions have been explored already, where planets are, and the orientation (ally/enemy) of each sector, which is determined by the majority of zones within it. Zooming in on a sector by clicking it will reveal the 10 × 10 grid of zones inside the sector, like this:

These individual zones (100 total in each sector) are where tactical control of the ship takes place. Warping from one zone to another is possible within a sector, but it is not possible to warp to another sector unless the ship is adjacent to that sector (for instance, the ship cannot warp to the sector above unless the ship is in the top row of zones). The galaxy map will display status information about a zone using the long range scanners. LRSCAN reveals the zones immediately surrounding the player's ship.

Going to tactical mode by zooming in on the player's current zone will reveal the 24 × 18 display shown earlier (see section “Main Display”). Each zone may have one or more planets, starbases, friendly or enemy ships, and other objects such as a Doomsday Machine, Black Hole, or Worm Hole (note: this teleports the ship elsewhere in the galaxy). The LRSCAN must be done manually. Short range (SRSCAN) is only applicable in the tactical screen, and is automatic. In the old Trek, it had to be done manually but let's assume sensors are operating full time.

Each quadrant has a unique group of alien races that were introduced through the various TV series and movies. The Alpha quadrant is where Earth is located, actually right on the border of the Beta Quadrant. The Federation spans a small sphere in both Alpha and Beta. Some other alien empires are also quite large and encompass both. Here are the key alien races in Alpha:

Beta Quadrant:

Gamma Quadrant:

Delta Quadrant:

The player may choose to play the galaxy using the galactic political situation that is true to Star Trek, or the location of alien planets and empires may be completely randomized for more replay value.

The whole point of the game is to engage in combat with alien ships and convince alien worlds to join the Federation. So combat is a huge part of the game. When the ship gets damaged, first the shields must be drained. If shields are not up, damage goes directly to the ship's hull and systems! It's up to the player to raise shields. Since this takes a lot of power, you can't travel at warp speed (across the sector from one zone to another) while shields are raised, merely because not enough power will be available. The warp engine provides power to the ship continuously, so it's possible to keep shields raised while firing at enemy ships.

The impulse engines are used to move in the tactical mode of the game inside a zone. Impulse engines can take a ship up to the speed of light, but no faster (that's where warp engines come in). A ship's specifications determine how fast and maneuverable it will be, how many weapons it has, how much armor it has, etc. When the shields are drained by enemy weapons, then those weapons will begin to damage parts of the ship.

The player may repair damage only if a system is not destroyed. If a system is damaged completely to 0%, then it must be repaired at a starbase. So, if you lose your warp engines in combat, it may take a long time indeed to get to the nearest starbase! You will have to limp from one zone to the next at impulse, and from one sector to the next, and perform LRSCANs to find one! This adds a lot of fun factor to the game, as it is realistic. Remember, it's a turn-based game after all.

If a system is damaged but not destroyed, it can be repaired, but repairs take time. The ship systems will come back online and become available when they are repaired up to a certain level. For instance, perhaps 25% damage renders a system inoperative, while 75% and lower reduces capacity, and 76 to 100% is full functionality. If phasers are damaged to 50%, then phaser power will be halved.

Combat relies heavily on the capabilities of each ship, which will be stored in a custom database of ships, and a custom editor program will be available. Ships will have a number of weapons available, each with different power requirements, damage, and range. A database of weapons will be used to configure each class of ship for each race. The ship database will provide data for each, such as the following (this is only a partial list):

These ship properties determine how a ship will function in general, as well as in combat. If a ship has only beam weapons with a short range (such as the Genser Class Escort), it will be easily destroyed by an opposing ship with long-range photon torpedoes.

The distance within a zone is very large and not to scale with the ships. One sector is 5,555 light years in width. Each sector is divided up into 100 zones (10 × 10). Each zone is therefore 555 light years in width. To further narrow down this scale would tend to become ridiculous, so the game will approximate, and scale will be way off track. But this isn't supposed to be an uber-realistic game, as it is based on classic Trek!

I propose that the longest-range missile weapons should only be able to fire halfway across the zone. If the maximum weapon can fire, say, 9 points in any direction, then consider the following illustration. Here, the Klingon Bird of Prey at H-6 probably can't hit the Enterprise at H-12, because despite the maximum range, this small ship doesn't have the most powerful weapons. However, the Enterprise probably could fire at H-6. The Klingon Predator Class Cruiser at Q-4 definitely can't hit the Excelsior at Q-13, but the Predator at V-8 probably can hit Q-13. The Excelsior can hit V-8 but not Q-4.

There is another important matter: that of firing arcs. A ship can't fire directly to the side or rear, only forward, roughly within a 90 degree arc. Beam weapons have roughly half the range of missile weapons, but do more damage. So the tradeoff is that you have to get close for phasers, and close equals vulnerable.

In classic Trek, weapons could only be fired along the actual points in the grid, not in a straight line to a target. (The idea was, this is a simulation of Trek, not a live action game, so simulated movement and combat on the grid was limited to the grid points.) Weapons can be fired at odd angles, but there is no “lock on” to an enemy. Part of the fun factor is the manual firing of weapons and waiting one turn per movement for the phaser beam or photon to hit a target. While it is moving, it's possible for a ship to get out of the way (again this depends on the ship's capabilities such as movement speed).

Torpedoes will move roughly 3-4 spaces per turn, and this will need to be part of the game's fine-tuning. Phasers hit a target in a single turn, and never miss because the attack is targeted. So, a ship with heavy beam weapons should close in to a missile ship quickly, while the missile ship should try to keep its distance.

The following partial list of ship classes will be initially available in the game. New ships and races will be added once the basic engine is functional. These ships come from the FASA Star Trek RPG (now defunct) and come with specifications that will be entered into the ship editor program. Some of these ship classes will be used by civilians and will be part of rescue missions, etc.

All of these ship systems will be available to the player in the Control window at the bottom of the screen. Clicking one of these options will open up the specific system interface.