mmofacts.com

Unter welchen Umständen PHP für Browsergames?

gepostet vor 13 Jahre, 6 Monate von graczykr

Hallo Community

Ich möchte mich erst einmal vorstellen. Mein Name ist Robert G. und ich entwickle inzwischen seit ungefähr 3.5 Jahren Webanwendungen, meine Kenntnisse würde ich als fortgeschritten bezeichnen. Da mich innerhalb der Webdesigntätigkeiten besonders die Entwicklung von Browsergames sehr interessiert, würde ich mich gerne an ein Projekt wagen.

Nun ist es so, dass ich bisher mit vielen verschiedenen Serversprachen gearbeitet habe. Um das ganze vielleicht als Liste zusammenzufassen: PHP, Python, Java, Javascript (Node.JS)

Ich weiss um die verschiedenen Vor-, resp. Nachteile der Sprachen, bin mir aber nicht ganz sicher, was für ein Browsergame geeignet wäre.

Wie der Titel bereits andeutet, mag ich die Entwicklung mit PHP.

Wobei ich mir jedoch nicht sicher bin, ist, ob PHP nun für ein Browsergame zu gebrachen wäre, besonders da mir ein Full-Screen 2D Strategiespiel vorschwebt, dass stark auf AJAX Polling setzen soll.

Ich bin noch Schüler, wenn möglich würde ich daher gerne auf günstiges Webhosting beschränken. (Was für mich ebenfalls ein Pro-PHP Argument ist...)

Es würde mich freuen, wenn mir ein paar Leute Denkanstösse zu dem Thema geben könnten. Vielleicht Leute, die selbst mit "requestlastigen" PHP Browsergames gearbeitet haben. Ansonsten bin ich wirklich für jede Hilfe / Anregung dankbar.

Ich freue mich schon auf eure Antworten und nochmals vielen Dank im Voraus

Robert G.

gepostet vor 13 Jahre, 6 Monate von NeoArmageddon

Bau ein Browsergame, mit der Sprache die du kannst/willst. Es kommt weniger auf die Sprache selbst an, als auf deine persönlichen Fähigkeiten. Es bringt nichts, ein Browsergame in PHP zu schreiben, wenn du in Java wesentlich besser und fitter bist.

Wenn du viel auf AJAX setzten willst, sehe ich kein Problem, warum im Hintergrund nicht PHP laufen soll. Ich finde die Arbeit mit AJAX + PHP 5 sehr angenehm.

Der Flaschenhals bei einem Requestlastigen Spiel, so wie du es schreibst, wird wohl eher an der Datenbank und deinem Webserver liegen und wie du deine Querys formulierst.

gepostet vor 13 Jahre, 6 Monate von Kevni

Hallo graczykr,

wie auch du bin ich ein relativ neuer Webentwickler in der Browsergame Branche. Ich habe mich durch diverse Browsergame-Projekte gekämpft, durfte sogar eines für 9 Monate leiten. Dabei konnte ich auch viele neue Dinge dazulernen.

Zurzeit entwickle ich ebenfalls ein Browsergame wobei ich gerade mit ein paar netten Leuten am Konzept sitze. Ich selber habe mir groß Gedanken über das Programmiertechnische gemacht. Mein Ziel ist es, ein "Client" mit JavaScript und HTML zu erstellen, der alle Daten via AJAX vom Webserver (lighttpd) läuft. Dabei benutze ich PHP 5.3 als Skriptsprache, sowie MySQL 5 als Datenbank.

Ich werde viel mit Stored Procedures arbeiten und möchte alle großen Rechnungen auf die SQL auslagern. Als Schnittstelle zwischen PHP und MySQL nutze ich MySQLi. Clientseitig arbeite ich mich gerade ein ein Javascript-Template ein. Zwischen Server und Client soll lediglich die nötigen Daten ausgetauscht werden (das geschieht im JSON Format). Javascript lädt dann ein Template (welches sich nach dem ersten Laden sogar in der Browsercache befindet) und füllt es mit den geladenen Daten. Schließlich wird es natürlich angezeigt.

So halte ich die Serverauslastung generell gering und nutze die Hardware des Benutzers. Heut zu Tage kann man das meiner Meinung nach ohne Rücksicht, da ein Großteil der PC's mit modernen Grafikkarten und modernen Prozessoren ausgestattet ist. Die moderne Browsergeneration ist sogar darauf ausgelegt ;)

PHP ist demnach auf keinen Fall schlecht, man sollte nur eben die Last der Anwendung aufteilen. Jede Programmiersprache hat Vorteile, diese muss man nutzen ;)

Mein Konzept ist selber noch in der Probephase. Das was ich schreibe ist mein "Plan" ;)

Hoffe konnte dir ein paar kleine Denkanstäße geben.

gepostet vor 13 Jahre, 6 Monate von buhrmi

Edit by khoernchen: Spam, wenns auch lustig war ;)

gepostet vor 13 Jahre, 6 Monate von Kampfhoernchen

Original von Kevni

Hallo graczykr,

wie auch du bin ich ein relativ neuer Webentwickler in der Browsergame Branche. Ich habe mich durch diverse Browsergame-Projekte gekämpft, durfte sogar eines für 9 Monate leiten. Dabei konnte ich auch viele neue Dinge dazulernen.

Zurzeit entwickle ich ebenfalls ein Browsergame wobei ich gerade mit ein paar netten Leuten am Konzept sitze. Ich selber habe mir groß Gedanken über das Programmiertechnische gemacht. Mein Ziel ist es, ein "Client" mit JavaScript und HTML zu erstellen, der alle Daten via AJAX vom Webserver (lighttpd) läuft. Dabei benutze ich PHP 5.3 als Skriptsprache, sowie MySQL 5 als Datenbank.

Ich werde viel mit Stored Procedures arbeiten und möchte alle großen Rechnungen auf die SQL auslagern. Als Schnittstelle zwischen PHP und MySQL nutze ich MySQLi. Clientseitig arbeite ich mich gerade ein ein Javascript-Template ein. Zwischen Server und Client soll lediglich die nötigen Daten ausgetauscht werden (das geschieht im JSON Format). Javascript lädt dann ein Template (welches sich nach dem ersten Laden sogar in der Browsercache befindet) und füllt es mit den geladenen Daten. Schließlich wird es natürlich angezeigt.

Ich bin eigentlich gegen Stored Procedures usw. Business-Logik sollte nicht in der Datenbank-Schicht liegen! Du wirst damit sehr schnell unflexibel und hat hohen Pflegeaufwand.

So halte ich die Serverauslastung generell gering und nutze die Hardware des Benutzers. Heut zu Tage kann man das meiner Meinung nach ohne Rücksicht, da ein Großteil der PC's mit modernen Grafikkarten und modernen Prozessoren ausgestattet ist. Die moderne Browsergeneration ist sogar darauf ausgelegt ;)

Browsergames werden zunehmend gerne auf Handys gespielt, da liegt die Rechenleistung nicht vor. Aber für deine Zwecke sollte das trotzdem gehen. Ich möchte natürlich daran erinnen: Alles was vom Browser kommt nochmal auf dem Server nachrechnen!

PHP ist demnach auf keinen Fall schlecht, man sollte nur eben die Last der Anwendung aufteilen. Jede Programmiersprache hat Vorteile, diese muss man nutzen ;)

Das mit der Last sehe ich auch so, grade die meisten BGs haben eine recht einfache Business-Logik und sehr viele DB-Operationen. Deshalb würde ich das trennen. Es nützt dir also nix, noch mehr Last Richtung DB zu schieben.

Mein Konzept ist selber noch in der Probephase. Das was ich schreibe ist mein "Plan" ;)

Hoffe konnte dir ein paar kleine Denkanstäße geben.

gepostet vor 13 Jahre, 6 Monate von Kevni

Hallo Kampfhoernchen,

Ich bin eigentlich gegen Stored Procedures usw. Business-Logik sollte nicht in der Datenbank-Schicht liegen! Du wirst damit sehr schnell unflexibel und hat hohen Pflegeaufwand.

Wieso werde ich dadurch unflexibel? Ich bin wie gesagt kein Profi und bin was Stored Procedures angeht noch am lernen. Bisher habe ich darin nur Vorteile gesehen.

Ich programmiere eine Wirtschaftssimulation (like Patrizier) und möchte die konstanten Daten die ich z.B. zum Brechnen des aktuellen Warenpreises brauche (Standartwarenpreis, oder Verbrauch pro Einwohner) in einer HEAP-Tabelle speichern. Von dieser werde ich nur Daten lesen. Sofern ich das Prinzip richtig verstanden habe ist die HEAP-Engine eine sehr schnelle, da sie auf dem Arbeitsspeicher liegt. Da die Daten Konstant sind und sich nicht ändern, wird ein möglich Absturz und somit folglicher Verlust der HEAP-Tabellen kein Problem darstellen.

Mit Stored Procedures oder Functions möchte ich nun Funktionen schreiben, die den aktuellen Preis der Ware einer Stadt berechnen. Angewendet wird es letzten endes via PHP dann so ( $mysqli->query(); )

SQL:

SELECT BerechnePreis(WarenID, StadtID);

Ich habe von mehreren Programmiern erfahren, das SQL generell schneller Rechnen kann. Daher möchte ich solche Berechnungen direkt in der Datenbank geschehen lassen.

PHP wäre dann nur für die Logik und für die Bereitstellung und Speicherung der Daten zuständig.

Browsergames werden zunehmend gerne auf Handys gespielt, da liegt die Rechenleistung nicht vor. Aber für deine Zwecke sollte das trotzdem gehen. Ich möchte natürlich daran erinnen: Alles was vom Browser kommt nochmal auf dem Server nachrechnen!

Das Spiel was ich plane ist generell schwer umsetzbar für kleine Displays, daher wird eine Handyversion in allen Punkten angepasst bereitgestellt werden. Der Client den der normale Benutzer am Rechner nutzt soll diese Vorstellungen nutzen.

Ich möchte natürlich daran erinnen: Alles was vom Browser kommt nochmal auf dem Server nachrechnen!

Das ist selbstverständlich ;)

Falls ich mich falsch ausgedrückt haben sollte: Im Browser wird nichts berechnet. Dies geschieht alles serverseitig. Der Client ist nur so ausgelegt, das er die Ergebnisse dieser serverseitigen Berechnungen darstellt. Ich möchte kurz gefasst damit sagen, dass ich kein HTML Code mit PHP generieren möchte ;) Dies geschieht alles clientseitig mit einer Javascript-Template-Engine.

...so zumindest meine Vorstellungen :)

gepostet vor 13 Jahre, 6 Monate von graczykr
Erst einmal vielen Dank fuer eure Antworten. Das Ganze hat mir bereits gut weitergeholfen, ich habe allerdings noch ein paar Fragen: 1. Ich entwickle mein Spiel so, dass es auf allen Plattformen spielbar sein wird. Da ich bei Google dazu nichts gefunden habe, wuerde ich gerne fragen, ob vielleicht jemand Benchmarks oder Vergleiche von PHP- und JS-generierten Templates hat. Wenn moeglich, waere es gut, wenn das Spiel auch auf iPod und iPad, sowie auch modernen Smartphones spielbar waere. Ist nun das Parsen mit JS oder aber das staendige Nachladen kompletten HTMLs aufwaendiger? 2. Wieviel bringt es genau Arbeiten an die Datenbank auszulagern? Merkt man bei aufwaendigen Berechnungen spuerbare Performancevorteile oder koennte man das genausogut mit PHP loesen? Hat vielleicht jemand vielleicht bereits Erfahrungen damit gemacht? Denn ansonsten teile ich die Meinung von Kampfhoernchen, die Datenbank sollte einfach fuer die Speicherung von Daten benutzt werden. 3. @buhrmi: Wie deinem Blog zu entnehmen ist, raetst du von PHP ab. Was sind die Gruende dafuer? Vielen Dank nochmals Robert G.
gepostet vor 13 Jahre, 6 Monate von MrMaxx

"Premature optimization is the root of all evil" !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Konzentrier dich lieber darauf ein Spiel zu bauen. Seh es als Prototypen an, den du eh irgendwann wegwerfen wirst (und das wirst du vermutlich eh irgendwann tun, wenn du lernfähig bist und nicht sofort aufgibst).

Benutz die Sprachen und Tools, die du kennst und beherrschst und nimm nur in einem beherrschbaren Rahmen neue Technologien in dein Projekt...und zum Thema Stored Procedures kann ich dir ein paar Punkte aus eigener Erfahrung sagen:

  • viel zu aufwändig für einen Hobbyprogrammierer (ca. doppelter Aufwand...nur ein ca. Wert, der aus bisheriger Projekterfahrung stammt)
  • deine IDE heist wieder NotePad+/UltraEdit, oder was auch immer
  • Geschäftslogik in der Datenbank ist nicht gut wartbar, da sie nicht gegen den Rest deiner Anwendung kompiliert/prüfbar ist (durch z.B. die IDE)
  • SP müssen manuell auf der Datenbank eingespielt werden (zusätzlicher Schritt in deinem Build-Prozess)
  • SP sind umständlicher zu testen, da immer Datenbankabhängig (zusätzliche Fehlerquelle) und dadurch nicht wirklich Mockup-fähig

Aus eigener Erfahrung kann ich dir nur sagen, dass Stored Procedures mit Bedacht eingesetzt werden sollten. In manchen Fällen macht es Sinn. Z.B. wenn du eine sehr schwergewichtige, datenbanklastige Operation hast, die viele Berechnungen macht (wie es ein Kampfscript z.B. ist). Allerdings ist in den meisten fällen simples SQL völlig ausreichend.

Maxx

gepostet vor 13 Jahre, 6 Monate von graczykr

Danke für die Antwort.

Ich bin alles nochmals durchgegangen und habe die Arbeit am BG mit PHP und NodeJS begonnen. Von dem, was sich bisher ergeben hat, werde das Spiel vermutlich mit Node erstellen, da mir die Arbeit damit interessanter erscheint als mit PHP, insbesondere habe ich auch relativ günstige Hosting Pakete gefunden, die für Node ganz gut in Frage kommen.

Ich wollte mich nochmals für eure Ratschläge bedanken, ihr habt mir sehr weitergeholfen.

Melde mich bestimmt nochmals wieder 

Besten Dank nochmals

Robert

Auf diese Diskussion antworten