Werde ich doch nicht. Ich hab die aktuelle Version abgekürzt. Das 3D-Model für Tower ist drin und ich hab die Grafikeinstellungen mal auf Low gesetzt. Zudem hab ich die Updates auf die Kanonen etwas reduzieren können - was auch nochmal Performance geben sollte.
Ich denke, dass ich dann in ein paar Minuten das Update in den Store einreichen kann.
So. Das Update ist eingereicht. Sollte in ein paar Minuten online sein.
Was auffallen könnte ist, dass Türme nicht mehr Rot eingefärbt werden - sobald diese nicht platziert werden können. Das war eigentlich noch auf meiner Todo-liste. Aber wie bereits geschrieben: ich werde das Spielprinzip etwas umbauen. Somit würde ich jetzt etwas fixen was ich in der nächsten Version komplett rauswerfen würde.
Von daher möchte ich die Zeit sinnvoll nutzen 
Zum Glück hab ich in Vergangenheit schon so manches Tutorial gemacht. Dadurch ist es relativ einfach in Unity mit einfachen Formen einfache Sachen zu machen. Und heraus kommt dann sowas:
Besteht derzeit wirklich komplett NUR aus würfeln. Mit Vertex-Snapping kann ich die auch perfekt zueinander ausrichten.
Letztendlich erhoffe ich mir davon auch, dass es performanter als das Terrain ist.
Das hat es für mich leider auch nicht gebracht. Schade, aber kann man wohl vorerst nichts machen. Dabei sollte die neue Pipeline doch auf Low-end Geräten besser funktionieren 
Zumindest ist das Unity Logo jetzt noch schneller und ich darf ganze 20 Sekunden die grünen UI Elemente auf schwarzem Hintergrund bestaunen
Vielleicht mag dein Smartphone die Partikel nicht. Weil ansonsten läuft da eigentlich nichts (soweit ichs gerade im Kopf habe). Ich hoffs mal, dass das die Ursache ist.
Dachte ich auch. Aber wenn es halt echt an den Partikeln liegt - die kamen halt afair mit der neuen Pipeline. Von daher bin ich echt gespannt, was das nächste Update bringt. Denn da machen Partikel vom Leveldesign her keinen Sinn mehr und ich bin auch gerne bereit darauf zu verzichten.
Ach ja: Und danke fürs testen im übrigen 
So - ein Großteil der Map steht schonmal:
Und ich konnte Haufenweise Zeug rauswerfen und löschen, auf das ich soooo stolz war ^^ — (leider kein Sarkasmus). Aber gerade all der Code über das Platzieren des Towers, Erkennen ob ein Minion geblockt ist, spawnen von dem Schuss … das braucht es bei dieser Variante einfach nicht mehr.
Gibt also keinen Grund den Code zu behalten.
Ich hab gerade eine richtig gute ProgrammierSession hinter mir. Hab angefangen die Plattformen zu mit Logik zu versehen. Und um zu erkennen welche Plattform ausgewählt wird nutze ich Raycasts. Soweit so gut. Eigentlich nicht wirklich kompliziert.
Das tolle an der Session ist, dass ich eine extreme Testabdeckung hinbekommen hab. Gerade solche Szenarien fand ich bisher immer unglaublich schwer zu testen. Vor allem wenn ich die Szenerie nicht komplett aufbauen möchte. Also hab ich mal das gemacht, was mir mit Java komplett klar gewesen wäre: Nicht testbaren Code in eigene Klassen auslagern. Und was nicht wirklich zu testen ist ist der Raycast an sich und der MausInput (Der kommt über eine readonly property).
Meine Tower hingegen haben tatsächlich einen Test der eine szenerie aufbaut wie im Spiel - nämlich wenn er einen Minion anvisiert. Das Problem hierbei ist nur: er war nicht unbedingt zuverlässig. Manchmal hat sich der Turm gedreht - manchmal nicht. Ich glaub das Problem war, dass ich nicht auf ein FixedUpdate gewartet hab - sondern auf ein Update (ersteres ist für die Physik da).
Da mir diese Art von Tests schon öfters Probleme gemacht haben, bin ich froh, hier einen (von anfang an) verlässlichen zu haben.
Ich war die letzten Tage recht fleißig und hab auch im Gegensatz zu sonst jeden Tag was machen können. Es waren zwar immer nur kleinere Subtasks - aber es hat mich doch ganz gut voran gebracht.
Momentan teste ich gerade die Funktionalität, dass man Türme auf Plattformen bauen kann. Und das schöne daran ist, ich bin mehr als zuversichtlich. Denn es gibt wirklich viele automatisierte Tests eben für genau dieses Feature. Vom Klick auf die Plattform bis hin zum schließen der Plattform hab ich alles abgedeckt.
… Nachdem ich es aufm Handy installiert hab stirbt die App beim kauf eines Turmes. Die Fehlermeldung ist nicht wirklich hilfreich - wo genau das Problem liegt 
Nachdem ich mir etwas Gedanken dazu gemacht hab - hab ich mich dazu entschieden das ganze neu zu implementieren. Und ich glaub die neue Lösung hat durchaus seine Vorteile. Hoffentlich wird diese dann keine Probleme machen.
Da ich am Wochenende und am Feiertag nicht wirklich Zeit fürs programmieren hatte, bin ich damit entsprechend auch noch nicht fertig. Aber heute Abend hab ichs immerhin schonmal soweit bekommen, dass man Tower kaufen + platzieren kann 
Heute kam übrigens voll die Ernüchterung. Ich spiel einen Zwischenstand auf mein Handy. Denk mir: das muss jetzt passen und CRASH. Gleiches Spiel wie vorher und ich dacht mir: das kann doch nicht wahr sein.
Mit der Fehlermeldung kann man übrigens so ziemlich gar nix anfangen - danach googlen hilft auch nichts, weil sie sehr generisch war. Im Prinip hatte ich soviel Inhalt: „App XYZ - Crash“. Wo, warum, wieso, weshalb. Keine Ahnung.
Hab es jetzt wohl aber fixen können. Das Problem war wohl, dass ich ein .Net-2-Mono-Runtime verwendet hab und das hab ich jetzt auf eine (afair) 4er-Version (ist maximal) hochgestellt. Im Internet hatte ich den Hinweis bekommen, dass es wohl was mit Multithreading zu tun hat und ich könnte mir vorstellen - das mir hierbei einfach ein Sprachfeature von einer höheren Version hilft.
Auf jeden Fall scheint es jetzt zu gehen und ich kann daran dann die Tage weiter arbeiten .
So ich hab es mal auf meinem neuen Handy installiert (was dazu führt dass ich auch öfter und schneller testen werde :D)
Und so ein zwei Sachen sind mir da aufgefallen.
Wenn man versucht den Turm „falsch“ zu platzieren bzw. hab es nur mit den Bergen getestet, wäre es gut wenn der Zielkreis rot wird, weil ich überhaupt nichts gesehen habe dass ich da nicht bauen darf.
Womit wir zum nächsten kommen, ich kann den Turm dann da lasse und weitere platzieren die dann aber nicht schießen aber zur Wegberechnung mit einbezogen werden.
Außerdem bin ich dann in einem komischen Zustand dass ich die Kamera nicht mehr bewegen konnte und beim Starten der Welle ging sie irgendwo hin und ich weiß nicht wieso.
Und man konnte die falschen Türme dann verkaufen und hat sein Geld bekommen 
Aber lass dich nicht davon entmutigen^^
Sehr gut. Das freut mich zu hören
Lass ich nicht. Keine Sorge. Warum? Weil all das was du beschrieben hast schon jetzt der Vergangenheit angehört. In Zukunft wirst du keine Tower mehr per Drag’n’drop platzieren können. Denn ich werde das komplette Level-Design umstellen 
.
Und alles was du beschrieben hast, würde ich eben auch genau dem Platzieren der Tower zuschreiben. Denn damit ist viel Logik verbunden die sich mittlerweile im Nirvana befindet ^^
Ah das ist gut. Ich hatte mir nicht alles zu 100% immer durchgelesen jetzt und dachte eig, dass die Änderungen jetzt vllt schon drinne waren
Dann hab ich nichts gesagt.
P.S. Tower Defenses mit frei platzierbaren Türmen hab ich zwar normal lieber, aber gibt auch Ausnahmen
Geht mir genauso. Deswegen hatte ich es auch ursprünglich so geplant. Nur leider wird das nicht performant laufen. Hatte das mal auf meinem Smarphone getestet und mit zunehmende Türmen ging die Performance dann leider doch irgendwann sehr drastisch nach unten. Darum die Entscheidung zum veränderten Gameplay.
Heute habe ich einen gefühlten Meilenstein erreicht:
Das Platzieren von den Türmen ist fertig, getestet und gemergt! Dazu kommt, dass ich noch einen Bug gefixt habe bei dem Türme bei einem neuen Spiel nicht entfernt wurden.
Zu viel mehr werde ich heute aber auch glaub nicht kommen. Denn in ~1h fahren wir gen Muttertag los.
So bin mal wieder etwas weiter gekommen. Hab jetzt drin, dass selektierte Plattformen markiert werden. Da waren die Tests das größte Problem - da die Start-Methode da nicht aufgerufen wurde. Hab mir jetzt nochmal die Doku durchgelesen und entdeckt, dass eigentilch die Awake-Methode als Konstruktor dient und mein Code deswegen wohl da rein gehört (hoffe ich).
Habs eben auf mein Handy gespielt und werde die neue Funktion mal testen
wie machst du die Tests? gibts da was von Unity oder NUnit?
Die Antwort lautet: ja. Unity bringt von Haus aus NUnit mit und erweitert es. Was ich immer dazu packe ist FakeItEasy fürs mocken (kommt leider nicht standardmäßig von Unity. Der weg ist auch etwas umständlich. So lade ich mir das NuGet-Pkg lokal runter, öffne die Zip und kopiere die richtige DLL (4.0) in mein Projekt. Soweit ich weiß (hab mich aber nicht wirklich schlau gemacht) hat Unity leider kein nuGet-support.
Im wesentlichen kannst du dann zwei Sorten von tests rennen lassen:
Editor Tests würde ich als stumpfe Unit-Tests bezeichnen. Sie laufen halt “einfach”. Wohingegen PlayMode tests Integrationstest sind. Unity lädt diese ein eine Szene rein und du hast damit den kompletten Lifecycle welchen du dir in den Tests einfach zu nutzen machen kannst. In dem Fall musst du lediglich eine andere Annotation (UnityTest anstelle von Test) nutzen und der Rückgabetyp muss vom Typ IEnumerator sein. Dann kannst du über z.B. mittels yield return null bis zum nächsten Update wareten. Du kannst anstelle von null aber auch konkret angeben was du magst (z.B. newWaitForFixedUpdate() oder newWaitForSeconds(seconds)).
Ansonsten gibt es halt ein paar Feinheiten. Z.B. das du am besten einen Layer für deine Input-Methoden einführst. Denn die Abfrage nach Maus & co. ist readonly und an sich nicht Mockbar.
Hin und wieder passieren zwar noch Dinge die ich mir nicht erklären kann (so z.B. gestern als die Start-Methode nicht aufgerufen wurde) - aber im großen und ganzen bin ich trotzdem sehr Zufrieden. TDD ist damit eigentlich ziemlich gut möglich.
Hier hatte ich mal was beschrieben - was meine Tests grob beschreibt (mit Fokus aufs Prefab-Testen):
So - und weiter geht es im TDD-Style. Ich hab die Story von gestern gemergt und heute eine neue gestartet. Begonnen hab ich damit, dass ich erstmal Tests geschrieben / angepasst hab die jetzt natürlich erstmal rot sind:
Die zwei Tests schlagen aus mehreren Gründen fehl (da Integrationstest haben die nun mal mehrere Assertations ). Die Story ist frühestens dann fertig, wenn diese beiden Tests ebenfalls grün sind.
Im übrigen gibt es für mich mit dem Projekt auch eine kleine Premiere. Bisher war ich nämlich immer zu faul bei Assertations den Grund mit anzugeben. Beispiel:
Assert.IsFalse(Prefab.BuyMenu.Show, "The BuyMenu should have been closed!");
Aber gerade bei Integrationstest sind diese aber nicht gerade unwichtig. Einmal kurz verguckt und auf einmal schaut man auf die falsche assertation. Oder man hat was geändert und die Zeilenangabe der Exception stimmt einfach nicht mehr. Aber mit der Nachricht ist es direkt klar, was fehl geschlagen ist.
So mal ein kurzes Update. Haben eben die Verkaufen-Funktionalität implementiert und alle meine Tests sind grün (+ ich hab zwei neue Unit Tests eingebaut).
Die Funktion geht also in die Testphase und ich bau gerade die APK, damit ich auf dem Handy das tatsächliche Ergebnis sehen kann.
(Nicht das wieder so was passiert wie bei der Kaufen-Funktion, wo alles im “Emulator” wunderbar funktioniert aber aufm Gerät crasht die App).
