Also das Spielprinzip hört sich für nen Spiel für zwischendurch schon witzig an, bei der Graphik gehe ich mal davon aus das diese nur vorläufig ist oder? (Die Kugeln sehen irgendwie recht platt aus)

Wie lange soll denn ein Match ungefähr dauern? Oder habt ihr noch keine konkreten Vorstellungen?

Wenn du bei dem dem Netzwerk angekommen bist hoffe ich das du schön detailiert berichtest wie du das machst, ich bin da auch hinter her..

Na dann mal viel Glück mit dem Projekt.

Auf wie viele Raumschiffe soll das ganze denn ausgelegt sein? Denn sobald es einige Raumschiffe, FogOfWar etc geben soll, muss man die Einheitenverwaltung ziemlich optimieren. Das ist für einen Anfänger (also nicht nur neu in OpenGL, sondern insgesamt) kaum zu schaffen. Bei meinem Projekt habe ich z.B. mehr als ne Woche an der Grundengine für Einheiten gearbeitet, damit er mit den bei RTS üblichen Einheitenzahlen zurecht kommt.

Hallo Leute,
die Grafik ist nur vorrübergehend so. Mittlerweile haben wir das Spielfeld beispielsweise grafisch auch schon etwas optimiert. Zu diesem frühen Zeitpunkt sicher noch nicht zwingend nötig, aber mir fiel es schwer selbst noch etwas zu erkennen Grundsätzlich würde ich aber auch in die Grafik der endgültigen Versionen nicht zu viele Erwartungen stecken

Ein normales Match soll ca. 30-45 Minuten dauern, je nach Größe des Spielfeldes und stärke des Gegners.

Zur Anzahl der Raumschiffe kann ich noch nichts sagen. Zur Zeit läuft alles noch mit einfachen Objekten, die zwar schon animiert sind, jedoch keine anderen Berechnungen (z.B. operative Schiffs-KI) durchführen. Mit diesen Objekten liegt die momentane Performance allerdings noch (!) stabil bei 60FPS mit 1200 Objekten auf Testsystem, das wir als Bezugsquelle für solche Daten nehmen. Das liegt allerdings auch daran, dass das Spielfeld ziemlich groß ist und nur das sichtbare gezeichnet wird. Und aufwendigere Berechnungen werden wie gesagt noch nicht für die Objekte angestellt. Die spätere grafische Optimierung werde ich meinem Freund überlassen, da dieser in OpenGl mittlerweile schon etwas fortgeschrittener ist wie ich. Bei dem Rest mache ich mir weniger Gedanken, da wir zwar Anfänger in OpenGl sind, nicht jedoch in Delphi Wobei ich dir jedoch nicht widersprechen will, Winner, da Optimierung ab einer bestimmten Projektgröße immer eine schwierige Sache ist, da man die Performancebremse erstmal finden muss.

Einen FogOfWar haben wir nach langer Diskussion nicht geplant. Es ist schließlich irgendwie sinnfrei, dass ich millionen Kilometer durchs All fliege und über modernste Technik verfüge, aber nicht weiß, was in meiner direkten Umgebung passiert. Und wie schon erwähnt wird es ein Spiel für zwischendurch. Wenn ich erst noch zig Kilometer an Karte aufdecken muss, um den letzten Gegner zu finden, werde ich definitiv länger spielen müssen.

@gucky: Sobald wir beim Netzwerk sind, werde ich nochmals auf dich zurückkommen

Noch zwei Hinweise:
1. Die Berechnung welche Gegner in Feuerreichweite sind ist in effizienter Form nicht trivial
2. Netzwerk sollte von Anfang an eingeplant werden, sonst droht das Schicksal von Anno1503

Was meinste damit?


Stimmt.

Wenn z.B. die Gegnersuche auf naive Weise implementiert hat man einen O(N^2) Algo der ziemlich in die Knie geht. Damit man in echtzeit schauen kann ob gegnerische schiffe in feuerrechweite sind, muss man das ganze stark optimieren, was nicht gerade einfach ist.

stimmt. da hast du vollkommen recht. du müsstest die distanz jedes einzelnen schiffs zu jedem anderen schiff berechnen. bei der simpelsten abfrage mit 2 schiffen wäre das 2, bei 4 schiffen 4^2 = 16. (1zu1, 1zu2, 1zu3, 1zu4, 2zu1, 2zu3 usw) Wenn man es jetzt dahingehend optimiert, dass man jedes Schiffpaar nur einmal berechnet (z.B. 1zu2 und 2zu1) und die unnötigen Berechnungen (1zu1 2zu2) etc weglässt hat man schon einiges optimiert. Weiterhin könnte man alles in Sektoren aufteilen und überprüfen, ob sich in Nachbarsektoren noch Schiffe befinden und nur, wenn sich dort was befindet die Entfernung berechnen. Aber auch das dürfte ab einer bestimmten Anzahl Schiffe und einer großen Anzahl Sektoren kritisch werden.
Um es einfach auszudrücken: da steckt noch viel Potenzial zum Optimieren hinter.

Warum nicht einfach die üblichen Ansätze? Statt der teuren 2-Norm kann man z.B. zuerst die viel billigere 1-Norm berechnen (Summe der Beträge der Koordinatenabstände). Die mit Wurzel 2 Multipliziert ist immer >= dem Abstand in der 2 Norm, wie man sie so kennt. Diese Rechnung dürfte etwas günstiger sein. Viel gibt es aber dabei nicht rauszuholen. Deutlich mehr Schub bekommt man durch eine andere Optimierung:

Das halten der "Schiffe" in einem Baum oder einer anderen Gitterstruktur (etwa Oct/Quadtrees oder ein ganz normales gröberes Grid). Und dann werden nur die Objekte untersucht, die sich in den nahe gelegenen Knoten befinden - wenn sich nicht grad alle Schiffe auf ein kleines Gebiet verteilen, bekommst du sofort sublinearen Zugriff auf die nächstgelegenen Objekte. Du musst das Grid dann nur gelegentlich updaten, wenn sich das Objekt bewegt - das nicht mal in jedem Frame, wenn sich die Objekte nur gemächlich bewegen (dann führt man einfach eine Variable spazieren, die beschreibt wann das letze Update war und wenn das zulange her... Am anfang wird diese Variable mit einem zufälligem Wert initialisiert). Und eigentlich braucht man nicht einmal in jedem Frame nach Gegnern zu suchen: Menschen haben nämlich Reaktionszeiten. Je nacht fitness und Co. etwa 0.1s-3.0s (letztere sind beim Autofahren immer ganz lustig). Wenn deine "Schiffe" also von menschen gesteuert werden, ist es nur zu natürlich, daß sie kleine Reaktionszeiten haben und die noch nicht einmal gleich sind - du brauchst also auch nicht ständing nach Gegnern zu suchen sondern nur gelegentlich. Und wenn halt grad einer Unter beschuss ist, dann konzentriert sich das Schiff v.a. auf diesen, etc. Ich denke nicht, daß man hier in übertriebene Probleme kommen kann - allein schon Weil das alte C&C selbst bei vielen Objekten noch auf 486ern mit 50MHz noch brauchbar lief

Mit der Rasterrechnik lässt sich das ganze gut optimieren, besonders wenn man für jeden Spieler ein eigenes Raster erstellt, und nur in den gegnerischen Rastern sucht. Die Eintragung in die Raster habe ich mit doppelt verketteten Listen gelöst. und ob "abs(x1-x2)+abs(y1-y2)<Radius" nennenswert schneller ist als sqr(x1-x2)+sqr(y1-y)<sqr(Radius) wage ich zu bezweifeln. Die getrennten Raster waren bei mir nötig weil sich häufig seht viele eigene Raumschiffe in Feuerreichtweite befinden, und bei einem gemeinsamen Raster mit abgefragt werden.

Zwei getrennte Raster sind zwar schön. Aber ich kann auch bei einem Raster bleiben und einfach bevor ich eine Distanz berechne einfach überprüfen, ob das Schiff einem gegnerischen Spieler gehört.
Ich weiß zwar nicht, wie du auf abs(x1-x2)+abs(y1-y2)<Radius und sqr(x1-x2)+sqr(y1-y)<sqr(Radius) kommst, aber zum ausrechnen der Distanz benutze ich hypot(x1-x2, y1-y2); Diese Funktion wiederum bedient sich bekanntermassen intern der Funktion Sqrt(X^2 + Y^2) Mit anderen Worten: Satz des Pythagoras.
Soll heißen: hypot(x1-x2, y1-y2) < Radius. Damit hätte ich schon zweimal sqrt gespart (was aber bei den FPUs moderner CPUs irrelevant sein dürfte).




Sehe ich genauso

"Summe der Beträge der Koordinatenabstände" => abs(x1-x2)+abs(y1-y2)<Radius, was aber einer 4 Wege Karte entsprechen würde
sqr(x1-x2)+sqr(y1-y2)<sqr(Radius) ist einfach der Satz des Pythagoras (X1-X2)^2+(Y1-Y2)^2<Radius^2 wodurch ich überhaupt keine wurzeln und funktionsaufrufe brauche (sqr ist afaik eine inline funktion)

Ich will ja nicht meckern... Die wesentliche Information war ja wohl, daß man v.a. durch den Einsatz von Gittern an Tempo kommen wird. Das andere war ja eher nebenbei erwähnt, wie man ein kleines Quäntchen bonus bekommt. Ob man nun quadriert oder Beträge rechnen lässt, wirds im wesentlichen nicht rausreißen

Stimmt. Das mit den Gittern ist ja auch nicht schlecht.
Leider hatte ich über die Feiertage keine Zeit mehr zum programmieren. Muss jetzt auch erstmal die paar Extra-Kilos verarbeiten.