• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Design Using buffers for maps

hippyman

Member
I've been fiddling around on paper for the past day trying to design a compact format for building pieces to allow for larger grid based maps while not using a ton of memory. The building mechanics I'm designing it for is something similar to a game called Project Highrise, just to give you an idea on what I mean.

I guess I was just curious if using buffers to manage my grid is a good way to handle this. In the documentation it says that buffers are usually used for temporary means, so I didn't know if there were some downsides to using these for this application.

I did the math for a 400 x 200 grid and it takes up a little over a half a MB so I thought that was pretty decent for the entire game map. Even a 1000 x 1000 grid only takes 7.6 MB. I haven't put any of this in code yet, so I have no idea what the performance would be like compared to the built-in data structures. I'll be testing it out in GM very soon. I'm just taking a break and thought I'd try and start a discussion.

(0-7)Base - buffer_s8
0) bit 1: is the base chunk built? (if this is 0 then this wall is skipped since nothing is here)
1-7) bit 2-8: light level of this entire chunk between all layers (0-127)

(8-32) Rear Layer
8-23) ObjectID - buffer_u16 (0-65535)
24) Rear Flags - buffer_u8
25) bit 1: object in use
26) bit 2: object needs attention
27-32) bits 3-8: spare

(33-40) Path Layer
33) Path Flags - buffer_u8
33) bit 1: indoor wall left
34) bit 2: indoor wall right
35) bit 3: door left
36) bit 4: door right
37) bit 5: neighbor left
38) bit 6: neighbor right
39) bit 7: neighbor up
40) bit 8: neighbor down

(41-32) Front Layer
41-56) ObjectID - buffer_u16 (0-65535)
57) Front Flags - buffer_u8
57) bit 1: object in use
58) bit 2: object needs attention
59-64) bits 3-8: spare

The format is designed in a way that allows this building design to be different from Project Highrise. I didn't want to completely rip them off. But I liked the idea of having multiple layers to work with. I made it so the entire building will be modular. You have to start by placing the base building object. When you connect multiple base building objects side-by-side they will connect and make a larger room and change a flag indicating it has a neighbor to the left or right. If the new base building object is placed above or below a pre-existing object then it changes a flag indicating it has a neighbor above or below (for stairs/elevators).

You can build inner walls which will change a flag on the corresponding base building objects letting it know which side the wall is on. You can place doors on inner walls which also changes a similar flag.
Then you can place a game object (decorative or interactive) in the rear and front layers.

The entire game map would be one single buffer that would work like an array. I'd have a script that figures out the start byte by giving it the wall and floor indices.

///index_from_2d(x,y,rowLength);
return argument1 * argument2 + argument0;

This script would give me the index for the wall I want to find in the buffer. In this case it would be for a 400 x 200 grid so I would do "index_from_2d(wallIndex,floorIndex,400)" and then I simply multiply the index by 8 and have the byte offset I need to begin manipulating that walls data.
 

The-any-Key

Member
If you don't loop the buffer to often it it's a good way to store data.
Note that the buffer scrips are slow but you save memory.
 

Juju

Member
I'd be surprised if you hit a memory cap with a grid. Additionally, buffers are not very fast, even peeking "fast buffers" is slower than grid lookup.

You'd usually only use a buffer for map data in this manner if you were planning on firing buffers around for networking, or if you're regularly saving map data and you're concerned about filesizes.
 

hippyman

Member
If you don't loop the buffer to often it it's a good way to store data.
Note that the buffer scrips are slow but you save memory.
I'd be surprised if you hit a memory cap with a grid. Additionally, buffers are not very fast, even peeking "fast buffers" is slower than grid lookup.

You'd usually only use a buffer for map data in this manner if you were planning on firing buffers around for networking, or if you're regularly saving map data and you're concerned about filesizes.
That's something I was curious about. So buffers aren't really going to do me any good as far as performance but they're useful for keeping file-size down? I suppose I could keep this format for saving the game map and then put everything into grids during runtime.
 
Top