Dokumentation zum Massive Multiplayer Online Game - Universität ...
Dokumentation zum Massive Multiplayer Online Game - Universität ...
Dokumentation zum Massive Multiplayer Online Game - Universität ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
5. Spieler, Allianzen und Nachrichten<br />
64<br />
Planung<br />
Die Beziehung zwischen den User und der Tabelle Relationship<br />
Problemstellung<br />
Es gab zwei grundlegende Fragen:<br />
• Wie kommt man am schnellsten an alle Freunde des Spielers, wenn nur einer von ihnen "friend" sein kann?<br />
• Wie implementieren wir das Konzept der Einladungen, sodass es einen Status "pending" gibt, damit<br />
gegenseitiges Einverständnis erreicht werden kann?<br />
• Lösungsidee: wir versehen die Relationship mit einem String-Attribut "status". Dieser kann sein:<br />
• "pending"<br />
• "accepted"<br />
• "declined"<br />
Jedoch haben wir uns aufgrund der hohen Unübersichtlichkeit nicht für dieses Konzept entschieden.<br />
Implementierung<br />
Model<br />
User<br />
Dem User werden sowohl die Relationships selbst, als auch die Freunde zugewiesen.<br />
user.rb:<br />
has_many :relationships<br />
has_many :friends, :through => :relationship, :source => :friend<br />
has_many :users, :through => :relationship, :source => :user<br />
has_many :reverse_relationships, foreign_key: "friend_id", class_name: "Relationship"<br />
Hier fällt auf, dass der User nicht nur mehrere "friends" hat, sonder auch mehrere "user". Das liegt an unserer<br />
Implementierung der Relationships. Das Konzept ist folgendermaßen zu erklären:<br />
Aufteilung in Spieler und Freund<br />
In der Tabelle Relationship werden für jeweils eine Beziehung zwei Einträge erstellt:<br />
1)spieler1-->spieler2