Jump to content
  • Advertisement
Sign in to follow this  
Plethora

Storing/Loading Randomly Generated Terrain.

This topic is 1849 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on a 2D top-down RPG with a free and open world (to some extent anyway).  As you explore the world, new terrain is generated for you in the form of chunks.  I have the terrain generation working using the Diamond-Square algorithm and while is pretty simplistic right now, it works.

 

I'm trying to work through how I'm going to save that data once it's been generated, since, after its generated it should remain constant in further sessions.  Within the engine right now, I simply treat each "chunk" like a tile and I have a vector that stores them in order, however this only really works when chunks are uniform squares, and I do not intend this to be the case in the final version.  I have two thoughts about how to proceed:

 

1)  Continue doing it as I have been but add some supporting data where a given chunk holds pointers to all of its borders.  If the player approaches the edge of a chunk and there is no border data, then generate a new chunk on the border.  Else, load the desired chunk from memory.

 

2)  Go brute force with it and don't even store data as chunks.  Have an absolute coordinate system where the player starts at 0,0 (or some other arbitrary coordinate), and store individual tile data just as individual tiles are stored within chunks.  I could still use chunks to generate new terrain, but I wouldn't store them as such.  Seeing as all that really needs to be stored is a couple of ints per tile I could store and load everything from memory at session start/finish for awhile before starting to see a performance hit (I would think anyway).

 

Either of these methods would probably work, but I'd love to have some input on which would be best, and I'll definitely consider suggestions for some alternate method.

 

:)

Share this post


Link to post
Share on other sites
Advertisement

If the terrain isn't modifiable, you can simply store the random seed used to generate the chunk. If it is modifiable, you can store the seed plus a list of changes. Either way, when a chunk is to be loaded, you check to see if there is a seed stored and if not, create a new seed. If there is a seed, use it to regenerate the chunk then iterate the list of changes and apply them. If a changes list exceeds some arbitrary threshold, it might be more cost-effective to switch over to storing the whole chunk instead.

Share this post


Link to post
Share on other sites

Hehe... that would be pretty simple wouldn't it.  Thanks for the tip, should've thought of that one myself.  :)

Share this post


Link to post
Share on other sites

If you're planning to release on more than one platform, and you intend the save games to work on both, you might want to consider your own random number generator (since there is a high possibility that the RNG implementations differ across platforms/compilers)

Share this post


Link to post
Share on other sites

If you're planning to release on more than one platform, and you intend the save games to work on both, you might want to consider your own random number generator (since there is a high possibility that the RNG implementations differ across platforms/compilers)

 

Thanks for the tip... would the same apply across various versions of Windows, for example?  I don't intend a commercial release at this time, but I do intend to release my game for free (eventually).

Share this post


Link to post
Share on other sites

It's not so much the operating system, but the C-standard library of the compiler you're using. i.e. the version of rand() from VC2005 is possibly implemented differently to the version found in VC2012, gcc 4.1.2, gcc 4.4.6, etc etc. If you were being pedantic, then you'd probably use your own RNG all the time. If you were being reasonable, you'd lock to a single compiler for any updates or patches once your game has been released (possibly with some testing to make sure that an i7 produces the same results as a core2 and pentium 4). Something such as:

 

#define myRand(X) rand(X)

#define mySRand(X) srand(X)

 

would make it easy enough to fix at a later date if needed ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!