What is the difference in the code between the editor running and the build that makes it so that in the editor when we hit play, the GUID is always the same, but in the release build the GUID is random on every launch? The player guid is read only with no ability to set it or change it, which is fine, in a pc or mac based game, even iphone based game, I can create a cache of previously used ID’s to pass to the server so I can resync the players data based on the last ID known to the server from the player then purge that from the queue, but why in editor is the GUID static?
the editor guid is, unless I’m wrong, persistent because its the library / scene guid.
in the player though (independent of the platform) its only runtime persistent so it depends on the initialization order etc
Makes sense, thanks, will have to write a routine to do a login and persist the last guid in a database table since with the game being web based, I can’t use the IO to cache the guid to a file. Come to think of this, it will be better in a database anyway since I am using a distributed server model for the game with a persisted database structure for the player, will help with re-syncing the player to the right game data on reconnection. I was worried for a moment that there was some inconsistancy in the guid building, but doesn’t look that way based on what you stated.
Thats at least how I understand it from experimentation.
The editor requires the kind of persistence it has cause the uids there are used to store relationships etc between objects too against the library.
On the client it only needs to be “this time identifyable”.
There is another reason it would be a problem if it worked on the client like in the editor:
-
As you realized it would have to store it somewhere, question is where given unity is not just focused on a single style of implementation (even with that focus its often not longterm persistent in most technologies as UE and Torque show with their pretty “single usage type” networking etc)
-
depending on 1, mmo type games with masses of players and persistent could become quite some problem. that requires some smarter setup and I think the one you likely have in mind will work pretty well
Agreed, this is a realtime based strategy game, like old school command and conquer, map is just larger and I want to properly handle the disconnection to reconnection to the same game witout a “your out of sync” warning.
in that case some truely unique userbound identifier naturally can be pretty important especdially if it is intend to be persistent (even if time restricted persistent)