PlanetSwitch Planet3DS PlanetVita PSP.de PlanetiPhone Classics Forum

PGN-ID:[?] (Nicht eingeloggt)
Login
Registrieren
PlanetDS PlanetGameboy N-Page.de

-

Sonstiges: Entwicklertagebuch - Der Weg zum eigenen Switch-Spiel

Michael Grönert, am 26.12.2016, Seite 5 von 25

Artikel mögen: Weitersagen:


BadToxic Discord-Server | GameMaster Discord-Server | BadToxic auf Twitter
BadToxic auf Instagram | BadToxics Entwickler-Instagram | BadToxic auf YouTube

2016- Teil 1: Willkommen in der Welt der Videospielentwicklung!
2017- Teil 2: Am Anfang stand die Idee
- Teil 3: Die Voraussetzungen
- Teil 4: Die letzten Vorbereitungen
- Teil 5: Es kann losgehen
- Teil 6: GONG! Das erste Minispiel
- Teil 7: Das Inventar
- Teil 8: Speichern & Laden
- Teil 9: Fähigkeitenbaum & Menüs
- Teil 10: Errungenschaften & Benachrichtigungen
2018- Teil 11: Tag- und Wetterwechsel
- Teil 12: Netzwerk-Spiele
- Teil 13: Begleiter-Haustier
- Teil 14: Unterstützung für Android und iOS
- Teil 15: Pairs - Finde Kartenpaare
- Teil 16: Einbauen von Pairs in GameMaster
2019- Teil 17: Statistiken
- Teil 18: Fizhy
- Teil 19: Fizhy in GameMaster einbauen & KI
- Teil 20: Erschaffen einer Community
- Teil 21: Shader und Partikel
2020- Teil 22: Overworld-Landschaftsgestaltung
- Teil 23: Charaktere im 3D-Manga-Style
- Teil 24: Gemeinsam Hamburger „kochen“
- Teil 25: Charakter-Individualisierung

Teil 5: Es kann losgehen
Nun da alle Vorbereitungen getroffen sind, können wir endlich loslegen. Unser Vorhaben ist sehr komplex und es gibt noch unzählige offene Fragen. Menschen mit Erfahrung in umfangreichen Projekten können bestimmt bestätigen, dass eine gute Planung das A und O einer effektiven Herangehensweise ist. Auf Grundlage meiner Spielidee könnte man bereits Wochen vorher planen, wie alles genau umgesetzt werden soll. Dazu müsste man unzählige Male über alles erneut iterieren. Ich habe allerdings für mich festgestellt, dass es effizienter ist, Teile zu isolieren und sofort umzusetzen, die von einer weiteren Planung nicht abhängen. Das Problem dabei ist vor allem, solche Teile ausfindig zu machen. Erschwerend kommt noch dazu, dass Unity und C# noch immer sehr neu für mich sind und ich von den Möglichkeiten nicht viel Ahnung habe. Gerade deswegen bietet es sich an, erst mit simplen Aufgaben zu beginnen und dabei zu lernen.

Die Welt und der Spieler
Ich habe mich also entschlossen, zunächst eine Welt zu basteln, in der ich umherlaufen und durch bestimmte Aktionen ein erstes Spiel starten kann, welches ich ebenfalls zeitig skizziere. Alles soll zunächst so simpel wie möglich gehalten werden, damit nichts unnötig mehrfach gemacht werden muss.

Die Welt ist einfach nur eine Ebene (Plane). Auf dieser wird ein Charakter platziert, der gesteuert werden können soll. Dazu genügt zunächst ein Quader. Dazu noch ein Objekt, mit dem interagiert werden soll, um ein Spiel zu starten - z.B. noch ein Quader. Ich werde nicht darauf eingehen, wie die einzelnen Schritte in Unity genau funktionieren, dafür gibt es bereits genügend Tutorials im Internet und das meiste lässt sich auch so herausfinden. Nun wollen wir unseren Spieler steuern können, also weisen wir ihm ein neues Skript zu, welches sich allgemein um den Spieler kümmern soll. Spätestens jetzt kommt bereits die erste plattformabhängige Frage auf - woher weiß ich, welche Taste gerade gedrückt wird? Hier kommt unser Nintendo 3DS SDK ins Spiel. Diese bietet Funktionen an, mit denen abgefragt werden kann, ob eine Taste aktuell gedrückt ist, oder nicht.

Unity erlaubt, einzelne Code-Abschnitte so zu markieren, dass sie nur auf bestimmten Plattformen ausgeführt werden. So kann ich also festlegen, dass auf dem 3DS über Variante A nach den Tastendrücken gefragt werden soll und auf einem anderen Gerät über Variante B. Für jede Richtung, in die wir laufen können wollen, ordnen wir der entsprechenden Taste eine Geschwindigkeit für unseren Charakter in diese Richtung zu. Mit wenigen einfachen Einstellungen übernimmt Unitys Engine dann selbstständig Aufgaben wie die Kollisionsbehandlung und die Reibung. Unser Würfel fällt so nicht mehr durch den Boden und wird beim Laufen abgebremst.

Mit diesem Charakter kann ich mich identifizieren
Das Charakterdesign ist eine sehr knifflige Aufgabe. Es gehört sicher zu den Herausforderungen, die man lange zurück stellen könnte. Aber irgendwie habe ich keine Lust, beim Testen neuer Funktionalitäten ewig einen Würfel durch die Gegend zu schieben und ich bin neugierig, wie das eine oder andere in Unity funktioniert. Doch kann ich mich jetzt schon entscheiden, was für eine Art von Figur ich am Ende haben möchte?

Benutze ich eine voll in 3D modellierte Person oder lieber nostalgische Pixel-Sprites? Steuere ich überhaupt einen Menschen oder kann mein Avatar auch ein Tier, ein Fantasiewesen oder gar ein Gegenstand sein? Das Szenario meiner Spielidee lässt hier sehr viel Freiraum. In meinem Fall sollte aber vor allem der Aufwand eine wichtige Rolle spielen, mal abgesehen von meiner fehlenden Erfahrung in der 3D-Modellierung. Mit Zeichnen und der Erstellung von Sprites kenne ich mich schon deutlich besser aus. Nichtsdestotrotz möchte ich mich nicht deswegen alleine auf etwas festlegen, sondern wollte erst einmal mit der für mich simpler erscheinenden Technik experimentieren. Also habe ich mich für eine pixelige 2D Variante in Form eines kleinen Männchens entschieden, welches ich bereits für ein anderes Projekt vor vielen Jahren erstellt hatte. Es galt somit herauszufinden, wie man eine zweidimensionale Figur im dreidimensionalen Raum darstellen und animieren kann - Stichwort „Billboard“. Selbst wenn ich diese Variante später komplett ersetzen sollte, wäre der Aufwand nicht umsonst, denn diese Technik lässt sich in vielen Fällen gebrauchen. Jetzt wirkt das simple Szenario viel angenehmer, mit einer Grafik, die leicht an Paper Mario erinnert.

Die erste Interaktion
Jetzt, da wir durch unsere Welt stolzieren, möchten wir auch mit ihr interagieren können. Der Spieler soll also zu dem vorhin erwähnten zweiten Quader laufen und ihn „benutzen“ können. Über die bereits vorhandene Kollisionsbehandlung können Quader und Spieler so aufeinander abgestimmt werden, dass beim Spieler in jedem Schritt eine bestimmte Methode aufgerufen wird. „Schritt“ nenne ich vereinfacht den Abschnitt zwischen zwei Code-Durchläufen. Dies kann dem Wechsel von einem Frame (gerendertem Bild) zum nächsten entsprechen oder nach Wahl auch unabhängig davon. Im Allgemeinen sollten wir nicht davon ausgehen, dass jeder dieser Schritte gleich viel Zeit benötigt. Bei einer Bildwiederholrate von 60 FPS würde ein Schritt alle 1/60 Sekunden auftreten, bei 30FPS nur noch alle 1/30 Sekunden. Solange der Spieler neben dem Quader steht, überprüft diese Methode dann, ob eine bestimmte Taste gedrückt wird. Wird diese „Aktionstaste“ gedrückt, soll schließlich unser erstes Minispiel aufgerufen werden. Die Implementierung dieses Spiels heben wir uns allerdings für den nächsten Tagebucheintrag auf.


Der aktuelle Fortschritt: Eine Figur kann durch die Welt laufen.

An dieser Stelle wäre Feedback zu dem Informationsgehalt meiner Tagebucheinträge hilfreich. Gehe ich eurer Meinung nach zu sehr ins Detail, oder wollt ihr sogar Genaueres wissen, etwa unterstützt mit Code-Beispielen? Gerne passe ich meinen Stil euren Wünschen an, wenn diese eindeutig in eine bestimmte Richtung gehen. Bis zum nächsten Mal!

Ihr möchtet die Auszüge aus dem Leben eines Entwicklers lieber in englischer Sprache lesen? Unter diesem Link findet ihr die englische Version dieses Tagebucheintrags!


Gehe zu Seite:
Vorherige Seite | Nächste Seite

ANZEIGE:
Kommentare verstecken

- Kommentare


- Noch keine Kommentare vorhanden -

Um Kommentare zu schreiben, bitte oben einloggen oder jetzt Registrieren!