Monday, April 23, 2012

System Generator - Iteration Two

First, a video:



That was created by the second iteration of the solar system generator.  I finished it this morning and spent the rest of the day flying around different systems until I realized it would be a cool idea to make a video.

The first "iteration" of the generator just placed an earth-sized planet and moon in each planet slot.

The first real iteration was basically me throwing code at the engine and seeing what stuck.  I developed some basics ideas for how the generator would work.  I refined those a little bit, but the thing was still a hulking mess by the time I called it "done".

For this iteration I went back to square two.  Using the strategies I had developed last time I rewrote the entire class.  The methods were cleaned up, things were reorganized, data structured were expanded, cake was had.

A lot of the stuff that changed in this iteration was simple number tweaking and reorganization.  The coolest thing though was planetary motion.  Planets and moons now have realistic orbital periods.  In the video, you can see the white circles representing each planet's orbit.  Unfortunately all orbits are circular at the moment, but perhaps in the future I'll expand them to ellipses.  Afterall, how hard can that be?

One of the things I'm not quite happy with is the moons.  Their orbits look great, but it's their size I'm concerned about.  If you look at the information scrolling on the left, you'll notice that most of the moons are around the same size.  I'm definitely planning on adding some more variety there in the future.

The System

There are two major parts to the procedural galaxy.  The first is the galaxy generator, which is run once at the beginning of the game.  It initializes the database and fills it with as many star systems as you want.  But these systems aren't complete yet.  When each star is created, the generator chooses a fraction of their mass to be left in the protoplanetary disk to form planets.  It also holds an integer entry for the number of planets in the system.

Those star system entries sit in the table until the player visits one.  At that point, the incomplete entry is handed off to the system generator which finishes the job.  The system generator takes the mass left for the planets and smears it out across a disk, and then integrates that mass function in concentric rings to form planets.

Next Iteration

I'm going to be taking a break from this for a while (not too long, probably a week or two) so I can work on other stuff.  Here's roughly what I'm hoping to accomplish next time:

- Moon Variety
     As mentioned above, moon sizes are a little too consistent.

- Wormhole Bridges
     These will serve as the main form of transport between solar systems.  There's a lot of interesting stuff I want to talk about with these, so I'll save it for another post.

- Other System Types
     Right now the system generator only creates planetary systems.  Eventually (hopefully next iteration) I'm hoping to expand it to the other two types of systems in the database: barren and debris.  More on those later.

- Rings
      Rings were removed since the last iteration because they were just randomly put in there.  In the future I'll be looking at a more realistic way of creating them.

- Planetary Characteristics
     Each planet data structure has three float parameters and three integer parameters as unused placeholders (easily expandable if I need more).  This is the least important of the things I want to get done, so I might not even get to it.

Monday, April 2, 2012

Bubbles Mk 2

This is probably the 8th or 9th time I've rewritten the core of the scene graph. My girlfriend says its because I keep learning more and figuring out how to improve it, but I think it has more to do with my grandmother's old adage "If you've got a weak mind, you'd better have strong legs."

I've flipped back and forth between using a spatial partitioning method I've called bubbling, where space is carved up into sections which all have their own independent coordinate system. They divided space up into a three-dimensional grid, but only when objects were in their specific cell. In other words, the a bubble only existed when an object was in it. This was a pretty straightforward memory- and performance-saving optimization. 99.99999% of space is empty, so why should I bother keeping track of all that emptiness?

They last went away when I switched everything over to doubles for position vectors. However, trimesh collisions were getting a little wonky as distance from the origin increased, even with double precision. Once they got past a certain distance trimeshs stopped colliding all together.

So I spent a not-insignificant amount of time in the lab today bringing bubbles back.

Instead of creating a dynamically-spawning grid again, I anchored a static bubble at each planet, since I can pretty safely assume that's where most of the gameplay will happen. This gives each planet its own local coordinate system, which is helpful in a lot of ways. These static bubbles have a radius, and when nearest celestials are recomputed every 30 seconds each object is checked against this radius. If they have passed outside, they're considered in interplanetary space.

The next step in this is implementing interplanetary space. This will consist of a new bubble class, called DynamicBubble. Dynamic bubbles move around space as the average of the positions of all the objects they contain. If any objects get too far apart, the bubble splits in two. This should keep coordinate systems from getting too large and causing the wonky collision problem again.

I suspect that dynamic bubbles are going to be harder to implement than they sound. But they will be extremely useful.