Construct 2 pozwala w łatwy sposób na zrobienie zapisów gry. One Umożliwiają graczom zapisać grę, a następnie wrócić później i załadować ją dokładnie tam, gdzie skończył. To ważne dla długich gier, zwłaszcza gdy poziom lub etapy są długie. O ile możliwe jest mieć bardzo prosty "Ostatni poziom osiągnięty" typ zapisać za pomocą Local Storage, to zwykle bardzo trudne w użyciu by zapisać pełny stan każdego ostatniego obiektu. Celem systemu Zapisz i Wczytaj są działania wygodne pozwalające zrobić tylko to, co pozwala w łatwy sposób dodać wysoką funkcjonalność save'a z niewielkim wysiłkiem.
Podstawowy system zapisywania
Łatwo jest zapisać gre używając podstawowych akcji Save i Load po naciśnięciu pewnego przycisku. Na przykład:
Dla gier mobilnych będziesz oczywiście musiał zrobić przycisk "zapisz" ale my skupimy się teraz na tworzeniu gier na komputer stacjonarny.
Zapisy gry są przetrzymywane na dysku przez przeglądarkę. Oznacza to, że gracze mogą wyłączyć swój komputer lub urządzenie, wrócić następnego dnia, a zapisy nadal można pomyślnie załadować. Należy jednak pamiętać ,że zapisane stany gry są związane z konkretną przeglądarką. Na przykład, Firefox i Chrome będzie przechowywać Zapisane stany gry oddzielnie; jeśli gracz zapisuje grę podczas korzystania z Chrome, a następnie przechodzi do Firefoksa, nie będzie on w stanie załadować tego save'a.
Zapisy gry nie są zapisywane w pamięci podręcznej. Pamięć podręczna przeglądarki jest bardzo tymczasowai jest wykorzystywana do zapisywania rzeczy jak zdjęcia na stronach internetowych bez konieczności ponownego pobrania ich za każdym razem, i to jest regularnie usuwane. Zapisy gry nie będą tam (na szczęście), są one przechowywane w albo WebStorage albo IndexedDB, które są stałymi magazynami i nie wpływa na nie użytkownik czyszczący ich pamięci podręczne.
"Sloty" na zapisy
Jest to często przydatne, aby umożliwić graczom mieć wiele zapisów gry. To jest to, co umożliwia save slot. Każdy slot (gniazdo) jest jak oddzielny plik, który przechowuje różne zapisy. Możesz oferować graczom zestaw gniazd, aby zapisać grę do nich, lub pozwolić im wprowadzić swoje własne nazwy save'a.
Należy pamiętać, że większość przeglądarek ma limit, ile danych strona internetowa może zapisać na dysku. Jest mało prawdopodobne, aby było to problemem dla większości gier, ale jeśli masz ogromną liczbę oddzielnych slotów możesz natrafić na limit pamięci. Oferowanie ograniczonej liczby slotów jest dobrym sposobem, aby upewnić się, że nigdy nie dojść do limitu. Odpowiednie użycie zachowania No save może równierz pomóc w zmniejszeniu zapisów (patrz niżej).
Powiadomienia o stanie zapisywania
Zapisywanie może trochę potrwać, a w tym czasie gra będzie pracowałą nad zapisaniem plików. Po ukończeniu zapisywania system powiadomi gracza przez akcję On save complete. Równierz ładowanie zapisu trochę trwa.Lecz także po ukończeniu wczytywania gry system może powiadomić gracza poprzez On load complete. Uwaga, zmiany wprowadzone po akcji save ale przed wiadomości On save complete zostaną jeszcze zapisane!
Jeśli próbujesz ładować z gniazda, które nie zostały jeszcze zapełnione system wyzwoli On load failed Jeśli użytkownik wybiera puste gniazdo do ładowania, może po prostu chce, aby rozpocząć nową świeżą grę.
Zachowanie "Nie zapisuj"
Wszystko z zachowaniem No Save nie zostanie zapisane, i nie będzie mieć wpływu podczas ładowania. Do jest dodać zachowanie No save dla każdego statycznego obiektu, jak sceneria czy tło. Może być również stosowany na automatycznie aktualizowane obiekty, takie jak HUD i tekstowych obiektów, które są aktualizowane co chwilę. To nie ma żadnej różnicy w grze, ale sprawia, że zapisane stany gry są mniejsze i szybsze we wczytywaniu, ponieważ niepotrzebne informacje pominięte. (Jest to również konieczne, aby [ciągły podgląd] [5], działał skutecznie.)
Zmiana projektu po zapisaniu
Zapisane stany gry powinny być wytrzymałe na zmiany w projekcie. Powinieneś być w stanie dodawać, usuwać i zmieniać kolejność różnych rzeczy jak zmienne, zachowania i inne obiekty, by stare zapisy gry też można było załądować.Należy także pamiętać ,żeby wszystkie nowe rzeczy dodane do gry nie zostały naruszone podczas ładowania. Również usunięcie starych obiektów w grze spowoduje ,że stare zapisy nie będą działać (nie dotyczy to obiektów z zachowaniem No save) ale jeśli usuniesz całe typy obiektów, układy lub warstwy, one nigdy nie będą ładowane z powrotem z zapisu.
Please, help in translating a rest of tutorial
Advanced topics
Everything covered so far is enough for most games to easily add a savegame feature. However advanced users may be interested in the following topics which go in to further detail about the savegame system.
Tracking which slots are used
The system save/load actions don't tell you which slots have been saved to. The best way to track this is to store some extra meta-data yourself in the WebStorage object. For example, whenever you save to a slot, also write a WebStorage key that indicates the slot has been saved to. You could add some other metadata like the player name or even a small screenshot of the game as a data URI. Then you can tell which slots are in use from the WebStorage data you've saved. You can perform other operations like resetting or clearing save game data just by adjusting these meta-data keys, such as removing them to make it look like the slot is empty again.
What is and isn't saved
The full state of the game - including instance variables, global and local variables, behavior properties, effects, particles, currently playing audio, etc. - is saved. However there are a few exceptions, hopefully none of which are surprising. The following things are not saved and won't be affected when loading:
- Input state (i.e. mouse position, or whether the player was holding keys or touches)
- AJAX requests
- WebSocket connections
- The XML object
- User Media video or audio feeds
- Facebook login
- WebStorage state
- CocoonJS/Windows 8 state
- Any in-app purchases on any platform
- Anything with the 'No Save' behavior
Using the JSON data directly
In both the On save complete and On load complete triggers, the system SaveStateJSON expression returns a string of all the JSON data for the savegame. Note the SaveStateJSON expression will return an empty string outside of these triggers; the triggers are your only opportunity to access the data directly.
If you have your own server, it's possible to make shared savegames by posting the JSON data to the server with the AJAX object and storing it in a server database. Alternatively some platforms like Windows 8 and Clay.io allow you to store data for the logged in user, where it's shared anywhere they log in. This is a useful for allowing users to take savegames with them wherever they go.
Once you get the JSON string back, you can load the game from it using the Load from JSON system action.
Versioning
Usually you'll be able to change your project and old games will still load just fine. However some advanced users may wish to track precisely which version of their project a savegame has come from. You can do this using a global variable. Call the variable Version and initialise it to 1. Later, if you publish a new version of your game, change the initial value of the variable to a new number, e.g. 2. Now when On load complete triggers, the global variable has been loaded and set with the value of Version at the time the Save action was used. This might be useful if you add lots of new objects to the game, but want to make sure they're destroyed or hidden when loading old savegames.