Legacy GM Infinite worlds! Help

J

justin

Guest
I'm a decent programmer not the best* My game is a 2D game to where you are in a sky view and you are a commander of a base. You can train troops and what not. So there will be a sandbox mode to where you can conquer basically a never ending world. So my problem is being able to see everything would crash the game or what the camera can see but my thought is what if the troops have sight* to where the game will only generate what the troops can see. New issue, if the player kept expanding and expanding than the game would crash. So the game
Would need to delete chunks or I'm
Confused would someone mind helping? Thanks
 
W

whale_cancer

Guest
That is a BIG question and depends a lot on how you have programmed various aspects of your game.

What you probably want to do is learn how to deactivate and activate instances (instance_activate_region, instance_deactivate_region, etc.,).

When I was using a lot of objects (too many, I was using them as map tiles!), I would simply deactivate all objects beyond a certain distance from my viewpoint and then activate those within a given range of my viewpoint. That way the game was only handling local objects, despite remembering where the other ones are.

Hope that helps.
 
J

justin

Guest
That is a BIG question and depends a lot on how you have programmed various aspects of your game.

What you probably want to do is learn how to deactivate and activate instances (instance_activate_region, instance_deactivate_region, etc.,).

When I was using a lot of objects (too many, I was using them as map tiles!), I would simply deactivate all objects beyond a certain distance from my viewpoint and then activate those within a given range of my viewpoint. That way the game was only handling local objects, despite remembering where the other ones are.

Hope that helps.
Thank you but I'm a bad programmer and yes as everyone bodies told me "don't do this idea to hard" oh well. Right anyways so how hard is that to learn?
 
W

whale_cancer

Guest
Thank you but I'm a bad programmer and yes as everyone bodies told me "don't do this idea to hard" oh well. Right anyways so how hard is that to learn?
It's fairly simple, just give it a try!

That being said, your game idea is very ambitious. If you are still learning, it is often better to do smaller, simpler games as a learning exercise, rather than launching into some epic idea that will require you to learn a LOT along the way.
 
J

justin

Guest
Thank you but I'm a bad programmer and yes as everyone bodies told me "don't do this idea to hard" oh well. Right anyways so how hard is that to learn?
And I have not coded a single thing... Still on graphics
 
C

ConsolCWBY

Guest
Here's some stuff to help you get the ideas of how to do this:
SIMPLE EXPLANATION
RESOURCES
Beyond this, I wouldn't know how to implement this stuff in GML.. yet. Hope you find what your looking for!
 
J

justin

Guest
It's fairly simple, just give it a try!

That being said, your game idea is very ambitious. If you are still learning, it is often better to do smaller, simpler games as a learning exercise, rather than launching into some epic idea that will require you to learn a LOT along the way.
also one more thing if I were to made villages how would I do this?
 
J

justin

Guest
It's fairly simple, just give it a try!

That being said, your game idea is very ambitious. If you are still learning, it is often better to do smaller, simpler games as a learning exercise, rather than launching into some epic idea that will require you to learn a LOT along the way.
So beyond that how hard is random world generation?
 
For my game, I use a chunk based system. Only the chunk in view + the 8 neighbor chunks are active at a time. I store each chunk as a text file holding a json string of all the objects in the chunk. Any variables needed are stored here as well. Then you just import/export chunks as the view moves. The only downside is I have to create the world outside the room editor so I had to create a level editor. For your world though, if it's randomly generated, it's just a matter of checking if a chunk exists and if not, randomly generate it. If it exists, just import it. The details all depend on how much your game can handle at once. For example, you may leave more chunks active if there is less demanding processing running to keep the world feeling more alive if you go back and forth a lot. Or chunk size could be larger if you have less objects per chunk and load time isn't to expensive. Filenames are key so you only grab the file you need instead of checking all the files until you find the right one. I save files as "x_chunk x_y_chunk y.chnk". So the first chunk I load is x_0_y_0.chnk.
 
J

justin

Guest
"Villages" could be implemented in any number of ways. There is no easy answer to this.

The manual, tutorials, and experimenting is how I learned GM.

It's hard to do well.
So my idea is possible but it won't be easy is what your saying?
 
W

whale_cancer

Guest
So my idea is possible but it won't be easy is what your saying?
Yes. GM is fairly powerful, but given your questions you will need to learn a lot to make your idea a reality.
 
J

justin

Guest
For my game, I use a chunk based system. Only the chunk in view + the 8 neighbor chunks are active at a time. I store each chunk as a text file holding a json string of all the objects in the chunk. Any variables needed are stored here as well. Then you just import/export chunks as the view moves. The only downside is I have to create the world outside the room editor so I had to create a level editor. For your world though, if it's randomly generated, it's just a matter of checking if a chunk exists and if not, randomly generate it. If it exists, just import it. The details all depend on how much your game can handle at once. For example, you may leave more chunks active if there is less demanding processing running to keep the world feeling more alive if you go back and forth a lot. Or chunk size could be larger if you have less objects per chunk and load time isn't to expensive. Filenames are key so you only grab the file you need instead of checking all the files until you find the right one. I save files as "x_chunk x_y_chunk y.chnk". So the first chunk I load is x_0_y_0
Well In the game you'll have individual troops who can move so each one would have to have a chunk so would this kill the game?
 
J

justin

Guest
Yes. GM is fairly powerful, but given your questions you will need to learn a lot to make your idea a reality.
One more thing the things are created chunk by chunk, so hostile AI villages wouldn't be able to defend them selves really, or could I do a create event then say spawn 4 tiger tanks at target x,y?
 
W

whale_cancer

Guest
One more thing the things are created chunk by chunk, so hostile AI villages wouldn't be able to defend them selves really, or could I do a create event then say spawn 4 tiger tanks at target x,y?
Using chunks/activating and deactivating instances would mean you couldn't simulate anything going on beyond the area that is actively loaded. You could load a chunk that is far away from your POV, but that ends up requiring some fairly sophisticated simulation of your world.
 
J

justin

Guest
Using chunks/activating and deactivating instances would mean you couldn't simulate anything going on beyond the area that is actively loaded. You could load a chunk that is far away from your POV, but that ends up requiring some fairly sophisticated simulation of your world.
Alright well.. One more question so in the game there will be 4 materials steel gold wood and food. Which resource vehicles will go to and then go back to your city. How hard would this be when the car is built it drives around until it finds a resource area then it loads up and heads home
 
Well In the game you'll have individual troops who can move so each one would have to have a chunk so would this kill the game?
In an infinite world situation, probably. Over time your game would get slower and slower. Best option for this would be only having chunks active in view but as you load chunks, simulate the time passed. If the player can't see the chunk, whatever you simulate would feel as if it has been happening the whole time but to save processing for what the player is currently seeing only have what the player sees run. Then you can take advantage of a chunk system even with a world that is infinite. Option 2 would be to limit the size of the world.
 
J

justin

Guest
In an infinite world situation, probably. Over time your game would get slower and slower. Best option for this would be only having chunks active in view but as you load chunks, simulate the time passed. If the player can't see the chunk, whatever you simulate would feel as if it has been happening the whole time but to save processing for what the player is currently seeing only have what the player sees run. Then you can take advantage of a chunk system even with a world that is infinite. Option 2 would be to limit the size of the world.
What if each troops could only see one chunk? Would this help? And how hard would this be to code?
 
J

justin

Guest
And one more question if a players troop where to find a fortress but the bad troops come to kill the player troop if the players troop exits that render area does the fortress and the bad troops just poof? Or I'm kinda confused
 
C

ConsolCWBY

Guest
Only part of the world would be active at any one time. You could do a background simulation - but not infinitely. The current place where the player is would be the active chunks. Persistence is the problem - and it's not an easy solution. If the player were to leave a sector, the chunk could be saved - but time would keep running, and if the entire chunk were loaded again (like a saved game), then it would be as if no time had passed. Therefore, you could run a background simulation of it; but without explicit multithreading, several simulations would kill the game (depending on the level of abstraction). The links I gave you, particularly the second one, is filled with ideas and even implementations in C++, Java, and python. Look them over, because if you think this is easy - this is hard core computer science and mathematics. But like I said, you can look at implementations and get a great overview without the hassle of school. :)
 
J

justin

Guest
Only part of the world would be active at any one time. You could do a background simulation - but not infinitely. The current place where the player is would be the active chunks. Persistence is the problem - and it's not an easy solution. If the player were to leave a sector, the chunk could be saved - but time would keep running, and if the entire chunk were loaded again (like a saved game), then it would be as if no time had passed. Therefore, you could run a background simulation of it; but without explicit multithreading, several simulations would kill the game (depending on the level of abstraction). The links I gave you, particularly the second one, is filled with ideas and even implementations in C++, Java, and python. Look them over, because if you think this is easy - this is hard core computer science and mathematics. But like I said, you can look at implementations and get a great overview without the hassle of school. :)
So there's no easy solution is what your saying?
And if I were to save and load chunks would this absolutely kill your PC?
 
What if each troops could only see one chunk? Would this help? And how hard would this be to code?
It might help but at the same time, if you mean keeping chunks active because troops can see that chunk, the game could potentially have more and more chunks active at once.

Here is a tutorial on game save/load.

It's not exactly what you need but it's a good start. Part 1 is similar to what I did. It's definitely not easy to do this but there are harder games to make. I wouldn't recommend this if it's a first game.

Chunk systems are based on view. If the enemy fortress is on your screen, it stays.

Here are some pictures to help explain the idea. Check out the bottom ones of the post. The monitor is the view and the surrounding chunks are active. As the view moves, the surrounding chunks change and so some are loaded and some are exported.
 
J

justin

Guest
It might help but at the same time, if you mean keeping chunks active because troops can see that chunk, the game could potentially have more and more chunks active at once.

Here is a tutorial on game save/load.

It's not exactly what you need but it's a good start. Part 1 is similar to what I did. It's definitely not easy to do this but there are harder games to make. I wouldn't recommend this if it's a first game.

Chunk systems are based on view. If the enemy fortress is on your screen, it stays.

Here are some pictures to help explain the idea. Check out the bottom ones of the post. The monitor is the view and the surrounding chunks are active. As the view moves, the surrounding chunks change and so some are loaded and some are exported.
so is this possible idea or? And if a player were to see a village can you set the village to have a timer that creates enemy units, but the village will be captured / destroyed
 

HayManMarc

Member
I believe your idea is too ambitious for you if you have no coding knowledge. This has the potential of causing you much frustration when learning to code. I suggest you think of something simpler to try, like a side scrolling shooter or a runner/dodge 'em game. Even half-way experienced programmers have troubles/issues with open world's.

Just saying' and offering a friendly suggestion. I'd hate to see you burn out before you even really get started.
 
J

justin

Guest
I believe your idea is too ambitious for you if you have no coding knowledge. This has the potential of causing you much frustration when learning to code. I suggest you think of something simpler to try, like a side scrolling shooter or a runner/dodge 'em game. Even half-way experienced programmers have troubles/issues with open world's.

Just saying' and offering a friendly suggestion. I'd hate to see you burn out before you even really get started.
Well right now that's what I want to do, that game idea and I'm sorry but it ain't changing trust me I'll find a way to get it done, sorry if I sound bitter but I'm going to do this game
 

HayManMarc

Member
Well right now that's what I want to do, that game idea and I'm sorry but it ain't changing trust me I'll find a way to get it done, sorry if I sound bitter but I'm going to do this game
OK! :) Determination is a good quality. Make it fun and I wish you well!
 
Top