00:00:00:06 - 00:00:19:29

Peter

In this section, we are going to implement a save system to persist the data when we transition between different scenes later. Of course, it will also work when we close and reopen our application, our game. The data will be also persisted and we are going to be able to load our game data or create a new game.

00:00:19:29 - 00:00:41:00

Peter

In terms of our code design, we are going to implement two new or three new classes. The one will be saved. I do repository a static class, the second one will be saved. Manager a minor behavior component and the third one will be an interface receivable. So the saved manager will do the work of actually saving the data.

00:00:41:14 - 00:01:11:05

Peter

All the scripts that will want to be saved or wants to have the data saved. We'll need to implement the ICE favorable interface, which will require each script. For example, the interesting Spanner, a new script that will actually spawn the player at the position near the door. And those will need to implement the ice capable interface. So they will need to know how to convert their own data into a JSON formatted string and how to convert the Egyptian format the string back to its own data.

00:01:11:18 - 00:01:36:21

Peter

Now, to save a minute, you will find all the game objects that implement this receivable interface. So this will be using decisive able interface and to know which object should receive which data. Because remember, we are saving the string values. We will have a save ID repos, the asset class which will define the idea of each object that wants to have its own data persistent.

00:01:37:06 - 00:02:02:29

Peter

And this has a downside of us having to re-implement this. So to modify it to have the values updated. If we want to add a new script, this needs to be saved on the other hand, it will be very easy to get the ID by calling this static class and getting this static value rather than to remember that, for example, central to spawn or has the idea of ten because those things are very easy to forget.

00:02:03:14 - 00:02:30:07

Peter

Now many classes will be implementing this receivable interface. I have marked a just few to give you an idea. Since Transition Spanner sells system tools Big player inventory. Because the inventory is a separate object, we will need to save all the objects that uses this inventory so ourselves is the sole system or the tools bag or the player will all be able to save its own inventory based on this ice capable interface.

00:02:30:15 - 00:02:54:28

Peter

So every object that wants to have its own data process that will need to implement all of this is capable interface and B of type model behavior. Now, again, this big UML diagram should probably be split into multiple diagrams, so you get the better idea of how it is all working. But I just want to show you and give you the idea of what we are doing and how it is affecting our global design.

00:02:55:04 - 00:03:17:28

Peter

So the idea here is that the interface and if we implement the interface, it does not change the internal logic of the object. We are adding the new logic to it, the save logic, and it will be able to convert any object to the object that can persist is own data. So it is very reusable system and this is what I want to show you how to implement in this section.

00:03:18:11 - 00:03:20:06

Peter

Okay, let's go to our project.