Tagebuch: Industry City


#162

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.


#163

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.


#164

Kann ich nicht bestätigen - ich nutzer aber auch eine externe lib dafür ( https://www.newtonsoft.com/json ). 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 :stuck_out_tongue:.


#165

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) :-/


#166

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.


#167

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 :stuck_out_tongue:.


#168

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 :slight_smile:.

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


#169

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.


#170

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:

image

Alles was auf It endet testet entsprechend eine Prefab.


#171

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 :slight_smile:.


#172

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 :slight_smile:. 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 :slight_smile:.


#173

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.


#174

Hab heute auch mal wieder spaßeshalber mit 3D-Modellierung rumgespielt und dabei kam das hier raus:

image

Und zwar schön inkl. 2 Animation (öffnen und schließen). War eigentlich auch relativ flott damit :slight_smile:.


#175

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.


#176

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 :-/.


#177

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.


#178

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:


#179

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!


#180

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 :sweat_smile:

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?

#181

Ja - so kommt es von einem zum anderen ^^. Aber genau die Iteration (was ja dann im Prototyp endet) scheint extrem wichtig zu sein.

  1. Das war echt simpel. Ich hab einen Sphere-Kollider (also ne Kugel) an die Kanone des Turms gepackt. Der hat dann halt einen relativ großen Radius (in dem ein oder anderen geposteten Video sieht man den auch). Läuft nun ein Minion da rein, dann löst er einen Trigger aus. Die Kanone erkennt also den Minion und nimmt diesen aufs Korn.
  2. Jupp, die Kugel bekommt Ihr Ziel vom Turm mit. Dadurch kann sie diesem folgen und macht Schaden sobald diese den Gegner trifft. Solange es damit nicht zu Problemen mit der Performance kommt würde ich das auch so lassen.
  3. Meinst du mit Impact den Schaden oder die Berührung an sich? Ersteres ist einfach eine Subtraktion von 1 (Minion startet mit 10 Leben initial). Die Berührung an sich ist dabei denkbar einfach: es geschieht mithilfe von Collidern (oder anders ausgedrückt: Unity3D nimmt mir die Arbeit ab^^).