Textbasiertes Rundenstrategiespiel

Status
Nicht offen für weitere Antworten.

simon_m

Mitglied
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 :oops:

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

Top Contributor
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

Mitglied
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?
 

simon_m

Mitglied
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

Top Contributor
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

Top Contributor
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

Mitglied
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!!!
 

simon_m

Mitglied
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

Top Contributor
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

Top Contributor
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

Mitglied
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

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

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

xZise

Aktives Mitglied
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
 

simon_m

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

einfach den Link vom letzten Post benutzen!
 

simon_m

Mitglied
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

Top Contributor
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:
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.

Ich würde es folgendermassen machen:

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

Code:
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

Bekanntes Mitglied
Wenn ich das von Lim_Dul noch fortsetzen darf :D
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

Top Contributor
K-Man hat gesagt.:
Wenn ich das von Lim_Dul noch fortsetzen darf :D
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

Bekanntes Mitglied
@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...
 
G

Guest

Gast
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...
 
G

Guest

Gast
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

Mitglied
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.
 

simon_m

Mitglied
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
[16:30] <@Roar> mhm
[16:30] <+zenabi> wie könnte man das machen?
[16:30] <@Roar> wenn du nur ein paar bunte bildchen haben willst sind ein paar labels mit icons drauf wohl am einfachsten?
[16:31] <+zenabi> und bei ner Spielfläche von ca. 30*30 ???
[16:31] <@Roar> das sollte auch noch zu schaffen sein, solang nicht für jedes feld ein neues imageicon laden musst
[16:32] <+zenabi> nö, das nicht...
[16:33] <+zenabi> in Delphi hab ich das mal so gemacht, dass ich ein großes Image hatte, und dann kleine darein gezeichnet hab
[16:33] <+zenabi> geht das in Java auch?
[16:33] <@Roar> ja
[16:33] <+zenabi> muss man dann ein Image oder ein ImageIcon nehmen?
[16:33] <@Roar> ein BufferedImage
[16:35] <+zenabi> ok, ich gucks mir mal an
[16:35] <+zenabi> danke erstmal

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???
 
R

Roar

Gast
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

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

Roar

Gast
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...
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen

Neue Themen


Oben