Browsergame entwickeln: Wer hat Tipps und Informationen?

[Andes]

Hallo alle zusammen,

wie es schon in der Überschrift steht, plane ich (vielleicht) ein Browsergame zu entwickeln. Da ich jetzt schon den Aufschrei der Massen höre, werde ich erstmal einige Fakten vorraussagen.

-------------------BITTE LESEN (und nicht nur überfliegen)----------------------------------
Mir ist klar, dass viele den Hang zu Übertreibung innerhalb von Projekten haben. Dies soll bei diesem Projekt nicht der Fall sein. Da ich selbst aus der Spielebranche bin, habe ich entsprechende Erfahrung und Referenzen auf dem Gebiet der Spieleentwicklung. Ich weiß also was in welcher Zeit realisierbar ist, oder auch nicht!
Daher würde ich mich freuen, wenn hier sinnvolle Inhalte zusammengetragen werden, die vielleicht auch anderen Leuten helfen könnten.
-----------------------------------------------------------------------------------------------------

Technische Daten:
Bei diesem Spiel soll es sich um einen 2d Titel handeln, der ganz regulär im Browser abgespielt werden soll. Also kein Flash, Unity oder sonstige Plugins/Addons. Ich sage jetzt mal in Klammern, so wie "Die Stämme". Diese Aussage bezieht sich auf die Darreichungsform und nicht auf den Inhalt!!! Es soll KEIN 3d oder Echtzeit Spiel sein, sondern ein "typisches" Browsergame sein. Paar Bilder, beschreibende Texte und GamePlay funktionen (Knöpfe, Listen).

Über mich:
Ich bin ausgebildeter Anwendungsentwickler und habe Game Design studiert. Aber ich habe noch keine Erfahrung im Bereich der Browserentwicklung. Demnächst werde ich in einem mehrmonatigen Lehrgang meinen "WE C Web Designer Grade 1" sowie "WE C Web Developer Grade 1" machen. Der Lehrgang beinhaltet (kurzum): html, css, javascript, php, mysql. Ich denke daher, dass ich damit gut gerüstet bin um ein Browsergame zu erstellen.


Jetzt die eigentliche Frage. Hat jemand Erfahrung zu diesem Thema? Weiß jemand etwas über Server/Client Architektur? Tipps? Was muss man beachten? Interessante Quellen? Alles was euch wissenswertes einfällt.

Viele Grüße, Andes

[kristof]

Ich habe zwar selber keinerlei Erfahrung mit dem Thema, mir ist aber ein Podcast eingefallen, den ich vor einiger Zeit mal gehört hab. Es geht darin zwar nicht ausschließlich um Browsergames, aber der Interviewpartner Sebastian Heinisch betreibt selbst eines und berichtet dort über seine Serverstruktur.

http://technikwuerze.de/podcast/technikwuerze160/

Vielleicht hilft dir das ja.
Gruß, Kristof

[hagbard]

Naja Browsergames sind doch meistens schon Echtzeit oder sehe ich da was falsch? Bei den meisten Weltraumstrategiespielen sind es wenige Sekunden. Bei anderen Beispielen läuft jeden Tag eine Runde. Also irgendeine Echtzeitforderung ist da immer mit drin wobei die unterschiedlich lax sein kann. Aber vielleicht kenn ich auch einfach nur die falschen Games ;)
Die meisten werden meines Wissens nach in PHP und MySQL entwickelt.

[Chromanoid]

Also soweit ich das sehe, sind die meisten Browsergames a'la "Die Stämme" oder "OGame" einfach sehr große Webanwendungen. Für Webentwicklung im Allgemeinen gibt es zahlreiche Entwicklungsansätze, da ja im Prinzip jede größere etwas interaktivere Webseite einem Browsergame serverseitig in der Komplexität das Wasser reichen kann.
Wenn du nicht auf Flash oder Ähnliches als Ausgabeform setzen willst, würde ich clientseitig auf jeden Fall GWT einsetzen. Damit kannst du relativ schnell interaktive Oberflächen ohne Browser-spezifischen Kram in Java programmieren und dann in optimierten Javascript-Code übersetzen lassen. GWT bietet für Eclipse ein Entwicklungsplugin sowie einen Oberflächendesigner. Da Webapplikationen i.d.R. auch Kommunikation mit einem Server benötigen, bietet GWT eine recht einfache Möglichkeit mit Diensten, die in einem Java Servlet Container laufen, zu kommunizieren (GWT RPC) (inkl. Session Management durch J2EE). Um das Spielgeschehen zu aktualisieren (sofern nötig), solltest du Tasks einsetzen, die periodisch oder durch Ereignisse aufgerufen werden (ggf. einen Scheduler wie Quartz einsetzen).

Evt. solltest du dir über Skalierbarkeit Gedanken machen. Bei Browsergames reicht es wahrscheinlich, wenn du Datenbank-orientiert arbeitest und die Skalierbarkeit einfach dem DBMS überlässt. Deine Tasks müssen dann einfach nur auf der (ggf. verteilten) Datenbank arbeiten und Transaktionen sorgen dafür, dass sich die einzelnen Tasks nicht in die Quere kommen.

[Andes]

Naja Browsergames sind doch meistens schon Echtzeit oder sehe ich da was falsch?

Hehe .... ja Zeit läuft immer irgendwie ab. Was heißt der Begriff Echtzeit eigentlich? Beispiel: Du machst Need for Speed an. Drückst auf Start und los gehts... brum, brum. Du hast es geschafft. 2:30 Minuten später bist du im Ziel. Diese Zeit warst du permanent am Rechner. Daher 2:30 Minuten Echtzeit :)

[Chromanoid]

Naja ich würde auf jeden Fall von einer Gameloop (die ja im Grunde für Echtzeit-Spiele steht) absehen. Sowas ist für Browsergames IMO unnötig, verschwenderisch und unpraktisch... Vieles kann man wahrscheinlich während einer Abfrage erledigen.
(Wenn du kontinuierlichen Ressourcenfluss möchtest:) Bei der Berechnung von gewonnenen Ressourcen wird der Berechnungszeitpunkt einfach mitgespeichert... Bei Aktionen, die die Berechnung von Ressourcen oder die Ressourcen selbst verändern, wird einfach vor der Änderung nochmal der Ressourcenstand ermittelt. So kann man das ganze Spiel auf ein paar Berechnungen bei Aktionen/Interaktionen der Spieler reduzieren. Echtzeitberechnung ist da nicht nötig.

Ich würde die Zeit übrigens in Spielrunden o.Ä. normalisieren und so zum Einen das Spiel realzeitunabhängig machen und zum Anderen die Synchronisation erleichtern. Der Spieler kann ja dann trotzdem wieder Sekunden sehen, im Backend hingegen läuft die Spielzeit in Runden...

[hagbard]

Ich habe das etwas falsch gedeutet und den Begriff Echtzeit im technischen Sinne gebraucht.

Ein Browsergame ist zwar kein Echtzeitspiel im klassischen Sinne da nicht eine kontinuierliche Spielumgebung simuliert wird. Dafür werden aber fortlaufend Abfragen von alle möglichen Spielern beantwortet (und das sollte innerhalb einer bestimmten Zeit passieren) was für einen selbst als Spieler zur Folge hat dass z.B. die Kolos geraidet wurden sind während man mal kurz essen war. Die Spielwelt verändert sich also in der Regel fast so kontinuierlich wie bei einen Echtzeitspiel und weniger wie bei einen rundengesteuerten Spiel. Die interne Realisierung kann jedoch völlig anders aussehen. Typischerweise sind Browsergames ja nichts weiter als ein paar Berechnungs-Skripte mit einer komplexen Datenbank kombiniert. So würde man sicherlich kein Echtzeitspiel realisieren weil dort meistens alles selber simuliert werden muss was bei einen Browsergame durch die Interaktion von vielen Spielern geschieht.

[Chromanoid]

BTW http://mybrowsergame.com ist vielleicht einen Blick wert.

[Andes]

Danke schon mal bis hierhin. Das sind doch schon paar Informationen. Das System von mybrowsergame . com kenne ich und finde es bedenklich.
Folgenden Satz finde ich dabei sehr Beispielhaft:
"Die Kosten für die Nutzung der Professional Licence richten sich nach der Anzahl der angemeldeten User im Spiel. Wir berechnen eine Monatsgebühr von EUR 50,00 pro angefangene tausend Spieler."
Mit anderen Worten, auch wenn mein User mir nichts zahlen bzw. einfach nur einen Account anmelden und nie wiederkommen - ich bezahle schon mal was.
Man kann sich zwar für die "Free Licence" entscheiden, jedoch dürfen sich die User dann mit Werbung begnügen.

Na ja .... ich persönlich halte von dem Geschäftsmodel nicht viel.

[Löwe]

Ich hab vor etlichen Jahren mal angefangen ein browsergame zu entwickeln ... auch in dem stiel, der dir anscheinend vorschwebt. ich habe damals nur html/css, php, wenig javascript und eine mysql-datenbank verwendet.
Ich schreibe einfach mal drauf los ... Wenn dir irgendwas davon als selbstverständlich erscheint, nicht sauer sein, ich mein es nicht böse.

ich denke, man kommt mit html, php und ner datenbank wie mysql ode so schon recht weit. zumindest zum entwicken reicht es imho. um den traffic beim entwickeln gering zu halten hab ich nen apache-server auf meinen rechner laufen lassen, so das ich im browser über loclahost auch immer direkt sehen konnte, was ich geänderte hatte ... das cachen der dateien am besten im html-code untersagen ;) ... ohne erst wieder alles hoch zu laden, oder mich über fehlermeldungen meines web-hosts ärgern zu müssen.

ein problem über das du dir irgendwann gedanken machen solltest, ist das schummeln der spieler. wenn du auf java, flash o.ä. verzichtest, und nur mit html/css, javascript, php und so arbeitest, wird irgendwann ein spieler auf die idee kommen sich ein script zu basteln, das für ihn zumindest ein paar grundfunktionen bedient, während er selbst nicht am rechner sitzt. das war zumindets in den BGs die ich kenne untersagt und wurde entsprechend geahndet, ließ sich aber kaum nachweisen.

... über ein vernünftiges admin-tool solltest du dir entsprechend auch schon gedanken machen. Ich hab es beim Browsergame Vendetta selbst erlebt, dass sich gut ein jahr lang, auch über den start des 2. servers hinaus, viele spieler nicht an de regeln gehalten haben (z.B.: nur 1. Account pro Person; Keine rechtsradikalen Slogans o.ä. auf den Allianzseiten, leine Beleidigungen in den PNs, ...), und die Admins nichts machen konnten weil es kein Tool gab. Es gab nur einen entwickler der immer manuel in der Datenbank rum werkeln musste (oder ein tool hatte in das man niemanden sonst einarbeiten konnte). Und der hat sich dashalb wohl auch nur um das nötigste gekümmert.

Wenn du mit vielen Grafiken/Bildern arbeitest, überleg dir, was davon mit jedem Seitenaufruf wieder neu hochgeladen wird. Das was im Cache beim user liegt kann man afaik nicht vorraussetzten. Und ja, ich weiß, 1MB ist heute auch nicht mehr, was es vor 5 jahren war. Aber je nachdem in welchem sessel ich sitze, freu ich mich auch, wenn meine wlanverbindung nicht ganz so viel laden muss :)

... mehr fällt mir gerade nicht ein.

[Thoran]

Habe vor über 10 Jahren auch ein browser-basiertes Strategiespiel angefangen, was ich dann aber zwischen durch auf Eis gelegt hab. Angefangen hab ich das ganze mit html, CSS und ASP. Recht schnell hab ich das ganze dann nach ASP.NET umgezogen. Der Aufwand, für das Spiel, war denke ich vertretbar. Allerdings wollte ich es immer noch hübscher und schöner haben, so daß ich letzten Endes bei nem 3D-Client gelandet bin. Als Datenbank hatte ich am Anfang MS Access, später MySQL.
Eines der Hauptprobleme dabei war aber vorrangig Mulitaccounting, was sich auch über technische Mittel nicht so richtig in den Griff kriegen läßt. Das beste dabei ist es so etwas schon vom Gamedesign her auszuschließen bzw. nutzlos zu machen. Bot-ing hat ja Löwe bereits angesprochen.

Thoran

[Chromanoid]

ASP.Net halte ich auch für eine gute Wahl - besonders falls du nicht Java benutzen möchtest. PHP finde ich ein bisschen unangenehm zu entwickeln, aber mit Disziplin kann auch PHP Code sehr sauber sein :). Da in PHP ja schon seit Längerem Debugging auch kein Problem mehr ist, kann man PHP sicherlich auch gut einsetzen... GWT könntest du ja trotzdem in allen Fällen einsetzen.

Hinter MyBrowsergame steckt sicherlich ein seltsames Geschäftsmodell, aber zumindest Prototyping ist damit sicherlich gut machbar.

[Andes]

wow .... ja klar. Doppel Accounts und Bots. Jetzt wo ich es lese ist es klar, aber sowas hatte ich nicht bedacht. Danke.

Das würde ich gerne auch aufnehmen und daraus eine Frage machen. Wie sieht es mit Bots und anderen schummel-Aktionen aus? Ich weiß zwar was grundsätzlich damit gemeint ist, aber wie kann ich mir das vorstellen. Die können doch nichts auf den Server hochladen (entschuldigt mein null Wissen)?? Noch wichtiger als die Frage: Wie geht das? ist allerding die Frage: Wie verhinder ich das?

Die zweite Fragegruppe würde ich auf das Multi-Accounting eingehen. Was würde ich dagegen tun. Als erstes wird natürlich jede Email-Adresse nur einmal erlaubt, und alle Trash-Mail Provider werden gesperrt. Das durfte aber auch nur die unerfahrenen Schummler abhalten. Dann gib es ja noch diese "IP-Geschichte", es darf sich nur eine Person über eine IP einloggen. Das System ist mir aber nicht ganz klar. A) Woher weiß ich den die IP des eingeloggten B) Was ist wenn sich jemand in der Arbeit einloggt und der Kollege auch?

Eigentlich habe ich noch mehr fragen, aber das sind erst mal die wichtigsten. Freue mich auf antworten.

[Thoran]

Also ich hab über Multiaccounts lange nachgedacht und eine hunterprozentige technische Lösung gibt es nicht. Das beste ist es das vom GameDesign her nutzlos zu machen. Ich hab in meinem Strategiespiel wenigstens versucht abzumildern, so daß größere Spieler durch Multiaccounts keinen so großen Nutzen mehr ziehen konnten.

Boting kann man meiner Meinung nach in nem Browserspiel als Spieler dadurch erreichen, das man zB. HTML-Seiten parst und dann bestimmte Einagen an den Server schickt um Resourcen aufzubauen, wie das bei nem TCG aussieht, weiß ich net.

Ein Punkt hab ich noch vergessen, der für ein TCG eventuell irrelevant ist, und das ist Newbie-Bashing. Wenn man also aus einem Wettsreit mit nem anderen Spieler Aufwertungen erhält, die es einem ermöglichen Bonis für das eigene Spiel freizuschalten (wie immer diese aussehen), dann werden ein Teil der Spieler sich sozusagen schwache Gegner suchen die gerade angefangen haben zu spielen und diese Bashen um mehr solcher Bonis zu bekommen, was für die Neuanfänger frustrierend wird. Aber ich denke da muß man per GameDesign gegenwirken. Ein entferntes Beispiel ist GuilWars, was ja letztenendes auf einem Kartenspiel basiert (die 8 Skills, die man verwenden will, sind sozusagen aus einem Kartendeck(die gesamtheit der eigenen Skills) pro Runde auszuwählen). Dort wurde eben ein PvP Mode eingeführt, der Spieler gleicher Stärke in bestimmten Arenen zusammenfasste. Mit dem PvP Spiel konnte man sich dann immer wieder neue Skills/Karten freischalten.

Thoran

[Löwe]

Ich hab selber keine erfahrung wie man bots nutzt. Aber auf den Server laden wohl die wenigsten was hoch. In den meisten fällen sind es wohl scrips, die den client hijacken. z.b. wird dein game in nem frame geladen, und der parent-frame greift vie javascript auf die links und buttons deines games zu ... nur so als idee ;)
das würde gegen html sprechen. aber, das ist wohl auch geschmacksache.

mein lösungsansatz dafür wäre die namensgebung deiner seiten, links und buttons nicht starr im code festzulegen, sondern php beim erstellen des html-codes zufallsnamen geben zu lassen, die dann bei einem click des users auf den link allerdings erst wieder aufgelöst werden müssten. der bot/das script hätte in diesem fall keine möglichkeit nach dem element mit name xyz zu suchen. nach einem ähnlichen prinzip müsstest du auch den seitenaufbau zufällig gerinfügig ändern, um zugriffe auf das so-und-so-vielte-element zu unterbinden ... keine ahnung, ob es da nicht was einfacheres gibt. hab die idee damals zusammen mit dem game auf eis gelegt.

gegen mutil-accounts hilft imho nur das untersagen von mehreren accounts unter der selben ip ... und dann entsprechendes sperren der accounts die die selbe ip nutzen. wobei du dann auch ausschließt, das irgendwelche schüler über den schulserver sielen, bzw studenten in der uni, usw.
eine einschränkung der spielmöglichkeiten wäre da wohl sinnvoller. z.b. das handeln/tauschen (was auch immer dein spiel da anbietet) zwischen accounts mit der selben ip nicht zuzulassen.
... wobei sich das einlogen mit verschiedenen ips auch nicht als so schwer erweist.

Was bei vendetta damals zu meiner zeit auch "gern" gemacht wurde, war eine "alternative loginseite" zu erstellen um an die logindaten anderer spieler zu kommen ... gibt immer wieder dumme, die auf so links reinfallen. lässt sich aber imho von deiner seite aus nur bedingt unterbinden, wenn du nicht ne art TAN-System wie banken es haben einbauen willst ... also quasi ne liste mit einwegpasswörtern die sich der user ausdrucken kann, wenn er dem internetcafe um die ecke nicht traut ;)

was das bashen von newbies angeht, hängt es imho sehr an deinem spiel, wie und was du dagegen tun willst/kannst. bei mir waren damals auch NPCs im game vorhanden. geplant war eine art ruf-wert, der bei angriffen auf andere spieler ermittelt wird. angriffe gegen schwächere spieler senken deinen ruf. bei einem zu schlechten ruf, machen dir die NPCs immer schlechtere preise, die zahl der unerfreulichen NPC-begegnungen nimmt zu und der zugang zu einigen städten wird dir verwehrt.


... wo ich das ganze jetzt so tippe, bekomm ich fast lust den kram wieder aus zu graben und weiter zu machen

[pUnkOuter]

Ich rate dir, deinen SQL-Code auch noch von anderen Personen begutachten zu lassen, denn als Neuling kann man sehr leicht Abfragen schreiben, die schon bei wenigen hundert gleichzeitigen Zugriffen einen modernen Server ziemlich auslasten. Oder du brauchst gleich ein Framework mit Object Relational Mapping (für PHP z.B. Doctrine) und kümmerst dich nicht mehr um SQL. Auch Client-seitig könnte dir ein Framework natürlich viel Arbeit abnehmen (jQuery, Dojo, etc.), allerdings lohnt sich die Einarbeitungszeit nicht, wenn von vorneherein klar ist, dass das Projekt wahrscheinlich nicht fertiggestellt wird.

Ich würde dir trotzdem mal ein paar Tutorials zum Google Web Toolkit durchlesen, vielleicht kannst du das auch sonst mal gebrauchen.

[Tiles]

Hm, wie siehts eigentlich mit html5 aus? Was für ne Technik kommt denn dann da zum Einsatz?

[Chromanoid]

html5 ist im grunde einfach eine erweiterung vom normalen html. man hat dort dann ein paar mehr tags/objekte zur verfügung, mit denen man dann z.b. auch malen (canvas), videos (video) oder töne abspielen (audio) kann. außerdem gibt es auch noch den neuen WebSocket mit dem man mit einem server eine dauerhafte verbindung eingehen kann bzw der server etwas zum client schicken kann. natürlich kommt noch eine menge mehr zeug dazu, aber das sind imo die dinge die bei spielen vor allem interessieren.
leider bietet afaik websockets mit javascript keine möglichkeit binärdaten zu verarbeiten, was die möglichen austauscharten ziemlich einschränkt.
bei html5 muss man genauso wie vorher mit javascript die webseite steuern und hat einfach ein paar mehr möglichkeiten dabei. insgesamt hinkt html5 was die möglichkeiten betrifft flash noch ziemlich hinterher. wenn webgl nicht vor molehill etabliert wird, denke ich, dass wir noch lange zeit flash anwendungen und besonders spiele zu sehen bekommen.

es gibt übrigens schon ein browsergame in html5 von einem der marktführer (zynga) --> http://m.mafiawars.com/mobileweb
das ganze ist für mobile endgeräte optimiert. ich denke dort wurde wahrscheinlich html5 gewählt weil html5 eine"touch api" anbietet um multitouch geräte zu unterstützen und insgesamt ein paar mehr ui features mit html5 möglich sind (animiertes mouseover usw.). aber wahrscheinlich wurde html5 in der pressemeldung vor allem erwähnt um ein bisschen mehr aufmerksamkeit zu erlangen... wer weiß ob die die touch api überhaupt einsetzen...

[pUnkOuter]

Interessant in dieser Hinsicht ist auch WebGL: www.learningwebgl.com Sollte in den nächsten Chrome und Firefox Public Releases drin sein.

[Tiles]

Laut Pressemeldungen sollte ja HTML5 der Stein der Weisen werden, heh. Wieder was gelernt. Danke Chromanoid :)

[Chromanoid]

Interessant in dieser Hinsicht ist auch WebGL: http://www.learningwebgl.com Sollte in den nächsten Chrome und Firefox Public Releases drin sein.

Ja webGL ist in der Tat sehr interessant, allerdings wird IE9 das Ding wohl nicht einbauen. Das sollte den Einsatz von webGL im Browserbereich zumindest für Browsergame-Unternehmen recht risikoreich machen. Soweit ich das sehe, würde man als Unternehmen doch eher auf das etablierte Flash setzen, wenn es um 3D im Browser für die Massen geht (wenn dann 3D in Flash endlich möglich ist). Eine ernsthafte Chance, die ich für WebGL sehe, ist eine Etablierung auf mobilen Endgeräten. Evt. schafft webGL darüber eine etablierte Plattform auch im kommerziellen Bereich zu werden. Aber das sind nur Spekulationen meinerseits.
Am meisten nervt mich, dass mit HTML5 keine vernünftige Möglichkeit gekommen ist Binärdaten in javascript zu verarbeiten...

[pUnkOuter]

Für IE-Nutzer gibt es das Chrome Frame Plugin. Aber ja, ist natürlich schon unschön. Zum Glück hat IE lange nicht mehr die Marktdominanz aus früheren Jahren, so dass sich diesmal tatsächlich Microsoft evtl. einem offenen Standard wird fügen müssen. Ich denke, gerade im professionellen Bereich bietet WebGL viel Potential für interessante Anwendungen. Und Unternehmen sind in dieser Hinsicht extrem pragmatisch. Wenn eine WebGL Seite einen deutlichen Mehrwert bietet, und nicht mit IE funktioniert, dann wird eben ein anderer Browser verwendet.

[Chromanoid]

Für IE-Nutzer gibt es das Chrome Frame Plugin. Aber ja, ist natürlich schon unschön. Zum Glück hat IE lange nicht mehr die Marktdominanz aus früheren Jahren, so dass sich diesmal tatsächlich Microsoft evtl. einem offenen Standard wird fügen müssen. Ich denke, gerade im professionellen Bereich bietet WebGL viel Potential für interessante Anwendungen. Und Unternehmen sind in dieser Hinsicht extrem pragmatisch. Wenn eine WebGL Seite einen deutlichen Mehrwert bietet, und nicht mit IE funktioniert, dann wird eben ein anderer Browser verwendet.

Für normale Anwendungen mag das stimmen, aber meinst du wirklich, dass man es sich bei Browsergames leisten kann auf die immer noch sehr zahlreichen IE Nutzer zu verzichten? Gerade weil Browsergames eigentlich immer von möglichst hohen Benutzerzahlen abhängen. Das Free-To-Play Modell basiert ja darauf möglichst viele Leute zum spielen zu bringen, das klappt IMO mit WebGL mittelfristig wahrscheinlich nur bedingt.

[pUnkOuter]

Ja, da gebe ich dir schon recht. Aber gerade der Casual-Markt kommt ja gut ohne 3d aus. Was ich oben meinte, war, dass, falls sich die Sache gut entwickelt, M$ nicht darum herum kommen wird, WebGL auch im IE zu unterstützen. "WebDirectX" können sie eigentlich nicht bringen, denn z.B. Apple Produkte werden vermutlich nie DirectX unterstützen.

Obwohl...man soll niemals nie sagen.

[Chromanoid]

Ja da bin ich auch gespannt. Naja man muss wohl abwarten und Tee trinken ^^.

@Andes: Und bist du schon weiter gekommen? Hast du schon eine Technologie ins Auge gefasst?

[Andes]

@ Chromanoid
Sorry, dass ich erst heute antworte, aber irgendwie habe ich keine Benachrichtigung bekommen oder sie ist in meinem Postfach untergegangen.

Ja was soll ich sagen - schon nach dem ersten Beitrag war ich gänzlich eingeschüchtert. Wenn ich manche eurer Texte lese, komme ich mir wie ein Dummkopf vor, weil ich nur jedes zweite Wort verstehe. Die letzten Tage war ich im Web unterwegs, um mir weitere Informationen zu diesem Thema zu besorgen und dabei hat sich eine Sache herauskristallisiert.
Wichtig sind die Programmier-Kenntnisse bzw. das Verstehen der Zusammenarbeit der Komponenten untereinander! In diesem Zusammenhang musste ich auch an deine erste Aussage denken: "Ein Browsergame ist auch nur eine Webanwendung".
Also habe ich beschlossen folgendes Buch zu kaufen: "Dynamische Webseiten in der Praxis: Mit PHP 5, MySQL 5, XHTML, CSS, JavaScript und AJAX". In diesem Buch entwickelt man von der ersten Seite an ein kleines CMS. Ich hoffe, der Kauf ist die richtige Entscheidung. Thematisch passt es zumindest zu dem Lehrgang, den ich besuchen werde.

Mein Ziel ist es also zunächst dieses Buch durchzuarbeiten und dann mit erweitertem Verständnis zu entscheiden, wohin die Reise gehen soll.

[pUnkOuter]

Ist sicher eine gute Wahl. Wenn du ein herkömmliches deutsches Browserspiel ohne flüssige Animationen entwickeln willst, dann sollte dich dieses Buch gut darauf vorbereiten. Evtl. brauchst du dann noch einen Dienst wie Cron, damit du gewisse Dinge in einem regelmässigen Takt vom Server aus starten kannst. Aber wenn du Timestamps schlau einsetzt, sollte es auch ohne gehen. Um z.B. Ressourcen anwachsen zu lassen, scheint auf den ersten Blick ein regelmässiger Skritaufruf nötig zu sein. Aber man kann das auch machen, indem man einfach die Zeit nimmt, zu der ein User seine Ressourcen abruft, und wenn er sie dann das nächste mal aufruft, addiert man einfach die Ressourcen, die laut Formel in der verstrichenen Zeit produziert worden wären, dazu. Man sagt dem auch Ereignisbasierte Simulation, weil zwischen den Ereignissen (Aktionen des Spielers) nichts gerechnet wird.

[TheBenji]

Ums genau zu nehmen ist die von pUnk Outer beschriebene Methode die grundlegend vorzuziehende.
Es gibt nur weniger ereignisse die per cron zu lösen sind.
Es hat einfach den Vorteil das es berechnet wird wenn es gebraucht wird und vor allem auf einmal.
Wenn ich einen Tag nicht drin war brauche ich so nur eine Rechnung statt denn gefühlten 1000 die ich per cron bräuchte ;)
Natürlich hat es auch vorteile in der serverlast, ich lasse nicht alle 5 minuten von allen spielern die ressourcen (what ever) berechnen was bei hohen spielerzahlen extrem aufwendig wäre sondern nur für die spieler gerade dann wenn es von nöten ist.
Solltest das also im normalfall immer vorziehen um effektive bg's zu schreiben^^

[Chromanoid]

Noch zwei links die mir heute vor die Flinte geraten sind...
http://buildingbrowsergames.com/tutorials/
http://www.browsergames24.de/os.php