Ich glaube ich werde jetzt erstmal wirklich weiter den Code aufräumen und separieren. Ein Problem was ich hab ist, dass die Präsentation führend ist und nicht die Logik. Sieht man auch schon daran, dass die Logik für die Map 3D-Vektoren entgegen nimmt obwohl im 2D-Bereich gearbeitet wird.
Bin noch immer am Aufräumen dran. Und hab gerade rausgefunden, wie ich meinen Serializer dazu bringen kann, die Typ-Information mit zu hinterlegen. Was praktisch ist - denn nun kann ich für Straße & Co wirklich eigene Objekte haben und nicht einen einzigen generischen Typ.
Ich bin mit dem Serializer immer auf die Fresse geflogen (NET1.1) und mache seit dem die Speicherung immer manuell. Das Problem damals war das er die aktuelle Version der Assembly mit gespeichert hat. Da die letzte Stelle an den Tag geknüpft ist (bzw. war), war es natürlich toll das das Einlesen am nächsten Tag nicht mehr funktioniert hatte.
Wie das jetzt mit 2.0++ ist weis ich ehrlich nicht.
Kann ich nicht bestätigen - ich nutzer aber auch eine externe lib dafür ( Json.NET - Newtonsoft ). Die kann ich auch direkt über den Unity-Asset-Store beziehen und bietet mir dann noch ein paar extras an für Unity-Klassen (z.B. Vector3).
Soweit scheint das auch wunderbar zu funktionieren (speichere das ganze im bson-Format + kleine encrypten). Solltest du noch was mit C# zu tun haben, dann kann ich dir die lib empfehlen.
Mal abgesehen von der Lib hab ich heute echt gute Fortschritte gemacht. Es gibt einige mehr tests und ich glaub ich hab auch kleine Effizienz rausgehauen. Wo ich früher immer alle x-Frames die Texte geupdated hab, passiert das nun Event-gesteuert.
Das ich da (wieder) drauf gekommen bin kam dadurch, dass ich Model- & Service-Klassen in einer eigenen Assembly hab. Und in der Assembly möchte ich möglichst wenig von Unity verwenden.
Muss das ganze jetzt mal bei Zeit bauen und auf mein Smarpthone installieren. Nur weil es im Editor läuft muss es noch lange nicht auf einem Androiden laufen ^^. Aber nicht mehr heute. Bin glücklich genug über meinen Erfolg und wills mir nicht kaputt machen 
.
Bin ich zu perfektionistisch veranlagt? Irgendwie nervt mich gerade - dass ich mich auf die Datenspeicherung so konzentriert hab + die Services. Warum erschien mir überhaupt das Speichern am Anfang als so wichtig…
Ich lasse mich davon glaub zu sehr ablenken. Irgendwie bezweifle ich, dass das Zielführend ist (auch wenn ich es von anderen Projekten so gewohnt bin) :-/
Oder ich definiere das ganze noch immer als Prototyp und nutze das wissen das ich hab - um es HOFFENTLICH ENDLICH richtig zu machen.
Da ich heute noch nicht wirklich viel gegessen hab und auf mich gleich ein halbes Hähnchen wartet - werde ich mit meiner Entscheidung bis danach warten.
Aber momentan hätte ich gute Lust den Master-Branch in Prototyp umzubennen und nochmal von einem relativ frühen Stadium abzubranchen. Weil es gäbe durchaus so einige Sachen die ich schon jetzt anders machen würde.
Hab mich im übrigen zu dem Schritt entschlossen und glaube es war auch gut so. Denn ich glaube TDD hat mich zu einigen falschen Entscheidungen verleitet.
Damit will ich nicht sagen, dass TDD was schlechtes wäre - nein. Es ist eine super Sache und ich bleibe auch dabei. Nur wenn man nicht wirklich weiß, wie man seine Sachen am besten testet, dann wirds wohl gefährlich. Ich glaub, damit hab ich einige Sachen unnötig kompliziert gebaut, einfach nur, weil ich nicht wusste wie ich es sonst hätte testen sollen.
Jetzt wo ich es besser weiß (geh ich einfach mal von aus) - da schaut das alles schon etwas anders aus. Zumal ich jetzt eine Absicherung hab, die ich mir schon des öfteren gewünscht hatte: ich teste meine Prefabs!
Wollen wir hoffen, dass das jetzt der letzte Restart von Industry City war .
Und wooohoo. Ich nutze gerade das erste mal die neuen Prefab-Variants. Somit hab ich ein Gebäude-Prefab, welches mir alles vordefiniert das jedes Gebäude haben sollte. Dann kann ich darauf basierend neue Prefabs erstlelen die spezifischer sind. Und das schöne: die sind nach wie vor miteinander verlinkt. Ändere ich was am Parent, dann bekommen das die anderen entsprechend mit 
.
Was hinzu kommt: Genau hier hat es sich ausgezahlt, die Prefab-Tests zu haben. Denn ich musste meine bisherigen alle löschen und neu anlegen. Nun sind alle Tests grün hurray
Und ich war gleich mehrfach blöd. Die Animation (welche selectierte Gebäude bewegt hat) - hatte ich hardcodiert. Warum auch immer entschied ich mich dagegen die Animationen von Unity zu nutzen. In der neuen Version nutze ich diese.
Vorteile sollten klar sein aber dennoch:
- Ich musste keinen Code schreiben
- Die Animation war ruck-zuck da
- Die Animation ist sehr einfach anzupassen
- Ich kann die Animation erweitern
Gerade der letzte Punkt: es war sehr einfach eine “fallen”-Animation hinzuzufügen. Hat keine 2min gedauert.
Also ich muss sagen: ich komm gerade richtig schnell voran. Hab jetzt in der kurzen Zeit 48 tests und alles soweit, dass ich Gebäude ersetzen kann. Nur halt alles mit schöneren Animationen und meine Projekt-Struktur gefällt mir auch viel besser.
Und bisher hab ich auch glaub ganz gut umgesetzt, dass ich in Komponenten denke. Was eigentlich ganz cool ist. Z.B. das hier:
Im Prototyp hatte ich auch so ein “City”-Objekt. Das hatte nur eine Komponente “CityManager” die entsprechend alles versucht hat zu managen. CityManager wurde dann aber auch z.T. von GameManager gesteuert.
Anstatt aber jetzt eine Manager-Klasse zu haben - die dann wieder auf verschiedene Service-Klassen versucht zurückzugreifen, versuche ich es nun alles direkt in Komponenten aufzubrechen. Wie oben zu sehen. Die haben auch EINE definierte Aufgabe und das wars dann.
Und bis jetzt hab ich auch wirklich für JEDE Komponente sinnvolle IntegrationsTests! Etwas, was mit meinen vorherigem Klassenkonzept nicht möglich gewesen ist (ich wollte es gerne und hatte deswegen auch extra Tasks im Kanban-Board angelegt … aber nun ja, es war mir nicht möglich ^^).
Und das ganze betrifft mittlerweile 10 einzelne Komponenten. Gut zu sehen hier:
Alles was auf It endet testet entsprechend eine Prefab.
Eben hab ich einen nervigen Bug gefixt. Nämlich das Gebäude nach einem Kauf/Verkauf nicht mehr animiert wurden. Das blöde: Im Editor hat es funktioniert, auf dem Handy nicht und Rider versteht sich grad mit ADB nicht - weswegen ein debuggen nicht möglich war …
Problemlösung war, dass ich die Animation besser erst einen Frame später trigger. Dann funktioniert es.
Und somit hab ich zugleich auch meinen ersten Test geschrieben, der einen gefixten Bug aus meinem Spiel fern halten soll .
Und wieder ein Stück weiter, denn jetzt kann man Gebäude nur noch kaufen, wenn man auch Geld hat. Das Header-Layout konnte ich einfach aus dem Prototyp-branch holen. Das hat mir den UI-Aufbau erspart . Die Logik aber hab ich komplett neu geschrieben.
Den Vorteil davon werde ich auch nicht müde zu betonen: Ich hab alles mit Tests abgedeckt - vor allem mit Integrationstests.
Das Szenario von kaufen und verkaufen ist komplett abgedeckt und das find ich gerade UNGLAUBLICH COOL. Sollte hier irgendetwas brechen, dann bekomme das sofort mit .
Hab hier schon lange nix mehr geschrieben. Aber momentan war es halt einfach eher, dass ich den veröffentlichten Stand einholen musste - da gibt es halt nichts wirklcih tolles mehr zu berichten.
Bin jetzt aber mittlerweile soweit und mache an dem Punkt weiter, an dem ich aufgehört hatte: das Konfig-Panel.
Dafür musste ich mir einiges an Gedanken machen - wie das Spiel überhaupt funktionieren soll. Was stellt man ein - was nicht? Ich hatte mich anfangs ziemilch auf die Lieferkette versteift. Aber das würde sehr schnell sehr langweilig werden. Und für ein Tycoon will man eigentlich auch durchaus etwas managen können.
Deswegen gehe ich mal weg von Routenplanung und gehe eher zu einem Mechanismus wie es Anno macht - oder noch einfacher AOE. Also entweder holen sich die Gebäude einfach von den Proudktionsgebäuden die Rohstoffe oder sie landen in einem globalen speicher wo man sich die Rohstoffe rausholen kann.
Ich denke mit Fokus auf einfache Parametersteuerungen kann man das Spiel viel abwechslungsreicher und interessanter gestallten. Dabei denke ich an so einfache Gegenübersellungsparameter wie z.B:
Qualität der Rohstoffe <—> Einkaufspreis
Und damit hätte ich dann auch Stellparameter mit denen ich Einfluss auf das Spiel nehmen könnte. So könnten bei einem einfachen Spiel die Preise/Qualitätslevel günstiger sein als in einem schweren Spiel.
Hab heute auch mal wieder spaßeshalber mit 3D-Modellierung rumgespielt und dabei kam das hier raus:
Und zwar schön inkl. 2 Animation (öffnen und schließen). War eigentlich auch relativ flott damit .
Spiele gerade damit einen State ins Spiel einzubauen. Und das was ich mal experimentel reingehauen hab find ich auch recht überzeugend.
Einfaches Beispiel:
Ich selektiere ein Gebäude indem ich einen Raycast von der Kamera in Richtung klick sende. Treffe ich auf ein Gebäude, dann wird dieses als “Aktuelles Gebäude” ausgewählt. Nun gibt es Situationen, in denen ich dieses Verhalten nicht haben möchte. Z.b wenn ein Popup geöffnet wurde oder ein Dialog. Denn dann könnte der Benutzer ausversehen durch einen Klick auf (z.B.) einen Button ein anderes Gebäude auswählen.
Dementsprechend darf die Komponente fürs Selektieren nur in bestimmten Zuständen vom Spiel aktiv sein.
Bisher war das so gelöst, dass ich auf verschiedene Events (in der Szene) reagiere und die Komponente entsprechend de-/aktiviere.
Ich muss damit aber immer sicher gehen, dass ich wirklich alle Events überall registriert habe. Und das war nur ein Beispiel von derzeit mind. 2 (und das Spiel ist am Anfang. Da kommen sicherlich noch weitere Fälle hinzu).
Dementsprechend schaut meine Überlegung so aus, dass ich einen Globalen Zustand habe, welcher sicher natürlich verändern kann. Zeige ich ein Popup an, dann vermerkt die Komponente das über ein entsprechendes Event im State. Andere Komponenten können sich als Listener am State registrieren und bekommen mit Das und Was sich geändert. Und darauf könnte ich dann reagieren.
Würde mir glaub so einiges vereinfachen.
Ich bin mir nicht sicher, ob Industry City nicht eigentlich ein zu großes Projekt ist - vor allem als zweites Projekt. Wenn ich an Feature Runner zurück denke, da war alles irgendwie “einfacher” und “simpler”.
Aus Neugier hab ich mich mal versucht ein Tower Defense zu prototypen. Allem voran erstmal nur Weg-findung. Und das Ergebnis (keine 3h arbeit) find ich schaut echt gut aus:
Und das lässt mich dann halt auch drüber Nachdenken. Das Spielkonzept von so einem Towerdefense ist irgendwie schlichter und einfacher als die eines Tycoon Spiels. Ein Großteil der Spielelemente hätte ich ja schon im Prototyp. Was jetzt noch fehlt sind die Angriffe vom Tower auf die Figur. Und dass die Figur angreift, wenn es keinen Weg gibt. Im Vergleich dazu ist die Liste von Industry City unendlich lang :-/.
Und einen simplemen Mechanismus zum Angreifen der Türme hab ich auch hinbekommen. Und das in nicht mal einer Stunde:
Zudem zeichne ich auch noch mithilfe von Gizmos (werden nur im Editor gezeichnet) mein Ziel + den Weg.
Der Prototyp ist mittlerweile echt voll weit. Und ich bin überrascht wie einfach das ganze bisher war. Der Feind wird mittlerweile erkannt und die Türme eröffnen automatisch das Feuer:
Also. Ich würde Industry City an der Stelle jetzt einfach mal auf Eis legen. Ich hab ja alles schön auf Gitlab gesichert und kann da jederzeit wieder weiter machen, wenn ich das denn möchte.
Ansonsten würde ich mich wohl eher dem Tower Defense widmen. Es reizt mich einfach gerade viel mehr, dass Spiel zu entwickeln als an Industry City dran zu bleiben.
Generell sollte ich bei Projekten den Prototyp besser nutzen. Industry City war als Prototyp nicht spielbar. Aber mein Tower Defender-Prototyp deckt schon jetzt die wichtigsten Elemente ab, sodass ich daraus tatsächlich was Spielbares machen kann:
- Ich hab ein Start- und Zielpunkt wohin sich die Minions selbstständig bewegen
- Wegfindung die sich mit jedem Hindernis aktuallisiert
- Bau von Towern
- Towern können Minions anvisieren und abschießen.
- Minions haben Lebenspunkte und sterben wenn diese auf 0 fallen
- Jede neue Welle bringt stärkere Minions hervor
- Kamerasteuerung
Und das alles in weniger als 24h arbeit!
Das Level ist zwar noch zu klein - aber schaut es euch an. Spielbar wäre es schon jetzt!
1 „Gefällt mir“
Bei der Spielentwicklung die Spaß-Aufwandsrelation zu maximieren sehe ich auch als einer der Best Practices. Sprich sich vom aktuell Möglichen treiben zu lassen. Meine ersten Spiele waren nur so gestrickt: Mal nen Männchen laufen lassen, mal bei Kontakt mit anderen reproduzieren lassen weils gerade einfach umzusetzen ist und huch ein kleiner Aufbau-Sim kam heraus.
Aber meist möchte man ja eigenen Ideen und Fantasien das Leben einhauchen, dann muss man gegen Goliath kämpfen. Achjaaa 
Wie ist das ganze realisiert?
- Wie entdecken die Türme valide Ziele?
- Die Kugeln folgen dem Ziel offensichtlich während des Fluges: erfolgt der Schaden bei Abschuss der Kugel oder bei Impact?
- Wie wird der Impact berechnet?