SP: Improve "Hub" levels

[mrwonko]

By using the HUB Spawnflag on a target_level_changer, you can save a level's state and restore that on a subsequent load. This allows for a lot of cool stuff in mods, like splitting big levels in multiple parts.

The technical realization leaves room for improvement though: The level's state as you exit it is saved to save/hub_.sav - the obvious problem here being having multiple parallel playthroughs - you can't save two different states of the map.

I propose a playthrough GUID that is kept across level changes and saved/loaded, but renewed when starting a map via console or the New Game option. This would be used for the hub savegame names, and could incidentally also be used for auto- and quicksaves.

[dusty22]

Don't quite understand everything you're talking about, but it sounds like a good idea!

[cadika-orade]

I think I see what he's talking about and I support it entirely. I love large maps, but sometimes they tend to crash for random reasons. Jurancor Park is one of the worst for me. With this, a large map could be chopped into pieces and when a player walks through a specific door and a new map loads, the state of the previous map is saved so that when you walk back the way you came, into the previous map, everything is how you left it and your player doesn't spawn at the start of the map.

@mrwonko Perhaps the saves could be tagged with a unique ID assigned at the start of a new game? Then it would be simple to identify which saves are part of the same playthrough. Reloading a past save would change this ID for subsequent saves.

[mrwonko]

Perhaps the saves could be tagged with a unique ID assigned at the start of a new game?

That's just what I was talking about - a globally unique identifier, or GUID. As for reloading changing it... I had not thought about that. But yes, whenever the player saves or loads we'd really need to generate a new GUID and clone all saves of the previous one?

[cadika-orade]

I was trying to figure out how to manage a branching GUID linking system, but cloning would make sense.

You are talking someone who developed a chess variant that implements time travel. the implications of this proposed saves system are fascinating.

[mrwonko]

You are talking someone who developed a chess variant that implements time travel.

😆 This is offtopic, but ever tried Achron? Multiplayer time-travel strategy game. Might suit you.

[cadika-orade]

Woah. My mind is blown right now.

Thank you, sir! If it were free I'd be playing it already!

[cadika-orade]

Coming back on-topic: Any progress with this?

I am attempting to rework a few parts of the engine to make a game of my own design, and this feature is fairly key to the game. Also, is map pre-loading plausible? I.e. it opens and begins caching the next map when you approach the portal, making the transition almost seamless.

[shinyquagsire23]

@cadika-orade
You could always make it more of a KOTOR style game with a loading screen while the next map loads and an advice/tip to read while it loads. But the only problem I see with precaching is that if the player steps away from the portal you've got a bunch of stuff to clean up. But yes, precaching could improve the speed of the loading screen.

[eezstreet]

Should be fairly simple. The only thing would be the saving/loading routine as well as GUID generation.

Sent from my Windows Phone

---

From: cadika-orademailto:notifications@github.com
Sent: ‎5/‎15/‎2013 10:03 AM
To: Razish/OpenJKmailto:OpenJK@noreply.github.com
Subject: Re: [OpenJK] SP: Improve "Hub" levels (#77)

Coming back on-topic: Any progress with this?

I am attempting to rework a few parts of the engine to make a game of my own design, and this feature is fairly key to the game. Also, is map pre-loading plausible? I.e. it opens and begins caching the next map when you approach the portal, making the transition almost seamless.

---

Reply to this email directly or view it on GitHub:
#77 (comment)