Keine Ansicht. Kommt von der Pathfinding lib und ich weiß noch nicht wie ich das los werde. Einzige Möglichkeit die ich sehe ist die Geschwindigkeit beim Drehen um die eigene Achse weiter zu erhöhen. Aber vllt bemühe ich einfach Mal Google ^^
Auch wenn es hier kein Update gab - so war ich doch fleißig in den letzten Tagen. Allem voran sei gesagt: ich bin sehr froh mich dafür entschieden zu haben, nochmal zur übersprungenen Prototypenphase zurück gekehrt zu sein.
Zum einen konnte ich viel experimentieren und Lösungen erarbeiten, zum anderen hat sich meine Idee vom Spiel durchaus verändert.
Ein Problem was ich gelöst hab, hat mit dem Pathfinding zu tun. Ich wollte wissen, ob ich mit Code überprüfen kann, ob ein Pfad existiert. Code dafür hab ich 
.
Desweiteren hab ich meine bisherigen Lösungen verbessert. Aus einer einfachen Simulation wurde nun so langsam eine spieltaugliche - welche einfache Abläufe sehr gut abdeckt. Den i.d.T werden mittlerweile echte Resourcen und Produkte von A → B gebracht:
Auf dem Bild seht Ihr die fertigen Produkte, welche aus Stein gemacht werden.
Produkte kennen übrigens ihre Ausgangsmaterialen womit ich schonmal ein einfaches Rezept-system habe.
Des weiteren haben sowohl Produkte als auch Resourcen einen Wert. Beide können in einem Shop verkauft werden. Das und die Tatsache, dass meine Autos sehr flexibel mit Ihren Zielen sind hat mich auf eine Idee gebracht.
Zuvor wollte ich es so realisieren, das Autos zu einem Gebäude gehören und davon kontrolliert werden. Davon bin ich jetzt erstmal weg. Ich will, dass der Spieler die Autos managed. Was zur Folge hat, dass ein Level beginn so aussehen könnte:
Es existiert ein Shop, es existiert ein Straßenteil und irgendwo gibt es ein Resourcenfeld. Der Spieler hat ein Auto unter seiner Kontrolle und würde zu Anfang das erstmal zwischen Resource und Shop pendeln lassen.
So mal die grobe Idee - ich hab noch ein paar mehr 
. Aber erstmal möchte ich noch ein paar Sachen an meinem Prototypen ausprobieren, die mitunter Einfluss auf die späteren Architektur haben werden.
Prototyping ist essentiell für eine erfolgreiche Design- und Konzeptphase. Mir ist ohne noch kein größeres Projekt „gut“ gelungen. Egal ob in der Softwareentwicklung oder im Maschinenbau. Leider hat man nicht immer die Möglichkeit dazu.
Vielleicht bin ich auch einfach nur eine Projektmanagement Niete. Wie planst du normalerweise Features wenn du nicht zu Prototyping greifst?
Das ist eine gute Frage. Es kommt halt immer drauf an, wie groß das Feature ist und in welchem Umfeld ich mich bewege.
In meiner letzten Firma hatte ich gerne mit Ablaufdiagrammen gearbeitet, die ich mir ausgedruckt und neben mich gelegt hab. Dadurch konnte ich darauf meine Notizen machen. Aber das war dann eher für komplexere Sachen der Fall.
Im jetzigen Betrieb setze ich bei einfachen Features auf Tests - wenn möglich am besten Integrationstests.
Das einzige wo ich bisher immer konsequent auf Prototyping gesetzt habe, war wenn ich mit neuen Technologien arbeiten musste.
Für sowas hab ich normalerweise immer ein Trash-Projekt irgendwo rumliegen. Da experimentiere ich erstmal mit dem neuen rum und schaue was möglich ist. Meist waren es dann halt irgendwelche Libs und von daher war das Prototyping auch schnell abgeschlossen.
Ich würde auch mal sagen, die meisten Features gehen auch ohne Prototyping. Aber bei Projekten wirds halt schon interessanter. Vor allem welche Art von Projekten und in welchem Umfeld. Im Betrieb fehlen uns leider die Prototypen - was ich seit einiger Zeit auch regelmäßig kritisiere. Da planen wir unsere Projekte eher mit Diagrammen, vielen Meetings, mit Architekten und eventuell dem ein oder anderen PoC.
Wir bekommen die Projekte zwar umgesetzt (nicht so wie im Betrieb davor), aber ich bin der Meinung, dass wir zu viele Probleme hatten, die wir mit einer besseren Vorbereitung (also Prototyping) nicht gehabt hätten.
Privat hingegen mach ich (seit ich Spieleentwicklung angefangen hab) eine kleines Projektmanagement-Studium. Denn zuvor hab ich praktisch nichts anderes als Prototypen daheim entwickelt - weil mir für größere Projekte die Motivation gefehlt hat. Wobei ich trotzdem hier erst richtig gelernt hab (und vermutlich noch immer lerne), was Prototyping bedeutet. Letztendlich finde ich, dass Industry City ein sehr gutes Beispiel dafür ist - warum Prototyping so wichtig ist.
1 „Gefällt mir“
Meine Simulation funktioniert mittlerweile so gut, dass sich meine Autos untereinander streiten. Wenn die Dinger nicht so putzig wären, würde es mich ja ärgern ^^. Aber es sieht doch irgendwie goldich aus, wie die sich vor einer Resource streiten:
Wie Ihr seht: 5 Autos streiten sich und bekommen den Konflikt nicht gelöst. So ganz ist mir noch nicht klar warum - denn jedes Auto ist noch im „Ich fahre zum Ziel“-Modus. Dementsprechend schaut es mehr so aus, als ob die sich blockieren würden - was ich seltsam finde, weil es eigentlich keine Kollisionserkennung geben dürfte (wobei, jetzt wo ich es hier schreibe - die agents haben zumindest jeweils eine breite und ja. ich habs während ich tippe rausgefunden.)
Wenn ich die „Obstacle Avoidance“ auf Quality:none setze, dann scheint es zu funktionieren. Ja, jetzt läuft die Simulation.
Was ich gerade am testen bin/war ist das erweiterte Rezeptsystem. Vorher konnten Produkte nur ein Basismaterial haben. Jetzt ist es eine Liste. Im Screenshot seht ihr es übrigens. Denn die Fabrik enthält Steinschwerter. Diese brauchen als Ausgangsmaterial Stein+Holz. Und das Schwert wird dann für 5 Geld verkauft.
Also es macht echt Spaß dem Gewussel zuzusehen und ich bin doch überrascht, wie einfach die Simulation bisher in der Entwicklung war.
Um nochmal eine Lanze für Prototypen zu brechen: Ohne Prototyp hätte ich erwartet, dass der aktuelle Stand sehr viel Aufwand benötigen würde und ich hätte nicht versucht es umzusetzen. Der Prototyp wird das MVP echt aufwerten!
Ich bin vollauf begeistert von der bisherigen Simulation. Vor allem, weil Sie bisher recht einfach war. Hab das ganze jetzt auch weiter ausgebaut, sodass ein Produkt auf einem anderen Produkt basieren kann. Zusätzlich sind jetzt auch Produktionszeiten variable. Hier mal ein Video von dem ganzen:
Und hier die Erklärung was passiert:
So eine Simulation ist einfacher zu schreiben als erwartet. Mein Prototyp deckt schon eine ganze Menge ab.
Ich hab jetzt z.B. folgende Produktion gesetzt:
Fabrik 1 baut Griffe und holt sich dafür Holz
Fabrik 2 baut Klingen und holt sich dafür Stein
Fabrik 3 baut Schwerter und holt sich dafür Griffe aus dem Lager von Fabrik 1 und Klingen aus dem Lager von Fabrik 2
Shop holt sich die Schwerter von Fabrik 3 ab und verkauft diese
Und dabei haben die unterschiedlichen Produkte unterschiedliche Werte im Verkauf und benötigen unterschiedlich lange in der Produktion.
Durch mein einfaches Rezeptsystem könnte ich das beliebig tief verschachteln - was mir später einen Tech-Tree erlaubt.
Danke für die ausführliche Antwort, sehr interessant
Dann haben wir ähnliche Erfahrung.
Keine Ursache. Musste mich etwas zügeln um mich nicht zu sehr in (nebensächlichen) Details zu verlieren. Ich glaub über Prototypen und Prozesse könnte ich ewig philosophieren 
.
So und an der Stelle noch ein weiteres Update zu meinem Prototypen. Ich hab jetzt eingebaut, dass Rezepte auch mehrere Typen von derselben Resource brauchen können (z.B. 2x Holz). Das war vorher nicht möglich.
Außerdem hab ich etwas mit dem UnityInspector rumgespielt und konnte mir ein DragAndDrop-Control bauen, um diese Liste einfach pflegen zu können.
Wie der ganze Spaß funktioniert hab ich mal in einem (diesmal längerem) Video gezeigt. Hier seht Ihr, wie ich ein neues Produkt anlege, das Rezept und Wert einstelle + die Einstellungen für Auto und Fabrik:
So. Hab in der letzten Zeit mal etwas Zeit in Tool-Entwicklung investiert. Zum einen hab ich den Inspector verbessert und ich hab einen eigenen Editor geschrieben:
Über kurz oder lang fände ich es glaub ganz praktisch, wenn ich damit meine Rezepte managen könnte. Ich könnte mir halt gut vorstellen, dass ab einer gewissen Menge an Produkten für eine bessere Übersicht sorgen könnte 
.
Gestern Abend hab ich dann auch glaub mein letztes Element in den Prototypen eingebaut. Nämlich, dass die StadtElemente (Gebäude und Autos) regelmäßig Kosten verursachen.
Von daher gesehen dürfte ich einen guten Prototyp haben der vor allem die Simulationselemente des MVPs komplett abdeckt. Und ich denke es ist wichtig, dass sich der Prototyp auf eine Sache konzentriert (eben die Simulation). Denn letztendlich darf man nicht vergessen: ich muss das ganze jetzt nochmal ordentlich machen ^^.
Einen (kleinen) Fehler hab ich aber glaub gemacht. Ich hab nämlich weder den Prototypen geplant - noch dokumentiert. Ich glaube gerade letzteres wäre aber für zukünftige Prototypen gut - nicht das ich beim übertragen ein Feature übersehe.
Ansonsten hab ich auch eine kleine Änderung in meinem Entwicklungsprozess geplant. Ich möchte glaub verstärkt auf Prototypen setzen - also das diese nicht nur bei Projektstart zum Einsatz kommen.
z.B. würde ich als nächstes einen Prototypen für das UI anpeilen.
Es mag im ersten Moment vllt etwas aufwendiger klingen - aber ich glaube, dass es mir sogar Zeit sparen könnte.
So schön TDD auch ist - so manches Refactoring wird dadurch dann doch in die Länge gezogen. Gerade diese größeren Refactorings möchte ich mit Prototypen erschlagen. Ich gehe also davon aus, dass ich mithilfe eines Prototypen viel gezielter meine Tests schreiben kann.
Eine weitere Änderung in meinem Ablauf wird sein, dass ich mir (endlich!!!) mal Scene-Tests anschauen werde. Bisher hab ich meine IntegraitonsTests auf Prefab-Ebene getestet. Mehrere Prefabs kommen also nicht zusammen. Ich glaube, dass ich mir dadurch hin und wieder Sachen verkompliziert habe. Ich hoffe, dass mir eine komplette Scene gerade so Sachen wie Test-Setup stark vereinfachen werden.
So. Ich hab mittlerweile ja meinen Prototypen als abgeschlossen definiert und bin jetzt dabei das ganze richtig umzusetzen.
Das refactoring vom Prototypen hab ich auch durch und dieser befindet sich mittlerweile auch auf meinem Handy. Was gut war - denn er hatte noch kleine Fehler, die erst dort aufgefallen sind. Jetzt funktioniert er aber wie er soll.
Stories habe ich mir auch schon erstellt und bin gerade auch an der ersten dran. Generell schaut mein Board momentan so aus:
Und wie Ihr seht bin ich auch an der ersten Story schon dran. Hab sie praktisch eigentlich schon fertig. Was mich überrascht ist, dass ich mit einem Integrationstest gerade auch die komplette Factory abgedeckt habe - UnitTests dürften dafür eigentlich gar nicht mehr wirklich notwendig sein. Vielleicht lass ich noch unterschiedliche Produkte testen - aber den wesentlichen Prozess hab ich schonmal gut getestet .
So. Genug für heute. Hab jetzt ganz schön was weg gearbeitet bekommen.
Ich hab jetzt meine Shops und meine Fabriken drin und entsprechende Tests. Diese decken auch schön folgende Szenarien ab:
- Was passiert wenn genug resourcen vorhanden sind
- Was passiert wenn die resourcen ausgegangen sind
- Was passiert wenn neue resourcen angekommen sind
Das ist durch Integrationstests abgedeckt.
Zusätzlich gibt es dann noch Unit-Tests für zwei Services, welche ich mir vom Prototyp rüber kopiert habe.
Ich merke hier gerade, dass ich deutlich weniger Tests habe als vorher. Dafür decken aber meine Integrationstests mehr ab und ich mache gebrauch von Black-Box-Testing.
Leider verabschiede ich mich damit von TDD. Auf der anderen Seite muss ich sagen, es beist sich halt auch mit Prototyping.
Da mir das Prototyping aber wichtiger ist, werde ich wohl nur so halbes TDD haben. Mal schauen, ob ich zukünftig einen Weg finde, wie sich beides besser vereinen lässt.
Hab den Prototypen fast komplett übernommen und dabei wieder was gelernt. Denn meine Tests sind fehl geschlagen.
Der Test der Fehl schlug war der für die Autos. Dabei wird der Weg vom Auto geprüft, wenn es Resourcen abholt und liefert. Ich dachte, wenn ich ein Ziel angebe, dann wird das genauso auch übernommen. Was aber nicht der Fall ist.
Z.B. gebe ich folgenden Vector als Ziel an: X:2 Y:0 Z:5. Aber wenn ich den Wert auslese stand drin: X:2 Y:0.1 Z:4.4. Irgendwann kam es mir. Am angegebenen Punkt befindet sich kein befahrbarer Weg. Also scheint der Vector genommen zu werden, der befahrbar und nahe zum Ziel ist. (Gut zu wissen).
Das war bisher auch mein aufwendigster Test - welcher eine eigene Szene hat:
Das ist mein erste Test, der mit einer Szene arbeitet. Funktionierte aber ganz gut und hab auch nochmal einiges gelernt, was ich für zukünftige Tests mitnehmen kann.
Was mir jetzt noch fehlt sind im groben zwei Dinge:
- Regelmäßige Unterhaltskosten für Gebäude und Fahrzeuge
- Eine Szene
Witzigerweise hab ich gerade für den letzten Punkt vergessen eine Story zu erstellen.
Alles in allem bin ich aber schon sehr zufrieden. Zumal ich dank dem Prototyp mehrere Male den Code refactored hab.
- Während der Erstellung
- Nach Fertigstellung des Prototypen
- Bei der Umsetzung
Gerade letzteres hat nochmal viel Verbesserung gebracht .
Die Tests mit den Scenes gefallen mir richtig gut. Denn die decken echt viel Code ab (zumindest sofern ich nicht falsch liege. Weiß noch nicht, wie ich meine Coverage messe). Ich bin gerade nur am überlegen, ob ich das nicht besser hätte machen können.
Z.B. hab ich jetzt eine TestScene für die monatlichen Kosten. Aber vllt wäre es geschickter gewesen eine richtige Spielscene zu bauen und diese testen zu lassen.
Das werde ich vermutlich auch als nächstes angehen - denn die Kosten sind implementiert. Zudem will ich schauen, ob ich die andere Scene mit der Navigation auch gegen die richtige laufen lassen kann. Obwohl ich hier tatsächlich weniger Sinn sehe.
Außerdem hab ich einen Weg gefunden, wie ich meine Tests etwas optimieren kann. Aber vorerst will ich erklären, WAS ich optimieren möchte.
In so einem Spiel dauern manche Prozesse einfach etwas länger. Z.B. die Produktion von einem Item könnte 3 Sekunden dauern. Der Weg, welchen das Auto zurück legen muss könnte 2 Sekunden dauern und monatliche Kosten werden alle 10 Sekunden berechnet.
Das sind alles Werte, die man so in einem Test nicht haben möchte und ich möchte diese für die Tests logischerweise nicht anpassen. Dennoch rennt mein Test für die monatlichen Kosten in unter 1s (was ich als Timeout momentan auch habe) obwohl der Code von 10s aus geht.
Es ist tatsächlich sehr einfach zu lösen. Ich setze Time.scaleTime von 1 auf 50 und dann läuft alles ingame 50x so schnell.
Bisher habe ich das immer für den kompletten Test gesetzt. Neu ist diese Methode: WaitForScaledSeconds(10):
public static IEnumerator WaitForScaledSeconds(int seconds, int scaled = 50) {
Time.timeScale = scaled;
yield return new WaitForSeconds(seconds);
Time.timeScale = 1;
}
Somit beschleunige ich nur meine Wartezeit.
Ich hab nämlich das Gefühl, dass mir ansonsten möglicherweise anderer Code für den Test zu schnell ausgeführt wird und mir deswegen in Ausnahmefällen ein Test vllt fälschlicherweise fehlschlägt. Ob diese Sorge berechtigt ist, weiß ich nicht. Aber irgendwie fühlt es sich besser an, nur dann zu beschleunigen, wenn ich es tatsächlich brauche.
Nein, wäre es wohl nicht. Ich hab mich dafür entschlossen den Setup für Scene extra zu testen und dabei kamen mehr Anforderungen bei rum als der eine spezielle test abgedeckt hätte. Von demher macht es Sinn für die Spielszene einen eigenen Test zu haben, der auf Notwendige Elemente prüft.
Dieser schaut momentan so aus:
namespace Tests.PlayMode.Scene {
[Category(TestCategory.scene)]
public class GameSceneTest : SceneTestFixture {
private Account _account;
private CityService _cityService;
[Inject]
public void Init(Account account, CityService cityService) {
_account = account;
_cityService = cityService;
}
[UnityTest]
[Timeout(1000)]
public IEnumerator CheckGameSceneSetup() {
yield return LoadScene("Game");
AssertCamera();
AssertAccount();
AssertCityElements();
AssertNavigation();
}
private static void AssertCamera() {
Assert.IsNotNull(Camera.main, "There should be a main camera in scene");
}
private void AssertAccount() {
Assert.AreEqual(100, _account.Money, "The player should start with 100 money");
}
private void AssertCityElements() {
Assert.IsTrue(_cityService.Cars > 1, "There should be at least 2 cars in scene");
Assert.IsTrue(_cityService.Factories > 0, "There should be at least 1 city in scene");
Assert.IsTrue(_cityService.Shops > 0, "There should be at least 1 shop in scene");
Assert.IsTrue(Object.FindObjectsOfType<ResourceStock>().Length > 0, "There should be at least 1 resource in scene");
}
private static void AssertNavigation() {
Assert.IsTrue(Object.FindObjectOfType<NavMeshSurface>().navMeshData != null, "There should be a pre-calculated navmesh in scene");
}
}
}
Der Test soll dafür sorgen, dass ich wirklich ein Minimum-Setup für die Simulation habe. Man könnte Ihn definitiv verbessern (z.B. Magic-Values entfernen), aber für den Moment tut er was er soll. Und da ich erwarte, dass ich den in Zukunft noch ein paar mal anpassen muss, werde ich diesen erstmal so lassen wie er ist .
Schön daran ist, dass ich jetzt wieder bei TDD angekommen bin. Außer einer leeren Scene hatte ich nämlich genau nichts. Der Test ist somit das Akzeptanzkriterium dafür, dass mein aktueller Task als erledigt angesehen werden kann.
So. Und ich hab eine „Marketing-Campagne“ gestartet. Ich poste updates zu meinen Spielen immer mal wieder in verschiedenen Channels (hier, in Slack auf Arbeit und ich bin in zwei Discord-Channel für Spieleentwicklung).
Meine Hauptmotivation außerhalb von hier etwas zu posten ist im wesentlichen folgende: Ich möchte Tester finden.
Und wie könnte man das eigentlich besser, als über die assozialen Medien. Also hab ich jetzt mal einen Tweeter-Feed zu dem ganzen gestartet - wo ich immer mal wieder Updates posten möchte. Sobald mein Spiel dann mal soweit ist, dass es tester braucht, erreiche ich damit dann hoffentlich genug (https://twitter.com/tomate_salat ).
Facebook lasse ich aber erstmal außen vor - auch wenn es damals zu Bandzeiten ganz brauchbar gewesen ist.
Ahja, die Gamer Community 
Ich dachte vor kurzem bei mir, über das gleiche Thema, an Plattformem wie Indiegogo oder Gamejolt. Da sind schon einige Projekte aus Demos hervorgegangen.
Irgendwelche spezifischen Channel Tips?
Oder Kickstarter - ja. Das hab ich mir auch schon überlegt, aber dafür will ich ein Projekt haben, das schon eine gewisse Reife hat.
Gerade für sowas wie Steam fände ich es nett, weil ich keine Lust habe mind. 100€ für die Veröffentlichung zu zahlen. Ich weiß nicht ob ich es hinbekomme, aber anfangs wollte ich Industry City so designen, dass es mobil und auf pc laufen könnte. Vielleicht landet es ja dann doch bei Kickstarter .
Ich bin bei Discord in Brackeys und GameDevHQ. Aber auch nicht mehr wirklich aktiv. Ersteres ist von einem YouTuber der wohl (wie ich vermute) mit Unity zusammen arbeitet und GameDevHQ ist von dem Typ der das Videotutorial gemacht hab, wodurch ich wieder zu Unity gekommen bin.
Wobei mich GameDevHQ doch sehr nervt mittlerweile. Die erinnern mich etwas ans JFO. Die Homepage von denen war am Anfang auf Focus Community ausgelegt. Kaum hatte er genug zusammen wird es immer kommerzieller ausgelegt.
Dort hatte ich auch einen DevBlog geführt, der wohl dem Kommerz geopfert wurde. Scheint alles weg zu sein, was ich verfasst hab. Bin da nur noch um Tester später zu finden.
Habe da etwas verwechselt, entschuldige, nicht Indiegogo sondern itch.io. Oder eben auch Gamejolt. Das sind keine Kickstarter Seiten im engeren Sinne, sondern dort kannst du deine DevLogs und „spielbare“ Prototypen veröffentlichen Game Jolt - Games for the love of it
Dort hat zum Beispiel Autonauts seinen Ursprung gefunden. Und als die Entwickler merkten, dass das kleine Hobbyprojekt den Leuten tatsächlich „Spaß“ macht, haben die eine Kickstarter Kampagne gegründet und das Spiel wurde dieses Jahr schlussendlich tatsächlich veröffentlicht.
*Edit: Aber ich hab selber keine Erfahrung damit gemacht und kann deshalb auch keine Empfehlung aussprechen. Ich würde sagen es liegt an uns Beiden das herauszufinden 
Achso. Ok, ja das ist natürlich was komplett anderes als Kickstarter. Prinzipiell eine nette Idee - sofern man sein Spiel für mehr als mobile Plattformen anbietet.
Aber wenn man damit tatsächlich Leute erreicht, wäre das ja durchaus eine Überlegung wert auch mal ein Spiel anzugehen was nicht Android-Only ist.
Ja wie gesagt, mal schauen. Prinzipiell auf jeden Fall interessant und ich muss echt im Hinterkopf behalten, dass Industry City auch fürn PC rauskommen könnte. Dann wäre das bestimmt eine Option und man könnte testen, wie es ankommt. Wäre halt wirklich eine nette Vorstufe zu Steam.
Oder - je nach dem wie die Konditionen aussehen, könnte man sein Spiel auch einfach dort komplett Vermarkten.