Welcome back.
Now, in all RPGs, just about there's the ability to save your progress.
And this is done in different ways depending on whether it's a single or a multiplayer game.
And there are different ways to go about it.
Now, when saving the game, we need to start thinking about what we need to save, what data is important.
Well, we know that we have an attribute set with some attributes on it, and those attributes, at
least the primary attributes are needed if we want all of the rest of our attributes to have the correct
values.
And as we level up, we spend attribute points on our primary attributes.
So if we're looking for data that we need to save, at least our primary attributes would be part of
that list.
In addition to that, we have variables on our player state.
So the player state contains some data that we're going to want to harvest and save whenever we save
our project.
And in this project, this just consists of four integers the level, the spell points, attribute points,
and the XP.
So those, of course, are data that we would like to save.
Now.
The ability system component itself has data of its own pertaining to our abilities, and luckily,
we've set up our system in a really efficient manner where we can identify abilities by their ability
tags.
So gameplay tags are the only thing that we would need to save in order to keep track of our progress.
Of course, they all have their own ability levels as well, and any other information that we may wish
to save with our gameplay abilities could be lumped in to some kind of data structure, but either way,
we do need to save information pertaining to our gameplay abilities.
Now, these are all data that we would like to save and load for our character.
But there could be additional information not stored in these variables that we would still want to
save.
This can include our location, perhaps the level or map that our character is in, and any other identifying
value that we can use to retrieve our saved data.
Some kind of a slot number or ID associated with the player.
Any of that would be data that we would want to save as well.
So we have a list of things that we're going to want to save.
And now we need to think about how we're going to save it.
Now there are two primary ways to save data.
You could save the data to disk, your actual machine that you're playing on.
So all of those values would now live on your machine and can be loaded from disk, or you could save
to somewhere else, elsewhere in the cloud, or elsewhere on your machine, or onto another machine.
This would be saving to a database of some kind.
All of those values would be streamed across the network and saved somewhere else.
And there are pros and cons to each way.
If you save to an external database, then all of the data for the game is saved in a central location.
This is for all users.
So if this is a multiplayer game, it's the database that contains information pertaining to each user,
not the user themselves.
This is useful because if you save all of your player data to a database on one machine, you could
log out and go to another machine and log in and still retrieve that saved information.
Because it's not local to the machine, it's saved on a database.
Another advantage is databases can be encrypted.
So you could store sensitive information.
And while encryption can be cracked, there's a level of security to it.
Now dedicated servers use databases.
This is typically the way to go for dedicated servers because the dedicated server does not have a player.
The player is connecting to the server from elsewhere, and if the player is connecting to the server,
then the server can connect to the database and have its information ready for the player.
And doing it this way gives the server authority over the data.
You see things that are determined by the client or sent from the client side up to the server.
Run the risk of cheating as clients can be hacked, they can send fake values up to the server.
And so for that reason, the server is typically seen as what should have authority.
So saving to a database and having the server be in charge of saving and loading that data and sending
it to the client is a secure way to do it.
Now, the drawback to this method is it requires APIs.
You need the ability to connect to a database.
This requires expertise and knowledge about databases, how to write to and retrieve data from databases
from within your game, and how to manipulate database data.
Now.
Saving to disk is simpler.
It's typically easier to implement.
It's faster.
It doesn't require an external database.
And for that reason, it's ideal for single player games as you don't really need to connect to a database
elsewhere.
Now, there are single player games that still do connect to dedicated servers and databases in order
to keep track of important things in the game to facilitate in-game purchases, leaderboards, and such.
But in the absence of that need, you could save to disk.
And in reality, most multiplayer games use a combination where important information is stored on the
database, but some information is stored to the disk.
For example, when you have a login and a password and your app remembers the password that you've entered
in that is saved to disk.
Now a con to saving to disk is the data is local.
So you could save your progress in the game on one machine and then go to another machine.
Open up the game and that data is not there because you saved it locally to another machine's disk.
That's a drawback.
And some games again that are single player would still save some data to either a dedicated server
or a database that the server can connect to.
Now.
Saving data externally to a database is outside the scope of this course, as that would require developing
the ability to connect to the database.
Teaching about how to retrieve and send to databases and from them.
And that's really material for a course in itself.
And I am planning on a course on dedicated servers that will talk about this in more detail.
And we'll be creating a system for this.
But in this course, which is primarily about the game play ability system, we're going to devise a
system for saving to disk.
But we'll do it in such a way that it could easily be swapped out for a system that saves to a database.
Really, the only thing that matters is what data you're saving, how you're saving it, and where you're
getting that data from when you load the game.
The only thing that would change in a database based system is that you would add the capability to
connect to the database or the dedicated server, or both.
So in this final section in the course, we're going to implement a save game system where we can save
our progress and load back in in the location where we were when we saved with the stats that we had
when we saved.
And this allows for a much more involved RPG, because if you retain your progress and load it back
up every time you come back into the game, you haven't lost your progression and you can continue moving
deeper into the game and venturing your way through deeper and darker dungeons and more complex levels
and so on.
So we're ready to start implementing a system for this, and we're going to need a way to load into
the game.
We'll need an opening screen.
And we're going to start with that first.
And then we'll work our way into figuring out how we can save our progress.
I'll see you soon.