• 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!

(solved)I need a second opinion about my complex game mapping design

I have a game that I have been working on for more than 20+ years, originally designed on a Commodore Amiga which I had to survive from PC to PC, after Commodore Business Machines went out of business. Since then I had to learn C which saved me from the insanity of BASIC. So I have been working on this game at the planning stage because since then, technology and software have changed. I created two C programs ( random generator programs ) that would build me the game data map details for my game that I was designing, because without it the data map, the game would not have an environment for the player. So now that I have GMS , I have been reworking my game and planning, to work with GMS.

I decided that I would explain the entire structure of my data system ( which is just the tip of the iceberg ) on this forum, about the basics of its map organization.

In my game , the environment of mapping system is contained in what I call the Universe Deck. The Universe Deck, can be thought of a deck of cards standing upright . In this deck, you have 1000 universe fields which are 2D , which can be thought as a card of the deck. Each universe field is represented as a 2D size of 20 x 20 units, in which each unit are called intergalactic fields. Each intergalactic field has a 2D size of 100 x 100 units, in which each unit can be a location for a galaxy unit or a void. A galaxy unit, can come in different sizes , and depending on those sizes, determines the size of the cut section of the galaxy, called the starfield. Starfields are also a 2D map, representing what is further broken down , called sectors. The sectors are 2D size of 10 x 12 intrasectors. Each of 10 x 12 intrasector units, represents a 2D map size of 60 x 60 zones. In each of these zones there can be a solar system, a asteroid field, a ice asteroid field, a nebula field, worm holes, black holes, and other things that I can define. Again this is all created by the random data generator. This not the full extent of the mapping system, because mapping system continues into each solar system, for each planetary system of every orbiting planet and moon, and further on. So let me go back to what I want to do, with the intrasectors of my mapping system.

I first need to use GML create a series of random data generator programs to create each part of the complex map structure that my game uses. The random data generators, which are part of my game, are used randomly create what is called the intrasector deck , which is 1000 units of 60 x 60 2D maps. The index number in this 3D array is what is used to construct the next larger piece of the map called the sector. A sector consists of a map grid of 10 x 12 intrasectors. Then from there, another random data generator uses references to the index number of intrasector deck, to randomly create 1000 units of sectors, create a sector deck. In the same way like the intrasector deck, the sectors index value of that 3D array is used to randomly create the starfield. Then from there another random data generator, randomly creates each starfield ( depending on the starfield size , which is dependent on the galaxy size ) using the index references to the sector deck. Depending on the galaxy size, the same random data generator will repeat making starfields data sets to represent the area of the galaxy. The galaxy unit which is created , is referenced by its location on the hard drive, by a specialized directory system, and is numbered from 1 to 2500. Each intergalactic field can support up to 2500 galaxy units, each unit on the 2D map is either galaxy or a void. Each intergalactic field represents one unit out of the universe field which is a 20 x 20 2D map. This is just part of what I am trying to do for the whole mapping system. Again, this is just the tip of the iceberg of my game idea.

To explain it easier, I constructed a picture diagram of the mapping system ( long ago ), which is now out of date to what I have planned out now. I have been changing my game design but the map design shows how everything fits together in my plan as a rough draft. Don't confuse what I have written above for values with the picture. Please note sideways 8s are meant to be interpreted as infinity symbols.

see picture:

universe6g1.gif


So am back to my main problem which is using 3D arrays for the deck mapping sets, to construct this system of maps in. GML does not provide an easy way to do this, so I think I have to come up with another way to do this and thats where I am stuck. Please note, I did not give all the details because of the complexity of my game design which is at the planning stage, which revolves around what I can and cant do with GMS.

I know how to do this when I program in C, but not in GML because of the problems GML has with accessing individual values in a array , especially if its a 3d array. So I am wondering if there is another way I can do this using the DS Grid data structure or some other way.

A second opinion would be appreciated.

Thanks.
 
Last edited:
L

Ludo Design

Guest
So what you're saying is, working from inside out... (I'm trying to understand this project, here)
  • There is a list of a random number of celestial bodies for every planet ("planetary system," as you called it); the celestial bodies maintain a starting orbit location, orbit speed, and other random information.
  • There is a list of a random number of these planetary systems for every solar system, which contains at least one star and maybe an asteroid belt. Each planetary system maintains an orbit location and orbit speed.
  • Solar systems are just one of several possibilities within its zone unit. Zone units are contained within a sector unit, a 2D grid of size 60x60.
  • These 2D grid Sector units are the units of a Starfield, a cell within a galaxy. The variety in starfield sizes is really just a variety of galaxy sizes. Galaxy size is a 2D grid (starfield) in a list of 20 slices of the galaxy.
  • A galaxy can randomly be generated in the cell of an intergalactic field, a 2D grid of size 120x120.
  • Each intergalactic field is a cell in a 2D grid of a universe field, a 2D grid of size 20x20.
  • Finally, we have the universe deck, a simple 1D list of universe fields.
Or, in simple words that illustrate the complexity of your data structure.
  • A 1D list (deck)
    • of 2D grids (20x20, universe field)
      • of 2D grids (120x120, intergalactic field)
        • The cells of the inner grid may contain a list (20 galaxy slices)
          • Each list item contains a 2D grid (size depends on the galaxy size)
            • The cells of this grid contain a 2D grid (60x60, sector unit)
              • The cells of this grid contain a list (varying size, solar system)
                • within this list, there is a random chance you'll need another list (varying size, planetary system)
                  • said list containing a planet and its celestial bodies

And you want to program this in Game Maker. Doable, although I do not recommend containing absolutely everything within one data structure like I've described above.
 
Last edited by a moderator:
So what you're saying is, working from inside out... (I'm trying to understand this project, here)
  • There is a list of a random number of celestial bodies for every planet ("planetary system," as you called it); the celestial bodies maintain a starting orbit location, orbit speed, and other random information.
  • There is a list of a random number of these planetary systems for every solar system, which contains at least one star and maybe an asteroid belt. Each planetary system maintains an orbit location and orbit speed.
  • Solar systems are just one of several possibilities within its zone unit. Zone units are contained within a sector unit, a 2D grid of size 60x60.
  • These 2D grid Sector units are the units of a Starfield, a cell within a galaxy. The variety in starfield sizes is really just a variety of galaxy sizes. Galaxy size is a 2D grid (starfield) in a list of 20 slices of the galaxy.
  • A galaxy can randomly be generated in the cell of an intergalactic field, a 2D grid of size 120x120.
Actually this is now 100 x 100 .....

  • Each intergalactic field is a cell in a 2D grid of a universe field, a 2D grid of size 20x20.
  • Finally, we have the universe deck, a simple 1D list of universe fields.
Or, in simple words that illustrate the complexity of your data structure.
  • A 1D list (deck)
    • of 2D grids (20x20, universe field)
      • of 2D grids (120x120, intergalactic field)
        • The cells of the inner grid may contain a list (20 galaxy slices)
          • Each list item contains a 2D grid (size depends on the galaxy size)
            • The cells of this grid contain a 2D grid (60x60, sector unit)
              • The cells of this grid contain a list (varying size, solar system)
                • within this list, there is a random chance you'll need another list (varying size, planetary system)
                  • said list containing a planet and its celestial bodies

And you want to program this in Game Maker. Doable, although I do not recommend containing absolutely everything within one data structure like I've described above.
Your basing your observation from the picture.. note this has changed , and it is deeper than that.

The organization goes deeper into the planet types and moon types, cities, city layouts, and buildings and their floor plans, which I am still planning out. However, what you see what I have done so far for this organization, thats why I needed a second opinion about the data structure. I have reached the same conclusion. It is doable, but its a headache if I get into trouble. But the amount of space that I need for the data is what is at question. My game is more complicated than what I have described, and consists of 60+ subgames of different complexities that share almost the same resources.
 
L

Ludo Design

Guest
This sounds like a very ambitious project, you've got, here.

Without more information about the game's scope, it's hard to suggest exactly what you need. But it feels very similar to Dwarf Fortress in how it generates all of its towns and people and buildings, as well.

All that is needed is a generic resource file structure. A folder for cities, a folder for planets, a folder for moons, etc. Each file could contain their properties.

What's probably more important is how the information is loaded and saved. You'll need a function for accessing your resource files (with intent to write) according to specific terms, and perhaps another function for simply reading a property of a specific resource, in case another part of the game only needs to know a specific piece of information of some sort. One way you could go about this is to have a resource index file, a simple file that is generated when the world itself is generated, and is updated with any newly added resources in the game. This resource index file could be used to quickly find the exact file path for the resource file you're looking for. You'll need an active list to keep track of all the things that have been edited in the current game session, and whether you use autosaving or have a manual save feature, the saving function should depend on that mechanic.

This probably all sounds like really generic information, of course, and a lot of this advice is part speculation and partly just from the top of my head.
 
I was planning to build the data files , by first creating a deck of 1000 intra-sectors, and by using the index value of that , have a program create sector files, by randomly choosing the index number of the inter sector files, to create a deck of 1000 sectors, each map composed of 10 x 12 intra-sector maps. Its like a grid of numbers ( like a BINGO game ) where the numbers of the sector map arel references to the intra-sector maps. This how the starfield map is created just like sector map, where the number of each sector in the starfield ( just like a BINGO game ) are references to index numbers of the sector deck. The number of starfield created is unique depending on the starfield size. If you notice in my old diagram, there are different galaxy sizes.

This is my current work on the map organization that I am using now :

WOTF_table1.PNG

In case your wondering what the hinge sector is.....

The hinge sector is the center sector of the galaxy, but on the starfield map is always the on the last, right column, of every starfield map in the center which is why a G-1 galaxy or a 1x1 starfield cant have a hinge sector because it occupies the same space as the hinge sector. If you look at the old map that I created showing how each map , you will see what I call the, cake mapping system , where I show the cut away view. G-1 galaxy or a 1x1 starfield represents the location of the hinge sector for all galaxy and starfield types. The cake mapping system, is the only way I could explain how the starfields relate to the galaxy, its just one side of the galaxy from the center axis, represented as a cake slice, that is further divided up into the individual starfields. So the bigger the galaxy the more starfields there are.

Another way to look at is to take a spiral bound note book and turning the book inside out, by closing the back and the front cover together and allowing the sheets of blank paper to spread out at different angles. The spiral center is the center of the galaxy, and the pages are the starfields that connect to the center.
 
Last edited:
Top