A
Anthony@DiversionKit
Guest
Hi everyone,
I'm new here on the forums, but I have been reading a lot. Thank you for being such an helpful community. Please be patient, I'm not that much familiar with Gamemaker.
I have been trying for a few days to figure out a grid system for an exploration/city building game prototype.
The exploration part means that the player is represented on the map and freely moves around a generated world made of regions, chunks, and tiles.
The city building part means that each tile needs to have a properties ( type, resource generation, sprite, etc) that can be modified and accessed. Building is done by getting the coordinates of the tile the mouse is in, and modifying the corresponding tile.
For a building that is bigger than a tile, there is an origin tile. The origin tile and the surrounding tiles are modified to assemble the building.
But let's talk about the grid system
In my previous version I created chunks with a DSgrid and each chunk was its own object. But it did not work well for buildings that are in multiple chunks.
So I tried to design a more reliable grid system that does no need objects for everything, and this is what I came with, but I don't know if this is feasible:
In this system, properties are nested and use a system of coordinates:
and so for example, to build this building, I would need to edit (removing the intermediate lists for clarity):
As for the generation itself, I would create all the grids at the generation of the world, then fill them when needed (radius around the player).
I am worried though, because that is a grid per tile + a grid per chunk + a grid per region.
For a world that is 16 regions, with regions that are 16 chunk large, with chunks that are 16 tiles large, with tiles that are 64px large:
An easy way would be a small map like old Zeus and Cleopatra game. But I'll be loosing the exploration aspect of the idea.
I wonder if some of the final steps need to be buffers instead of grids and lists. (Probably both chunk and tile level) But I also like the operations possible with grids as it can be really helpful for generating the terrain.
I also thought of bigger grids with two of the size level inside, It is probably a good way to avoid having too many grids.
But wonder if I can get the same unified coordinates system with those. Which is my bigger concern.
I think this could work, but I do not have enough experience in Gamemaker to know if this is the right way to do it.
So I'm asking the community:
I'm new here on the forums, but I have been reading a lot. Thank you for being such an helpful community. Please be patient, I'm not that much familiar with Gamemaker.
I have been trying for a few days to figure out a grid system for an exploration/city building game prototype.
The exploration part means that the player is represented on the map and freely moves around a generated world made of regions, chunks, and tiles.
The city building part means that each tile needs to have a properties ( type, resource generation, sprite, etc) that can be modified and accessed. Building is done by getting the coordinates of the tile the mouse is in, and modifying the corresponding tile.
For a building that is bigger than a tile, there is an origin tile. The origin tile and the surrounding tiles are modified to assemble the building.
But let's talk about the grid system
In my previous version I created chunks with a DSgrid and each chunk was its own object. But it did not work well for buildings that are in multiple chunks.
So I tried to design a more reliable grid system that does no need objects for everything, and this is what I came with, but I don't know if this is feasible:
In this system, properties are nested and use a system of coordinates:
and so for example, to build this building, I would need to edit (removing the intermediate lists for clarity):
- (bottom-left) tile[3,2] ; chunk[25,12] ; area[1,1]
- (bottom-right) tile[0,2] ; chunk[26,12] ; area[1,1]
- (top-left) tile[3,1] ; chunk[25,12] ; area[1,1]
- (top-right) tile[0,1] ; chunk[26,12] ; area[1,1]
As for the generation itself, I would create all the grids at the generation of the world, then fill them when needed (radius around the player).
I am worried though, because that is a grid per tile + a grid per chunk + a grid per region.
For a world that is 16 regions, with regions that are 16 chunk large, with chunks that are 16 tiles large, with tiles that are 64px large:
- REGIONS - 16x16 grid (256 positions)
- in each position a list
- CHUNKS - in each list a 16x16 grid (256 positions)
- in each position a list
- TILES - in each list a 16x16 grid (256 positions)
- in each position a list
- REGIONS - 1 16x16 grid
- 256 lists
- CHUNKS - 256 16x16 grids
- 65 536 lists
- TILES - 65 536 16x16 grids
- 16 777 216 lists
- and 262144x262144 room size
An easy way would be a small map like old Zeus and Cleopatra game. But I'll be loosing the exploration aspect of the idea.
I wonder if some of the final steps need to be buffers instead of grids and lists. (Probably both chunk and tile level) But I also like the operations possible with grids as it can be really helpful for generating the terrain.
I also thought of bigger grids with two of the size level inside, It is probably a good way to avoid having too many grids.
But wonder if I can get the same unified coordinates system with those. Which is my bigger concern.
I think this could work, but I do not have enough experience in Gamemaker to know if this is the right way to do it.
So I'm asking the community:
- What do you think of this way to generate the world (concept)
- Do you think it would work in Gamemaker (1.4) (feasibility)
- In terms of optimization, (given that I plan to save in a file and delete inactive tiles/chunks/regions) is this too many grids ?) (optimization)
- Would you be interested in the progress of the project (follow-up)
Last edited by a moderator: