Currently I’m chasing a bug in the chunk creator that’s making editing chunks impossible.

That is all..

Tonight I began building the framework to handle filling in the game space to match the model given by the chunks.

Nothing much to show though, since I haven’t finish it yet, but it’s a start.

Not a whole lot to say about today, since I was busy with volleyball. I did manage to make some more chunks, and added the beginning of functionality to move between different chunks without saving.

I added the logic to save all my chunk data to one file, and it’s working quite well. I still need to add the logic to read that information, but this is a good start.

I hit a couple of snags on the way that are worth mentioning. C#’s XmlSerializer class cannot serialize multidimensional arrays (e.g. int[, ] array), which means that if you don’t want to reimplement the serialized to handle them, you have to have a property that coverts a multidimensional array to a multi-indexed array (e.g. int[][] array). This property must be public, since XmlSerializer can’t handle private elements, and it must implement both a getter and a setter. Additionally, the class to be serialized must have a no-arg constructor.

All-in-all, I think the things I’m doing to leverage XmlSerializer are hackish, but worth the built-in power of the class. Since this is a dev tool, I’m not too concerned about it being perfect. In the future though, I think that designing classes that need to be serialized around these kinds of constraints would be cleaner and more efficient. 

I’ve gotten the basic functionality of the chunk creator implemented, now I need a way to save a chunk to disk so that in the game I can read it back.

I also need a way to move the camera so I can see the whole chunk, but that’s fairly trivial.

The way that I intend to store the chunks for the game is to write them out to an XML flat file, and then read them all at once on game load. I figure I can make each chunk I create by hand work as four different chunks by rotating them. Because of that, I plan to make ~250 chunks by hand by the end of March. To start, I will probably only make five or ten.

As I build this data set, I plan to load it all into memory each time I open the chunk creator to verify that it doesn’t have an adverse impact on performance.

The way I see it, this project will likely be split into a couple of pieces. The first is to actually generate the data I need to make an interesting game. This is where the chunk creator comes in. It is essentially going to be a grid, with each cell colored based on its in-game contents. The goal for tonight was to have the basics of it completely implemented (including switching the cell type), but in retrospect with volleyball and work, that was overly ambitious.

After the data is all generated, I will create a framework to load it dynamically into the world. I’m thinking probably two or three chunks will be loaded in the game space at a given time (meaning as objects with visual elements attached) to save on memory, but the chunk objects themselves will be loaded up by the hundreds to save on disk access time. I figure that the chunk objects will probably take up a couple of hundred of kilobytes in memory at most (not the ones being actively displayed), but if this estimate is inaccurate I might come up with a different strategy.

Finally, a scoring system and other polish elements will be added to the game. I try to do the art last and stress making an art system that doesn’t require much artistic skill; I don’t have any training in art, and though I can make it, it takes me a very long time.

All in all, I’m pretty happy with my general road map. It will probably not look anything like it does now come the end of March, but for now, it at least seems like a sane estimate of the work involved.

One of the main challenges with any kind of procedural generation is creating a result that doesn’t look and feel randomly generated. In the case of Sudoku, this means generating symmetrical puzzles. In the case of a game like Minecraft, this means making terrains and biomes that flow smoothly from one area to another. In the case of Gravity Runner (this title is definitely a work in progress), this means chains of obstacles and rewards that flow and aren’t randomly scattered. It also means not creating any dead ends that the user won’t have time to avoid.

Unfortunately, the research I’ve done into this area suggests that getting it right for this kind of environment is incredibly hard. The general guidance is to make many larger chunks by hand, and then chain them together randomly. Since I don’t want to be encoding all of these different chunks by hand, I’ll be making a quick Unity scene that will let me do it visually, and save the results to a file that I can read at runtime.

A screen during the game will be 10 cells high, and 25-30 units wide (this will be decided during testing), a chunk will be 10×100. The chunk editor will show a 10×25 grid, but will scroll to show all 100.