Kamera

Die Kamerapositionen werden übers Netzwerk übertragen und zu Beginn synchronisiert.

Musikalische Begleitung

Für Titelmusik und evtl. Untermalung der Credits wird die Band Even sorgen,
dessen Schlagzeuger ich sehr gut kenne und der auch unser Projekt Spheropuzzle
damals musikalisch aufgebessert hat. Zusätzlich werden diverse Soundeffekte
(positioniert im 3D-Raum)
und auch die Melodie des Hauptspiels von meinem Bruder komponiert und
arrangiert. Das ganze sollte im Prinzip spätestens Ende April fertiggestellt sein.

PhysX - erste Eindrücke

Physik-Bugs wurden behoben, es ist jetzt der Learjet mit seinen Eigenschaften realisiert. Mit Hilfe von Datensets (in Form von XML) wäre es nun möglich, im Prinzip beliebig viele Flieger auszuwählen. Das Problem ist nur, dass diese Flieger auch jemand modellieren müsste, die Datenhaltung erlaubt es jedenfalls.
Zusätzlich sind erste AI-Eindrücke entstanden und es wurden kleine Kameras programmiert, die die Türme abgrasen (patrollieren) und diese schließen, sobald ein Feind in Sicht ist (im Field of View). Dabei passen sie auf, dass sie nicht kollidieren (Abtastung des Untergrunds und der Gebäude in der Nähe). Netzwerkfixes wurden eingespielt und fertige Texturen, Icons und Modelle werden hoffentlich bald fertig gestellt.

Strenges Spiel

Die Konsistenz wird ab jetzt nur mehr bei der Spieloption "strenges Spiel" überprüft. Diese Option erzwingt allerdings nur, dass der Strategiespieler vorhanden ist.

Konsistenz des Spielzustandes

Ab jetzt wird die Konsistenz sicher gestellt:
Es kann nicht sein, dass weniger als ein Action- und ein Strategiespieler pro Team beigetreten sind. Aus diesem Grund lässt sich ein Spiel erst ab einem Action- und einem Strategiespieler pro Team starten. Zusätzlich kann es vorkommen, dass ein Strategiespieler hinausfliegt (schlechte Verbindung, Rechner stürzt ab, Teamwechsel, Typwechsel, etc.). In diesem Fall wird ein Actionspieler "zwangsbeglückt". Sollte dieser wieder wechseln, wird der nächste Strategiespieler. So wird mehr oder weniger erzwungen, dass immer jemand den strategischen Teil regelt.
Sollte ein Actionspieler hinausfliegen und kein weiterer Actionspieler ist dem Team beigetreten, wird das Spiel angehalten, bis wieder ein Actionspieler pro Team vorhanden ist.

Tankstellen - Menü

Ein weiterer Punkt im Spiel - Prinzip wurde fertiggestellt: das Tankstellen - Menü. Es ist soweit fertig und einsatzbereit. Der Actionspieler kann mit seinem Flugzeug durch die Tankstelle fliegen und das Menü öffnet sich. Hier kann er kostenlos tanken oder Upgrades, die vom Strategen bereits erworben wurden, gegen wenig Entgeld, installieren lassen. Die Synchronisierung mit dem Server funktioniert ebenfalls schon.

Strategie-Bugs

Weiter Bugs in der Strategie-Logik wurden entfernt. Vor allem werden jetzt die Updates richtig angezeigt und außerdem wurden weitere Speicherprobleme behoben (VORSICHT!)
Zusätzlich lässt sich schnell zwischen den unterschiedlichen Sichten problemlos wechseln und bereits gekaufte Objekte werden weiter entwickelt. (Erweiterung, Basis war bereits vorhanden.) Bufferüberläufe wurden auch einige behoben (sollten eher nicht vorkommen!).

Strategie-Bugs behoben, PhysX in Arbeit

Es wurden endlich nach langer Suche (heute alleine ca. 3-4 h) die "argen" Strategiefehler behoben. Es waren sehr viele Abstürze die Folge, obwohl die "argen" Fehler gar nicht so "arg" sind.
Folgendes war falsch:

• C-Fehler Nr. 1: Verwechseln von = und ==: eigentlich ziemlich traurig, aber Schlampigkeitsfehler passieren leider auch unachtsamen erfahreren Programmierern
• Cast-Fehler: die SkyTactiXLogik wurde fälschlicherweise in eine Strategielogik gecastet. Statt (LOGICINST->getLogic()) wurde LOGICINST auf CStrategyLogic* gecastet! Was ich nicht verstehe, ist, dass es in diesem Fall keine Typüberprüfung gibt! Zumindest eine Microsoft Exception wäre fein, weil ja auch zur Laufzeit mi RTTI der Typ bestimmt werden kann und somit könnte man so etwas doch einfach verhindern!

Neuigkeiten bezüglich Physik haben sich ergeben: Es hat sich gezeigt, dass die Matrixmultiplikationen doch nicht so aufwendig sind, wie ursprünglich angenommen, sondern dass diese auf jeden Fall für die Flugdynamik eingesetzt werden können!
Sonst kann man sagen, dass vor allem an der Texturierung weiter gearbeitet wird und nebenbei diverse Erweiterungen und Bugfixes hinzugefügt werden.

Graph - Punkte setzen

Der Actionspieler kann jetzt zwischen seine definierten Ringe durchfliegen.
Zur Ermittlung der aktuellen Höhe werden wieder Strahlen geschickt und
der kleinste Abstand der Rays von den Triangle-Selektoren wird ermittelt.
Dies stellt sicher, dass die Platzierung immer auf der richtigen Höhe erfolgt
und nicht nur auf dem Boden des Terrains ausgerichtet ist.
Die Pfeil-Animation ergänzt das Ringe-Setzen. Der Strategiespieler hat die Möglichkeit Ringe für den Actionspieler zu setzen und kann somit aktiv in das Verhalten der Spieler eingreifen. Unterschiedliche Ringtypen mit unterschiedlichen Prioritäten sind geplant.

UDP

Diverse Netzwerkfixes wurden behoben, außerdem ist ab jetzt immer ein 2. Socket offen, der sich um das auffinden der Server und um die Versendung von Positions-Updates bemüht. Prinzipiell ist alles so ausgelegt, dass man "umschalten" kann, ob für den jeweiligen Nachrichttyp (immerhin bis jetzt schon über 40 Nachrichten-Typen) TCP oder UDP eingesetzt wird. Weiters wurden diverse Synchronisationsbugs und sonstige Fehler behoben, die Bewegungen schauen schon ziemlich gut aus, vor allem UDP hat zu dieser Verbesserung beigetragen. Zusätzlich soll eventuell für die Extrapolation noch der vereinfachte Algorithmus von Cristian eingesetzt werden.

AI

Prinzipien der AI wurden implementiert (AI-library eingebunden, AIManager geschrieben, Wegpunkte festgelegt, verlinkt, etc...)
Probleme dabei:
-> Flugzeug kann sich nicht einfach "umdrehen" wie Mensch
-> Flugzeug sollte nicht durch Wände fliegen
-> Flugzeug muss genauso steuern und denken, wie Mensch das machen würde

Es muss daher irgendwie eine Art "Roboter" geschaffen werden, der irgendwie
mit Sensoren erkennt, wie seine Umgebung aussieht!
Dies wäre möglich mit Strahlen, die mit Hilfe der Triangle-Selektoren ausgesendet und
geprüft werden können. Problem läge in der Auswertung und Positionierung dieser Strahlen.

Tipps von Herrn Professor Haberstroh würden wir gerne annehmen, bzw. erhoffen wir!
Im Prinzip wäre das ja so eine Art Roboter-Problem oder?
Sie haben mit der Robotik wahrscheinlich doch schon ziemlich viel Erfahrung, wie
könnte man das möglichst effizient lösen?

bug-fixes, extensions, schießen

Schießen ist jetzt (zumindest lokal möglich), wobei das ganze gar nicht so einfach ist.
Es werden geschosse nicht mit der newton-engine verschossen (komischerweise gehen ab bestimmten geschwindigkeiten die kollisionen nicht mehr), sondern "händisch" geprüft. Dazu werden die geschosse händisch weiterbewegt. Mit Hilfe einiger Triangle-Selektoren wird geprüft ob der aktuelle Strahl (Position - Position + Geschwindigkeit) mit Triangle-Selektoren kollidiert. Davon wird sogleich das minimalste genommen. Aufgepasst werden muss noch mit Schutzschild (ist nur manchmal aktiv, also darf nicht geprüft werden, wenn das ganze invisible ist!). Diverse andere Optimierungen sind noch nötig und - voala => Schießen möglich.
Diverse weitere Netzwerkoptimierungen wurden vorgenommen, das Interpolieren verbessert.
Komischerweise funktioniert es nicht auf Rechnern, die nicht Server sind, weil die Zeiten zu groß sind. => Bug?

C++ ist manchmal seltsam

Man kann hier laut Screenshot den Inhalt des Iterators ansehen, dereferenzieren ist nicht möglich. Irgendwie lustig, auf der anderen Seite aber extrem zum Verzweifeln, wenn man schon über 2h an dem Fehler sucht und auch ein Rebuild nichts hilft.