RPG Game-Loop und Klassenstruktur (cocos2D für iPhone)

Question

Ich suche ein RPG mit Cocos2D auf dem iPhone zu machen. Ich habe ein bisschen Nachforschungen angestellt, und mir gefällt das Modell, das Cocos2D für Szenen verwendet. Ich kann eine Szene instanziieren, meine Charaktere einrichten usw. und alles funktioniert wirklich gut ... mit denen ich Probleme habe, ist eine Spielschleife zu strukturieren und den Code von den Szenen zu trennen.

Zum Beispiel, wo gebe ich meinen Code ein, der den Status des Spiels über mehrere Szenen hinweg erhält? und setze ich den Code für Ereignisse, die in einer Szene in der Klasse dieser Szene ausgelöst werden? Oder habe ich eine andere Klasse, die den Init-Code von der Logik trennt?

Ich habe auch eine Menge Tutorials gelesen, die wechselnde Szenen erwähnen, aber ich habe keine gelesen, die über das Aktualisieren einer Szene sprechen - nehmen die Eingaben vom Benutzer und aktualisieren die darauf basierende Anzeige. Passiert das im Szenenobjekt oder in einer separaten Klasse des Display-Engine-Typs?

Vielen Dank im Voraus!

Answer 1

Es klingt, als ob Sie gut auf dem Model-View-Controller Muster nachlesen können. Sie müssen sich nicht sklavisch daran halten (in einigen Kontexten ist es beispielsweise sinnvoll, eine Überschneidung zwischen Modell und Ansicht zuzulassen), aber wenn Sie ein gutes Verständnis davon haben, können Sie jedes Programm mit vielen grafischen Objekten erstellen und Logik, die sie steuern, und die Notwendigkeit, Rundfunk zu senden oder es auf Disc (Spiel speichern), etc.

Sie müssen auch erkennen, dass cocos2d bietet ein gutes System zur Strukturierung der grafischen Szene Grafik und Rendern effizient, aber Es bietet keine vollständige Infrastruktur für die Programmierung von Spielen. In diesem Sinne ist es eher eine Grafik-Engine als eine Game-Engine. Wenn Sie versuchen, die Architektur Ihres Spiels in die Struktur von cocos2d einzupassen, erhalten Sie möglicherweise nicht das am besten wartbare Ergebnis. Stattdessen sollten Sie cocos2d als das behandeln, was es ist: ein großartiges Werkzeug, um sich um Ihre Anzeige- und Animationsbedürfnisse zu kümmern.

Sie sollten auf jeden Fall ein anderes Objekt als die Szenen haben, die den Spielstatus beibehalten, weil sonst wo wird der ganze Zustand gehen, wenn Sie zwischen den Szenen wechseln? Und innerhalb von Szenen/Ebenen sollten Sie einfach versuchen, gutes objektorientiertes Design zu verwenden, um den Status über Objekte verschiedener Klassen zu verteilen. Jedes Zeichenobjekt merkt sich seinen eigenen Zustand usw. Hier sehen Sie, wo MVC nützlich wird: Wenn Sie das Spiel auf Disc speichern, möchten Sie sich die Gesundheitsstufe jedes Charakters merken, aber wahrscheinlich nicht den genauen Frame-Index der Sprite-Animation. Sie müssen also zwischen dem Sprite und dem Zeichen (Modell) selbst unterscheiden. Das heißt, wie ich vorher für Objekte im Spiel erwähnt, die mit ihnen verbunden nicht viel Logik haben oder die nicht brauchen, um gerettet zu werden, könnte es in Ordnung sein, nur das Modell verschmelzen und anzeigen zusammen in einer Klasse (im Grunde durch Unterklassen CCSprite).

Um MVC so zu ziehen, wie es sein sollte, sollten Sie auch die Grundlagen von Key-Value Observing lernen. (Und Sie würden gut daran tun this replacement für das Apple-Schnittstelle zu verwenden.) In intensiver Echtzeit-Spiele, Techniken wie dies könnte zu langsam sein, aber da Sie machen ein RPG (gute Wahl für den Einstieg) Sie könnten wahrscheinlich opfern Leistung für eine wartungsfreundlichere Architektur.

Die Spielszene (die nur ein weiteres cocos2d-Sprite ist) spielt die Rolle des Controllers in Bezug auf das MVC-Muster. Es zeichnet nichts selbst, sondern sagt allem anderen, sich basierend auf Eingaben und Zustand zu zeichnen. Es ist verlockend, alle Arten von Logik und Funktionalität in der Spielszene zu setzen, aber wenn Sie feststellen, dass es quillt, sollten Sie sich fragen, wie Sie diese Funktionalität in andere Klassen trennen konnte. Analysieren Sie, welche Art von Funktionalität Sie implementieren. Geht es um Daten und Zustand (Model)? Oder geht es um Animation und Rendering (View)?Oder geht es darum, Logik mit Rendering zu verbinden (in diesem Fall sollten Sie versuchen, die View direkt zum Modell zu führen)?

Die Spieleszene/Controller ist im Grunde ein Dispatch-Center, das Eingabeereignisse (vom Benutzer oder von Sprites, die z. B. etwas getroffen haben) nimmt und entscheidet, was mit ihnen zu tun ist: es könnte einen oder sagen Einige der Model-Objekte aktualisieren sich auf irgendeine Weise, oder sie können beispielsweise nur eine Animation in einigen anderen Sprites auslösen.

In einem Echtzeitspiel haben Sie eine "Tick" - oder "Step" -Methode in der Szene, die allen Objekten sagt, dass sie sich selbst aktualisieren sollen. Diese Methode (die Spielschleife) ist das Herzstück des Programms und wird jedes Mal ausgeführt, wenn ein neuer Rahmen gezeichnet wird. (In modernen Spiele-Engines gibt es eine Menge Multi-Threading, aber lass uns nicht darüber nachdenken.) Aber in deinem Fall möchtest du vielleicht ein Modul erstellen, das "das Spiel" komplett getrennt von der Spielszene spielen kann. Stellen Sie sich vor, Sie erstellen ein Programm, das Schach über das Terminal spielen kann und nur Texteingabe verwendet. Wenn Sie das ganze Spielsystem auf diese Weise erstellen und es dann über eine kleine und saubere Oberfläche mit der Grafik-Engine verbinden, haben Sie eine wirklich wartbare App mit viel wiederverwendbarem Code für zukünftige Projekte!

Einige gute Faustregeln: Das Modell (Daten) sollte nicht wissen irgendetwas über Sprites oder Anzeigezustände; Die Ansicht (Sprites) sollte keine der tatsächlichen Logik des Spiels enthalten (die Spielregeln), sondern nur einfache Dinge wie Bewegen und Springen und das Berichten an die Szene, wenn etwas Kompliziertes passiert. Wenn möglich, sollte die Ansicht direkt auf Änderungen im Modell reagieren, ohne dass der Controller eingreifen muss.