GMS 2 Planning: Maintaining surface world when entering a dungeon

Papa Doge

Member
Hello,

I'm at a critical point in my game's development where I'm starting to get into scaling and performance issues. I've coded myself into a hole so to speak with some previous features that resulted in costly refactors. To learn from my mistakes, I'd like to do better planning before I work on this next feature:

Random dungeon instances

The game I'm working on has a very large surface world and tons of stationary and dynamically positioned instances. It works like the game Forager where the player is unlocking new islands to expand their base. Also like Forager and other games like Swords of Ditto, I want to design little dungeon instances that occur randomly on the surface world.

I've been reading the manual and some existing forum topics and see that there are a variety of tools at my disposal like room_persistent and instance_deactivate_all();

While I'm not ready to start designing and implementing these dungeons in my game I'm cognizant of the fact that I need adding new objects and behavior to the surface world all the time and I'm starting to worry that when I go to implement a solution that I'll have to do a major overhaul of how the rest of my game works.

When entering a dungeon I'd the following to happen:

1. Time on the surface world freezes
2. Any in progress actions, like a structure printing something, will also freeze
3. When the payer returns to the surface world, there's a random roll that adds extra instances to fake the passage of time and all existing instances continue as normal.

My questions are...

1. What are the different kinds of solutions that are most common for this problem?
2. What are the pros and cons of these solutions?
3. What kinds of pitfalls should I be avoiding while I work towards this feature?
 

2DKnights

Member
I think instance_deactivate/activate functions are the way to go. keep in mind that deactivated instances still use memory, but their events are skipped for processing.

Id say try that first and if performace doesn't take a hit consider it solved.

If you didn't want to do that then you can use "with all" to run code relative to all instances and save what you need for each object including the object_index to a file and reconstructing when you reload the overworld. The only issue here is the amount of work that may be needed to save everything, but memory use and performance won't be impacted at all

Thirdly there's the persistent room, this will have the easiest implementation, but the least amount of control. Memory usage will be larger then the other two methods but again is performance is not hindered then it's viable
 
Last edited:
Top