Single-Player Spiel in Multi-Player erweitern

J

Javalus

Grünschnabel
Hi Leute, tolles Forum habt ihr hier!

Ich habe vor einiger Zeit ein kleines Graphikadventure mit J2SE programmiert. Es geht im Groben darum in gewisser Zeit die Freundschaft von mindestens einem der 6 NPCs im Spiel zu erwerben. Je schneller man es schafft, desto mehr Punkte gibt es. Nun möchte ich gerne das Spiel erweitern, so dass meine Freunde und ich gleichzeitig per WWW im Spiel agieren und um die Gunst der Damen buhlen können.

Ich müßte meine Java Kenntnisse in Bezug auf Server - Multiple Clients erweitern. Es gibt aber so viel zu lesen, dass ich gar nicht weiß wo ich anfangen soll. Vielleicht kann mir hier jemand einen Tipp geben, was ich dazu alles lernen muss, bzw. was empfehlenswert wäre, damit ich es umsetzen kann. Ich besitze eine statische IP-Adresse und einen Linux Server und wollte einen standalone Tomcat als Webserver installieren. Hier nun meine Fragen:

  • Ist es sinnvoll die Webbrowser-Clients über den Tomcat zu empfangen oder gibt es eine bessere Möglichkeit?
  • Ich muss die Clients eindeutig identifizieren per Login/Passwort und anschliessender Session-Id. Kann das der Tomcat oder seine Alternative machen oder wie könnte ich das besser lösen?
  • Kann ich mein Programm irgendwie mit JS2E Mehrplatzfähig machen oder benötige ich J2EE dazu?
  • Muss ich dazu Enterprise Beans implementieren?
  • Kann der J2EE Application Server anstelle des Tomcats auch alleine die WWW-Anfrage der Clients entgegen nehmen oder benötige ich eine Art Tomcat als Frontend?
  • Kann der Tomcat oder seine Alternative den Application Server ersetzen, bzw. kann ich mein Programm ohne Application Server Mehrplatzfähig machen?
  • Gibt es eine bessere Lösung?

MfG Javalus

[edit:] Ups, ich sehe gerade, es gibt ein Unterforum dafür, meine Entschuldigung an den Mod, für die Mehrarbeit.
 
Zuletzt bearbeitet:
Tomcat / j2ee Verwirrung ...

Der Tomcat bedient auch im j2ee die Browser, denn der Tomcat ist die Implementierung eines j2ee Webcontainers. Also ein Subpart von j2ee.

So nun zu deiner Anwendung: So wie es aussieht, hast du bereits fertige alleinstehende Clients die du vernetzen willst. Der Tomcat wäre somit nicht wirklich das was du suchst, denn du willst ja nicht einen Browser bedienen.

Ich würde dir zu folgender Technik raten: JMS

Lies dir mal das hier durch: http://www-106.ibm.com/developerworks/webservices/library/ws-jms/

Axis ist eine Implementierung von Soap. Soap selbst ist ein Protokoll zur Informationsübertragung. JMS wiederum benutzt unter anderem Soap um die Nachrichten zu übertragen.

Vorteil des Systems: JMS kann z.b. auch Emailverbindungen verwenden. Somit wäre z.b. auch ein Spiel denkbar, das nur alle paar Tage eine Synchronisation der Clients über eine Mailbox durchführt.

hth
cybi
 
Hi Cybi,

ich habe mir deinen Vorschlag heute auf deren Webseite angeschaut und mir einige Erklärungen durchgelesen. Ich möchte aber schon statt meiner fertigen Single-Player GUI einen normalen Webbrowser zur Darstellung im Internet benutzen. Viele User haben eine gewisse Hemmschwelle um sich solch ein Java Programm auf dem Rechner zu installieren, bzw. spielen von der Arbeit aus und dürfen es dort nicht. Ich möchte langfristig mein Spiel vielen Menschen per Webbrowser anbieten, insofern werde ich um einen Webserver nicht herumkommen.

Ich habe heute früh den Tomcat gesaugt und installiert und im Laufe des Tages ein paar Servlets geschrieben, die ich mit http://localhost/servlet/BildAnzeigen oder .../TrainierenGehen usw. dann auf dem Webbrowser darstelle, ähnlich wie in meiner GUI.

Soweit so gut, aber ich komme mir mittlerweile wie ein PHP Skripter vor. Mit zig Servlets die vom Tomcat immer aufgerufen werden, wenn jemand einen bestimmten Link in seinem Browser anclickt , hätte ich das Spiel auch in PHP schreiben können. Ausserdem sehe ich Probleme mit den Servlets, wenn jemand Daten in der Datenbank verändert, ein anderer User aber gerade Daten ausliest und auch verändern will, diese Skripte sich aber vielleicht in Warteschleifen befinden (simuliertes Multitasking bei Single CPU Computern). Da sind Bugs vorprogrammiert.

Was muss ich denn lernen, damit ich statt zig Servlet Skripts ein einziges Programm habe, dass sich um alles kümmert und auch Datenbankzugriffe koordiniert, damit kein Chaos entsteht? Wenn ich alle kritischen Zugriffe mit synchronisierten Methoden mache und je User einen neuen Thread aufrufe, dann habe ich doch einen wahnsinnigen Overhead (ich glaube es waren 400kb Speicherplatzbedarf je Thread nur zur Eröffnung). Gibt es da keine sinnvolle Lösung und ein einfaches und sicheres Server - Multiple Clients Verhältnis aufzubauen? Mir fehlt sozusagen ein Tipp, wie ich mehrere Useranfragen gleichzeitig auf meinem Server parallel und sicher bearbeiten kann.

MfG Javalus
 
Ich rate zu myfaces.org
Eine Implementierung der JSF Spefizikation.

Bei JSF handelt es sich um ein Framework zur Erstellung von WebGuis. Es trennt den View von den Daten und bringt zudem einen Controller mit, der all diese Tätigkeiten koordiniert (Grob gesagt die Umsetzung des MVC Patterns für webbasierte Applikationen.)

Ich empfehle dir deshalb http://horstmann.com/corejsf/
Die dortigen PDFs decken zwar nicht das ganze Buch ab und sind zudem nicht die Endversion vom Buch, sollten dir aber dennoch den Einstieg erleichtern.

Lad dir von Myfaces die Beispielwebapp runter. Nimm sie als Einstiegspunkt.

Zum Thema Daten => Jpox.org
Allerdings kann ich dir keine freie JDO Ressource nennen ;o) Selber googlen.

Für multiple User mußt du im speziellen den Part "Transaktionen" beachten.

hth
cybi
 
Ich habe mir heute Nacht bis kurz nach 5 Uhr JSF auf der von dir empfohlenen Seite angeschaut und die verfügbaren Online Kapitel des Buches durchgelesen.
Ich hoffe alles richtig verstanden zu haben und fasse es kurz in einem Satz zusammen. JSF ist eine alternative, einfacher umzusetzende Dartsellungsmethode für die Client-Seite einer Applikation, sie könnte aber auch mit JSP und Servlets realisiert werden. Das ist sicher später für mich interessant. Im Augenblick muss ich vieles andere neu erlernen und werde mich, was die Client-Ausgabe betrifft, auf den mir gut bekannten Servlet/JSP/HTML Code verlassen.

JDO gefällt mir, vor allem nachdem ich deinen Beitrag hier im Forum im Topic "Welche Persistenz für große Datenmengen" gelesen habe. Bei Jpox habe ich Bedenken wegen der Zuverlässigkeit. Das Projekt scheint gerade erst der Beta Phase entschlüpft zu sein, jedenfalls existiert es noch nicht lange. Da du es mir aber empfohlen hast, werde ich es zusammen mit JDO einsetzen.

Mir fehlt nun noch dringend eine Idee, wie ich mehrere parallele Client-Anfragen serverseitig sicher verarbeiten kann. Ich müsste bei einer Anfrage den Eingangsport schnell wieder freigeben, damit andere User ihn auch benutzen können, das ginge z.B. per Threads, aber ist es optimal? Wie kann ich Transaction am besten implementieren, ohne das es zu Locks kommt?

Vielleicht kann mir ein alter Hase noch ein paar allgemeine Tipps zur serverseitigen Grundstruktur eines Multiclient-Server Programms geben?
Welche Bausteine eignen sich gut dafür usw.

Danke und viele Grüße, Javalus
 
Du hast noch ein paar Denkfehler.

Zum Thema parallele Verarbeitung: Du müsstest zusatzaufwand betreiben um den von Haus aus parallel arbeitenden Webcontainer zur reinen seriellen Verarbeitung zu zwingen ;o) Ist von haus aus bereits Parallel. Der Tomcat hat per Default glaub ich 10 Worker Threads am laufen. (Zahl sowieso irrelevant, da du sie in der server.xml justieren kannst)

Die richtige Frage die du dir stellen solltest wäre folgende: Wie schaffe ich es das die gleichzeitige Bearbeitung keinen Datensalat erzeugt. Hierfür solltest du dir das Kapitel Threads in einem Buch deiner Wahl durchlesen ;o) Besonderer Augenmerk auf "Synchronisierung".

Wenn du dein Servlet syncronisierst wirst du feststellen das du die parallele Abarbeitung auf seriell reduziert hast. Hierfür mußt du eigentlich nur ein Schlüsselwort im Servlet hinzufügen ;P Das macht man aber im Regelfall nicht, denn effizient ist es die wirklichen problemzonen zu synchronisieren. Also bestimmte Methoden / Container.

JSF: Hier unterliegst du auch einem Irrglauben. JSF ist eine höherwertigere Funktionalität die Ihrerseits JSP verwendet um diese anbieten zu können.

Normalerweise hast du merhere JSPs die irgendwie interagieren. JSF validiert dir die Formulare der JSPs, kümmert sich um die Verknüpfung dieser Ressourcen (Navigation) etc.

Und nein, keiner wird freiwillig nur JSP verwenden. Wenn schon JSP dann ein Framework wie Struts, denn den reinen JSPs mangelt es am intelligenten Controller. JSF ist in etwa das selbe wie Struts, allerdings mittlerweile Standard, da es den JCP durchlaufen hat.

Deine Vorstellungen bezüglich JSP / JSF sind also falsch. Richtiger wäre: JSP + ettliches an Arbeit = JSF

cybi
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück