- Home /
Loading data from a different game
I'm trying to find specific steps to take in order to implement loading data from a different game. I'm intending to make a series of games for Web and Mobile where at the end of each game the character could be loaded into the next game (keeping any stats and items he gained in the first game)
I'm having trouble searching for this topic, because any search with "Unity" and "Loading" tells me very basic stuff about serialization and such. The one topic I did find from 4 years ago got derailed into a discussion on how PlayerPrefs is not secure and why PlayerPrefs won't work between devices.
I have read that I might be able to do something like this with a SQL Database and my own web host, but that presents a whole new set of challenges that I don't know how to overcome. IE: Where do I get this host and how do I make sure I have a host that does what I need that allows games (IE - most web hosts specifically do not let games operate on their servers) Also I have no information on what code I need in order to do that - just the vague suggestion that's what I need.
I'm interested in suggestions on how to find this information - or any suggestions from the Asset Store or specific hosts. I already have EasySave2 which supports PHP and MySQL - but without knowledge of server information that doesn't do me any good - and I'm also not certain that that asset can be used to load data from a different game.
Answer by RobAnthem · Feb 04, 2017 at 02:18 AM
Basically, it would be nearly no difference in how the loading process was done. If you control the server-side data or have a generic location on your users hard drive to store your data then essentially loading the data wouldn't be different, if you already have a method of saving/loading then you already handled the inventory and player information side. If you are wanting to make some sort of progress definition, you could create a dictionary with progress IDs of some sort. The main thing is to make sure you use the same class file definition for "Player", so that the code never interacts with the player file differently. If every game has the same item system and player system, than the sequels could change literally everything else, including all the data within the defined parameters about items, thereby creating new, possibly more graphical items, entities, or worlds. If you keep a seperate section of data that pertains directly to the progression of each game then it should have no effect on a character moving to another game. In fact if done right, they could log into a new game, gain progress and items, then log into an older game. The only problem would be handing the fact that the sequel may include new items, but if you have generic definitions, you can easily use a null reference to assign a generic icon. Anyway if you have any more questions just ask.
An example of handling the data, we'll use the icon data as as an example:
public Item ImportItem(Item item)
{
if (item.icon == null)
{
if (item.itemType == ItemType.Sword)
{
item.icon = GameManager.Data.IconDictionary[iconType.GenericSword];
}
else if (item.itemType == ItemType.Helm)
{
item.icon = GameManager.Data.IconDictionary[iconType.GenericHelm];
}
}
return item;
}
There tons of ways to handle every idea, so this is not the best or worst way of handling such things, just an example of one way.
I'm of the understanding that the web implementation doesn't allow saving and loading to the hard drive and that Android and iOS apps cannot access data from other apps without rooting. Is this not the case?
As far as 'controlling server-side' data - that's part of the question (see paragraph 3)
I'm less concerned with the implementation of the data structures within a game - that's the easy part. It's getting the data to be accessed by the different games that I have no idea where to begin. I don't even know how to do something like store a single string (such as a player's name) in one game in a way that can be accessed by another game in Web and $$anonymous$$obile (It's easy on desktop - like you said it's just saving a file to hard drive and loading it from there)