Echtzeitstrategiespiel mit A7?

Easy Particle 3 und Spellbox sind hier zu empfehlen wenn ich dich richtig verstanden habe. Beide müssten über die Au Ressourcen auf jeden Fall aber übers wiki zu finden sein. Spellbox ist eher für simple Effekte aber dafür sehr leicht in der Bediehnung. Easy Particle ist schon sehr mächtig. Beide sind free (oder waren es zumindest mal )

EDIT: Wenn du Worldsforge verwenden willst, lad dir die gefixte dll runter:
http://files.filefront.com/cre+hmpdll/;8740258;/fileinfo.html

Easy Particle 3 habe ich. Kann man den Effekt dann in Echtzeit anzeigen oder nur als Spriteanimation?

Easy Particle schreibt dir ein .wdl Script. Das kannst du dann in dein Spiel einbauen, wenn du LiteC verwendest musst du dabei evtl. ein paar Konvertierungen vornehmen, da Easy Particle in C-Script ausgibt.
Das Script erzeugt den Effekt als Particle Effekt nicht als Sprite animation, das mit der Spriteanimation ist nur ein zusätzliches Feature von Easy Particle.

Je nachdem solltest du dir vielleicht auch mal die Spring Engine ansehen:
http://spring.clan-sy.com/
Ist zwar ursprünglich darauf ausgelegt Total Annihilation zu portieren, aber du kannst damit auch so gut wie alles andere machen. Die Vorteile hier wären, dass du dir quasi keinerlei Gedanken mehr um Pathfinding, Multiplayer, Lobby-Client usw. machen musst, da das alles schon vorhanden ist. Dafür ist das modden vielleicht nicht ganz so leicht wie in 3DGS einen Panzer einzufügen, aber gerade da du alleine bist ist es die Frage ob du wirklich diesen ganzen "Arsch voll Arbeit" mit der ganzen Spieltechnik haben möchtest, denn wirklich spannend ist es nicht sowas zu coden...

Zumindest kann ich mir spaßigere Sachen vorstellen...

Mahlzeit
Toast

Die Spring Engine kenne ich, allerdings sagt mir die grafische Qualität nicht sonderlich zu. Schon alleine wenn ich das Wasser sehe bekomme ich Schüttelfrost. :-)

Also:

erstens, Du kannst sicher ein RTS machen, mit jeder 3dgs version.
(Ich hab dier erste Version von Wasteland mit A5 Extra gemacht)

Du solltest einige Vorüberlegungen machen, die die weitere Entwicklung bestimmen.

Spielmodus:

-soll es eine Reines klassisches RTS Spiel gegen die KI sein?
Vorteil: das Spiel lässt sich im Singleplayer spielen, und Du kannst
interessante Missionen und Campains erstellen, Trigger und Storyelemente.

-soll es ein reines Multiplayer-spiel sein?
Vorteil: Du brauchst nur die recht einfache Einheiten KI mit State-machines bauen,
die Gegner werden dann von den Mutspielern gesteuert.
Aus diversen Gründen sollte es aber eine LAN basiertes Spiel sein,
eine solche Multiplayer-entwicklung ist wesentlich einfacher als Internet-basierte Spiele.
Nachteil: das Spiel kann nur gespielt werden, wenn du mindestens einen Partner im Netz hast.
Wenn Du keine Luete findest, kann man das Spiel nicht spielen, und es Frustriert gegeben
dem vorherigen Aufwand.

-Multiplayer + Singleplayer: Ein solches Konstrukt ist dann ein "richtiges" RTS,
aber auch ein riesen Stück Arbeit, das ich keinem Hobbyentwickler raten würde.

Game-Architektur + Limits:

Du musst frühzeitig die Features, das Gameplay etc limitieren, damit
eine klare Linie bei der Entwicklung hast.
zB: Anzahl der Einheiten, Anzahl der Rassen und Einheitentypen.
Größe des Spielfeldes bezüglich des Pathfinding (zB maximal 128x128 er Grid)

Bau man später Features rein, die nie so angedacht waren, kann das eine Husarenarbeit werden,
und eine unleserliche Code-Suppe erzeugen.


Trennen von Darstellung und Architektur:

Das komplizierte bei einem RTS ist die dahinterliegende Struktur:
Also: Client-Server Trennung, Wie agieren Einheiten im Spielsystem (es sind keine Shooter-Entities!)
Wie wird mit dem Spieler kommuniziert, welche Kommandos kann der Spieler geben, und wie
wird das zum Server weitergeleitet.
Wie funktioniert das Pathfinfing, wie kann die KI damit umgebhen.
Das sind alles Sachen, die unabhängig von 3dgs-Funktionalitäten sind. Es sind typische Probleme der Programmierung.

Wie das ganze (die Spielwelt) dargestellt wird muss man seperat betrachten.
Ob man nun so, oder so viel Polys verwendet, oder diese Shader benutzt, hat keinen
Einfluss auf die Spielmechanik. Auch solltest Du verstanden haben, das ein c_move nichts in
einem RTS zu suchen hat. Es ist keine Shooter. Starcraft benutzt auch kein c_move,
im Gegensatz zu einem Half-Life, das eine Ähnliche funktion für Bewegungen verwendet.
Ich glaube dieser Ansatz der Programmierer, die zwar Shooter machen können, und dann
das auf ein RTS übertragen ist das Haupt-problem bei der Realisierung.

Kümmer Dich erstmal nicht um Probleme, wie Polycount, Effakte, shader oder die Story,
sondern versuche ein funktionierendes Pathfinding zu basteln.
Versuche Einheiten wie Schachfiguren zu sehen, die sich auf einer flachen Ebene
nur um ganze Kästchen bewegen können.
(genau so funktionieren Starcraft, Warcraft 3, Earth 2150)

Schau Dir mal an, wie der Warcraft Editor funktioniert.
Für ein RTS solltest Du bestimmte Teile in einem Eigenen Editor realisieren.

PS: wie Du Wasser oder Partikel darstellts is nun wirklich komplett irrelevant
bei dieserm Entwicklungsstatus.
Das ist wie das Erfinden eines Autos, und bevor man weiss wie ein Motor funktioniert,
sich um die Verziehungen der Kühlerfigur Gedanken zu machen.

@Damocles:

Danke für deine ausführlichen Infos. Ich habe bereits ein RTS gemacht (steht am Angang), es ist also nicht Neuland. Alleine für die Planung werde ich circa 9 bis 12 Monate brauchen, also bis auf dem Papier alles steht, was ich brauche. Dann weiß ich auch, welche Features ich brauche und was ich programmieren muss.

Meine Fragen zielen darauf ab, was die Engine selber schon kann. Ich werde mir sehr viel Mühe geben, aber ich will nicht mitten in der Arbeit feststellen, dass die Engine für meine Vorstellung nicht gut genug ist.

Ich habe in den letzten Jahren einige, teils sehr anspruchsvolle Spiele gemacht. Was mich aber laufend verärgert hat, waren die "faulen Kompromisse" welche getroffen werden mussten. Mal lag es an der Zeit, mal an der Engine, mal an den Ressourcen. Dieses mal soll das alles keine Rolle spielen. Zeit und dadurch auch Ressourcen sind bei mir unendlich. Wenn ich 10 Jahre dafür brauche, spielt das keine Rolle. Ich will aber mit einer gesunden Basis arbeiten und eine Engine, die heute zeitgemäß ist. Wenn ich eine Engine verwende, die heute schon schlecht ist, dann wird sie in einigen Jahren noch schlechter sein. Da gehören Partikel, Wasser, Physik und viele andere Dinge einfach dazu, ohne direkt was mit dem Gameplay zu tun zu haben.

Du kannst Dich ja stückchenweise Rantasten, und diverse
Elemente (Spielmechanik, Grafische Effekte, Beslastungstest mit vielen Modellen)
Prototypeen basteln, die seperat laufen.

So kannst Du sehen, ob bestimmte Sachen müglich sind, und wenn, wie viele
Ressourcen sie bekommen sollen.

Das eigendliche Spiel soltest Du erst starten, wenn alle Parameter und Elemente
so zu realisieren sind, wie Du es benötigst.

3dgs kann viel, ist aber nunmal eine Engine die es allen recht machen will,
und dir somit nicht das Optimum für alle elemente geben kann, wie
eien komplett selbst entwickelte Engine.

Genau so habe ich es dann auch vor. Ich muss mich ja auch erst einarbeiten und so kann ich beides zeitgleich machen, also Einarbeitung und testen. Bei mir wird es schon mit einfachen Sachen wie "3D Figur zum laufen bringen" los gehen. Derzeit versuche ich es so akribisch wie möglich zu planen, also nicht nur das Spiel, sondern auch die Vorgehensweise.

Um deine Frage noch kurz zu beantworten. Ich will ein richtiges RTS machen. Also Missionen UND Multiplayer. Es wird zwar drei Rassen geben, aber derzeit möchte ich nur für eine Rasse Missionen erstellen, aus mehreren Gründen.

Die Planung, falls es einen interessiert, sieht im groben so aus:

1.) Erst wird eine Rasse komplett auf Papier generiert. Also Technikbaum mit allen Einheiten und Gebäuden, Bauzeiten, Kosten, Upgrades und so weiter. Wenn das alles schlüssig ist, entstehen die beiden anderen Rassen auf Papier.

2.) Nachdem ich technisch alles ausgelotet habe, konzentriert sich ert mal alles auf die Grafik. Ich will die erste Rasse fertig stellen und ein komplettes Set für eine Spielewelt, also entweder Wüstenplanet, Eiswelt, Mond, Graslandschaft oder sonstwas. Grafisch muss hier erst mal alles so weit fertig machen, dass ich damit leben kann. Funktionieren muss noch nichts.

3.) Anschließend geht es an den Code. Von Basenbau, Truppenbewegungen, Wegfindung und so weiter. Es sollte so weit gehen, dass ich mir der Rasse alles machen kann, ohne dass ein Gegner dabei vorkommt.

4.) Multiplayer. Das Ziel ist hier erst einmal, dass man zu zweit gegeneinander spielen kann. Hier geht es erst mal um das Grundgerüst vom MP und dem Balancing.

5.) Wenn sich das Balancing der ersten Rasse im MP bewehrt hat, wird die zweite Rasse erstellt bis sie im MP getestet werden kann. Wenn das auch perfekt funktioniert, kommt die dritte Rasse dran.

6.) Nun bin ich an dem Punkt, an dem ich drei im MP funktionierende Rassen habe. Durch die vielen Tests zeigt sich, welche Strategien für eine Rasse gut und welche Schlecht sind. Dies wird die Grundlage für meine KI. Also beginne ich mit einem Gefechtsmodus.

7.) Sobald der Gefechtsmodus und somit die KI funktioniert, geht es an die Missionen.

Da gibt es noch 1000 Zwischenschritte, aber das sind meine Kernpunkte welche ich abarbeiten will. Was hier so einfach klingt, ist natürlich mörderisch viel Arbeit.

spring sieht doch hervorragend aus... ? ich weiß gar nicht, was du hast... derartige qualität (shader, vegetationsdichte, effekte) in a6/7 im spielbaren bereich zu halten ist derzeit noch zukunftsmusik.

theoretisch ist alles möglich, theoretisch kannst du "dir deine editoren selber coden" (wozu dann acknex kaufen...) etc - aber a6/7 bringt von haus aus keine rts-templates mit, was du also auch machst, du beginnst mit 0. und wenn du schon mit 0 beginnen musst und bereits game-creation erfahrung gesammlt hast, dann würd ich mir doch eine andere engine wählen, eine, die von haus aus schon einige grundsteine mitbringt und/oder auf der eyecandy-seite einiges mehr zu bieten hat als (das derzeitige) acknex.
es gibt ja auch so wenige rts auf quake- oder nfs-engine-basis... warum also etwas übers knie brechen und sich am ende ärgern?

Ich habe zwar keine Erfahrung in Sachen RTS development oder MP projects, allerdings solltest du in betracht ziehen das du schritt 3 und 4 nicht so trennen kannst.
Wenn man ein singeplayer spiel erstellt und dieses dann um multiplayer erweitern will fängt man wieder ganz von vorne an.
Somit solltest du dir vor schritt 3 gedanken um den multiplayer machen und den singleplayer als multiplayer von einem spieler vs. bots gestalten.
Damit meine ich, das du vorher trennen solltest was der server macht und was der client macht. (code architektur)
Wenn du das weißt kannst du anfangen einheiten zu bewegen.
An dem simplen beispiel stellt sich ja die frage: was macht davon der server und was der client?

Ich würde also mit einer multiplayer architektur anfangen und diese dann für den singleplayer "missbrauchen" indem man zwar eine multiplayer session startet, aber diese nicht öffnet und nur einen spieler zu lässt und bots lädt.

Aber wie gesagt: just my humble opinion.

Zwecks Balancing und Architektur solltest Du alle drei Rassen gleichzeitig erstellen.

Wenn die Rassen grundsätzlich ähnlich sind, (Age of Empires) kannst Du allerdings
auch erstmal mit einer Anfangen.
Sind sie komplett unterschiedlich (Starcraft) musst Du alle gleichzeitig entwickeln und
balancen. Ansonsten kannst Du das Balancing der ersten Rasse vergessen, wenn Du eine
weitere implementierst.

Mach am besten eine "Strictly Client-Sever" Architektur. Wobei
auch im Singleplayer Client und Server laufen. (zwei Programm auf einem Rechner)
Wenn es Multiplayer haben soll, musst Du definitiv mit dem Multiplayerpart anfangen.
Umstellen von Singleplayer auf Multiplayer ist kaum möglich.

Ich rate Dir die von Anfang an die GSTNet.dll zu nutzen, das ist die vernüftigste Lösung
für ein solches Projekt die ich kenne (für Acknex).
Ich hoffe die dll wird auch in Zukunft unterstützt.

@Yamm:
Also ich weiß auch nicht was du gegen die Spring Engine hast - gerade das Wasser sieht sehr gut aus (bedenke es ist nur ein Echtzeitstrategiespiel und kein Half-Life 2 Ego Shooter), man muss nur den Shader einschalten:


Falls du meinst dass die Einheiten schlecht aussehen - da hast du irgendwo recht, aber die Models stammen auch aus einem Spiel von 1997, wo noch keine 3D-Beschleunigung vorgesehen war und von daher sehen die Einheiten von Nahem nunmal so aus:

Allerdings gibt es jetzt schon seit einiger Zeit Bestrebungen, die Einheiten "aufzufrischen" und von daher könnte das auch so aussehen (mal ein Bild ohne Textur aus dem Forum entnommen):


Um ehrlich zu sein würde ich mir auch um die Rassen etc. noch gar keine großartigen Gedanken machen (was die Realisierung angeht). Ich wäre zunächst einmal froh wenn ich Kästchen über ein Terrain verschieben kann die nicht aneinander hängenbleiben, Gebäude umfahren bzw. generell den Weg auch durch anspruchsvollere Strecken finden und sich gegenseitig abschießen können. Das Ganze dann natürlich auch noch im Multiplayer ohne das es laggt...

Naja - auf jeden Fall wünsche ich dir viel Glück und Erfolg dabei und wenn was dabei rauskommt kannst du's ja als User Contribution hier reinstellen...

Mahlzeit
Toast