Gestaltungsrichtlinien
Warum ein Neuansatz?
Die Zielsetzung hat sich geändert. Beim letzten Bunny-Hill-Projekt ging es darum, ein funktionierendes Programm zu erhalten und - so weit wie möglich - zu verbessern. Die Verbesserungen blieben stecken, und der dazugehörige Kurseditor ist zu komplex angelegt, ohne wirklich nützlich zu sein. Nun soll es darum gehen, mich in fundamentale Zusammenhänge einzuarbeiten und dazu Bunny Hill als konkreten Rahmen zu verwenden. Wenn es klappen sollte, gut. Falls nicht: der Lernerfolg ist auch ein Erfolg. Grundsätzlich bleibt aber Bunny Hill erhalten und kann auch gelegentlich noch verbessert werden. Das neue Bunny Hill wird komplett unabhängig entwickelt. Im folgenden wird in dieser Dokumentation für das alte Bunny Hill wieder der Name "Tuxracer" verwendet.
Abhängig davon ist das Verfahren. Das Gesamtprojekt wird in Teilprojekte zerlegt, die vollkommen autonom entwickelt und getestet werden. Falls alle - oder fast alle - erfolgreich sind, kann es zu einer Integration zu Bunny Hill kommen. Doch, wie gesagt, so weit muss es nicht kommen. Das Verfahren verlangt nach modernen, ausgereiften Strukturen und kann nur gelingen, wenn in hohem Maße strukturell gedacht wird. Ein Beispiel: In Tuxracer ist die Spielesteuerung in einer Kontrollstruktur ctrl untegebracht. Es ist aber besser, sie einem Player zuzuordnen. Da muss also gefragt werden, was zu einem Player dazugehört, welche Untermodule benötigt werden, wie übergeodnete Module mit einem oder mehreren Playern umgehen sollen usw.
Allgemeine Grundsätze
- Es wird von vornherein plattformübergreifend programmiert, also immer wieder ein Übertragen nach Windows.
- Sprache ist modernes C++. Dabei sollen alle verfügbaren Optionen verwendet werden, sofern nützlich.
- Im OpenGL-Bereich bedeutet das die Hinwendung zu Shadern und die Entwicklung eine kapselnden Bibliothek.
- Mathematisch muss der Übergang zu OOP vollzogen werden, also doch eine Klasse Vector3.
- Für die Bezeichner werden Regeln aufgestellt (hier in der Doku), die allerdings nicht mit den üblichen "Undurchsichtigkeiten" übereinstimmen müssen. Grundsatz: ich programmiere für mich.