Identifier - Object.id - brauche ich das wirklich? Wenn ja wie?

[Ismoh]

Hallo,

 

ich habe mir die Tage mal einige Eigenschaften zu meinen Klassen überlegt und wie man das so kennt, schreib man erstmal ID hin...

 

Nun habe ich bisschen mehr über "ID" nachgedacht:

 

Ich kenne das als Identifier, welcher aus einer natürlichen Zahl besteht und ebenso einzigartig ist.

 

Nur ist mir bisher kein Anwendungsfall diesbezüglich eingefallen.

 

Ebenso dachte ich über folgendes nach:

 

ObjectID -> eine einmalige natürliche Zahl repräsentiert nur dieses eine Objekt

TypeID -> eine einmalige/einzigartige natürliche Zahl repräsentiert den Typen einiger/der gleichen Objekte (Ich dachte da an Minecraft: "/give Ismoh 100 3" oder so ähnlich, dabei ist 100 die ID von dem Typen Keks..

 

Wenn mir noch ein sinnvoller Anwendungsfall einfällt, wäre es ebenso interessant eine vernünftige - wenns eben geht - automatische Implementierung zu entwerfen.

 

Welche Erfahrungen habt ihr gemacht ?

[Felix K.]

Hi,

ich weiß nicht genau was Du realisieren willst, aber eine Objekt-ID kannst Du so automatisiert abfassen:

 

http://docs.unity3d.com/ScriptReference/Object.GetInstanceID.html

 

 

MfG Felix

[AgentCodeMonk]

Naja... die InstanceID ist jedes mal anders.

Beispiel:

Wenn du deinem Character ein Item in das Inventar legen willst, ist das per ID garnicht verkehrt. (AddItem(int id){// clone from itemDatabase} ) sowas mit strings zu machen ist ein gutes Stück fehleranfälliger. Da man sicher nicht in jedem Frame ein Item ins Inventar schiebt, ist das Prüfen des strings wohl auch nicht DER Performancekiller ...angenommen du hast aber schon beim Testen deine Spielstände gesichert oder du entscheidest dich ein Item umzubenennen, ist es der ID des Items völlig egal wie dein Item heißt - es lädt einfach das "richtige" Item.

Bei der Erstellung im Editor kannst du dir die neue ID ja automatisch erstellen lassen, indem du nach der letzten ID in der Datanbank schaust. Vorrausgesetzt, du sortierst auch aufsteigend nach ID.

Ob du dann mal Items löscht und dann zwischen 2 IDs einen Sprung von X hast, ist doch egentlich völlig egal.

Nächster Punkt: speicherst du dein Inventar in einer Datenbank, musst du nur die ID übergeben, nicht den Namen des Items...wo wir wieder bei den möglichen Fehlern sind. Was wenn sich der Name ändert?

[Hrungdak]

Eine eindeutige ID erleichtert einfach das Leben. Wie die ID aufgebaut ist, ist dabei weniger entscheidend. Ein Integer-Wert ist üblich. Ich sehe auch oft, dass GUIDs verwendet werden, die zwar sperrig sind, dafür aber auch z.B. eingesetzt werden können, wenn viele Objekte gleichzeitig von unterschiedlichen Standorten aus oder in parallelisierten Systemen angelegt werden.

 

Was eine ID bedeutet, ist dabei natürlich dem Zweck geschuldet. Eindeutige Identifizierung eines einzelnen Objekts oder eines gesamten Kekstyps, was auch immer.

[Ismoh]

Hi,

ich weiß nicht genau was Du realisieren willst, aber eine Objekt-ID kannst Du so automatisiert abfassen:

 

http://docs.unity3d.com/ScriptReference/Object.GetInstanceID.html

 

 

MfG Felix

Das Hilft mir nicht weiter, da die ID jedes mal wenn das Spiel beendet wird, anders ist. Ich hab sogar gelesen, dass die InstanceID von Unity die Speicherzelle repräsentiert, jedoch weiß ich nicht ob das wirklich stimmt.

 

Naja... die InstanceID ist jedes mal anders.

Beispiel:

Wenn du deinem Character ein Item in das Inventar legen willst, ist das per ID garnicht verkehrt. (AddItem(int id){// clone from itemDatabase} ) sowas mit strings zu machen ist ein gutes Stück fehleranfälliger. Da man sicher nicht in jedem Frame ein Item ins Inventar schiebt, ist das Prüfen des strings wohl auch nicht DER Performancekiller ...angenommen du hast aber schon beim Testen deine Spielstände gesichert oder du entscheidest dich ein Item umzubenennen, ist es der ID des Items völlig egal wie dein Item heißt - es lädt einfach das "richtige" Item.

Bei der Erstellung im Editor kannst du dir die neue ID ja automatisch erstellen lassen, indem du nach der letzten ID in der Datanbank schaust. Vorrausgesetzt, du sortierst auch aufsteigend nach ID.

Ob du dann mal Items löscht und dann zwischen 2 IDs einen Sprung von X hast, ist doch egentlich völlig egal.

Nächster Punkt: speicherst du dein Inventar in einer Datenbank, musst du nur die ID übergeben, nicht den Namen des Items...wo wir wieder bei den möglichen Fehlern sind. Was wenn sich der Name ändert?

"Wiedererkennung" über String ist super schei.., da hast du Recht. Speicherstände und Inventarverwaltung über eine ID ist ein gutes Beispiel.

Ich könnte diesbezüglich auch eine SQL-Datenbank nutzen, nur sehe ich das im Moment als zu aufwendig - soll ja kein mmorpg werden oder ähnliches.

Ich denke es wird eher eine Art XML-Datei.

 

Eine eindeutige ID erleichtert einfach das Leben. Wie die ID aufgebaut ist, ist dabei weniger entscheidend. Ein Integer-Wert ist üblich. Ich sehe auch oft, dass GUIDs verwendet werden, die zwar sperrig sind, dafür aber auch z.B. eingesetzt werden können, wenn viele Objekte gleichzeitig von unterschiedlichen Standorten aus oder in parallelisierten Systemen angelegt werden.

 

Was eine ID bedeutet, ist dabei natürlich dem Zweck geschuldet. Eindeutige Identifizierung eines einzelnen Objekts oder eines gesamten Kekstyps, was auch immer.

Guid habe ich mir auch schon angeschaut, jedoch soll diese nicht zu 100% einzigartig sein, außerdem mag ich das Format nicht, aber wäre definitiv eine Lösung.

 

Ich bedanke mich und wünsche euch noch einen schönen Tag

[Mark]

Eine GUID ist zu beinahe 100% einzigartig, die Chance da eine Kollision zu haben ist 1 : 2^128 (1:340282366920938463463374607431768211456)

[AgentCodeMonk]

Ja...da hat man ne Menge Platz, bis es kracht;)

[Mark]

Nicht nur das, eine Kollision zu erzeugen auf dem gleichen System ist afaik auch technisch unmöglich. Aber dazu kann ich nun leider keine Quellen geben.

[Life Is Good]

Also, ich habe für mich persönlich noch keinen Punkt erreicht, an dem ich eine ID als besonders hilfreich empfand.

Mein Inventar und alles was dazu so gehört funktioniert tatsächlich über den Namen des Items (ScriptableObject) solange ich das System weiter entwickel und demnach solche Änderungen vornehme (wie name eben) lösche ich die alten Save Daten einfach (mach ich aber sowieso bei jeder Änderung während ich das Speicher und Inventar System änder, einfach zur Sicherheit) ich find das schicke und deutlich übersichlicher als beispielsweise blöde integer hin und herzuschieben, im Speicher und auch in den Logs etc. erkenne ich sofort was drin ist am Namen, Fehler sind schnell gefunden (finde einen Namen der da nicht hingehört findest du fixer als eine von ne Menge zahlen die du immer wieder nachschauen musst)

Klar, angenommen das Spiel ist schon released und man ändert den Namen zum Update, das ist dann was Blöd, aber versuche eben auch einfach sowas für eine veröffentlichte Version auch zu verhindern...

[AgentCodeMonk]

Schäm dich, Mark! Ich habe mehr von dir erwartet

[Hrungdak]

Früher wurde die GUID anhand der global eindeutigen MAC-Adresse der Netzwerkkarte und einem Zeitstempel gebildet. Mittlerweile sind die meisten Teile einer GUID nur noch Zufallszahlen. Bei dem großen Zahlenraum ist die Wahrscheinlichkeit, zwei gleiche GUIDs zu erzeugen, nicht messbar.

 

Für GUIDs gibts 3,40 * 10 Hoch 38 Möglichkeiten. Ich habs mal ausgerechnet. Wenn ich von einer einigermaßen aktuellen CPU ausgehe mit 4 GHz und weiter davon ausgehe, dass diese CPU pro Taktzyklus eine GUID erzeugt (was einigermaßen utopisch ist), sind das vier Milliarden GUIDs pro Sekunde. Um jede Guid zu erzeugen, benötigt diese eine CPU ca. 2.697.570.767.701.503.547.242 Jahre. Wenn man davon ausgeht, dass es weltweit zehn Milliarden CPUs gibt (einfach geschätzt...) und alle das gleiche machen: nach 269.757.076.770 Jahren (296 Milliarden Jahre!) wären alle GUIDs einmal durch. Unser Universum hat nach allgemeinen Schätzungen noch etwa sieben Milliarden Jahre vor sich...

[malzbie]

Wie das aber bei der Wahrscheinlichkeit leider so ist, kannst du auch 3 Mal hintereinander die gleiche ID bekommen.

Unwahrscheinlich, aber durchaus möglich!

Ich wollte es einfach nur mal erwähnen, will hier keinem Angst machen!

[Hrungdak]

Yup, technische Sperren dagegen gibts nicht mehr. Da hast du Recht. Deshalb ist es ja ganz gut, dass es Datenbank-Constraints gibt (hoffentlich), die die Eindeutigkeit nochmal prüfen...

 

Ich wollte nur mal der Zahl 3,40 * 10 hoch 38 einen Rahmen geben. So stellt sich jeder vor, na ja, ganz schön groß. Aber wenn man das mal ausrechnet, ist GIGANTISCH immer noch zu klein

[Ismoh]

Also, ich habe für mich persönlich noch keinen Punkt erreicht, an dem ich eine ID als besonders hilfreich empfand.

Mein Inventar und alles was dazu so gehört funktioniert tatsächlich über den Namen des Items (ScriptableObject) solange ich das System weiter entwickel und demnach solche Änderungen vornehme (wie name eben) lösche ich die alten Save Daten einfach (mach ich aber sowieso bei jeder Änderung während ich das Speicher und Inventar System änder, einfach zur Sicherheit) ich find das schicke und deutlich übersichlicher als beispielsweise blöde integer hin und herzuschieben, im Speicher und auch in den Logs etc. erkenne ich sofort was drin ist am Namen, Fehler sind schnell gefunden (finde einen Namen der da nicht hingehört findest du fixer als eine von ne Menge zahlen die du immer wieder nachschauen musst)

Klar, angenommen das Spiel ist schon released und man ändert den Namen zum Update, das ist dann was Blöd, aber versuche eben auch einfach sowas für eine veröffentlichte Version auch zu verhindern...

Mit einem String als Identifizierung ist es auf jeden Fall besser zu lesen, aber das möchte man ja auch nur, wenn man diese implementiert oder auf Fehlersuche ist.

 

 

Total krass was hier wieder für ne Party geht

Guid ist für mich keine Lösung, da das Format in diesem Fall nicht schön zu lesen ist.

 

Ich habe mir, währenddessen ihr hier philosophiert habt , eine Klasse geschrieben, die nach bereits vorhandenen Ids sucht und je nach Typ eine Neue erstellt oder die in Verbindung des Typs zurückgibt.

 

Die ID heißt idType und repräsentiert nur den Typen des Objekts.

 

Siehe Bilder anbei.

 

//EDIT:

Versteht mich nicht falsch: ich finde es sehr gut, wenn ihr hier diskutiert!