Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

22.12.2011, 00:37

Rundenbasiertes Strategiespiel mit kleiner Wirtschaftssimulation in Python

p { margin-bottom: 0.21cm; } Hallo!
Ich bin ein Neuling auf dem Gebiet des Programmierens, interessiere mich aber sehr dafür. Ich habe in der letzten Zeit einige C++-Bücher und Tutorials durchgeschaut und -gearbeitet und mir nun ein (noch sehr oberflächliches Bild) vom Programme-Schreiben gemacht.
Nun zu meinem Anliegen: Viele werden noch das Brettspiel „Battletech“ kennen (ich meine nicht die Videospiele). Ich habe nun die Idee gehabt, das Spiel 1:1 in ein Programm umzusetzen. Da ich aber schon bei einigen Versuchen, auch nur kleine Teile des Spiels ideenhaft zu schreiben an meine Grenzen stieß, habe ich nun einige Fragen. Zunächst aber eine kleine Übersicht, was ich mir bisher überlegt habe und es würde mich freuen, wenn ihr eine ehrliche Einschätzung geben würdet:
Allgemeiner Aufbau des Programms
  1. Mich interessieren mehr die Verrechnungs- und Verknüpfungs-“vorgänge“ im Programm. Daher muss keine grafische Oberfläche vorhanden sein. Textbasiert reicht für mich erstmal. Nach allem, was ich gelesen habe, dürfte das mein Vorhaben erleichtern.
  2. Es sollte eine Art Menüführung vorhanden sein. Die Menüs und Untermenüs sollen miteinander verknüpft sein, d.h. man soll natürlich vor und zurückspringen können und eingegebene Werte (ob durch Funktionen ermittelt oder vom Nutzer eingegeben) sollen gespeichert werden (Name, Erfahrungswerte etc.)
  3. Der Benutzer des Programms soll seinen Spielstand speichern können.
Details zum Spielprinzip
  1. Es soll eine Mech-Klasse geben und die Mechs sollen daraus erstellte Objekte sein. Die Klasse soll Werte enthalten wie → Tonnage, externe und interne Panzerungspunkte für Körperteile, Wärmetauscherzahl, Bewegungseinheiten, Bewaffnung, Sprungdüsen.
  2. Es soll eine Spieler-Klasse geben, welche die Werte → Bordschützenwert und Mechpiloten-Fähigkeit und Erfahrungswert enthält. Wahrscheinlich wird hier auch das verfügbare Geld eingetragen werden.
  3. Der Spieler soll zufällig im Inventar angegebene Mechs kaufen können, deren Preis Schwankungen in einem bestimmten Intervall unterliegen. D.h. Besucht der Spieler einmal einen Markt, so wird sich der Preis beim nächsten Mal zufällig entschieden unterscheiden.
  4. Der Spieler soll seinen Mech ausrüsten und reparieren können, d.h. Er kann Waffen- und Panzerungsschadenspunkte wieder auf maximum zurücksetzen, was ihn Geld kostet.
  5. Der Spieler soll Missionen auswählen können, durch welche er Geld verdient. Die Missionen werden wahrscheinlich einige Typen umfassen,d.h. ein Storymode wird so erstmal nicht vorhanden sein, welche zufällig zur Auswahl angeboten werden (ähnliches Prinzip wie beim Preis). Die Missionen werden Ziele wie "Zerstören", "Verteidigen", "Erreichen einer Umgebung" etc. umfassen.
Kampfsystem
  1. Das Kampfsystem würde ich gerne wie aus dem Spiel übernehmen. Dazu gehört die Wärmeentwicklungsskala, Entscheidungen, ob gestanden, gegangen oder gerannt werden soll, das Abfeuern von Waffen etc.
  2. Die Landschaft soll durch Koordinaten angegeben werden. Hier bin ich noch nicht ganz sicher, wie ich es textbasiert umsetzten kann, möglicherweise kann eine Karte im ASCII-Zeichen dargestellt werden, aber wird auch noch eine Weile dauern, bis ich bei diesem Punkt bin. Jedenfalls soll die Landschaft Werte wie Höhe und Art der Beschaffenheit enthalten, welche den Spieler beim Laufen und Abfeuern der Waffen beeinflussen.
  3. Der Spieler soll fähig sein, über eine Menüführung Werte des Mechsystems abzufragen, also derzeitige Wärmeentwicklung, Waffen, Schäden, Karte des Spielfeldes.
  4. Der Gegner soll über eine gewisse Intelligenz verfügen (Hier vermute ich den schwersten Teil, auch wenn alles davor sicherlich nicht einfach umzusetzen ist)
Das wären soweit meine Ideen. Natürlich ist das Ganze noch nicht zuende gedacht. Mein Anliegen ist auch mehr, dass ihr mir Empfehlungen geben könnt, welche Themen ich auf jeden Fall noch in C++ lernen sollte. Bis jetzt habe ich mich beschäft mit Werte eintippen, Nachrichten ausgeben, ein wenig zu Klassen und Objekten, for, while, else schleifen, arrays, zeiger und einige andere Themen.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Dädalus« (19.07.2013, 13:27)


2

22.12.2011, 00:41

Noch eine Ergänzung: Das Kampfsystem soll rundenbasiert ablaufen.

3

22.12.2011, 15:07

Einige Details

Hallo!

Ich konkretisiere das Ganze noch etwas, vielleicht fällt dann eine Einschätzung leichter. Was ich mir wünsche, wären einige konkrete Angaben, welche Themen ich in C++ beherrschen sollte, um das zu realisieren (Ich selbst kann den Aufwand noch gar nicht so genau abschätzen) Das hier ist ein Ausschnitt aus dem Kampfmodus, er umfasst hier aber nur die Bewegung der Mechs.

Generelles
Das Spielfeld setzt sich aus Hexfeldern zusammen.
Mechs können ausgerichtet werden nach:
Norden
Nordwesten
Südwesten
Südosten
Nordosten
Die Hexfelder haben unterschiedliche Eigenschaften:
Freies Gelände
Unwegsames Gelände
Lichter Wald
Dichter Wald
Wasser Tiefenlevel1
Wasser Tiefenlevel2
Höhenunterschiede
Im Folgenden die ersten zwei Hauptabschnitt der Spielrunde, hintendran kommen noch Wärmephase, wo die Werte der Bewegung verrechnet werden und die Kampfphase:

Initiativphase (IPh)
Partei 1: W6-Wurf1
Partei 2: W6-Wurf2
W6-Wurf1 < W6Wurf2
Partei 2 hat die Initiative
Andernfalls:
Partei 1 hat die Initiative;
Initiativpartei verfügt
über die gesamte Runde (InPh,BePh,WäPh,KaPh) über die Initiative.
Bewegungsphase (BePh)
Nichtinitativpartei: Entscheidet, welcher Mech wie bewegt werden soll. Bewegung wird ausgeführt.
Initiativpartei: Entscheidet, welcher Mech wie bewegt werden soll. Bewegung wird ausgeführt.
Hin- und herwechseln, bis alle Mechs bewegt wurden.
Eine der Parteien hat 2x/3x so viele Mechs wie die andere: Es werden beim Bewegen statt einem Mech 2/3 Mechs bewegt. Daraus folgt, dass Initiativpartei stets den letzten Mech bewegt.
Mögliche Bewegungsarten
Stehen
Mech bleibt in Hexfeld stehen, in welchem er die Runde begonnen hat und verändert auch nicht die Ausrichtung;
Daraus folgt:
Wärme bleibt gleich.
Bewegungspunkte bleiben gleich.
Gehen
Mech kann direkt vorwärts/direkt rückwärts gehen.
Mech muss erst Ausrichtung in entsprechende Richtung ändern, bevor er das Feld betreten kann.
Ausrichtung und Gehschritte können beliebig kombiniert werden.
Vorwärts können bis zu 2 Höhenlevel über/unterschritten werden.
Rückwärts kann kein Höhenlevel über/unterschritten werden.
Daraus folgt:
Wärme: +1 pro Runde
Bewegungspunkte:
-1 pro Gelände-Hexfeld/Ausrichtungsänderung
-2 pro Unwegsam-Hexfeld
-2 pro Lichter Wald-Hexfeld
-3 pro Dichter Wald
-2 pro Wasser (Tiefenlevel1)-Hexfeld
-4 pro Wasser (Tiefenlevel2-Hexfeld)
Höhenunterschied -2 pro Level
Ausrichtungsveränderung -1 pro Feldseite
Zu Boden werfen -1
Aufstehen -2
Laufen
Bewegungspunkte*1,5
Mech kann nur vorwärts laufen, klettern oder Ausrichtung ändern.
Mech kann nicht mehr als 2 Höhenlevel über/unterschreiten.
Daraus folgt:
Wärme: +2 pro Runde
Bewegungspunkte: wie beim Gehen
Springen
Nur Möglich, wenn Sprungdüsen vorhanden.
Mech kann beliebiges Hexfeld in Reichweite besetzen.
Mech kann Ausrichtung beliebig festsetzen.
Mech kann keinen positiven Höhenunterschied überwinden, der seine Sprungreichweite überschreitet.
Daraus folgt:
Wärme: +1 pro Feld; mindestens +3 pro Runde

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

4

22.12.2011, 16:08

Willkommen im Forum:)
Ich kannte das Spiel überhaupt nicht. Habe grad mal ein wenig bei Google geschaut und muss sagen, dass mein Interesse geweckt wurde. Werde mir gleich mal BattleMek angucken, da es wohl eine gut umgesetzte Version des Spiels zu sein scheint. Auf die schnelle kann ich mir das Brettspiel sonst nicht ansehen;)
Deine Idee hört sich ganz gut an. Missionen einzubauen erscheint sich als sinnvoll. Übernimm dich mit dem Projekt nur nicht. Alles in allem, würde ich es als nicht zu komplex ansehen. Das Problem was ich dabei jedoch sehe, ist der große Umfang. Auch wenn die Aktionen und Features als einzelnes vielleicht nicht sonderlich komplex zu sein scheinen, macht es die Sache im Ganzen jedoch nicht einfacher. Versuch alles in kleinen Schritten umzusetzen.
Ich habe wie gesagt noch nicht viel Ahnung vom Spiel selbst, von daher berichtige mich, wenn ich jetzt Quatsch erzähle;)
Versuche vielleicht zuerst die Spieler umzusetzen, wenn die soweit funktionsfähig sind, dann kannst du dich an die Mechs begeben. Aber auch hier nicht direkt alles umsetzen, sondern Aktion für Aktion. Du kannst ja zuerst gucken, dass man Mechs kaufen kann. Dann könntest du gucken wie du die Bewegung von Mechs umsetzt. Wenn die Bewegung funktioniert nimmst du dir das nächste. Wenn dann alle Aktionen soweit funktionieren, fügst du alles zusammen. Baust quasi den richtigen Ablauf ein. Vor allem als Anfänger versucht man oft alles direkt "richtig" zu machen. Dabei übernimmt man sich aber oft, und wechselt viel zwischen den Themen. Lieber erst mal Funktionen fertig stellen. Dann die nächsten und dann alles zusammen klatschen.
Du musst das Spiel ja auch vielleicht nicht direkt mit vollem Funktionsumfang fertigstellen. Es scheint ja sehr viel zu geben, was sich auf das Spiel auswirkt, zum Beispiel Wärme etc. Guck doch, was du davon am Anfang alles vernachlässigst. Lass einfach erst mal so viel wie möglich weg. Mit der Umsetzung weniger Dinge wirst du schon genug zu tun haben.
Wenn dann das Grundgerüst steht und funktioniert, kannst du dann nach und nach immer mehr Features einbauen. Alles kann man am Anfang oft eh nicht bedenken, von daher sind nachträgliche Arbeiten eh oft ein muss.

Naja die Fragen zu den Themen die du behandelt haben solltest ist so eine Sache. Du musst dir die Frage Stellen was du willst. Da du schon C++ kennst, vermute ich, dass du gern bei der Sprache bleiben möchtest. Guck dir vielleicht mal folgenden Artikel aus unserem Wiki an Spiele_programmieren_lernen
Hier wird unter anderem auch auf verschiedene Sprachen eingegangen.
Klassen solltest du bei so einer Größe von Projekt schon gut kennen. Mach vielleicht ein oder zwei kleine Testspiele vorher um alles noch mal zu verinnerlichen. Auch Vererbung etc sollten dir bekannt sein. Was du davon alles brauchst ist natürlich dir überlassen, jedoch stecken dahinter Konzepte, die einem wenn man sie richtig einzusetzen weiß, wirklich helfen können. Wenn du bei C++ bleibst sollten Zeiger und Referenzen keine Fremdwörter sein. Damit solltest du vernünftig umgehen können und wissen was sie tun und wie du damit umgehst.
Die STL bzw Standard Bibliothek von C++ sollten dir auch bekannt sein. Dadurch stehen dir Datenstrukturen wie Listen und dynamische Arrays zur Verfügung. Außerdem bietet sie dir eine Zahl von Algorithmen smart Pointer und und und.
Dann gibts noch die Templates. Ob man die jetzt braucht oder nicht sei erst mal dahin gestellt. Ich denke du wirst dein Projekt auch gut ohne bewerkstelligen. Trotzdem lohnt es sich aber dort mal reinzugucken. Vor allem deren Verwendung sollte dir bekannt sein, wenn du auf andere Bibliotheken zugreifst.
Das hört sich jetzt erst mal nach viel an, ist es aber auch;) Du sagtest, du hättest schon mehrere Bücher und Tutorials durchgearbeitet. Leg dir am besten immer ein Buch als Nachschlagewerk daneben. Und wie gesagt, versuch vielleicht erst mal ein oder zwei kleinere Testspiele.
Für die grafische Ausgabe könntest du dir mal SFML anschauen. Damit ist es nicht besonders schwer 2D Spiele zu erstellen. Ich wüsste spontan nicht, wie ich das Spiel als "Konsolen"-Spiel umsetzen sollte und ASCII Karten auszugeben muss auch nicht unbedingt einfach sein;)
Naja wie du schon siehst gibt es noch viel zu tun. Guck vielleicht erst mal den oben genannten Wikiartikel an und lass dir alles in Ruhe durch den Kopf gehen.
Bin schon gespannt wie es mit dem Projekt weiter geht:)
Viel Erfolg.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

5

22.12.2011, 16:38

Hallo!

Erst einmal vielen Dank für deine ausführliche Antwort!

Was ich an dem Spiel hervorragend finde: Das Spielkonzept ist selber in verschiedene Komplexitätsstufen unterteilt. Der schwierigste Modus geht dann viel weiter ins Detail, hier könne Mechs sogar schlagen, treten, stoßen, rammen, die Wärmeentwicklung kann zu internen Monitionsexplosionen führen, vorübergehende Stilllegung des Reaktors usw. Ich habe mir die einfachste Stufe erstmal überlegt, die ist schon lang genug und umfasst vergleichsweise einfache Handlungen (Z.B. sind Torsodrehungen hier gar nicht möglich). Die Umsetzung BattleMek kenne ich gar nicht, ich weiß noch nicht, ob ich sie mir anschaue, ich würde gerne erstmal meine Ideen versuchen durchzusetzen. Wenn ich einen nennenswerten Fortschritt habe, werde ich vielleicht mal reinschauen, um mich zu orientieren oder weiterzuentwickeln.

Wer sich für Battletech interessiert, dem kann ich Mechwarrior 1 ans Herz legen. Das war noch sehr simpel und für damalige Verhältnisse spektakulär :) Auch die Nachfolger machen Spaß, wenn man solche Videospiele überhaupt mag. Es stand anfangs nicht die Action-Komponente im Vordergrund, sondern mehr die Umsetzung der Simulation.

Nun aber zurück zu meiner Idee: Ich halte die angegebenen Werte im Spiel für Computerprogramm-geeignet. Ich selbst habe das Spiel vor einigen Jahren mal gespielt, der große Nachteil ist, dass das Spiel auf dem Tisch gespielt sehr lange dauert, weil man ständig würfeln, schauen, rechnen, schreiben muss. Übernimmt diese Dinge aber ein Programm, so glaube ich, dass es wirklich Spaß machen kann.

Ich bin momentan eigentlich erstmal nur am Spielanleitung durchschauen. Ich glaube zum Programmieren komme ich erst in einiger Zeit. Ich halte das aber für keinen schlechten Schritt, weil ich eigentlich während des Programmierens keine Zeit mehr auf das Grundkonzept verwenden will, sondern mich nur mit Problemen der Computersprache herumschlagen will, was ja der Sinn meines Vorhabens ist.

Die meisten der Begriffe, die du genannt hast, habe ich schon gelesen und auch versucht zu verstehen. Da ich aber erst seit kurzem mich "intensiv" mit dem Thema auseinander setze, hatte ich noch nicht die Zeit, sie wirklich zu durchdringen. Ich werde sie aber versuchen sinnvoll abzuarbeiten. Mittlerweile überlege ich auch, nicht doch auf grafikbasiert umzusteigen, das soll aber keine abgefahrenen Effekte mit einschließen, sondern einfach die Handhabung vereinfachen. Es reicht, wenn das Spiel im Endprodukt aussieht, als könnte es aus 1990 stammen ;). Ich habe in der Zwischenzeit sogar den von dir genannten Artikel durchgelesen, welchen ich sehr gut finde! Er hat mich in meinem Vorhaben eher bestärkt als entmutigt.

Ich denke, ich werde hier wieder etwas posten, wenn ich Fortschritt gemacht habe. Wer aber Vorschläge einbringen will, der sei herzlich dazu eingeladen.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

6

22.12.2011, 17:04

Wie gesagt, halte deine Iterationsschritte klein und nimm dir einfach nicht zu viel vor. Auch diese einfache Version benötigt ja schon sehr viele Aktionen pro Schritt, die du ja oben Beispielhaft selbst aufgeschrieben hast. Immer eins nach dem anderen. Ansonsten viel Erfolg.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

7

23.12.2011, 04:04

Zum Einstieg würde ich das gesamte Spielkonzept erstmal auf eine Grundbasis kürzen und zwar so, dass ein spielen noch gerade eben möglich ist.
Überlege dir dazu, was das Spiel eigentlich ausmacht (Start und Endbedingung) und welche Futures nur 'nice to have' sind aber für das Spiel nicht zwingend notwendig. Beispielsweise braucht das Spiel keine diversen Arten von unebenen Geländen. Es reicht wenn erstmal nur ein Freies Gelände vorhanden ist auf dem sich die Spielfigur bewegen kann. Auf Dinge wie die 'Missionen' kann auch erstmal komplett verzichtet werden. Natürlich fehlen so taktische Elemente des eigentlichen Spiels, das Balancing sollte dich aber erstmal nicht interessieren. Hast du erstmal die Grundbasis programmiert, kannst du solche Futures Schritt für Schritt hinzufügen.

8

15.07.2013, 16:44

Hallo!

Ich wollte mal nach langer Zeit meine Arbeit aktualisieren. Ich habe mich nun statt für C++ für Python entschieden und kann das aus Sicht eines Programmieranfängers eigentlich nur empfehlen. Python hat den Vorteil, dass man schnell Fortschritte macht und schnell etwas von der Tipparbeit sichtbar machen kann, wie man es sich ungefähr vorstellt. Nachteil weiß ich noch keinen gravierenden, vielleicht die unübliche Synthax etwa durch Einrückung, aber mir fehlt die Erfahrung, um das zu beurteilen.

Soweit kann ich leider nicht viel bieten, was man sich anschauen könnte. Aber der Stand der Arbeit ist momentan folgender:

(*) Planung der Elemente, die wirklich im Spiel enthalten sollen ist abgeschlossen
(*) Menüumgebung im groben erstellt und läuft auf minimalistischem Niveau
(*) Spieler-Klasse, Roboter-Klasse und Shop-Klasse ist erstellt
(*) Spieler-Klasse enthält: Name, verfügbares Geld, Inventar-Liste; außerdem: Methode "Hat Spieler das Item?", Methode "Hat Spieler genug geld für diesen Kauf?", Methode "Füge Item zum Inventar hinzu", Methode "kaufen", Methode "Verkaufen" sowie einige Methoden, die die Ausgabe von Werten ermöglichen, bzw. erleichtern.
(*) Shop-Klasse erbt die Eigenschaften von Spieler-Klasse und hat noch die Methode "Fülle die Shopliste auf", also wo der spieler kaufen kann.
(*) Zufallsgenerator zum Auffüllen der Roboterliste, wo der Spieler einkaufen kann ist fertig; es sind derzeit 53
Roboter
im Spiel enthalten mit minimalistischen Werten; Der Generator verteilt die Roboter auf die Liste so: 10 Stellen frei; Gauss'sche Summenformel aus 53, daraus berechnet sich die Wahrscheinlichkeit, mit der ein
Roboter
im Shop gespawnt wird. Der schwerste und teuerste
Roboter
wird mit 1/SUMME(53) erstellt, der leichteste kommt dann am häufigsten vor. Die Verteilung ist noch nicht perfekt an die Werte angepasst.

(*)
Roboter
-Klasse: Name, Tonnage, Schadenspunkte, Preis; Die speziellen Typen von Roboter erben von der
Roboter
-Klasse
(*) Außerdem noch eine Uhr, die als 2. Thread neben dem Hauptthread läuft. Die Uhr ist wichtig, um Kosten von dem Geld des Spielers abzuziehen, das ist bisher nur von der Überlegung fertig, ist aber nicht weiter schwer, Kosten entstehen aus: Gehalt der Piloten, die engagiert werden, Miete für die Robotergarage, Reparatur, Lagerplatz für Ausrüstung. (Hab noch andere Ideen, aber das hier ist alles erstmal die minimalistische Variante)
(*) Vom Konzept her habe ich auch schon Ideen für den Kampfmodus versucht umzusetzen, das hier ist aber lösgelöst vom Battletechspiel: Alles was das Programm hier tut ist, das Bild mit Farbe zu füllen. Später wird dann jedes einzelne Feld einer Klasse "Feld" entspringen und Eigenschaften wie "blockiert" "undurchsichtig" "höhenlevel" tragen. Bis jetzt lässt sich das kleine "M" in der Mitte per Pfeiltasten steuern, kann sich aber frei auf jede Position in der Karte bewegen (weil das ja letztlich nur Hintergrundfarbe ist) (Siehe Dateianhang) Nachtrag: karte wird zufällig generiert, sieht also jedesmal (wahrscheinlich) komplett anders aus.


Was jetzt langsam, aber immer mehr kommt: Das ganze in eine Menüstruktur verpacken und so, dass sich auch alles so gegenseitig beeinflusst wie es soll. Ich denke, im nächsten Monat werde ich nochmal einen großen Schritt machen können.

Gruß

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Dädalus« (19.07.2013, 13:25)


9

19.07.2013, 00:55

Die ersten Schritte im Kampfmodus sind gemacht. Die Karte besteht nun aus einzelnen Feldern mit speziellen Eigenschaften. Derzeit leider noch etwas primitiv, da jedes Feld nur wenige Eigenschaften trägt.

Die Klasse Tile trägt derzeit die Eigenschaften
Farbe
Blockiert

Kartengenerierung erfolgt so, dass zunächst festgelegt wird, welche Felder blockiert sind und anschließend anhand der Eigenschaft "blockiert" und "nicht-blockiert" die jeweilige Farbe verwendet wird (in meinem Fall grün für Gras und braun für Berg).

Nächster Schritt:
Die Spielfigur soll Höhenlevelunterschiede von 1 überwinden können. D.h. das Feld ist nur dann blockiert, wenn Spielfigur (S) im Ausgangstile (A_0) mit Höhenlevel 0 in Zieltile (A_1) mit Höhenlevel 1 will, dann ist das möglich. A_0 mit h 0 + S -> A_1 mit h 2 wäre allerdings unter den jetztigen Voraussetzungen nicht möglich.

Später tragen die Tiles noch jede Menge mehr Eigenschaften, die aber jetzt noch nicht weiter wichtig sind.
- Farbe
- Blockiert ja oder nein
- Höhe
- Modifikation auf Schussgenauigkeit ja oder nein
- Kühlung ja oder nein
- Modifikation auf Laufen (was zum Fallen führen kann)

etc.
Das wäre dann aber schon sehr fortgeschritten.

Kleine Anmerkung noch:

Mein Plan ist derzeit bis Anfang August eine Demoversion fertigzustellen, in welcher die Spielfigur bewegt werden kann, Höhenlevel überwinden kann, ein Rundensystem, begrenzte Schrittzahl pro Runde (momentan zwar unsinnig, da eh nur eine Spielfigur vorhanden). Mit anderen Worten soll das Bewegungssystem bis dahin halbwegs stehen. Anschließend dann spezielle Fälle wie Fallen etc.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Dädalus« (19.07.2013, 13:25)


BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

10

19.07.2013, 07:09

WizKids lizensiert BattleTech. Du solltest also stark darauf achten nicht die ganzen geschützten (Marken-)Namen zu kopieren.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Werbeanzeige