0
\$\begingroup\$

I have already implemented a checkpoint system that respawns the player at the last checkpoint they cross through. Now imagine this:

  • NPC A interacts with NPC B
  • NPC B walks over to a nearby car
  • A bird flies over the car and takes a dump
  • Player dies tragically (lol)
  • Player respawns at the last checkpoint X

Given that checkpoint X is achieved after watching all these NPC interactions, how can I fast forward/skip these interactions when respawning the player? The build I have right now respawned at the correct location but of course, the NPC interactions happen again even though they were supposed to end before reaching that last checkpoint (if that makes any sense 😀 )

I understand that this can be achieved by saving all the last known locations of the NPCs, flags that indicate whether the bird took a dump (true/false). For example, this seems quite tedious for a game like Uncharted/GTA where a lot of interactions happen at the same time.

My initial thought was to somehow fast forward the entire game to a point where all these interactions are done and dusted. That way, I can safely respawn the player knowing that they don’t see something they’ve already seen.

Sorry for the detailed post 😀 Any tips on how this can be accomplished?

\$\endgroup\$
3
  • 1
    \$\begingroup\$ How do you currently manage the state of these NPC interactions / cutscenes /.etc? The better we understand that, the better we can suggest how to integrate it into.your checkpoint save system. \$\endgroup\$ Commented Jan 26, 2019 at 9:39
  • 1
    \$\begingroup\$ Welcome. You have to define carefully which members of your classes needs to be saved and restored on savegame, or dump everything into your save file if you think you may forget about future modifications to your classes. Probably inefficient storage wise, but integrity safe. If you go the "smart" way, you can skip things that are calculated from other things and for most games probably all engine low level stuff. Also, you can skip trivial/decorative things (nobody cares if the clouds in the sky start at the exact point they were at the previous save and probably nobody can remember it). \$\endgroup\$ Commented Jan 31, 2019 at 2:50
  • \$\begingroup\$ Also, you probably want the full scene graph, this is all NPCs and player characters, the camera, all nodes except for things that can be calculated following some well known rules or that are loaded as part of the map. This means all their transformations, not only their position. Just dump the transform matrix to avoid having to look for the position plus the lookAt vector and so on. \$\endgroup\$ Commented Jan 31, 2019 at 2:53

1 Answer 1

Reset to default
1
\$\begingroup\$

Look at the overall game in itself first. I recently played Hitman so I will try and use how I would make the NPCs work.

The game will be bigger than a single complex scene, thus all GameObjects (plus NPCs) will have to page in and out depending on their visibility. As the bird is paged out, it must be able to save its state and restore that state when it pages back into the scene.

Now on to how to save this data. Come up with or get one, a collection of data (a database). and structure it such that objects can fetch and store/update their records without having to read the entire database or parse all of it into memory. Also as fore-sight, make it so that you can fit the entire game world state into the memory as a database. The technical design is up to you but SQLite is one option.

All gameobjects report to the game's state manager and when they get paged in, they just restore their state from the database. When they go out of camera view enough to get paged, they save their state to the database. Be sure to deregister a paged-out object from the state manager too. The state manager should be designed such that can send a command to alo objects in the scene and tell them to save their state and that's how you save your entire game.

You should consider putting in place a quest tracker for objects in the game. Your gameobjects must then have some sort of looped or single quest status. If the bird poops once and doesnt need to do it again, then if it has pooped, its quest state is saved to the database. When the game tries to page it back in or reload it, the bird refuses because it's completed its quest. If it poops then goes to eat again, simply save the last state, for example eating, before it gets pajed out. When the bird is re-loaded back in or paged in, it knows it was eating and now, it should go and poop. It'll loop until it gets paged out again and the cycle repeats.

Now, when you save the entire game, the game state manager tells all in-scene objects to save their state to the database. When reloading the game you simply parse this info from however you had saved it. The technical structure is trivial, as long as it is fast and a sort of random access system.

When you reload the scene you start with global fixed gameobjects designed to keep track of which place the player was in when the game was saved. The fixed gameobject will then load that zone, position the player in it, and load in all the gameobjects that were there at the time of saving. When the gameobjects are added to the zone, they start to query their state from the database and those that need to be displayed, get displayed. those that have a completed quest status, don't need to process further.

You'll use flags that you decide on for the gameobjects. I use static strings and ints.

Get to work!

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.