Eben, kommt aufs gleiche heraus, aber es wäre konsequenter
Bis man den Shop erspielt hat, vergeht einem schon teilweise die Lust. Und dann muss man Shop-Items erst kaufen um sie kaufen zu können?
Etwas was ich nicht so sehr mag an dem Spiel. Wenn du mir die Kritik erlaubst.
Es geht um das kaufen von Features - witzige Idee -, aber das Feature Features zu kaufen? Oder Feature Features Features zu kaufen?
Persönlich würde ich stattdessen die Shop-Barriere herausnehmen. Oder zumindest einen Basic Shop machen um die Basic Features billig zu kaufen und den jetzigen Shop als Adv. Shop weiter zu führen.
Klar. Als her damit! Nur so hab ich ne Chance das Spiel zu verbessern. Solange es konstruktiv ist, möchte ichs auch hören
Da ich das Gefühl hab, dass der Shop anfangs eher für Verwirrung sorgt, ist der Punkt mit der Shop-Barriere wohl gar nicht vekehrt (ich denke, du meinst damit, dass man den Shop frei kaufen muss). Dann würden die Leute auch sehen, was sie kaufen können.
Von der Idee, die Basics als Feature zu verkaufen bin ich nach wie vor nicht überzeugt (eben, weil ich befürchte, dass es sich negativ auswirken auf das Spielerlebnis auswirken würde). Zum anderen stehe ich da vor einem weiteren Problem: ich muss mal generell das Hauptmenü + Shops überarbeiten. Schon alleine der Power Up-Store-Button passt ja eigentlich nicht ins Gesamtbild. Und der Feature-Shop an sich ist auch nur deswegen nicht unübersichtlich, weil die Features ja aufeinander basierend sind.
Hab mal wieder mein Grafiktablet angeschlossen und Krita installiert. Dachte mir: vllt kann ich ja auch die ein oder andere Grafik selber malen… Angefangen hab ich mit einer „Krone“.
Das Ergebnis ist dann aber doch seeeehr ernüchternd
Cool. Hab gerade ScriptableObjects in Unity entdeckt. Damit würden sich die Features netter umsetzen lassen. Damit würde ich das Enum los werden. Da in C# enums keine Felder haben können, hab ich mir die Feature-Daten (Preis, Anzeigetext, …) dann über eine Service-Klasse geholt. Das kann ich glaub alles schöner Lösen mithilfe der ScriptableObjects, da ich damit jedes Feature als eigenes Asset ablegen kann:
Wenn der gesamte Grafikstil so wäre könnte das ganz lustig aussehen.
Das gehört zu den schwierigsten Parts beim Programmieren eines Spiels. Klar kann man sich fertige Assets holen, aber die müssen dann alle den gleichen Zeichenstil und Farbpalette haben, sonst sieht das schlecht aus.
Ja, den Stil bekomme ich sicherlich wiederholt hin . Aber ja, ein Mischmasch wäre hier offensichtlich nicht gut. Zum Glück bieten das Asset-Paket bisher ausreichend Grafiken an - die man verwenden kann ^^.
Dachte mir nur, dass ich vllt Icons für die Features selber malen kann, wobei ich da sehr unkreativ bin. Deswegen bleib ich momentan auch erstmal beim Refaktoring.
So - gestern fast den ganzen Abend in Refactoring gesteckt. Das ist ne ganz schöne arbeit und wird mich noch eine Weile beschäftigen. Heute kommt unsre Nichte, weswegen ich nicht wirklich was an der App machen werden kann - aber ich denke eh, dass ich damit noch ein paar Tage beschäftigt sein werde. Hoffe dass ich bis spätestens Montag damit fertig sein werde. Denn ich muss unbedingt mehr Content einbauen, ich starte selber so gut wie kaum noch mein eigenes Spiel. Die Münzen häufen sich, die Runs bringen nix und die Power Ups … ich nutze keins wirklich.
Deswegen drehen sich meine Gedanken gerade darum, was ich als nächstes einbauen kann - das Langzeitmotivation schafft. Dabei denke ich Hauptsächlich an 2 Dinge:
Irgenwas mit Archievements / Freischalten / Skills
Premium-Shop mit höheren Preisen (Kaufbare Sachen: Hintergrundanimation, vllt andere Spielerfarbe, … so Zeug)
Der Premium-Shop würde dann auch das Element “Quests” sinnvoll machen. Wenn man Aufgaben erfüllen muss um Sachen freischalten zu können. Mit den Quests könnte ich dann u.U. auch die normalen Shop Preise anheben.
Auf jeden Fall merke ich gerade: ein Spiel mit Wiederspielwert zu erschaffen ist alles andere als einfach ^^.
Ich befürchte das genau die Dinger es brutal in sich haben werden. Die Figur “einzufärben” dürfte noch relativ einfach gehen. Noch keine Ahnung ob ich das programmatisch dann über Unity mache oder die Sprites bearbeite.
Was mich halt sehr stark eingrenzen wird ist, dass ich kein Designer/2d-Artist bin. Ich muss mit dem arbeiten was ich hab. Das maximale was ich vermutlich machen kann, sind halt Anpassungen.
Durchaus möglich, da es der einzige Endless-runner ist, welchen ich wirklich oft und lange gespielt hab. Und ich mich deshalb sicher von inspirieren lasse (wobei ichs nicht auf einen Klon abgesehen hab - zumal ich das überhaupt nicht hinbekommen würde ^^).
Hehe ja hab da auch viel gespielt
Wollte auch nicht ausdrücken, dass es ein Klon ist. Sind dann doch ein paar Unterschiede.
Kam nur drauf, weil ich mir so als Feature/Modus gedacht hatte: Überkopf also dass alles umgedreht ist bzw man switchen kann. Und dann fiel mir der Anzug aus Jetpack Joyride ein
^^ Das wäre i.d.T mal ein ausgefallener Modus (der schon jetzt funktioniert: einfach smartphone umdrehen xD).
Aber da Jetpack Joyride so vieles richtig gemacht hat und ich etliche Stunden damit verbracht hab ist es sicherlich halt kein Vorbild . Wobei es halt wirklich darum geht zu verstehen, wie die Kernkonzepte funktionieren und das auf mein eigenes Spiel anwenden (möglichst in einer eigenen Form).
Und was Jetpack Joyride auch imho sehr gut umgesetzt hat ist das F2P-Konzept. Man kam an die Sachen ran OHNE den Drang zu haben Geld ausgeben zu müssen (auch wenn mans kann).
Hier ein exemplarisches Beispiel wie es vorher war und wie es nun ist/wird. Vor dem Refactoring waren die Manager überall im Lande bekannt. Die Spawner kannten sie, die Controller kannten sie und die Manager kannten sich auch untereinander. Das Schaubild zeigt schon in dem kleinen Fall recht deutlich, wie die Abhängigkeiten da natürlich immerzu gewachsen sind. Da die Manager ja alle einen Zustand haben, haben diese auch etliche Felder. Und genau wurde eine Sache, die ich an C# mag - vom Segen zum Fluch. Ich brauchte Felder, ich bruachte Properties, ich brauchte delegates und ich brauchte Events. Und alles war in den Managern drin. Das machte den Code sehr unleserlich und auf Dauer auch schwer zu verstehen. Für die die es nicht kennen, hier mal einen Auszug aus meinem gerade wachsendem UiModel:
public class UiModel : MonoBehaviour {
[SerializeField] private bool _showHighscoreButton;
[SerializeField] private bool _showPowerUps;
public delegate void ValueChangedHandler<in T>(UiModel model, T show);
public event ValueChangedHandler<bool> ShowHighscoreChanged;
public event ValueChangedHandler<bool> ShowPowerUpsChanged;
public bool ShowHighscoreButton {
get { return _showHighscoreButton; }
set {
_showHighscoreButton = value;
if (ShowHighscoreChanged != null)
ShowHighscoreChanged(this, _showHighscoreButton);
}
}
public bool ShowPowerUps {
get { return _showPowerUps; }
set {
_showPowerUps = value;
if (ShowPowerUpsChanged != null)
ShowPowerUpsChanged(this, _showPowerUps);
}
}
}
Wie ihr seht, für 2 Felder die Events bei einer Änderung feuern ist das doch viel Code. Nachdem ich mich etwas mit den GameDevs aus unsrer Firma und EagleEye unterhalten hab, dachte ich mal darüber nach - wie und ob man MVVM hier reinbekommen kann. Daraufhin hab ich etwas umgebaut und gehofft, dass alles so funktioniert wie ich es mir ausgemalt habe. Und ich muss sagen: es tut! Ich bin begeistert davon, wieviel besser der Code geworden ist. Ich bekomme immer mehr Abhängigkeiten zu den Managern raus. Wenn ich damit fertig bin, dann werden die sich (hoffentlich) nur noch um die Datenverarbeitung kümmern müssen. Und die Änderungen bekommen sie einfach durch Events mit! D.h. anstelle von GameManager#StartGame(); setze ich einfach im GameModel die ensprechende Property auf true und alle Manager die es interessiert bekommen es mit. Im groben passiert dann das:
Der GameManager macht das generelle Setup (Punkte/Distanz auf null, Task starten zum erhöhen der Levelgeschwindigkeit, …)
Der Spawnmanager aktiviert seine Spawner
Der Ui-Manager blendet das Hauptmenü aus (und ggf. die Popups ein)
Zuvor mussten diese Manager sich alle kennen - nun weiß keiner mehr vom anderen Bescheid. Ist ein Spiel fertig, dann werden die Änderungen in die Models geschrieben. Woraufhin wieder andere Manager aktiv werden. Der HighscoreManager reagiert z.B. auf das ende vom Spiel und schaut sich das Ergebnis an. Schreibt neue Highscores in das HighscoreModel - woraufhin der PersistenceManager aktiv wird, der dafür sorgt, dass die Highscore auch in die entsprechende Datei geschrieben wird.
Der neue Code der dabei entsteht ist einfach jetzt schon um soooo vieles angenehmer als der alte!
Ach und noch eine Ergänzung zu dem: Wie es dazu kam. Ich dachte schlichtweg nicht, dass ich mehr als 1 oder 2 Manager haben würde. Als ich das Projekt gestartet hatte, rechnete ich nur mit einem GameManager und einem UiManager. Letztendlich halt eine Sache die man spätestens dann lernt, wenn man einfach mal blind und naiv ein Projekt startet ^^
Derzeit arbeite ich an einem neuen Level-Spawner. Im Gegensatz zu dem jetzigen erlaubt dieser dann das nutzen von Vorlagen. Somit kann ich mit einfachen Bild-Dateien Strukturen vorgeben die dann als Level übersetzt werden. Eine Vorschau kann ich euch auch schon zeigen:
Wie ihr seht wurde daraus der erste Teil des levels erstellt. Um es interessant zu halten möchte ich einfache Mapteile anbieten und je länger das Spiel läuft, desto schwerere können hinzu kommen .
Ich bin gerade dran den Controller für die Inputs (zum Bewegen der Spielfigur) neu zu schreiben. Der bisherige Controller hat die Sprunghöhe limitiert, indem er ab einer gewissen y-position die Geschwindigkeit stark gedrosselt hat. Was natürlich kacke ist, wenn das Level-design jetzt auch an Höhe gewinnt. Der neue Controller ermöglicht mir aber jetzt das Feature 2xJump umzudefinieren. Anstatt 2x so hoch springen zu können, wird es wohl einfach ein zusätzliches Springen in der Luft erlauben. Aber seht selbst:
Gerade eben mein erstes Performance Problem gefunden und gelöst .
Das verwenden der neuen Map-teile ist wohl etwas rechenintensiver als erwartet. Aufm Smartphone hat es auch Stellenweise Lags gehabt und das Gerät wurde auch ziemlich warm. Mein erster Schritt war es asynchron laden zu lassen. Hat so im ganzen nichts gebracht - aber die Idee war wohl gut. Denn jetzt lade ich es „Spaltenweise“ nach jedem so genannten FixedUpdate. Und siehe da - es läuft wieder alles Rund freu
Ok. Ich glaube ich bin kurz davor wieder ein Update bereit stellen zu können. Hier seht ihr, den aktuellsten Stand:
Ich hab die ganzen Level-Elemente verkleinert, sodass ich mehr “Units” (vgl. mit Pixeln) hab um Maps zu bauen. Jedes Element ist jetzt nur noch halb so groß (1x1) anstatt wie vorher (2x2).
Die Levels werden also in Zukunft interessanter und anspruchsvoller sein! Das schöne ist, dass man Levels sehr einfach anpassen kann. Denn wie schon oben gezeigt, handelt es sich einfach nur um Bild-dateien. Durch die kleineren Elemente kann man dann auch (imho?) coole Sachen wie das hier machen:
Das update werde ich jetzt erstmal bis morgen auf meinem eigenen Smartphone testen. Wenn ich keine Bugs finde, Dann wird es morgen einen Release geben =).
. Wobei es halt wirklich darum geht zu verstehen, wie die Kernkonzepte funktionieren und das auf mein eigenes Spiel anwenden (möglichst in einer eigenen Form).
