nicht angemeldet
Softwareprojekt
Hallo,
wir sind ne 7 köpfige Gruppe von Informatik-Studenten, 5tes Semester. Wir haben 7 Wochen Zeit um ein Spiel zu programmieren. Ein Teil muss auf nem Windows 2003 Server laufen (der Spieleserver) und ein Teil auf dem Client (das Spiel). Es soll möglich sein, später weitere Spiele hinzu zu programmieren. Es soll den Modus "Mensch gegen Mensch" und "Mensch gegen Computer" geben. Soweit zur Aufgabe. Nun zur Umsetzung. Beispiel: Kartenspiel
-
Datenbank, speichert aktuelle Spielstände, Benutzerdaten...
-
Spiele-Server (läuft auf Windows 2003 Server), greift als einzige Anwendung auf die Datenbank zu, nimmt Anfragen von Clients entgegen beispielsweise "geb mir die nächste Karte", bestimmt die Anwort aus der Datenbank und antwortet dem Client
-
Spiel 1, kommuniziert mit dem Spiele-Server.
-
KI 1, simuliert einen Menschen. Die KI wird nur dann ausgeführt, falls ein Mensch gegen den Computer spielen möchte. Für jedes Spiel das wir programmieren, müssen wir einen separate KI programmieren. Die KI wird auf dem Server ausgeführt. Sie enthält Methoden wie z. B. MakeNextMove()
So, weit so gut. Beispiel: es spielen zwei Spieler gegen einander. Die Clients zeigen nur die Karten da, stellen anfragen wie "getNextCard()" an den Server und erhalten antworten. Ob das Spiel vorbei ist, spirch ob jemand gewonnen oder verloren hat entscheidet der Server. Das Ergebnis wird am Client ausgegeben.
Das ist mal unser Grob-Konzept. Nun bitte ich um Meinungen!
LG Nick
-
Hallo,
Hallo auch.
wir sind ne 7 köpfige Gruppe von Informatik-Studenten, 5tes Semester.
aha
Wir haben 7 Wochen Zeit um ein Spiel zu programmieren.
7 Wochen, 7 Köpfe ... jede Woche muss dann ein Kopf rollen?
- Datenbank, speichert aktuelle Spielstände,
Wozu und was ist ein aktueller Spielstand?
Benutzerdaten...
Wozu und was für Benutzerdaten?
"geb mir die nächste Karte", bestimmt die Anwort aus der Datenbank
Das macht wenig bis überhaupt keinen Sinn. Wozu brauch es eine Datenbank um per Zufall das erste Element aus einem nach Zufall sortierten Array zu wählen? Die Karten sollen nicht immer in der selben Reihenfolge ausgegeben werden.
- Spiel 1, kommuniziert mit dem Spiele-Server.
Spieler 1 vielleicht?
- KI 1, simuliert einen Menschen. Die KI wird nur dann ausgeführt, falls ein Mensch gegen den Computer spielen möchte.
Definiere KI! (Such mal hier im Archiv nach "Skat")
Für jedes Spiel das wir programmieren, müssen wir einen separate KI programmieren.
Denn Skat folgt ja nicht den Mau-Mau Regeln, macht Sinn.
Die KI wird auf dem Server ausgeführt. Sie enthält Methoden wie z. B. MakeNextMove()
Ähem, okay. Der Server erwartet dann also (synchroner Aufruf) eine Antwort vom Client? Das riecht nach mäßiger Skalierbarkeit und bidirektionaler Kommunikation in RPC Manier (Remote Procedure Call).
So, weit so gut. Beispiel: es spielen zwei Spieler gegen einander. Die Clients zeigen nur die Karten da, stellen anfragen wie "getNextCard()" an den Server
Können alle das zur selben Zeit machen, oder müssen _wir_ da eine Reihenfolge einhalten? Wie weiss der Spieler, wenn er (womit auch immer) getNextCard() aufrufen kann?
Ob das Spiel vorbei ist, spirch ob jemand gewonnen oder verloren hat entscheidet der Server.
Wieviele Server pro Spiel bzw. wieviele Spiele pro Server sollen denn laufen und wie wollt ihr die auseinanderhalten?
Das Ergebnis wird am Client ausgegeben.
Sonst hat der ja nicht viel von der ganzen Geschichte, oder?
Das ist mal unser Grob-Konzept.
Von der Körnigkeit eines Planeten. :)
Nun bitte ich um Meinungen!
Bezüglichen welchen Aspekten? Oder wolltest du fragen: "Wie mach ich das jetzt? Hat jemand Beispielscripte?" Oder: "Ist PHP und MySQL besser als .Net für dieses Projekt?"
Ein recht gutes Stichwort für KI für dich lautet Finite State Machine. Ein weiteres "ereignisbasierte Programmierung" (in E: event-driven programming).
Und bitte fangt nicht grad mit "Skat" an, sondern mit was einfachem wie Texas Hold'em. Vielleicht wäre auch Würfeln gut, da kann man ja fast alles dem Zufallsgenerator überlassen und brauch schauen Spieler 1 > Spieler 2 und so.
-
Hallo,
- Datenbank, speichert aktuelle Spielstände, Benutzerdaten?
Nun, um beispielsweise Punkterekorde zu speichern, Spielernamen... möchten wir das sich Benutzer registrieren. EInmal registriert, können die Benutzer alle Spiele spielen. Benutzerdaten sind die typischen daten wie Namen, Vorname, Email... schon hier wäre eine DB recht sinnvoll.
Spielstände: es gibt z. B. 52 karten, es muss gespeichert werden, welcher Spieler die Teilmenge 1 hat, welcher Spieler die Teilmenge 2 hat und welche übrig geblieben sind.
"geb mir die nächste Karte", bestimmt die Anwort aus der Datenbank
Das macht wenig bis überhaupt keinen Sinn. Wozu brauch es eine Datenbank um per Zufall das erste Element aus einem nach Zufall sortierten Array zu wählen?Wenn vom Client eine bestimmte Anfrage kommt. z. B. GetNextCard und zusätzlich der Benutzername angegeben ist, so kann eine Karte bequem aus der Datenbank mit nur einer einzigen Zeile Select... where user... bestimmt werden. Der Zufall lässt sich da mit einbauen.
Würden wir ein Array verwenden, hätten wir da wesentlich mehr aufwand.Definiere KI! (Such mal hier im Archiv nach "Skat")
Zunächst tuts auch ne KI die einfach mal zufällig zieht. Diese Funktionalität lässt sich später noch erweitern.
Die KI wird auf dem Server ausgeführt. Sie enthält Methoden wie z. B. MakeNextMove()
1. Möglichkeit, Mensch gegen Computer
Das Spiel des Menschen läuft auf seinem Client. Der Spiele-Server startet die KI auf dem Server selbst, dies könnte einfach eine Klasse sein die eben bestimmte Methoden anbietet wie MakeNextMove().LG Nick
-
Hallo zur Nacht nochmals,
die Frage nach den Benutzerdaten war mehr oder weniger eine Fangfrage um zu sehen, ob du weisst warum du was willst. Von Registrierung für die Spiele war im Ausgangsbeitrag ja keine Rede.
Spielstände: es gibt z. B. 52 karten, es muss gespeichert werden, welcher Spieler die Teilmenge 1 hat, welcher Spieler die Teilmenge 2 hat und welche übrig geblieben sind.
Muss es? Stell dir vor, du hast 10.000 gleichzeitige Spieler und jedesmal, wenn eine Karte gegeben/gezogen wurde, musst du ein Update/Insert/Delete auf die Datenbank machen? Hast du dir überlegt, wie lang solch ein Spiel max. laufen soll? Soll man es unterbrechen können müssen? Du bringst mit der Datenbank eine Ressource ins Spiel, die es für eine KI nicht braucht und auch nicht unbedingt für einen Controller/KI. Für Statistiken über die Spiele - keine Einwände, aber für die Abwicklung des Spiels ... tssss??!!
bequem aus der Datenbank mit nur einer einzigen Zeile Select... where user... bestimmt werden
Wow ... mit nur einer einzigen Zeile!?? Dein Prof sollte dir dafür ne Auszeichnung verleihen. Aber ehrlich, mehr als ein Select wäre auch sinnlos.
Würden wir ein Array verwenden, hätten wir da wesentlich mehr aufwand.
"Würden" und "hätten" klingt aber nicht nach "wirklich ausprobiert"! Habt ihr überhaupt schon mal was ausprobiert?
Also was bietet euch eine Datenbank _wirklich_ für Vorteile dabei?
Synchrone Methodenaufrufe sind nicht gerade ideal für solche Szenarien, da der ausführende Thread, ob Client oder Server jeweils auf die Rückkehr des Messiahs äh des Aufrufs wartet. Damit könnt ihr keinen Multiuser-Betrieb sinnvoll (wenn überhaupt) gewährleisten. Deswegen erwähnte ich auch Eventing. Dazwischen kehren alle Teilnehmer immer in einen bekannten (==definierten) Ruhezustand/Idle State zurück.
Ansonsten stimme ich restlos dem Sven zu. :)
Ciao und gutnacht
Frank
-
Hi Nick!
Was mir gar nicht klar ist, ist wie ihr vorgehen wollt; wollt ihr mit Java oder .Net(C#) arbeiten (Stichwort Verteilte Systeme), oder klassisch Cient-Server Architektur verwenden.
Gibt es Anforderungen bezüglich des Clients, namentlich:
-
Soll es im Browser laufen - wenn ja, in welche(m/n)? Ist Javascript erlaubt? C# und .Net + IE: dürft ihr die Security Policy auf dem Client anpassen?
-
Soll es plattformunabhängig laufen (Linux/Windows/Mac)?
-
Soll es den Download eines Client Applets bedingen? Oder soll gar eine eigene Clientapplikation erstellt werden?
Gibt es Anforderungen bezüglich des Servers (außer OS=WIN2003)?
-
Soll eine eigene Serverapplikation erstellt werden (Java oder .Net)?
-
Dürft ihr anstelle des IIS auch den Apachen verwenden?
-
Welche serverseitigen Technologien stehen zur Verfügung (PHP, Perl, Ruby, Python)?
Welche Kompetenzen gibt es bei euch - wer kann was?
Nur so als Tip: ein nicht unwesentlicher Teil der Arbeit besteht darin, den Server so aufzusetzen, dass alles so funktioniert, wie man will, wenn man dies noch nie gemacht hat...
Mein Tip wäre, die Applikation in folgendem Umfeld zu gestalten:
Server: Apache + CGI - Scriptsprache eurer Wahl (CGI, PHP, Perl, Ruby, Python)Client: Initialfestlegung auf _einen_ plattformübergreifenden Browser in aktueller Form (z.B. Firefox 2.x); wenn mehr Zeit ist, könnt ihr gerne für den IE alles nochmal coden...; Javascript sollte als aktiviert vorausgesetzt werden. Über alternative Techniken (zu reinem HTML) wie XML könnt ihr nach Kompetenz entscheiden.
Teamverteilung würde ich vorschlagen:
1 Projektleiter/Koordinator/Buildguard
4 Serverteam, interne Aufteilung:
Team A: Start: 2 Server/Systemsetup und Konfiguration, Später: 2 Tester für Team B
Team B: Start: 2 Systementwurf (zusammen mit Team A), Später: 2 CGI/Datenbank-Zugriffs Entwickler
2 Clientteam, Aufgaben
Team C: Start: 2 Systementwurf (zusammen mit Team B), Später: 2 Clientapplikationsentwickler mit gegenseitiger Testfunktion.Ich wünsche euch auf jeden Fall viel Spaß - und denkt bitte dran, auch für die Dokumentation Zeit einzuplanen. Diese ist von den Teams und nicht durch den Leiter anzufertigen, der hat sowieso genug zu tun...
Viele Grüsse,
Richard-
Hallo!
sorry, heut war schon ein langer tag, hab die hälfte vergessen aufzuschreiben. Du hast natürlich Recht.
Was mir gar nicht klar ist, ist wie ihr vorgehen wollt; wollt ihr mit Java oder .Net(C#) arbeiten (Stichwort Verteilte Systeme), oder klassisch Cient-Server Architektur verwenden.
Wir werden Java verwenden (zusammen mit Eclipse). Außerdem möchten wir keine Webanwendung schreiben, sprich kein php, asp, asp.2.0, keine browser... Es wird eine eigene, eigenständige Anwendung die nur auf Windows läuft. Ansonsten bekommen wir nen eigenen Server, mit dem wir alles anstellen dürfen was wir mögen.
- Soll eine eigene Serverapplikation erstellt werden (Java oder .Net)?
Ja, Java.
- Welche serverseitigen Technologien stehen zur Verfügung (PHP, Perl, Ruby, Python)
Da wir ja java verwenden, benötigten wir ja weder php, noch perl...
Welche Kompetenzen gibt es bei euch - wer kann was?
Also ich hab ne Ausbildung als Fachinformatiker Anwendugnsentwicklung und hab schonr recht viel mit C# programmiert, und kenn micht mit Datenbanken gut aus. Der Rest kennt die Inhalte ausm Studium, C++ (Progammieren 1, 2 und 3), Datenbanken 1. Ein anderer hat ne Ausbildung als Systemintegrator und kennt sich von daher mit Servern prima aus.
Mein Tip wäre, die Applikation in folgendem Umfeld zu gestalten:
Server: Apache + CGI - Scriptsprache eurer Wahl (CGI, PHP, Perl, Ruby, Python)Okay, wir müssen halt Java verwenden. Wie oben schon gesagt, es wird keine Webanwendung. Frank hat gemeint wir sollen gar keine Datenbank verwenden. Aber ich seh das anderst. Nehmen wir folgendes Beispiel. Es haben sich am Server 7, 8 Spieler angemeldet und spielen. Wird nun eine bestimmte Karte an einen Spieler ausgegeben, genügt ein simples Update... (einzeiler) um die Änderung zu registrieren. Auch Abfragen bezüglich des Benutzers könen/müssen in das Update hinein.
Würde man ein Array verwenden, hätte man nicht nur einen höheren Aufwand O(n) - okay bei der Größe wäre der auch so minimal. Aber da irgendwo anzufangen strings oder ids zu vergleichen, ich weiß nicht. Ich halte das nicht für wirklich sinnvoll. Ich glaube eine Datenbank für den Code außerdem übersichtlier bzw. einfacher gestalten.
LG
-
Moin!
Okay, wir müssen halt Java verwenden. Wie oben schon gesagt, es wird keine Webanwendung. Frank hat gemeint wir sollen gar keine Datenbank verwenden.
Sehe ich ähnlich. Datenbank nur für permanente Datenspeicherung. Oder wenn wirklich große Datenmengen zu speichern sind. Aber dann kriegt ihr das Projekt nicht in 7 Wochen durchgezogen, weil große Datenmengen in der Regel nur bei komplexen Spielen anfallen werden.
Aber ich seh das anderst. Nehmen wir folgendes Beispiel. Es haben sich am Server 7, 8 Spieler angemeldet und spielen. Wird nun eine bestimmte Karte an einen Spieler ausgegeben, genügt ein simples Update... (einzeiler) um die Änderung zu registrieren. Auch Abfragen bezüglich des Benutzers könen/müssen in das Update hinein.
Du sagst, du schreibst keine Webanwendung (also etwas, das über HTTP mit einem Browser kommuniziert), aber du denkst die zu erzielende Lösung so.
Mal allgemein gesprochen: Der Java-Client verbindet sich mit dem Spielserver. Da landet er erstmal in einer zentralen "Lobby", in der der Benutzer sich anmeldet (oder zumindest einen Benutzernamen liefert) und aktive Spiele angezeigt kriegt.
Wenn sich mehrere Spieler zum Start eines Kartenspiels (als Beispiel) melden, dann gibts einen abgespaltenen Prozess, der sich um die Abwicklung des Spiels kümmert. Welcher Spieler welche Karte hat, speichert der Server dabei logischerweise am besten im RAM - bei Java also in einer geeigneten Datenstruktur auf dem Heap. Bei schätzungsweise 52 oder vielleicht 104 Spielkarten pro Spiel dürfte sich der Speicheraufwand deutlich im unmerklichen Bereich bewegen. Dafür aber eine Datenbankanbindung zu stricken wird vermutlich viel aufwendiger.
Ich würde auch die permanente Datenspeicherung nicht zwingend in einer Datenbank machen, sondern irgendetwas verwenden, was Java u.U. schon von sich aus mitbringt. Gibts da nicht irgendwas, mit dem man Objekte serialisiert in Dateien schreiben kann (Hibernate, oder wie das heißt)? Dann mußt du dich primär nur um Java kümmern, und nicht noch um die Findung einer geeigneten Datenbankstruktur, sowie der Konvertierung der Daten hin und zurück.
Würde man ein Array verwenden, hätte man nicht nur einen höheren Aufwand O(n) - okay bei der Größe wäre der auch so minimal. Aber da irgendwo anzufangen strings oder ids zu vergleichen, ich weiß nicht. Ich halte das nicht für wirklich sinnvoll. Ich glaube eine Datenbank für den Code außerdem übersichtlier bzw. einfacher gestalten.
Ich glaube an das Gegenteil, abgesehen davon, dass das O des O(n) bei Speicherung im RAM deutlich kleiner ist, als das eventuelle O im O(log n) des indizierten Datenbankzugriffs (was übrigens nur fürs Lesen gilt, beim Schreiben hast du natürlich die üblichen Dinge wie Locking, Index-Updating etc, die ebenfalls Zeit fressen - vom notwendigen Parsing des SQL-Statements und der Kommunikation mit der Datenbank über ein (Unix- oder TCP/IP-)Socket mal ganz abgesehen.
Da reißt die Datenbankmethode vielleicht erst bei extrem hoher paralleler Nutzung was raus - die aber für diese Übungsaufgabe vollkommen irrelevant ist. Du optimierst gedanklich schon eine Lösung, die noch gar nicht existiert, und die auch noch gar kein Performanceproblem hatte. In den 7 Wochen Projektlaufzeit habt ihr für solche Dinge wirklich keine Zeit.
- Sven Rautenberg
--
"Love your nation - respect the others." -
Hallo Nick,
Okay, wir müssen halt Java verwenden. Wie oben schon gesagt, es wird keine Webanwendung. Frank hat gemeint wir sollen gar keine Datenbank verwenden.
Das ist durchaus keine dumme Idee. Object-Relation-Mapping macht meistens Umstände. Wenn man viele Daten hat, kommt man nicht dran vorbei. Bei Euch ist es aber einfacher und vermutlich auch deutliche effizienter, einfach alle Daten für gerade laufende Spiele im Speicher zu halten und beim Unterbrechen eines Spiels irgendwie zu speichern.
Ich könnte mir z.B. so eine Architektur gut vorstellen:
Auf dem Server läuft für jedes Spiel ein Thread. Dieser Thread regelt die Kommunikation zwischen zwei Clients bzw einem Client und einer KI-Instanz.
Gespeichert werden die Daten entweder einfach per Serialization oder falls man das gespeicherte Format auch anderweitig lesen will als XML-Datei oder eben auch in eine Datenbank. Das ist aber Extrafunktionalität. Die Datenobjekte für ein Spiel kann man per Serialization direkt in eine Datei schreiben und später wieder laden.Client und Server tauschen per RMI direkt Javaobjekte aus. Damit spart man sich auch, ein Protokoll zu entwickeln. Man muss natürlich etwas aufpassen, welche Daten man da hin und her schiebt, und dass der Client nicht Daten bekommt, die er nicht kennen darf (je nach Spiel) oder Daten ändern kann, die er nicht ändern darf. Also nicht einfach das Datenmodell hin und her schicken. Es wäre aber durchaus möglich, den Client über ein Interface direkt Methoden des Datenmodells auf der Serverseite aufrufen zu lassen. Man könnte sogar die Klasse, die die graphische Darstellung eines Spiels erzeugt, auf dem Server ablegen und sie vom Client laden lassen. Dann müsste der Client die Spiele nicht schon kennen und wäre nur so eine Art minimale Laufzeitumgebung. Aber das ist vielleicht etwas zu übertrieben ;-)
Aber ich seh das anderst. Nehmen wir folgendes Beispiel. Es haben sich am Server 7, 8 Spieler angemeldet und spielen. Wird nun eine bestimmte Karte an einen Spieler ausgegeben, genügt ein simples Update...
Wäre ohne Datenbank mindestens genau so einfach. Nur ein Methodenaufruf, die Karte wird in einem Set gespeichert und an den Client geht ein Methodenaufruf receiveCard(Card) o.ä.
Würde man ein Array verwenden, hätte man nicht nur einen höheren Aufwand O(n) - okay bei der Größe wäre der auch so minimal. Aber da irgendwo anzufangen strings oder ids zu vergleichen, ich weiß nicht. Ich halte das nicht für wirklich sinnvoll.
Wenn Du irgendwelche IDs aus Arrays raussuchst, machst Du an der Stelle was falsch. Du musst natürlich ein angemessenes Datenmodell haben und auch mal andere Datenstrukturen als Arrays verwenden (Maps wären für etwas mit IDs vielleicht toll).
Normalerwiese machen Datenbanken die Organisation einer Anwendung wirklich nicht einfacher.Für Dein welcher User hat welche Karten problem würde man sowas machen:
Map<User, Map<Karte, Integer>> kartenverteilung = new HashMap<User, Map<Karte, Integer>>();
Map<Karte, Integer> stapel = new Map<Karte, Integer>();boolean gibKarteAn(Karte karte, User user) {
int count = notNull(stapel.get(karte));
if (count == 0) {
return false;
}
stapel.put(karte, count - 1);
kartenverteilung.get(user).put(karte, notNull(kartenverteilung.get(user).get(karte)) + 1);
return true;
}int notNull(Integer i) {
return i == null ? 0 : i;
}Mit weniger Logik kommt man da in SQL auch nicht durch. Manche Berechnungen sind in SQL sicher einfacher, weil man eine mächtige Abfragesprache hat. Allerdings ist die Organisation des Programms meist schwieriger, weil man die Logik nicht so geschickt über seine Objekte verteilen kann. Last but not least: So lang Du die Daten so einfach im Speicher halten kannst, ist die Datenbank mit Sicherheit langsamer ;-)
Ich will Dir die Datenbank nicht grundsätzlich ausreden. Aber die eigentliche Anwendungslogik in SQL zu basteln, dürfte Probleme mit sich bringen. Vor allen Dingen, da ihr ja auf andere Spiele erweiterbar sein sollt und das DB-Design damit auch nicht so einfach wird, oder geht es nur um Kartenspiele?
Grüße
Daniel
-
Hey!
Also erst mal danke an alle für die vielen Antworten zu später Stunde.
Habe in einem Projekt einmal solche Datenstrukturen wie Array List verwendet und bin damit mächtig auf den Mund gefallen. Deswegen wohl meine Vorliebe zur DB. Vielleicht wäre es besser, die Frage noch offen zu lassen. Aber eher zu einer Datenstruktur zu tendieren.
Wenn ich das jetzt richtig verstanden habe, wäre eine gute Lösung die folgende. Wird ein Spiel gestartet, erzeugt der Server zu diesem Spiel eine art Manager-Objekt. Aktuelle Spielstände, angemeldete Benutzer... kann das Objekt zur Verügung stellen. Für jede Instanz des Spiels wird auch ein neues Objekt erzeugt. Die Speicherung der Daten kann in einer DB erfolgen oder vorzugsweise über eine geeignete Datenstrukur. Aber beim Verwenden des Manager-Objekts sollte man davon sowieso nix merken.
Der Server und der Client kommunizierne über RMI mit einander. Beispielsweise bei einer Anfrage des Clienst GetNextCard(). Der Server leitet dann die Anfrage zum jeweiligen Objekt (Manager-Objekt weiter).
Vom Gefühl her würde ich sagen, machen wir den Server recht schlank. Sprich die Grafikdarstellungen, die einzelnen Bildchen der Karten... lagern wir komplett in das Spiel aus, welches auf dem Client läuft. Der Client erhält Karten vom Server, zeigt diese an, gibt Karten zurück, stellt Anfragen, erhält Antworten oder Anweidungen...
Das selbe macht die KI, nur ohne eine UI oder irgend eine grafische Darstellung.
LG
-
Hallo Nick,
Wenn ich das jetzt richtig verstanden habe, wäre eine gute Lösung die folgende. Wird ein Spiel gestartet, erzeugt der Server zu diesem Spiel eine art Manager-Objekt. Aktuelle Spielstände, angemeldete Benutzer... kann das Objekt zur Verügung stellen. Für jede Instanz des Spiels wird auch ein neues Objekt erzeugt.
Ja so stelle ich mir das vor.
Die Speicherung der Daten kann in einer DB erfolgen oder vorzugsweise über eine geeignete Datenstrukur. Aber beim Verwenden des Manager-Objekts sollte man davon sowieso nix merken.
Richtig. Im Prinzip ist es fast egal, wie die erste Implementierung aussieht, wenn er Euch nicht sicher seid, welche Datenstrukturen wie am besten sind. Wenn die Schnittstelle stimmt, könnt ihr die Implementierung immer noch ersetzen.
Der Server und der Client kommunizierne über RMI mit einander. Beispielsweise bei einer Anfrage des Clienst GetNextCard(). Der Server leitet dann die Anfrage zum jeweiligen Objekt (Manager-Objekt weiter).
Richtig, wobei hier RMI schon sehr viel von selbst machen kann. Man kann z.B. eine Referenz auf das Manager-Objekt (bzw auf ein Hilfsobjekt, das zulässige Zugriffe an das Manager-Objekt weiter leitet) an den Client geben.
Darum, dass die Methodenaufrufe des Clients übers Netz zum Serverobjekt wandern, kümmert sich RMI selbst.Vom Gefühl her würde ich sagen, machen wir den Server recht schlank. Sprich die Grafikdarstellungen, die einzelnen Bildchen der Karten... lagern wir komplett in das Spiel aus, welches auf dem Client läuft.
Klar, der Code für die GUI sollte auf jeden Fall auf dem Client laufen und nur logische Kommandos sollten ausgetauscht werden. RMI erlaubt es allerdings, ganze Objekte inklusive der Klasse und des zugehörigen Bytecodes übers Netz zu übertragen. Man könnte damit quasi die GUI des Spiels auf dem Server instanzieren und an den Client schicken. Damit müsste man neue Spiele nur auf dem Server installieren, nicht auf den Clients. Das war aber nur so eine Idee, so etwas würde ich höchstens machen, wenn am Schluss noch Zeit ist.
Der Client erhält Karten vom Server, zeigt diese an, gibt Karten zurück, stellt Anfragen, erhält Antworten oder Anweidungen...
Ja.
Das selbe macht die KI, nur ohne eine UI oder irgend eine grafische Darstellung.
Ja, die KI verwendet die selbe Schnittstelle, wie ein normaler Client. Nur greift sie eben nicht übers Netz per RMI zu, sondern läuft lokal. Der Server muss also so entworfen sein, dass er Kommandos/Ereignisse des Spiels an Client-Objekte bzw. Kommandos von diesen an das Spiel weiterreichen kann.
Ob das nun ein lokales Objekt (KI) oder ein entferntes Objekt (GUI-Client) ist, sollte an der Stelle keine Rolle spielen.Grüße
Daniel
-
Vielen Dank für die Hilfe! LG Nick
-
-
-
-
-
Hallo Nick,
wir sind ne 7 köpfige Gruppe von Informatik-Studenten, 5tes Semester. Wir haben 7 Wochen Zeit um ein Spiel zu programmieren.
Also zu viele Leute für zu wenig Zeit, das bedeutet weniger eine Herausforderung an Eure Programmierfähigkeiten (vorausgesetzt ihr könnt hinlänglich gut programmieren) als an Eure Organisationsfähigkeiten ;-)
Also erstmal eine minimale Zeitplanung vielleicht:
1 Woche "Spezifikation" bzw. Selbstfindungsphase, was wollt Ihr überhaupt, wie viel könnt Ihr in dieser Zeit umsetzen. Beschränkt Euch auf eine sinnvolle Basisfunktionalität. Diese Woche ist mittlerweile vermutlich sowieso schon fast rum.
2 Woche "Entwurf". Überlegt welche Komponenten ihr braucht, welche Technologien ihr nehmt, versucht den Kram so zu verstehen, dass ihr damit auch arbeiten könnt. (Zu viel neues Zeug wird also nicht gehen, ihr habt ja kaum Zeit zu lernen, wie man damit umgeht.)
3-4/5 Woche Implementierung, überlegt euch, wie ihr dabei vorgeht. Zentrale Teile zuerst, möglichst bald etwas erreichen, was rudimentär tut. (Also nicht einfach mal die guten Leute an der tollen KI tüfteln lassen und die schlechten am Layout und dann gucken, was noch fehlt ;-)
4/5-7 Woche, Testen, Fehler beheben, retten was zu retten ist ;-), Pufferzeit falls ihr Euch irgendwo verschätzt habt.
Das scheint ein großer Teil der Zeit zu sein, aber in nur einer Woche kann man verdammt wenig reparieren, wenn irgendwie alles doch noch nicht so funktioniert, wie man das wollte.Ein Teil muss auf nem Windows 2003 Server laufen (der Spieleserver) und ein Teil auf dem Client (das Spiel).
Das müsst Ihr genauer klären, wenn es Anforderungen sind. Wenn es keine sind, müsst Ihr es auch klären, aber indem Ihr Euch überlegt, was für euch da am sinnvollsten ist. (Also eher im 2. Schritt)
Es soll möglich sein, später weitere Spiele hinzu zu programmieren.
Welche Arten von Spielen, ihr müsst für einen Entwurf wissen, welche Art von Datenaustausch Ihr zwischen Clients und Server ermöglichen müsst. Dazu braucht Ihr wahrscheinlich eine gewisse vorstellung davon, was ein Spiel so ist.
- Datenbank, speichert aktuelle Spielstände, Benutzerdaten...
Hier ist auch wieder wichtig, wie Spielstände aussehen und welche Informationen man über Spiele sonst noch speichern muss. Je mehr man hier abdecken will, desto flexibler muss dann auch das Design werden.
- Spiele-Server (läuft auf Windows 2003 Server), greift als einzige Anwendung auf die Datenbank zu, nimmt Anfragen von Clients entgegen beispielsweise "geb mir die nächste Karte", bestimmt die Anwort aus der Datenbank und antwortet dem Client
- Spiel 1, kommuniziert mit dem Spiele-Server.
- KI 1, simuliert einen Menschen. Die KI wird nur dann ausgeführt, falls ein Mensch gegen den Computer spielen möchte. Für jedes Spiel das wir programmieren, müssen wir einen separate KI programmieren. Die KI wird auf dem Server ausgeführt. Sie enthält Methoden wie z. B. MakeNextMove()
Das Konzept muss noch genauer werden, vor allem dahin, wie Ihr einzelne Spiel-Sitzungen verwaltet und wie Ihr vom konkreten Spiel und der konkreten KI so abstrahiert, dass das alles ausreichend erweiterbar ist.
Wichtig sind denke ich folgende Punkte:
- versteht Eure Technologie hinreichend gut.
- macht darauf aufbauend ein robustes Konzept für die zentralen Anforderungen.
- implementiert das so schnell wie möglich, damit Ihr seht, ob es tut.
Dass die KI gut funktioniert, man im Client wirklich schön spielen
und der Server was weiß ich noch tun kann, ist erst danach wichtig. Das kann man dann auch sehr gut auf mehre Leute verteilen und zusammenarbeiten, wenn eine robuste Basis steht.
Grüße
Daniel