Programiersprache für Browsergame

Sry aber ich sag nur SAP.

Siemens war damals eben so "blind".
Sie haben zu viel aufgesetzt.
Ohne weitsicht.
Klar verursacht das Konvertieren von Software nicht nur Geld und Zeit, sondern auch findige Programmierer.
Man hätte Damals schon teile Parallel entwickeln können, aber das nur am Rande.
So es aber überall.

NASA, SAP, CIA, egal...
Alle haben damit probleme.
Wer aba das meiste Geld hat, der bekommts am schnellsten hin !
 
Tut das not das hier über irgendwelche völlig banalen Quark diskutiert wird?

Ihr ruiniert mir meinen schönen Fred :D


Und wenn dann bitte etwas sachlicher...
aber verschiebt das lieber in die Kneipen-Laber-Ecke des Forums oder so ;)

Danke sehr
 
Langsam koennte einer der Mods die Diskussion echt mal aus dem Thread auskoppeln und einen "Programmiersprachen Flamewar" Thread machen, dann wissen alle wo das hingehoert ^^
 
Um auch nochmal ein wenig Senf in den Raum zu streuen:

Es ist auch nicht zwingend notwendig sich auf eine Programmiersprache festzulegen. Funktioniert Modul A mit PHP gut - schreib's in PHP. Funktioniert Modul B mit ASP besser - schreib's in ASP.
Andere Module, Cronjobs o.ä. können z.B. auch in Perl abgearbeitet werden, oder in Powershell um mal ganz exotisch zu werden :)

Wichtig ist auch zum einen das man weiß was eine Sprache kann, und zum anderen das du damit umgehen kannst. Ich persönlich finde es besser 1000 Zeilen lesbaren PHP Code zu schreiben, als 500 Zeilen hochperformanten Perl Code, bei dem man, nach 2-3 Wochen Abstand von dem Script, erstmal mit nem großen Fragezeichen im Gesicht davor steht.
(Was nicht heißen soll das Performance egal ist, und PHP und Perl sollten jetzt auch nur Beispiele sein *G*)
 
Ein verhältnismäßiges kleines Projekt wie das hier angedachte in zig verschiedenen Sprachen aufzuziehen macht aber irgendwann auch kein Spaß mehr (und unnötig kompliziert wirds auch irgendwann ;)). Das nicht alles in nur einer gelöst werden muss sollte (hoffentlich) klar sein, wann es sich lohnt ist die andere Frage.

PS: danke für die Erheiterung durch deine Posts tobomator :mrgreen:
 
Oh, grad noch eingefallen: eine Programmiersprache muss nicht wirklich sein, du musst nur gute Schnittstellen haben. Bei vielen Projekten muss ich sagen hat sich eine Kombination aus PHP frontend (user interface), mit PHP-JMS [1], ActiveMQ [2] und einem Worker in einem J2EE Container [3] als unglaublich flexibel erwiesen. Das Frontend is relativ schnell geschrieben, und der Worker is sehr flexibel was das abarbeiten der Bau Warteschlange, der Truppen Bewegungs queues, und sonstiges. JMS und ActiveMQ sind dazu da damit frontend und queues nicht auf ein und dieselbe DB einhaemmern, aber trotzdem miteinander Kommunizieren koennen. Somit kannst du mit Lucene [4] sogar einen business grade indexer bauen mit dem du ueber alles suchen kannst :D

Oh und JMS eignet sich wunderbar um ein Admin Interface zu bauen und alles bequem zu monitoren :D

Just a little brainstorming ^^

Sonst wer Ideen wie man ein flexibles, ausbaufaehiges System zusammenschustern kann?

[1] https://onjava.com/pub/a/onjava/2004/10/27/php-jms.html
[2] https://activemq.apache.org/
[3] https://static.springsource.org/spring-batch/
[4] https://lucene.apache.org/java/docs/
 
Jup, die Java-Warteschlangen durch Gearman ersetzen [1] :biggrin:
Und Lucene raus, ich wüsste nicht wofür wir Volltextindizierung brauchen.

Möglicherweise auch relationale Datenbanken raus und durch einen Key-Value-Store wie Apache Cassandra in einem durable-Mode ersetzen.

Alle Aktionen werden vom Frontend auch nicht mehr direkt durchgeführt sondern mit einem REST-Webservice.

Nebenbei sind Truppenbewegungen, Bauaufträge usw doch eh nur Zeitstempel in der Datenbank, die irgendwann in ferner Zukunft ausgeführt werden und im Nachhinein Änderungen dieser Aktion durchgeführt werden.
Also ich bin 4 Stunden offline, vor 3 Stunden ist aber meine neue Goldmine fertig geworden, wenn ich nun wieder online gehe sieht das System, dass mein letzter Zugriff vor 4 Stunden war, also berechnet es mir eine Stunde normal Ressourcen und 3 Stunden Ressourcen mit der neuen Goldmine.

[1] die Java-Warteschlangen sind sicherlich keine schlechte Sache, aber die Anbindungen an die PHP-Welt sind nicht sehr prickelnd, auch sind es wirklich mehr Warteschlangen wobei Gearman eben ein asynchroner JobQueue-Server ist.
 
ice-breaker schrieb:
Jup, die Java-Warteschlangen durch Gearman ersetzen [1] :biggrin:
Und Lucene raus, ich wüsste nicht wofür wir Volltextindizierung brauchen.
Zum Vergrößern anklicken....
Joa, momentan verwenden wir Lucene zur indizierung von Daten Annotationen von Biologischen Samplen, da is Volltextsuche eben unabdingbar.
Aber auch sonst kann ich mir einige Szenarien vorstellen wo Volltext schoen is.

ice-breaker schrieb:
Möglicherweise auch relationale Datenbanken raus und durch einen Key-Value-Store wie Apache Cassandra in einem durable-Mode ersetzen.
Zum Vergrößern anklicken....
Cassandra is schoen, das kann anscheinend auch Hadoop Jobs verarbeiten (wenn da jemand infos zu Cassandra + Pig Latin + Hadoop Jobs kennt bitte melden ^^).

ice-breaker schrieb:
Alle Aktionen werden vom Frontend auch nicht mehr direkt durchgeführt sondern mit einem REST-Webservice.
Zum Vergrößern anklicken....
Sauber ja, auch wenn ich vor dem Overhead etwas skeptisch bin. Kannst du mich da eines besseren beleeren?

ice-breaker schrieb:
Nebenbei sind Truppenbewegungen, Bauaufträge usw doch eh nur Zeitstempel in der Datenbank, die irgendwann in ferner Zukunft ausgeführt werden und im Nachhinein Änderungen dieser Aktion durchgeführt werden.
Also ich bin 4 Stunden offline, vor 3 Stunden ist aber meine neue Goldmine fertig geworden, wenn ich nun wieder online gehe sieht das System, dass mein letzter Zugriff vor 4 Stunden war, also berechnet es mir eine Stunde normal Ressourcen und 3 Stunden Ressourcen mit der neuen Goldmine.
Zum Vergrößern anklicken....
Naja leider nicht immer, solange es nur bauauftraege sind is das kein Problem aber stell dir Truppenbewegungen vor, und zwei Truppen kaempfen gegeneinander wenn sie auf sich treffen. Solange events endgueltig von Anfang an entschieden sind is alles klar, aber wenn man truppen unterwegs abwenden kann, oder darauf was passiert is eine event queue eben doch besser :D

ice-breaker schrieb:
[1] die Java-Warteschlangen sind sicherlich keine schlechte Sache, aber die Anbindungen an die PHP-Welt sind nicht sehr prickelnd, auch sind es wirklich mehr Warteschlangen wobei Gearman eben ein asynchroner JobQueue-Server ist.
Zum Vergrößern anklicken....
Immer schoen zu fachsimpeln, da lernt man eben auch solche sachen kennen. Ich komm eben von der Enterprise Java Welt, und deshalb meine Vorliebe fuer JMS :mrgreen:
 
Snyke schrieb:
Cassandra is schoen, das kann anscheinend auch Hadoop Jobs verarbeiten (wenn da jemand infos zu Cassandra + Pig Latin + Hadoop Jobs kennt bitte melden ^^).
Zum Vergrößern anklicken....
ich habe mich die letzten Tage mal mit Redis beschäftigt, würde das momentan den Entwicklern statt einer Datenbank vorschlagen, immerhin hat ein Browsergame kaum Daten, die miteinander verknüpft werden müssen, und die Datenstrukturen machen Redis meiner Meinung nach deutlich nützlicher als normale Key-Value-Stores.
Wenn es nicht ganz so low-level sein soll, würde sich sicherlich auch noch MongoDB anbieten, das ist mit dem Konzept näher an Datenbanken (Indexe).

Snyke schrieb:
Sauber ja, auch wenn ich vor dem Overhead etwas skeptisch bin. Kannst du mich da eines besseren beleeren?
Zum Vergrößern anklicken....
was ist schon ein Web-Request ;)

Snyke schrieb:
Naja leider nicht immer, solange es nur bauauftraege sind is das kein Problem aber stell dir Truppenbewegungen vor, und zwei Truppen kaempfen gegeneinander wenn sie auf sich treffen. Solange events endgueltig von Anfang an entschieden sind is alles klar, aber wenn man truppen unterwegs abwenden kann, oder darauf was passiert is eine event queue eben doch besser :D
Zum Vergrößern anklicken....
da nur 2 Truppen miteinander kämpfen wenn bereits eine Truppe unterwegs ist und die 2. losgeschickt wird, ist hier doch auch wieder bekannt, wann sie aufeinander treffen, also kann ich den Kampf auch erst durchführen, wenn es nötig ist. Wenn ich natürlich Realtime-Benachrichtigungen machen möchte, ist es sicherlich nicht schlicht einen zeitgesteuerten Auftrag in eine Wartschlange zu legen, der direkt bei Aufeinandertreffen der Truppen ausgeführt (mit einem Job-Scheduler, z.B. Quartz aus der Java-Welt, gibt aber bestimmt noch mehr Software)


Snyke schrieb:
Immer schoen zu fachsimpeln, da lernt man eben auch solche sachen kennen. Ich komm eben von der Enterprise Java Welt, und deshalb meine Vorliebe fuer JMS :mrgreen:
Zum Vergrößern anklicken....
Jup :)
Btw: JPPf ist auch imho oft eine bessere Lösung als MessageQueues (wenn Tasks einfach schnell asynchron ausgeführt werden müssen).
 
ice-breaker schrieb:
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ß.
Zum Vergrößern anklicken....

Da bin ich dezent anderer Meinung. Denn 100%ig OOP ist auch nicht immer sinnvoll. In vielen Fällen reichen auch simple Funktionen ;D. Wenn ich also an fünf Stellen X Berechnen möchte, schreib ich mir dafür eine Funktion anstatt da jetzt eine Klasse aufzusetzen. Und Frameworks, naja ist auch Geschmackssache. Ich persönlich hab mich in Symfony eingearbeitet und hab recht schnell den Überblick verloren. Und hatte am Ende mehr Probleme und Fragen als Lösungen. Hat sich für mich nicht rentiert.
Ich schreibe mir lieber meine eigenen Funktionsbibliotheken und Klassen und hab am Ende (IMO) schöneren Code.
 
FeelGoodInc. schrieb:
Ein verhältnismäßiges kleines Projekt wie das hier angedachte in zig verschiedenen Sprachen aufzuziehen macht aber irgendwann auch kein Spaß mehr (und unnötig kompliziert wirds auch irgendwann ;)). Das nicht alles in nur einer gelöst werden muss sollte (hoffentlich) klar sein, wann es sich lohnt ist die andere Frage.

PS: danke für die Erheiterung durch deine Posts tobomator :mrgreen:
Zum Vergrößern anklicken....

Jederzeit immer wieder gern.
Ich mag es auch mal etwas erheiterndes zum Thema beizutragen
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben