-
Notifications
You must be signed in to change notification settings - Fork 0
Persönlicher Text
Hallo,
Ich hab während meiner Projektarbeit in der Freien Schule Winterthur das Thema Game Design gewählt. (Mehr über dieses Thema steht im Sachtext.) Als Kreativ Arbeit hat es sich natürlich angeboten ein Spiel selber zu designen und zu entwickeln.
Ich sollte eventuell noch erwähnen, dass ich in meiner Freizeit schon länger programmiere und somit war dieses Projekt kein Sprung ins kalte Wasser.
In diesem "Kapitel" werde ich den Ablauf von meinem Projektes beschreiben. Es wird der Hauptteil dieses Textes sein.
Dieser Montag war der erste nach der Weihnachtsferien und somit der Startschuss in die Projektarbeit. Wir hatten jeweils am Montag drei Lektionen Zeit um an unserem Projekt zu arbeiten.
Allerdings habe ich in den ersten zwei Wochen noch nicht begonnen zu programmieren. Ich stattdessen den Sachtext geschrieben (da wir am 03. Februar Abgabetermin hatten).
Wie man dem Titel entnehmen kann, habe ich an diesem Montag den Sachtext fertig geschrieben.
Zum Sachtext ist ev. noch wichtig zu wissen, das ich in den Weihnachtsferien ein 570 Seitiges Buch über Game Design gelesen habe. Dadurch musst ich mich am 9. Januar nicht noch in mein Thema vertiefen, sonder konnte direkt damit beginnen den Text zu schreiben.
An diesem Tag habe ich das erste Mal Gedanken zu meinem Spiel auf Papier festgehalten.
Wenn man ein Spiel designen will, macht man am besten ein Konzept des Spiels auf Papier. In diesem hält man fest, wie die Mechaniken funktionieren, wie sich was soll anfühlen, um was es gehen soll, .... Man "schreibt" das Spiel auf Papier auf. Später hilft ein das enorm (mir auf jeden Fall), da man nicht jede Idee im Kopf halten muss.
Ich hatte bereits ein Konzept fast fertig, allerdings verwarf ich es (leider) wieder. Der Grund dafür war, dass wir eine Kopfrechnungsprüfung hatten und ich nach Spielen suchten, mit denen ich das Einmaleins lernen kann. Ich wurde nicht fündig (was mich sehr überraschte). Also erstellte ich ein Mathe-Klicker Konzept. Dieses Konzept orientierte sich an Spielen wie Cookie-Clicker und Tap Titans 2 (Beide Spiele gehören dem Idle Genre an). Das Konzept findet man hier.
Nun hatte ich ein praktisch fertiges Konzept und doch war ich nicht zufrieden. Das liegt nicht zuletzt an meinem Freund Tim, der entäuscht von meiner Mathe-Clicker Idee war, da ich ihm zuvor von einem schnellen spassigen Spiel (das erste Konzept) erzählt habe.
Ich selbst bekam zweifel und evaluierte meine Entscheidung auf ein neues. Ich kam zu Schluss, dass der Spass an einem Clicker Spiel darin liegt vom Spiel überrascht zu werden und neues zu "entdecken". Und das kann ich bei meinem Spiel, was ich selbst programmiere und darum in und auswendig kenne, kaum. Das war ebenfalls der Grund, wieso ich zum ersten Konzept zurück kam (, welches ich gelöscht habe!).
Ich hab in den Skiferien das dritte und erste Spielkonzept (nochmals) geschrieben. Das Konzept findet man hier.
Das ist nun der erste Montag an dem ich programmiere. Das erste was mein Charakter bei brachte, war das laufen. Ich hatte allerdings schon ein Prototyp im Wochenende geschrieben (, wie man es ja sollte tun im Game Design,) und es war mehrheitlich Copy Past von altem Code mit ein bisschen neuen Code.
Von diesem Wochenende her war der Spieler kein grauer Block von Unity mehr sonder eine Textur, die halbwegs menschlich aussieht. Zu dem sah man die ersten Züge des Kampfsystems. Dieses System wird mich allerdings noch lange begleiten. Ich hab ebenfalls noch Hilfscode programmiert, der mich in der weiteren Entwicklung unterstützen wird.
Am Montag hab ich mich dann noch um die Animationen des Hauptcharakters gekümmert. Diese waren am letzten Wochenende zwar schon vorhanden, aber sie wurden noch nicht benutzt. Ebenfalls folgte die Kamera dem Spieler nun. Bis anhin konnte man aus dem Sichtfeld der Kamera heraus laufen.
An diesen zwei Tagen arbeitete ich an einem wichtigen Teil des Spiels, das Kampfsystem.
Nun konnte ich jemand schlagen und es wurde registriert. Dieser Fortschritt tönt nach wenig, trotz dem war es recht viel Arbeit.
An diesem Montag habe ich die begonnen die Künstliche Intelligenz (kurz KI oder AI) zu implementieren. Es tönt allerdings viel komplizierter als es ist, da sie eine einfachere KI ist.
Sie steht herum, bis der Spieler genug nahe ist. Dann geht sie auf den Spieler auf dem direktesten Weg hinzu bis sie genug nahe am Spieler ist um ihn an zu greifen.
Sie ist also kein Intelligenzbestie (und kommt nie und nimmer an HAL heran).
Allerdings möchte ich anmerken, dass es in grösseren Produktionen durchaus komplizierte KIs gibt, welche mehr als nur drei States haben. Die suchen dann auch Deckung, versuchen ev. einen Hinterhalt zu machen oder sonst was. Mit diesem Thema könnte man aber eine Projektarbeit für sich machen, darum belass ich es bei diesen einfachen Versuchen.
Ich hab ebenfalls noch eine Lade-Balken implementiert. Dieser wird für die Leben der Gegner und des Spielers genutzt.
Das denke ich, wenn etwas funktioniert, was sich schon seit Tagen sträubt. So war es auch bei der KI und beim Kampfsystem und es wird noch bei anderen Themen sein.
Man kann sagen, dass das ein Fluch und ein Segen des Programmieren ist, denn ein Fluch, %weil man nicht vorankommt und man gefrustet ist, dass man nichts geschafft hat. Und ein Segen, weil das Gefühl so gut ist, wenn man es dann einem geschaft hat.
So was habe ich dann diesen Montag zum funktionieren gebracht?
Die KI von Kasa Obake ist fertig und funktioniert. (Kasa Obake ist der Name des "Monsters".)
Diesen Mittwoch habe ich die Bewegungsfreiheit des Spielers erhöht und die KI von Kasa Obake nochmals überarbeitet.
Ist jemand schon aufgefallen, dass ich immer wieder auf Themas zurück komme, die ich als funktionierend bezeichnet habe. Fast überall wo Sie in diesem Text "funktioniert" finden, können es sie durch “funktioniert fast” ersetzen.
Das ist leider auch so eine Wahrheit des programmieren. Wenn man nicht alles extremstens plannt und testet, hat man immer Bugs, also Fehler, im Code. Im Zusammenhang von kleineren Projekten ist es nicht so schlimm, wenn man nicht alles plant, da es genug übersichtlich ist um solche meist kleine Patzer zu verbessern.
Das Waffensystem hatte ein grossen Mangel. Es war zu genau. Es hat nicht simuliert, wie ein Schwertschlag funktioniert.
In der alten Version habe ich ein geraden unsichtbaren Strahl von dem Spieler weg geschickt in die Richtung in die er gerade schaut. Alles was diesen Strahl dann traf, wurde von meinem Schwert getroffen. Leider ist ein Schwertschlag keine Linie, sondern mehr ein Dreieck.
Dieser Umbau hat mich VIELE Nerven gekostet. Ebenfalls wollte ich Projektil noch unterstützen für Fernkampfwaffen, was aber einfacher war.
Das Inventar war auf eine Art sehr frustrierend.
Ich hab am 02. angefangen und zuerst wollte ich ein Kontextmenü (das ist das Menü, welches aufploppt, wenn Sie die rechte Maustaste drücken), in welchem man informationen über das Item sieht und mit dem Item interagieren kann. Also habe ich begonnen ein System zu entwickeln was dies unterstützt.
Später hat mir (wieder) Tim den Tipp gegeben, es könnte ja bloss Informationen anzeigen.
Und auf eine Art stimmt das durchaus, das fand ich auch. Also die hälfte des Codes löschen und tada. Im Moment wo ich das schreibe, denke ich, ich wird wohl doch ein Kontextmenü brauchen. Zum Glück programmier ich bloss ein Prototyp.
Es gab noch ein zweiten Frustmoment.
Ein Inventar besteht normalerweise aus Kacheln (wie im Bild) in die man Items legen kann und mit Drag&Drop verschieben kann.
Ich wollte natürlich auch so ein System. Also habe ich (ohne vorher zu googlen) angefangen zu programmieren. Irgendwann stiess ich auf Probleme und nach längerem googlen fand ich ein Lösung, die ich in wahrscheinlich 2-3 Stunden implementiert hätte.
Was lernt man nun daraus? Man sollte zuerst denken und dann programmieren.
An diesem Tag hatten wir die letzten 3 Lektionen in der Schule Zeit. Danach heisst es: zu Hause arbeiten!!!.
Was habe ich in diesen Stunden getan? Ich hab vorallem diesen Text geschrieben.
In dieser Woche habe ich:
-
ein Hauptmenü
-
Speicher
-
Optionen Menü
-
ein Info-Panel für Items
-
Waffen Upgrades
-
Spawners
implementiert. Zu dem wurden noch (viele) Bugs gefixt. Also durchaus viel…
(Noch etwas am Rande: Am Ende dieses Dokumentes gibt es ein Kapiptel "Für Programmierers". In diesem Kapitel werden einige Probleme technisch genauer beschrieben.)
Diese zwei Themen gehen Hand in Hand, denn was ist der Punkt eines Hauptmenüs, wenn man nicht speichern kann.
Ein Hauptmenü zu machen, ist nicht schwer (und es gab auch fast keine Probleme). Ich brauchte etwa einen halben Tag. Was aber länger dauerte war das Speichern. Ich muss zugeben, dass ich beim programmieren der Items nicht an das Speicher gedacht habe und rückblickend würde ich wohl einige Dinge anders implementieren. Das bestätigt die Aussage des Kapitels "02. - 09. April 2017 - Der Frust", dass man zuerst denken soll und dann programmieren.
Diese Mechanik bringt ein bisschen neuen Spielspass in das Spiel, denn es gibt dem Spieler ein einfaches Ziel: versuch das nächste Upgrade zu kaufen/freizuschalten. Ein solches Ziel kann sehr Motivierend sein (denn man denkt sich nur noch bis ich das nächste Upgrade erreicht habe, dann höre ich auf) und ist bei einigen Spielen sogar das Spiel. Denken Sie mal an Spiele, wie Farmville und Clash Of Clans. Diese Spiele finanzieren sich dadurch, das einige Spieler zu motiviert sind, um zu warten, bis sie genügend Geld haben und sich das Geld im Ingame Shop (mit echtem Geld) kaufen.
Ein zweiter Effekt ist, dass es eine gewisse Progression gibt, denn man kann darauf zurück Blicken und sieht den Fortschritt (, was ebenfalls motivierend ist).
Spawners sind (in meinem Spiel) unsichtbare Objekte, welche Gegnern spawnen, also "generieren"/auf erstehen lassen. Dank diesen Objekten, gibt es genug Gegner, damit sich der Spieler vergnügen kann.
Die Kunst ist nun, wieviel Gegner sollen spawnen. Sind es zu viel, wird der Spieler überrannt, sind es zu wenig, langweilt sich der Spieler.
Eine andere Frage ist, ob sich die Stärke der Gegner am Spieler anpassen soll.
Wenn ja, bleibt es immer eine Herausforderung und somit spannend.
Wenn nein, spürt der Spieler, wie er besser wird, da er die Gegner, an denen er mal mühe hatte, einfach besiegen kann. Damit dann keine Langeweile aufkommt, müssen natürlich neue Gegner eingeführt werden, damit es trotzdem eine Herausforderung ist (Dies geht in die Interessens Kurven hinein. Steht sonst in meiner theoretischen Arbeit.).
Die erste Woche war sehr auf neue Gameplay Mechaniken fokussiert. Die zweite Woche ist auf die Ästhetik fokussiert, aber auch auf den Rest, der noch zu tun ist. (Leider habe ich in dieser Woche nicht ganz so viel Zeit, wie in der Letzten.)
Das erste was ich getan habe, ist das austauschen des Hauptcharakter. Der alte Hauptcharakter war an sich ok (, auch wenn er keine Schönheit war). Allerdings hatte die Schwert Animation ein gröberes Problem. Sie reflektiert nicht, was das Spiel im hintergrund macht. Die Folge daraus ist, dass wenn man einen Schwertschlag macht, fühlt es sich nicht so an, als ob man mit dem Hauptcharakter "verbunden" wäre. Es fühlt sich falsch an und das Fühlen ist in einem Spiel, wie das Meine, ein sehr wichtiger Punkt, da es darum Spass machen soll. (Es ist eines der Kern Mechaniken des Spiels.)
Die neue Version fühlt sich viel besser an, ist aber weit weg von perfekt. Da meine Zeichnung Künste aber zu wünschen übrig lassen, wird sich das (leider) auch nicht so schnell ändern.