Browsergame mit Java(WebSocketServer) als Backend?

[VinceG]

Moin Leute,

ich bin zwar nicht komplett neu was Java angeht.. allerdings eigentlich eher in englischen Foren unterwegs. Allerdings ist das Thema für mich zu komplex um es auf Englisch zu beschreiben, deshalb habe ich mich mal hier registriert.

Es geht um folgedes: Ein Browsergame welches anhand von WebSockets mit einem Netty-Server kommuniziertum eben Befehle etc. zu validieren , zu verarbeiten und eine entsprechende Antwort an den WebSocket (Browser) zu senden.

Meine Frage ist jetzt... ob es im allgemeinen so Sinn macht wie ich das versuche umzusetzen und ob sich Java überhaupt als Backend eignet? Ich wollte zuerst alles in PHP und JS umsetzen... allerdings war das nicht das gelbe vom Ei und in Java kenne ich wenigstens ein bisschen was. Bitte beachtet nicht den 0815 Code sondern geht eher auf die Idee ein.

Hier der Link zur Github Repo https://github.com/Ganjagandalf/webserver-game-test

Hier noch der Link zu einer extrem schlechten Erklärung zu dem ganzen:

EDIT// Gerade gesehen, dass Socket sogar direkt ein Präfix war... hätte ich natürlich auswählen können :|

 

[httpdigest]

Klar, Java ist eine gute Lösung für ein Backend. Was genau ist nochmal deine Frage oder ist das nur eine Vorstellung deines Projektes? Ich guck mir doch kein 18 Minuten Video an...

 

[VinceG]

Ohh nenenene... ich möchte hier auf keinen Fall mein Projekt "vorstellen" (da es eh niemals irgendwie "veröffentlicht" wird) . Es geht eher um die Umsetzung... ob das so Sinn macht, so wie ich das umsetze/umgesetzt habe... welche Probleme das verursachen könnte und auf was ich achten muss, wenn ich das erweitere und komplexer gestalte.

Ich guck mir doch kein 18 Minuten Video an...

Nachvollziehbar, würde ich auch nur tun, wenn es mich persöhnlich interessiert. Dafür habe ich allerdings extra das GitHub-Repo angehängt und public gemacht.

 

[httpdigest]

Ich wollte dir damit nur den Hinweis geben, dass du eine relativ unkonkrete, unfokussierte bzw. weit gefasste Frage stellst ("welche Probleme könnte ich alles bekommen?") und den Leuten Code in Form eines GitHub Repos entgegenwirfst. Damit ist die Wahrscheinlich relativ gering, dass sich überhaupt jemand damit befasst.
Vielleicht kannst du ja deine Frage auf einen kleineren Ausschnitt des Codes beschränken bzw. die Frage mehr fokussieren?

Allerdings schreibst du auch "Bitte beachtet nicht den 0815 Code sondern geht eher auf die Idee ein." Welche Idee denn? Java als Backend mit WebSocket Schnittstelle zu verwenden? Ja klar, geht das. Nimm' z.B. Netty und Non-Blocking I/O und du kannst tausende Clients/Browser bedienen. Aber die Art und der Umfang an Problemen, die du eventuell bekommen kannst, hängen sehr von deiner Erfahrung mit der eingesetzten Programmiersprache (Java), den angebotenen Libraries, shared-memory basiertem Multithreading in Java und Netzwerkarchitekturen im Allgemeinen zusammen. Dieselben Probleme kannst du mit jeder anderen Sprache/Plattform bekommen.

 

[VinceG]

Ich wollte dir damit nur den Hinweis geben, dass du eine relativ unkonkrete, unfokussierte bzw. weit gefasste Frage stellst

Das war so auch meine Intention. Offene Frage = mehr Raum beim beantworten.

Klar gebe es die Möglichkeit fragen zu einem speziellen Thema direkt zu stellen. Mir geht es eher um die Erfahrung anderer Programmiere die sich mit Sockets in Kombination mit Browsergames auseinandergesetzt habe und entsprechend ein, zwei Erfahrungen teilen können/möchten. Heißt es in der Nettiquette nicht "Gib eine Sammlung deiner Erkenntnisse ans Netz weiter "?

Bitte beachtet nicht den 0815 Code sondern geht eher auf die Idee ein.

Das Stil in welchem der Spaß gecodet wurde, die vorhandenen oder nicht vorhandenen Comments sind 0815 Code. Tut mir leid, hätte ich auf jeden Fall besser beschreiben sollen. "Idee" war das falsche Wort... ich meine eher Aufbau/Konzept der aktuell vorhandenen Codebase. Das technische Konzept welches sich erahnen lässt, wenn man sich den Quellcode im GitHub-Repo anschaut oder das Video.

Folgendes. Ich merke, dass es dich stört, dass keine direkte Frage zu einem direktem Thema enthalten ist. Das ist natürlich absolut dein Recht und auch absolut nachvollziehbar. Allerdings ging der Thread - wie bereits gesagt - an Programmierer die sich mit der Materie in dem gegebenen Umfeld bereits auseinandergesetzt und ein paar Anmerkungen/Tipps zur z.B. Kommunikation zwischen Server und Client in einem Browsergame haben.

Sollte es allerdings ein Problem für dich sein, dass der Post frei beantwortet werden kann und auch entsprechend darauf abzielt, tut es mir leid.

 

[mihe7]

Deine Eingangsfrage muss man lesen als "Ist die Idee gut, JavaScript im FrontEnd und Java im Backend zu verwenden?" Die Antwort hat Dir @httpdigest bereits gegeben.

welche Probleme das verursachen könnte und auf was ich achten muss, wenn ich das erweitere und komplexer gestalte.

Du könntest Probleme mit Deiner Freundin bzgl. des notwendigen Zeitaufwands bekommen, beim Erweitern musst Du aufgrund steigender Komplexität insbesondere darauf achten, dass die nicht zu kurz kommt.

Heißt es in der Nettiquette nicht "Gib eine Sammlung deiner Erkenntnisse ans Netz weiter "?

Das heißt, dass Du die Lösung auf Deine Frage der Nachwelt hinterlassen sollst aber nicht, dass Dir jemand seine Autobiographie als Spieleentwickler in den Editor tippen soll.

Das technische Konzept welches sich erahnen lässt, wenn man sich den Quellcode im GitHub-Repo anschaut oder das Video.

Ich bin kein Spieleentwickler, daher scheide ich schon mal als Antwortgeber aus - im Gegensatz zu @httpdigest, der sich sehr gut und nicht nur damit auskennt. Grundsätzlich aber gilt, dass sich ein Ansatz nur bewerten lässt, wenn der Zweck bekannt ist.

Die Spiel-Idee wird aber nirgends erklärt. Man tippt etwas in eine Art Konsole ein, das wird an den Server geschickt und die Antwort wird auf der Seite wieder angezeigt. Kann man per WebSockets machen, muss man aber nicht und wenn man sich die Befehle ansieht, dann bräuchte man das Backend höchstens für die Registrierung und die Authentifizierung. Da steckt jetzt aber keine Wertung drin, da das Ziel unklar ist.