Adventure Game Progress?

Unity Engine
1

Hello,

I’m creating an adventure game with Unity and am wondering what the best / most efficient and tried and tested way is to store the player’s adventure progress. I’ve looked around for a while and can’t find anything, but if I could be directed to something else I’ll delete this thread

Note that I am not talking about storing variables in general - I know all about playerprefs and all that. But, say you have a cabin you can talk to people at, and depending on what you have done / what you are doing the cabin may have different people in it or be deserted, based on where you are in the game. How is it that the scene of the cabin interior knows how many people to have in it?

All I can think of is that you have a whole big list of bools stored in playerprefs that the game accesses when it loads the scene and populates it accordingly (or perhaps there are different scenes for each cabin a game manager decides which one to load - whatever, it is inconsequential - my question is more about the bools). It seems like on paper it would work, but it also seems on paper that for a game of any substantial length that list of bools would quickly grow unweildy and get out of hand.

This is especially true for quests. I imagine that when you embark on a quest, you would have a bool to check when you are on it, so that the game can set up the quest stuff when you load scenes, and then when you complete it another completed bool is checked, or you could even have multiple bools for checkpoints along the quest. Maybe an NPC only appears here after you’ve talked to this other guy. Either way, it’s a lot of bools and if then statements

Is this how it is done? Or is there a more efficient way?

Thanks

2

Hello, i’m not working on an adventure game but on a 4x strategy game. So it’s not exactly the same but the common point is that i have a lot of variables to store (population of planets, production, stock etc… more than 100 variables for up to 1000 planets) The only thing I can tell you is that if you wan’t to save lot’s of variables between game session, you don’t want to use PlayerPrefs. Because it’s really slow. I mean really really slow : I made some test and i tried to save 180000 value to PlayerPrefs. I stopped the experience after 20 mins, at 46% of my 180000 values.Then i found a tutorial on how to store values to a text file. And that’s really efficient, it takes less than one second to write 180000 values to a text file. Here is the tutorial to store value to a text file (you need to watch part 163, 165 and 167):

You may also want to check about serialization and xml or binary files, but it’s more complicated and simple text files may do what you need.

To keep some value between scenes and between save points or saves (if you allow the player to save progress anytime) you can use static variables.

3

First of all, stop using PlayerPrefs for anything but preferences. It’s not meant to be used the way most people use it, and as a rule of thumb it should only be used to store stuff that won’t be game-breaking if the data is lost.

Here’s a good tutorial on file saving/loading

So, following that tutorial, you’ll have a persistent “AdventureGamePlotProgress” object.

Now, getting more specific. You have some options. Assuming your adventure has a linear structure, one option is to simply have an int that get incremented each time you progress to the next plot element. Every piece of dialog in the game can have a “range” that it works on. From 1-10, the blacksmith says this. From 11-40, he says that. From 41-100, he’s off on an adventure, so disable his GameObject in the blacksmith shop. That sort of thing.

There’s a few minor issues with this and one really, really major one: you can’t change anything, ever. As soon as you create all the plot for plot points 80 through 400, you can never add a single plot element between 39 and 40, or you’ll have to update every single piece of dialog after that. You can remove stuff as long as you remember to add special code that jumps from 37 to 43 at the right time.

So, probably not a great idea. So what else is there?

I recommend a node-based system. You’ll probably want to write a MecAnim-style editor window for your nodes, which looks at all the PlotPoint objects in a particular folder of Resources. These objects can run whatever code needs to be run to make sure that the world is set up as it should be. If you want to use a linear, number-based system WITHIN these nodes, you can certainly do that, with much fewer issues than you’d have doing your whole game that way. Each node, upon its completion, will be responsible for activating the next node (or nodes) in the plot, which also allows you to have a nonlinear branching story.

But you asked about saving the game using this. I recommend creating another class, PlotPointTracker, which is specific to one saved game (in contrast to the PlotPoint class, which is set in stone in the code of the game). This tracker will contain the name of the node that it’s about (you can then find that node using Resources.Load) plus any status information you need to set about it such as whether that node has been completed. (Also, make sure that PlotPointTracker has the [System.Serializable] attribute.)

So now, you just need to put a big old pile of PlotPointTrackers in you AdventureGamePlotProgress object. An array will probably be sufficient. And there you go, easy as pie!

(Actually it’s complicated as hell, but TBH, there’s no way around that if you’re doing it right.)

1 Like
4

Thanks much fellas, this sort of information is exactly what I was looking for

5

We do something similar. We use JSONs to store our quest data and our save data. Every quest has a unique id, and can either be linked from previous quests id or chain into other quest ids once complete.

Our save game JSON has a dictionary keyed by quest id, and for the dictionary values it has a C# QuestData class that contains all the info about how much of the quest has been completed.

EDIT: This makes it super easy to make tests for stuff like, has a quest been completed? Our level designers can require a quest id be marked as complete for a NPC to become visible.