Datenbank design für z.B. Browsergame

PRIEST

Servus,

ich wollte mal bissl rumfragen wie Ihr denn eine Datenbank für ein Browsergame in etwa designen würdet. Mir geht es hauptsächlich darum das es schnell ist und dass es nicht irgendwann "überläuft".

Sagen wir mal zum Beispiel wir hätten ein Browsergame und der Spieler1 Loggt sich ein. Er führt eine Aktion aus z.B. Holzhacken. Diese Aktion dauert 3 Stunden.
Wie würdet ihr das in die DB schreiben? Mein Anstaz war jetzt eine Aktionstabelle zu bauen in der ich jegliche Aktionen von allen Spielern reinschreibe PK eventuell SpielerID&Datum.

Die Aktion ist vorbei und der Holzschatz wurde um etwa 100Punkte erhöht. Dann wäre es doch eig. angebracht diesen Posten wieder aus der Aktionstabelle zu löschen.

Tut mir leid wenn es unverständlich ist auf was ich hinnaus möchte oder gar unverständlich überhaupt

Meine Bedenken liegen jetzt nur darin, dass wenn ein Browsergame oder eine Community mehrere Tausend Besucher das mir die Seite nicht Lahmt. Wobei sich das bei einem Brwosergame noch in grenzen halten kann da ein Spieler bestimmt nich mehr als ca. 30 Aktione aufeinmal ausführen könnte (Wegen Virtuellenschatzkapazitäten ;)). Aber bei einer Community von ca. 100.000 Nutzern bei der jeder User ein Gästebuch besitzt mit hunderten von Einträgen usw.

Danke für eure Antworten. Ich denke immernoch und schreibe parallel dazu eventuell nicht das beste

*Heul*
Hab auch mal angefangen mit nem Browsergame, musste aber aus Zeitmangel beendet werden.
Macht aber Spass; ist ein nettes Thema und kann bei ausreichend Zeit auch von einem Programmierer zu einer spielbaren Version gebracht werden.
Aber zum Thema:

PRIEST schrieb:

Sagen wir mal zum Beispiel wir hätten ein Browsergame und der Spieler1 Loggt sich ein. Er führt eine Aktion aus z.B. Holzhacken. Diese Aktion dauert 3 Stunden.
Wie würdet ihr das in die DB schreiben?

Gar nicht!
Ich kenne bei so Browsergames nur 'Travian' und bei Abstürzen konnte da 'laufende Aktionen' auch nicht rekonstruiert werden.
Also speichern die das wahrscheinlich auch nicht. Wozu auch?
Die Game-Engien muss ja laufend aktuelle Events bearbeiten.
Soll da sekündlich (oder wie genau soll's sein) die DB abgefragt werden, ob gerade was anliegt?
Dass sollte doch besser permant im Speicher gehalten werden.

nurf

Ja Datenbank-Design ist sehr wichtig !!!
Ich kenne deinen SQL-Background nicht, von daher empfehle ich erstmal dich mit dem Thema "Datenbank-Normalisierung" zu beschäftigen. Dann erledigen sich einige Grundlegende Probleme.

Problem 1: Zu große Tables
Wenn man alles in eine Table speichert, geht das gut, solange man keine Schreibzugriffe durchführt, denn dann muss die Table "gelockt" werden und in der Lock-Zeit kann keiner was damit anfangen.

Problem 2: Zu viele direkte Datenbankzugriffe
Nicht alle "Dienste", die auf der Datenbank arbeiten, brauchen aktuelle Daten.
D.h. eine Highscore-Abfrage muss nicht zwangsläufig ein Select Max über die Haupttabelle sein.

Problem 3: Joins

for ( int i = 0; i < results; ++i){
  myDB->Query("Select * from blub where id= %s", id[i]);
  ...
}

Sowas hab ich auch schon gesehen ...

Greetz

PRIEST

@nurf Normalisierung hab ich lange durchgkauen müssen wegen beruf.
Ich muss mir einfach mal mehr gedanken machen wie ich das am besten mit der DB löse ... aber für ideen wie gesagt bin ich offen.

@Jockelx
Laufende events? Halte ich für ein browsergame ala O-Game für unnötig. Weiß ja nicht wie die das gemacht haben. Aber es reicht doch einfach eine neue abfrage zu machen auf bestimmte posten wenn man die Seite Refresht, sich einloggt oder der JavaScript Zähler der die Zeit angibt auf 0 gelaufen ist für diese Aktion.

PRIEST schrieb:

@nurf Normalisierung hab ich lange durchgkauen müssen wegen beruf.
Ich muss mir einfach mal mehr gedanken machen wie ich das am besten mit der DB löse ... aber für ideen wie gesagt bin ich offen.

@Jockelx
Laufende events? Halte ich für ein browsergame ala O-Game für unnötig. Weiß ja nicht wie die das gemacht haben. Aber es reicht doch einfach eine neue abfrage zu machen auf bestimmte posten wenn man die Seite Refresht, sich einloggt oder der JavaScript Zähler der die Zeit angibt auf 0 gelaufen ist für diese Aktion.

Hi,

ich hatte auch mal ein Browsergame geschrieben. Dabei handelte es sich allerdings um ein Strategiespiel. Man konnte Gebäude bauen, forschen, usw. Dafür hatte ich dann jeweils eine eigene Tabelle. In dieser Tabelle habe ich dann die Endzeit geschrieben. Alle Zeiten in UTC!

Wenn der Spieler dann wieder etwas macht, wird überprüft, ob der Bau bereits abgeschlossen ist, ist das der Fall, dann wurde beispielsweise die Rohstoffproduktion erhöt und der Eintrag aus der Datenbank gelöscht.

Du solltest auch die Zeiten immer länger werden lassen. Das heißt die Spieler, die weiter sind, brauchen automatisch länger und die Ereignisse treten nicht bei jedem Spieler alle 3 Sekundene in sonder bei einem nach 20 Stunden, bei dem anderen nach 10 Minuten, usw...

BBBB schrieb:

PRIEST schrieb:

@nurf Normalisierung hab ich lange durchgkauen müssen wegen beruf.
Ich muss mir einfach mal mehr gedanken machen wie ich das am besten mit der DB löse ... aber für ideen wie gesagt bin ich offen.

@Jockelx
Laufende events? Halte ich für ein browsergame ala O-Game für unnötig. Weiß ja nicht wie die das gemacht haben. Aber es reicht doch einfach eine neue abfrage zu machen auf bestimmte posten wenn man die Seite Refresht, sich einloggt oder der JavaScript Zähler der die Zeit angibt auf 0 gelaufen ist für diese Aktion.

Hi,

ich hatte auch mal ein Browsergame geschrieben. Dabei handelte es sich allerdings um ein Strategiespiel. Man konnte Gebäude bauen, forschen, usw. Dafür hatte ich dann jeweils eine eigene Tabelle. In dieser Tabelle habe ich dann die Endzeit geschrieben. Alle Zeiten in UTC!

Wenn der Spieler dann wieder etwas macht, wird überprüft, ob der Bau bereits abgeschlossen ist, ist das der Fall, dann wurde beispielsweise die Rohstoffproduktion erhöt und der Eintrag aus der Datenbank gelöscht.

Du solltest auch die Zeiten immer länger werden lassen. Das heißt die Spieler, die weiter sind, brauchen automatisch länger und die Ereignisse treten nicht bei jedem Spieler alle 3 Sekundene in sonder bei einem nach 20 Stunden, bei dem anderen nach 10 Minuten, usw...

Ich habe noch etwas vergessen. Damit jein Spieler nicht sehr wenige Punkte hat, da er sich nie einloggt und daher keine Punkte gutgeschrieben bekommt, solltest du ein Cronjob einrichten, der einmal am Tag (wenn wenig los ist) für alle Spieler die Punkte neu berechnet

PRIEST

BBBB schrieb:

BBBB schrieb:

PRIEST schrieb:

@nurf Normalisierung hab ich lange durchgkauen müssen wegen beruf.
Ich muss mir einfach mal mehr gedanken machen wie ich das am besten mit der DB löse ... aber für ideen wie gesagt bin ich offen.

@Jockelx
Laufende events? Halte ich für ein browsergame ala O-Game für unnötig. Weiß ja nicht wie die das gemacht haben. Aber es reicht doch einfach eine neue abfrage zu machen auf bestimmte posten wenn man die Seite Refresht, sich einloggt oder der JavaScript Zähler der die Zeit angibt auf 0 gelaufen ist für diese Aktion.

Hi,

ich hatte auch mal ein Browsergame geschrieben. Dabei handelte es sich allerdings um ein Strategiespiel. Man konnte Gebäude bauen, forschen, usw. Dafür hatte ich dann jeweils eine eigene Tabelle. In dieser Tabelle habe ich dann die Endzeit geschrieben. Alle Zeiten in UTC!

Wenn der Spieler dann wieder etwas macht, wird überprüft, ob der Bau bereits abgeschlossen ist, ist das der Fall, dann wurde beispielsweise die Rohstoffproduktion erhöt und der Eintrag aus der Datenbank gelöscht.

Du solltest auch die Zeiten immer länger werden lassen. Das heißt die Spieler, die weiter sind, brauchen automatisch länger und die Ereignisse treten nicht bei jedem Spieler alle 3 Sekundene in sonder bei einem nach 20 Stunden, bei dem anderen nach 10 Minuten, usw...

Ich habe noch etwas vergessen. Damit jein Spieler nicht sehr wenige Punkte hat, da er sich nie einloggt und daher keine Punkte gutgeschrieben bekommt, solltest du ein Cronjob einrichten, der einmal am Tag (wenn wenig los ist) für alle Spieler die Punkte neu berechnet

Hi, danke für die Bestätigung, genauso hatte ich mir das auch gedacht.

Für Spiele mit sehr großer Spieleranzahl würde ich einen eigenen Server schreiben, der die Daten im Speicher behält und nicht bei jedem Zugriff die DB abfrägt. Die Datenbank Synchronisierung würd ich dann im Hintergrund laufen lassen. Der Nachteil ist aber, dass du bei einem Servercrash ein Rollback machen musst und so Daten verloren gehen.