This course is the third course in the specialization about learning how to develop video games using the C# programming language and the Unity game engine on Windows or Mac. Why use C# and Unity instead of some other language and game engine? Well, C# is a really good language for learning how to program and then programming professionally. Also, the Unity game engine is very popular with indie game developers; Unity games were downloaded 16,000,000,000 times in 2016! Finally, C# is one of the programming languages you can use in the Unity environment. This course assumes you have the prerequisite knowledge from the previous two courses in the specialization. You should make sure you have that knowledge, either by taking those previous courses or from personal experience, before tackling this course. The required prerequisite knowledge is listed in the "Who this class is for" section below. Throughout this course you'll build on your foundational C# and Unity knowledge by developing more robust games with better object-oriented designs using file input and output, inheritance and polymorphism, and event handling. This course gives you even more tools to help you build great games with C# and Unity! Module 1: Start using files to implement your Unity games Module 2: Learn how inheritance and polymorphism help us write less code for our games Module 3: Implement event handling to make better object-oriented designs and add menus to your Unity games Module 4: Explore the complete implementation of a small Unity game Module 5: Complete final peer review
PlayerPrefs
Loading...
En provenance du cours de University of Colorado System
Intermediate Object-Oriented Programming for Unity Games
16 notes
University of Colorado System
16 notes
Cours 3 sur 5 dans Specialization C# Programming for Unity Game Development
À partir de la leçon
Exceptions and File IO
Rencontrer les enseignants
Dr. Tim "Dr. T" ChamillardAssociate Professor
Computer Science
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.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
