Saving the State of an Infinite Procedural World

The last thing I got working was procedural generation of the game world. It will generate random rocks no matter how far you fly in any given direction, until the algorithm finally breaks down because the random seeds get too big (I really curious how far that is).

Now that I can generate the this enormous game world, the question becomes “How do I save the state of a practically infinite world!?” I obviously can’t save an infinite number of objects. I’ve peeked around a little inside Minecraft save-games, and I understand the basic approach used there. The world is divided up into “chunks” and only chunks that have actually been visited by the player are saved. No need to save stuff that the player hasn’t even seen yet. As a result, there’s no limit to how large the save-game can grow, but it only grows as much as the player roams around the map.

I decided to take a similar approach, but with a slight change that suits my world generation algorithm a little better. I only save the “diff” of what the player has done. Space is divided up into “sectors,” which are just square areas of space. As the player flies around, I generate rocks inside these sectors. But I don’t actually save any information about those rocks until the player does something to them (e.g. mines them). For example, if a rock is completely destroyed, I just add an entry to the saved state that says “rock 123 destroyed.” If the player ever comes back to that sector, I just generate all the rocks as I normally would, but when I come to rock 123, I skip it. Or if it has been partially mined, I’ll have some saved state that says “rock 123 mined, now has 500 hitpoints, next resource drop is 5 silicon,” etc…

So, the save-game can grow indefinitely, but it will stay about as small as possible. For now, I’m just saving the game in localStorage, which is essentially a browser cookie. I don’t think that will work as the permanent solution because localStorage tends to just randomly be erased. There are no guarantees about how much space you can use or how long it will last. The best idea I have for something better is to let the user download a save file and save it locally on their system. We’ll cross that bridge when we get to it.

Try out version 0.4.2.2. on the releases page. In this version, I’m currently saving any rocks that you completely destroy, any drops that you leave floating around (but their positions are all wrong), and your ship (where it is and what you’ve built).

How I Solved the “Far Lands” Problem in Ladon, Kinda

Minecraft veterans all know about the legendary “Far Lands.” This was where the game’s terrain generation would fall apart and the world would start to look like the image at the top of this post. I’m not certain, but I believe this has been fixed in modern versions of the game. It used to happen at a distance of about 12.5 million units (12500 km) from the center of the world, where the player is spawned. By some really weird coincidence, that’s roughly the diameter of the Earth.

Continue reading “How I Solved the “Far Lands” Problem in Ladon, Kinda”

The Beginnings of an Upgrade System

One of the core features of Ladon is the ability for the player to build a better and better ship. Until now, the only way to do that was by adding new tiles. I found that this type of “upgrade” is too coarse. If you start with one laser and the first upgrade you can make is to build a second one, that’s a 100% increase in firepower. It needs to be more gradual in the early stages, and more drastic in the later stages. An exponential curve does exactly that.

Continue reading “The Beginnings of an Upgrade System”

Asteroid Mining that Feels More Like Mining

I spent a lot of time this week on generating asteroids with more realistic sizes and making them produce “drops” more realistically. Instead of the whole asteroid breaking apart all at once, it now steadily drops resources as you mine it, until its hit-points reach zero. It’s slow and feels like work, which is good! There’s your motivation to build some bigger guns.

Continue reading “Asteroid Mining that Feels More Like Mining”

Beams!

It’s not just “pew pew pew” anymore – now there’s also “bzzzt bzzzt.” This forced me to right a whole new class of collision detection shapes. Up to now, everything was treated as a circle, which is easy. For beams, I just had to add line segments and the test for collisions between lines and circles. My collision algorithm uses a sparse grid implementation, and testing a line segment against a grid was a little tricky. There’s a subtle bug in there somewhere because sometimes I see collisions being missed…

Check out beams in version 0.3.7.0.

Ladon’s First Pre-Alpha Release!

I did a lot of code cleanup this week in preparation for the first true release of Ladon. It’s a “release” because it’s actually going out to people, but it’s still very far from being an actual game. My very generous friends have volunteered their time to play around with Ladon at this early stage and share their feedback.

The version is 0.3.6.1 and I went through a heavy code cleanup. The on-screen text is now using the 3D text class I wrote recently in the BabylonJS forum, which was a huge performance improvement.

If you, dear reader, would also like to play the early version, you can do so right here and you can leave feedback in the comment section, below.

“Going Pro” as a Game Developer

It’s not the writing part that’s hard. What’s hard is sitting down to write.

Steven Pressfield

That’s a quote I came across a few years ago and it really stuck with me. Mr. Pressfield was talking about actual writing, as in novels, but it applies to any creative pursuit. With a game, the hard part isn’t solving the various algorithms, creating the artwork, or even the game design itself. The hard part is sitting down every day and just doing the work. Yesterday, I did what he calls “going pro.”

Continue reading ““Going Pro” as a Game Developer”