Da ich mich für meine Verhältnisse zur Zeit etwas mehr mit Spielemachen beschäftige als sonst, wird es vielleicht Zeit, etwas mehr übers Spielemachen zu schreiben. Die ganzen abgebrochenen Projekte sind eher uninteressant. Ich werde diesen Beitrag dem Spiel widmen, das tatsächlich fertig geworden ist, und mich gleich darauf wieder Candy Wars widmen. Ich sehe voraus, daß ich von Thema zu Thema springen werde, also konzentriert euch! Am Ende gibt es ein Quiz.
Zuerst war das Softwaretechnikstudium. Im Hauptstudium gab es dann die Vorlesung "Bildsynthese", wo man in der ersten Hälfte des Semesters die Aufgaben in OpenGL gelöst hat. Also habe ich mir das "Open GL Programming Guide" gekauft, das als "Red Book" besser bekannt geworden ist, weil es rot ist. Es gibt noch ein "Reference Manual" oder "Blue Book", das in Papierform völlig unnötig ist, weil man beim lesen einer Referenzdokumentation mehr Zeit mit Suchen und Navigieren als mit Lesen verbringt. Suchen und Navigieren ist auf dem Rechner viel angenehmer als mit einem Buch. Das Red Book liest man ein Kapitel nach dem anderen.
Ich weiß nicht, wie es mit der aktuellen Ausgabe aussieht, aber das Buch zu OpenGL 1.2, das ich habe, ist das beste Programmierlehrbuch, das ich jemals in der Hand hatte. Es sorgt dafür, daß man für jedes Kapitel immer mit genug Wissen gewappnet ist, um das neue Konzept zu verstehen. Die Code-Listings sind immer komplett und so wie sie stehen ausführbar. Man muß nicht herausfinden, welchem Programm in welchem Zustand man den Code hinzufügen muß, damit es funktioniert, und es kann nicht passieren, daß man eine Zwischenkomponente vergisst. Der Text konzentriert sich mit so einer Präzision auf dem Punkt, ohne zu wenig oder zuviel zu erzählen, daß man denkt, er müsste von einer Maschine stammen.
Es hilft auch, daß OpenGL zumindest in der Version 1.2 und mit seiner Basisfunktionatlität (ohne die Extensions) einfach zu verstehen ist und den Programmierer möglichst wenig belästigt. OpenGL zusammen mit SDL für die vereinfachte Fensterverwaltung ist meine Empfehlung für einen Amateurentwickler, der aus irgendwelchen Gründen kein XNA benutzen will. XNA benutzt man zum Beispiel nicht, wenn man das Spiel auf mehrere Plattformen laufen lassen will, wenn man in C++ programmieren will, wenn man das Spiel auf Rechner laufen lassen will, die den Hardwareanforderungen von XNA nicht genügen, wenn man eine Steuerung mit Controllern erlauben will, die nicht der Xbox 360 Controller sind usw. Wenn einem das alles egal ist, dann ist XNA eine bessere Wahl, weil es ähnlich einfach ist aber im Gegensatz zu OpenGL ein komplettes Paket darstellt, das Sound/Input/Netzwerk/Importer/Tools abdeckt. Damals gab es aber XNA noch nicht.
Also gut, halten wir mal fest, daß ich mehrere Projekte angefangen habe, die ich abgebrochen habe. Die Fehler, die ich dabei gemacht habe, sind monumental. Dabei beziehe ich mich nicht auf die Programmierung an sich sondern Entscheidungen bei der Herangehensweise. Ich wollte ein Street Fighter vs. Dragonball Prügelspiel machen und habe ein halbes Jahr lang an einem möglichst korrekten Importer für das .spr-Format, in dem animierte Sprites gespeichert werden, verschwendet. Ich habe schon immer den Wunsch gehabt, alles machen zu wollen zum Teil des Lerneffekts wegen, und von diesem Laster bin ich immer noch bei weitem nicht befreit, aber das war absurd. Ich habe dennoch tatsächlich ein gutes Bild davon, wie Binärformate aufgebaut sind, was cool und bisher nutzlos ist. Nutzlos ist bei mir alles, was keine Frauen ins Bett befördert.
Als erstes habe ich den Entschluß gefasst, daß ich ein Spiel komplett entwickeln werde. Alles andere war sekundär, ich mußte nur fertigwerden. Ich habe mich also hingesetzt (Lüge: Programmierer sitzen per Definition ständig) und mir überlegt, was ich alles nicht machen werde, damit das Spiel fertig wird. Das zeitaufwendigste (fast hätte ich 'aufwändig' geschrieben), wenn man Programmierer ist, ist die Grafik. Also dürfte mein Spiel möglichst wenig Grafik haben und nach Möglichkeit keine Animationen. Dann darf das Spiel keinen Leveleditor verlangen. Man kann davon ausgehen, daß ein Programmierer sich beim Editieren von Levels sich wohler fühlt als beim malen von Grafik, aber es ist ein Prozess, der viele Iterationen braucht, Feedback von Spielern und je nach Spielart kann die Programmierung des Leveleditors genauso viel Aufwand bedeuten als das Spiel an sich.
Ich wußte aus Erfahrung, daß ich jede Aufgabe, die mir bevorsteht, unterschätze. Das ist immer so. Also habe ich zu extremen Mitteln gegriffen. Was lernt man in der ersten Lektion des Red Book? Ein Dreieck zeichnen. Was lernt man danach? Ein Dreieck rotieren. Kann man ein Spiel daraus machen? Wenn man so wie ich ein Genie ist, dann ja. Die Idee für Dreieck23 wurde geboren.
(Fortsetzung folgt)
2 Kommentare:
Sehr interessant. Ich bin auch soweit, dass ich für mein erstes Spiel, das ich voraussichtlich 2030 coden werde (nach meinem großen Lottogewinn), nur äußerst simple Grafik nehme und das ganze auch nur auf einem Screen stattfinden soll. Nur die Idee fehlt noch. Meine beiden bisherigen Lieblingsideen haben entweder scrollbare große Levels oder benötigen sehr gute Ballphysik. Erscheint mir beides für ein erstes Projekt zu aufwendig.
Ich würde an deiner Stelle einfach loslegen und sehen wie weit ich komme. Selbst wenn du das Projekt nicht beendest, ist programmieren der einzige Weg, wie du (spielspezifisches) programmieren lernst. Und wenn man im Flow ist, dann lässt sich später viel schneller arbeiten.
Falls du Ballphysik willst, kannst du dir die Unreal Engine 3 anschauen (ist inzwischen kostenlos, es sei denn du verkaufst eine bestimmte Menge) oder Unity.
Kommentar veröffentlichen