Programiersprache für Browsergame

[ice-breaker]

Google nutzt für viele Dienste (z.B. YouTube) BigTable

nicht nur
Immerhin bringt auch Google viele Patches für MySQL mit interessanten Features raus.

aber ehrlich gesagt kommen wir total vom Thema ab.
Immerhin wird auch Youtube noch weit mehr Storage-Engines einsetzen, denn die eine für jeden Zweck gibt es nicht. Da müssen eben auch mal die Informationen in verschiedenen Software gespeichert werden, und das ist was ich meine:
Nutze für eine Aufgabe das richtige Tool.

 

[DerFabi]

Guuut... also das ganze geht hier schon teilweise viel zu weit...


Also die Spielmechanik ist eig. relativ schlicht, im Grunde soll die Basis ein schlichtes Aufbau-Spiel sein, so im Stil von Travian oder was es da halt so gibt, man kann seine Gebäude ausbauen, Einheiten ausbilden.. dazu soll man Einheiten Leveln können, des weiteren brauchen wir ein flexibles Gruppensystem. Die Spieler können sich natürlich gegenseitig angreifen etc.

Im Grunde könnte das allermeiste Text dargestellt sein (außer eine Karte die die Positionen der Spieler darstellt vllt.)
Dazu gibt es eine Art Computergegner, der nach einer bestimmten Zeit eine bestimmte Gruppe von Leuten angreift.

Also im Grunde relativ schlicht.

Nichts wo man aktiv irgendwas bewegen könnte oder so,

man wird das Spiel also auf jeden Fall mit PHP und MySQL programmieren können, aber gibt es vielleicht bessere Alternativen? Das ist halt eigentlich meine Frage.. ich kenne nicht besonders viele Sprachen und es gibt scheinbar ziemlich viele..

Ich bin ein Fan von objektorientierter Programmierung, falls ihr das in euer Empfehlung einfließen lassen wollt

Danke, für die bereits gegebenen Antworten.

 

[saitho]

Also die Spielmechanik ist eig. relativ schlicht, im Grunde soll die Basis ein schlichtes Aufbau-Spiel sein, so im Stil von Travian oder was es da halt so gibt, man kann seine Gebäude ausbauen, Einheiten ausbilden.. dazu soll man Einheiten Leveln können, des weiteren brauchen wir ein flexibles Gruppensystem. Die Spieler können sich natürlich gegenseitig angreifen etc.

[....]

man wird das Spiel also auf jeden Fall mit PHP und MySQL programmieren können, aber gibt es vielleicht bessere Alternativen? Das ist halt eigentlich meine Frage.. ich kenne nicht besonders viele Sprachen und es gibt scheinbar ziemlich viele..

Mit PHP und MySQL schaffst du das allemal. Aber Spiele wie Travian gibts recht viele, teilweise gibt es auch Fertigscripte, die man nur hochladen und installieren muss.
Ich denke ein Aufbau-/Dörferspiel kann Erfolg haben, wenn es überzeugt (ist ja eigentlich klar *g*). Könntest, wenn das Spiel steht, vielleicht etwas mit JavaScript oder so machen, um ein paar Features hinzuzufügen, wie z.B. Countdowns bei den Restzeiten beim Gebäudeausbau und sowas.
Kommt meistens aber auch auf die Grafiken an, weil ein Spiel mit Kindergartengekritzel bekommt meiner Meinung nach nur wenige Spieler.
Wünsche dir auf jeden Fall viel Spaß und Erfolg mit deinem Spiel.

 

[tobomator]

Eine richtig gutes DBMS ist Sybase.
Wer damit mal zu tun hatte, der freundet sich sehr schlecht mit andern Alternativen an!
Aber das Thema hier sinnlos auszuweiten, was kommerzielle Sachen anbelangt ist wohl nicht nötig.

@Ice: woher weißt Du das Google MySQL benutzt ?

 

[Bububoomt]

hat Ice doch geschireben, weil google jede menge Verbesserungen für MySQL raus bringt. Werden die wohl kaum machen wenn Sie MySQL nicht benutzen.

 

[ice-breaker]

Eine richtig gutes DBMS ist Sybase.
Wer damit mal zu tun hatte, der freundet sich sehr schlecht mit andern Alternativen an!

Ab diesem Punkt hast du ehrlich gesagt für mich jegliche fachliche Kompetenz verloren.
Ein Fanboy wie du kann keineswegs unvoreingenommen entscheiden, und wer mit Thesen kommt, dass wenn man mit X gearbeitet hat, dass man eigentlich nicht mehr mit anderen Produkten arbeiten möchte hat einen sehr beschränkten Blickwinkel.
Ich kenne zwar Sybase nur sehr wenig, aber diese Datenbank wird genauso ihre Schwächen haben wie andere Datenbanken auch, weshalb auch diese Datenbank für manche Dinge ungeeignet sein wird, sonst hätte sie im kommerziellen Bereich wahrscheinlich schon längst Oracle abgelöst (, die ein breites Spektrum mit einer wirklich guten Software abdecken, aber eben auch nicht alles).

Aber das Thema hier sinnlos auszuweiten, was kommerzielle Sachen anbelangt ist wohl nicht nötig.

da dies ein Hobbyprojekt ist, jup.
Btw: Es gibt auch kostenlose Oracle-Versionen
Key-Value-Stores würden sich je nach Design der Applikation eventuell auch anbieten, mit dem richtigen Design und Workload übertreffen sie die Performance einer relationalen Datenbank um ein vielfaches.
(Sie sind aber nicht für jedes Problem anwendbar)

@Ice: woher weißt Du das Google MySQL benutzt ?

ich habe dir sogar Quellen verlinkt
und eine Google-Suche liefert dir noch weit mehr.


Wir sind aber weit vom Thema abgewichen.


@DerFabi: schaut euch an von welchen Datenbanken und Sprachen ihr genug Erfahrung habt und nehmt einfach die, dies ist wirklich keine Applikation, die besondere Software braucht. Ist ja nicht mehr als ein bisschen Eingabe-Ausgabe.
Als Tipp: vollkommen objektorientiert bauen, prozedural mit Spaghetti-Code werdet ihr gnadenlos scheitern
Wenn an 5 Stellen Codestücke stehen um X zu berechnen habt ihr später riesige Probleme, wenn ihr im Nachhinein etwas ändern wollt.
Und je nachdem welche Sprache ihr nutzt, nehmt auf jedenfall ein Framework zum entwickeln, das bringt euch mehr Struktur und besseren Code.
Und hier sollte nun wirklich keiner einen Vorschlag machen, die Entwickler sollen sich das aussuchen, was ihm am besten gefällt.
Denn auch wenn manche glauben Sie würden das beste Framework (bzw. die beste Datenbank, Sprache, sonstwas) nutzen, das ist falsch, jede Software wird auf Grund von bestimmten Annahmen und Vorlieben geschrieben, wenn die auseinandergehen hat man damit auch keinen Spaß.

 

[tleilax]

@DerFabi: ...

Full Ack. Besser hätte man es wohl nicht ausdrücken können...

 

[Banane]

Als Tipp: vollkommen objektorientiert bauen, prozedural mit Spaghetti-Code werdet ihr gnadenlos scheitern
Wenn an 5 Stellen Codestücke stehen um X zu berechnen habt ihr später riesige Probleme, wenn ihr im Nachhinein etwas ändern wollt.

Nicht objektorientiert zu programmieren führt nicht automatisch zu Spaghetticode oder zum Verletzen des DRY-Prinzips und objektorient programmieren bewahrt einen nicht automatisch davor.

 

[tobomator]

Nicht objektorientiert zu programmieren führt nicht automatisch zu Spaghetticode oder zum Verletzen des DRY-Prinzips und objektorient programmieren bewahrt einen nicht automatisch davor.

beipflicht !!......!!!!!!!!!!!!!!!

 

[tleilax]

Nicht objektorientiert zu programmieren führt nicht automatisch zu Spaghetticode oder zum Verletzen des DRY-Prinzips und objektorient programmieren bewahrt einen nicht automatisch davor.

Aber ein Projekt neu aufzuziehen und dabei nicht auf Klassen zu setzen, zeugt nicht grade von Weitsicht. Es macht - nicht zuletzt in der Teamarbeit - schon Sinn, mit in sich gekapselten und strukturierten (weil definierten) Objekten zu arbeiten und nicht mit durch den globalen Namensraum verteilten Funktionen, die auf irgendwelche aus Programmiersprachensicht gesehen unstrukturierte Arrays ausgeführt werden.

Da müssen wir doch jetzt hoffentlich nicht grossartig drüber diskutieren oder?

 

[tobomator]

Dann sag oder erklär mir mal wie NASA damals oder andere nicht Namhafte oder hier erwähnbare Firmen, in COBOL, PASCAL oder ADA, oder anderen auch Proceduralen Sprachen x-tausende Zeilen Code in einem nicht 1 Mann Betrieb "herzustellen" vermochten ?
Auch damals funktionierte es einwandfrei, ohne objektorientierten Aufbau.

Absprachen in einem Team sollten wohl beim Entwickeln eines Produktes an erster Stelle stehen. Bekommt man das hin, sollte der Rest nicht allzuschwer fallen.

 

[theHacker]

Dann sag oder erklär mir mal wie NASA damals oder andere nicht Namhafte oder hier erwähnbare Firmen, in COBOL, PASCAL oder ADA, oder anderen auch Proceduralen Sprachen x-tausende Zeilen Code in einem nicht 1 Mann Betrieb "herzustellen" vermochten ?
Auch damals funktionierte es einwandfrei, ohne objektorientierten Aufbau.

Vermutlich genauso, wie man damals ohne Induktionskochfeld und geeigneten Töpfen, Kochlöffeln etc. was gekocht hat. Mit einem Feuerstein, n paar Stückchen Holz, dünnen Ästen zum Anfachen des Feuers und nem Primitiv-Tongefäß hat man damals schließlich auch kochen können. Funktionierte einwandfrei.

 

[ice-breaker]

Nicht objektorientiert zu programmieren führt nicht automatisch zu Spaghetticode oder zum Verletzen des DRY-Prinzips und objektorient programmieren bewahrt einen nicht automatisch davor.

nicht objektorientiert zu entwickeln führt aber meist zu Spaghetticode, denn dann wird auf die schnell einfach nochwas mittenrein geklatscht.
Natürlich ist Objektorientierung kein Garant für gute Software, aber ich kann Fehler in solch einem Modell schneller ausmerzen: Refactoring.
Nebenbei kann ich die Software auch ordentlich testen: UnitTests
Mach das mal mit prozeduralem Code

Dann sag oder erklär mir mal wie NASA damals oder andere nicht Namhafte oder hier erwähnbare Firmen, in COBOL, PASCAL oder ADA, oder anderen auch Proceduralen Sprachen x-tausende Zeilen Code in einem nicht 1 Mann Betrieb "herzustellen" vermochten ?
Auch damals funktionierte es einwandfrei, ohne objektorientierten Aufbau.

klar funktionierte es, ohne Frage, aber die Kosten für die Wartung waren um ein vielfaches höher als heute.
Warte mal 1000 Zeilen Assembler-Code und 1000 Zeilen objektorientierten Code
1. wird dein Assembler-Code schwerer zu verstehen sein
2. wirst du mit deinen 1000 Zeilen weit weniger machen können (die LoCs steigen: Wartbarkeit--)
3. schonmal so low-level programmiert? ich denke nicht, sonst würdest du nicht so tönen.

Schön, dass du auch Cobol ausführst, dann müsstest du ja wissen, dass die meisten Firmen seit Jahren sehr viel Geld reinstecken um ihre Cobol-Software auf neuere zeitgemäßere Sprachen zu portieren, da die Wartung einfach viel zu teuer ist.

 

[tleilax]

Dann sag oder erklär mir mal wie NASA damals oder andere nicht Namhafte oder hier erwähnbare Firmen, in COBOL, PASCAL oder ADA, oder anderen auch Proceduralen Sprachen x-tausende Zeilen Code in einem nicht 1 Mann Betrieb "herzustellen" vermochten ?
Auch damals funktionierte es einwandfrei, ohne objektorientierten Aufbau.

Und nun frag doch mal die Entwickler von damals, wie sie lieber entwickeln würden - nach damaligen Standards oder nach heutigen...

Sorry, aber dieses Argument ist doch nun wirklich lächerlich, denn dann müsstest Du genauso sagen, dass Lochkarten immer noch eine Daseinsberechtigung haben sollten, denn "damals hat's ja schliesslich auch funktioniert".

Wenn Du wirklich diskutieren und nicht mit halbgaren "Argumenten" nur rumtrollen willst, erläutere doch lieber mal die Vorteile, die sich bieten, wenn man nicht objekt-orientiert programmiert.

 

[chrissel]

Und nun frag doch mal die Entwickler von damals, wie sie lieber entwickeln würden - nach damaligen Standards oder nach heutigen...

(darauf antworte ich mal )

... nach heutigen.
Ich glaube nicht, dass man OOP nun bevorzugt, weil es "in" ist oder so.. Alleine dass immer neue Konzepte entstehen, neue Frameworks entwickelt werden, ältere Frameworks komplett übern Haufen geschmissen und neuen Standards angepasst werden sollte wohl genug zeigen, dass die heutige Programmierung schon weiter fortgeschritten ist im Gegensatz zu der "älteren".

 

[Banane]

und nicht mit durch den globalen Namensraum verteilten Funktionen, die auf irgendwelche aus Programmiersprachensicht gesehen unstrukturierte Arrays ausgeführt werden.

Eine Programmiersprache braucht nicht objektorientiert zu sein, um Namensräume zu haben.

Nebenbei kann ich die Software auch ordentlich testen: UnitTests

Für Softwaretests brauch ich keine Polymorphie, dafür kann sich gerade das populäre OOP-Entwufsmuster "Singleton" als für Testen recht problematisch erweisen (und wenn jetzt jemand damit kommt, dass das Singleton-Muster nicht objektorient sei: es wird auch im hochgepriesenem Standardwerk zu OOP-Mustern beschrieben).

Wenn jemand hohen Wert auf Richtigkeit legt, dann sollte er lieber auf funktionalle/deklarative Programmiersprachen setzen oder gleich alles in nachprüfbaren Grammatiken zu implementieren versuchen.

 

[tleilax]

Eine Programmiersprache braucht nicht objektorientiert zu sein, um Namensräume zu haben.

Mag sein, aber das ist absolut nicht der Punkt, auf den ich hinaus wollte...

 

[tobomator]

....
Warte mal 1000 Zeilen Assembler-Code und 1000 Zeilen objektorientierten Code
1. wird dein Assembler-Code schwerer zu verstehen sein
2. wirst du mit deinen 1000 Zeilen weit weniger machen können (die LoCs steigen: Wartbarkeit--)
3. schonmal so low-level programmiert? ich denke nicht, sonst würdest du nicht so tönen.

Schön, dass du auch Cobol ausführst, dann müsstest du ja wissen, dass die meisten Firmen seit Jahren sehr viel Geld reinstecken um ihre Cobol-Software auf neuere zeitgemäßere Sprachen zu portieren, da die Wartung einfach viel zu teuer ist.

für jemanden der seinen Code versteht, seine Programmiersprache (egal ob Assembler oder eine Hochsprache oder Interpretierte Sprache ) aus dem FF beherrscht, ist es egal, ob er spagetti Code oder OO Code hat.
Wichtig für euch "Klugscheißer" ist es doch nur zu sagen, wer OO kann, hebt sich aus der Masse ab. Masse is das, was wenn es in Bewegung ist nur schwer aufzuhalten ist, oder gar nicht. Kleines Gimmick am Rande.

Cobol oder anderer Code ist ja nicht schlimm.
Es würde gar nicht so viel Geld kosten.
Kompilierter Code is in assembler form.
Es muss nur mal einer einen Konverter von Assember in eine Hochsprache schreiben.
Quasi ein Reverse Algorithmus als das was die heutigen Übersetzungstools machen mit dem Hochsprachen Code -> Assembler.

Darin könnte man Geld investieren und jeglicher alter Code wäre ganz einfach Konvertierbar.

egal das is halt nur ein Traum, der mal irgendwann wirklichkeit wird

@Banane: Richtig, du hast es Ihnen gegeben. So sehe ich das auch. Nörgeln nörgeln nörgeln, nur nicht hilfreich sein. Spricht man eine andere Seite an, werden sie feinfühlig und motzen in jede Richtung ...

@Ice: Ich habe wärend meines Studiums in Assembler programmiet, habe schon zu C64 Zeiten mit Assembler zu tun gehabt.
Ich weiß ja nicht, was an Assembler so schlimmes ist, und auch dort, kann man recht schönen Code stricken, nutzt man heute ein Absstraktionslevel höher !


Egal, mehr Senf zu diesem Thema is von mir nur Verschwendung !

 

[Xot]

für jemanden der seinen Code versteht, seine Programmiersprache (egal ob Assembler oder eine Hochsprache oder Interpretierte Sprache ) aus dem FF beherrscht, ist es egal, ob er spagetti Code oder OO Code hat.

Du scheinst es nicht zu kapieren. Ich bin in einer grossen Firma (ca 70000 Mitarbeiter) beschäftigt und ich arbeite dort im SAP-Team.
Wir geben im Jahr einen grösseren Millionenstelligen Betrag dafür aus, um den gesammten Code zu OOP zu portieren!

Vorallem bei solch einer grossen Software ist es einfach nicht mehr tragbar, neue Programme nicht Objektorientiert zu haben.

 

[ice-breaker]

Es muss nur mal einer einen Konverter von Assember in eine Hochsprache schreiben.
Quasi ein Reverse Algorithmus als das was die heutigen Übersetzungstools machen mit dem Hochsprachen Code -> Assembler.

was meinst du wohl warum so etwas nicht existiert? oder warum es so etwas nicht für den produktiven Zweck gibt

Darin könnte man Geld investieren und jeglicher alter Code wäre ganz einfach Konvertierbar.

wunderbar, so ein Converter versteht ja auch, dass meine 100 Low-Level Assembler-Befehle eigentlich nur eine String-Suche war, gell?

@Ice: Ich habe wärend meines Studiums in Assembler programmiet, habe schon zu C64 Zeiten mit Assembler zu tun gehabt.
Ich weiß ja nicht, was an Assembler so schlimmes ist, und auch dort, kann man recht schönen Code stricken, nutzt man heute ein Absstraktionslevel höher !

weil es einfach ab einer gewissen Masse an Assembler-Code unwartbar wird, schön, dass du im Studium und Privat ein paar Assembler-Dinge gebaut hast die vielleicht einige hundert Befehle hatten, jetzt bedenke aber dass Software in einem Unternehmen, die auf Assembler laufen würde, Millionen Zeilen Assembler-Code hätte.

Wir geben im Jahr einen grösseren Millionenstelligen Betrag dafür aus, um den gesammten Code zu OOP zu portieren!

Vorallem bei solch einer grossen Software ist es einfach nicht mehr tragbar, neue Programme nicht Objektorientiert zu haben.

vergiss es, er lebt in seiner kleinen Welt ohne Blick über den Tellerrand
Das bei großer Software sich die Probleme potenzieren ist ihm unbewusst.