I’m making a simple 2D top-down game where a player lives on an island and can upgrade their house size (like Animal Crossing) and add / remove / move rooms in their house.
I have a few questions here.
From all my Googling I wasn’t able to find a clear answer on the best way to handle house interiors.
The most frequent answers I saw were:
Load (async) the scene of the house interior when you get near
Have the interior live on a gameObject that gets active/inactive in the same scene
Teleport far away on the same scene
What I want to accomplish is this:
The ability to customize room layout in the house (moving kitchen from one side to the next, adding on additional rooms, etc)
I have a save/load system already in place so data persistence isn’t much of an issue.
I was just wondering what the ‘best practice’ is for something like this.
All three of those approaches are valid. There are other approaches as well, completely dependent on what you’re trying to finally accomplish.
^ ^ ^ Does this mean making an interactive level editor that the user can organize the level (within their house) however they like? If so, start with basic level editor functionalities, which would include the expected UI flow you want, such as select, deselect, move, rotate, flip, etc.
Just as a heads-up: making interactive level editors is hard, not at all “a simple 2D top-down game.” That’s why we all use Unity.
And when your game has a room editor, you’re gonna need loading/saving, so start on that immediately otherwise you may have some very ugly surprises if you defer the work until later.
At a minimum, make a preset scene with three sprites in it, the ability to drag those sprites around, and have a save / reload button to test your load / save code early. The pain saved will be well worth your time.
Load/Save steps:
An excellent discussion of loading/saving in Unity3D by Xarbrough:
And another excellent set of notes and considerations by karliss_coldwild:
Loading/Saving ScriptableObjects by a proxy identifier such as name:
When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. Save data needs to be all entirely plain C# data with no Unity objects in it.
The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object, so you end up with a defective “dead” Unity object.
Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.
If you want to use PlayerPrefs to save your game, it’s always better to use a JSON-based wrapper such as this one I forked from a fellow named Brett M Johnson on github:
Do not use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.