Posts mit dem Label Candy Wars werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Candy Wars werden angezeigt. Alle Posts anzeigen
Sonntag, 9. März 2014
Samstag, 8. März 2014
Paint Wars Post Mortem
Hier ein Link zu dem Spiel.
Es ist ziemlich genau 5 Jahre her, dass ich mit der Programmierung von Paint Wars angefangen habe und etwa ein halbes Jahr seitdem ich es veröffentlicht habe. Ich sammle mal meine Gedanken, damit ich die Lektionen nicht vergesse und vielleicht andere auch daraus lernen können.
Hintergrund
Ich habe es anderswo im Blog schon mal erwähnt aber ich habe während meiner Studienzeit die Programmierung mehrerer Spiele angefangen und sie abgebrochen, sobald mir bewusst geworden ist, wieviel Zeit vor allem die Grafik auf sich nehmen würde. Zu diesem Zeitpunkt konnte man nicht Tools auf dem Niveau von XSI Softimage oder Engines wie Unreal und Unity quasi kostenlos kriegen. Heute kann man einen großen Teil ihrer Features einfach so nutzen. Ich hatte auch in meinem jungendlichen Leichtsinn den Eindruck, dass richtige Männer alles selbst machen und jede Einzelheit des Prozesses beherrschen müssen. Das dümmste, was ich gemacht habe, war ein .spr-File-Leser zu schreiben, um das Dateiformat zu lesen, dass ein 2D-Animationsprogramm, das ich damals hatte, ausgespuckt hat. Es hat am Ende sogar funktioniert.
Irgendwann wollte ich einfach nur etwas fertigkriegen. Also habe ich das einfachste gemacht, was grafisch und vom Spielaufbau her ging, ohne dass es spielerisch in dem Bereich zu kommen, wo es für mich nicht vertretbar ist, meinen Namen drunterzuschreiben. Das war Dreieck23.
Die Entwicklung von Dreieck23 dauerte viel zu lang aber ich war zufrieden, dass es irgendwann fertig war. Man könnte denken, dass das schwierigste an einer Hobbyentwicklung ist, die Grafik schön zu machen oder die Komplexität der Programmierung zu beherrschen, aber das ist es nicht. Die Entwicklung hat einen Sweet Spot in der Mitte, in dem die Systeme stehen und aus einem funktionierenden Spiel mit vielen kleinen Schritten ein spielenwertes Spiel gemacht wird. Davor quält man sich mit Befehlen, die was auf dem Bildschirm zeichnen sollten und es nicht tun, weil irgendwelche Koordinaten außerhalb des Bildschirms zeigen, und danach quält man sich mit der richtigen Handhabung von Auflösungen und die richtige Handhabung von "Cancel"-Befehlen in Menüs. Die größte Herausforderung ist es, bei den weniger spannenden Sachen durchzuhalten.
Ziele/Motivation
So wie Dreieck23 ein Kind von Mohrhuhn und des ersten Kapitels des OpenGL Red Book ist, wo einem beigebracht wird, sein erstes Primitiv (Dreieck) zu zeichnen, ist Paint Wars auch ein Kind seiner Umstände. Ich wollte nichts überstürzen. Stattdessen wollte ich noch ein Zwischenschritt in der Größe des Spiels machen, bevor ich mich einem Spiel widme, das ich tatsächlich machen will.
Das wenige an Aufwand sollte mir helfen, die Motivation aufrechtzuerhalten, das Spiel tatsächlich zuende zu bringen. Ein weiteres Ziel war, einmal ein Konsolenspiel zu machen, weil ich seit Jahrzehnten davon geträumt habe. Das dritte Ziel war, primitive 3D-Grafik in einem 2D Spiel zu benutzen, so dass ich am Ende des Projekts genug Kenntnisse über 3D Modellierung habe, dass ich besser entscheiden kann, ob das nächste Spiel ein 2D oder 3D Spiel wird.
Was lief gut?
1. Ich habe ein Stück weit C# gelernt und zum ersten Mal in fremden Code so eingestiegen, dass ich mir eine Übersicht schaffen konnte, wie ein Spiel auf Architekturebene aufgebaut werden kann. Ich habe zwar schon mal an einem professionellen Spiel gearbeitet aber während meiner 4 Monate dort, habe ich immer noch kein Bild, das gut genug ist, machen können, wie die Teile zusammenhängen. Dabei habe ich an Spiellogik, Editor, bißchen Grafik, Sound, Scripting, etwas von allem gearbeitet.
Ich habe dank des Äquivalents der Zertifizierungslisten gelernt, auf was für Details man im Drumherum des Spiels achten muss.
2. Ich habe mit Beaterator auf der PSP eigene Musik gemacht und gemastert. Das hat Spaß gemacht und ich kann jetzt mit absoluter Sicherheit sagen, dass man 90% der Charts innerhalb von 10 Minuten auf dem Klo zusammenstellen kann.
3. Von der Spielmechanik her ist das Spiel genau so geworden, wie ich es mir vorgestellt habe. Und meine ursprüngliche Vorstellung vom Spiel hat sich beim testen bewährt. Wenn man so herumliest, was andere Entwickler schreiben, passiert es sehr oft, dass ein implementiertes Spiel oder Feature nicht so ablaufen kann, wie man es sich am Anfang im Kopf vorgestellt hat. Oder es läuft so wie vorgestellt, macht aber trotzdem keinen Spaß.
Meine zwei Spiele sind nicht innovativ sondern vorhandene Konzepte "with a twist" aber es ist erstaunlich, wie schnell ich sie parametrisieren konnte, dass sie sich "richtig anfühlen". Ich habe nicht mehr als ein paar Minuten gebraucht, um Beschleunigung und Maximalgeschwindigkeit des eigenen Schiffs zu bestimmen, Geschwindigkeit und Frequenz der Schüsse usw. Ich habe diese Sachen vor dem allerersten Test mit mehreren Spielern bestimmt und meiner Erinnerung nach nicht ändern müssen.
4. Ich habe das Spiel fertiggekriegt und ausgeliefert.
Was lief weniger gut?
Die Entwicklung dauerte 4 Jahre. Das ist zu lang.
1. Nutzloser Versuch, das Spiel online spielbar zu machen. Es ist erstaunlich, wie naiv ich noch vor 3 Jahren sein konnte. Ich dachte, es spielt eine Rolle, ob das Spiel seine Verkäufe verdoppelt oder verdreifacht. Das tut es nicht. Da das Spiel keinen Single-Player-Modus hat, habe ich gedacht, dass es um einiges attraktiver ist, wenn man es online spielen kann. Also habe ich das Implementieren neuer Features abgebrochen und eine Weile lang (fragt nicht wie lang!) Zeit darin investiert, den Aufbau des Codes so zu ändern, um ihn auf Netzwerkfähigkeit vorzubereiten. Ich habe Dokumente gelesen, wie man ein XNA Spiel online spielbar macht, die ganzen Regelungen mit Einladungen, Statusanzeigen, Lobbys usw und dann mittendrin aufgegeben. Davon abgesehen, dass es die Komplexität des Spiels und die möglichen Fehlerquellen vervielfacht hätte, habe ich keine Möglichkeit gehabt, das Zeug vernünftig zu testen.
2. Der Grafikstil ist nicht so geworden, wie ich ihn haben wollte, und die Grafik an sich ist nicht gut. Ursprünglich hieß das Spiel Candy Wars. Ich wollte, dass die Spielelemente nach Bonbons und sonstige Süßigkeiten aussehen, ein wenig wie Candy Crush, und die Spielumgebungen Tischoberflächen oder sonstiges in etwa wie Micro-Machines von der Perspektive her. Bei den Hintergründen habe ich es nicht geschafft, Texturen zu machen, die den ganzen Bildschirm bedecken, stilisiert sind und trotzdem erkennbar, was sie darstellen. Wenn ich eher Richtung Fotorealismus ging, mit Fotos, über die ich ein paar Filter laufen liess, sah das zu häßlich aus. Also habe ich aus dem Thema Süßigkeiten das Thema Ölfarben gemacht und den Titel geändert. Die Grafik war dann auch nicht mehr aus 3D-Elementen gemacht sondern nur noch 2D. Die Kollisionsabfrage passiert aber immer noch wie ursprünglich in einem 3D-Koordinatensystem, das parallel zum Koordinatensystem der Grafik existiert.
3. Wenn ich auf das Netzwerkzeug verzichtet und das Spiel früher rausgebracht hätte, hätte ich meine Verkäufe wahrscheinlich allein dadurch vervielfacht, dass mehr Interesse an Indie Games auf der Xbox bestand. Zahlen, von anderen Leuten, die ich vor einiger Zeit gelesen habe, sagten, dass man ungefähr mit 8000 Downloads der Demo rechnen soll, wobei 1/10 in Verkäufen umgewandelt bin. Inzwischen sind wir bei 1000 Downloads angekommen.
Die angegebenen verkauften Einheiten müssen laut Microsoft in dieser Darstellung nicht stimmen. Nur das Geld, das man kriegt, ist ausschlaggebend.
Wenn man die fehlenden Einheiten dieses Jahres dazurechnet, dann kommt man darauf, dass etwas weniger als 10% der Demos in Verkäufen umgewandelt wurden, was zu erwarten ist, wenn man ein Multiplayer-only Spiel macht, das solide aber spielerisch weder besonders reichhaltig, noch optisch ansprechend ist.
Zu diesem Zeitpunkt sind die Verkäufe also wie zu erwarten aber trotzdem ist es verdammt wenig.
Schlusswort
Habe ich meine Ziele erreicht? Ich habe das Spiel tatsächlich fertiggestellt. Ich habe ein Konsolenspiel gemacht. Es taugt. Ich habe nichts neues über 3D-Modellierungsprogramme gelernt und das bißchen, das ich gelernt habe, habe ich vergessen. Und XSI Softimage wird sterben.
Die größte Erkenntnis ist, dass ich bei den Zielen noch zwei zusätzliche Sachen aufnehmen sollte.
Erstens spielt es nicht nur eine Rolle, dass der netto Zeitaufwand für das Spiel gering ist. Wenn ich Vollzeit daran gearbeitet hätte, dann wäre ich in 1 oder 2 Monaten fertig. Wichtig ist auch, dass das Ende und der Anfang des Projekts nicht zu weit auseinanderliegen. Die Lebenszeit des Menschen ist begrenzt und man sollte nicht zuviel Zeit an Sachen verschwenden, dessen Chancen, erfolgreich zu sein, gering sind. Schnelle Iterationen sind nötig. Ich war in der Zeit nicht unbedingt faul. Ich habe es innerhalb von drei Jahren geschafft, vom Salsa-Nichtskönner zum bezahlten Salsa-Tanzlehrer zu werden, aber Paint Wars hat mich in dieser Zeit nicht glücklicher gemacht. Es war eine Sache in der Ecke meines Bewusstseins, an die ich immer denken musste, dass sie beendet werden soll, auf die ich aber keine großartige Lust hatte.
Warum hatte ich darauf keine Lust? Das Hauptkriterium war wie bei Dreieck23, dass das Spiel einen Umfang hat, dass es fertiggestellt werden kann. Beide Spiele waren aber keine, die ich selbst spielen wollte. Ein weiteres Ziel ist also, ein Spiel zu machen, das ich spielen will.
Als letztes Ziel sollte ich darauf abzielen, Spiele zu machen, die erfolgreich sein können. Damit ist nicht nur das Spieldesign sondern auch der Markt gemeint, womit XNA gleich am Anfang ausfallen sollte. Ich habe das bewusst gewählt und ich wusste von vorne rein, dass mir Paint Wars kein Geld einbringen wird und das tut mir auch nicht weh. Was unerwartet weh tut, ist wie wenig Leute das Spiel spielen, wenn man bedenkt, wie lange es gedauert hat, bis es fertig war. Ich habe keine Statistiken über Dreieck23 aber ich denke, Paint Wars ist verhältnismäßig erfolgreicher, also ist das schonmal gut.
Damit ich die neuen Ziele besser erreichen kann, werde ich in Zukunft Tools benutzen, mit denen ich weniger programmieren muss und schneller zum Ergebnis komme. Ich habe Unreal Engine 3 runtergeladen aber die Funktionen dort erschienen mir zu umfangreich. Unity ist übersichtlicher. Im letzten Steam-Sale habe ich GameMaker Studio gekauft und gehe jetzt die Tutorials durch. Letzteres scheint recht beschränkt zu sein aber wahrscheinlich werde ich es für die nächsten zwei, drei Spiele benutzen und mit den Beschränkungen arbeiten lernen. Ich will halt keinen eigenen Leveleditor programmieren, weil es nichts bringt.
Mike Acton von Insomniac hat unter anderem gesagt, dass man seine Zeit in Sachen stecken sollte, die man besser als andere machen kann. Auch wenn ein richtiger Mann alles selbst macht, wird mein Spiel besser, wenn ich meinen eigenen Leveleditor programmiere, obwohl zig andere schon existieren, die ich nutzen kann? Eher nicht. Ich bin über die Phase hinaus, wo ich etwas lernen würde (z.B. das Design von Level-Editoren) nur damit ich es weiß. Ich werde jedes vorhandene Werkzeug benutzen, das mich schneller zum Ziel bringt.
Die Lektion von Paint Wars ist: das Leben währt nicht ewig, verschwende es nicht!
Es ist ziemlich genau 5 Jahre her, dass ich mit der Programmierung von Paint Wars angefangen habe und etwa ein halbes Jahr seitdem ich es veröffentlicht habe. Ich sammle mal meine Gedanken, damit ich die Lektionen nicht vergesse und vielleicht andere auch daraus lernen können.
Hintergrund
Ich habe es anderswo im Blog schon mal erwähnt aber ich habe während meiner Studienzeit die Programmierung mehrerer Spiele angefangen und sie abgebrochen, sobald mir bewusst geworden ist, wieviel Zeit vor allem die Grafik auf sich nehmen würde. Zu diesem Zeitpunkt konnte man nicht Tools auf dem Niveau von XSI Softimage oder Engines wie Unreal und Unity quasi kostenlos kriegen. Heute kann man einen großen Teil ihrer Features einfach so nutzen. Ich hatte auch in meinem jungendlichen Leichtsinn den Eindruck, dass richtige Männer alles selbst machen und jede Einzelheit des Prozesses beherrschen müssen. Das dümmste, was ich gemacht habe, war ein .spr-File-Leser zu schreiben, um das Dateiformat zu lesen, dass ein 2D-Animationsprogramm, das ich damals hatte, ausgespuckt hat. Es hat am Ende sogar funktioniert.
Irgendwann wollte ich einfach nur etwas fertigkriegen. Also habe ich das einfachste gemacht, was grafisch und vom Spielaufbau her ging, ohne dass es spielerisch in dem Bereich zu kommen, wo es für mich nicht vertretbar ist, meinen Namen drunterzuschreiben. Das war Dreieck23.
Die Entwicklung von Dreieck23 dauerte viel zu lang aber ich war zufrieden, dass es irgendwann fertig war. Man könnte denken, dass das schwierigste an einer Hobbyentwicklung ist, die Grafik schön zu machen oder die Komplexität der Programmierung zu beherrschen, aber das ist es nicht. Die Entwicklung hat einen Sweet Spot in der Mitte, in dem die Systeme stehen und aus einem funktionierenden Spiel mit vielen kleinen Schritten ein spielenwertes Spiel gemacht wird. Davor quält man sich mit Befehlen, die was auf dem Bildschirm zeichnen sollten und es nicht tun, weil irgendwelche Koordinaten außerhalb des Bildschirms zeigen, und danach quält man sich mit der richtigen Handhabung von Auflösungen und die richtige Handhabung von "Cancel"-Befehlen in Menüs. Die größte Herausforderung ist es, bei den weniger spannenden Sachen durchzuhalten.
Ziele/Motivation
So wie Dreieck23 ein Kind von Mohrhuhn und des ersten Kapitels des OpenGL Red Book ist, wo einem beigebracht wird, sein erstes Primitiv (Dreieck) zu zeichnen, ist Paint Wars auch ein Kind seiner Umstände. Ich wollte nichts überstürzen. Stattdessen wollte ich noch ein Zwischenschritt in der Größe des Spiels machen, bevor ich mich einem Spiel widme, das ich tatsächlich machen will.
Das wenige an Aufwand sollte mir helfen, die Motivation aufrechtzuerhalten, das Spiel tatsächlich zuende zu bringen. Ein weiteres Ziel war, einmal ein Konsolenspiel zu machen, weil ich seit Jahrzehnten davon geträumt habe. Das dritte Ziel war, primitive 3D-Grafik in einem 2D Spiel zu benutzen, so dass ich am Ende des Projekts genug Kenntnisse über 3D Modellierung habe, dass ich besser entscheiden kann, ob das nächste Spiel ein 2D oder 3D Spiel wird.
Was lief gut?
1. Ich habe ein Stück weit C# gelernt und zum ersten Mal in fremden Code so eingestiegen, dass ich mir eine Übersicht schaffen konnte, wie ein Spiel auf Architekturebene aufgebaut werden kann. Ich habe zwar schon mal an einem professionellen Spiel gearbeitet aber während meiner 4 Monate dort, habe ich immer noch kein Bild, das gut genug ist, machen können, wie die Teile zusammenhängen. Dabei habe ich an Spiellogik, Editor, bißchen Grafik, Sound, Scripting, etwas von allem gearbeitet.
Ich habe dank des Äquivalents der Zertifizierungslisten gelernt, auf was für Details man im Drumherum des Spiels achten muss.
2. Ich habe mit Beaterator auf der PSP eigene Musik gemacht und gemastert. Das hat Spaß gemacht und ich kann jetzt mit absoluter Sicherheit sagen, dass man 90% der Charts innerhalb von 10 Minuten auf dem Klo zusammenstellen kann.
3. Von der Spielmechanik her ist das Spiel genau so geworden, wie ich es mir vorgestellt habe. Und meine ursprüngliche Vorstellung vom Spiel hat sich beim testen bewährt. Wenn man so herumliest, was andere Entwickler schreiben, passiert es sehr oft, dass ein implementiertes Spiel oder Feature nicht so ablaufen kann, wie man es sich am Anfang im Kopf vorgestellt hat. Oder es läuft so wie vorgestellt, macht aber trotzdem keinen Spaß.
Meine zwei Spiele sind nicht innovativ sondern vorhandene Konzepte "with a twist" aber es ist erstaunlich, wie schnell ich sie parametrisieren konnte, dass sie sich "richtig anfühlen". Ich habe nicht mehr als ein paar Minuten gebraucht, um Beschleunigung und Maximalgeschwindigkeit des eigenen Schiffs zu bestimmen, Geschwindigkeit und Frequenz der Schüsse usw. Ich habe diese Sachen vor dem allerersten Test mit mehreren Spielern bestimmt und meiner Erinnerung nach nicht ändern müssen.
4. Ich habe das Spiel fertiggekriegt und ausgeliefert.
Was lief weniger gut?
Die Entwicklung dauerte 4 Jahre. Das ist zu lang.
1. Nutzloser Versuch, das Spiel online spielbar zu machen. Es ist erstaunlich, wie naiv ich noch vor 3 Jahren sein konnte. Ich dachte, es spielt eine Rolle, ob das Spiel seine Verkäufe verdoppelt oder verdreifacht. Das tut es nicht. Da das Spiel keinen Single-Player-Modus hat, habe ich gedacht, dass es um einiges attraktiver ist, wenn man es online spielen kann. Also habe ich das Implementieren neuer Features abgebrochen und eine Weile lang (fragt nicht wie lang!) Zeit darin investiert, den Aufbau des Codes so zu ändern, um ihn auf Netzwerkfähigkeit vorzubereiten. Ich habe Dokumente gelesen, wie man ein XNA Spiel online spielbar macht, die ganzen Regelungen mit Einladungen, Statusanzeigen, Lobbys usw und dann mittendrin aufgegeben. Davon abgesehen, dass es die Komplexität des Spiels und die möglichen Fehlerquellen vervielfacht hätte, habe ich keine Möglichkeit gehabt, das Zeug vernünftig zu testen.
2. Der Grafikstil ist nicht so geworden, wie ich ihn haben wollte, und die Grafik an sich ist nicht gut. Ursprünglich hieß das Spiel Candy Wars. Ich wollte, dass die Spielelemente nach Bonbons und sonstige Süßigkeiten aussehen, ein wenig wie Candy Crush, und die Spielumgebungen Tischoberflächen oder sonstiges in etwa wie Micro-Machines von der Perspektive her. Bei den Hintergründen habe ich es nicht geschafft, Texturen zu machen, die den ganzen Bildschirm bedecken, stilisiert sind und trotzdem erkennbar, was sie darstellen. Wenn ich eher Richtung Fotorealismus ging, mit Fotos, über die ich ein paar Filter laufen liess, sah das zu häßlich aus. Also habe ich aus dem Thema Süßigkeiten das Thema Ölfarben gemacht und den Titel geändert. Die Grafik war dann auch nicht mehr aus 3D-Elementen gemacht sondern nur noch 2D. Die Kollisionsabfrage passiert aber immer noch wie ursprünglich in einem 3D-Koordinatensystem, das parallel zum Koordinatensystem der Grafik existiert.
3. Wenn ich auf das Netzwerkzeug verzichtet und das Spiel früher rausgebracht hätte, hätte ich meine Verkäufe wahrscheinlich allein dadurch vervielfacht, dass mehr Interesse an Indie Games auf der Xbox bestand. Zahlen, von anderen Leuten, die ich vor einiger Zeit gelesen habe, sagten, dass man ungefähr mit 8000 Downloads der Demo rechnen soll, wobei 1/10 in Verkäufen umgewandelt bin. Inzwischen sind wir bei 1000 Downloads angekommen.
Die angegebenen verkauften Einheiten müssen laut Microsoft in dieser Darstellung nicht stimmen. Nur das Geld, das man kriegt, ist ausschlaggebend.
Wenn man die fehlenden Einheiten dieses Jahres dazurechnet, dann kommt man darauf, dass etwas weniger als 10% der Demos in Verkäufen umgewandelt wurden, was zu erwarten ist, wenn man ein Multiplayer-only Spiel macht, das solide aber spielerisch weder besonders reichhaltig, noch optisch ansprechend ist.
Zu diesem Zeitpunkt sind die Verkäufe also wie zu erwarten aber trotzdem ist es verdammt wenig.
Schlusswort
Habe ich meine Ziele erreicht? Ich habe das Spiel tatsächlich fertiggestellt. Ich habe ein Konsolenspiel gemacht. Es taugt. Ich habe nichts neues über 3D-Modellierungsprogramme gelernt und das bißchen, das ich gelernt habe, habe ich vergessen. Und XSI Softimage wird sterben.
Die größte Erkenntnis ist, dass ich bei den Zielen noch zwei zusätzliche Sachen aufnehmen sollte.
Erstens spielt es nicht nur eine Rolle, dass der netto Zeitaufwand für das Spiel gering ist. Wenn ich Vollzeit daran gearbeitet hätte, dann wäre ich in 1 oder 2 Monaten fertig. Wichtig ist auch, dass das Ende und der Anfang des Projekts nicht zu weit auseinanderliegen. Die Lebenszeit des Menschen ist begrenzt und man sollte nicht zuviel Zeit an Sachen verschwenden, dessen Chancen, erfolgreich zu sein, gering sind. Schnelle Iterationen sind nötig. Ich war in der Zeit nicht unbedingt faul. Ich habe es innerhalb von drei Jahren geschafft, vom Salsa-Nichtskönner zum bezahlten Salsa-Tanzlehrer zu werden, aber Paint Wars hat mich in dieser Zeit nicht glücklicher gemacht. Es war eine Sache in der Ecke meines Bewusstseins, an die ich immer denken musste, dass sie beendet werden soll, auf die ich aber keine großartige Lust hatte.
Warum hatte ich darauf keine Lust? Das Hauptkriterium war wie bei Dreieck23, dass das Spiel einen Umfang hat, dass es fertiggestellt werden kann. Beide Spiele waren aber keine, die ich selbst spielen wollte. Ein weiteres Ziel ist also, ein Spiel zu machen, das ich spielen will.
Als letztes Ziel sollte ich darauf abzielen, Spiele zu machen, die erfolgreich sein können. Damit ist nicht nur das Spieldesign sondern auch der Markt gemeint, womit XNA gleich am Anfang ausfallen sollte. Ich habe das bewusst gewählt und ich wusste von vorne rein, dass mir Paint Wars kein Geld einbringen wird und das tut mir auch nicht weh. Was unerwartet weh tut, ist wie wenig Leute das Spiel spielen, wenn man bedenkt, wie lange es gedauert hat, bis es fertig war. Ich habe keine Statistiken über Dreieck23 aber ich denke, Paint Wars ist verhältnismäßig erfolgreicher, also ist das schonmal gut.
Damit ich die neuen Ziele besser erreichen kann, werde ich in Zukunft Tools benutzen, mit denen ich weniger programmieren muss und schneller zum Ergebnis komme. Ich habe Unreal Engine 3 runtergeladen aber die Funktionen dort erschienen mir zu umfangreich. Unity ist übersichtlicher. Im letzten Steam-Sale habe ich GameMaker Studio gekauft und gehe jetzt die Tutorials durch. Letzteres scheint recht beschränkt zu sein aber wahrscheinlich werde ich es für die nächsten zwei, drei Spiele benutzen und mit den Beschränkungen arbeiten lernen. Ich will halt keinen eigenen Leveleditor programmieren, weil es nichts bringt.
Mike Acton von Insomniac hat unter anderem gesagt, dass man seine Zeit in Sachen stecken sollte, die man besser als andere machen kann. Auch wenn ein richtiger Mann alles selbst macht, wird mein Spiel besser, wenn ich meinen eigenen Leveleditor programmiere, obwohl zig andere schon existieren, die ich nutzen kann? Eher nicht. Ich bin über die Phase hinaus, wo ich etwas lernen würde (z.B. das Design von Level-Editoren) nur damit ich es weiß. Ich werde jedes vorhandene Werkzeug benutzen, das mich schneller zum Ziel bringt.
Die Lektion von Paint Wars ist: das Leben währt nicht ewig, verschwende es nicht!
Samstag, 23. Februar 2013
Paint Wars
Es ist ein wenig deprimierend. Oder auch nicht. Die Entwicklung von Candy Wars, das inzwischen Paint Wars heißt, hat vor vier Jahren angefangen. In dem Spiel stecken vielleicht zusammengezählt vier Wochen Vollzeitarbeit drin. Für jemanden, der schon einen Job hat, ist das ganze natürlich nicht in einem Monat zu machen, aber vier Monate wären realistisch statt vier Jahre. Dafür bin ich in den letzten zwei Jahren zu einem ordentlichen Salsa-Tänzer geworden. Das macht dann mehr Frauen als Männer glücklich...
Schauen wir mal, was ich letztes Mal geschrieben habe, was ich noch machen will:
- Farbe oder Aussehen der Extras ändern, damit sie "einladender" aussehen.
Ich kann mich nicht mal erinnern, wann ich das gemacht habe. Das war wahrscheinlich kein Ding.
- Sortierung der Spieler in der Ergebnistabelle nach Score.
Äh, ich glaube, dass ich das doch gemacht habe.
- 2-4 zusätzliche Extrawaffen.
Es sind insgesamt drei drin. Die große Unbekannte sind die Bomben, die über Wände gehen und einen größeren Wirksamkeitsradius haben. Damit gab es zwei Probleme. Mit einem festen Abstand, den die Bomben zurücklegen, war es schwierig, Leute zu treffen, die auf der anderen Seite der Wand "kleben", weil sie zu nah dran sind. Sah etwas bescheuert aus, dass man da nichts machen konnte. oder jemand hat sich in die Ecke verschanzt und der Bombenwerfer hinter der Wand hat ihn einerseits nicht erreicht, andererseits, hat er dem anderen keine Chance gegeben, sich von der Ecke zu lösen. Also habe ich es gemacht, dass die maximale Reichweite der Bomben größer wird, und dass man mit der Stärke der Eingabe des rechten Sticks bestimmen kann, wie weit die Bombe geht. Das ganze ist sehr schwierig zu steuern, deswegen habe ich den Bomben etwas mehr Schaden gegeben.
- Mehr Musik und zusätzliche Soundeffekte.
Drei Musikstücke, die man hier schon anhören dürfte. Das Feedback habe ich benutzt, um ein paar nervige Sachen zu entfernen. Mein oberstes Ziel war, daß die Musik nicht nervt. Ich bin (noch) nicht gut im komponieren und kann auch keine richtigen Sequencer bedienen.
- Ein animiertes Intro das zum Titelbildschirm führt.
Das Intro ist das beste am ganzen Spiel. Das Spiel an sich finde ich OK aber das Intro könnte ich in der Endlosschleife anschauen und es würde mich trotzdem zum grinsen bringen.
So wie das Spiel an sich ist es erstaunlich, wie sehr es meiner ursprünglichen Vision entspricht.
- Ein Logo malen und einbauen.
Ist drin. Sieht nett aus.
- Menüs ausbauen, ansehbar machen und zum funktionieren bringen.
Ist alles drin, nur gefällt mir das Aussehen nicht so. Ich habe aber keine Idee, wie ich das mit wenig Aufwand verbessern könnte, und es ist mir auch nicht wichtig genug.
- Erhebung von Spielstatistiken und speichern auf der Festplatte?
Das habe ich aufgegeben und ich werde es bereuen, falls das Spiel doch beliebt sein sollte. Der Indie-Kanal ist aber inzwischen tot von Minecraft-Klonen abgesehen.
- Online Modus?
Hahaha, ich habe ein paar Monate mit Refactoring verschwendet, damit ich den Code auf den Einbau von online-Spielen vorbereite. Am Ende wollte ich mich nur noch dem nächsten Spiel widmen, also habe ich das gelassen.
Die Dinge, mit denen ich mich zuletzt beschäftigt habe, war ein Fehler, den ich im letzten Moment entdeckt habe, und zwar konnte man Gegner treffen, die sich auf der anderen Seite der Wand befanden. Zum Teil war da die XNA-Funktion schuld, die herausfindet, ob eine Gerade eine Kugel schneidet. Sie liefert zum Teil positive Ergebnisse zurück, wenn der Abstand zu groß ist, aber weil sie den Abstand als Zahl auch liefert, konnte ich eine zusätzliche, manuelle Prüfung machen. Ich habe mehr als eine Stunde gebraucht, um auf so eine triviale Lösung zu kommen, was mich im nachhinein verwirrt. Also es verwirrt mich, wie verwirrt ich gewesen bin.
Was ich zuletzte noch gemacht habe, war zu entscheiden und zu implementieren, worauf die Spieler Zugang haben, wenn sie das Spiel als Demo benutzen. Es kommt auch ein zusätzlicher Menüpunkt, der einen zum Kauffenster führt.
Ich werde das Spiel morgen zur Prüfung vorlegen. Das einzige, was mir Sorgen bereitet ist, wenn es nicht durchkommt, weil die Tester finden, dass nicht alle relevanten Spielinformationen in Röhrenfernsehern zu sehen sind. Wegen ihrer Natur muß man davon ausgehen, daß Röhrenfernseher so eingestellt sind, daß bis zu 10% Informationen an jedem Rand fehlen. In diesen 10% an Pixeln am Rand dürfen keine relevanten Spielinformationen sein.
Drückt mir die Daumen!
Schauen wir mal, was ich letztes Mal geschrieben habe, was ich noch machen will:
- Farbe oder Aussehen der Extras ändern, damit sie "einladender" aussehen.
Ich kann mich nicht mal erinnern, wann ich das gemacht habe. Das war wahrscheinlich kein Ding.
- Sortierung der Spieler in der Ergebnistabelle nach Score.
Äh, ich glaube, dass ich das doch gemacht habe.
- 2-4 zusätzliche Extrawaffen.
Es sind insgesamt drei drin. Die große Unbekannte sind die Bomben, die über Wände gehen und einen größeren Wirksamkeitsradius haben. Damit gab es zwei Probleme. Mit einem festen Abstand, den die Bomben zurücklegen, war es schwierig, Leute zu treffen, die auf der anderen Seite der Wand "kleben", weil sie zu nah dran sind. Sah etwas bescheuert aus, dass man da nichts machen konnte. oder jemand hat sich in die Ecke verschanzt und der Bombenwerfer hinter der Wand hat ihn einerseits nicht erreicht, andererseits, hat er dem anderen keine Chance gegeben, sich von der Ecke zu lösen. Also habe ich es gemacht, dass die maximale Reichweite der Bomben größer wird, und dass man mit der Stärke der Eingabe des rechten Sticks bestimmen kann, wie weit die Bombe geht. Das ganze ist sehr schwierig zu steuern, deswegen habe ich den Bomben etwas mehr Schaden gegeben.
- Mehr Musik und zusätzliche Soundeffekte.
Drei Musikstücke, die man hier schon anhören dürfte. Das Feedback habe ich benutzt, um ein paar nervige Sachen zu entfernen. Mein oberstes Ziel war, daß die Musik nicht nervt. Ich bin (noch) nicht gut im komponieren und kann auch keine richtigen Sequencer bedienen.
- Ein animiertes Intro das zum Titelbildschirm führt.
Das Intro ist das beste am ganzen Spiel. Das Spiel an sich finde ich OK aber das Intro könnte ich in der Endlosschleife anschauen und es würde mich trotzdem zum grinsen bringen.
So wie das Spiel an sich ist es erstaunlich, wie sehr es meiner ursprünglichen Vision entspricht.
- Ein Logo malen und einbauen.
Ist drin. Sieht nett aus.
- Menüs ausbauen, ansehbar machen und zum funktionieren bringen.
Ist alles drin, nur gefällt mir das Aussehen nicht so. Ich habe aber keine Idee, wie ich das mit wenig Aufwand verbessern könnte, und es ist mir auch nicht wichtig genug.
- Erhebung von Spielstatistiken und speichern auf der Festplatte?
Das habe ich aufgegeben und ich werde es bereuen, falls das Spiel doch beliebt sein sollte. Der Indie-Kanal ist aber inzwischen tot von Minecraft-Klonen abgesehen.
- Online Modus?
Hahaha, ich habe ein paar Monate mit Refactoring verschwendet, damit ich den Code auf den Einbau von online-Spielen vorbereite. Am Ende wollte ich mich nur noch dem nächsten Spiel widmen, also habe ich das gelassen.
Die Dinge, mit denen ich mich zuletzt beschäftigt habe, war ein Fehler, den ich im letzten Moment entdeckt habe, und zwar konnte man Gegner treffen, die sich auf der anderen Seite der Wand befanden. Zum Teil war da die XNA-Funktion schuld, die herausfindet, ob eine Gerade eine Kugel schneidet. Sie liefert zum Teil positive Ergebnisse zurück, wenn der Abstand zu groß ist, aber weil sie den Abstand als Zahl auch liefert, konnte ich eine zusätzliche, manuelle Prüfung machen. Ich habe mehr als eine Stunde gebraucht, um auf so eine triviale Lösung zu kommen, was mich im nachhinein verwirrt. Also es verwirrt mich, wie verwirrt ich gewesen bin.
Was ich zuletzte noch gemacht habe, war zu entscheiden und zu implementieren, worauf die Spieler Zugang haben, wenn sie das Spiel als Demo benutzen. Es kommt auch ein zusätzlicher Menüpunkt, der einen zum Kauffenster führt.
Ich werde das Spiel morgen zur Prüfung vorlegen. Das einzige, was mir Sorgen bereitet ist, wenn es nicht durchkommt, weil die Tester finden, dass nicht alle relevanten Spielinformationen in Röhrenfernsehern zu sehen sind. Wegen ihrer Natur muß man davon ausgehen, daß Röhrenfernseher so eingestellt sind, daß bis zu 10% Informationen an jedem Rand fehlen. In diesen 10% an Pixeln am Rand dürfen keine relevanten Spielinformationen sein.
Drückt mir die Daumen!
Freitag, 29. Oktober 2010
Candy Wars v0.3 Download
Hier ist der Download, falls es jemand eilig hat. Feedback wie immer erwünscht. Ich werde jetzt etwas über die Hintergründe des Spiels erzählen und dann zunehmend spezifische Sachen über die aktuellen Schritte:
Nachdem Dreieck23 fertig war und es keiner spielen wollte, habe ich mir als Ziel gesetzt, ein Spiel zu machen, das mindestens ein paar Personen spielen wollen. Death Tank war ein guter Kandidat, weil das Spiel schon ein eingebautes Publikum hatte: meine Freunde. Dazu kam, daß die einzig existierende Version auf dem Saturn lief und keiner noch einen Saturn aufgebaut haben wollte. Ich habe drei Versuche gemacht, Death Tank zu implementieren. Die erste Version war in C++ und OpenGL und ich kann mich nicht erinnern, warum ich aufgehört habe. Vermutlich, weil man keine 4 Leute vor einem PC setzen kann. Der zweite Versuch war mit Java. Ich wollte eine online-spielbare Version machen, die auf mehreren Plattformen lief, weil die Hälfte des Publikums nur Macs hatte. Damit habe ich aufgehört, als ein Test klargemacht hat, daß der Mac, der dreimal leistungsfähiger als mein PC war mit der Hälfte der Framerate lief (also mit unter 15FPS) wenn ihm Java die Anweisung gegeben hat, in jedem Frame tausend senkrechte Linien zu zeichnen. War echt zuviel verlangt.
Der dritte Versuch war mit XNA, weil es endlich die Gelegenheit gab, vier Spieler lokal vor der Plattform zu sammeln, auf der das Spiel läuft. Glücklicherweise kam dann eine offizielle Version von Death Tank raus, weil es die Hölle ist, richtige Reaktionen zu programmieren, wenn ein Trapez auf einem Boden mit beliebiger Form landet.
Eine Idee, die ich immer im Hinterkopf hatte, war, daß Geometry Wars und co nichts anderes als plattgedrückte Egoshooter sind. Wenn man ihnen die Höhendimension entzieht und die Spielmechanik an sich betrachtet, dann ist das herausstechendste Merkmal, daß die Richtung, in der man schießt, völlig unabhängig von der Richtung, in der man läuft, ist. Das fällt einem noch mehr auf, wenn man Doom komplett mit der Tastatur durchspielt, nur um viel später zu entdecken, wie andere Leute Quake mit Maus und Tastatur spielen. Wenn also Geometry Wars und ähnliches plattgedrückte Egoshooter sind, wo ist das plattgedrückte Quake 3 und Unreal Tournament?
Damit wurde habe ich den Versuch angefangen, Arenashooterprinzipien in einem Spiel mit Geometry Wars Steuerung zu übertragen:
- Anforderungen an gleichzeitigem zielen und ausweichen.
- Übersichtliche bis primitive "Labyrinthe", in denen man sich bewegt.
- Extrawaffen mit bestimmter Platzierung, die Hotspots in den Maps erschaffen, die Risiko mit mehr Feuerkraft belohnen.
Es hätte total in die Hose gehen können aber mit Glück oder Intuition habe ich auf Anhieb sehr spielbare Mechanik auf die Beine gestellt. Ein gutes Zeichen war, daß die Hände eines Freunds geschwitzt haben, während er gegen mich gespielt hat. Ein weiteres Zeichen, daß ein anderer Freund Tränen in den Augen hatte. Selbst die letzte Version, die ich zum Download angeboten habe, war für einige Leute spannend genug, obwohl die Scorevergabe quasi unsichtbar und nicht nachvollziehbar war. Inzwischen habe ich eine vernünftige Ergebnistabelle nach jeder Runde und eine in-game Anzeige mit gewonnenen Punkten, die die Motivation des Spiels gehörig aufwerten dürfte.
Was ich noch seit dem letzten Mal gemacht habe, ist die erste Extrawaffe mit den abprallenden Schüssen. Das war glaube ich letztes Mal nicht drin. Ich habe Hintergründe gemalt mit meinem neugekauften Wacom Bamboo und dem Programm ArtRage. Ich habe Intro-animationen für Schiffe, Wände und Extras eingebaut.
Als nächstes steht folgendes an:
- Farbe oder Aussehen der Extras ändern, damit sie "einladender" aussehen.
- Sortierung der Spieler in der Ergebnistabelle nach Score.
- 2-4 zusätzliche Extrawaffen.
- Mehr Musik und zusätzliche Soundeffekte.
- Ein animiertes Intro das zum Titelbildschirm führt.
- Ein Logo malen und einbauen.
- Menüs ausbauen, ansehbar machen und zum funktionieren bringen.
- Erhebung von Spielstatistiken und speichern auf der Festplatte?
- Online Modus?
Außerhalb des Spiels muß noch folgendes gemacht werden:
- "Verpackungsbild" für das Xbox Marketplace
- Trailer
- Webseite mit ein paar Screenshots, Links und Infos
Uff!
Nachdem Dreieck23 fertig war und es keiner spielen wollte, habe ich mir als Ziel gesetzt, ein Spiel zu machen, das mindestens ein paar Personen spielen wollen. Death Tank war ein guter Kandidat, weil das Spiel schon ein eingebautes Publikum hatte: meine Freunde. Dazu kam, daß die einzig existierende Version auf dem Saturn lief und keiner noch einen Saturn aufgebaut haben wollte. Ich habe drei Versuche gemacht, Death Tank zu implementieren. Die erste Version war in C++ und OpenGL und ich kann mich nicht erinnern, warum ich aufgehört habe. Vermutlich, weil man keine 4 Leute vor einem PC setzen kann. Der zweite Versuch war mit Java. Ich wollte eine online-spielbare Version machen, die auf mehreren Plattformen lief, weil die Hälfte des Publikums nur Macs hatte. Damit habe ich aufgehört, als ein Test klargemacht hat, daß der Mac, der dreimal leistungsfähiger als mein PC war mit der Hälfte der Framerate lief (also mit unter 15FPS) wenn ihm Java die Anweisung gegeben hat, in jedem Frame tausend senkrechte Linien zu zeichnen. War echt zuviel verlangt.
Der dritte Versuch war mit XNA, weil es endlich die Gelegenheit gab, vier Spieler lokal vor der Plattform zu sammeln, auf der das Spiel läuft. Glücklicherweise kam dann eine offizielle Version von Death Tank raus, weil es die Hölle ist, richtige Reaktionen zu programmieren, wenn ein Trapez auf einem Boden mit beliebiger Form landet.
Eine Idee, die ich immer im Hinterkopf hatte, war, daß Geometry Wars und co nichts anderes als plattgedrückte Egoshooter sind. Wenn man ihnen die Höhendimension entzieht und die Spielmechanik an sich betrachtet, dann ist das herausstechendste Merkmal, daß die Richtung, in der man schießt, völlig unabhängig von der Richtung, in der man läuft, ist. Das fällt einem noch mehr auf, wenn man Doom komplett mit der Tastatur durchspielt, nur um viel später zu entdecken, wie andere Leute Quake mit Maus und Tastatur spielen. Wenn also Geometry Wars und ähnliches plattgedrückte Egoshooter sind, wo ist das plattgedrückte Quake 3 und Unreal Tournament?
Damit wurde habe ich den Versuch angefangen, Arenashooterprinzipien in einem Spiel mit Geometry Wars Steuerung zu übertragen:
- Anforderungen an gleichzeitigem zielen und ausweichen.
- Übersichtliche bis primitive "Labyrinthe", in denen man sich bewegt.
- Extrawaffen mit bestimmter Platzierung, die Hotspots in den Maps erschaffen, die Risiko mit mehr Feuerkraft belohnen.
Es hätte total in die Hose gehen können aber mit Glück oder Intuition habe ich auf Anhieb sehr spielbare Mechanik auf die Beine gestellt. Ein gutes Zeichen war, daß die Hände eines Freunds geschwitzt haben, während er gegen mich gespielt hat. Ein weiteres Zeichen, daß ein anderer Freund Tränen in den Augen hatte. Selbst die letzte Version, die ich zum Download angeboten habe, war für einige Leute spannend genug, obwohl die Scorevergabe quasi unsichtbar und nicht nachvollziehbar war. Inzwischen habe ich eine vernünftige Ergebnistabelle nach jeder Runde und eine in-game Anzeige mit gewonnenen Punkten, die die Motivation des Spiels gehörig aufwerten dürfte.
Was ich noch seit dem letzten Mal gemacht habe, ist die erste Extrawaffe mit den abprallenden Schüssen. Das war glaube ich letztes Mal nicht drin. Ich habe Hintergründe gemalt mit meinem neugekauften Wacom Bamboo und dem Programm ArtRage. Ich habe Intro-animationen für Schiffe, Wände und Extras eingebaut.
Als nächstes steht folgendes an:
- Farbe oder Aussehen der Extras ändern, damit sie "einladender" aussehen.
- Sortierung der Spieler in der Ergebnistabelle nach Score.
- 2-4 zusätzliche Extrawaffen.
- Mehr Musik und zusätzliche Soundeffekte.
- Ein animiertes Intro das zum Titelbildschirm führt.
- Ein Logo malen und einbauen.
- Menüs ausbauen, ansehbar machen und zum funktionieren bringen.
- Erhebung von Spielstatistiken und speichern auf der Festplatte?
- Online Modus?
Außerhalb des Spiels muß noch folgendes gemacht werden:
- "Verpackungsbild" für das Xbox Marketplace
- Trailer
- Webseite mit ein paar Screenshots, Links und Infos
Uff!
Montag, 30. August 2010
Dreieck23 Teil 3
(Hier ist Teil 1)
(Hier ist Teil 2)
Ich sollte aufhören, meine Zeit irgendwelcher Prinzipien wegen zu verschwenden und mich mehr darauf konzentrieren, nur das zu tun, was meine Aufgabe in schnellen Schritten voranbringt. Ich habe jahrelang versucht, in meinem Bemühen mehr über Computer und Betriebssysteme zu verstehen, Linux zu lernen und zu mögen. Ich bin sogar etwas in die slashdot-Propaganda eingestiegen. Linux hat sich bei mir bedankt, indem keine der Distributionen, die ich ausprobiert habe, bei mir jemals einwandfrei funktioniert hat.
Ich habe einige ausprobiert (debian, ubuntu, mandrake, suse, mandriva, fedora, red hat, knoppix... OK, jetzt bin ich deprimiert. Ich habe sie nie nachgezählt) und von jeder dieser Distribution habe ich durchschnittlich drei verschiedene Versionen ausprobiert. Ich habe nicht erwartet, daß sie von Haus aus funktionieren. Ich habe Stunden reingesteckt, um sie zum funktionieren zu bringen. Unter "funktionieren" verstehe ich, daß 3D-Grafik, Sound, Internet, Drucker und der Paketmanager arbeiten. Die einzige Distribution, die jemals funktioniert hat, war Mandrake Version 8.1 und das war auch nur für ein halbes Jahr. Meine Dummheit ist unendlich.
Der Gnadenschuß kam, als ich Dreieck23 auf Linux zum laufen bringen wollte. Ich bin davor schon mit einer IDE namens "Anjuta" in Berührung gekommen und habe sie erstmal angeschaut. Ich kann mich nicht erinnern, ob mich da noch mehr genervt hat, aber auf jeden Fall, war das Syntax-Highlighting per default so konfiguriert, daß rosa Schrift, fette Schrift und vermutlich auch Schriften in verschiedenen Größen zu sehen war. Das zu einem lesbaren Format umzukonfigurieren war mir zuviel Aufwand für die paar Zeilen, die ich anpassen mußte, so daß ich "KDevelop" eine Chance gegeben habe. KDevelop ist etwa zweimal pro Arbeitssession abgestürzt. Das beste war, daß plötzlich ein Bug aufgetaucht ist, der Windows nicht da war.
OpenGL hat einen Picking-Modus. Man schaltet den Picking-Modus ein, gibt OpenGL seine Mausposition oder eine sonstige Position auf dem Bildschirm an, lässt den Zeichencode einmal durchlaufen und gibt den Primitiven, die gezeichnet werden, einen Index, der nicht eindeutig sein muß. Am Ende der Zeichenoperationen sagt OpenGL einem, welche Indizes die Objekte haben, die von dem Strahl getroffen wurden, der von der angegebenen Bildschirmposition ausgeht. Dann schaltet man wieder auf den normalen Zeichenmodus zurück. Ich habe den Picking-Modus benutzt, um herauszufinden, wann man welche Dreiecke "getroffen" hat. Auf Linux hat sich das Spiel geweigert, vom Picking-Modus in den normalen Zeichenmodus zu gehen, wenn ich den Befehl, den Modus zu ändern, nicht zwei mal hintereinander ausgeführt habe!? Dabei muß man bedenken, daß ich damals eine nVidia Karte hatte, eine der beliebteren von nVidia und nVidia dafür bekannt war, linuxfreundlicher zu sein. Das ging so weit, daß die proprietären Treiber von nVidia mit dem Paketmanager jeder Distribution gefunden werden konnten und die von ATI nicht.
Mit der Zeit habe ich zunehmend Microsoft Mitarbeiter Blogs besucht und zu schätzen gelernt, wie leidenschaftlich viele Menschen hinter der Microsoft Fassade sind, wie ehrlich und vernünftig sie rüberkommen, welche schwierigen Entscheidungen sie treffen müssen und wieviel Schelte sie dafür zum Dank bekommen, obwohl sie versuchen, es gleichzeitig 15 Milliarden Leuten recht zu machen und jede ihrer Entscheidungen grundsätzlich für irgendjemanden falsch ist. Lest die Kommentare und nehmt euch vor, nie wieder einer von denen zu sein.
Wie auch immer. Eine Linux Version von Dreieck23... habe ich eigentlich erzählt, woher die Zahl kommt? Die Levels werden durch eine Textdatei beschrieben, in der in jeder Zeile steht, wann wo ein Dreieck mit welcher Ursprungsgeschwindigkeit und Farbe erscheint. Die Dreiecke wurden numeriert. Irgendwann bin ich auf einen Bug gestoßen, bei dem das Spiel ab einem bestimmten Dreieck aufgehört hat zu funktionieren, und wenn ich mich recht erinnere, war es Dreieck 23. Ich habe mit der Entwicklung aufgehört und ein Jahr später hat mich ein Kollege gefragt, ob ich die Textdatei im ASCII- oder Binärmodus gelesen habe. Häh? Scheinbar wurde irgendeine Zahl als der entsprechende ASCII Code interpretiert oder sowas. Ich habe es nicht nachverfolgt, weil das Spiel funktioniert hat, sobald ich auf den Binärmodus umgestiegen bin, ich habe aber bestimmt irgendwas dummes gemacht. Ein Jahr danach wurde die Entwicklung also wieder aufgenommen und kurze *hust* Zeit später beendet. Eine Linux Version gab es dazu auch.
Wenn man die Liste der Erkenntnisse aus dem letzten Posting liest, könnte man meinen, daß ich den Spielern vorwerfe, nicht über die abstrakte Grafik hinweg und die Schönheit der Funktionalität meines Spiels zu sehen. Aber Vorsicht! Das stimmt nicht. Die übergeordnete Erkenntis ist, daß die Funktionatlität des Spiels nur die Basis ist und man etwas darauf bauen muß, das Gefühle auslöst, sei es mit einer Geschichte, hübscher Grafik, interessanten Gegnern, mehr Charakter usw. Dreieck23 hat zuwenig von diesem Rest. Und dieser Rest reicht bei bestimmten Spielen für bestimmte Spieler, damit sie grobe Mängel in der Funktionalität übersehen.
Der Plan für das Spiel nach Dreieck23 war, daß ich mir trauen werde, etwas zu machen, das ein Stück aufwendiger ist, und mich dann von Projekt zu Projekt "hocharbeite". Dazu kam später die Anforderung, daß es ein Spiel sein muß, das ich selbst spielen würde. Das mag vielleicht nicht so wichtig sein, wenn man für die Arbeit bezahlt wird, aber für die Motivation, irgendwas in der Freizeit zu machen, ist es unerlässlich.
Bald widmen wir uns wieder dem aktuellen Stand von Candy Wars.
(Hier ist Teil 2)
Ich sollte aufhören, meine Zeit irgendwelcher Prinzipien wegen zu verschwenden und mich mehr darauf konzentrieren, nur das zu tun, was meine Aufgabe in schnellen Schritten voranbringt. Ich habe jahrelang versucht, in meinem Bemühen mehr über Computer und Betriebssysteme zu verstehen, Linux zu lernen und zu mögen. Ich bin sogar etwas in die slashdot-Propaganda eingestiegen. Linux hat sich bei mir bedankt, indem keine der Distributionen, die ich ausprobiert habe, bei mir jemals einwandfrei funktioniert hat.
Ich habe einige ausprobiert (debian, ubuntu, mandrake, suse, mandriva, fedora, red hat, knoppix... OK, jetzt bin ich deprimiert. Ich habe sie nie nachgezählt) und von jeder dieser Distribution habe ich durchschnittlich drei verschiedene Versionen ausprobiert. Ich habe nicht erwartet, daß sie von Haus aus funktionieren. Ich habe Stunden reingesteckt, um sie zum funktionieren zu bringen. Unter "funktionieren" verstehe ich, daß 3D-Grafik, Sound, Internet, Drucker und der Paketmanager arbeiten. Die einzige Distribution, die jemals funktioniert hat, war Mandrake Version 8.1 und das war auch nur für ein halbes Jahr. Meine Dummheit ist unendlich.
Der Gnadenschuß kam, als ich Dreieck23 auf Linux zum laufen bringen wollte. Ich bin davor schon mit einer IDE namens "Anjuta" in Berührung gekommen und habe sie erstmal angeschaut. Ich kann mich nicht erinnern, ob mich da noch mehr genervt hat, aber auf jeden Fall, war das Syntax-Highlighting per default so konfiguriert, daß rosa Schrift, fette Schrift und vermutlich auch Schriften in verschiedenen Größen zu sehen war. Das zu einem lesbaren Format umzukonfigurieren war mir zuviel Aufwand für die paar Zeilen, die ich anpassen mußte, so daß ich "KDevelop" eine Chance gegeben habe. KDevelop ist etwa zweimal pro Arbeitssession abgestürzt. Das beste war, daß plötzlich ein Bug aufgetaucht ist, der Windows nicht da war.
OpenGL hat einen Picking-Modus. Man schaltet den Picking-Modus ein, gibt OpenGL seine Mausposition oder eine sonstige Position auf dem Bildschirm an, lässt den Zeichencode einmal durchlaufen und gibt den Primitiven, die gezeichnet werden, einen Index, der nicht eindeutig sein muß. Am Ende der Zeichenoperationen sagt OpenGL einem, welche Indizes die Objekte haben, die von dem Strahl getroffen wurden, der von der angegebenen Bildschirmposition ausgeht. Dann schaltet man wieder auf den normalen Zeichenmodus zurück. Ich habe den Picking-Modus benutzt, um herauszufinden, wann man welche Dreiecke "getroffen" hat. Auf Linux hat sich das Spiel geweigert, vom Picking-Modus in den normalen Zeichenmodus zu gehen, wenn ich den Befehl, den Modus zu ändern, nicht zwei mal hintereinander ausgeführt habe!? Dabei muß man bedenken, daß ich damals eine nVidia Karte hatte, eine der beliebteren von nVidia und nVidia dafür bekannt war, linuxfreundlicher zu sein. Das ging so weit, daß die proprietären Treiber von nVidia mit dem Paketmanager jeder Distribution gefunden werden konnten und die von ATI nicht.
Mit der Zeit habe ich zunehmend Microsoft Mitarbeiter Blogs besucht und zu schätzen gelernt, wie leidenschaftlich viele Menschen hinter der Microsoft Fassade sind, wie ehrlich und vernünftig sie rüberkommen, welche schwierigen Entscheidungen sie treffen müssen und wieviel Schelte sie dafür zum Dank bekommen, obwohl sie versuchen, es gleichzeitig 15 Milliarden Leuten recht zu machen und jede ihrer Entscheidungen grundsätzlich für irgendjemanden falsch ist. Lest die Kommentare und nehmt euch vor, nie wieder einer von denen zu sein.
Wie auch immer. Eine Linux Version von Dreieck23... habe ich eigentlich erzählt, woher die Zahl kommt? Die Levels werden durch eine Textdatei beschrieben, in der in jeder Zeile steht, wann wo ein Dreieck mit welcher Ursprungsgeschwindigkeit und Farbe erscheint. Die Dreiecke wurden numeriert. Irgendwann bin ich auf einen Bug gestoßen, bei dem das Spiel ab einem bestimmten Dreieck aufgehört hat zu funktionieren, und wenn ich mich recht erinnere, war es Dreieck 23. Ich habe mit der Entwicklung aufgehört und ein Jahr später hat mich ein Kollege gefragt, ob ich die Textdatei im ASCII- oder Binärmodus gelesen habe. Häh? Scheinbar wurde irgendeine Zahl als der entsprechende ASCII Code interpretiert oder sowas. Ich habe es nicht nachverfolgt, weil das Spiel funktioniert hat, sobald ich auf den Binärmodus umgestiegen bin, ich habe aber bestimmt irgendwas dummes gemacht. Ein Jahr danach wurde die Entwicklung also wieder aufgenommen und kurze *hust* Zeit später beendet. Eine Linux Version gab es dazu auch.
Wenn man die Liste der Erkenntnisse aus dem letzten Posting liest, könnte man meinen, daß ich den Spielern vorwerfe, nicht über die abstrakte Grafik hinweg und die Schönheit der Funktionalität meines Spiels zu sehen. Aber Vorsicht! Das stimmt nicht. Die übergeordnete Erkenntis ist, daß die Funktionatlität des Spiels nur die Basis ist und man etwas darauf bauen muß, das Gefühle auslöst, sei es mit einer Geschichte, hübscher Grafik, interessanten Gegnern, mehr Charakter usw. Dreieck23 hat zuwenig von diesem Rest. Und dieser Rest reicht bei bestimmten Spielen für bestimmte Spieler, damit sie grobe Mängel in der Funktionalität übersehen.
Der Plan für das Spiel nach Dreieck23 war, daß ich mir trauen werde, etwas zu machen, das ein Stück aufwendiger ist, und mich dann von Projekt zu Projekt "hocharbeite". Dazu kam später die Anforderung, daß es ein Spiel sein muß, das ich selbst spielen würde. Das mag vielleicht nicht so wichtig sein, wenn man für die Arbeit bezahlt wird, aber für die Motivation, irgendwas in der Freizeit zu machen, ist es unerlässlich.
Bald widmen wir uns wieder dem aktuellen Stand von Candy Wars.
Freitag, 27. August 2010
Dreieck23 Teil 2
(Teil 1)
George Michael wurde mal gefragt, wie er herausgefunden hat, daß er Musiker werden könnte. Er sagte, er hat im Restaurant seiner Eltern gearbeitet und Musik gehört. Ein Lied ist zu einem bestimmten Punkt in der Melodie gekommen und dann in einer Art weitergegangen, die schlechter war, als das was George in seinem Kopf hatte. Vielleicht denke ich mir das alles aus aber so ist es in meiner Erinnerung.
Das eine Mal, das ich Mohrhuhn gespielt habe, fand ich es ärgerlich, daß die weiter entfernten Mohrhühner unverhältnismäßig viele Punkte abgegeben haben. Soviele, daß es sich nicht gelohnt hat, sich mit den großen zu beschäftigen. Das "Problem" war, daß man, sobald man sich auf die kleinsten Hühner konzentriert hat, den Bildschirm sehr schnell von solchen geleert hat, und es vom Zufall abhing, wieviele davon erscheinen und ob man den richtigen Bildschirmausschnitt sieht, um möglichst viele im Sichtfeld zu haben. Nach drei Spielen oder so habe ich festgestellt, daß der Score weit mehr vom Zufall als vom Können abhing und damit ist mein Interesse frühzeitig verschwunden (20 Sekunden vor seiner Zeit).
Mohrhuhn war beliebt und es wäre ein schöner Bonus, wenn Dreieck23 nicht nur fertig wird sondern auch von jemanden gespielt wird. Wie verbessern wir Mohnhuhn? Meine Herangehensweise war, den Zufall zu eliminieren, indem ich als Entwickler bestimme, in welcher Reihefolge die Ziele kommen. Ein Punktesystem, das den Spieler für seine Mühe belohnt, und zwar wenn er sich geschickt anstellt und das Spiel lernt. Vielschichtigkeit im Gameplay, indem man für zwei Ziele gleichzeitig kämpft, die im Konflikt stehen: 1. überleben 2. Score erhöhen.
Deswegen fallen die Dreiecke von der Gravitation angezogen auf dem Boden. Wenn 5 Dreiecke den Boden berühren, dann hat man verloren. Ziel Nr 1. Wenn man mehrere Dreiecke hintereinander abschiesst, die dieselbe Farbe haben, dann steigt jedesmal die Punktanzahl, die man für jedes abgeschossene Dreieck kriegt. Mit dem Leveldesign sorge ich dafür, daß gleichfarbige Dreiecke zunehmend mit größerem Abstand kommen, so daß es immer riskanter wird, auf das gleichfarbige Dreieck zu warten, während eins mit einer anderen Farbe sich dem Boden nähert. Wenn man sich freiwillig ins Risiko stürzt, dann wird man mit einem höheren Score belohnt. Ziel Nr 2.
Ich brauchte keine Grafik, weil das Spielprinzip auch mit Dreiecken funktioniert, das Leveldesign sind quasi ein paar Text-Dateien und ich kam mit sehr wenig OpenGL für die Darstellung und SDL für die Fensterverwaltung, Sound und Eingabe aus. Die Musik hat der Bicycle Repair Man gemacht, bei dem ich mich, glaube ich, noch nicht gebührend bedankt habe. In 5 Jahren vielleicht. Und das Spiel ist tatsächlich fertig geworden. Was habe ich daraus gelernt?
1. Keine Sau will heute abstrakte Grafik sehen.
Auch wenn sie einen vor häßlichen Hühnern rettet.
2. Kein Schwein hat guten Geschmack.
Genug guten Geschmack, um die Hühner häßlich zu finden.
3. Kein Depp legt Wert auf eine genaue Abbildung der Leistung des Spielers auf das Ergebnis im Spiel.
Zumindest sind es weit weniger Leute als man denkt. Der größte Teil ist in dieser Hinsicht sehr tolerant.
4. Vielschichtigkeit wird überbewertet.
Ein Waffenarsenal, das aus Variationen einer einzigen Waffe besteht, und eine Sorte Feind reicht aus, um 40 Mio Call of Dutys zu verkaufen.
5. Manche Kundengruppen schließen sich aus.
EA kann kein Madden auf der Wii verkaufen. Madden-Spieler wollen nicht fuchteln und das Wii-Publikum will keine komplizierten Sportspiele spielen. Dadurch, daß die Entwickler Aspekte aus beiden Welten vereinigen, bringen sie die Spieler nicht zusammen sondern scheuchen sie mit Eigenschaften, die die jeweilige Gruppe nicht will aus.
Genauso kann ich nicht Moorhuhnspieler und ernsthafte Scorejäger zu einem Publikum vereinigen. Dem Moorhuhnspieler ist das zu kompliziert, abstrakt und schwierig, der ernsthafte Scorejäger will durch etwas beansprucht werden, das über das Niveau eines Lightgunshooters light (he!) hinausgeht.
6. Ich bin dumm.
Zwei Jahre lang dachte ich, daß das Spiel ein unlösbares Problem hatte, und zwar zwingt das Spieldesign ein Mindestmaß an Schwierigkeit, das zu schwer ist. Da ich im Leveldesign sehr früh dazu gezwungen bin, viele Dreiecke gleichzeitig auf dem Schirm zu haben, damit das Scoresystem zum tragen kommt, muß der Spieler ziemlich gut sein, um mithalten zu können.
Erst zwei Jahre, nachdem das Spiel fertig war, ist mir eingefallen, daß ich eventuell vielleicht DIE STÄRKE DER GRAVITATION SENKEN KÖNNTE!
7. Linux ist scheiße.
(Erklärung folgt)
George Michael wurde mal gefragt, wie er herausgefunden hat, daß er Musiker werden könnte. Er sagte, er hat im Restaurant seiner Eltern gearbeitet und Musik gehört. Ein Lied ist zu einem bestimmten Punkt in der Melodie gekommen und dann in einer Art weitergegangen, die schlechter war, als das was George in seinem Kopf hatte. Vielleicht denke ich mir das alles aus aber so ist es in meiner Erinnerung.
Das eine Mal, das ich Mohrhuhn gespielt habe, fand ich es ärgerlich, daß die weiter entfernten Mohrhühner unverhältnismäßig viele Punkte abgegeben haben. Soviele, daß es sich nicht gelohnt hat, sich mit den großen zu beschäftigen. Das "Problem" war, daß man, sobald man sich auf die kleinsten Hühner konzentriert hat, den Bildschirm sehr schnell von solchen geleert hat, und es vom Zufall abhing, wieviele davon erscheinen und ob man den richtigen Bildschirmausschnitt sieht, um möglichst viele im Sichtfeld zu haben. Nach drei Spielen oder so habe ich festgestellt, daß der Score weit mehr vom Zufall als vom Können abhing und damit ist mein Interesse frühzeitig verschwunden (20 Sekunden vor seiner Zeit).
Mohrhuhn war beliebt und es wäre ein schöner Bonus, wenn Dreieck23 nicht nur fertig wird sondern auch von jemanden gespielt wird. Wie verbessern wir Mohnhuhn? Meine Herangehensweise war, den Zufall zu eliminieren, indem ich als Entwickler bestimme, in welcher Reihefolge die Ziele kommen. Ein Punktesystem, das den Spieler für seine Mühe belohnt, und zwar wenn er sich geschickt anstellt und das Spiel lernt. Vielschichtigkeit im Gameplay, indem man für zwei Ziele gleichzeitig kämpft, die im Konflikt stehen: 1. überleben 2. Score erhöhen.
Deswegen fallen die Dreiecke von der Gravitation angezogen auf dem Boden. Wenn 5 Dreiecke den Boden berühren, dann hat man verloren. Ziel Nr 1. Wenn man mehrere Dreiecke hintereinander abschiesst, die dieselbe Farbe haben, dann steigt jedesmal die Punktanzahl, die man für jedes abgeschossene Dreieck kriegt. Mit dem Leveldesign sorge ich dafür, daß gleichfarbige Dreiecke zunehmend mit größerem Abstand kommen, so daß es immer riskanter wird, auf das gleichfarbige Dreieck zu warten, während eins mit einer anderen Farbe sich dem Boden nähert. Wenn man sich freiwillig ins Risiko stürzt, dann wird man mit einem höheren Score belohnt. Ziel Nr 2.
Ich brauchte keine Grafik, weil das Spielprinzip auch mit Dreiecken funktioniert, das Leveldesign sind quasi ein paar Text-Dateien und ich kam mit sehr wenig OpenGL für die Darstellung und SDL für die Fensterverwaltung, Sound und Eingabe aus. Die Musik hat der Bicycle Repair Man gemacht, bei dem ich mich, glaube ich, noch nicht gebührend bedankt habe. In 5 Jahren vielleicht. Und das Spiel ist tatsächlich fertig geworden. Was habe ich daraus gelernt?
1. Keine Sau will heute abstrakte Grafik sehen.
Auch wenn sie einen vor häßlichen Hühnern rettet.
2. Kein Schwein hat guten Geschmack.
Genug guten Geschmack, um die Hühner häßlich zu finden.
3. Kein Depp legt Wert auf eine genaue Abbildung der Leistung des Spielers auf das Ergebnis im Spiel.
Zumindest sind es weit weniger Leute als man denkt. Der größte Teil ist in dieser Hinsicht sehr tolerant.
4. Vielschichtigkeit wird überbewertet.
Ein Waffenarsenal, das aus Variationen einer einzigen Waffe besteht, und eine Sorte Feind reicht aus, um 40 Mio Call of Dutys zu verkaufen.
5. Manche Kundengruppen schließen sich aus.
EA kann kein Madden auf der Wii verkaufen. Madden-Spieler wollen nicht fuchteln und das Wii-Publikum will keine komplizierten Sportspiele spielen. Dadurch, daß die Entwickler Aspekte aus beiden Welten vereinigen, bringen sie die Spieler nicht zusammen sondern scheuchen sie mit Eigenschaften, die die jeweilige Gruppe nicht will aus.
Genauso kann ich nicht Moorhuhnspieler und ernsthafte Scorejäger zu einem Publikum vereinigen. Dem Moorhuhnspieler ist das zu kompliziert, abstrakt und schwierig, der ernsthafte Scorejäger will durch etwas beansprucht werden, das über das Niveau eines Lightgunshooters light (he!) hinausgeht.
6. Ich bin dumm.
Zwei Jahre lang dachte ich, daß das Spiel ein unlösbares Problem hatte, und zwar zwingt das Spieldesign ein Mindestmaß an Schwierigkeit, das zu schwer ist. Da ich im Leveldesign sehr früh dazu gezwungen bin, viele Dreiecke gleichzeitig auf dem Schirm zu haben, damit das Scoresystem zum tragen kommt, muß der Spieler ziemlich gut sein, um mithalten zu können.
Erst zwei Jahre, nachdem das Spiel fertig war, ist mir eingefallen, daß ich eventuell vielleicht DIE STÄRKE DER GRAVITATION SENKEN KÖNNTE!
7. Linux ist scheiße.
(Erklärung folgt)
Dienstag, 24. August 2010
Dreieck23
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)
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)
Mittwoch, 16. Juni 2010
Beaterator
Ich habe nach einem Tool gesucht, mit dem ich für Candy Wars schnell ein paar Musikstücke machen kann. Vor ein paar Jahren habe ich CuBase ausprobiert, mich ein paar Minuten damit beschäftigt, nicht herausgefunden, wie man einfach ein Loop in das Lied setzt und aufgegeben.
Vor einer Weile habe ich parallel Beaterator für die PSP als Notlösung geholt und die Demo von Fruity Loops auf dem PC ausprobiert. Es stellt sich heraus, daß die Benutzeroberfläche von Fruity Loops so angenehm wie Lepra ist und Beaterator nicht nur Beats kann sondern eine für meine Anfängerkenntnisse vollwertige Sammlung von Sequencer, Synthesizer, Drumkit, Mastering-Werkzeug und wie man das Ding nennt, mit dem Melodien in Loops zusammenstellt. Das ganze mit einer Benutzeroberfläche bei der ich nicht wüßte, wie man sie auf der PSP verbessern kann, Tutorialvideos, die auch das Vokabular erklären und Geschenke vom Weihnachtsmann. Hardwarebedingte Beschränkungen sind die 8 Tracks, die man maximal gleichzeitig haben kann, auch wenn man pro Track mehrere Instrumente nacheinander benutzen kann, die maximal zwei Mastering-Effekte pro Track und daß die Hardwarebedienelemente nicht mal annähernd dafür taugen, mit Melodien zu experimentieren.
Und so habe ich drei Tracks zusammengestellt, die sehr wenig melodisch sind. Mein Idealvorstellung wäre sowas wie die chillige Musik von N+ (das diese Woche glaube ich im Angebot ist) allerdings ist mir mein Bedürfnis, das Mastering von fetten Beats zu beherrschen in die Quere gekommen. Dem Mastering von fetten Beats ist die Quere gekommen, daß ich Drumloops ausgesucht habe, die sich am besten anhören, wenn sie weniger bassig sind. Also ist eher Getrommel rausgekommen, mit dem ich zufrieden aber nicht begeistert bin und von dem ich zumindest hoffe, daß es nicht nervt. Deine Aufgabe, verehrter Leser, ist, abzustimmen, welches Stück nervt und welches nicht. Die Namen sagen nichts über das Stück an sich aus; eher über mein Vorhaben, als ich das Stück angefangen habe. Ich behalte die Namen erstmal für meine eigene Wiedererkennbarkeit.
Easier
Melodic
Multitest
...und etwas, das nicht ins Spiel kommt...
Rap
Tötet mich!
Vor einer Weile habe ich parallel Beaterator für die PSP als Notlösung geholt und die Demo von Fruity Loops auf dem PC ausprobiert. Es stellt sich heraus, daß die Benutzeroberfläche von Fruity Loops so angenehm wie Lepra ist und Beaterator nicht nur Beats kann sondern eine für meine Anfängerkenntnisse vollwertige Sammlung von Sequencer, Synthesizer, Drumkit, Mastering-Werkzeug und wie man das Ding nennt, mit dem Melodien in Loops zusammenstellt. Das ganze mit einer Benutzeroberfläche bei der ich nicht wüßte, wie man sie auf der PSP verbessern kann, Tutorialvideos, die auch das Vokabular erklären und Geschenke vom Weihnachtsmann. Hardwarebedingte Beschränkungen sind die 8 Tracks, die man maximal gleichzeitig haben kann, auch wenn man pro Track mehrere Instrumente nacheinander benutzen kann, die maximal zwei Mastering-Effekte pro Track und daß die Hardwarebedienelemente nicht mal annähernd dafür taugen, mit Melodien zu experimentieren.
Und so habe ich drei Tracks zusammengestellt, die sehr wenig melodisch sind. Mein Idealvorstellung wäre sowas wie die chillige Musik von N+ (das diese Woche glaube ich im Angebot ist) allerdings ist mir mein Bedürfnis, das Mastering von fetten Beats zu beherrschen in die Quere gekommen. Dem Mastering von fetten Beats ist die Quere gekommen, daß ich Drumloops ausgesucht habe, die sich am besten anhören, wenn sie weniger bassig sind. Also ist eher Getrommel rausgekommen, mit dem ich zufrieden aber nicht begeistert bin und von dem ich zumindest hoffe, daß es nicht nervt. Deine Aufgabe, verehrter Leser, ist, abzustimmen, welches Stück nervt und welches nicht. Die Namen sagen nichts über das Stück an sich aus; eher über mein Vorhaben, als ich das Stück angefangen habe. Ich behalte die Namen erstmal für meine eigene Wiedererkennbarkeit.
Easier
Melodic
Multitest
...und etwas, das nicht ins Spiel kommt...
Rap
Tötet mich!
Montag, 10. Mai 2010
Balkon Wars
Hier geht es nochmal um Candy Wars.
Ich habe mal den Boden meines Balkons fotografiert und die Rillen so versetzt, daß sie dort sind, wo die "Wände" eines Levels waren.
Das sieht mir zu realistisch aus und die Filter, die mein Photoshop light oder wie das heißt, bietet, um dem ganzen etwas Stil zu geben, gefallen mir nicht. Sie machen das Bild nicht mehr erkennbar. Ich glaube, ich werde das ganze verwerfen und die Grafik so gut wie ich kann malen, im Notfall was abstraktes.
Ich habe mal den Boden meines Balkons fotografiert und die Rillen so versetzt, daß sie dort sind, wo die "Wände" eines Levels waren.
Das sieht mir zu realistisch aus und die Filter, die mein Photoshop light oder wie das heißt, bietet, um dem ganzen etwas Stil zu geben, gefallen mir nicht. Sie machen das Bild nicht mehr erkennbar. Ich glaube, ich werde das ganze verwerfen und die Grafik so gut wie ich kann malen, im Notfall was abstraktes.
Samstag, 1. Mai 2010
Candy Wars v0.1 Download
Hier ist ein Link zum Download der aktuellen Version. Der Link wird irgendwann im nächsten Monat voraussichlich eine Weile lang nicht mehr fuktionieren, weil die Verwaltung der Homepages des Providers übel ist. Es kann auch sein, daß der Link irgendwann mal zu einer neueren Version des Spiels zeigt.
Zu beachten ist folgendes:
Das Spiel ist nur für mehrere Spieler gedacht. Weil mindestens zwei spielen und einer die Maus/Tastatur auf dem PC benutzen kann, wird mindestens ein kabelgebundenes Xbox 360 Pad gebraucht. Das Aufladekabel tut's komischerweise nicht. Man kriegt es auch ohne Pad zum laufen, nur muß man dann mindestens ein Dummy erstellen, das ins Spiel einsteigt. Es wird natürlich Windows gebraucht und irgendeine DirectX 9 Karte vermutlich. Nicht, weil das Spiel irgendwas funkymäßiges nutzt sondern weil XNA sagt, daß das die Voraussetzungen sind.
Die Optionen im Optionsmenü haben keine Auswirkung auf irgendwas. Score kriegt man für jeden Treffer und dann mehr für einen Kill. Ich werde die Werte erst anpassen, wenn ich eine Anzeige gemacht habe, die in Echtzeit zeigt, wann man wieviel kriegt, weil man zur Zeit eh nicht nachvollziehen kann, wie sich der Score zusammensetzt.
Zu beachten ist folgendes:
Das Spiel ist nur für mehrere Spieler gedacht. Weil mindestens zwei spielen und einer die Maus/Tastatur auf dem PC benutzen kann, wird mindestens ein kabelgebundenes Xbox 360 Pad gebraucht. Das Aufladekabel tut's komischerweise nicht. Man kriegt es auch ohne Pad zum laufen, nur muß man dann mindestens ein Dummy erstellen, das ins Spiel einsteigt. Es wird natürlich Windows gebraucht und irgendeine DirectX 9 Karte vermutlich. Nicht, weil das Spiel irgendwas funkymäßiges nutzt sondern weil XNA sagt, daß das die Voraussetzungen sind.
Die Optionen im Optionsmenü haben keine Auswirkung auf irgendwas. Score kriegt man für jeden Treffer und dann mehr für einen Kill. Ich werde die Werte erst anpassen, wenn ich eine Anzeige gemacht habe, die in Echtzeit zeigt, wann man wieviel kriegt, weil man zur Zeit eh nicht nachvollziehen kann, wie sich der Score zusammensetzt.
Freitag, 23. April 2010
Candy Wars
Hier ist ein Screenshot von dem Spiel, an dem ich gerade arbeite. Die Grafikelemente sind natürlich Platzhalter.
Das ist vom Prinzip her das erste Computerspiel, das es überhaupt gab (Space Wars) mit einer Geometry Wars Steuerung. Es ist erstaunlich, daß obwohl ich das Spiel vor einem Jahr angefangen habe (und seitdem einmal im Monat daran arbeite) keiner bisher so ein Spiel gemacht hat. Es gibt Spiele mit Geometry Wars Steuerung, die man alleine oder kooperativ gegen den Computer spielt, und welche, die man gegeneinander aber auf Scorejagd spielt. Keine, in denen man versucht, sich gegenseitig zu töten. Bis auf den Space Wars Klon, der das erste XNA-Beispiel von Microsoft war. Aber das hat wiederum diese Steuerung, in der man rotiert.
Ich dachte, daß man mit ein paar geschickt platzierten Wänden und Extras das Spiel einigermaßen interessant wird und trotzdem supereinfach zu verstehen. Ich werde in Zukunft mehr darüber schreiben, warum ich dieses Spiel mache und wie ich welche Entscheidungen treffe. Das Ding ist voll spielbar mit 360 Joypads und/oder Maus & Tastatur und hat zur Zeit eine Extrawaffe, mit der Schüsse an den Wänden abprallen. Ursprünglich wollte ich sehr viele Extras haben, zur Zeit denke ich eher daran, es auf 3-5 zu beschränken, wenn überhaupt. Und ich neige dazu, es online spielbar machen zu wollen, obwohl es mir beträchtliche Kopfschmerzen bereiten wird. Das Problem ist nämlich nicht, die Nachrichten von System zu System zu schicken und sie zu interpretieren sondern die Programmierung der Lobby und die Behandlung aller Ereignisse bei allen möglichen Zuständen in der online Welt.
Wenn mir auch noch jemand erzählt, wo ich kostenlosen Webspace kriege, der die Leute nicht mit Pop-up Werbung oder sonstwas belästigt, dann kann ich die aktuelle Version auch noch hochladen, damit ihr sie spielen könnt.
Ich habe zur Zeit recht wenig Hunger.
Das ist vom Prinzip her das erste Computerspiel, das es überhaupt gab (Space Wars) mit einer Geometry Wars Steuerung. Es ist erstaunlich, daß obwohl ich das Spiel vor einem Jahr angefangen habe (und seitdem einmal im Monat daran arbeite) keiner bisher so ein Spiel gemacht hat. Es gibt Spiele mit Geometry Wars Steuerung, die man alleine oder kooperativ gegen den Computer spielt, und welche, die man gegeneinander aber auf Scorejagd spielt. Keine, in denen man versucht, sich gegenseitig zu töten. Bis auf den Space Wars Klon, der das erste XNA-Beispiel von Microsoft war. Aber das hat wiederum diese Steuerung, in der man rotiert.
Ich dachte, daß man mit ein paar geschickt platzierten Wänden und Extras das Spiel einigermaßen interessant wird und trotzdem supereinfach zu verstehen. Ich werde in Zukunft mehr darüber schreiben, warum ich dieses Spiel mache und wie ich welche Entscheidungen treffe. Das Ding ist voll spielbar mit 360 Joypads und/oder Maus & Tastatur und hat zur Zeit eine Extrawaffe, mit der Schüsse an den Wänden abprallen. Ursprünglich wollte ich sehr viele Extras haben, zur Zeit denke ich eher daran, es auf 3-5 zu beschränken, wenn überhaupt. Und ich neige dazu, es online spielbar machen zu wollen, obwohl es mir beträchtliche Kopfschmerzen bereiten wird. Das Problem ist nämlich nicht, die Nachrichten von System zu System zu schicken und sie zu interpretieren sondern die Programmierung der Lobby und die Behandlung aller Ereignisse bei allen möglichen Zuständen in der online Welt.
Wenn mir auch noch jemand erzählt, wo ich kostenlosen Webspace kriege, der die Leute nicht mit Pop-up Werbung oder sonstwas belästigt, dann kann ich die aktuelle Version auch noch hochladen, damit ihr sie spielen könnt.
Ich habe zur Zeit recht wenig Hunger.
Abonnieren
Posts (Atom)