koobas.hobune.stream
Retaining GameObject data when switching scenes?
I'm making an RPG, and wanted to know how I would be able to retain a GameObject's possibly changed data/variables (such as HP, coordinates, etc.) when switching scenes. I am asking this because when a new scene is loaded all of the previous scene's GameObject's (such as the character object in that scene) data/variables (HP, etc.) will be set to their defaults and all of that mandatory info would be lost.
Any help would be appreciated. Thank you!
You could call Object.DontDestroyOnLoad(myGameObject); and then just keep the same gameObject from scene to scene.
But this will cause there to be two copies of the items in question when you return to the scene. You'd have the original object in the position you left it, and a carbon copy positioned right where it was in the authoring tool. That's not really helpful.
You can create the permanent objects in one scene, set them to not destroy on load, then load the scene you really want to play. Then you never go back to the loading scene, just to the scene you want to play again.
You could do PlayerPrefs.SetInt("string", int); This basically allows you to store integers on the computer, and it would save this even after the game is closed. For example:
using UnityEngine;
using System.Collections;
public class Player : MonoBehaviour {
public int gold;
public int health;
public void loadLevel () {
PlayerPrefs.SetInt("HP", health);
Playerprefs.SetInt("Money", gold);
}
}
Then in the next level make it go:
using UnityEngine;
using System.Collections;
public class Player : MonoBehaviour {
public int gold;
public int health;
// Use this for initialization
void Awake () {
health = PlayerPrefs.getInt("HP");
gold = PlayerPrefs.getInt("Money");
}
}
There's a lot more information in the documentation (just do Ctrl+" on PlayerPrefs in MonoDevelop).
You could also consider creating a "checkpoint" before level changes where all Data are written e.g. in a Savegame/File/Database and reloaded (respectively only the data needed for the new level) after every level change. Thus you can purge the memory from data unneeded for the scene (e.g in a indoor scene you barely need cooridates of visited places or other data related to outdoor levels)
I was sort of thinking of the same idea, but I don't have the slightest clue on how to write data, let alone load it and read it, is there some place you could point me to for help on this?
I've seen commercial RPGs (e.g. Drakensang) using SQLite files for their savegames. They saved practically everything in there. Depending on your target platform you can use any embedded database, preferable SQlite since there is plenty of documentation and c# wrappers for it.
Another approach (not the best but an easy one) would be making static objects which can store player data. Those objects don't need an instance to be altered, but be careful to reinitialize those objects appropiately.
With static objects, you can also avoid passing lots of data from one object to another, or keep looking for objects every scene like in DontDestroyOnLoad() or store data Methods, but player data will be always on memory, and most programmers consider using static objects a bad programming habit.
$$anonymous$$ost stupid programmers consider using static objects as bad program$$anonymous$$g habits.
$$anonymous$$ake sure people know that there is absolutely nothing wrong with using static variables, and that the paranoia around them is mostly from idiots who have no idea what they're talking about.
I have seen it time and time again, would so-called programmers (even professionally hired programmers) say that static variables are "evil". These people are idiots, plain and simple. It is best to always ignore all their advice, as they pollute the internet with this sort of misinformation.
Static variables are only bad, if you make them bad- just like ANY other variable. If you want a variable to hold game data, such as a "player character", as long as there will only ever be ONE "player", it would be perfect to use a static variable. If you want to add a second player, then you need only make a second static variable, "Player2". As long as you know what 'static' means, there is no such thing as bad program$$anonymous$$g.
Likewise, the argument that a variable can be "bad" is as ludicrous as those who ignore the fact that ALL variables are "bad program$$anonymous$$g" if they're...bad program$$anonymous$$g. The idea that somehow 'static' is worse than any other misuse of a variable type, is purely idiots parroting what other idiots parrot, and the original know-nothing who came up with the idea. It is the equivalent of highschool gossip or people pretending to be extreme know-it-alls when they have absolutely no idea what they're talking about.
