spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo zusammen,

mein Team und ich wollen euch unser Spieleprojekt, mit dem vorläufigen Arbeitstitel Synthetic Age, vorstellen. Eine Vorstellung des Teams und meiner Person findet Ihr weiter unten in einem eigenen Bereich. (Alle hier gezeigten Screenshots sind aus der aktuellen Spielversion entnommen.



Allgemeine Beschreibung:

Bei Synthetic Age handelt es sich um ein Echtzeitstrategiespiel das den Fokus auf taktisches Zusammenspiel im Team legt. Durch einen strategischen Basisbau und ein variables Forschungssystem steuern die Spieler die Geschicke ihres Teams, während die KI die Kontrolle über die Truppen der Spieler übernimmt. Dadurch lenkt Synthetic Age die Aufmerksamkeit weg vom klassischen Micromanagement und rückt die taktischen Entscheidungen der konkurrierenden Parteien in den Mittelpunkt des Spiels. Zusätzlich erlaubt das variable Forschungssystem eine spezialisierte Rollenverteilung im Team, die für dieses Genre völlig einzigartig ist. Die Kombination dieser Spielelemente ermöglicht ein Teamspiel, welches man ansonsten nur aus Online-Rollenspielen kennt. Jeder Spieler erschafft eine individuelle Armee, indem er seine Produktionsgebäude zielgerichtet platziert und ausbaut. Die produzierten Einheiten bewegen sich automatisch auf vordefinierten Pfaden auf die Stützpunkte des Feindes zu um diese zu zerstören. Die Kontrolle über Checkpoints auf diesen Pfaden gewähren Ressourcen und Vorteile für das eigene Team. Doch dies stellt nur die grundlegenden Elemente des Spiels dar. Die Sabotage feindlicher Einheiten und Gebäude, die Verstärkung der Verteidigung oder die Erhöhung der Teamressourcen sind nur einige wenige Beispiele wie man das eigene Team durch spezialisiertes Forschen und Bauen weiter unterstützen kann.







Story (Kurzfassung):

Die menschliche Spezies wurde durch eine außerirdische Invasion ausgerottet. Als den Menschen klar wurde, dass sie den Kampf verlieren würden, erschufen sie KI's die sie in unterirdischen Anlagen einschlossen. Dort sollten Sie nun solange ruhen, bis sich die Invasoren vom Planeten zurückgezogen hatten. Dieser Tag ist nun gekommen und der Spieler schlüpft in die Rolle einer dieser KI's, die nun im Wettstreit um Ressourcen mit den anderen konkurriert, um die menschliche Spezies wiederzubeleben.

Innovatives und Besonderes:

Die Kombination aus Setting, Spielprinzip und Grafikstil empfinden wir bereits als innovativ, es gibt jedoch noch kleinere und größere Dinge die unser Spiel weiter auszeichnen werden.

• Die Kombination verschiedener Spielegenres und die Verwendung gängiger Mechaniken auf neuartige Weise erzeugt ein einzigartiges Spielerlebnis.
  
• Ein umfangreiches Forschungssystem, zahlreiche Gebäude und viele verschiedene Einheitentypen schaffen eine enorme taktische Vielfalt
  
• Jeder dieser Einheitentypen erhält verschiedene optische Upgrademöglichkeiten. Das ergibt dutzende Einheitenkonstellationen, wodurch jeder Spieler seine Einheiten dem eigenen Spielstil anpassen kann.
  

• Eine persönlich anpassbare GUI und ein optisch veränderbares Hauptgebäude sorgen für ein individuelles Spielgefühl.
  
• Voll animierter Produktionszyklus von Einheiten (Kein plötzliches aufploppen neben dem Produktionsgebäude).
  

Technisches:

Tools:

• Das Spiel wird mit der Visual Studio 2013 Community Edition entwickelt
  
• Für den zugehörigen MapEditor wurde XNA + Windows Forms benutzt.
  
• Für die Spielentwicklung verwenden wir Monogame als Engine.
  
• Als Netzwerkbibliothek wird Lidgren verwendet.
  
• Für die Grafikerstellung wird Blender, 3d-Coat und CrazyBump eingesetzt.
  
• Verschiedene Programme werden für die Grafiknachbearbeitung benutzt. Spritesheetpacker, gimp und paint.net.
  

Wissenswertes:

• Es handelt sich um ein isometrisches 2D Spiel.
  
• Eine Einheit + Upgrades besteht aus bis zu 6144 einzelnen Grafiken, wobei eine Grafik aus 256 x 256 Pixeln besteht.
  
• Die Grafiken werden zu Spritesheets zusammengefasst, was bis zu 100 Bilder pro Einheit ergibt.
  
• Es stecken bisher ca. 2000 Stunden an Arbeit in dem Projekt.
  
• Es wurde bisher 1 ½ Jahre an dem Spiel gearbeitet. Geschätzter Aufwand beläuft sich auf insgesamt ca. 5 Jahre.
  
• Die Zielplattform wird zunächst Windows sein.
  

Detaillierte Beschreibung:

• Die einzige Ressource im Spiel ist Energie.
  
• Es gibt keine unterschiedlichen Parteien. Jeder Spieler kann alles bauen und forschen.
  
• Es wird mehrere Tutorial Missionen geben.
  
• Eine Einzelspielerkampagne ist geplant, jedoch liegt das Hauptaugenmerk auf dem Multiplayer.
  
• Uns ist ein schönes Ambiente sehr wichtig. Es wird animiertes Wasser, zufällige optische Ereignisse wie Vulkanausbrüche und vorbeiziehende Wolkenschatten geben.
  

Gebäude:

• Geplant sind 30 – 50 verschiedene Gebäude im Spiel.
  
• Die Gebäude werden in 5 Kategorien unterteilt.
  
  Hauptgebäude:
  
  • Wird dieses Gebäude vom Gegner zerstört, scheidet man aus dem Spiel aus.
    
  • Das Hauptgebäude kann man wie in anderen RTS üblich, ab einem gewissen Forschungsstand zur nächsten Stufe ausbauen, sodass neue Forschungen und Gebäudetypen freigeschaltet werden.
    
  Verteidigungsgebäude:
  
  • Beschützen die Eingänge zur eigenen Basis
    
  • Sind nicht vom Spieler baubar.
    
  • Können vom Spieler aufgerüstet werden
    
    • Man erhält ein komplett neues Gebäude (Bsp: Bunker wird zum Turm)
      
    • Das Gebäude wird verbessert. (Bsp: Auf Bunker wird Flak montiert).
      
  Zivile Gebäude:
  
  • Sehr unterschiedliche Effekte pro Gebäudetyp. Ein paar Beispiele:
    
    1. Erhöhung des Einheitenlimits
       
    2. Forschungsgebäude
       
    3. Bonusressourcen wenn man eine bestimmte Route hält
       
    4. Energiespeicher der auf die aktuelle Energiemenge x % rauf addiert.
       
  Produktionsgebäude:
  
  • Produziert Einheiten
    
  • Zu produzierende Einheiten können über kleinere Upgrades aufgerüstet werden.
    
  • Gebäude kann zu neuem Einheitentyp aufgerüstet werden. Bisher erworbene kleinere Upgrades gehen daraufhin verloren.
    
  Aliengebäude:
  
  • Im Spiel einzigartiges Gebäude das starke Vorteile bringt. Beispiele: Alle Einheiten machen mehr Schaden, alle x Sekunden wird eine Einheit geheilt, alle Bonusressourcengebäude einer Route gewähren x % mehr Bonus etc..
    
  • Hat ein Spieler ein solches Gebäude fertiggestellt, steht dieses Gebäude keinem anderen Spieler mehr zur Verfügung.
    

Einheiten:

• Einheiten haben verschiedene Attribute die man aus anderen RTS kennt. Leben, Rüstung, Angriffsgeschwindigkeit, Fernkampfreichweite, Ausweichchance, Supportaura, Schadensreflexion etc.
  
• Einheiten werden einer von 3 Kategorien zugeordnet
  
  1. Lebend: Anfällig gegen Feuerschaden
     
  2. Hybrid: Keine Nachteile, aber schwerer zu erreichen durch Forschungen.
     
  3. Mechanisch: Anfällig gegen Schockschaden
     
     Externes
     Originalbild
     anzeigen
     (Link)
     
     
• Es wird Boden und Flugeinheiten geben. Nicht jede Einheit wird jede angreifen können. (Nahkämpfer können keine Flugeinheiten angreifen).
  
• An einer Einheit können verschiedene Waffensysteme hängen, die in einem Angriffsintervall nacheinander abgefeuert werden. Die Einheit „Mech“ bspw. hat 2 Geschütze am Bauch, einen Flammenwerfer am Arm und eine Minigun.
  
• Die einzelnen Waffen müssen in der Regel erst durch Upgrades freigeschaltet werden. Die Einheit erhält dann entweder ein komplett neues Aussehen oder die Kampfanimationen werden ersetzt.
  
  Externes
  Originalbild
  anzeigen
  (Link)
  
  
• Die einzelnen Waffensysteme besitzen verschiedene Effekte:
  
  • Heilung: Heilt Verbündete anstatt Schaden zu machen.
    
  • Feuer: Macht zusätzlichen Schaden an lebenden Einheiten
    
  • Schock: Macht zusätzlichen Schaden an mechanischen Einheiten
    
  • Gefrierend: Reduziert Angriffsgeschwindigkeit vom Gegner
    
  • Flächenschaden: Waffe macht in einem Umkreis bei allen Einheiten Schaden.
    
  • Rüstungsdurchdringung: Ein Teil der Rüstung wird ignoriert.
    
  • Gebäudevernichtung: Mehr Schaden an Gebäuden, weniger an Einheiten.
    

Forschung:

• Es wird einen komplexen Forschungsbaum geben (Größenordnung 50 – 100 Forschungen)
  
• Der Spieler wird der Art seiner Armee durch Forschungen eine Richtung geben können. Beispiele:
  
  1. Starke Spezialisierung, sodass die stärksten lebenden Einheiten erstellt werden können. Die eigene Armee kann durch Aliengebäude verstärkt werden, die ausschließlich lebende Einheiten verbessern.
     
  2. Möglichst alles forschen um die besonders starken Hybriden zu erhalten.
     

Beispielpartie:

Es spielen 2 Teams á 3 Spieler gegeneinander. Jeder Spieler hat einen direkten Gegenspieler, eine eigene Basis und eine Route für die er zuständig ist. Nun gibt es verschiedene Ansätze wie das eigene Team vorgehen kann.

1. Jeder Spieler versucht seine eigene Route einzunehmen und zu halten. Was auf den anderen Routen passiert ist dem einzelnen egal.
   
2. 2 Spieler konzentrieren sich darauf ihre Route zu halten, der 3te versucht möglichst schnell zu forschen und viel Geld anzusammeln. Das Team konzentriert sich auf eine spezielle Route und diese soll unter allen Umständen gehalten werden. Der Supportspieler unterstützt die beiden anderen Spieler.
   
   Typische Spielsituation:
   
   Einer von 3 vordefinierten Pfaden ist stark umkämpft und die Armee der zuständigen Spielers wird immer weiter zurückgedrängt. Ein Teammitglied, das sich darauf spezialisiert hat viele Ressourcen anzusammeln und schnell zu forschen, entschließt sich dazu ein einzigartiges Gebäude zu bauen. Dieses Gebäude verbessert die Kampfkraft aller Einheiten des eigenen Teams. Zusätzlich baut dieser ein Produktionsgebäude, für eine sehr fortschrittliche Einheit, in der Basis des verbündeten Spielers in Not. Der Feind wird zurückgedrängt und der Pfad kann von der eigenen Seite gehalten werden.
   

Vorteile des Spielprinzips für die Entwicklung:

Das genannte Spielprinzip umgeht einige große Probleme der Entwicklung eines typischen RTS und bietet einige tolle Optionen für die Zukunft.

• Es ist schwierig für Tablets und Smartphones ein RTS zu entwickeln, aufgrund der hackeligen Einheitensteuerung ohne Maus. Das Problem hat man bei diesem Spielprinzip nicht, da man nur Bauplätze auswählt oder Forschungen und Upgrades anklickt.
  
• Es gibt keine zeitkritischen Updates, die übers Netzwerk übertragen werden müssen. Z.B. dauert der Bau eines Gebäudes in einem RTS einige Sekunden. Somit hat die Nachricht ein paar Sekunden Zeit anzukommen.
  
• Wenn man die selbe Bau- und Forschungsreihenfolge ungefähr zur selben Zeit einhält, passiert frame-genau immer das selbe. Dadurch ist das Spiel eine einzige riesige Debugversion was die Arbeit enorm erleichtert.
  
• Da die Einheiten festgelegten Routen folgen, gibt es keine riesigen Pfade vom einen Ende der Karte bis zum anderen. Die Wegfindung ist somit recht performant. Obwohl die Wegfindung da durch einfacher zu implementieren ist, ist dieses Thema immer noch extrem schwer umzusetzen und wir wären daran schon einige male fast gescheitert.
  

Aktueller Stand:

• Fertige spielbare Version mit allen Grundfunktionalitäten vorhanden (Gebäudebau, Upgrades, Kampf etc.)
  
• Die Grafikerstellung geht gut vor ran und durch den immer größer werdenden Erfahrungsschatz, werden wir immer schneller. Es sind bereits 6 Einheiten komplett fertig (modelliert, texturiert und animiert). 10 weitere Einheiten sind bereits zum Teil fertig.
  
• Es gibt zu allen weiteren Grafikkategorien (Gebäude, Bodentexturen und Objekte wie z.B. Berge) fertige Grafiken die bereits im Spiel implementiert sind. Für dieses Vorgehen haben wir uns entschieden, da wir sehen wollten ob wir einen einheitlichen Grafikstil erreichen können.
  
• Da wir uns in einem Programmiererforum befinden, werde ich den komplizierten Themen in diesem Thread einen eigenen Post widmen. Die Einheiten-KI - für mehrere hundert Einheiten gleichzeitig - hat mir z.B. sehr viele schlaflose Nächte bereitet.
  

Historisches:

Kurz zu meiner Person. Mein Name ist Stefan, ich bin 31 Jahre alt und der Ideengeber des Projekts. Beruflich bin ich in der internen Softwareentwicklung tätig. Anfang 2014 habe ich mich dazu entschieden in meiner Freizeit Spiele zu entwickeln. Zu diesem Zeitpunkt hatte ich noch keine konkrete Idee und war noch als Einzelkämpfer unterwegs. Nachdem ich eine kleine Gameengine entwickelt hatte, lernte ich XNA und programmierte dann einige kleine Spiele (Candy Crush Clon, 2d top down Spaceshooter). Ein ehemaliger Arbeitskollege und guter Freund fand das ganze so spannend, das er zusammen mit mir ein Spieleprojekt starten wollte. Mir ist dann nach kurzer Zeit die Idee gekommen meine Lieblingsmod Civilization Wars für Warcraft III, die ich immer noch spiele und liebe, in neuem Gewand umzusetzen. So begann die Arbeit am MapEditor zum Spiel. Ich war bis 3 Monate nach Projektbeginn nicht nur für einen Teil der Programmierung, sondern auch für die Grafikerstellung zuständig. (Die gesammelte Erfahrung in diesem Bereich ist jetzt sehr hilfreich). Ich merkte sehr schnell, dass die beiden Dinge, wenn man sie vernünftig machen will, für eine Person zu viel sind. Darum fragte ich einen weiteren guten Freund von mir, ob er mir nicht bei der Grafikerstellung mit kleineren Tätigkeiten helfen möchte. Eigentlich habe ich nicht viel erwartet, da mein Bekannter genau wie ich keine Erfahrung in der Grafikerstellung hatte. Dieser hat mir dann aber nach 1 Woche ein Model von einer Einheit geliefert, das mich einfach aus den Socken gehauen hat. So ist das jetzige Team entstanden und wir sind alle nach 1 ½ Jahren weiterhin mit Feuer und Flamme dabei :-)

Das Team
Stefan: Ideengeber, Programmierung der Spielelogik, 2D Grafik Nachbearbeitung, PR
Marko: Grafikerstellung
Sebastian: Netzwerkinfrastruktur, Netzwerkprogrammierung, Programmierung kleinerer Tools die für die Entwicklung benötigt werden.

• Gamedesign und Story entwickeln wir zusammen
  
• Wir sind alle fest angestellt und arbeiten nur in unserer Freizeit an dem Projekt
  
• Alle 2 Wochen machen wir eine Teamsitzung per Teamviewer
  

Abschlusswort:

Es ist noch sehr viel zu tun. Die Entwicklung eines Multiplayer RTS ist in so einem kleinen Team ohne Erfahrung wirklich ein ambitioniertes Unterfangen. Es ist jedoch nicht unmöglich. Wir haben mittlerweile einen Stand erreicht, bei dem ich mir sicher bin, das wir ein sehr schönes Spiel fertigstellen und veröffentlichen werden. Wir würden uns sehr über Meinungen, Kritik und Fragen eurerseits freuen. Besonders interessiert wären wir an ähnlichen Spielen, egal ob es sich um Mods oder Standalone Versionen handelt, die ihr bereits gespielt habt. Obwohl ich sehr viel zocke sind mir solche Spiele kaum bekannt.

Erst mal vielen Dank für die netten Worte.
Ein Gameplay Video ist fest eingeplant, folgt aber später da wir im Spiel viele Platzhalter Grafiken verwenden, die aus größeren Spielen entwendet wurden.
Z.B. ist das persönlich anpassbare Interface fertig programmiert, kann aber noch nicht gezeigt werden.
Danke für den Link. Castle Fight kannte ich vom Namen her bereits, habe ich aber selber nie gespielt.

Wie schon im ersten Post angesprochen, möchte ich diesen Thread nicht nur dafür nutzen um das Spiel an sich vorzustellen, sondern auch um die programmiertechnischen Hürden bei der Entwicklung eines RTS genauer zu beleuchten, auf die wir gestoßen sind. Anfangen möchte ich mit dem von uns geschriebenem System zur Wegfindung und Kollisionserkennung. In anderen Genres ist eine automatische Wegfindung zwar auch keine triviale Sache, jedoch wird es bei einem RTS, wenn dutzende von Einheiten zum selben Ziel wollen, recht tricky.

Grundlegende Dinge die ich während der Entwicklung gelernt habe:

• Ich habe nach einiger Zeit festgestellt das ich rein durch Tutorials im Internet nicht weiter komme. Es gibt einfach zu viele Möglichkeiten um an das Thema ran zugehen, daher kaufte ich mir das BuchArtificial Intelligence for Games. Das Buch hat mir sehr geholfen neue Denkansätze für meine Problemstellungen zu entwickeln.
  
• KISS wurde für mich während der Entwicklung äußerst hilfreich. Ich habe 2 mal gegen dieses Prinzip verstoßen und es hat mich ungefähr einen Monat zurück geworfen
  
• Mathematisch korrekte Formeln habe ich zu Beginn überbewertet. Wichtig ist das sich das Gesamtergebnis natürlich anfühlt.
  
• Ich dachte bei den leistungsstarken Rechnern heutzutage ist Performance bei einem 2D Spiel nicht mehr besonders wichtig. Die Entwicklung der Wegfindung / Kollisionserkennung hat mich eines Besseren belehrt.
  

Wegfindung:

Als Grundlage für die Wegfindung wird eine TileMap verwendet, wobei jedes Tile die Eigenschaft besitzt, ob sie blockiert ist. Je nachdem auf welchem Bauplatz das Produktionsgebäude der Einheit gebaut wurde, folgen die Einheiten unterschiedlichen Wegpunkten. Das sorgt dafür das die Einheiten einer festen Formation folgen. Sobald das erste Mal gekämpft wurde, wird die Formation aufgelöst und die Einheiten versuchen nun schnellst möglich zur gegnerischen Basis zu gelangen.

Ich verwende für die Wegfindung eine selbstgeschrieben Variante eines SpaceTime A* Algorithmus. Ich habe schmerzlich festgestellt das eine Implementierung eines reinen A* Algorithmus bei mehr als 10 Einheiten extrem bescheuert aussieht. Das liegt daran das die Wegfindung zwar den perfekten Weg zum Ziel ermittelt, sie berücksichtigt jedoch nicht ob zum Beispiel freundlich gesinnte Einheiten den Weg kreuzen werden.

Um das Ganze einmal bildlich auszudrücken:
Die Mitarbeiter in einem Büro sollen sich einen Platz in einem Büro aussuchen. Nachdem Sie das getan haben werden jedem einzelnen die Augen verbunden und die einzelnen Mitarbeiter sollen sich nun zu ihrem ausgesuchten Platz begeben. Mit 2 Mann mag das funktionieren, mit 20 Mann gibt es ein komplettes Chaos.

Der SpaceTime A* sorgt nun dafür das den Einheiten die Augenbinde abgenommen wird, da eine weitere Ebene und zwar die Zeit bei der Wegfindung berücksichtigt wird. Es kann mit dem von uns geschriebenem System für jede Einheit frame-genau bestimmt werden, zu welchem Zeitpunkt sie sich an welchem Ort befindet. Auf den ersten Blick wirkte das Ganze auf mich nicht sehr performant, jedoch kollidieren die Einheiten da durch kaum noch miteinander. Der Weg muss nun selten korrigiert werden, das führt zu einer Performanceverbesserung. Das ist nur einer von vielen Vorteilen dieses Systems.

Probleme während der Entwicklung:

1. Die ver....... Heuristik:
   Entscheidet man sich dafür eine isometrische TileMap für sein 2D Spiel zu verwenden, gibt es 2 Arten von Tutorials, die ihr zum Aufbau einer TileMap im Internet finden werdet.
   
   
   1. Diese Tutorials bauen auf einem Koordinatensystem auf, welches folgendermaßen aussieht. (Rotated Diamond isometric)
      
      Externes
      Originalbild
      anzeigen
      (Link)
      
      Age of Empires verwendet beispielsweise so eine rautenartige Karte. Hierbei wird eine quadratische Karte einfach der Perspektive entsprechend gedreht und kann mit einer Formel recht einfach wieder in den Ursprung transformiert werden. Es funktionieren mit der transformierten Karte die üblichen Heuristiken ganz normal z.B. die Manhattendistanz etc..
      
      
   2. Die anderen Tutorials setzen auf folgendes Koordinatensystem, für das auch ich mich entschieden habe. (straight row isometric)
      
      Externes
      Originalbild
      anzeigen
      (Link)
      
      Für diese Art des Koordinatensystems habe ich keine Verfahren zur Transformation finden oder entwickeln können. Es gibt auch keine mir bekannte Heuristik die für die Wegfindung verwendet werden kann. Es dauerte eine ganze Weile bis mir dieses Problem bewusst wurde. Die Frage nach der richtigen Heuristik für dieses Koordinatensystem wird relativ häufig im Internet gestellt. Neben Beleidigungen das man zu blöde zum Transformieren ist, habe ich aber keine Antworten auf dieses Problem gefunden. Da ich wirklich gar nichts sinnvolles zu dem Thema gefunden habe, hier ein mal der Sourcecode meiner Lösung. Vielleicht hilft er ja dem einen oder anderen.
      
      

      C#-Quelltext

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

      public float GetIsometricDistancePoints(Point firstPoint, Point secondPoint) { Point tmpPoint = new Point(); if (firstPoint.Y > secondPoint.Y || (firstPoint.Y == secondPoint.Y && firstPoint.X > secondPoint.X)) { tmpPoint = secondPoint; secondPoint = firstPoint; firstPoint = tmpPoint; } tmpPoint = firstPoint; float diffx = Math.Abs(firstPoint.X - secondPoint.X); float diffy = Math.Abs(firstPoint.Y - secondPoint.Y); float distance = 0; while (diffy > 0) { if (diffx > 0 && diffy > 0 && ((tmpPoint.Y % 2 == 0 && firstPoint.X > secondPoint.X) || (tmpPoint.Y % 2 != 0 && firstPoint.X < secondPoint.X))) { distance += 1; diffy -= 1; diffx -= 1; tmpPoint.Y += 1; tmpPoint.X += 1; } else if (!(diffx == 0 && diffy % 2 == 0) && ((diffx == 0 && diffy % 2 != 0) || (tmpPoint.Y % 2 != 0 && firstPoint.X > secondPoint.X) || (tmpPoint.Y % 2 == 0 && firstPoint.X < secondPoint.X))) { distance += 1; diffy -= 1; tmpPoint.Y += 1; } else { break; } } //CostStraight = Wurzel 2 distance += (diffy / 2 + diffx) * PathFinder.CostStraight; return distance; }

      
      
2. Das richtige Ziel:
   
   Eins der Hauptprobleme warum sich Einheiten in unserem Spiel total bescheuert verhalten haben, lag in der Bestimmung des Zielpunkts der Wegfindung. Im Kreis laufende, sich überlappende oder sich vom Ziel entfernende Einheiten waren zum Großteil auf eine falsche Zielermittlung zurück zu führen. Hier mal ein paar Beispiele für verschiedene Problemstellungen, die nicht auf den ersten Blick ersichtlich waren und die einer speziellen Lösung bedurften.
   
   
   1. 2 verfeindete Einheiten haben sich gegenseitig als Ziel ermittelt:
      Eigentlich recht simpel. Es musste jedoch gewährleistet werden, dass während der Bewegung der Einheiten, sich die Mitte zwischen den beiden nicht anpasst, ansonsten begannen die Einheiten beispielsweise im Zick Zack zu laufen.
      
   2. 2 Gegner stehen als Ziel zur Auswahl:
      Sinnvoll ist es den Gegner zu wählen, der die kürzeste Entfernung zur Einheit hat. In den meisten Fällen funktionierte das super, es kam jedoch in seltenen Fällen zu einer Endlosschleife. Bewegte sich die Einheit auf dem Weg ein Feld weiter, konnte es passieren das der andere Gegner nun näher dran war und der kürzeste Weg zu ihm, führte in die entgegen gesetzte Richtung.
      
   3. Die ausgewählte feindliche Zieleinheit hat eine andere verbündete Einheit als Ziel:
      Dieser Fall bot das meiste Fehlerpotenzial. In den meisten Fällen war das Ziel der Wegfindung der gegnerischen Einheit auch als Ziel der Wegfindung sinnvoll, da sich die beiden Einheiten dann am Endpunkt oder früher trafen. Häufig kam es dabei jedoch zu schwachsinnigen Entscheidungen. Hier eine schwierig zu ermittelnde Fehlerquelle: Um zu einer verbündeten Einheit zu gelangen, um diese angreifen zu können, muss eine feindliche Einheit um ein Kampfgetümmel herum laufen, da ihre verbündeten Einheiten im Weg stehen. Werden die Feinde im Kampfgetümmel nun vernichtet, wird diese Einheit als neues Ziel für die eigenen Einheiten ausgewählt. Da ihr Weg sie jedoch um das Kampfgetümmel herum führt, liegt ihr Ziel hinter den eigenen Einheiten. Somit bewegen sich diese kurzzeitig in die falsche Richtung, um dann wieder umzudrehen und auf den Gegner zuzulaufen. (Gott wie habe ich diesen Fehler gehasst ).
      
   4. Füge hier einen von weiteren 100 Sonderfällen ein.
      
   
   

Durchgeführte Performanceverbesserungen:

• Die Wegfindung wird so selten wie möglich aufgerufen.
  
• Wenn das Ziel der Wegfindung nicht erreicht werden kann, weil es blockiert ist, durchläuft ein A* normalerweise jeden einzelnen Punkt einer TileMap. Je nach Größe der Karte kann dann ein Durchlauf schon mal ein paar Sekunden dauern. Wir haben eine sinnvolle Abbruchbedingung eingebaut.
  
• Wenn die Wegfindung erneut aufgerufen wird und das Ziel ist immer noch das selbe, wird überprüft ob der alte Pfad weiterhin begehbar ist. wir sparen uns so einen erneuten Durchlauf der Wegfindung.
  
• Für Fernkampfeinheiten wird die Wegfindung nur solange durchgeführt, bis sie in Fernkampfreichweite gelangen.
  

Kollisionserkennung:

War für uns eigentlich nicht weiter schwierig und es gibt hunderte Tutorials zu diesem Thema. Hier trotzdem ein paar Fakten zu unserem System:

• In einem extra Thread werden die Kollisionen der Einheiten / Gebäude untereinander ermittelt.
  
• Zu Kollisionen zählen beispielsweise:
  
  1. Gegner ist in Fernkampfreichweite
     
  2. 2 Einheiten eines Teams kollidieren untereinander
     
  3. Gegnerische Einheit tritt in Sichtradius
     
• Wir verwenden Quadtress um eine vernünftige Performance zu gewährleisten
  

Probleme:

• Geometrische Form der Kollisionsermittlung:
  Aufgrund der Perspektive hatte ich ursprünglich vor als geometrische Form eine Ellipse für die Kollisionsermittlung zu verwenden. Man glaubt es kaum aber im Gegensatz zu einem Kreis oder Rechteck ist die Überprüfung ob sich 2 Ellipsen überlappen ziemlich schwierig umzusetzen. Nach einigem rumprobieren bin ich dann bei einer Raute hängengeblieben, die die selbe Form wie ein Tile hat. Die Raute hat den ganz großen Vorteil, dass die Einheiten sich z.B. um große Gebäude korrekt platzieren, da diese die selbe Form wie der Kollisionsradius aufweisen.
  

Kollisionsauswertung:

Im Gegensatz zur Kollisionsermittlung ist die Kollisionsauswertung, mit den daraus folgenden Konsequenzen, für uns deutlich schwerer umzusetzen gewesen. Wenn Einheiten des selben Teams miteinander kollidieren, wie kriegt man diese sinnvoll wieder auseinander? Bevor ich den SpaceTime A* eingebaut hatte, kollidierten regelmäßig sehr viele Einheiten miteinander und bildeten ein „Knäuel“, das nicht leicht zu entwirren war. Aber auch nach der vollständigen Implementierung des Wegfindungssystems, gibt es immer wieder Situationen wo ein Kollisionssystem für uns unerlässlich ist.

Das System unterscheidet zwischen 2 Arten von Kollisionen im eigenen Team und behandelt diese unterschiedlich.

1. Weiche Kollisionen:
   Kollidieren 2 sich bewegende Einheiten miteinander, werden diese durch das System zu einer Gruppe zusammen gefasst. (Stehende Einheiten die sich z.B. im Kampf befinden werden ignoriert). Es wird über verschiedene Bedingungen ein Anführer diese Gruppe ermittelt. (Rennt nicht über andere Einheiten der Gruppe, ist am schnellsten bei seinem Ziel, Position liegt nahe an der gegnerischen Basis etc.). Der Anführer der Gruppe darf sich nun auf seinem Pfad weiter bewegen, während die andere Einheit warten muss. Während darauf gewartet wird das der Anführer den Kollisionsradius verlässt, können 2 Fälle eintreten.
   
   
   1. Der Anführer verlässt den Kollisionsradius und die andere Einheit kann ihren Weg fortsetzen.
      
   2. Weitere Einheiten des eigenen Teams kollidieren mit einer der beiden Einheiten, bevor sich die Kollision auflösen kann. Die neuen Einheiten werden der Gruppe hinzugefügt und ihr Weg wird mit dem des alten Anführers verglichen. Evtl. wird eine der neuen Einheiten als Anführer ausgewählt und der alte Anführer muss warten. Der neue Anführer läuft darauf hin weiter. Sobald der Anführer den Kollisionsradius verlassen hat, wird ein neuer Anführer bestimmt der losläuft. Ist nur noch eine Einheit übrig hat sich die Kollision aufgelöst.
      
2. Harte Kollisionen (Sehr kleiner Kollisionsradius)
   Wenn eine harte Kollision zwischen Einheiten eines Teams auftritt, ist irgend etwas schief gelaufen und die Systeme die bis dorthin greifen sollten, haben versagt. Ein Bug der daraus resultiert ist z.B. das Einheiten sich auf die selbe Position begeben, um von dort zu schießen, sich dabei aber komplett überlappen. Es muss nun auf jeden Fall interveniert werden und einige sonstige Regeln gelten hier nicht, z.B. durch einen erneuten Aufruf der Wegfindung.
   

Probleme:
Ich habe die Kollisionsauswertung aufgrund von Performanceproblemen bereits mehrfach neu geschrieben. Das lag hauptsächlich daran, dass ich bei den alten Systemen häufig die Wegfindung mehrfach aufgerufen habe. Im neuen System habe ich die Wegfindung quasi vollständig aus der Kollisionsauswertung verbannt.

Ich hoffe ihr fandet diese kleine Einführung in unsere Wegfindung / unser Kollisionssystem interessant und wie immer würden wir uns über Meinungen, Verbesserungsvorschläge und Kritik freuen. Zum Abschluss möchte ich noch eine Nahaufnahme der Einheit „Taurus“ im vollständig aufgewertetem Modus zeigen. Die Einheiten sind in Nahaufnahme aus unserer Sicht so schön, dass wir auf jeden Fall planen mit diesen Zwischensequenzen zu erstellen. Was meint ihr dazu?

Hallo Endgegner,

das der Post von der Länge her abschrecken kann, hatte ich bereits vermutet. Mir persönlich sind ausführliche Projektvorstellungen immer lieber, als solche die zwar tolle Projekte vorstellen, bei denen man sich aber anhand der Beschreibung zusammen reimen muss, worum es eigentlich geht. Unschön finde ich auch wenn die Autoren in ihren Vorstellungen Begriffe oder Zahlen verwenden, mit denen der Leser nichts anfangen kann, weil ihm die Zusammenhänge fehlen. Die Kunst einen interessanten und verständlichen Artikel zu schreiben, ist nicht einfach zu lernen. Ich habe mir auf jeden Fall für die Zukunft vorgenommen meine Posts hier im Forum kürzer zu halten und die Details mehr zu "stückeln". Das ich ein wenig von unserem Herzblut vermitteln konnte, freut mich natürlich sehr. (Grenzt bei mir teilweise schon an Fanatismus )

Die Anzahl der Grafiken sowie die Grafikerstellung finde ich selber ein sehr beunruhigendes Thema. Unser Grafiker arbeitet jedoch fast schon mit gespenstischer Geschwindigkeit. Er liefert mittlerweile Grundeinheiten komplett animiert in 2-4 Wochen. Das der Grafikstil gefällt ist auf jeden Fall eine schöne Sache.

Die festgelegten Pfade bei der Wegfindung bringen in der Tat Vorteile, aber leider nicht so viele wie wir uns das wünschen würden. Nicht die festgelegte Pfadverfolgung ist das Problem, sondern der Kampf der einzelnen Armeen, der jedes Mal anders aussieht. Der Gedanke mit dem Flow Field ist mir auch bereits gekommen, ich habe aber keine sinnvolle Anwendung dafür finden können. Der Artikel und das Video zu Velocity Obstacles sehen sehr interessant aus und den Begriff kannte ich bisher noch gar nicht. Werde ich mir am Wochenende in Ruhe zu Gemüte führen

Das Droide geschützt ist, ist irgendwie wieder typisch. Das umgangssprachliche Begriffe geschützt werden dürfen, selbst wenn Sie durch ein bestimmtes Medium geprägt wurden, finde ich persönlich ein Unding. Wie sieht es denn mit der ausgeschriebenen Form (Androide) aus? Gilt der gleiche Schutz auch hierfür?

Hallo zusammen,

unser Team war weiterhin recht fleißig und wir sind ordentlich vorangekommen. Da die letzten Einträge ziemliche Textwände waren, möchte ich heute weniger schreiben und mehr zeigen. Die letzte Zeit haben wir viel an Spezialeffekten gebastelt. Wir als Team waren überrascht was man alles für hübsche Effekte in 2D mit den richtigen Techniken erschaffen kann.

Flammenwerfer (Wird mit einer selbst geschriebenen Partikel-Engine realisiert)





Blitze (Wurde mit Hilfe von folgendem Tutorial umgesetzt)

Einfacher Blitz:



Aufgesplitterter Blitz (Mehrere Ziele):



Laser (Kombination aus beiden Systemen)





Wir haben außerdem den Einheitentypen Arachnoid vom Aussehen her komplett überarbeitet und ihn mit allen Upgrades ins Spiel integriert.



Die Einheit ist ein typischer Fernkämpfer mit wenig Leben und viel Schaden.
Mögliche Upgrades:

1. Gefrierschuss: Verlangsamt Zieleinheit
   
2. Verbesserte Rüstung
   
3. Skorpionsschwanz 1: Extra Angriff mit 4 Einzelschüssen
   
4. Skorpionsschwanz 2: Extra Angriff mit Laser
   
5. Skorpionsschwanz 3: Extra Angriff mit Einzelblitz
   
6. Skorpionsschwanz 4: Extra Angriff mit Mehrfach Blitzeinschlag
   

Zusätzlich haben wir viel an der Webseite zum Spiel gearbeitet. Im Anhang findet ihr einmal unseren Hintergrund für die Seite. (Ist außerdem ein sehr schickes Wallpaper )

@swoerm: Danke für die positiven Worte.

@margfx:

Der dunkle Hintergrund ist nur Platzhalter und die Einheiten wie z.B. der Stier wurden bereits überarbeitet und sind nun heller. Diese befinden sich nur noch nicht im Spiel.

Das mit den riesigen Mengen an Daten hat uns vor einiger Zeit wirklich vor ein Problem gestellt. Ich hatte irgendwo gelesen das komprimierte Grafiken wie z.B. png's auf Festplatte und im Arbeitsspeicher der Grafikkarte gleich viel Speicher benötigen, was natürlich Käse ist. Bevor ich das festgestellt habe, brauchte eine Einheit trotz dxtCompression 400mb im Arbeitsspeicher. Viel zu viel....... und auch das erstellen der Grafiken fürs Spiel hat zu lange gedauert. Von daher haben wir uns einen Automatismus überlegt wie das ganze deutlich schneller geht. Hier ein mal grob der Ablauf

1. Zunächst werden die Animationen der Einheiten nacheinander in Blender gerendert und als Einzelgrafiken in speziell benannten Ordnern erstellt. (Upgrades und Einheiten sind einzelne Grafiken). Da das ganze ewig dauert, haben wir extra einen Rechner angeschafft der von morgens bis abends nur Grafiken rendert. Für den Arachnoiden lief der beispielsweise 50 Stunden.
   
2. Ein selbst geschriebenes Tool wandelt die Grafiken dann in Spritesheets um. Die freien Tools auf dem Markt wie z.B. der Spritessheetpacker sind dermaßen unkomfortabel, das dieser Schritt notwendig war. Das händische zusammenfassen hat vorher mehrere Stunden gedauert.
   
   Externes
   Originalbild
   anzeigen
   (Link)
   
   
3. Überflüssige und überlappende Schatten von Upgrades und Einheiten werden durch das Tool entfernt oder in eigene Dateien geschrieben.
   
4. Nun kam das Problem der Größe im Arbeitsspeicher. Das war eine wirklich harte Nuss. Auch hierfür musste ein weiteres Tool her. Die Spritessheets werden weiter zusammengefasst, sodass soviel Platz wie möglich ausgenutzt wird. Diese Transformation dauert ca. 10 Minuten und es entstehen je nach Einheitentyp 10 - 20 Dateien die folgendermaßen Aussehen. Eine Einheit benötigt dadurch noch 40 – 80 MB im Arbeitsspeicher.
   
   
   Externes
   Originalbild
   anzeigen
   (Link)
   .
   
5. Es wird durch das Tool eine .txt Datei erstellt deren Inhalt ich nur mit Copy Paste in den Sourcecode des Spiels einfügen muss, damit das Spiel z.B. weiß wie breit und hoch jedes einzel Bild ist. Die Bilder als Ressourcen einzufügen ist dann das geringste Übel.
   

Händischer Aufwand sind hierbei ca. 30 Minuten pro Einheit.

Da die Einheiten den Mammutanteil der Grafiken ausmachen werden wir ungefähr 2GB Arbeitsspeicher im RAM verbrauchen, wenn der Spieler HD Grafiken verwenden möchte. Es ist auch eine abgespeckte Version mit 128px pro Einheit geplant. Da benötigen wir dann noch ca. 512 MB RAM, was gleichzeitig als minimale Anforderung für die Grafikkarte geplant ist.

Videos wollen wir in der Tat mittlerweile hochladen und da kommt demnächst auch was