Und so schaut es aus:
2 „Gefällt mir“
So. Hier mal ein paar Updates zum Spiel. Das letzte was ich euch vorgestellt hatte, waren die Animationen beim platzieren der Türme. Die selbe Animation spiele ich dann auch beim verkaufen wieder ab - nur halt rückwärts. Bietet sich an, denn ich hab nicht vor den Shader zu wechseln oder komplizierter zu machen.
Aus meinem Bekanntenkreis kam der Hinweis, dass die Kugeln kacke sind und etwas in Richtung „Laser“ besser wäre. Die Idee fand ich gut und außerdem wäre ein Laser aus Sicht der Performance sicher besser - da weniger komplex. Anfangs war mir nicht klar, wie ich das mache - aber dann hab ich die Line-Render-Komponente entdeckt. Vereinfacht erklärt: damit kann ich ein Polygon zeichnen. Gefreut hab ich mich darüber, dass ich die Anzahl der Vertecies der Enden und Ecken anpassen kann. Den damit hab ich den Schuss abgerundet bekommen.
Desweiteren hab ich noch einen Bug gefixt. Die Türme haben Ihre Liste an Minions nicht richtig aktualisiert. Dadurch war an erster Stelle in Minion der nicht mehr existiert - dementsprechend hat der Turm nie wieder gefeuert. Wird mit dem kommenden Update behoben werden.
Damit hab ich auch nur noch einen offenen Punkt auf meiner Liste:
- Türme sollen sich langsamer drehen.
Ist auch ein Feedback gewesen um das ich mich kümmern möchte. Stellenweise ist das doch sehr Ruckartig. Außerdem muss ich da auch implementieren, dass Türme erst feuern, wenn ausgerichtet. Gerade beim Laser schaut der erste Schuss sehr seltsam aus.
Ich hätte gerne ein Video angehängt - aber mein Aufnahme-Programm erkennt die Monitore nicht mehr, was das Aufzeichnen schwer macht. Aber da ich hoffentlich spätestens bis Ende der Woche eine neue Version veröffentliche, kann ich eigentlich euch auch selber die Änderungen entdecken lassen 
.
Oh mann. Hab endlich mein OBS-Problem gelöst, dank diesem YT-Video hier:
Hatte letzten Monat mal eine Occulus Rift ausprobiert und dafür auch meine NVIDIA-Settings angepasst gehabt. Nachdem ich dort OBS explizit intern laufen lasse funktioniert alles wieder wie gewohnt (yay … hip hip).
Abgesehen davon bereite ich gerade das nächste Release vor 
:
- Fix: Turm schießt erst nach Anvisierung
- Bugfix: Türme hatten Gegner nicht mehr anvisiert
- Bugfix: Lebenspunkte von Minions werden nun korrekt mit jedem Level erhöht
- Radius von Türmen ist besser zu erkennen
- Lebensbalken für Minions
- Turm schießt nun laser anstatt Kugeln
- Animation: Nach töten von Minions
- Animation: Bei Platzierung von Türmen
- Animation: Nach Verkauf von Türmen
Und laut Play-Store Benachrichtigung ist das Update nun online 
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:
- Ich hatte am WE nicht viel Zeit
- 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:
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:
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:
Das wars für heute. Es geht dann damit weiter, dass ich eine Ansicht für das Changelog baue
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 .
Die ist ja in Stuttgart 
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 
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 .
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 .
Das Release ist getestet und hatte noch ein paar Kleinigkeiten zu machen. Aber jetzt ist es durch und eingereicht . 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 .
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 
).
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 .
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 ( Getting Started with ECS in Unity 2019 - YouTube ). 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 
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: Some of the best optimization tips for Unity UI - Unity