Neues Game, Womit anfangen?

Es geht um den Programmierteil. Es soll alles in PHP gecodet werden.
Nur wie fängt man am besten an. Es gibt viele Möglichkeiten, man könnte ein CMS wie Joomla zu nem Browsergame machen. Oder man nimmt ein fertiges Framework wie Cakephp, was ich sehr gerne mag und wofür ich mich im Moment entschieden habe.
Ganz von vorne alle selbst schreiben ist ziemlich viel Action, auch das hab ich schon durch
Ich denke ein gutes PHPFramework wäre wohl die beste Lösung. Gibt es da vielleicht welche die für die Browsergame Entwicklung zu bevorzugen oder zu empfehlen sind?
Die Einbindung von Smarty und evtl Ajax sollte dort möglich sein.
Wie habt ihr eure Projekte angefangen?
Grüße Silver.
P.s. Auch wenn ich das Forum unpassend finde, in die anderen komme ich nicht rein Hoffe ich darf trotzdem zur Diskusion anregen.

Ich bin da von Prinzip aus für die "ohne-alles" - Version. Kommt drauf an wie du dein BG aufbaust, aber heute empfiehlt sich sehr stark AJAX - daher hast du bei einem kleinen Seitenaufbau schon den Overhead der Initialisierung der gesamten Engine.
Ich finde auch Smarty nicht unbedingt geeignet um ein Browserspiel zu schreiben, da der Cache nur bedingt viel hilft... aber ich denke, mit diesen 2 Meinungen steh ich ziemlich allein da.
Entscheiden solltest du dich danach, wo dir das programmieren Spaß macht - Arbeit wirds noch mehr als genug.

1. Wozu Framework? 99% der funktionen passen auf ein Browsergame eh nicht und müssen dann angepasst werden.
2. Wozu in fremden (vllt. mit 1-2 Bugs/Scherheitslücken behafteteten) Code einarbeiten? Dann kann ich das auch gleich neu schreiben.
3. Wozu Smarty? Der Sinn einer Template-Engine innerhalb einer Template-Engine erschliesst sich mir nicht. Wenn man Templates nutzen möchte, dann kann man das auch ohne Overhead machen und nutzt (wie bspw. Savant3) php als Templateengine.
4. Weisst du, was AJAX ist? Weisst du, wie man damit umgeht? Da kann man nichts vorfertigen. Man kann es nur Kapseln. Mit nem Framework wie prototype reduziert sich ein request auf eine Objektinstanzierung mit Callback.
Generell haben Frameworks immer den Nachteil, dass sie zusätzlichen Overhead mitbringen.
Ansonsten bin ich - wie Nuky - vertreter der "ohne-alles"-Fraktion

*meld*
Kann mich da nur anschliessen. Einziger Nachteil: Wer alles selber macht hat keinen Sündenbock.

Ich empfehle auf jeden Fall TinyAjax, ein sehr einfach zu bedienendes PHP-AJAX-Framework.

CakePHP kann ich empfehlen das ist tatsächlich recht praktisch, zumal du nur die Libs einbauen kannst die du haben willst und der Overhead sich somit ziemlich in Grenzen hält.
Anschauen würde ich mir auch mal das ZendFramework, vielleicht ist das ja was für dich.
Und wenn du Ajax benutzen willst greif halt auf die üblichen verdächtigen JS-Libraries zurück, ich mag die Kombination prototype und scriptculous für kleinere Sachen

Original von Nuky
aber ich denke, mit diesen 2 Meinungen steh ich ziemlich allein da.

Absolut nicht. Ich teile deine Ansicht. Wer alles selbst programmiert, hat die volle Kontrolle über seinen Source Code und bekommt letztendlich auch genau das, was er benötigt. Zudem kann es problematisch sein, sich in die Abhängigkeit eines Frameworks zu begeben. Frameworks können auch plötzlich nicht mehr weiterentwickelt werden...
Gruß,
Marc

Ich mag großen overhead auch nicht, daher mag ich Cake ganz gerne, das kapselt einige Funktionen und bietet gute Funktionen für den Datenbankzugriff. Mit Smarty als Template kann man das ganze dann sehr schön und gezielt darstellen.
Der Cake core ist gerade mal 1 MB. Was ich für sehr überschaubar halte im Gegensatz zu z.B. 4,7 MB bei Joomla. Und man hat ne schöne MVC umgebung mit meiner Meinung nach sinnvoll festgelegten Strukturen.
Selbst gecodet wird es wenn man sich nicht im vornherein sehr viele Gedanken macht sehr schnell unübersichtlich. Grade wenn mehr als 1 Programmierer beteiligt ist.

Original von Quick_silver
Selbst gecodet wird es wenn man sich nicht im vornherein sehr viele Gedanken macht sehr schnell unübersichtlich. Grade wenn mehr als 1 Programmierer beteiligt ist.

Das kommt sehr darauf an, wie enge Grenzen man sich setzt.
Z.B. bei mir:

$ ls -l | grep -e '^d'

drwxr-xr-x 8 sdressel www-data 4096 2007-08-30 22:20 admin
drwxr-xr-x 2 sdressel www-data 4096 2007-09-11 15:02 ajax
drwxr-xr-x 3 sdressel www-data 4096 2007-08-30 22:20 class
drwxr-xr-x 2 sdressel www-data 4096 2007-08-30 22:20 css
drwxr-xr-x 2 sdressel www-data 4096 2007-08-30 22:20 genscripte
drwxr-xr-x 12 sdressel www-data 4096 2007-09-12 14:01 img
drwxr-xr-x 2 sdressel www-data 4096 2007-09-08 22:23 inc
drwxr-xr-x 4 sdressel www-data 4096 2007-09-12 13:44 js
drwxr-xr-x 3 sdressel www-data 4096 2007-08-30 22:20 konzept
drwxr-xr-x 2 sdressel www-data 4096 2007-08-30 22:20 pages
drwxr-xr-x 5 sdressel www-data 4096 2007-08-30 22:20 templates
in /class/ sind bei mir alle abstrakten Klassen (im eigentllichen nicht mehr als eine Funktionssammlung in Klassen gekapselt).
in / hab ich eine zentrale datei, die wie folgt funktioniert:
1. user prüfen (noch eingeloggt/gerade eingeloggt, div. sicherheitssachen, autologout, etc. pp.)
2. db-verbindung aufbauen und als Singleton verfügbar machen
3. einbinden der passenden /pages/...php-datei in einem switch-case
3.1. bearbeitung der user-anfrage (NUR hier findet eine interaktion user <-> code statt. Hier kommt auch das ganze escapen, validisierung etc. der vars hin, insb. $_REQUEST)
3.2. ggf. includieren einer /class/ und aufrufen einer geegneten methode (z.b. Gebaeude::build($user,$gid); oder Gebeaude::getList($user,$planet); ) zur behandlung der user-anfrage
3.2.1. innerhalb - und NUR innerhalb - der Klassenmethode findet die db-kommunikation statt
3.3. Zuweisung der ergebnisdaten in ein Template
4. Aufräumen (db-verbindung schliessen etc.)
5. Template darstellen (z.b. $tmpl->display('/templates/de/test.tpl.php'); )
Wenn man das ganz streng durchzieht, dann ist klar, wo welche Teile vom Code was machen. Durch die Klassen bleibt das ganze system generisch. Wenn man z.b. die Datenbank tauscht oder umstrukturiert, kann man sicher sein, dass nicht woanders noch teile von sql-code rumfliegen.
Aber das muss jeder für sich entscheiden. Ich bin mit meinem Weg voll zufrieden.

Ich schließe mich auch der ohne-alles Fraktion an - die Gründe warum wurden schon von Vorrednern genannt.
Aktuell fällt bei mir nur xajax unter die Kategorie 3thrdParty. Jedoch habe ich auch hier vor das noch zu ersetzen, ganz einfach weil ich bestimmt 80-90% der gegebenen Funktionen nicht nutze.

Hey Drezil, dein Verzeichnis sieht fast genau so aus wie bei mir.
Womit ich sagen will: Ordnung muss sein, und je höher der Umfang eines Projekts, umso wichtiger wird es auch das ganze in einer logischen Struktur abzulegen. Sowohl die Programmierung selbst (Stichwort: Klassen, OOP) als auch die simple Verzeichnis-/Dateitstruktur.
Und wenn man sich an diesen Grundsatz hält, kommt man evtl. sogar besser zurecht, als mit einem Framework.
Das einzige, was bei mir nicht selbst gecodet ist: Lightbox für die Anzeige der Screenshots auf der Frontendseite des Spiels.
Gruß,
Marc

Einmal ohne alles bitte...

Einmal ohne alles, dann wenig selbst aufbauen.
Ein kleines selbstgeschriebenes Framework mit Template-Einbindung, Datenbank und Sessions tuns.

Dann oute ich mich mal als jemand, der lieber zu Frameworks greift. Was den Lerneffekt betrifft, ist es vermutlich besser, wenn man alles selber macht. Aber wenn man mit den betreffenden Techniken so und so vertraut ist, und das selbst schreiben nur noch eine Fleißarbeit ist, macht es in meinen Augen keinen Sinn. Warum soll ich Sachen wie Logging-Engine, Test-Framework, Internationalisierung usw. immer wieder selbst schreiben?
Es gibt hervorragende Frameworks, und manche davon haben schon mehr oder weniger den Status von Industrie-Standards. Das sieht man besonders bei Java sehr gut, wenn man sich Frameworks wie JUnit, Log4J und Luscene ansieht. So etwas kann man ohne Probleme nutzen.
Frameworks selbst schreiben mache ich nur noch, wenn ich weiß, dass ich 100%ige Kontrolle brauche und sich die Arbeit läuft, weil man es immer wieder braucht. So habe ich mir selbst ein PHP Framework geschrieben, welches das FrontController und Command Pattern implementiert.

Kannst du irgendwelche PHP Frameworks empfehlen?

Das ist vermutlich Geschmackssache und Gewöhnung. Hier mal meine Standard-Sammlung:
Template-Engine => patTemplate
Datenbankzugriff => ADOdb
Unit Tests => PHPUnit
Darüber hinaus, will ich mir das Zend Framework mal genauer ansehen. Da könnten ein paar Sachen interessant dran sein. Im speziellem denke ich da an die MVC Klassen und das Logging, da ich noch keine vernünftige Logging-Lösung unter PHP gefunden habe. Das PEAR Modul ist zwar schon recht dicht an Log4J aber irgendwie nicht so wirklich schön. Musste es gerade aus einem Projekt rausschmeissen, weil es nicht so richtig funktionierte.

einmal für mit sparpaket
also ich bin ein absoluter fan vom orm-konzept und einer ordentlichen trennung von code und layout, da ich aber selbst keine zeit habe mir das zeug alles selbst zusammenzuschrauben greife ich da auf 2 third-party librarys zurück, für alles andere gilt aber auch bei mir: selbst ist der mann, dann weißt wenigstens wer was tut oder warum wer was nicht macht
btw. meine favoriten in der hinsicht sind phpDoctrine und auch Savant, die beiden reichen vom Funktionsumfang vollkommen aus, sind schön schnell und falls man mal wirklich zur Not selbst Hand anlegen muss, ist der Code gut dokumentiert und lesbar.

+1 für alles selber schreiben.
Insbesondere den Webserver selbst ;-)
Ok, CRT darf man fertig nehmen...

Ich würde mit den Anforderungen anfangen. Wenn man dann etwas findet, dass die Anforderungen mit weniger Aufwand erfüllt, als selbst geschriebenes, nimmt man das. Kommt das dann später mit der Performance/Flexibilität nicht hin, wird es ersetzt.
Der Vorteil von fertigen Komponenten ist meist, dass sie ausgiebig getestet sind und man sie nicht selbst schreiben muss. Der Nachteil ist meist, dass man sich er in sie einarbeiten muss und wenn man dann nur einen Bruchteil der Funktionalität verwendet, ist selbstschreiben oft intuitiver.
Und wirklich Inovationen bekommt man mit Standardkomponent wahrscheinlich eh nicht hin. Wenn google mit LAMP arbeiten würde oder auf einen Berater von IBM gehört hätten, wären die mit Sicherheit nicht da, wo sie heute stehen.

Ohne alles + mootools ;-)