Designing the World

My first task was to create a world. I had already decided that, like Empire, my game would create its own custom world for each playing. I anticipated that this could create a nasty problem. My world-creation algorithms would be quite complex and could conceivably create nonsensical worlds. In such cases, I would need to re-create the nonsensical world and track down the programming bug that led to the mistake. Yet, if the algorithms relied on random numbers to create the world, then I would have no way to re-create the world. I solved the problem by asking the user to provide a name for the world; this name became the seed for the random number generator, guaranteeing repeatable results should they be required.

LESSON 66

Don't be such a square! Think about alternative ways of organizing space in your design.

My map system relied on provinces rather than a grid of squares. Such grids, called rectgrids (see the discussion of various grid systems in Chapter 13, "Tanktics") are ubiquitous in computer games; even if you can't see the rectgrid, it's there. Somewhere inside the program there are little X's and Y's denoting the position of every object and character in the game. I find such all-encompassing convention offensive to my creative sensibilities. If everybody does it, then surely I must find another way. And indeed there are plenty of other ways to organize space on a map: polar projections, hexgrids, triangular coordinates, and so on. But the most interesting, and I believe the most flexible, approach uses provinces: irregularly shaped splotches of territory treated as single spatial units. I therefore designed the map as a collection of such provinces. This innovation improved the game, I believe.

As I had decided not to include naval factors in my game, map generation would be greatly simplified by the lack of islands. I need create just one huge continent. Map generation began with placement of the capital cities of the various provinces. This was a purely random process save for the obvious provisions that cities not be too close to the edge of the map or to each other. The second step was the placement of roads between some of the provinces. Note that, at this point, adjacency between provinces had not been established.

Having decided on roads, I then set about establishing the spokes that connected the cities. Imagine a cluster of points on a map; obviously, they can be connected in many different ways (as shown in Figure 24.1).

24.1. Different spoke systems.

graphics/24fig01.gif

How is the computer to decide upon the best configuration of spokes? The most effective algorithm, I believed, would minimize the total lengths of all spokes. However, when I wrote up this algorithm, it took far too long to run. The reason was that there were up to 64 cities in the game, and the number of arrangements with 64 cities was astronomical. Now, I could have worked out a good pruning algorithm that would have permitted me to explore only the best few thousand arrangements. However, I chose an alternate route, based on a simple-minded scheme using the angles between spokes. It was a clumsy algorithm, and required a certain amount of tweaking, but it ran quickly and yielded acceptable results. In the immortal words of Adam Osborne, "Adequacy is sufficient."



Chris Crawford on Game Design
Chris Crawford on Game Design
ISBN: 0131460994
EAN: 2147483647
Year: 2006
Pages: 248

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net