XML and Save Games

I'm about ready to continue forward in developing the various game classes (planets, stars, etc.), but there is one last system that I definitely need to build before moving forward much--saving and loading the game state and game parameters.

I'm planning to hold as much data as possible in external files, allowing users to edit and modify as they wish.  I see three different types of data files:

1) Game parameters, such as galaxy sizes, weapons damage, or the max. number of planets allowed per system.

2) Save game data.

3) Application settings information, such as keyboard mappings, video settings, etc.

I'm currently using Java Enums for some of (1), have not even touched (2), and have a Settings object that I pass to the relevant systems for (3).  I plan to convert (1) and (2) entirely to XML, and probably create an XML file that contains (3) as well.

For (1) and (3) I can probably use either Java's native XML capabilities (likely going the DOM route), JAXB, or XPath for creating new, user-generated classes.  The latter two options would be exercised if the user (for example) added new technologies to the game by editing the tech tree XML file.  

For (2), I plan to use XStream, which looks like a very quick and powerful way to grab object data and store it in XML, and then also unpack XML data back into Java objects.  I test ran it the other night by saving just one StarSystem object--and it followed all the references in the Controller, Views, and Model for that system, creating a 1.2MB text file...  Upon review, it had followed references to Java Monkey Engine classes and ended up saving a good chunk of the graphics engine's underlying object data, none of which was necessary.  Oops.  I can write some conversion classes that will better determine what data should be saved.

So all this is what I'll be doing over the next couple weeks--in addition to just refreshing my memory on XML (worked with it for a month or two about 5 years ago!) and celebrating the new year!  I also got the new Deus Ex game for Christmas, so I might be a little slower than I'd like in getting to all this... :)

Minor update--Elliptical Galaxies and Collision Detection

1) Straightened out a few kinks in the collision detection algorithm.
2) Converted the bounding boxes for detecting collisions into bounding polygons, so custom galaxies of any shape can be aligned in a variety of ways and not "squared off" as the old bounding rectangle method I used would have it.
3) Implemented elliptical galaxies.
4) Implemented random galaxy rotations--most noticeable with the ellipticals.  Adds some variety to the layout.

In the picture below, the bright orange pixels are the bounding polygons for each galaxy--I turned them on in this run to observe.  There are two large elliptical galaxies, two large spirals, one medium spiral, one small spiral, and about four tiny ellipticals.  Note that not all ellipticals will look like footballs--I set their parameters to make them dramatically non-circular for testing reasons.

I'll maybe have one more post in the next day or two, then nothing until after Christmas.  Enjoy!

Multiple Galaxies

I can now place multiple galaxies in random, non-intersecting patterns.  Each galaxy has its own hex grid that references world coordinates--meaning, I can place the galaxies anywhere and their grids take on appropriate values, but I don't have to place any grid locations between the galaxies.  Saves quite a bit of space.  Later, I'm going to add the ability to create hex grid locations in empty space to allow for the possibility of new destinations being created out there.

Note that the 2-arm spirals below are actually barred spiral galaxies.

Star Locations Picked

I've finished the algorithm for randomly generating star locations within a galaxy.  A few pictures, again using stand-in graphics (the blue dots):

Detailed Spiral Galaxy Shapes Complete

I know I promised some pictures with stars in them in my last post, but they're not here yet--don't worry, they're coming though!  Since my last update I've been integrating the hex grid locations into my game.  This has ended up being a bit more complicated than expected due to the sheer number of them.

I encountered two performance bottlenecks:

(1) Generating the hex locations
(2) Determining which locations are in which sector of the galaxy.

The algorithm for (1) runs in O(n^3), which would be fine if my hex grid was only about 50x50 tiles (2,500 tile area).  Unfortunately, the grid can be as large as 300x300 (90,000 area) so the generation was taking anywhere up to about half a minute.  The solution was to auto-generate a large array of locations and save them and their distances from the center point of the map (0,0) to a text file.  The text file can then be read in during any galaxy generation, with the read stopping at a specified distance (so the whole file isn't read every time).  The process now takes ~0.5 seconds for the largest galaxies, though the text file is about 8 MB.  I could probably put it in a .zip file to decrease that size.

(2) was a bit more difficult until I discovered that Java AWT could create polygons from (x,y) coordinates and test if points were within them very quickly.  It takes about 3 seconds to test 75,000 points and determine which sector of the galaxy they are in.  My only complaint is that the test can only use integers, so there are some rounding errors that create a handful of points that should be in a sector but are not.  If the test used floating point numbers there'd be no problem, but I'd guess it wouldn't be so fast...

On top of (1) and (2) I've had to fix a number of small errors with the positioning, rotation, and spiral skewing of the various branches that come off the main arms of the galaxy.  The pictures below show locations in the main body of the galaxy (green) and those outside the galaxy (red).  The red locations will actually host some scattered stars, as they form the galactic halo.  The center red hole shouldn't be there--one of my sectors isn't showing up for some reason.  My apologies in advance to those who are red/green colorblind--I'll think of a better color combo if I post something like this again.

There are 2, 3, 4, and 6 arm spiral galaxies.  Shown above are a 3-arm and a 4-arm.  Remember, these pictures are just for testing and the solid colors are actually about 90,000 individual points--the shots are just very zoomed out.

Hex Grid Working

I've been re-tooling the galaxy generation algorithm to account for the existence of the hexgrid.  While doing that I've also been testing the amount of memory that a hex grid will consume and finally playing around with different lighting options, etc. in JME3.

I can now generate circular arrays of hexagons over 400 tiles wide and maintain a decent framerate.  The picture below is a sample grid that's about 100 tiles wide.

To keep performance acceptable, I've made the tiles all one object.  Additionally, as you move away from the tiles they'll disappear.  Note that they become a blue "haze" above at some distance away--that haze will be replaced by a gradual fade out as they recede into the distance.

I've estimated that a low density, 3,000 star spiral galaxy will require a circular gird approximately 400 tiles across, so I appear to be ok.  I'll try to get some more pictures together (maybe with a star or two) this weekend!