3D Game Programming All in One (Course Technology PTR Game Development Series)

Okay, enough typing and programming for now. It's time to examine some higher-level issues, like game design.

Start with a vision.

You have an idea. It can be an amorphous, gee-I'm-not-really-sure-but-something-like-this idea, or it can be concrete, specific, and detailed. Using that as your reference, start asking yourself questions, write them down, and don't worry about answering them…yet.

Requirements

There are a myriad of questions you can ask yourself when considering the design of your game:

• What will the genre or play style be like?

• Will this be a single-player or multiplayer game?

• If it is to be a multiplayer game, will it be an online game or a split-screen type of multiplayer game?

• Does the game relate to real-world activities?

• Does the player play as a creature (human, animal, alien, and so on) character or as some sort of machine?

• If the player isn't a creature or a machine, is he some sort of higher-level being that directs or controls a multitude of game entities?

• What are the player's goals?

• How do we measure player success and what are the scoring mechanisms?

• What are the challenges that the game presents to us as players?

• Will the challenges be designed (planned by the game developers) or will they be random?

• What is the backstory—the narrative that describes the world the game takes place in, if any?

• What is it about the game that will make people want to play it?

• What is the one skill or skill set that the game requires the player to master in order to succeed?

• What other skills will contribute to player success?

• What mechanisms can the game offer that will help players develop those skills?

• How much game enhancement of skills is too much help?

Feel free to add more questions of your own.

As you can see the list is big, and we've only scratched the surface here. By answering these questions, and any others you may want to add, we can build a list of requirements. It is important to generate at least this list—the requirements specification—in order to know where we are going with our design and how to measure our progress toward completion.

Software design is a Big Ticket Item, and hundreds of books have been written about it and the various design methodologies that have been proposed. It's an industry unto itself. There are dozens of different ideas about the best approach to take—and much disagreement. The one area everyone seems to agree on, however, is the need for the requirements to be determined and recorded in a meaningful way. Functional specs, test plans, schedules, and the like may or may not work for you, but you will get nowhere fast if you don't know what it is you are trying to accomplish.

Some of the questions lead to other questions. Some answers may need to be deferred until later when you have more information. Even if your list of questions exceeds your list of answers, it is still an important activity. Keep the list nearby, return to it regularly, and update the answers. See where it leads you. Perhaps you can see that you are wandering away from your original vision. The list may uncover things you'd never considered before, that really are important, and prevent you from wasting time on a mistaken approach.

When you work your way through creating the questions, try hard to stay general—steer away from specifics until they can't be avoided any longer.

At some point you will want to ask yourself, "What technology should I use to create this game?" Don't ask this question at the very beginning. In most cases you should wait until you know the answers to the bulk of your questions—in other words, wait until your requirements are starting to look meaty and useful—before you ask yourself technology questions.

Constraints

We usually have to accept that there are constraints that can arbitrarily force us to move in particular directions or prevent us from moving in others.

The design should drive the technology and not the other way around. However, in a low-budget development shop, this is often an unaffordable luxury. There are budgetary constraints caused by available funds that will force us in certain technological directions. In our case, because this book is about making games with minimal expenditure and using the Torque Game Engine to help us achieve that goal, we will have to accept that constraint and monitor the effect it has on our design as we build it up.

Again in our case, because we already know the technology we are going to use, we should examine it for its limitations and measure our constraints starting there.

As mentioned elsewhere Torque is designed for online, multiplayer, first-person shooter-style games. This means that whenever implementation tradeoffs had to occur when creating the game engine, the developers always tried to make their decisions in a way that favored efficient and fast networking, first-person perspective 3D rendering, and multiplayer support.

One of things that Torque, right out of the box, doesn't address in its design is massive multiplayer support. Torque can easily handle 64 players logged in to one session. It can even handle more than 100. In fact, there is no hard-coded limit to the number of players that could log in to the same server. But because of its design, Torque really starts to lose its shine when you exceed the realm of about 100 players.

Massively multiplayer games require the ability to have thousands of players playing the same game together. Torque just doesn't handle this kind of load.

So the server load is a constraint. While Torque's ability to handle 100 players at once is better than most, if not all, other FPS-style games out there, that still doesn't translate to thousands. We must keep this in mind.

The tools we have available can dictate other constraints. It's fine to decide that you will have a certain feature, but it may require an expensive 3D modeling tool to create and thus sit out of reach. So make sure you can create the things you want.

Koob

So let's go about listing some requirements for Koob, the game we are making. Feel free to add your own, but the list of 29 items here will serve as a starting place.

1. First-person and third-person perspective play.

2. Internet multiplayer game play.

3. Global in-game chat.

4. Ability to use at least one weapon.

5. Ability to get in and out of vehicles.

6. Ability to drive vehicles.

7. A road or track in the world to drive on.

8. Trees and other foliage.

9. Powerups: health, energy, ammunition, coins (for points).

10. Buildings that serve as hiding places and storage locations for powerups.

11. All other players are enemies.

12. All point values configurable from a setup file.

13. 1 point per enemy killed.

14. 3 points per vehicle destroyed.

15. Ability to race around the track and score 5 points for each lap you lead.

16. Laps can only be scored in the car.

17. A 10-lap race with no time limit.

18. A 10-point bonus for winning the race.

19. On-screen scorecard.

20. Scores retained at the end of each race restored when player resumes the game.

21. Each player gets an account at startup and must use a password to log in to the game.

22. Track must be clearly marked on the terrain.

23. Checkpoints along the way to measure progress and ensure the player stays on course.

24. Laps can only be completed when all checkpoints are completed for that lap.

25. Checkpoints must be completed in sequential order.

26. Coins of three denominations will be randomly scattered around the maps. The values will be 1 point, 10 points, and 100 points for copper, silver, and gold, respectively.

27. Some nice burning objects to admire as we play.

28. A waterfall to drive through just for the heck of it.

29. When one map is finished, cycle to the next in the list.

So as you can probably gather, Koob is a kind of death match scavenger hunt game. The player tries to win the race, accumulate some loot, and, at the same time, stop his enemies from winning.

As we progress from here to the end of the book, we'll check back against this list of requirements to make sure we've covered all the items.

Right off the bat, we can check off item 1. A few of the other items are definitely doable because we've chosen the Torque Engine to create the game, but we have some programming yet to do to make them happen.