In this lecture, we'll talk about the Unity PlayerPrefs class.

Up to this point, that game configuration data that we've been talking

about is really read-only data that controls how the game works.

We also need read-write data associated with our game.

So here's the problem.

We need to be able to persist data between gameplay sessions.

So for example, we might need to keep

track of how far the player has progressed in the game

and what they have in their inventory and even

how long cumulatively they've played the game,

although sometimes we don't actually want to see that number,

but there's data that we need to save that persists,

that lasts, between gameplay sessions but that

has changed because of a particular game session.

So the solution to this problem is the PlayerPrefs class.

What's PlayerPrefs?

It is a class that stores and accesses player preferences between game sessions,

and that's straight from the PlayerPrefs documentation.

That why it's in quotes.

So you should go do an in-video quiz about PlayerPrefs.

OK, how does this work?

We have a string that we call a key that we

use as a word that we can use to look something up. It's a label.

Just like a variable name is a label for a memory location,

this key is a word that we'll use to look up a value,

a string, int or float that we've associated as the value for that key.

And so we get the value of the particular item we're looking for by using the key,

and we set the value using the key as well.

Let's go look at a Unity game that does

this so that we can make it a little more concrete.

This is a tiny Unity game that demonstrates PlayerPrefs.

So when we run this,

we will have an area that says, "Enter Gamertag."

And if we highlight that and enter a gamer tag and then finish,

then we end up saving that information.

So let me go ahead and save a new gamer tag.

Let's say Bob.

And I finished editing.

The next time I run the game,

we'll see that instead of "Enter Gamertag," it has

the gamer tag that I entered on the previous run.

So, we're saving this information in PlayerPrefs.

Let's see in the code how that actually happens.

Here's my gamertag processing script.

In the start method,

I call PlayerPrefs GetString and I provide a key.

Let's actually look at the documentation for PlayerPrefs.

And here we are in that documentation. I'll zoom in.

So you can see there are a number of static methods,

so that's why we precede our method calls with the PlayerPrefs class name.

And I can delete everything,

I can delete a particular key,

I can get a float,

an int or a string.

So remember the values that we can store are floats, ints or strings.

The key is always a string.

We can find out whether it has a key.

So we can look to see whether there is a particular key that exists.

And then we can also set floats, ints and strings,

so set the value for a particular key.

Here's how my code works.

I call the PlayerPrefs GetString method with

the gamertag key and I put the result into a gamertag string.

Now, we should look at the documentation for GetString to discover

that if in fact the key we are asking for doesn't exist,

which will be the case the first time we run the game,

this method is going to return default value which

we can see up here is the empty string.

So I'm going to call with the key,

and if PlayerPrefs has a stored value for that key,

it's going to give me that stored value.

I'm calling GetString, so it's going to return a string.

But if it doesn't have that stored value,

it's going to return the empty string to me.

I check here in this if statement whether what was returned is null or empty.

It's really going to be empty if it's the default value,

but I used this pre-built string method to check.

And if that's true, it means there was no value for that key,

so I just provide the "Enter Gamertag" prompt.

So this code right here is to handle the case

where we haven't yet stored a gamertag in PlayerPrefs.

Whether or not we've done that,

I've now set the gamertag variable to be an appropriate variable,

so I extract the input field associated with the text object,

and I set the text to my gamertag string.

And finally, I add this listener for changes to the gamertag.

So what happens here,

because we haven't talked about event handling yet,

is when the gamertag input field component detects that

the user or the player has stopped editing by clicking outside of that field,

it is going to call this method.

And we will talk much more about delegates and event handling in module three,

so just trust me that what's going to happen is

when the player stops editing the gamer tag,

this SaveGamertag method gets called.

And here's all that SaveGamertag does is it calls PlayerPrefs SetString with

the gamertag key and the gamertag string and we also call PlayerPrefs Save.

Let's see why we do that.

Here's the documentation for that Save method.

The important stuff is in the second paragraph that says,

by default, Unity writes preferences to disk during OnApplicationQuit.

So in other words, we don't write to the disk any time the game is running,

we only write to the disk for these PlayerPrefs when the game ends.

And while writes to the disk are expensive to do while our game runs,

it is safer to save right away rather than waiting till the game

ends just in case our game crashes and then

we end up not saving the stuff we wanted to save.

So this is the tradeoff you have to decide,

whether you're willing to pay that performance impact of a disk write during gameplay.

But we're going to do it in this game because it won't

really have a significant impact at all.

I'll run the game one more time,

and I can now change this from Bob to Bubba,

and the next time I run my game we'll see that it comes up as

Bubba because that's what was saved in PlayerPrefs under the gamertag key.

So we keep talking about this stuff getting saved in PlayerPrefs,

and where does that actually happen?

The PlayerPrefs documentation tells us

where this stuff gets stored on different platforms.

So, I'm working on Windows right now, obviously.

Let's go take a look at where this is stored.

I will tell you that because the place it

gets stored is based on company name and product name,

I have set those here in this project.

So if we go to Edit, Project Settings, Player,

you can see that I have filled in the company name as Burning

Teddy and I have filled in the product name as PlayerPrefs.

On Windows machines, this information gets stored in the registry,

so I have fired up Reg Edit,

and it is in HKEY_CURRENT_USER,

which people will regularly abbreviate as HKCU,

and it's under software and it's under

the company name and the product name but you don't see PlayerPrefs here.

And the reason you don't see PlayerPrefs here is because at this moment,

we've been working in the editor.

So down here in the Unity UnityEditor,

Burning Teddy, we can see that we do have a folder called PlayerPrefs,

and we can even see that there's a gamertag PlayerPrefs saved with those values,

42 75 62 62 61.

And so let's go look at a Unicode table to see what those values actually mean.

So we can see in this table that four two is capital B,

seven five is lowercase u,

six two is lowercase b,

and six one is lowercase a.

So 42 75 62 62 61 is Bubba,

just as we saved it.

Now the documentation said it would get saved here under

software company name and product name and we don't see it here.

And the reason is that we're running in the editor,

we're not running an actual build.

So if we actually build and run our game,

you'll notice that it has that default value again because

the PlayerPrefs in the registry that it's looking for isn't there yet.

So let's change this to Bubba,

and then we'll quit and now we'll fire up Reg Edit again.

And you can see under Burning Teddy that we now have

that PlayerPrefs folder and it has

that gamertag of 42 75 62 62 61, which means Bubba.

So it actually does store where it

says it stores in the documentation if you're running from a build,

but it stores in the editor if you are

working from the editor and dealing with PlayerPrefs.

To recap, in this lecture,

we learned how to use the PlayerPrefs class to persist data between game sessions.

And you will actually see this key value idea

again when you explore the DictionaryCollection class not in this course,

but as you pursue your game programming,

you will certainly see keys and values again.

PlayerPrefs

Intermediate Object-Oriented Programming for Unity Games

Rencontrer les enseignants