# Textbasiertes Rundenstrategiespiel



## simon_m (19. Nov 2005)

Hallo Leuts.
Ich wollte mich mal daran machen, ein textbasiertes Rundenstrategiespiel zu proggen. Ich kann Java noch net so lang und einige kennen meine mehr oder minder dämlichen Fragen aus dem Chat   

Deshalb meine erste Frage, glaubt ihr, dass das sehr schwierig wird???
Ich wollte es ganz simpel machen:
Man baut Gebäude - kriegt Rohstoffe - baut Truppen - greift den Gegner an

Ich denke mal, dass ist nicht so kompliziert.

Mein größeres Problem ist die KI. Da hab ich überhaupt keinen Plan, wie man das machen könnte.

Für Anregungen wäre ich sehr dankbar.

mfg
Simon


----------



## Illuvatar (19. Nov 2005)

Hm textbasierte Rundenstrategie - ich hab grad keine Vorswtellugn wie das aussheen soll, auf der Konsole oder wie?

Ich denke wenn du dir vorher gescheit überlegst was für Klassen du brauchst und so dürfte die Grundstruktur zumindest sicher nicht leicht, aber auch nicht unüberwindlich schwierig.

@KI: Na ja wie schlau soll sie denn sein, sin ja eigentlich bloß paar einfahce Regeln: Wenn viele Soldaten - zum Feind schicken, wenn Feind bei mir - alles zum Abewhren tun, wenn keine Rohstoffe - Militär zurücksetzen und Rohstoffe bauen, wenn Gebäude fehlt - Gebäude bauen etc.


----------



## simon_m (19. Nov 2005)

Ich stelle mir das so ähnlich wie ein Browsergame vor (nur damit du eine Vorstellung hast).

Zu den "gescheiten Überlegungen": Ich weiß immer nicht genau, wie ich sowas anfangen soll. Ich habe mir schon überlegt, eine Klasse "Gebäude" zu machen, von denen ich die anderen dann ableite. Genauso könnte man es auch mit Forschung und Einheiten machen, aber weiter weiß ich auch nicht. Ich mach mir aber noch einmal Gedanken dazu. Viell fallt mir noch was ein.

KI: Jo. So könnt man es machen. Je ausgefeilter die KI dann werden soll, umso umfangreicher wird der Code, oder sehe ich das falsch?


----------



## MPW (19. Nov 2005)

hm, ich würde es aber so anlegen, dass du später Grafik hinzufügen kannst


----------



## krey (20. Nov 2005)

joa ich auch


----------



## simon_m (20. Nov 2005)

wie jetzt? Der Quellcode soll so sein, dass man da gaanz schnell bewegte Bilder reinsetzen kann? Das stell ich mir sehr schwierig vor. Außerdem habe ich davon gar keine Ahnung.


----------



## MPW (24. Nov 2005)

Nah OOP halt,(falls du nicht weiß, was das ist, stop dein Projekt und lern erstmal Java)..

Also, du machst Klassen, die das eigneltiche Spiel verwalten, die GUI, ob Textbasierent oder nicht, machst du so, dass man sie durch andere klassen ansteuern kann, diese kannst du später graphisch gestallten.


----------



## Lim_Dul (24. Nov 2005)

So ein Spiel ist generell ein etwas größeres Projekt.

Ich würde daran wie folgt rangehen:

Schritt 1: Spielregeln definieren.
Dafür ist nichtmal ein Computer notwendig, Papier und Stift tun es auch. Du solltest dir erstmal überlegen, was es alles beim dem Spiel gibt.

Du hast was von Gebäuden, Truppen, Rohstoffen, Kämpfen erwähnt:

Was für Rohstoffe?
Was für Gebäude?
Was für Truppen?
Wie wird ausgebildet? Sind die Einheiten sofort nächste Runde da oder kann das mehrere Runden dauern?
Wie laufen Kämpfe ab?
Was für Eigenschaften haben die ganzen Sachen? (Stärke, Produktionsmenge etc.)
Gibt es ein Spielfeld?
Kann man Gebäude angegreifen?
Was für Sonstige Aktionen gibt es?

Die Werte müssen nicht umbedingt toll sein, dass kann man auch später noch alles justieren. Wichtig ist, dass du dir klar wirst, was für Sachen es gibt und welche Eigenschaften die haben und wie das Spiel abläuft.

Schritt 2: Objektstrukturen für die Sachen definieren.
Dann kann man das ganze in Objekte gießen. Hier bietet sich UML an (Oder wieder ein Blatt Papier und Stift).

Das heißt, das du dir überlegst, was für Objekte gibt es. (Spieler, Gebäude, Einheiten, Rohstoffe, Truppen, ...) und was für Eigenschaften und Methoden haben sie (Stärke, Wert, ....)

Schritt 3 und weitere: Hier kann ich dir jetzt nicht konkret was sagen, was sinnvoll wäre, aber es würde dann folgen:
GUI überlegen, wie soll die GUI aussehen. (Ob jetzt Text oder Graphisch ist erstmal egal, beides erfordert überlegungen, wie das ausszusehen hat)
Überlegen, wie die GUI mit den Spielelementen kommuniziert. (Idealerweise eine MVC Konzept) (Google oder die Forumssuche sollte dazu was ausspucken)


----------



## simon_m (27. Nov 2005)

Vielen Dank!!!
Ich bin jetzt zwar weg von der textbasierten Rundenstrategie und möchte das lieber mit grafischer Echtzeit machen, aber die Ansätze kann ich ja trotzdem sehr gut gebrauchen! Ich meld mich, wenn ich noch Fragen hab.
Also nochmal Danke!!!


----------



## MPW (28. Nov 2005)

Viel Spaß und Erfolg beim Coden, keep us up to date!


----------



## simon_m (28. Nov 2005)

Ich hab mir jetzt noch einen "Mitarebiter" gesucht. Wir sind zu dem Schluss gekommen, dass wir jetzt wahrscheinlich doch lieber textbasierte Rundenstrategie nehmen, da das andere einfach zu schwer ist!
Das ganz grobe Grundgerüst steht schon (nur auf dem Papier, gecodet ist noch nichts). Vielleicht kann ich demnächst mal was konkretes dazu schreiben!
Ich werde euch auf jeden Fall "up to date keepen" und wäre euch dnn für Kritik (positiv sowie auch negativ) sehr dankbar!


----------



## Lim_Dul (28. Nov 2005)

Textbasiert ist auf jeden Fall deutlich einfacher als Echtzeit.
Bei Textbasiert kann man sich das ganze Gedöns mit Threads und Gui Gestaltung sparen


----------



## MPW (28. Nov 2005)

Lim_Dul hat gesagt.:
			
		

> Textbasiert ist auf jeden Fall deutlich einfacher als Echtzeit.
> Bei Textbasiert kann man sich das ganze Gedöns mit Threads und Gui Gestaltung sparen



Also Threads wird man auch in Textbasiertenspielen brauchen, sofern sie gut gemacht sind und Ereignisgesteuert sind.

Sach' einfach mal bescheidt, wenn's 'ne Alphaversion gibt!


----------



## simon_m (29. Nov 2005)

Vorab haben wir hier mal eine Art Grundkonzept (leider noch nicht vollständig - Freistunde zu kurz  )!
Medieval-Konzept downloaden

Aso: Es heißt absofort Medieval, sind aber auch auf bessere Namen von euch gespannt... (war eher eine "Notlösung")


----------



## MPW (29. Nov 2005)

Sieht schön aus, ich bin sicher ihr packt das schon...

Wenn ihr Hilfe braucht, wisst ihr ja wo ihr sie findet;-)


----------



## xZise (1. Dez 2005)

Leider gibt es angeblich schon Medieval, und da wir kein Bock auf "stress" haben wollen, wäre es nett, wenn ihr vielleicht auch noch Namen hättet


----------



## André B. (1. Dez 2005)

www.conquer-space.net
Das ist ein Browserspiel, das koplett in Java geschrieben wurde. Den Quellcode kannst du dir auch runterladen. Ist richtig gut gemacht und wie gesagt alles opensource.


----------



## simon_m (1. Dez 2005)

Es gibt jetzt ein aktualisiertes Medieval Konzept! Wäre nett, wenn ihr eure Meinung zu den Sachen äußert.
Falls ihr es euch noch nicht gedacht habt, xZise ist der "Mitarbeiter" von dem ich gesprochen habe!

PS: Wir haben immer noch ein Namensproblem!


----------



## simon_m (2. Dez 2005)

Gibt jetzt noch ne neue Version (wir hatten heut 2 Freistunden )

einfach den Link vom letzten Post benutzen!


----------



## xZise (5. Dez 2005)

Jetzt benutzten wir eine gemeinsame Plattform mit einen neuem Link.


----------



## xZise (6. Dez 2005)

Das Konzept scheint endlcih fertig geworden zu sein.

Näheres siehe den Link oben.

Entwicklungstagebuch


----------



## simon_m (13. Dez 2005)

So....
wir haben jetzt mit dem coden angefangen und da sind gleich einige Fragen zum Vorschein gekommen. Eine fällt mir so spontan ein:
Wir wollen die Stärken der Einheiten aus einer externen Datei auslesen, damit man die Werte nicht im Quellcode ädern muss. Weiterhin haben wir eine Klasse "Einheiten", die die ganzen Eigenschaften besitzt, die zugewiesen werden sollen.
Jetzt fragen wir uns, was weniger Ressourcen fressend wäre:
Ein Array zu erstellen, das von der Klasse Einheiten abgeleitet wird und dann immer wenn eine Einheit neu produziert wird den Wert zuweisen....
oder Unterklassen zu erstellen, die von Einheiten erben und sich die Werte aus der Datei holen. Dann würden wir verschiedene Arrays machen - für jeden Einheitentyp eins.


----------



## Lim_Dul (13. Dez 2005)

simon_m hat gesagt.:
			
		

> So....
> wir haben jetzt mit dem coden angefangen und da sind gleich einige Fragen zum Vorschein gekommen. Eine fällt mir so spontan ein:
> Wir wollen die Stärken der Einheiten aus einer externen Datei auslesen, damit man die Werte nicht im Quellcode ädern muss. Weiterhin haben wir eine Klasse "Einheiten", die die ganzen Eigenschaften besitzt, die zugewiesen werden sollen.
> Jetzt fragen wir uns, was weniger Ressourcen fressend wäre:
> ...



Ich würde es folgendermassen machen:

Eine abstrakte Klasse EinheitenBuilder machen, die ungefähr so ausssieht:


```
abstract class EinheitenBuilder {

  public static Einheit createEinheit(int typ) {
    switch(typ) {
      case typ1: ErzeugeTyp1; return erzeugteVariable;
      // usw.
  }
}
```

Innerhalb der Klasse kannst du dann die Daten aus einr Datei einlesen. Ich würde sie auch in der Klasse speichern, da die Daten nicht so groß sein sollten und Festplattenzugriffe relativ teuer sind.


----------



## K-Man (13. Dez 2005)

Wenn ich das von Lim_Dul noch fortsetzen darf  
Wenn du es mit dieser Factory machst (warum ist die hier abstract?), dann kannst du neue Einheiten erzeugen, indem du einfach eine neue Einheit in deiner Datei erzeugst. Am leichtesten machst du es wohl mit einer XML-Datei. Da gibts du den Namen der Einheit, Stärke usw. an. Zusätzlich kannst du den Klassenpfad der Hauptklasse der neuen Einheit angeben, falls sie noch zusätzliche Aufgaben erfüllen muss (zb später die graphische Darstellung...)
Hoffe, dass war jetzt nicht zu verwirrend und wenigstens etwas sinnvoll :lol:


----------



## Lim_Dul (13. Dez 2005)

K-Man hat gesagt.:
			
		

> Wenn ich das von Lim_Dul noch fortsetzen darf
> Wenn du es mit dieser Factory machst (warum ist die hier abstract?),


Gegenfrage: Warum soll jemand eine konkrete Instanz davon benötigen, wenn eh nur über statische Methoden darauf zugegriffe nwird.



> dann kannst du neue Einheiten erzeugen, indem du einfach eine neue Einheit in deiner Datei erzeugst. Am leichtesten machst du es wohl mit einer XML-Datei. Da gibts du den Namen der Einheit, Stärke usw. an. Zusätzlich kannst du den Klassenpfad der Hauptklasse der neuen Einheit angeben, falls sie noch zusätzliche Aufgaben erfüllen muss (zb später die graphische Darstellung...)
> Hoffe, dass war jetzt nicht zu verwirrend und wenigstens etwas sinnvoll :lol:


Das schöne an der Lösung ist, dass man dies, was du vorschlägst, immer noch später machen kann - Man muss nur diese Factory Klasse anpassen. Man muss es also nicht sofort machen


----------



## K-Man (13. Dez 2005)

@Lim-Dul:
Naja das mit der Factory ist wohl eine Ansichtssache. Kommt wohl darauf an, wie es benutzt werden soll. Hat man die Klassen schon vorher, dann eignet sich ein Factory-Interface. Diese wird dann abgeleitet und jede Ableitung kümmert sich selber um die Methode...somit kann man die Factory über das Interface aufrufen und erst zur Laufzeit wird entschieden, welche Ableitung benutzt wird.
In diesem Fall kann man die Sache wohl schon static machen, was den Vorteil hat, dass man diese Factory-Klasse nicht mehr ändern muss. Wie gesagt: Man gibt in der XML-Datei gleich den Pfad der neuen Einheitenklasse an und per Reflection kann diese zur Laufzeit durch die Factory erzeugt werden...


----------



## Guest (2. Jan 2006)

Sprechen wir davon, dass jede Einheit eine Klasse ist? Oder haben wir ein Objekt Einheit, von dem für jede Einheit eine Instance vorhanden ist, die sich in den Werten unterscheidet (schonmal an ein RPG-Element gedacht)?

In jedem Fall: keine Array's , da musst du von anfang an festlegen, wie viele Elemente maximal vorhanden sind, besser ist Vector/ArrayList/LinkedList oder so irgendwas, dass von Collection erbt...

Zur Factory: 
Sinnvoll! 
abstract: 
Die Klasse muss, soweit ich weiß, mindestens eine abstracte Methode enthalten, und die hast du nicht, wenn eh nur static's drinn sind->also nicht abstract...


----------



## Guest (2. Jan 2006)

Achso, ich vergass die Sache mit dem Namen: 
da ich nicht am eigenen Rechner sitze will ich ungern irgendetwas herunterladen, deshalb hab ich euer Konzept nicht gesehen...aber:

Habt ihr irgendeinen bekannten Background: Mittelalter, erster/zweiter Weltkrieg, Fantasy ö.ä.

Wenn ja:
Verkettet mit einem bekannten zeitlichen/mythologischen Background: Tafelrunde, Kreuzzüge usw...
Sucht einen Begriff der dazu passt, ergänzt Füllmaterial: Schatten über ...  , die xyz von/der ... usw.
Fertig!

Wenn nein: 
sucht einen deutschen Begriff, der eurer Speil beschreibt, sucht möglichst viele Übersetztungen (Onlinewörterbücher, Bekannte fragen usw.)...da ist bestimmt was schönes bei...es müssen auch nicht genaue Übersetzungen eures Begriffs sein, ungefähr reicht vollkommen...
Das ist ein oft genutztes Prinzip: volvo: Latein, ich will, Video, Latein, ich sehe, ich wusste mal noch mehr...Caesar??

Eventuell beides mischen...was heißt Tafelrunde auf Hawaiisch?


----------



## simon_m (10. Jan 2006)

Wir haben uns mal mit der Arraylist beschäftigt. Dabei ist uns folgender Begriff aufgefallen:

"*Iterator*"

Deshalb fragen wir euch alle:



			
				Simon und xZise hat gesagt.:
			
		

> Was ist eigentlich ein Iterator?



Wir wollen jetzt erstmal mit einem Editor für die Einheiten und die Karten anfangen. Bei dem Karteneditor wird die Arbeitsfläche so ähnlich sein, wie später die Spielfläche. Da können wir das schonmal üben.

PS: Sorry, dass wir so lange nichts geschrieben haben, aber wir hatten kaum Zeit. Jetzt machen wir aber mal was.


----------



## Illuvatar (10. Jan 2006)

http://www.galileocomputing.de/open...el_11_001.htm#Rxx365java110010400038C1F0131D6


----------



## simon_m (12. Jan 2006)

Das mit dem Iterator, hab ich noch nicht ganz begriffen...kommt aber noch, dank ich mal.
Für den Editor ist das ja auch noch nicht so wichtig.

Jetzt hab ich noch ne andere Frage. Ich poste dazu mal ne Unterhaltung aus dem Chat:


			
				zenabi & Roar hat gesagt.:
			
		

> [16:28] <+zenabi> ich hab ne kleine Frage:
> [16:29] <+zenabi> wenn man ein Spielfeld erstellen will, das aus lauter Quadraten bestehen soll
> [16:29] <+zenabi> dann ist es doch dumm, wenn man ein 2D ImageIcon - Array nimmt, ...
> [16:30] <+zenabi> weil man dann ja auch noch ein Array mit JLabels machen muss, wo die dann raufgezeichent werden
> ...



Ich hab mir BufferedImage jetzt mal ein bisschen angeguckt. Ich finde das klingt ganz gut. Meine Frage ist jetzt, was besser wäre, auch später für das Spiel. Die Darstellung wäre doch sicher mit einem BufferedImage schneller, oder nicht? Und ich denke auch, dass man die Spiellogik da genau so gut hinkriegt, denn man hätte dann ja immer noch die ImageIcons, die dann halt nur auf ein BufferedImage gezeichnet werden.
Gibt es einen Nachteil, den ich übersehen habe???


----------



## Roar (12. Jan 2006)

ein BufferedImage wär die bessere lösung, da wahrscheinlich schneller, wenn du intelligent neuzeichnest, und weniger speicherlastig. 
wenn du ein BuffededImage benutzt brauchst du keine ImageIcons mehr, da kannst du direkt Images draufmalen.


----------



## simon_m (12. Jan 2006)

Meinst du mit intelligent neuzeichnen, dass man immer nur das neuzeichnet was sich verändert, oder gibts da noch mehr zu beachten?


----------



## Roar (12. Jan 2006)

simon_m hat gesagt.:
			
		

> Meinst du mit intelligent neuzeichnen, dass man immer nur das neuzeichnet was sich verändert, oder gibts da noch mehr zu beachten?


ja, z.B.. es gibt aber noch mehr sachen die man beachten sollte. Da ich mich mit java2d nicht besonders auskenne such lieber mal im forum hier nach BufferStrategy und so...


----------

