Jump to content


Photo
- - - - -

Procedural Map Generation Example


  • Please log in to reply
2 replies to this topic

#1 DarkFlame

DarkFlame

    GMB Member...wtf?

  • GMC Member
  • 2167 posts

Posted 05 January 2015 - 05:07 AM

  • Title: Procedural Map Generation Example
  • Description: Shows the first 3 steps to generate a cave system
  • GM Version: :GMS:
  • Registered: Probably?
  • File Type: .gmz
  • File Size: 181kb
  • File Link: https://app.box.com/...slfioo37gyptc98
  • Required Extensions:None
  • Required DLLs: None
  • Tags: cellular automata, ds_grid, floodfill

Summary:
Following in the footsteps of many other game developers I have been learning about map generation using cellular automation (CA). I have been working on many projects to teach myself different aspects of map generation and thought that this might come in handy to those people out there who like to see how it can be achieved in a familiar language. 
 
The major areas this code covers is what I would consider the first 3 steps of map generation.
1. Populate a ds_grid with noise
2. Use CA to shape that noise into a cave system
3. Identify the isolated regions of the cave system

 

Here is a video showing the example in action: 

 


http://youtu.be/G9JajyNLiq8
 


  • 0

#2 chance

chance

    GMC Member

  • Global Moderators
  • 8762 posts
  • Version:GM:Studio

Posted 05 January 2015 - 12:41 PM

I like world generation based on cellular automata techniques.  And this one is interesting.  That said, I can't say I like this particular approach.  Instead of using ds_grids and queues, I think this could be done more intuitively just using old-fashioned arrays and a raster approach to the CA rule.   But that's just my speculation -- I haven't tried it.

 

On the other hand, the ds_grid approach works well here.  And clearly, it has some advantages over simple arrays.  Like, for example, checking neighbors and summing values over a sub-region, overall access to sub-regions,etc.  So you've put them to good use here.

 

The overall approach here isn't easy to follow, so I wouldn't recommend this for beginners.  But the comments in the various scripts help a bit.  So users should be able to follow this, and make adjustments to suit their needs.

 

A few things I don't like, so I'll ask you to fix them.  Mostly, it's the lack of proper statement termination with semi-colons.  GML allows this, but it's risky and can lead to ambiguous code or errors.  So please pay more attention to that, especially when you have multiple assignments on a single line.

 

One thing that bothers me is that you use the DRAW event to check for a mouse click (in the obj_btn_new, for example) and set a flag.  Then you use that flag in the STEP event to trigger a script.  I think you could do this much more efficiently by just using the built-in mouse events.  (Just a pet peeve...)

 

But overall, I think this could be useful to other members.


  • 0

#3 DarkFlame

DarkFlame

    GMB Member...wtf?

  • GMC Member
  • 2167 posts

Posted 05 January 2015 - 08:45 PM

I like world generation based on cellular automata techniques.  And this one is interesting.  That said, I can't say I like this particular approach.  Instead of using ds_grids and queues, I think this could be done more intuitively just using old-fashioned arrays and a raster approach to the CA rule.   But that's just my speculation -- I haven't tried it.

 

On the other hand, the ds_grid approach works well here.  And clearly, it has some advantages over simple arrays.  Like, for example, checking neighbors and summing values over a sub-region, overall access to sub-regions,etc.  So you've put them to good use here.

 

The overall approach here isn't easy to follow, so I wouldn't recommend this for beginners.  But the comments in the various scripts help a bit.  So users should be able to follow this, and make adjustments to suit their needs.

 

A few things I don't like, so I'll ask you to fix them.  Mostly, it's the lack of proper statement termination with semi-colons.  GML allows this, but it's risky and can lead to ambiguous code or errors.  So please pay more attention to that, especially when you have multiple assignments on a single line.

 

One thing that bothers me is that you use the DRAW event to check for a mouse click (in the obj_btn_new, for example) and set a flag.  Then you use that flag in the STEP event to trigger a script.  I think you could do this much more efficiently by just using the built-in mouse events.  (Just a pet peeve...)

 

But overall, I think this could be useful to other members.

 

I have uploaded a newer version. It doesn't change much (other than adding semi colons and moving non draw related scipt out of the draw event) so I have uploaded it under the same link. I should of added a disclaimer that my code is a mess :P

I find the ds_grid system useful because I can store the ds_grid ids in a 2D array which makes it far more flexible when it comes to generating chunks for a larger map. Creating one big map array takes a lot of time and creates far smaller worlds. If i were to use a unique seed for each chunk in my 2D array then it would always generate the same chunk at the same location. Meaning a huge open world map that requires no loading times and no additional disk space to store the map. If the player moves to the left, then we ask a 2D array for that locations seed and create the ds_grid and store its id in another 2D array.

 

I made this to help me understand my particular map generation process. Looking in the alpha-games section I noticed no shortage of random generation and thought somebody might find this useful.


  • 0