So, da es nun ziemlich sicher ist, dass meine neues Projekt Industry City sein wird eröffne ich schonmal meinen Tagebuch-Thread.
Im Gegensatz zu Feature Runner werde ich dieses Projekt nicht blindlings starten und sehen was bei raus kommt - nein es gibt diesmal ein Konzept. Dieses umfasst bisher 5 Seiten und soll das Spiel im groben Beschreiben … und ist noch nicht fertig!
Ziel von dem Konzept ist nicht, dass ich alles Haargenau vorplane. Es geht hierbei nicht um Details. Das Konzept soll mich nur soweit bringen, dass ich weiß wie mein Spiel gespielt wird. Technische Lösungen werden erst später forciert. Im Wesentlichen ist das Konzept bisher wie folgt aufgebaut:
Es gibt einen Elevator Pitch
Es gibt fast 2 Seiten voll mit Brainstorming. Hier beschreibe ich Elemente und deren spielerische Funktionsweise
Es gibt weitere 2 (bald 3) Seiten in denen ich Workflows sammle, die mir schon jetzt bekannt sind.
Es gibt eine letzte Seite mit “Sonstigem” Kram. Dies beinhaltet eine Mockup-Grafik, eine Liste an noch offenen Fragen und eine Sammlung von Views die ich wohl ziemlich sicher umsetzen darf.
Um das Konzept abzuschliesen werde ich auf jeden Fall noch die Workflows fertig aufschreiben. Danach sollte ich hoffentlich keine offenen Fragen mehr haben und wissen - was ich bauen möchte!
Der nächste Schritt der folgen wird ist dann hacknplan. Hier werde ich dann Anfangen mein Konzept in Aufgaben zu übersetzen und meinen ersten Milestone zu planen.
Ich hatte gestern dann mal überlegt wie ich weiter mache und wie ich zu den Stories komme. Da fiel mir eine Technik ein, die unsere Scrum-Masterin uns mal gezeigt hatte. Man erstellt im wesentlichen ein Diagramm bestehend aus den Workflows und kann davon dann ganz gut User-Stories ableiten.
Da ich Diagramme total toll finde hab ich mir auch direkt gedacht: machste mal.
Klappt alles Wunderbar, nur fällt mir gerade ein, dass eine Ansicht so dermaßen komplex ist, dass ich praktisch keinen Platz mehr hab um weitere Workflows dran zu hängen. Und eine kleine Stimme tief in mir schreit mir zur “Die Maske ist zu komplex du depp!!!”.
Hier seht Ihr einen Ausschnitt vom Knotenpunkt an den noch 1 oder 2 Workflows dran müssten … mindestens.
Ok, ich glaube ich habe eine Lösung gefunden. Ich konnte die Workflows im Diagramm vereinfachen ohne Sie tatsächlich verändern zu müssen. Und das “wie” war relativ einfach: Gruppierung. In diesem Fall waren sich zwei mal zwei Workflows sehr ähnlich und konnten somit zusammen gefasst werden. Um es dennoch übersichtlich zu gestalten “leben” diese in Ihrem eigenen Panel:
Damit hab ich nur noch 2 Ausgänge an der Gebäude Detail Übersicht und kann meine weiteren Workflows daran anknüpfen lassen.
Wegen den Gedanken zur Komplexität: Ja, diese Übersicht wird vermutlich sehr Komplex - aber ich glaube das wird dem Spiel gut tun. Denn somit kann (fast) sein komplettes Gebäude (z.B. Fabrik) von einer Ansicht aus managen.
Tomate… das Gesuchte ist: superstates = nested states bzw substructures = regions im statechart diagram. Das ist ein bisschen verwirrend, weil nicht alle den Begriffen der UML State diagrams folgen (Link 1). Ein Beispiel wäre hier (Link 2).
Vereinfacht summa summarum gesagt: So wie du das gemacht hast ist es genau richtig.
Wäre mir auch um ehrlich zu sein komplett egal wenn es nicht UML-Konform ist. Es ist lediglich ein Mittel zum Zweck und soll mir als grober Leitfaden dienen. Letztendlich ist es auch der hoffentlich letzte Schritt mein Konzept zu vervollständigen.
Immerhin hilft das Konzept schon jetzt - da ich zwischendurch ein Element vergessen hatte. Da niedergeschrieben bleibt es aber auf meinem Schirm .
ich wollte das nur erwähnt habn, weil ich selber vor nicht allzu langer Zeit das gelernt hatte. Ganz unwichtig ist das (Konformität?) jetzt auch nicht.
Ist ja auch in Ordnung hab mir die Links sogar angeschaut.
Ne - ich liebe es eher gerade eine kleine Firma zu sein. Denn das ist es, was mich Feature Runner gelehrt hat. Selbst so ein kleines Spiel erfordert professionelle Techniken. Dazu gehört eben auch Projekt Management. Das ganze zieht sich ja aber durchaus noch weiter. Ein Punkt ist dann noch das Budget. Natürlich könnte ich von meinem Geld Assets kaufen (die 40€ hätte ich dann grad noch so xD) - aber es ist halt auch irgendwo ein Experiment was jetzt in die nächste Phase geht.
Von Feature Runner hatte ich mir nie mehr erhofft als Wissen zu generieren. Zusätzlich hat es mir noch ~2,75€ eingebracht. Das ist ein nettes extra - aber ich glaube Feature Runner wird nicht viel abwerfen. Die meisten Werbeviews kamen vermutlich von mir. Also glaube ich nicht, dass ich da im Monat mehr als ein paar Cent mit verdiene. Vor allem, weil die App seine Spieler wohl auch nicht halten kann - aber das ist ok.
Interessant wird es jetzt eben mit Industry City. Durch meine Planung kann ich im voraus schon stellen planen wo ich den Nutzer dazu bringen kann Werbung anzusehen. Es wird nach wie vor keine Zwangseinblendungen geben - aber für manche Dinge wird der Spieler eben Werbung ansehen müssen.
Alles in allem hoffe ich dann damit ein Konzept zu haben, was den Spieler hält (es ihm Spaß macht) und die Werbung nicht als lästig empfunden wird. Wenn das funktioniert, dann kann ich meine Spieler (hoffentlich) halten - diese generieren mir Einnahmen. Für Hero Tycoon wäre das zumindest mal verdammt praktisch .
So. Ich glaube mein Konzept nun zu einem Abschluss bekommen zu haben. Denn vorhin wurde ich mit dem Workflow-Diagramm fertig und hab mittlerweile (glaube) ein ziemlich gutes Bild vom Spiel. Ich weiß wo was gemacht werden soll und wie gespielt wird. Auch weiß ich ungefähr was ich darstellen möchte.
Mein fertiges Konzept umfasst 8 Seiten und mein fertiges Diagramm schaut so aus:
Und ja: Es ist absichtlich so unscharf . Ich bin mir noch nicht sicher wieviel ich spoilern will und ob ich mein Konzept wirklich schon so früh komplett offen legen möchte.
Nun ja. Auf jeden Fall wirds dann weiter gehen in hacknplan ein neues Projekt mit den ersten Stories anzulegen.
Und es ist so toll. Dank dem Diagramm war es ein leichtes die ersten Stories zu erstellen! Klar sind diese noch viel zu groß und viel zu allgemein. Aber ich hab jetzt User-Stories auf denen ich aufbauen kann.
Die erste dreht sich z.B. um das Hauptmenü. Da kann ich mir jetzt sinnvoll zu Gedanken machen und einige kleinere Stories rausbrechen die ich dann angehen kann.
Vielleicht fang ich doch an mich grad drin zu verlieben ^^. Ich hab das Gefühl das Projekt jetzt wirklich sehr Zielstrebig angehen zu können. Und so ziemlich alle meine Gedanken zum Spiel hab ich im 8-Seitigen Konzept dokumentiert. D.h. wenn mir in ein paar Wochen nicht klar ist, warum ich damals was geplant hatte, dann kann ichs einfach nachlesen (und erneut bewerten). Momentan würd ichs auf jeden Fall weiterempfehlen .
Ich habe einige der Techniken hier im Forum mal nachgeschlagen und das kommt alles scheinbar aus den Ingenieurswissenschaften und mir sind die in der Informatik umbenannten Techniken auch als Ingenieurs-Begrifflichkeiten bekannt - Toyota ist auch 100 Jahre später noch DAS Vorzeigeunternehmen.
Aber nicht in der Form wie sie hier angewendet werden oder Wikipedia mir die 1:1 Verwandschaft weiß machen will.
Mir wird klar ich wurde darin ausgebildet ein Projekt zu leiten, nicht ein Teil eines Projektes zu sein.
Aber ich hab das Gefühl bis ich das in HackNPlan eingetippt und eingestellt habe, hab ich die Funktionalität in der gleichen Zeit bereits umgesetzt. Was bringt das einem? Wenn es gröber sein soll, dann setze ich lieber auf MS Project, aber es gibt eigentlich kein Team zu leiten.
Schicke jetzt erstmal eine Rundmail an mich selbst wie ich bis nächsten Montag erste Ergebnisse von mir erwarte
Hast du was dagegen mir dein UML mal in besserer Auflösung zu schicken per PN? Vielleicht kann ich daraus ja etwas lernen.
Ja, wenn ich mich so an die Scrum-Consultants richtig erinnere - dann stammt das alles von da. Wurde einfach adaptiert.
Das gilt für kleine Projekte welche in Ihrem Umfang sehr leicht zu überblicken sind. Zu beginn von Feature Runner hätte ich dir deshalb da auch recht gegeben. Nur Irgendwann hast du soviele Ideen und Aufgaben - dass du diese irgendwo niederschreiben musst. Und die Entwicklung hab ich schon durch:
Von Gedächtnis auf Post Its übertragen → Von Post Its dann umgestiegen auf ein Notizbuch (was am meisten Spaß gemacht hatte!) → von Notizbuch umgestiegen auf Trello → von Trello umgestiegen auf Hacknplan.
Und wenn du im Tagebuch von Feature Runner nachschaust: Hacknplan wurde da genannt (afair von Landei) und ich hielt es auch zunächst für übertrieben. Aber je mehr Aufgaben du erfasst - desto mehr benötigst du da eine Ordnung. Vor allem wenn die anfangen Abhängigkeiten zueinander zu bilden.
Jetzt hast du irgendwann dein Spiel öffentlich und musst regelmäßig releasen um deine Tester bei Laune zu halten. Aber releases wollen auch irgendwie geplant sein. Und hier hilft dir Hacknplan auch weiter, da du es dort einfach mit Milestones lösen kannst. Und du kannst auch mehr als einen gleichzeitig planen.
Irgendwann bin ich dann ja auch vom Schema einer Aufgabe umgestiegen auf User-Stories.
Du magst das vielleicht gerade müde belächeln (was ich verstehen kann, immerhin nutze ich Techniken die fürs Arbeiten im Team konzipiert sind) - aber mir hat das enorm geholfen! Deswegen beginne ich Industry City auch direkt unter Verwendung dieser Techniken.
Mir ist aufgefallen, dein Workflow Diagramm ist direkt mit der Oberfläche verknüpft und bildet nicht die Funktionsweise der unterliegenen Simulation ab. Ist das Absicht? Immer so? Oder Unity?
Feage deshalb weil ich konzentriere mich (versuche mich mit HackNPlan) selber auf die Simulation und Wechselwirkungen der Klassen und Pakete. Die GUI ist nur aufgegossen…
Die Frage ist sehr einfach zu beantworten: Es ist so weil es den Workflow aus reiner Nutzersicht beschreibt. Und der Nutzer kennt die technische Umsetzung nicht. Also ja, das ist Absicht und hat nichts mit Unity zu tun. Wie gesagt, mein Ziel von dem ganzen Prozess war es Stories zu erstellen. Und das Workflow-Diagramm hat seine Arbeit imho perfekt getan - denn alle „Zustände“ (praktisch fast gleichzusetzen mit Oberflächen) sind eine Story.
Vielleicht mal ein kleiner Exkurs in Scrum:
Du startest dein Projekt mit sehr großen Stories. Eine Story ist geschrieben nach dem Schema: „Als ein [Rolle] möchte ich [Funktion] damit ich [Vorteil der sich daraus ergibt].“. Am Beispiel eines Taschenrechners. „Als Anwender möchte ich einen Taschenrechner damit ich einfache Grundrechenarten berechnen kann“.
Hast du nun deine ersten Stories, dann geht es darum diese kleiner zu bekommen. Aus den Grundrechenarten könntest du jetzt 4 weitere Stories rausziehen: Eine jeweils für Plus, minus, mal und geteilt.
Normalerweise läuft das ganze ja als Team. Dann gehst du jede Story mind. 3x durch und erfasst dann noch so Rahmeninfos wie Akzeptanz-Kritierien. Irgendwann schätzt du die und dann wird der Sprint geplant.
Ich mach das nur zum Teil so. Ich hab jetzt meine größeren Stories und entsprechende Abhängigkeiten gesetzt. D.h. es kann eigentlich nichts laufen ohne das Hauptmenü. Dementsprechend werde ich damit auch anfangen. Ich werde jetzt weiter machen indem ich mir kleinere Stories da raus ziehe.
Ich sag mal so: Hacknplan stellt dir im groben erstmal ein Kanban-Board und eine recht gute Aufgabenerfassung. Auch wenn ich dir meinen Weg empfehlen kann - so ist er sicherlich nicht für jeden geeignet und sicherlich auch kein muss für Hacknplan. Wie gesagt: ist in erster Linie ein Kanban-board.
So. Gestern habe ich dann endlich mal richtig angefangen. Ich hab mir meine erste Story (Hauptmenü) gepackt und … hinten angestellt. Weil meine wirklich erste Story war „Sprint 0“. Hierbei geht es um Vorbereitung.
Also im wesentlichen das Setup machen. Ich habe das Projekt erstellt, eine Basis-struktur, die assemblies definiert, Rider eingerichtet und ein relativ großes Thema war: Git!
Vorher hab ich Collaborate von Unity verwendet und Git ist einfach besser. Nachdem ich einiges an Dokumentationen und Co. durchgelesen hab, glaub ich auch alles wichtige - und wirklich nur das wichtige eingecheckt zu haben.
Dann konnte ich auch den zurückgestellten Punkt „Hauptmenü“ wieder auskramen. Ersten Milestone erstellt und die Story reingepackt. Mir dann überlegt was ich alles brauche und insgesamt wurden daraus dann 6 einzelne Stories. Nachdem ich jetzt die hälfte abgearbeitet hab, hab ich auch schon meine ersten 2 IntegrationsTests (woohoo!) und auch schonmal ein „Ergebnis“ wo man sehen kann - wie das Menü später mal aussehen wird:
Btw. verwende ich gerade das erstemal eine neue Komponente: „TextMesh Pro“. Wurde wohl von Unity3d aufgekauft und steht jetzt in der Vollversion (glaube ich) allen komplett kostenlos zur Verfügung. Sollte hier einer auch mal mit Unity3D starten, klare Empfehlung: setzt euch mit auseinander. Es war echt nie einfacher mit Texten zu arbeiten
Es ist toll wenn man so langsam in der Denke von Unity3D drin ist und sein Werkzeug ein bisschen kennt. Ich habe bisher wenige Komponenten - die dafür aber jetzt schon öfters Wiederverwendet worden sind. Viel abgenommen haben mir Events welche als ScriptableObjects umgesetzt sind.
Z.B.: Navigation Hauptmenü → Einstellungen und wieder zurück. Dafür hätte ich früher einen UIManager angefangen + jeder Button hätte wohl seine eigene Klasse (was 3 klassen entspricht). Dank meiner Events hab ich für diese Navigation aber keinen extra Code gebraucht.
Gut, dass ich bei Feature Runner so viel mit der Architektur rumgespielt hab. Das hat sich echt gelohnt
Ich merke gerade: bei Feature Runner bin ich mit meinen ScriptableObjects (oder kurz: SO) nicht weit genug gegangen! Die Dinger sind einfach Klasse. So hatte ich bei Feature Runner meine Services nicht als SOs realisiert gehabt - sondern nur die Models. Es ist aber echt von Vorteil, so manchen Service auch als SO zu haben. Weil dann kann ich ganz einfach über den Insepector sagen: „Wenn EVENT XYZ dann nimm den SO-Service ABC und rufe darauf METHODE X auf“. Das erspart mir Code - was mir dann wieder Tests erspart.
Somit hab ich z.b. meinen GameManager schon jetzt vereinfachen können:
Was letztendlich das gleiche tut - nur sehr viel flexibler ist. Wenn ich jetzt andere Dinge zum Spielstart laden möchte, dann hänge die einfach dazu und der GameManager muss diese nicht direkt kennen. Das einzige was ich jetzt noch testen muss ist, dass das Event zum richtigen Zeitpunkt gefeuert wird. Fertig
.
hab mir die Links sogar angeschaut.
.
. Ich bin mir noch nicht sicher wieviel ich spoilern will und ob ich mein Konzept wirklich schon so früh komplett offen legen möchte.
