Daniel Schuller und ich gründeten Bigyama im Jahr 2012, nachdem ich an zahlreichen Titeln wie Magic the Gathering: Duell der Planeswalker und Star Wars: Battlefront gearbeitet hatte. Das Unternehmen begann mit einem Fehlstart in PlayStation Home und einem Umzug nach Schottland, bevor es nach Nottingham zurückkehrte und wir uns wieder auf unsere Kerntalente konzentrierten: Programmierung und großartige Spiele! Unser erster Schritt war die Bereitstellung der technischen Hilfsmittel, um Fallen Tree Games dabei zu helfen, Quell Memento auf die PlayStation Vita zu bringen.
Dieser Artikel beschreibt, wie wir bei Bigyama Quell Memento nach Vita portiert haben. Wenn Sie mehr über das Design von Quell erfahren möchten, lesen Sie den Artikel von The Fallen Tree, The Making of Quell.
Memento ist das dritte Spiel in der Quell-Reihe; Die vorherigen Spiele hatten sich auf dem Handy sehr gut bewährt, und ich hatte Joe und Lewis schon einige Zeit bei FTG gekannt. Vor ihrem Ableben hatte ich mit ihnen bei Free Radical Design gearbeitet. Es war großartig, die Chance zu haben, wieder mit ihnen zusammenzuarbeiten und an einer neuen Plattform arbeiten zu können.
Vor einiger Zeit hatte ich das Team von Honeyslug getroffen, den Entwicklern des erfolgreichen PSP Mini Kahoots, die dann den Vita-Launch-Titel Frobisher Says entwickelten. Sie bringen uns mit dem Entwicklerteam von SCEE (Sony Computer Entertainment Europe) in Kontakt..
Wir gingen in das SCEE-Studio in London und besprachen die Optionen - PSP Mini, PlayStation Mobile oder PlayStation Vita -, die den Entwicklern Zugriff auf Vita mit unterschiedlichem Funktionsumfang bieten. Nach ein paar E-Mails hin und her entschlossen wir uns für Quell, ein natives Vita-Spiel zu erstellen, das uns vollen Zugriff auf die Möglichkeiten der Vita und alle Funktionen von PSN wie Ranglisten und Trophäen bietet.
Oft ist die erste Aufgabe beim Erstellen eines Spiels die Entscheidung, welche Engine verwendet werden soll. Es gibt eine Reihe von Motoren auf der Vita, aber die meisten sind aus technischer Sicht völlig übertrieben und aus finanzieller Sicht für ein Projekt dieser Größe einfach nicht machbar.
Es gibt auch die oft übersehene PhyreEngine, die von Sony selbst entwickelt wurde und von registrierten PlayStation-Entwicklern kostenlos verwendet werden kann. Sie wurde für die Entwicklung von Spielen von Demon Souls bis Colin McRae: Dirt and Journey verwendet. Wie Sie sich wahrscheinlich vorstellen können, war dies so viel mehr als wir wirklich brauchten, als würden wir versuchen, eine Nuss mit einem Vorschlaghammer zu knacken.
Praktischerweise hat Quell Memento die eigene Engine von Fallen Tree Games verwendet, und sowohl die Engine als auch der Spielcode wurden mit C geschrieben. C und seine Varianten sind die Standardsprache, aus der Spiele erstellt werden, und wenn Sie ein Spiel entwickeln, das Sie auf vielen verschiedenen Plattformen veröffentlichen können sollte eigentlich mit nichts anderem gehen.
Dies machte unsere Entscheidung offensichtlich: Wir würden die Engine von Fallen Tree Game selbst auf die Vita portieren. Es war kostenlos, es wurde speziell für die Ausführung der Quell-Spiele entwickelt und war eine schöne Codebasis.
Es klingt vielleicht nicht intuitiv, alle Engines zu ignorieren, die bereits auf Vita laufen, und eine Engine zu wählen, die dies nicht tut. Wenn Sie jedoch ein Spiel auf eine neue Engine umstellen, kann das gesamte Spiel für diese Engine neu erstellt werden, da es auf eine ganz andere Weise funktioniert . Durch das Portieren der Engine wird die Wurzel des Problems behoben. Sie müssen sich keine Gedanken über die Neuerstellung der einzelnen Gameplay-Funktionen machen - Sie müssen lediglich die Funktionalität neu erstellen, auf der sie sich befinden.
Wenn Sie Glück haben, bietet Ihnen ein Port die Möglichkeit, Ihre eigene Technologie für eine neue Plattform zu entwickeln und dafür bezahlt zu werden. Bigyama hat eine eigene Engine im Haus. Wäre Quell Memento auf einer Engine ohne Quellcode-Zugriff wie UDK oder Unity aufgebaut worden, wäre dies eine Überlegung wert gewesen.
Das Schöne an der Entwicklung eines Hafens ist, dass Sie ein klares Ziel anstreben.
Das Schöne an der Entwicklung eines Hafens ist, dass Sie ein klares Ziel anstreben.
Das mag auf den ersten Blick entmutigend erscheinen, kann aber in einige Schlüsselbereiche unterteilt werden: Grafik, Benutzereingaben, Audio, Netzwerke und Speicherspiele.
Wie ich bereits erwähnt habe, bedeutete das Portieren der Engine, dass kein bedeutender Spielcode geschrieben oder umgeschrieben werden musste. Wenn diese Schlüsselbereiche zum Laufen gebracht werden, muss das Spiel sich weitgehend selbst kümmern. Die ersten Schritte bei der Erstellung eines Spiels sind ein Schlag, um den Spaß im Gameplay zu finden, aber mit einem Port ist es ein Schlag, um genug zu bekommen, um herauszufinden, wo es kaputt ist.
Beginnen Sie beim Portieren mit der Grafik.
Dies ist der beste Ort, um zu beginnen - wenn Sie nichts auf dem Bildschirm anzeigen können, ist es sehr schwer zu wissen, ob Sie Fortschritte erzielen. Wir haben mit der Grafik angefangen, noch bevor wir eine Vita in die Hände bekommen haben. Die Grafik-API der Vita ist OpenGL sehr ähnlich und Quell Memento verwendete bereits OpenGL.
Quell verwendete eine feste Funktionspipeline (was bedeutet, dass der Benutzer nur über einen festen Satz von Funktionen Stufen des Rendering-Prozesses konfigurieren kann), die Vita verwendete jedoch eine programmierbare Pipeline (Shader-Programme ermöglichen die Programmierung von zuvor fixierten Schritten des Rendering-Prozesses.) wie der Benutzer wünscht).
Wir hatten eine kurze Zeit zwischen lizenzierten Entwicklern und dem Erhalt der Entwicklungskits. Daher haben wir in unserer eigenen Engine (die Lua / C ++ / OpenGL verwendete) das Verhalten des OpenGL-Matrixstacks mit Shader und etwas benutzerdefiniertem Code nachgeahmt. Dies bedeutete, dass der gesamte Quellcode, der auf der traditionellen Pipeline mit fester Funktion basierte, weitgehend unverändert blieb.
// Teil unseres Wrappers zum Emulieren des OpenGL-Matrixstacks // Die vollständige Datei finden Sie hier: https://github.com/balaam/glfacade Matrix4 glfCalcProjMatrix () Matrix4 mat; mat = mat.identity (); für (int i = 0; i < (int)g_glFacade.projectStack.size(); i++) mat = mat * g_glFacade.projectStack[i]; return mat;
Sobald wir Kits hatten, hatten wir schnell etwas zum Laufen. Es gab wenig Arbeit, beispielsweise das Farbformat der Scheitelpunkte in das vom Shader erwartete zu konvertieren und die Scheitelpunktdaten aus mehreren separaten Puffern, die jeweils separate Scheitelpunktattribute (Position, UVs usw.) enthielten, in einen einzigen Puffer zu packen verschachtelter Puffer wie in der folgenden Abbildung dargestellt:
Nachdem wir einen sehr einfachen Shader hinzugefügt hatten, hatten wir schon bald unseren Begrüßungsbildschirm auf dem Kit installiert.
Mit dem Hinzufügen eines einfachen Shaders zum Anwenden von Texturen wurde dies bald zu folgendem:
Wie bereits erwähnt, verwendete Quell die Fixed-Function-Pipeline, und die Vitas waren programmierbar. Das heißt, das gesamte Rendering musste für die Verwendung von Shadern konvertiert werden, anstatt den festen Funktionsansatz zu setzen, bei dem eine Vielzahl verschiedener Renderzustände festgelegt wurde, um einen bestimmten Effekt zu erzielen.
Es gibt einige Denkschulen, wie Sie Ihre Shader verwalten können. Zum einen erstellen Sie einen separaten Shader für jedes Material oder jeden Effekt. Der andere ist der "Uber-Shader" -Ansatz, ein riesiger Shader, der Pre-Prozessor-Definitionen verwendet, um die zur Kompilierzeit benötigten Varianten zu erzeugen. Jeder hat seine eigenen Vor- und Nachteile:
Einzelne Shader - Vorteile:
Einzelne Shader - Nachteile:
Uber-Shader - Vorteile:
Uber-Shader - Nachteile:
In der Realität verwenden die meisten Projekte wahrscheinlich eine Kombination beider Ansätze. Für unseren Quell-Port haben wir uns ganz für den individuellen Shader-Ansatz entschieden, da unsere Anforderungen so einfach und fest waren.
Das Spiel stützte sich auf relativ wenige verschiedene Kombinationen der OpenGL-Renderzustände. Um zu verstehen, wie einfach unsere Anforderungen an den Shader waren, habe ich hier die komplexesten hinzugefügt:
float4bbbbbbbbbbbbbbgbgbgbggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg denNOnSchIdnAnstAnDeNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNTTTNNNNNNNNNNNNNNNNNNNNNNNHTTANZEN sind normalerweise nicht identisch ); float4 texResult2 = tex2D (testTex1, vTexCoord1); float4 texResult3 = tex2D (testTex2, vTexCoord2); float4 currentCol = texResult; currentCol [0] = texResult3 [0] * vColor [0]; currentCol [1] = texResult3 [1] * vColor [1]; currentCol [2] = texResult3 [2] * vColor [2]; currentCol [3] = ((texResult2 [3]) * (texResult [3])) * vColor [3]; return currentCol;
Der Quell Vita-Code enthielt insgesamt 13 Shader: acht Shader-Programme (ein Scheitelpunkt und sieben Fragment-Shader), die mit bestimmten Überblendungsmodi kombiniert wurden. Es war ziemlich einfach, Code in der Quell-Engine zu ersetzen, der alle OpenGL-Variablen mit Aufrufen einrichtete, um stattdessen einen Shader festzulegen:
rlSetBlend (RL_BLEND_RGBA); rlSetMultiTexture (0, rlGetTexture (quellGame_getAtlasImage (QUELLATLAS_SURROUND, true))); rlSetMultiTexBlend (0, RL_TEXBLEND_MODULATE_PASS_INV_ALPHA_TO_NEXT); rlSetMultiTexture (1, rlGetTexture (paneDesatTexture)); rlSetMultiTexBlend (1, RL_TEXBLEND_PREVIOUS_ALPHA_WITH_TEX_ALPHA);
wurden:
rlSetShader (RL_SHADER_BLEND_RGBA_4);Das
rl
(Renderebene) -Funktionen sind eine Reihe von Funktionen, die die OpenGL-Funktionalität einschließen. das 4
im RL_SHADER_BLEND_RGBA_4
Es wurde lediglich darauf hingewiesen, dass dies unsere vierte Variante dieses RGBA-Shatters war - mit so wenigen Shadern brauchten wir keine besonders beschreibende Namenskonvention. Diese rl
Funktionen waren bereits in der Quell-Engine vorhanden. Wenn das zu portierende Spiel diese Art der Abstraktion jedoch nicht verwendet, sollten Sie dies frühzeitig hinzufügen. Der Rendering-Code kann so abstrahiert werden, dass plattformspezifische Änderungen vorgenommen werden können, ohne den Code des Spiels zu beeinflussen.
Der Idealist in mir hätte wirklich gerne ein über-Shader-basiertes System implementiert. Dies wäre jedoch ein Overkill gewesen und hätte von den FTG-Jungs Arbeit gefordert, um sie zu unterstützen. Wir haben hart daran gearbeitet, sie zu minimieren. Das Portieren unterscheidet sich nicht von anderen Programmieraufgaben, da Sie sich immer abwägen müssen, wie Sie die Aufgabe erledigen können, und zwar anhand Ihrer idealisierten Vision sollte getan werden.
Letztendlich gab es nur sehr wenige Kopfschmerzen, wenn es darum ging, die Grafikseite des Spiels in Gang zu bringen, obwohl frustrierend viel Zeit verschwendet wurde, wenn ich herausfand, was ich vermutete, dass der Speichercode im Rendering-Code überschrieben wurde. Es dauerte eine Weile, bis mir das klar wurde, im Gegensatz zu Anrufen wie glDrawArrays
In OpenGL werden die Array-Aufrufe der Vita beim Öffnen des Arrays nicht kopiert. Dies bedeutet, dass Sie den Vertex-Puffer nicht wiederverwenden können, den Sie an die Draw-Aufrufe der Vita übergeben, bis das Zeichnen abgeschlossen ist. Wie Sie dem folgenden Screenshot entnehmen können, kann dies zu einem Chaos führen.
Um dieses Problem zu beheben, wurde einfach die vorhandene Funktionalität in der API verwendet, um zu warten, bis der Puffer fertig ist. Es war jedoch eine rechtzeitige Erinnerung an die Gefahren, wenn man Annahmen über die Funktionsweise der neuen Plattform (und auch den Fehler) vornimmt kann auf jeder Plattform sein).
Wir hatten das Glück, dass die früheren Spiele bereits auf Sonys Xperia Play veröffentlicht wurden. Dies bedeutet, dass nicht viel Arbeit erforderlich war, um die Tasten zum Laufen zu bringen - viele der physischen Steuerelemente, die auf der Vita vorhanden sind, existieren auf der Xperia und der verwandte Funktionalität war bereits vorhanden.
Dies bedeutete, dass es wirklich nur darum ging, die Hardwareschlüssel den Softwareschlüsseln zuzuordnen und den Status der Tasten "Gedrückt" und "Freigegeben" an den vorhandenen Eingabebearbeitungscode weiterzugeben.
Da das Spiel von mobilen Geräten stammt, gilt dies auch für das Front-Touch-Panel. Das hintere Touchpanel erforderte ein wenig Finesse, das offensichtliche Problem ist, dass Sie beide nicht einfach in den gleichen Eingabestrom speisen können, denn wenn ein Spieler beide Panels berührt und die Front freigibt, möchte das Spiel dies möglicherweise als registrieren Entsprechung der Freigabe des Rückens oder nicht.
Es gab auch ein wenig Arbeit, um Eingaben von der Rückseite (die nicht die gleiche Größe wie der Bildschirm hat) anzufertigen, um das Gefühl zu haben, als würden sie korrekt auf der Frontplatte abgebildet. Dies wurde erreicht, indem eine Totzonenbegrenzung um die Kante der Rückwand nicht berücksichtigt wurde und die Eingänge innerhalb dieses Bereichs skaliert wurden, um sie dem Bildschirm zuzuordnen.
// Die hinteren Eingaben scheinen sich nicht vollständig an den vorderen Bildschirm anzupassen, also strecken Sie sich im Code. // Dies sind Werte, die sich als leicht zugänglich ergaben. define REAR_STRETCH_Y 544 statisch vec2 vitaMapRearInputToScreen (int inputX, int inputY) vec2 stretchedInput; stretchedInput.x = (inputX-REAR_DEADZONE_MIN_X) * REAR_STRETCH_X / (REAR_DEADZONE_MAX_X-REAR_DEADZONE_MIN_X); stretchedInput.x = clampf (stretchedInput.x, 0, REAR_STRETCH_X); stretchedInput.y = (inputY-REAR_DEADZONE_MIN_Y) * REAR_STRETCH_Y / (REAR_DEADZONE_MAX_Y-REAR_DEADZONE_MIN_Y); stretchedInput.y = Spiel (stretchedInput.y, 0, REAR_STRETCH_Y); retouredInput zurückgeben;
Alles in allem glaube ich, dass wir hier ziemlich leicht davongekommen sind, zum Teil aufgrund der Tatsache, dass das Spiel vollständig auf einer einfachen Wischgeste beruht. Das Portieren über radikal unterschiedliche Schnittstellen kann echte Kopfschmerzen verursachen und, wenn man es schlecht macht, das Potenzial haben, ein ansonsten großartiges Spiel zu beeinträchtigen. Hätten wir ein Third-Person-Actionspiel auf die Wii portiert, wäre dieser Abschnitt wesentlich länger gewesen.
Ich lüge nicht Ich habe eine echte Liebe / Hass-Beziehung zu Audio. In meiner Zeit bei Free Radical Design habe ich viel Zeit mit den Audio-Jungs des Engine-Teams und den Sound-Designern gearbeitet, um Audio in das Spiel zu bekommen und es hat mir sehr gefallen. Audio hebt ein Spiel wirklich an und erweckt es zum Leben.
Leider hat mich die etwas niedrigere Seite der Dinge mit ihrem Cocktail aus Dateiformaten, Sample-Raten, Komprimierung, Stimmen, Bussen, Dateistreaming usw. noch nie so begeistert. Wir sind also mit einiger Besorgnis an diese Aufgabe herangegangen.
Glücklicherweise enthält das Vita SDK (regelmäßig aktualisierte) Samples, die alle Möglichkeiten der Verwendung der Audio-API umfassend behandeln. Das Minimum, das Sie selbst in den einfachsten 2D-Spielen benötigen, ist die Möglichkeit, einmalige Sounds (die Soundeffekte des Spiels) wiederzugeben, und die Möglichkeit, Audio (Musik und andere große Dateien, die zu groß sind) zu streamen die ganze Zeit in den Speicher geladen bleiben). In vielen 2D-Spielen können Sie sich wahrscheinlich sogar für Mono entscheiden und sich etwas mehr Speicherplatz sparen - vielleicht sogar, um das Streaming vollständig zu vermeiden.
Mit einigen großartigen Hinweisen für die Arbeit in den Samples hatten wir in ein paar Tagen alle Audiodateien in Betrieb. Die einzige andere Hauptarbeit im Bereich Audio war die spätere Umstellung des Audioformats von VAG auf ein proprietäres Format mit einem viel höheren Komprimierungsgrad, wodurch der Speicherbedarf des Audiospeichers auf etwa 30% des vorherigen Werts reduziert wurde.
Am Ende war der Prozess der Audio-Implementierung weit weniger schmerzhaft als ich befürchtet hatte.
Quell Memento ist ein Einzelspieler-Spiel ohne vernetztes Gameplay und eingeschränkte Online-Funktionen. Daher sollte dies theoretisch einer der einfacheren Bereiche gewesen sein. In der Realität wird auf eine der Herausforderungen bei der Portierung auf eine PlayStation-Plattform hingewiesen: Die gefürchteten TRCs (Checkliste für technische Anforderungen - eine Liste der Entwickler, die Entwickler für das Bestehen der QA erfüllen müssen).
Ich sollte darauf hinweisen, dass Sony hier nicht einzigartig ist. Microsoft und Nintendo haben ihre Entsprechungen. Im Gegensatz zu mobilen Anwendungen, bei denen die Online-Funktionalität häufig von einer Cross-Platform-Lösung eines Drittanbieters bereitgestellt wird, oder von PCs, bei denen die Endbenutzer die einzige Entscheidung über Ihre Implementierung treffen, wird bei diesen Konsolen dieser Bereich häufig einer eingehenden Prüfung unterzogen. Dies hängt zum Teil mit der Sicherstellung zusammen, dass die von einem Dienst wie PSN bereitgestellte Funktionalität sich über die Titel hinweg konsistent verhält und dass Jugendschutz, Altersbeschränkungen usw. eingehalten werden.
Wenn Sie also zu einer Konsole portieren, kann dies, selbst für ein Spiel mit relativ einfachen Online-Funktionen, mehr Zeit in Anspruch nehmen als erwartet. Die Einhaltung von TRCs ist für einen Port möglicherweise einer der aufdringlichsten Teile Ihrer Arbeit. Spezifische Anforderungen für den Umgang mit Ereignissen wie Verbindungsverlust oder Ablehnung des Zugriffs auf Funktionen aufgrund einer Kindersicherung sowie der Zeitpunkt und die Art und Weise, in der Sie diese Dinge an den Benutzer weiterleiten müssen, kann durchaus ein gewisses Maß an Hin- und Herbewegungen erfordern Spiel- und Netzwerkkomponenten, die im ursprünglichen Spiel einfach nicht vorhanden waren.
Wir haben eine von Sony bereitgestellte Bibliothek verwendet, die alle einfachen Setups und Abbrüche von PSN- und Online-Aufgaben in einer recht einfachen Oberfläche zusammenfasst und Rückrufe für alle asynchronen Aufgaben bereitstellt. Die Aufrufe des Spiels in die Online-Funktionalität können auf wenige Gruppen - Login, Store und Leaderboards - beschränkt werden, die jeweils einige Parameter zur Festlegung der Details enthalten.
All dies bedeutete, dass eine Online-Anfrage mit nur wenigen Codezeilen ausgelöst werden konnte, und am Ende hatten wir wahrscheinlich nicht mehr als fünf oder sechs verschiedene Funktionen, die aus dem Spiel aufgerufen wurden, um die Online-Funktionen zu unterstützen.
Die Rückrufe des Sony-Wrappers liefern sehr detaillierte Details zu allen Fehlern, die jedoch meistens fehlerhaft sind. Diese können jedoch einfach als Erfolg oder Misserfolg eingestuft werden und den entsprechenden Rückruf für das Spiel auslösen. Dies bedeutete, dass wir auch die Rückrufe von der Engine in das Spiel auf ähnlich wenige Aufrufe reduzieren konnten.
Fehlerzustände wurden so weit wie möglich im Engine-Code behandelt. Dies bedeutete, dass die Fallen Tree-Jungs Quell weiterentwickeln konnten, ohne sich um Vita-spezifische Versagenszustände kümmern zu müssen.
Zum Beispiel, wenn eine Engine-Funktion einen Aufruf mit Voraussetzungen hatte, der möglicherweise fehlschlagen könnte, anstatt vom Spiel die Voraussetzungen und aufrufen zu müssen dann Bei seiner Anfrage würden wir die Voraussetzung im Hintergrund aufrufen und die eigentliche Anfrage zwischenspeichern. Wenn die Voraussetzung fehlschlug, würden wir die Anforderung ausgeben und das Spiel durch den normalen Rückruf benachrichtigen, indem das Dialogfeld von der Engine-Seite aus aufgerufen wird. Bei Erfolg wird die Anforderung wie beabsichtigt ausgeführt.
Dies funktionierte im Allgemeinen gut. Wie bei jedem System, das später hinzugefügt wird und sein bestes tut, um nicht aufdringlich zu sein, gab es ein oder zwei weniger elegante Teile, aber es hat seine Aufgabe erfüllt.
Sichere Spiele sind erwähnenswert, da sie wie die oben genannten Netzwerkfunktionalitäten in Bezug auf TRCs einem hohen Grad an Überprüfung unterliegen. Speicherspiele sind anfällig für zwei Schlüsselfehler: Nicht genügend Speicher für Dateien oder Speicherkontingent.
(Ich habe das Speichern von Korruption ausgeschlossen, da es wirklich nicht viel ist, was Sie im Zusammenhang mit einem korrupten Speichern tun können. Das System wird Sie darauf aufmerksam machen und Sie können den Benutzer informieren. Alles, was Sie tun können, ist, sie zu entfernen und fortzusetzen … Und vielleicht bei all den verlorenen Stunden ein leises Weinen haben.)
Das Auslagern des Dateisystems ist ziemlich selbsterklärend: Es gibt einfach nicht genug Speicherplatz, um das zu speichern, was Sie möchten. Die Sicherungsquote wird während der Entwicklung Ihres Spiels festgelegt. Es handelt sich im Wesentlichen um eine selbst deklarierte Begrenzung des Speicherplatzes, den Ihre Anwendung zum Speichern von Spieldaten benötigt. Dieses Kontingent wird jedoch nicht bei der Installation Ihres Spiels zugewiesen - es ist jedoch nicht garantiert, dass es existiert.
Bei der Handhabung jedes dieser Optionen haben Sie zwei Möglichkeiten.
Wenn für das Spiel kein Dateisystemspeicher mehr zur Verfügung steht, können Sie:
Das Speichern des Kontingents ist erschöpft:
Die Natur von Quell erlaubte es uns, dies mit den Optionen 2 und 1 recht knapp zu bewerkstelligen. Quell ist kein Spiel, bei dem Sie möglicherweise zu Ihrem Save von vor fünf Minuten zurückspringen möchten. Es ist nur ein Save erforderlich, und dieser wird automatisch erstellt, -saved und -loaded. Der Inhalt und damit die Größe des Speichers ist etwas vorhersehbar.
Beim ersten Versuch wird unser Speichersystem versuchen, die maximale Speichermenge zuzuteilen, die es für Ihre Sicherungsdatei benötigt. Wenn dies nicht möglich ist, das heißt, wenn bereits unzureichender Dateisystemspeicher verfügbar ist, wird die folgende Standardmeldung angezeigt:
Der Player darf nicht fortfahren, bis er dieses Problem selbst gelöst hat (durch Minimieren oder Schließen der App und Löschen einiger Daten). Wenn Sie auf OK klicken, wird erneut versucht, den Speicher zu reservieren. Wenn diese erste Sicherung erfolgreich erstellt wurde, kann davon ausgegangen werden, dass ein Mangel im Dateisystem und eine Sicherungsquote niemals auftreten werden.
Ich habe bereits kurz auf TRCs (die Checkliste für technische Anforderungen) hingewiesen, und als Haftungsausschluss würde ich sagen, dass ich glücklich bin, dass TRCs existieren. Als Spieler sind Dinge wie PSN zu einem so wesentlichen Bestandteil der Erfahrung geworden, dass ich es zu schätzen weiß, dass ich ein gewisses Maß an Konsistenz im Verhalten von Spielen erwarten kann.
Das heißt, als Entwickler sind sie ein Schmerz. Wir hatten Glück, dass das Spiel relativ einfach war und daher könnten viele TRCs einfach ignoriert werden, da sie nicht zutreffen. Selbst wenn Sie daran arbeiten, ein relativ einfaches Spiel auf einer der Konsolen zu veröffentlichen, würde ich Ihnen dringend raten, sich mit den Regeln dieser Plattform vertraut zu machen früh und verweisen auf sie häufig. Was möglicherweise auf einer Plattform akzeptabel war, kann auf einer anderen Plattform nicht flogen, und Sie möchten nicht warten, bis Sie eine große Liste von Gründen erhalten, warum Sie die Qualitätssicherung nicht geschafft haben, um festzustellen, dass Sie alles falsch gemacht haben.
Für ein kleines Team ohne eigene QS-Abteilung kann dies wie eine wirklich schwierige Aufgabe erscheinen, aber ein bisschen Sinn und Planung kann den Unterschied ausmachen.
Erstens sind viele Anforderungen nur eine spezifisch formulierte Methode, um Sie aufzufordern, keine dummen Dinge zu tun, die Sie wahrscheinlich sowieso nicht tun möchten. Zum Glück hatten die FTG-Jungs bereits etwas Dummes vermieden, also war dies ein guter Anfang.
Zweitens führten wir eine Tabelle mit allen Anforderungen und ob sie aktuell bestanden sind, nicht bestanden wurden, noch nicht getestet werden konnten oder einfach nicht anwendbar waren. Während die wichtigsten Funktionen in das Spiel einflossen, könnten wir diese Liste überarbeiten, um den Status jeder Anforderung zu aktualisieren und gleichzeitig unsere Erinnerungen auf die geltenden Beschränkungen aufzufrischen.
Als wir unsere QA-Phase erreichten, hatten wir eine ziemlich klare Vorstellung davon, wo wir in Bezug auf TRCs standen und sahen uns keinen bösen Überraschungen gegenüber.
Stellen Sie sicher, dass Sie klare Zeitpläne und Ziele festgelegt haben. Dies ist mehr ein geschäftliches als ein technisches Problem, aber entscheidend, wenn Sie ein Spiel für eine andere Person portieren, auch wenn es sich nur um ein Hobbyprojekt unter Freunden handelt. (Du willst Freunde bleiben, oder ?!)
Als wir mit der Arbeit an Quell Memento begonnen haben, war es noch nicht fertig, und obwohl es ein allgemeines Gefühl gab, wann der Endtermin sein würde, war nichts in Stein gemeißelt. Letztendlich dauerte das gesamte Projekt länger als erwartet.
Im Nachhinein wäre es vorzuziehen gewesen, zu warten, bis das Spiel vollständig beendet ist - oder zumindest weitaus vollständiger -, bevor wir unseren Hafen beginnen. Da wir die Engine portierten, wurde sie selten von neuem Gameplay und Inhalten beeinflusst, aber es gab Fälle, in denen Features Engine-Änderungen erforderten. Es gab auch Zeiten, in denen der Fortschritt beim Portieren der Engine blockiert wurde, da wir auf neue Funktionen warteten, die hinzugefügt werden sollten.
Wir haben eine großartige Beziehung zu den Jungs von FTG und hatten das Glück, in diesen Situationen die Flexibilität zu haben, während dieser Zeit zu unseren eigenen Projekten zu wechseln (einschließlich der Untersuchung einiger der einzigartigen Eigenschaften der Vita wie der Augmented Reality), aber wie jedem anderen auch Wer schon einmal ein bisschen Multitasking versucht hat, sollte wissen, dass dies nicht die effizienteste Arbeitsweise ist.
Es ist schwer, auf einzelne herausragende Lektionen hinzuweisen, die wir gelernt haben. Wir haben mehr und mehr Wissen über neue Tools, APIs und Prozesse gesammelt.
In Zukunft wäre es vielleicht mutiger, Änderungen im Code des Spiels zu erzwingen (oder zumindest zu suggerieren), wo es sinnvoll erschien - wir haben einige Aufgaben schwieriger gemacht, als sie diesmal nötig waren. Die Definition von „vernünftig“ wird jedoch von Projekt zu Projekt immer sehr unterschiedlich sein.
Außerdem würden wir wahrscheinlich warten, bis ein Spiel vollständiger ist, bevor wir in der Zukunft mit der Arbeit an einem Hafen beginnen und mehr Leute daran arbeiten werden, um es kürzer zu machen. Wiederum kann die Realisierbarkeit dieses Vorgangs je nach Veröffentlichungszeitplan sehr unterschiedlich sein. Wenn wir es einmal gemacht haben, können wir jetzt viel besser einschätzen, wie lange wir brauchen werden.
Am wichtigsten ist jedoch, dass wir auf einer neuen Plattform über Monate hinweg wertvolle Erfahrungen gesammelt haben, einschließlich des Einreichungsprozesses. Außerdem erhielten wir sogar die Möglichkeit, einige seiner einzigartigen Merkmale zu untersuchen. Für ein Team, das weitgehend auf Einstellungsarbeit und Leiharbeit basiert Einnahmen, deren Wert nicht unterschätzt werden kann.
Mein Rat für jeden von Ihnen, der einen Hafen für Vita in Betracht zieht, wäre, ihm einen Riss zu geben. Ich denke, es gibt eine gewisse Mystik um die Entwicklung von Konsolen. Wir hatten das Glück, Erfahrung auf diesem Gebiet zu haben, aber auch ohne dass Sie nicht abschrecken sollten.
Sony ist sehr herzlich zu Indies und kleinen Entwicklern (etwas, das sich meiner Meinung nach für die breitere Game-Entwickler-Community bemerkbar macht). Wenn Sie über ein gewisses Maß an technischen Kenntnissen bei der Entwicklung von Spielen verfügen, sollten Sie sich mit dem großartigen Support des Sony Developer Support-Teams nicht entscheiden keine unüberwindlichen Herausforderungen.
Quell Memento for Vita ist ab sofort in SCEA und SCEE verfügbar.