Idea Need suggestions to make the game more effective

River

Member
Hi, I'm working on a survival game right now, I went through Don't Starve and wanted to find a hint for my game. According to you, in the game don't starve, the land they make will use background (tiles) or object? Currently, my game is working, the land I think will be the object, because using only 1 object I can replace images such as excavated soil, watered soil, soil for planting ā€¦ because if using ground as background (tiles), then dig the soil to plant trees, default also will have to create soil objects. What I'm interested in is: I will create a very large map like don't starve game, maybe the size will be: width: 50000 and Height: 50000 and there will be hundreds of thousands of objects, of course I will too: use instance_deactivate_object and instance_activate_region to prevent game lag. I have read through "Optimizing Your Games" here: Optimizing Your Games . But I still want to know if with a huge map room and hundreds of thousands of objects like that, can my game still run smoothly without lag? And as I mentioned above, is it good for the ground to make 1 cell into 1 object (meaning that the soil covering the room will be the object soil plots) is it good? Or should we still use the ground and the background, when do we plant trees or dig the soil to create objects? Which way will be more effective? Thank you everyone for your comments.
 
T

Tristan

Guest
Never played don't starve, so I can't help you there. But here's the advise and lag. Don't worry about it. Dumb? no, there is a quote that goes something like "optimization is the root of all evil" -someoneidontknowthenameof. Unless your game IS lagging now, your fine. Seriously, unless each object is running collision code or massive for loops you can just make a empty room and spam your objects around and see if it lags.
 

Alice

Darts addict
Forum Staff
Moderator
The exact quote is "Premature optimization is the root of all evil" (attributed to Donald Knuth). And in this case - when the author plans 50k x 50k map - I don't think the optimisation is premature.

Personally, I'd be wary of handling such a massive map all at once - 50k x 50k means 2500m, so if each cell information took only one byte, the whole map would take whooping 2.5GB of memory. The memory is cheaper now than it has been in earlier days, and usually computational processing time it more of a concern, but in this specific case you might want to slow down with loading such a massive thing all at once.

Maybe try splitting the game region into smaller maps (I dunno, 500x500 is already pretty sizeable, with 250k cells) and generate more areas as you play? You might still need to save each area the player visits, but this kind of incremental approach should be easier on both the runtime memory and disk storage. You might also cap the world size by generating "rooms" layout upfront - along with which room should connect to another - and generate newly visited room so that they respect the connection rules. That way you can ensure the world never gets larger than, say, 100m cells, which should make save files potentially lighter as a result. If certain parts of layout are randomly generated but never change aftereards (e.g. land + water + mountains or something) you might also save a random seed used to generate them which would be dirt-cheap to store, but you'd also need to have an RNG of your own so that it works consistently across platforms. Still, large sequences of same kind of terrain should be easily represented by something like "W123L45W34M12W12", with numbers corresponding to how many units of specific terrain should be added. So if you want to store the maps without taking too much drive space, there are various options.

As for the game itself, personally I'd opt for creating a grid (or several grids) with width and height the same as the map size. Then, based on data of these grids and on current camera positions, I'd determine how many cells are "in view" and draw only them.

If there are more interactible or animated entities, I could also setup corresponding objects and either activate/deactivate them (as your original idea) or create/destroy them depending on whether they are roughly on screen or not. Or, if these objects are scarce enough, I would keep them activated (so that they can still participate in interactions and proceed with their animations or whatever) but instead prevent drawing them when they are off-screen. Limited time animations/effects like tree falling down or grain being harvested should be so relatively rare and short-lived that you won't need to bother activating/deactivating them; just let them play out and destroy them afterwards.

So yeah, the general takeaway is:
- 50k x 50k is a lot, you don't want that kind of map loaded all into your memory, and might instead want to split it into other areas
- 500 x 500 is more manageable, but you still want to limit the amount of cells and objects being drawn
- the general terrain (waters, lands, mountains etc.) should probably be handled by a ds_grid rather than individual objects, since an object can add quite a large memory overhead
- objects that are relatively frequent compared to the number of cells but are simple counterparts of cells might need to be created/destroyed depending on whether they're on screen or not (something like high grass that adds an animation and sound effect when walked through)
- if certain objects are somewhat rarer compared to the number of cells might be deactivated when off-screen, or even just keep going as usual but don't draw when off-screen (maybe something like monsters? I dunno)
- short-lived objects can just be kept active and drawn, since they're likely infrequent enough not to be a problem

The rule about "premature optimization being the root of all evil" still stands. It's best if you play around with whatever sized maps you'll create and see whether the performance stays at acceptable levels or drops too much, and then try to employ some optimisation strategies.
 
T

Tristan

Guest
Everything that Alice said is correct, but I'm going to throw this out there anyway (I just remembered it). Hope it helps a little.


Also thanks for the full quote Alice. :)
 

River

Member
The exact quote is "Premature optimization is the root of all evil" (attributed to Donald Knuth). And in this case - when the author plans 50k x 50k map - I don't think the optimisation is premature.

Personally, I'd be wary of handling such a massive map all at once - 50k x 50k means 2500m, so if each cell information took only one byte, the whole map would take whooping 2.5GB of memory. The memory is cheaper now than it has been in earlier days, and usually computational processing time it more of a concern, but in this specific case you might want to slow down with loading such a massive thing all at once.

Maybe try splitting the game region into smaller maps (I dunno, 500x500 is already pretty sizeable, with 250k cells) and generate more areas as you play? You might still need to save each area the player visits, but this kind of incremental approach should be easier on both the runtime memory and disk storage. You might also cap the world size by generating "rooms" layout upfront - along with which room should connect to another - and generate newly visited room so that they respect the connection rules. That way you can ensure the world never gets larger than, say, 100m cells, which should make save files potentially lighter as a result. If certain parts of layout are randomly generated but never change aftereards (e.g. land + water + mountains or something) you might also save a random seed used to generate them which would be dirt-cheap to store, but you'd also need to have an RNG of your own so that it works consistently across platforms. Still, large sequences of same kind of terrain should be easily represented by something like "W123L45W34M12W12", with numbers corresponding to how many units of specific terrain should be added. So if you want to store the maps without taking too much drive space, there are various options.

As for the game itself, personally I'd opt for creating a grid (or several grids) with width and height the same as the map size. Then, based on data of these grids and on current camera positions, I'd determine how many cells are "in view" and draw only them.

If there are more interactible or animated entities, I could also setup corresponding objects and either activate/deactivate them (as your original idea) or create/destroy them depending on whether they are roughly on screen or not. Or, if these objects are scarce enough, I would keep them activated (so that they can still participate in interactions and proceed with their animations or whatever) but instead prevent drawing them when they are off-screen. Limited time animations/effects like tree falling down or grain being harvested should be so relatively rare and short-lived that you won't need to bother activating/deactivating them; just let them play out and destroy them afterwards.

So yeah, the general takeaway is:
- 50k x 50k is a lot, you don't want that kind of map loaded all into your memory, and might instead want to split it into other areas
- 500 x 500 is more manageable, but you still want to limit the amount of cells and objects being drawn
- the general terrain (waters, lands, mountains etc.) should probably be handled by a ds_grid rather than individual objects, since an object can add quite a large memory overhead
- objects that are relatively frequent compared to the number of cells but are simple counterparts of cells might need to be created/destroyed depending on whether they're on screen or not (something like high grass that adds an animation and sound effect when walked through)
- if certain objects are somewhat rarer compared to the number of cells might be deactivated when off-screen, or even just keep going as usual but don't draw when off-screen (maybe something like monsters? I dunno)
- short-lived objects can just be kept active and drawn, since they're likely infrequent enough not to be a problem

The rule about "premature optimization being the root of all evil" still stands. It's best if you play around with whatever sized maps you'll create and see whether the performance stays at acceptable levels or drops too much, and then try to employ some optimisation strategies.
Your suggestion is very good to me, thank you so much.
 

Yal

šŸ§ *penguin noises*
GMC Elder
Wave Function Collapse is a new up-and-coming procedural generation technique that lets you generate data that matches existing data at the edges, it would work perfectly for a "generate things only when needed" approach:
 

River

Member
Wave Function Collapse is a new up-and-coming procedural generation technique that lets you generate data that matches existing data at the edges, it would work perfectly for a "generate things only when needed" approach:
Thanks for your suggestion
 
Top