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.
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.)
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.
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.
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
20K units -- about right
50K units -- too far
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)
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.