Storms on Cloud 9 #35:

Order and Planning

by Scott Holliday
2004-08-20

Last time, I delved a bit into the philosophy of coding. Although many of these concepts may be old news to an experienced programmer, for those of you considering game code, it never hurts to take another look. Similarly, the topic would also be helpful to even beginning players in understanding what they have been given. So, picking up from last time… assuming you already have a game in mind and a ready codebase, what next?

When I teach computer science to beginning students, one of the hardest things to convey is just how much time pre-planning saves later on. Often, my assignments require only a diagram of what needs to be accomplished. Although it doesn't teach code, instead it trains students to think logically and to think ahead. Learning the intricacies of a single computer language is ephemeral unless it is your chosen tool. In contrast, learning how to plan out logic, assess future problems, and design an overlying structure for your code to hang from… these sorts of skills continue to be useful no matter what language you end up with.

So, one of the earliest stages of game design must be code planning. My guess is that each hour spent planning before you even start will save you several hours later one. Perhaps for an extremely simple game, it might be easier to just plunge in. However, extensive pre-planning is essential for the larger, internet game ideas most of us are looking at. This is doubly true if you have more than one coder. In order for each person to understand where their work fits in with the whole, their part of the code must be planned to fit with the rest of the puzzle.

Some beginners reading this might think at this point that I am referring to the story elements, the map, or even the game/dice resolution system. Although these might be important parts, the real issue is how you program the computer to understand them all, how they all work together, and in what ways they affect each other. Worse, you have even more basic issues. How does the computer recognize commands by the user? In what order are commands operated? For online games, how are the players kept synced and how is lag handled?

As a basic example, let's look at just a single piece, client-server planning, one of my favorite topics. For the vast majority of online games, the client program is just the tip of the iceberg. The amount of code that the server must handle (and handle well) is often many, many times larger than the client. The reason for this is simple - by definition, the client only sees what the client needs to see. Unless each player has some sort of god-view of the game world, the client must only be allowed to see what is accessible to the player. If you pass additional data to the client, your players will figure out how to use that data against you. Ideally, the server should only pass data concerning the objects which the player is aware of at that moment. In fact, the ideal server/client relationship would bypass the player's computer entirely to go straight to the monitor.

Although server-heavy design is relatively easy for text style games, for graphical games it becomes next to impossible. If the server only sends data on the objects that your character can currently see in their cone of vision, what happens when you turn around too quickly? Worse, the cost of bandwidth to continually load and unload the same objects over and over would be massively prohibitive. Sadly, the coder must find a happy compromise - such as loading all the objects in the near area, but only reporting their positions when they are in the player's sensory range. But even this data can be abused. If the client suddenly loads the data for the hulking monstrosity that is around the corner, the savvy (cheating) player will know what to expect.

So then, how does the coder diagram this client-server interface? Does the client continuously stream position data to each and every player? How does it handle sending/receiving new terrain data as the player moves? What about a secret door? Is it sent one way to some players, but differently to those who know about it? How is latency handled? Given your diagram, will players see other characters moving smoothly, or will players appear to zap from spot to spot? A very complex topic is client level code to predict where players will move so that a moment of lag won't make the world suddenly go still. And this is just the tiniest piece…

The puzzle analogy I used earlier is actually very fitting. Each coder, without knowing exactly how their own piece is meant to be shaped, will not be able to fashion it to combine with the surrounding pieces. What inputs does the piece have? What outputs? How many other pieces must it interface with? Does it need to store information over time for retrieval later?

And even if all proceeds perfectly to plan, from the second coding starts, there is one additional benefit: a constant measure of accomplishment and an estimate of the work remaining to be done…

[ <— #34: The Wheel | #36: Cliché Practicality —> ]