Hi Leute,

Ich wollte mal fragen wie ihr ein Projekt wie ein RTS angehen würdet.
Ich meine damit:

• Ordner Strukturen
  
• Scriptaufbau
  

den momentan habe ich noch keine richtige vorstellung wie ich das anstellen soll, das ich hinterher nich 10 000 inneinander verworrene Scripts habe die im endlosen raum umherschwirren.

Ich würde gerne Objekt orientiert programmieren, doch die WDL unterstützt das ja meines wissens nicht. Löst man sowas dann über DLL's oder wie machen das die erfahrenen unter euch?

Ich erhoffe mir von denen die sowas schonmal angegangen haben (*sich an "WasteLand" oder "2662" erinnert) ein par nützliche Tipps.

Viele Grüße
Shoebox

Also was soweiso immer Wichtig ist, fange nicht mit den unnützesten Sachen an...

Mache dir erstmal eine Basis von deinem Spiel, Beispiel Schiffe können bewegt werden, Gebäude aufgebaut, Ressourcen können gesammelt werden, dann kannste nach und nach immer mehr hinzufügen, wennde von allem einen Teil hast Beispiel:

Du willst das man in dem SPiel Gebäude und Panzer Bauen kann, Forschen sollte auch net Fehlen. Dann machste dir erstmal ein Dummie Model (Einfach einen Würfel den du später durch ein richtiges ersetzt) und schreibst dir den Code das du schonmal ein Gebäude bauen kannst.
Das Gleiche machste mit den Schiffen.
Dann kommste zur Forschung, beispielweise soll bei einer bestimmten Forschung der ANgriffswert der Einheiten Steigen, das machste dann auch noch rein...

Somit haettest du schonmal für den Anfang was, nach und nach kannst du dies dann erweitern, sodass man nachher 10 Gebäudearten 20 Einheitarten und 5 verschiedene Forschungsarten bauen kann...

Wennde einmal soweit sein solltest, kannste dich um die Gegner KI kümmern und dann um das Restliche Zeug...

Was dir Empfehle, mach dir eine "Header.wdl" dort kommen alle Bitmap Definitionen, Variablen, Strings usw rein, diese Inkludierste dann einfach in dein Main Script, ich hatte am Anfang keine Headder Datei, und somit wurde das alles un+übersichtlich, da ich nicht die Varialblen etc in einer Datei hatte sonder mit auf die anderen 23 Scripte verteilt...

Achja noch was: KOMMENTIER alles schön aus, ich hatte manchmal Variablen drin, dort wussete ich net mal wofür die sind,und dann geht das gesuche los und bei 23 Scripten mit mehr als 6000 Zeilen ist das kein Vergnügen...

Hoffe ich konnte dir hiernmit was weiter helfen

cYa Sebastian

Die Idee von Sebastian mit der header.wdl datei ist sehr gut.
Innerhalb dieser wdl datei solltest du allerdings auch möglich viel struktur haben, also nich alle bitmap definitionen durcheinander schreiben sondern hübsch geordnet:
hud
menu
etc.

was auch noch wichtig sein könnte:
skill bereiche!

Damit gemeint ist: Welche .wdl datei darf welche skills beliebig benutzen?

Beispiel:
In der header.wdl stehen die "globalen" skills, zb:
define health,skill1;

Nun können alle entities ihren skill1 mit "health" ansprechen.

"Lokale" skills wären nun skills die du innerhalb einer sub-wdl datei definierst und an deren ende wieder undefinierst.
Beispiel:
define weapon_type,skill20;
..
undef weapon_type;

Dies ist nützlich für skill namen die nur eine bestimmte art von entities benutzt, z.b. fahrzeuge.
Gebäude werden wahrscheinlich keinen waffen type haben, wenn ja könnte man überlegen es als globalen skill einzurichten.

Sorgfälltig solltest du auch sein wenn du festlegst welcher skill was ist.
skills die man nicht im WED setzen brauchst sollten nicht die ersten 20 skills blockieren.

A7 bzw. LiteC wird auch Strukturen bieten, was die Sache etwas einfacher macht. Letztlich ist das aber nichts zu den möglichen von oop. Ich schreib meine Engine deshalb jetzt selber. Ich denke aber schon, dass es möglich ist, ein RTS zu schreiben, da Damocles so etwas schon einmal in Angriff genommen hat. Vllt. solltest du dich mal mit ihm in Verbindung setzen.

Ich danke euch bis hierhin schonmal für eure nützlichen Tipps
Ham mir schonmal sehr geholfen.
Danke

Also: erstmal, nimm Lite-C.
Durch die Möglichkeit strukturen zu verwenden, kannst Du solche ein komplexeres Projekt
wesentlich eleganter erstellen.

Wenn Du Erfahrung im Umgang mit C++ und der Anbindung in 3dGS hast, dann kannst
Du natürlich auch diesen Weg gehen.
Das solltest Du aber nur tun, wenn Du auch die Entsprechende Erfahrung hast,
da man mit den dlls noch mehr "Um die Ecke" denken mußt. Allerdings
ist natürlich die Verwendung einer objektorientierten Sprache wesentlich eleganter
als das prozeduale Lite-C.

Bevor Du anfängst das Projekt als solches zu planen, und die Architektur
entwirfts, solltest Du Testprojekte mit A* Pathfinding machen.
Das Pathfinding ist ein absoluter Grundbaustein.
Auch solltest Du viel Erfahrung im Umgang mit pointern/handles haben.

Des Weiteren les dich in das Konzept von Statemachines ein.
Jede Unit kann man als kleine Statemachine sehen.
Im Grunde gibt es eine KI für die Unit,
und eine KI für den Computerspieler, oder den menschlichen Spieler.
Beide geben Kommandos an die KI der Unit.
Dieses vergeben von Kommandos sollte für die Computer-KI und den menschlichen Spieler
ein einheitliches Format haben. (zB gehe zu Position x/y -> die Unit empfängt das Kommando
und berechnet den Pfad, und setzt sich dann in den Bewegungsmodus)


Eine klare trennung von diesen Komponenten
(unit-KI, Computer-KI, Interface und Kommandos für den Menschlichen Spieler,
Darstellung der Welt)
sollte Grundsatz der Skript-architektur sein.


... muß jetzt leider los, ich kann später noch was dazu schreiben.

Wie schon angesprochen, sollte es eine (oder mehrere) Dateien
mit predefinitionen geben.

also: define unit_health = skill10; usw.

das selbe mit allen verwendeten Modell, Sound und Bitmap files.
Die sollten nie direkt mit ihrem File-Namen erzeugt werden, sondern als String oder bmap vorher
definiert werden.

Vor jeder Funktion sollte ein Block mit einem Kommentar stehen.
Da gehört rein, was die Funktion tut, und welche Parameter übergeben werden, verändert werden
und zurückgegeben werden.

Alle Funtktionen sollten predefiniert sein in einem definitionsskript.

also
function to_diesunddas(parameter_1_var,parameter_2_var);

so werden alle funktionen auch von anderen funktionen gefunden (beim Kompilieren), und du
mußt Dir nicht um die Reihenfolge im Skript gedanken machen.


Mach Dir vielleicht auch eine Grafik in UML oder einem anderen Tool,
um die Module visuell in Zusammenhang zu bringen.

Ausserdem erzeuge Dir früh ein Debuggingfenster, in dem Du
überall im skript einfach Daten und Strings reinschreiben kannst.
Ich nehme ein kleines Skript namens "echo.wdl"
Das erzeugt ein Fenster, in welches werte und Strings per
echo("neue Unit", wert);
geschrieben werden können.

Ich habe mal an einem RTS gearbeitet, bin damals aber nicht so weit gekommen (war auch noch nicht so erfahren und hab mit A4 gearbeitet ). Ein Interface und ein anständiges Steuerungsscript sind recht einfach machbar, die Hauptschwierigkeiten liegen (oder lagen bei mir) in zwei Punkten:

1: Die Modelle, davon brauchst du bei einem RTS nunmal viele, wenns schön und obendrein noch komplex sein soll, dann sogar sehr viele. Du solltest also entweder jemand haben, der dir die macht, oder eben sehr gut modellen können.

2: Die Ki. Das ist einfach ein harter Brocken Scriptarbeit. Du solltest während des Scriptens alle deine Codes so anfertigen, dass sie sowohl vom Spieler als auch vom PC gesteuert werden könnten. Die Ki muss dann lediglich für einen intelligenten Input sorgen. Und benutz ein Pathfinding Tutorial hier aus dem Forum oder den Resources, ich hab damals fast ein Jahr lang ein eigenes ausgearbeitet mit dem Ergebnis, dass es nicht halb so gut war, wie die Tutorials.

Außerdem solltest du dein Spiel möglichst gut voraus planen, das geht bei RTS ja recht gut, überleg dir Technologiebäume etc. schon vorher, das macht das Arbeiten leichter, aber bleib realistisch, bei dem Umfang des ganzen, sonst wirst genauso wie ich scheitern (wobei man diese Erfahrung einfach auch mal gemacht haben muss )

Pathfinding ist das a und o. Da viele Einheiten bewegt werden, sollte man sich folgende Gedanken machen:
Ist der "absolut kürzeste Weg" wirklich wichtig?
Nicht zwangsläufig. Ist zwar der beste, kostet aber auch am meisten Performance. Je nachdem, wieviele Einheiten also im Spiel sind, sollte man die Heuristik (siehe A* Tutorials) vereinfachen, eventuell auch die Feinheit der Nodes verringern. Am besten bindet man das an die CPU-Auslastung.
Es empfiehlt sich vor allem, in Basisnähe genauer zu suchen und sonst eher etwas ungenauere Wege zu verwenden. Sich durch eine Basis zu wurchteln ist schwieriger als auf offenem Terrain. Hier vllt. das Level auch in Sektoren unterteilen mit dem Grad der Hindernisse.
Vllt. auch kurze Wege von einer Basis zur Gegnerbasis speichern und wiederverwenden. Erst in der Nähe der Basis wird dann genauer gesucht.

es gibt die ausgezeichnete möglickeit ein grobes raster anzulegen und dann bis zum nächsten node des rasters ein feineres(und genaueres) zu verwenden, das sollte performance sparen