Käpt'n Coco - Flucht von Pepaja

Hallo,

ich habe vor 36 Level für mein neues Projekt zu erstellen. Es wird einfach beginnen und dann schwieriger werden. Dabei wird es 4 verschiedene Szenarien geben mit dann jeweils 9 Abschnitten.

Mit dem ersten Abschnitt habe ich bereits begonnen. Hier ein Screen des ersten Levels.

 

Hallo,

ich möchte euch heute einen kleinen Einblick in einen Level von Käpt'n Coco geben. Es handelt sich um den ersten von vier Spielwelten. Aus der ersten Spielwelt ist das jetzt einer von neuen Leveln die Käpt'n Coco auf seiner Flucht von Pepaja durchqueren und absolvieren muss.

https://www.youtube.com/watch?v=Z7D5aw7F-VA

 

Das Artdesign finde ich wirklich schön. Spricht mich persönlich wirklich an.
Ich würds auch meine Kinder spielen lassen.

Was mich persönlich irgendwie in dem Video nervt ist die permanente Rolle bei jedem Sprung. Könnte man einen Doppelsprung mit dieser Rolle integrieren und eine normale Sprunganimation einbauen? Nur mal so, die permanente Rolle beim Sprung wirkt halt sehr unruhig.

Ansonsten kann man halt noch nicht viel Feedback geben. Die weichen Animationen finde ich aber schön gemacht.

 

Ich danke dir. Es wird auch ein gewaltfreies Spiel werden. Der Spieler wird auch selber nicht böse aggieren können. Es geht ja um Geschicklichkeit und auch ein wenig Taktik.

OK, das dir das jetzt nicht so zusagt ist schade. Ich werde aber an dem Konzept festhalten.

Ich bin gerade dabei mit dem zweiten Abschnitt zu beginnen. Wenn es etwas Neues gibt werde ich es vorstellen.

 

Heute habe ich mit der zweiten Spielwelt angefangen und mir ein Layout überlegt. Desweiteren wird Käpt'n Coco Begegnungen mit Bewohnern von Pepaja haben.

Ein erster Gegner ist auf dem Screenshoot zu sehen. Hier wird es darum gehen schnell genug über die Hindernisse zu springen, bevor Coco erwischt wird und vom Stein fällt.

 

Hallo,

heute möchte ich euch eine kleine Demo vom Projekt zum Spielen anbieten. Die ersten 9 Level sind fertig. Es ist ein kleines Spiel für Zwischendurch. Käpt’n Coco muss mit Sprüngen nach vorne versuchen die Level erfolgreich zu beenden.

In der weiterführenden Version erhält er dann nach dem Vollenden einer Spielwelt ein Teil seines Raumschiffes zurück.

Hier der Downloadlink: http://www.pchobbyspieleschmiede.de/coco/FVP_0.1.0.zip

 

Ich gehe davon aus, dass du hier nicht einfach nur Beifall und Schulterklopfen suchst, sondern ernsthaft an Feedback interessiert bist (um das Beste aus deinem Projekt zu holen). Von daher ist das Feedback auch etwas detaillierter, da ich Feedback à la "Movement ist clunky" mangels Inhalt ziemlich nutzlos finde.

Feedback zur Grafik
Prinzipiell gefällt mir die Aufmachung, aber bei mir hat es den Eindruck hinterlassen, dass sich das Spiel nicht entscheiden kann, ob es bunt sein möchte oder nicht. Manche Elemente haben knallige Farben, andere sind relativ blass. Vor allem diverse Pflanzen wirken eher wie ausgewaschen.

Irritierend fand ich auch die Inkonsistenz bei den Grafik-Modellen. Manche Pflanzen haben viele Rundungen und wirken sehr organisch. Andere Pflanzen wiederum haben sehr eckige Modelle.

Feedback zum Gameplay

Grundmechanik/ Grunddesign
Nach meinem Verständnis ist das Kern-Gameplay so ausgelegt, dass man die passenden Sprünge von A nach B macht. Und zwar mit folgendem Rahmen:

• Man kann einen normalen Sprung machen.
• Den normalen Sprung kann man zu einem Doppelsprung machen.
• Der Doppelsprung kann nur ein Mal eingeleitet werden.
• Coco muss auf dem Boden landen, bevor der nächste Sprung möglich ist.

Momentan wird der Sprung aber nicht nur bei einer Landung aufgeladen, sondern sobald man Kontakt mit der Level-Geometrie hat, z.B. wenn man gegen ein Hindernis prallt. Das wirkt ungewollt und als Spieler wie Glitch-Abusing.

Tod & Respawn
In der Regel wird bei Platformern nach dem Tod der gesamte Level zurückgesetzt. Dies hat zur Folge, dass die Ausganssituation und somit auch die Herausforderung immer dieselbe ist. Hier erfolgt nur ein Respawn von Coco und der Level läuft weiter. Dies kann bei späteren Leveln ziemlich nervig sein, da man unter Umständen bei zeitkritischen Passagen einfach im falschen Moment ankommt und teilweise (fast) keine Chance mehr hat weiterzukommen.

Im Prinzip läuft man also manchmal direkt in eine Sackgasse, weil das Timing nicht mehr passt. Natürlich kann man das umgehen, indem man den Level auswendig lernt und dann an bestimmten Stellen abwartet. Das ist aber ziemlich nervig, weil das Spiel den Level auch einfach zurücksetzen könnte.

Kollisionsabfrage, Gravitation & Movement
Gefühlt ist bei der Gestaltung der Kollisionsabfrage und einzelnen Movement-Aspekten etwas grundlegend falsch. Jedenfalls bin ich auf mehrere Probleme gestoßen.

1. Man kann an unsichtbaren bzw. nicht-nachvollziehbaren Kanten hängen bleiben. (Dies betrifft vor allem die Treppen-Elemente)
2. Man kann zwischen Plattformen hängen bleiben (anstatt in den Tod zu fallen)
3. Man kann von herabfallenden Plattformen stürzen, obwohl man sich nicht bewegt.
4. Man kann am Rande einer Plattform in der Luft stehen - oder auch nicht - oder doch...

Punkt 3 ist wohl eine Interaktion aus Bewegung der Level-Geometrie und der Gravitation, die auf Coco wirkt. Die herabfallende Plattform bewegt sich nach unten links und wenn man nichts tut, dann würde Coco eigentlich auf der Plattform stehen bleiben (Physik und so). Coco wandert aber nicht mit der Platform mit und wird somit im Zweifelsfall von der Gravitation von der Plattform in den Tod gezogen. (Das kann übrigens durch den vorher aufgezeigten Aspekt bei "Tod & Respawn" ziemlich nervig werden. Eventuell muss man nämlich aus Timing-Gründen erst warten, aber das Spiel zieht einen dann in den Tod...)

Punkt 4 ist anstrengend, weil die Kollisionsabfrage am Rand nicht immer nachvollziehbar ist. Manchmal steht Coco visuell komplett in der Luft, aber steht sicher. Manchmal steht Coco quasi nur an einem Pixel am Rande und dann weiß man nie was passiert.

Die Spielfigur neigt übrigens unter gewissen Umständen zum Driften. Das sieht man bereits im allerersten Level, wenn die Figur in der Luft spawnt, landet und dann im Stand nochmal nach rechts rutscht. Ich denke mal das hängt auch mit der Gravitation zusammen(?).

Lesbarkeit & Feedback
Bei der Kollisionsabfrage hatte ich schon ein paar Punkte angesprochen, welche sich auf die Nachvollziehbarkeit auswirken. Folgendes ist mir noch aufgefallen:

Movement
Die Animationen für den normalen Sprung und den Doppelsprung sind identisch (wie @muppel bereits angemerkt hat). An der Stelle fehlt nicht einfach nur ein optisches Schmankerl, sondern wichtiges visuelles Feedback. Der Wechsel der Animation kommuniziert nämlich wie die Sprungmechanik funktioniert. Konkret ab wann man vom normalen Sprung in den Doppelsprung wechseln kann. Das ist viel greifbarer, wenn es visuell kommuniziert wird.

Levelstruktur
Die Position der Spielfigur in der Tiefe ist manchmal etwas ungünstig und wirkt irritierend. Das sieht man z.B. im ersten Level sehr deutlich. Da steht Coco mal mittig auf einer Plattform und mal vorne an der Kante. (Kommt wahrscheinlich dadurch zustande, dass du die Plattform einfach nur gedreht und nicht neu ausgerichtet hast).

Darüber hinaus habe ich mich gefragt, ob du beim Leveldesign mit einem Raster arbeitest und dabei zwischen 3 grundlegenden Sprüngen unterscheidest (Normaler Sprung, Früh eingeleiteter Doppelsprung für kurze Distanz, Spät eingeleiteter Doppelsprung für weite Distanz), um die Abschnitten passen zu designen. Bisher hat es sich für mich nach einem inkonsequentem Raster angefühlt. Jedenfalls war ich mir öfters unsicher, ob ich vorher doof gesprungen bin oder das Level "einfach krumm designt ist".


Gesamtfazit
Wie eingangs erwähnt wollte ich detailliertes Feedback geben. Insgesamt fand ich das Spiel interessant, andernfalls hätte ich es gar nicht erst getestet. Und es hat mir durchaus Spaß gemacht.

Zur Zeit ist eben das Problem, dass verschiedene Macken/ Schwächen ineinandergreifen und deswegen kann das Spielerlebnis ziemlich schnell bergab gehen, wenn es gerade nicht läuft. Für mich hat sich das Spiel dann teilweise wie ein einziges Glitch-Fest angefühlt. Oder es hat sich nervig angefühlt, weil man gefühlt eher ein Opfer von Designschwächen war.

Das hat mich auch irritiert, da das Spiel (gefühlt) grafisch schon sehr weit ist. Ich habe den Eindruck, dass du an allem gleichzeitig arbeitest. Von daher würde ich an dieser Stelle empfehlen einen Schritt zurück zu machen und mit Prototyping-Models erst mal nur an der Mechanik zu arbeiten (Quasi so wie hier), weil dann nichts vom Gameplay ablenkt. Und die Grafik kommt dann drauf, wenn alles schön knackig ist.

 

Das Feedback kann ich so unterschreiben.
Aber das Artwork spricht mich wirklich sehr an. Erinnert mich an frühe Plattformer Ende der 90er. War ne tolle Zeit und es weckt sehr schöne Erinnerungen daran.

Stecke aber deine Energie erst mal wie bereits erwähnt in die Mechanik und mach es rund.

 

Hallo kanedat,

wow, vielen Dank für das umfangreiche Feedback und die vielen Verbesserungsvorschläge. Natürlich möchte ich eine qualifizierte Rückmeldung und die hast du mir eindruckvoll erteilt. Ich mache das aus rein hobbymäßigem Interesse und lerne gerne immer etwas dazu. Da ich mit Unity erst im November letzten Jahres angefangen habe, muss ich noch kräftig lernen. Die andere Seite ist das Gameplay und die Gamemechanik und meine eigene Vorgehensweise bei der Erstellung eines neuen Projektes. Jedes Gengre hat ja so seine Eigenheiten und eine andere Vorgehesweise. Desweiteren habe ich selber auch, was die einzelnen Gengres angeht, keine eigenen großen Spielerfahrungen. Ich schau mir dann einfach bereits existierende Spiele an und orientiere mich daran. Ich will sie nicht 1:1 nachbauen, aber als Zielrichtung hilft mir das enorm.

Eine gute Hilfe ist auch der Projektablauf, den du als Verlinkung angegeben hast. Kann man sich schön dran orientieren. Fällt mir zwar immmer schwer, ist aber doch recht sinnvoll. Vieles fällt mir dann auch erst später auf. Daher ist ein Feedback für mich immer sehr motivierend. Schon allein, wenn das Grundprinzip des Spiels schon mal positiv ankommt.

Ich habe mich gestern auch schon mal an die ersten drei Level gemacht und das eine oder andere beachtet und geändert. Im prinzip kann ich das alles nachvollziehen was du geschrieben hast.

Ein Problem habe ich aber ncoh bezüglich der Ausrichtung an einem Raster. Das kann ich nachvollziehen und macht auch Sinn. Ich kann z.B. den Abstand zwischen den Platformen entfernungsmäßig so bauen, das es mit einem Sprung, Doppelsprung... so hinhaut, das Coco immer in der Mitte der Plattform landet. Wenn es jetzt aber bewegenden Plattformen sind (hoch/runter), das verändert sich ja jeweils der Winkel und das funktioniert dann nicht mehr. Spätestesn dann wird es wieder zu Verschiebungen bis hin zu einem Levelneustart kommen.

Damit der Spieler sich bei Fehlsprügen nicht in den Tod retten muss, um einen Levelneustart zu erhalten, habe ich jetzt eine zusätzliche Schaltfläche eingebaut. Mit der kann der Spieler jederzeit entscheinden den aktuellen Level abzubrechen und neu zu beginnen.

Ich werde jetzt die neun Level der ersten Spielwelt "schön" oder "schöner" machen und dann meine Überarbeitung hochladen. In diesem Zusammenhang würde ich mach dann wieder über eine Rückmeldung freuen. Ich hoffe ich kann das alles soweit einbauen und überrabeiten.

Gruß, Andreas

 

Ja, im Zweifelsfall überspringt man gerne mal einen Schritt, da man natürlich gerne früher Ergebnisse sehen möchte, aber das rächt sich am Ende immer.

Auf den Schritt zurück zu Prototyping-Elementen kam ich auch aufgrund der Kollisionsabfrage, aber bin mir nach wie vor unsicher, wie die technisch umgesetzt ist. Also ob die Models über eine einfache Kollisionsbox verfügen oder die Models selbst (inklusive allen Unebenheiten) genutzt werden. Bisher hatte ich den Eindruck, dass die Kollisionsabfrage über das 3D-Model selbst läuft und durch die Unebenheiten ungünstige Situationen entstehen. Aber ich kann mich da natürlich auch irren.

Beim mittig stehen ging es mir um die räumliche Tiefe, ich erläutere das mal mit diesem Screenshot:

Spoiler

Es gibt hier in der Levelgeometrie immer einen klaren Weg, den habe ich mal farblich eingezeichnet. Donkey Kong steht in der Tiefe immer an der selben Position, er wandert nicht nach vorne oder hinten. Dadurch ist die Spielfigur ganz klar verortet in der Umgebung.

Natürlich ist Coco bei dir auch in der Tiefe an der selben Position verortet, aber die Levelgeometrie lässt das teilweise anders wirken, weil die Positionierung ungünstig ist. Auf dem obigen Screenshot vom ersten Level sieht man, wie Coco nach vorne (zur Kamera hin) an der Kante steht. Auf dem ersten Fels steht sie aber mittig auf dem Felsen. Es wirkt also unfreiwillig so als würde die Coco ein wenig nach vorne/ hinten wandern, die Verortung in der Umgebung ist dadurch auch nicht so klar. (Das ist natürlich kein Weltuntergang, aber wenn der Umstand mit 2-3 anderen Macken zusammen kommt, dann fühlt sich am Ende eventuell alles etwas diffus an.)

Für solche Dinge ist der Prototyping-Schritt auch ganz praktisch, weil man dann erst mal mit stumpfen Blöcken arbeitet und einen klaren Weg hat. Und sobald man die richtigen Models einsetzt, merkt man wie sich der Weg ggf. verschiebt.

Zur Rasterung:
Natürlich gibt es mehr als die 3 Sprünge, die ich oben erwähnt hatte. Von daher wird man immer mal in unterschiedlichen Positionen landen. Und eben auch aufgrund des Winkels, den du angesprochen hast.

Es ging mir in erster Linie darum, dass sich die Level konsistent anfühlen und mehr Klarheit herrscht. Bei der allerersten Plattform im zweiten Level bin ich z.B. bei der ersten Plattform meistens an der vordersten Kante oder an der hintersten Kante gelandet, aber nie richtig auf der Plattform. Gefühlt war der eine Sprung zu kurz, aber gleichzeitig der andere Sprung zu lang und es gab keine richtige Lösung. (Und das eben beim allerersten Sprung im zweiten Level, bevor es wirklich losgeht)

Gefühlt war die Plattform einfach doof positioniert und dieses Gefühl bleibt im Zweifelsfall auch erhalten. Im Anschluss habe ich dann bei diversen Stellen ernsthaft daran gezweifelt, ob ich den Sprung falsch mache oder „die Plattform einfach wieder doof positioniert ist“.

 

Hallo Community,

nach einem sehr umfangreichen und konstruktiven Feedback habe ich meine erste Demo von Käpt’n Coco überarbeitet.

Folgende große Kritikpunkte waren:

1. Man kann an unsichtbaren bzw. nicht-nachvollziehbaren Kanten hängen bleiben. (Dies betrifft vor allem die Treppen-Elemente)
2. Man kann zwischen Plattformen hängen bleiben (anstatt in den Tod zu fallen)
3. Man kann von herabfallenden Plattformen stürzen, obwohl man sich nicht bewegt.
4. Man kann am Rande einer Plattform in der Luft stehen - oder auch nicht - oder doch...

Ich habe mir jeden Level diesbezüglich nochmal angesehen. Mir ist dabei insbesondere aufgefallen, dass ich bei den Kollisionsboxen sehr ungenau gearbeitet habe. Desweitere habe ich die ersten Plattformen an die Möglichkeiten der Sprünge angepasst. So landet Coco jetzt direkt auf der Plattform. Das Prinzip ist natürlich nur bei sich nicht bewegenden Plattformen möglich. Die Treppen habe ich raugenommen. Ich habe keine eindeutige Kollisionsabfrage hinbekommen. Im Moment habe ich noch keine Differenzierung von Coco bezüglich eines einfachen bzw. doppelten Sprung.

Die fehlerhafte Panelabfrage im Menü habe ich beseitigt und in jedem Level kann der Spieler jetzt jederzeit den Level neu starten. Insbesondere wenn er frühzeitig erkennt, dass seine Sprünge nicht richtig getacktet waren.

Ich habe jetzt eine überarbeitete Demo Version 0.2.0 zum Download eingestellt und würde mich über eine Rückmeldung freuen.

Download: http://www.pchobbyspieleschmiede.de/coco/FVP_0.2.0.zip

Gruß, Andreas

 

Das zweite Level ist wohl verbuggt. Wenn man im Ziel ankommt, dann erscheint nur die Sterne-Übersicht und es geht nicht weiter.

 

Sorry, da habe ich die Kollisionsbox wohl etwas zu klein gemacht. Ist jetzt behoben.

 

Ich hatte das selbe Problem nochmal im vierten(?) Level. Ich war mir mit der Level-Nummer unsicher, wollte dann doch noch einen Screenshot machen und habe das Spiel nochmal gestartet. Aber dann hat es funktioniert.

(Für das Testen wäre es cool, wenn die Level-Nummer irgendwo angezeigt wird. Dann muss man sich das nicht merken)

Ansonsten:
Bisher fühlt es sich durch die Bank weg sauberer an. Die Mechanik hakt eben noch hier und da.

Punkt 2 und 3 konnte ich jetzt nicht richtig testen, weil ich nicht in die Situation gekommen bin. (Dazu unten mehr)

Sprung-Reset
Prinzipiell konnte ich mich wieder mal etwas durchmogeln, als ich an einer Plattform vorbei gesprungen bin. Ich hatte nämlich noch den Doppelsprung, bin mit dem Doppelsprung von unten an die Plattform gesprungen und dadurch wurde der Sprung-Reset ausgelöst. Dann bin ich wieder von unten an die nächste Plattform gesprungen, bekam meinen Sprung-Reset und konnte mich somit unterhalb von 2-3 Plattformen durchglitchen.

Ich denke an der Stelle liegt das Problem darin, dass Idee und Umsetzung nicht richtig zusammenpassen.

Bisher hatte ich die Idee so interpretiert:
Immer nur 1x Sprung und 1x Doppelsprung = Sprung-Reset mit Landung

Und die ist momentane so umgesetzt:
Sprung-Reset bei Kollision mit Level-Geometrie

Die Kollision kann aber in vielen Fällen auftreten und nicht nur mit der Landung. Momentan fehlen also die weiteren Faktoren, die sicherstellen, dass die Idee richtig umgesetzt wird. An sich müsste noch geprüft werden, ob Coco sich bewegt. Vielleicht wird es das auch schon, weil man bei Kollision mit Level-Geometrie im Zweifelsfall für einen Frame komplett stillsteht. Das könnte man aber wiederum mit zusätzlichen Zonen einschränken, die nur dort liegen, wo Coco auch landen kann:

Spoiler: Kollisionszonen für Sprung-Reset

Die Logik grundlegende wäre dann:
Kollision mit Level-Geometrie + Coco bewegt sich nicht + Coco ist in Reset-Zone = Sprung-Reset

Die Zonen wären dann eben Teil vom Prefab.


Kollision bei Plattformen
Punkt 4 hat sich gefühlt in die Gegenrichtung verschoben hat. Ich hatte jetzt wiederholt das Problem, dass ich in sehr knapp Sprüngen am Rand durch die Plattform gefallen bin. Das ist mir so oft passiert, dass ich erst mal abgebrochen habe. Gefühlt ist diese Ecke hier teilweise Luft:

Spoiler: Doofe Kollisionsecke

Das innerhalb der regulären Level durchzutesten ist denke ich generell zu umständlich. An der Stelle würde ich empfehlen Testumgebungen zu bauen, um bestimmte Dinge explizit durchzutesten.

Testumgebungen
Bei manchen Sachen bin ich mir unsicher, ob die sich recht schnell auflösen und ganz viel Feintuning benötigen. Mein Ansatz wäre an der Stelle für spezifische Szenarien eine eigene Testumgebung zu bauen.

Bei Kollisionsabfrage geht es z.B. allgemein darum, dass Coco zuverlässig auf einer Zielplattform landet. Das wäre dann schematisch so:

Spoiler: Testumgebung

Wobei ich das auch automatisieren würde. Im Prinzip bräuchte man dazu ein Array mit den möglichen Positionen für die Level-Elemente und ein Skript zur Simulation von User-Input. Letzteres müsste dann verschiedene Sprünge auslösen (Normaler Sprung, Doppelsprung zu verschiedenen Zeitpunkten)

Dann würde eine Schleife das Array durchlaufen und folgendes machen:

• Positionierungsphase
  • Elemente neu positionieren
    (hier: Plattform 1, Plattform 2, Spawn-Punkt von Coco)
• Sprungphase
  • Coco spawnen
  • Den nächsten Sprung auswählen
  • Sprung auslösen

Damit könntest du dann eine Vielzahl von Konstellationen automatisch durchlaufen lassen und schauen, ob deine Spielmechanik sich so verhält, wie sich verhalten soll. Du müsstest einfach nur zuschauen. (Im Idealfall hättest du noch ein paar Kontrollelemente und kannst z.B. über ein Dropdown-Menü eine bestimmte Testkonstellation auswählen, die du nochmal testen willst, weil es genau bei dieser Konstellation vorher einen Fehler gab)

Das ist natürlich mit einem gewissen Aufwand verbunden, weil man dafür erst die Grundlagen schaffen muss. Aber wenn das erst mal steht, dann kann man mit einem geringen Aufwand in sehr kurzer Zeit sehr viele Situationen durchtesten. Beim manuellen Testen geht nämlich auch viel Zeit für unnützen Krams drauf.

Punkt 3 (Man kann zwischen Plattformen hängen bleiben (anstatt in den Tod zu fallen)) konnte ich z.B. aktuell gar nicht wirklich testen, weil ich gar nicht in die Situation gekommen bin. Ich hätte da also erst mal schauen müssen wie ich Coco nun positionieren muss, damit ich das an einer bestimmten Stelle im Level überprüfen kann. Dafür hatte ich dann keine Motivation.

Klar, du kannst es selbst machen und bist mit Sicherheit motivierter (als meine Wenigkeit), aber ich denke du kannst deine Zeit auch sinnvoller nutzen, wenn du hauptsächlich an der Spielmechanik arbeitest.

 

Danke dir für die weiteren Rückmeldungen, Ideen und Vorschläge zur Verbesserung meines Spiels. Ich habe jetzt die Plattformen so definiert, das ein Aufladen des Sprungs nur noch dort möglich ist. Jetzt habe ich aber noch eine Nachfrage wie du das lösen würdest.

Ich habe hier meine Plattform:


Dort habe ich wie beschrieben meine Plattform mit der auch der Sprung aufgeladen wird. Der Felsen selbst hat jetzt keine Kollisionsbox, da diese ja dann wieder größer wäre als die Plattform. Jetzt müsste ich aber von unten nochmal eine unsichtbare Plattform etwas unter die odere schieben, damit beim Unterspringen der Sprung nicht wieder aufgeladen wird. Das war ja das von dir beschriebenen "Mogeln" wenn ich dich richtig verstanden habe. Oder hast du einen anderen Vorschlag?

Da stellt sich mir jetzt die Frage wie das bei sich bewegenden Plattformen funktionieren soll. Da existieren doch dann im Prinzip unendlich viele Variationen. Ich denke, ich werde das einfach mit viel Probieren und Zeit so gut wie möglich anpassen. Auf jeden Fall sind mehrere Kollisiosboxen jetzt zu klein gewählt. Ich passe erstmal die Box von Coco an, vielleicht reicht das dann.

In der nächsten Testversion werde ich die einzelnen Level vom Menü direkt auswählbar machen.

 

Man muss es in Relation zum manuellen Testen sehen:
Manuell testet man vielleicht 10-20 Variationen und selbst wenn man automatisch nur 50-60 Variationen testet, dann ist das bereits ein Vielfaches. Und dieses Vielfache läuft schneller durch.

Wenn du von Hand durch eine Testumgebung hüpfst, dann würdest du ja auch ein paar Variationen zusammenstellen. Bei denen variiert man z.B. dann einfach automatisiert die X-Koordinate, wenn Coco unterschiedlich stark auf der Kante landet. (Die beweglichen Plattformen wären auch nicht so dramatisch, da es um die Kollisionsabfrage bei der Landung geht. Von daher muss sich die Zielplattform nur von ihrer Ausgangsposition ein bisschen bewegen, aber keinen längeren Weg haben)

Wie bereits gesagt wäre das auch nur ein Ansatz für den Fall, dass die Kollisionsabfrage zeitnah nicht richtig knackig wird und man daher noch viel an Mechaniken ändern und diese anschließend testen muss. (Im Sinne von "Wenn schon viel Feintuning, dann am besten auch viele Variationen testen")

Zum wichtigeren Teil:

Ja, mit Mogeln meinte ich das Aufladen des Sprungs, wenn man von unten/ seitlich an Plattformen stößt ohne zu Landen. Ich war aufgrund eines dummen Fehlers unterhalb von Plattformen und wäre in den Tod gefallen, aber konnte von unten den Sprung immer wieder aufladen.

Ich bin mir unsicher, ob es der letzte Beitrage eventuell etwas unklar war, weil 1-2 Stellen nicht komplett ausformuliert waren. Prinzipiell sind es 2 Probleme:

1. Passende Kollisionsabfrage
2. Sprung nur dann aufladen, wenn er aufgeladen werden soll

Die Mogel-Problematik kam dadurch zustande, dass grundlegend verschiedene Spielmechaniken über einen Mechanismus geregelt wurden, also die Kollision. Kollisionen gibt es prinzipiell aber mit jeder Seite eines Objekts (Oberseite, Unterseite, linke Seite, rechte Seite). Der Sprung soll aber nur aufgeladen werden, wenn Coco landet, also wenn Coco auf der Oberseite steht und sich nicht bewegt.

Wenn ich das richtig verstanden habe, dann löst du nach wie vor alles über die Kollision mit einem Objekt. Nur jetzt mit einer unsichtbaren Plattform, die in dem 3D-Modell steckt. Ich würde aber beide Punkte getrennt behandeln, da es zwei verschieden Spielmechaniken sind:

• Kollision: Hier geht es nur darum, dass die Plattform ein fester Körper ist. Hier also Feintuning der Kollisionsbox der Plattform.
• Sprung aufladen: Hier geht es nur darum, dass Coco auf einem Objekt steht. Hier muss also nur geprüft werden, ob Coco auf der Oberseite eines Objekts steht und sich nicht bewegt. Dafür wäre die zusätzliche Zone da.

Nachtrag:
Die elegante Variante um nach einem Boden zu prüfen wird in Unity über Raycasts geregelt.

 

Hallo kanedat,

ich hoffe ich habe es jetzt nicht schlimmer gemacht als vorher. Die Kollisionsboxen und die Box von Coco habe ich jetzt nochmals etwas angepasst. Wenn Coco auf die Plattformen springt (oben) dann wird sein Sprung aufgeladen. Ich habe jetzt unter jeder Plattform noch eine zweite, etwas kleinere erstellt. Wenn Coco diese von unten anspringt, dann läd sich der Sprung nicht mehr auf. Jedenfalls habe ich das bei mir so testen können. Somit müsste das Problem mit dem Unterspringen jetzt nicht mehr vorhanden sein.

Ich habe im Menü die Möglichkeit vorgesehen die Level einzeln aufzurufen. Also, wenn du möchtest, dann schau dir meine neue Version mal an. Ich hoffe es wird besser. Jedenfalls motivieren mich deine Hinweise und Vorschläge sehr.

Download: http://www.pchobbyspieleschmiede.de/coco/FVP_0.2.0.zip

 

Hallo,

nach dem doch wesentlich länger und noch nicht komplett abgeschlossenen Feintuning bezüglich der Kollisionsabfrage, habe ich mich heute mit der zweiten Spielwelt befasst und den ersten Level daraus fertiggestellt.

Diesmal ist es eine etwas steinigere Welt mit vielen Felsen und Wasser. Coco wird hier auf Gegner treffen, denen er ausweichen (wegspringen) muss. Für einen ersten Eindruck habe ich ein kleines Video erstellt. Hier könnt ihr Coco in Action sehen.

https://www.youtube.com/watch?v=WJpCFd8sPAE

 

Also es spielt sich insgesamt schon wesentlich besser als die erste Version, aber bei verschiedenen Dingen ist nach wie vor der Wurm drin.

Auf bewegten Plattformen (welche die wie ein Aufzug von oben nach unten fahren) hat sich Coco zuweilen etwas ruckelig verhalten und ist nicht mit der Plattform sauber von oben nach unten gewandert. Außerdem kann es noch vorkommen, dass Coco beim Stehen auf einer Plattform in eine Richtung driftet. Beides passiert bei weitem nicht mehr so häufig wie zuvor, aber sollte dennoch zu denken geben, dass da beim Stehen auf einer geraden Oberfläche sollte eigentlich nichts unvorhergesehenes passieren.

Die Kollisionsbox bei den Felsen-Plattformen ist nach wie vor schwierig. Ich bin jetzt wiederholt durch den Rand einer Plattform gefallen (und teilweise nach einem erstmaligen Stand noch runtergerutscht). Bei einem großen Steinklotz bin ich auch am linken Rand durch das Modell gefallen, obwohl Coco mit der gesamten Schuhlänge auf dem Fels stand. Die Kollisionsbox fühlt sich hier nach wie vor wie ein Notlösung an.


Das wirkt sich leider auch auf die Spielerfahrung aus:
Ich habe gemerkt, dass ich relativ oft knappe Sprünge in den Randbereich mache. Beim jetzigen Stand ist es leider so, dass man mit der Spielweise sehr stark der Willkür der Spielmechanik unterworfen ist, da man zuweilen einfach in den Tod stürzt und das viel zu oft erkennbar am Spiel liegt. Deswegen habe ich dann Level 7 einfach übersprungen, weil ich an manchen Stellen immer wieder in Probleme gelaufen bin.

Ansonsten ist mir zuweilen nicht unbedingt klar, wie das Spiel gespielt werden will. Soll man bestimmte Passagen einem Rutsch durchqueren oder eigentlich ständig stehen bleiben und Abwarten? Sollen die Level bei hohem Skill beim ersten Anlauf durchquerbar sein oder gehört Trial&Error grundlegend zum Design? Nach meinem Empfinden trifft das auf Level 9 mit seinen beweglichen/ bewegten Teilen mit am meisten zu und da hatte ich auch nach diversen Anläufe kein Gespür dafür, was nun eigentlich der richtige Weg sein soll. Gerade im Hinblick auf die eingangs erwähnten Problem war das ein diffuses Erlebnis, bei dem sich nur bedingt ein Lerneffekt einstellt.

P.S.
Die neuen rechteckigen Plattformen finde ich schick. Die zweite Welt sieht auch super aus und wirkt sehr klar, da der eigentliche Gameplay-Bereich hier sehr viel Raum erhält und einfacher zu greifen ist.

 

Da habe ich Moment keine Erklärung. Ich muss mal schauen was ich da unter Physik und Rigidbody eingestellt habe.

Ich bin fleißig am Ausprobieren. Werde es mal mit einer ganz schmalen Kollisionsbox für Coco versuchen. Evtl. lässt sich das besser ausloten.

Die Level habe ich mit Absicht nicht sehr lang gestaltet. Meine Idee war schon, dass der Spieler in jedem Level neu an die Sache angehen soll. Dazu gehört dann auch Trial&Error. Ich bin mir jetzt nicht so ganz so sicher ob das den Spieler auf Dauer eher nervt. Im Vergleich habe ich nur meine beiden Söhne. Bei denen kann es nicht schwer genug sein. Die spielen Level teilweise 50X bis zum Erfolg. Die hält es auch nicht davon ab, wenn es Bugs oder bestimmte (fast) unlösbare Aufgaben oder Gegebenheiten gibt. Natürlich ist das kein Maßstab. Ich bin da nicht so schmerzfrei. Ich spiele die Level natürlich selber x-mal durch und werde dann bei jedem Durchgang irgendwie besser und sicherer. Natürlich nervt es mich auch, wenn ich duch eine Plattform falle. Daher werde ich wohl noch etwas Feintuning benötigen.

 

Hallo,

in meinem Projekt wird es drei verschiedene Spielwelten geben. Die ersten beiden habe ich bereits fertig, jedenfalls was das Szenarium angeht. Jetzt überlege ich, wie die dritte Spielwelt gestaltet werden soll. Dabei schwanke ich zwischen zwei Versionen.

Die erste Idee ist eine Spielwelt, die in der Nacht spielt. Dann hätte man die Möglichkeit schöne Lichteffekte zu erstellen, zum anderen ist der Level dann natürlich recht dunkel. Die andere Idee ist eine Eis- bzw. Schneelandschaft. Die könnte dann allerdings recht langweilig auf Dauer werden. Für beide Versionen habe ich mal einen Screenshoot mitgebracht.

 

Hallo,

ich habe mich jetzt für ein Nachtszenarium entschieden. Das hat mir jetzt persönlich besser gefallen. Schon allein die Lichteffekte und Farben haben mir die Entscheidung leicht gemacht. Somit geht es jetzt an die dritte Spielwelt die Coco meistern muss.

Für einen Einblick in die Spielwelt habe ich ein kleines moderiertes Video eingestellt.

https://www.youtube.com/watch?v=GSmTJ0x_LPY

 

Hallo,

heute habe ich mich mit einem kleinen Intro befasst. Coco muss ja irgendwie auf dem Planeten abstürzen. Daher wird es beim alltäglichen „umherfliegen“ im Weltraum einen kleinen Zwischenfall geben, der dazu führt, dass Coco dann auf Pepaya „notlanden“ muss.

Das kleine Intro wird vor dem Startmenü dann abgespielt. Hier mein erster Entwurf.

https://www.youtube.com/watch?v=LZUIWdAG7Zs

 

Hallo,

ich habe mich doch gegen einen Level bei Nacht entschieden. Das wirkte auf Dauer etwas trist. Daher habe ich für meine dritte Spielwelt eine Wasserlandschaft gewählt. Die helleren und leuchtenden Farben haben mir mehr zugesagt.

Hier ist Coco bei einer seiner letzten Missionen auf Pepaja zu sehen.

 

Hallo Community,

Käpt’n Coco kann jetzt seine Flucht von Pepaja antreten. Es steht eine Vorabversion 0.9.0 zum Download bereit.

Download: Coco Version 0.9.0

https://www.youtube.com/watch?v=Q_cPDcFGtJo

Spielumfang:

- Drei Spielwelten
- Insgesamt 24 Level
- Intro und Extro

Gameplay:

Käpt’n Coco hat im Spiel nur die Möglichkeit zu springen. Er kann dabei zwischen einem einfachen oder einem Doppelsprung wählen. Der Sprung ist aufgeladen. Somit kann der Doppelsprung zeitlich versetzt nach dem ersten Sprung erfolgen. Im Level kann jederzeit neu begonnen werden. Der aktuell erfolgreich absolvierte Level wird jeweils gespeichert.

 

Hallo,

ich habe heute noch ein paar Dinge, die mir zurückgemeldet wurden, eingebaut.

- Fehler bezüglich der Anwahl der Buttons ist behoben
- Im ersten Level habe ich eine kleine Beschreibung für die Sprungmöglichkeiten eingebaut. Sozusagen ein MiniMini-Tutorial.
- Im oberen Bildschirmbereich wird jetzt ein Balken eingeblendet, der mit zunehmendem Level länger wird. Damit kann sich der Spieler dann
orientieren wie viele Level noch vor ihm sind.
- Den Startbildschirm habe ich etwas verändert
- Ein paar „Hängenbleiber“ habe ich noch beseitigt

Download: www.pchobbyspieleschmiede.de/coco/fvp_1.0.0.zip





Damit ist jetzt mein Coco-Spiel fertig. Ich hatte viel Spaß bei der Erstellung und habe wieder eine Menge dazugelernt. Ich hoffe das euch das kleine Spiel gefällt und der eine oder andere es dann auch mal spielt. Rückmeldungen über Fehler etc. werde ich natürlich nachgehen und diese dann einarbeiten. Am Gameplay und dem Spielumfang werde ich aber nichts mehr ändern.