spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Es gibt Tools wie z.B. Apachebench, mit denen man einfach mal eine gewisse Anzahl an Requests erzeugen kann und dazu Statistiken bekommt. Da kannst du dir mal anschauen wie sich dein Browsergame mit wachsender gleichzeitiger Spielerzahl verhält und auch mal profilen wo der Flaschenhals sitzt.

Ansonsten würde ich nicht davon ausgehen, dass dir die Spieler am ersten Tag den Server einrennen. Fang vielleicht mit einem kleinen Webspace oder VServer an und wenn du siehst das es nicht mehr reichen wird, kannst du immer noch was größeres nehmen, DB auf einen separaten Server umziehen etc.

Ich stimme Tobi da absolut zu. Solange du kein Riesenbudget in Marketing investierst, wird ein kleiner Server anfangs genug sein. Da reicht dann sicherlich auch ein mittlerer vServer von HostEurope (, die ich uebrigens sehr empfehlen kann). Auch verschiedene Server fuer einzelne Teile des Games braucht man erstmal nicht, allerdings macht man nichts falsch, wenn man das Game so programmiert, dass es das auch kann, wenn es denn spaeter doch mal gebraucht wird.

Fuer einen Belastungstest eignet sich meiner Meinung auch eine Open Beta vor dem Release sehr gut. Damit suggeriert man den Spielern, dass das Spiel noch nicht stabil laeuft und kann ein paar Sachen testen. Ganz nebenbei kann man seine Userbase ein bisschen aufbauen und einen kleinen Lasttest unter realen Bedingungen durchfuehren. Mit ein bisschen Monitoring sieht man dann ganz gut, an welchen Stellen man noch ein bisschen schrauben muss.

Das mit den Open Beta's empfinde ich auch manchmal so, aber nur weil so eine Betaphase von einigen seltsam genutzt wird, heisst das ja nicht, dass man das auch so machen muss.

Ich habe bei HostEurope einen vServer (den es allerdings so nicht mehr gibt), allerdings laeuft da kein Browsergame drauf und von Last kann man bei den paar Dingen darauf auch nicht sprechen. Der Support ist allerdings klasse, man wird per E-Mail ueber Wartungsarbeiten informiert, die einen treffen koennten. Bei Ausfaellen wird man stets ueber den derzeitigen Status der Arbeit informiert (sowohl per E-Mail als auch im Kundenbereich). Bevor du nun Angst bekommst, es gab bisher nur einen groesseren Ausfall in den letzten 3 Jahren.

Mir fallen hier zweit unterschiedliche Ansaetze ein:

a) Du faengst mit nem kleinen Prototypen an und machst dir nicht viel Gedanken um Skalierbarkeit. Der Vorteil hier ist, dass du sehr schnell vorzeigbare Ergebnisse hast, und schon frueh mit einigen Spielern spielen kannst. V-Server kann man in einem gewissen Rahmen noch gut skalieren (man bucht einfach etwas mehr CPU/Ram dazu und hat sofort etwas mehr Performnance).
Der offensichtliche Nachteil ist, dass du ab einer Gewissen Userzahl ein Problem hast. Du musst auf einen neuen Server portieren oder deine gesamte Serverseite neu schreiben um Skalierung zu unterstuetzen.

b) Du programmierst von Anfang an mit unterstuetzung fuer Skalierbarkeit. D.h. du baust deine Anwendung so, dass sie auf mehrere V-Server verteilt werden koennen, die Datenbanken verteilt werden koennen, etc. Das ist alles andere als einfach und macht die Entwicklung um ein vielfaches komplexer.
Alternativ koenntest du jedoch auch auf Cloud Dienste setzen (Google App Engine, https://www.heroku.com/, Microsoft Azure, etc). Der Nachteil an den Diensten ist, dass du nicht mehr PHP/MySQL nutzen kannst, sondern auf die API des Cloud Dienstes angewiesen bist, welche dir jedoch quasi automatisch Skalierbarkeit bringen. Dieser Ansatz ist mehr Aufwand in der Entwicklung (lernen neuer APIs/Sprachen oder komplexe Entwicklung in PHP) aber du kannst ohne viel Aufwand auf beliebige Nutzerzahlen skalieren.

Welchen Ansatz du hier benutzen moechtest kommt denke ich auf deinen Fokus an. Wenn du dein Browsergame moeglichst flott ans laufen kriegen willst um Feedback von Spielern zu bekommen und zu sehen ob es erfolgreich sein kann, dann wuerde ich mit a) anfangen und spaeter auf b) umschwenken.

Wenn du Spass an Serverseitiger Entwicklung hast und dir der zusaetzliche Entwicklungsaufwand nichts ausmacht, dann ist b) ne gute option... man lernt verdammt viel darueber wie man Webseiten ordentlich skaliert.