Home       About Me       Contact       Downloads       Part 8    Part 10   

Part 9: A Larger World

January 20, 2011

I'm just getting back into this today after a week lost to my shoulder injury (I'm worthless when I can't sleep through the night.) So I don't have much new code to show you. Here's where I am with the world design.

We want a (semi) infinite world, and that takes some work. First, let's review the requirements:

  • The graphics card is not infinitely fast, so we can only render pieces of our world as we move around. We're going to have a tension between distance and detail. We want to give the user an overview of the world, so they know where they are and can see interesting places to go. But we can't spend much of the graphics rendering time on that, or else we won't be able to render nearby objects well.

  • The full world will contain an immense amount of data. Disk space and bandwidth are not infinite either. We need to cut the world up into chunks that so a server can give you pieces on demand.

  • The world is procedurally generated, which means it is created by an algorithm, not by an artist. This allows us to generate terrain on demand as you move into new areas. In order to implement this, the terrain algorithm has to be reasonably fast.

  • Once terrain has been generated, it can be altered by users. They will be able to reshape the terrain and create plants, buildings, critters, etc.. We need to summarize these at a distance, so that we aren't drawing every doorway in a distant city on the horizon.

What Worlds Are Made Of

Next, let's define all the elements of the world.

saturn

Sky

The sky is always drawn, and could be artwork, not procedurally generated. Currently, I'm thinking it includes the sun, stars and a field of asteroids in the distance (nearby asteroids are handled differently.) The sun might have some animated spots or storms and a corona. The distant asteroids might form a visible disk, like Saturn's rings.

Terrain

I'll be using the word "terrain" to mean the procedurally generated content, which in this case will be the asteroids. We need many levels of detail -- low for a rock in the sky, higher for when you approach it from space, and full detail when you are standing on it (or in it.)

asteroids

landscape

Landscape

"Landscape" is terrain that has been modified by the user. Within limits, the user should be able to shape the asteroids, mostly to clear space for buildings.

Plants

There will be some simple polygon-based plants. These can be summarized at a distance, and small ones like grass or bushes can be removed. Grass needs to be procedural, so you are not placing each blade. I'm not sure yet if the generated asteroid should include any plants, ice or other decoration. Perhaps I should just leave that up to user landscaping.

plants

buildings

Buildings

Minecraft-style structures created by users. Summarizing these at a distance is going to be hard. You can see cubes from a great distance, and replacing a 2x2x2 group with a single "summary" cube is going to ruin a lot of structures.

Ships

A "ship" is made the same way as a building, except that it can move. At any given time, it has to have a well-known position, so that players can find it. In a client-server architecture, where the server knows everything about the world, this is no problem. In a peer to peer world, it might be more of a challenge.

ships

Scripted Objects

The elements mentioned so far (sky, terrain, landscape, buildings and ships) are all static. In addition, there will be objects which can be scripted. These are all based off the "avatar" object. This is a skeleton with blocks and other shapes attached to the limbs. Under the control of a script, the limb can be moved, dragging the blocks along with it. This can be used in several ways:

Avatars   One per user, they represent a player.
 
Furniture     A movable object, and the "limbs" of the skeleton could implement doors or other moving parts.
 
Weapons   The script could move the parts (limbs) to show a firing effect. I'm not sure how "beams" or projectiles are implemented.
 
Mounts   The mount travels with the user and adjusts his speed. Otherwise, just like an avatar.
 
Creatures   The creature has an independent position and would be moved under control of a script. Creatures might also be disposable, with their positions and numbers forgotten when you move out of range.

Implementation

To implement all this, we need to solve some problems:

  • How do we represent the world? This is a data structure question and touches all the requirements. We need to be able to deliver the world in chunks, at varying levels of detail, and draw it quickly. There won't be a single data structure for all the different object types.

  • How do we generate the terrain? It's not enough to just say "noise based on your x,y,z position." How do we position and size asteroids to give a nice mix? How do we create a summary shape in polygons that you'll see at a distance? How detailed is the asteroid surface we generate automatically?

  • How do users modify the world? We use Minecraft style add and delete of blocks on buildings and other objects. I still need an editing style for landscape and plants. I need to find out if avatars and other objects made of small cubes are usable.

I know I'm using the Octree for buildings. I will try a skeleton with octrees on all the limbs for avatars and other objects. I'm still thinking about how I want to represent the asteroids.

The Field of Asteroids

One thing I did do this week was try to figure the distance between asteroids. I wanted them to be visible on the horizon, so players are tempted to visit. Ideally, the rendering would show which parts of the asteroid had been covered with structures, although I'm not sure I can keep this much detail on each distant asteroid.

I tried different sizes in the demo to see how they looked. The asteroids are radius 630 units, or 1260 across. Spacing the asteroids about 20,000 units apart seems visually right.

10K units -- too close
10K units
20K units -- about right
20K units
50K units -- too far
50K units

Unfortunately, when I made an asteroid field with this average distance, I didn't like the looks of it. The asteroids are hard to pick out against the stars, they don't really look interesting, and there are too many close ones (impossible to render the detailed shape of all of these in real time.) What's more, they don't make a pretty ring, because we are seeing them from within the ring.

Not what I want (click for full size)
lots of worlds

I will probably have to rethink things a bit in this area. Any suggestions for making this more visually appealing?

Currently, I'm reworking the demo to load and unload chunks of landscape so that I can move through a large world (the way Minecraft does.) I'd like to get a new demo up next week.

Home       About Me       Contact       Downloads       Part 8    Part 10   

blog comments powered by Disqus