Tagebuch: Tower Defense

Ich kann ja mal einen Ausblick auf v0.5 geben. Geplant ist ein Hauptmenü einzuführen mit erstmal den folgenden Funktionen:

  • Spiel starten
  • Laufendes Spiel beenden
  • Changelog einsehen

Daneben hab ich noch einen weiteren wichtigen Punkt:

  • 64bit support
  • AppBundle-Builds für kleinere apk-größe (solls zuminest mal bewirken [glaub ich])

Denn momentan ist die App nur 32bit fähig und der Play-Store wird das auch nicht mehr all zu lange mitmachen.

So. Schon eine ganze Zeit her, dass ich hier was geschrieben hab. Hatte mitunter zwei Gründe:

  1. Ich hatte am WE nicht viel Zeit
  2. Ich hatte mal wieder meinen 3D-Kurs weiter gemacht und wollte erstmal die Lektion abschließen.

Allerdings kommt Punkt 2 meinem Spiel zu gute. Also hab ich im Prinzip meine Zeit einfach mit lernen verbracht.

Heute hat es mich aber mal wieder gereizt etwas umzusetzen und hab mehr erreicht als gedacht. Eigentlich war mein Tagesziel das Hauptmenü soweit im groben fertig zu bekommen. Das hab ich auch, inkl. tests. Den Spiel-Starten-Button hatte ich ja, nur war der bisher ohne test. Das hab ich geändert.

Außerdem hab ich jetzt ein nettes Navigationssystem drin. Das managt im wesentlichen welches Panel wann angezeigt wird. Im wesentlichen funktioniert es recht einfach. Es gibt ein NavigationsEvent. Das nimmt entgegen, welches Panel ich anzeigen möchte und eine Router-Componente schaltet dann das entsprechende Panel aktiv und alle anderen als inaktiv (ist auch getestet). Schaut dann so aus:

image

Das ganze lässt sich sehr einfach erweitern und dürfte flexibel genug sein um alle meine Use-cases abzudecken. Das Target ist btw ein enum - wo ich direkt an den Thread denken musste:

Aber da ich hier eine endliche Anzahl erwarte und der Inspector mir eine schöne Dropdown-Ansicht ermöglicht, hielt ich es für eine gute Idee:

namespace Game.Ui {
    
    [Serializable]
    public enum NavItem {
        MainMenu = 0,
        ChangelogPanel = 1
    }
}

Allerdings mit festen Konstanten. Ich weiß nicht mehr genau welche Probleme ich damals mit Feature Runner hatte, aber ich meine das es sinnvoll war dem enum Werte zuzuweisen. Ich glaube es war wegen dem löschen. Angenommen ich lösche “MainMenu”, dann würde “ChangelogPanel” den Wert 0 bekommen, was ja nicht mehr stimmt.

Zu guter letzt hab ich jetzt noch die Changelogs im Spiel als Scriptable-objects hinterlegt:

image

Zum Glück hab ich ja alles in Hack’n’plan hinterlegt, sodass es relativ einfach war an die Infos zu den Änderungen zu kommen. Und pflegen kann ich das dann im Unity-Inspector:

image

Das wars für heute. Es geht dann damit weiter, dass ich eine Ansicht für das Changelog baue :slight_smile:

Hab die letzten Tage immer mal wieder was machen können und heute sogar recht viel. Die Ansicht für das Changelog ist nun komplett fertig und geht (hoffentlich) das letzte mal in die Testphase.

Schön war vor allem der Moment, als ich Komponenten wiederverwenden konnte. Somit konnte ich den Zurück-Button komplett ohne eine Zeile Code einbauen und auch direkt als Prefab ablegen. Denn für andere Panels kann ich den noch super gebrauchen.

Viel werde ich heute dann auch nicht mehr machen (vermutlich nur das mergen der Sachen von Feature-Branch -> 0.5-Branch).

Morgen werde ich vermutlich gar nix machen können, weil da sind wir auf der ComiCon. Aber am Sonntag komm ich vllt dann noch zu was :slight_smile:.

Die ist ja in Stuttgart :fearful: Alle bekannten Messen sind doch immer irgendwo in Norddeutschland. Wahnsinn. Wollte immer auf die CeBit, aber Hannover war mir dann doch zu krass, und jetzt gibt es die nicht mehr. Dann halt auf die ComiCon :sweat_smile:

Warum schockiert? Ich nehme an, weil du dein Glück kaum fassen kannst, da hinzu kommen, weil du in der nähe wohnst? Also ich finds gut, dass die hier ist. Karlsruhe wäre mir zwar lieber (A8 ist kacke) - aber immerhin sinds nur 45-60min fahrt von uns aus.

War auf jeden Fall mal wieder echt cool gewesen. Zwar viele Menschen, aber das ist wohl unausweichlich ^^.

Ich finde zwar gerade etwas wenig Zeit für das Projekt - aber tot ist es definitiv nicht. In der letzten Woche hab ich die Darstellung des Changelogs fertig gestellt und bin mittlerweile am Settings-Panel.

Auch dort war ich doch schon relativ fleißig. Ich hab die Persistierung der Einstellung schon drin und ein EditorWindow für Unity geschrieben (damit ich auch von dort die Einstellung manipulieren kann).

Was jetzt noch fehlt ist halt das UI und auch, dass die Einstellungen angewandt werden. Hier hab ich aber noch ein bisschen Schiss vor crashes. Deswegen überlege ich, ob ich die Einstellungen erst bei Spielstart anwende. So hätte der Spieler bei einem Crash die Chance Einstellungen bei einem Neustart zu ändern.
Ich hatte diesbezüglich auch etwas gegoogelt ob ich mitbekommen kann, ob meine App gecrasht ist oder nicht. Leider hab ich dazu nicht wirklich was gefunden. Weil eigentlich wollte ich in dem Fall die Einstellungen beim nächsten Start zur Sicherheit resetten.

Also Ihr seht: auch wenn die Geschwindigkeit momentan etwas gedrosselt ist - die Entwicklung geht trotzdem weiter voran. Und vielleicht kann ich bis Ende der Woche ein neues Release raushauen :slight_smile:.

Ok, also ein Release wird es heute wohl doch nicht mehr geben. Ich sehe zu, dass ich das mit den Einstellungen vllt heute fertig bekomme - auch wenn ich es vermutlich nicht aktiv haben werde im Release.

Warum? Nun ja - ich kann keinen Unterschied im Spiel festmachen, wenn man zwischen low und heigh einstellungen wechselt. Von daher gesehen, wäre es lediglich ein Risiko. Dennoch will ich es fertig implementieren, denn vielleicht kann ich es ja doch irgendwann mal gebrauchen. Und da wäre es blöd, wenn ich den existierenden Code weg werfen würde.

Abgesehen davon hab ich noch einen Bug offen, der es erlaubt, dass Spieler für den selben Minion mehrfach belohnt werden. Und den möchte ich auch gern im nächsten Release mit drin haben. Wobei - vllt auch nicht - ich weiß noch nicht.

So. Den Bug konnte ich heute tatsächlich auch noch fixen (hätte ich nicht gedacht, war aber dann doch relativ einfach).

Allerdings komme ich heute abend nicht mehr zum testen. Das sollte ich aber unter der Woche bewerkstelligen können. Wenn dabei nichts größeres mehr auftaucht, dann sollte ich ohne Probleme die nächste Woche Version 0.5 releasen können :slight_smile:.

Das Release ist getestet und hatte noch ein paar Kleinigkeiten zu machen. Aber jetzt ist es durch und eingereicht :slight_smile:. Dementsprechend sollte das Update auch bald bereit stehen.

Die Release-notes:

+ New: 64bit-support
+ New: Hauptmenü 
+ New: Changelog Panel
+ Fix: Spieler bekam mehrfach die Belohnung für getötete Minions

Was vor allem wichtig für das Release war, war der 64bit support. Denn (wie glaub schon erwähnt) wird der bald vom PlayStore voraus gesetzt. Deshalb hab ich beim veröffentlichen der letzten Versionen auch immer einen Warnhinweis angezeigt bekommen. Heute hatte die PlayStore-Console aber zum Glück nichts zu meckern :slight_smile:.

Da ich die letzten Tage (und noch immer) in Fuerteventura bin, hab ich natürlich nicht am Spiel weiterentwickelt. Dennoch konnte ichs nicht lassen hin und wieder ans Programmieren zu denken. Und da ich auch das ein oder andere Mobile-Game installiert habe, kam dann auch so einfaches Interesse an manchen UI-Komponenten auf. Und ich war mir sicher: ich könnte das relativ einfach nachbauen - auch wenn ich nicht weiß wofür.

Und irgendwann hab ich mich dann doch mal an den Laptop gesetzt (hin und wieder hat man doch mal Zeit aufm Zimmer für sowas, z.B. wenn man drauf wartet - dass man bald los kann um zum Essen zu gehen :stuck_out_tongue:).

Was ich hier umgesetzt hab war ein Button, der auch zugleich einen Fortschritt anzeigen kann. Im Gegensatz zum “Original” skaliert mein Button aber nicht beim druck, sondern schaut so aus, als ob er nach unten gedrückt wird. War letztendlich auch tatsächlich sehr einfach:

Unity hat irgendwas am Handling von Prefabs geändert und jetzt sterben einfach 32 von 70 tests! Und die einzige Meldung die ich bekomme ist “Not a Prefab scene.” Das hilft mir aber nicht wirklich weiter. Kann doch wohl nicht wahr sein -.-

Ok, ich konnte es lösen - dank diesem Thema hier:

https://answers.unity.com/questions/1643631/annoying-error-in-console-not-a-prefab-scene.html

Der TO ist zwar ein ****** (seid kreativ) dafür, dass er die Antwort nicht gepostet hat - aber in den Kommentaren hat jemand anderes geantwortet. Ein Neustart von Unity3D hat tatsächlich geholfen!

Bin nämlich gerade “fertig” mit der Ansicht von Statistiken und wie man diese speichert.

Hab heute mal wieder etwas weiter gemacht. Ab sofort werden Statistiken zum Spiel erfasst, die man sich auch im Hauptmenü ansehen kann:

Dabei hat sich auch die Stärke meiner Architektur gezeigt. Dadurch, dass meine wichtigsten Events in Form von Assets vorliegen, konnte ich mich super einfach daran registrieren. Andere Komponenten mussten nichts davon wissen.

Das kommt mir natürlich sehr gelegen, denn ich möchte im späteren Verlauf auch noch gerne Quests ins Spiel einbauen. Und dafür wäre es schon praktisch, gut und einfach an meine Daten zu kommen :slight_smile:.

Bin gerade zufällig auf ECS gestoßen. Eine neue Art und Weise wie man wohl zukünftig mit Unity programmiert. Das in Kombination mit dem neuen Burst-Compiler scheint schon ziemlich cool zu sein.

Gerade ein Video dazu angesehen ( https://www.youtube.com/watch?v=ILfUuBLfzGI ). Da wird ziemlich schön demonstriert, was das kann. Was mich am meisten fasziniert hat war der Burst-Compiler. Wo der CPU-main-thread vorher 50ms gebraucht hat, braucht er nach dem Burst-Compiler nur noch 3!

Da scheint einiges möglich zu sein mit dem neuen System - leider find ich nur sehr wenig Dokumentation darüber. Denn eigentlich würde ichs mir gerne ansehen :frowning:

Ok. Das ganze ist noch nicht final und wenn dann würde man es wohl als hybrid Technologie einsetzen.

Wie 100% Pure ESC ausschaut kann ich mir auch noch nicht vorstellen, denn da würde man komplett auf die GameObjects verzichten. Was bedeutet, das eigentlich Recht viel von Unity3Ds WYSIWYG Editoren “nutzlos” macht. Denn bei Pure ESC würde man (derzeit) alles programmatisch machen

ECS war gestern ja eine ziemliche Sackgasse. Aber heute habe ich mich mal aus interesse etwas schlauer gemacht was Canvas angeht.

Bisher hatte ich für meine komplette UI ein Canvas verwendet. Hat mir zwar keine Probleme bereitet, war aber dumm. Denn wenn eine Sache auf dem Canvas “dirty” ist, dann ist wohl das ganze Canvas dirty. Bedeutet: haufenweise Zeug wird neu gezeichnet, was nicht neu gezeichnet werden müsste!

Außerdem hab ich ein paar nützliche Tipps zu weiteren Optimierungen bekommen. Wie z.B. darauf zu achten, dass nicht jedes Element Ziel von einem Raycast sein muss (was default ist und deswegen schnell mal untergeht).

Für mehr Details zu dem ganzen empfehle ich einfach meine Quelle zu lesen: https://unity3d.com/de/how-to/unity-ui-optimization-tips :slight_smile:

okay - muss ich mir heute Abend mal durchlesen - bei mir funktioniert Unity gerade gar nicht (https://issuetracker.unity3d.com/issues/srp-causes-crashes-100-percent-when-running-with-graphics-jobs-enabled?_ga=2.165194431.1005041556.1565168537-1615053437.1559744828) und zurück auf 2019.1 geht nicht mehr

danke für den Tipp-Link

Oha. Totalausfall von Unity ist natürlich unschön fürs Projekt. Da drück ich mal die Daumen, dass der Fix schnell kommt.

Ansonsten: gern geschehen. Hab eben mein Refactoring ziemlich zum Abschluss gebracht. Anstelle von einem Canvas hab ich jetzt einige mehr und konnte gleichzeitig ein paar Sachen vereinfachen … und vermutlich auch direkt mal 2 Bugs lösen :slight_smile:

Ich merke gerade - ich hab einen Fehler gemacht bei meinen SVGs (aber ich glaub, keinen schlimmen).

Und zwar hätte ich die Farbe noch nicht festlegen dürfen! Dadurch, dass ich das Grün vorgegeben hab, kann ich die jetzt nicht mehr einfärben:

Siehe GIVE UP-Button. Wenn ich den nun rot einfärben möchte, dann schaut das so aus:

Das hab ich auch gemerkt, als ich im Urlaub die eine Komponente entwickelt hab. Mit weiß- und grautönen zu spielen ist definitiv sinnvoller. Natürlich könnte man auch verschiedene Grafiken bereit stellen - aber ich würde doch schon die färbe-technik vorziehen. Damit ist man definitiv flexibler und kann auch mal eben schnell eine neue Variante erstellen.

Des weiteren macht mir auch mein Kontextmenü Probleme. Weswegen ich es gerne neu schreiben möchte. Bei der Gelegenheit will ich auch versuchen etwas umzusetzen, was mir besser gefällt. Das momentane sieht eher so nach “quick’n’dirty” aus.

Eine Vorstellung vom Türme-Kauf-Menü hab ich zumindest schon mal:


(Nicht verwirren lassen, 2 der 3 Türme sollen Platzhalter sein, damit man sieht, wie es mit mehr Türmen ausschauen könnte).

Für das Upgrade-Menü überlege ich, ob ich es hinbekomme das in der nähe von Türme anzeigen zu lassen. Da werde ich vielleicht mal etwas rumprobieren müssen.