The Forge Before the Kingdom

Voordat ik kon beginnen met een brainstorm sessie, moest ik zogenoemde technieken kiezen. Ik was best onder de indruk van alle keuzes die mogelijk waren. Zodoende had ik geen idee wat ik moest kiezen. Uiteindelijk ben ik voor de Role Playing en de What if scenario’s technieken gegaan, gezien ik dacht dat deze twee een logische keuze was voor een experimentele PoC.

Ik vond het vroeger geweldig om die old school strategie games te spelen zoals, Warcraft I, II en III, de Command & Conquer series, Knights and Merchants en SpellForce I en II. Waar ik tegenwoordig de complexiteit van Factorio en het crafting systeem van de verlaten game Ashes of Creation als een gevoel van voldoening zie.

Dus ik begon de brainstorm sessie met Mary. Ik vertelde haar een kleine stelling dat ik een PoC wou maken met de invloed en inspiratie van de bovengenoemde games. Tot mijn verrassing werd het een gesprek met haar, waar ze vragen begon te stellen over hoe mijn ideeën tot stand moest komen binnen de grenzen van de PoC. Ik moet eerlijk zeggen, het was best een interessant gesprek waarin de diepere gevoel van de core game pilaren tot stand kwamen dat getoond moest worden binnen de PoC.

Uiteindelijk heeft Mary een samenvatting gemaakt over de twee sessies die ik had, waaronder een interactieve HTML pagina om de uitkomst van de sessie te visualiseren. Deze HTML pagina is als een artefact toegevoegd aan deze ontwikkel sessie.

Het volgende om te doen was het maken van een product brief dat de gemaakte brainstorm sessie omzet in een document waarbij de focus gelegd werd naar het doel dat binnen de brainstorm sessie gedefinieerd was. Ik wist niet zo goed wat ik hiervan moest verwachten, maar het bleek alleen een geautomatiseerde taak te zijn dat geen interventie nodig had van een mens gezien Mary dit heeft gedaan. Wat zij produceerde was eigenlijk een functionele design-achtige document waarbij de grenzen van de PoC, uitleg wie de stakeholders zijn en wat de basis spelerservaring moest zijn beschreven staan.

Ik kan me zo voorstellen dat dit document vele malen groter zal zijn wanneer het om een daadwerkelijke game zal gaan dat gebouwd moet worden.

De product brief is toegevoegd als artefact aan deze sessie.

Deze sessie was best interessant. John heeft een document gemaakt op basis van de brainstorm sessies en de product brief, dat de volledige visie bevat van de PoC. De features dat moet bestaan zijn beschreven als Function Requirements (FR) en de Non Function Requirements (NFR) die ik tevens kan gebruiken als test scenario’s. Daarnaast is de volledige scope gemaakt en tevens wat buiten de scope valt voor deze PoC.

Om antwoorden te krijgen was een beetje anders, John heeft eerst aannames gedaan waar hij dit kon doen. En waar hij dit niet kon doen heeft hij een aantal open vragen voor mij achtergelaten om te beantwoorden. Deze vragen traden al best in detail, zoals “Welke vergoeding moet een quest geven?” of “Hoelang moet de morele boost duren?”. Het is vrij logisch om zulke details helder te hebben voordat er begonnen wordt met de productie, maar de aantal vragen was best indrukwekkend.

Nadat de eerste opzet gedaan was heeft John de eerste twee documenten nog doorgelopen om te kijken of we iets gemist hadden. En hij vond er een paar.
Toen dit klaar was eindigde we met 19 FR’s en 6 NFR’s. Dat zijn er best wat voor een kleine PoC leek me 😊

Het uiteindelijke product requirements document is toegevoegd als artifact voor deze sessie.

Het genereren van de mockups voor de UI wat niet echt een interactieve sessie. Ook omdat ik denk dat de visuele gedeelte geen hoge prioriteit heeft wanneer de initiële PoC technisch gericht is. Dus Sally deed exact wat er verwacht werd. Ze heeft een strakke UI gemaakt wat goed genoeg is voor nu.

Maar ik vermoed dat deze stap best veel tijd gaat kosten wanneer het een echte game betreft gezien er zoveel aspecten zijn qua gebruikers ervaringen en de mockup die ze moet maken 😆

De mockups zijn toegevoegd aan deze sessie.

Om de Game Design Document (GDD) te genereren keek John naar de eerder gegenereerde Product Requirements Document (PRD) en vandaar uit werd de GDD gemaakt. Initieel dat deze twee documenten vergelijkbaar waren.

Blijkbaar had ik het verkeerd.. zal ook niet de eerste keer zijn 😇
De PRD definieert wat de PoC moet leveren en hoe we kunnen weten hoe we daaraan kunnen voldoen; De GDD definieert hoe het spelen daadwerkelijk wordt ervaren.

Voor deze PoC betekend dit:

• De PRD zegt dingen zoals “crafting duurt 30 seconden”, “de inventory heeft 10 sloten”, “de speler kan een zwaard hebben”, en “Tim moet kunnen uitleggen welke gevechtseffecten welke betekenis hebben.”. Dit zijn de Functionele Requirements (FR), de beperkingen en de acceptatie criteria.

• De GGD verbindt deze verplichtingen in een samenhangend spelerservaring: de fantasie, pilaren, moment op moment loop, eenheid controle, gevechtsregels, recepten, progressie, gevechtsontwerp, audio en visuele feedback.

• De architecture definieert later hoe Unity systemen geïmplementeerd moeten worden volgens het design.

Dus de flow is grofweg: PRD = vereiste resultaten en grenzen → GDD = gameplay-ontwerp → architecture = implementeert structuur.

De uiteindelijke GDD is toegevoegd aan deze sessie.

Wauw.. er zijn zoveel dingen gebeurd deze sessie. Winston was lekker bezig. De uiteindelijke architectuur bestand was best groot voor zo’n kleine PoC. Het bevat de grote core systemen uitgelegd, code conventies, implementatie patronen, testing/project structuur. En naast dat heeft hij tevens 96 regels gemaakt waar de architectuur aan moet voldoen.

Met regelmaat is het best verbluffend om te zien wat deze agents allemaal voor output genereren 🤯
Wanneer ik dit zo zie, ben ik best enthousiast over de daadwerkelijke implementatie van deze PoC.

Het architectuur en de project context documenten zijn toegevoegd als artefacten voor deze sessie.

Toen Winston klaar was, heeft er een verificatie taak gelopen dat alle bestanden en hun inhoud ging valideren, en het vond verbazingwekkend 31 problemen over de gehele linie. Ik denk dat ik met wat agents moet gaan praten om dit allemaal op te lossen.

John heeft alle epics problemen opgelost. Er mistte een aantal functional requirements dat geen epic was of niet werd benoemd in een van de epics.
Hij heeft tevens alle epics voorzien van stories.

Sally heeft een aantal zaken binnen de UI/UX design opgelost. Bleek dat er een hele verificatie proces bestaat voor de UI/US stroom, denk dat ik dat proces had moeten doorlopen wanneer Sally haar eerste UI/UX design had gemaakt 😅

En Winston heeft missende architect links opgelost. De review verwachte het architectuur bestand op een andere locatie dan dat waar deze stond.

Nadat de sprint planning gedaan was, was het eindelijk tijd om te starten met de implementatie.. tenminste dat dacht ik.. Ik vind het raar dat de eerste taak dat gedaan moet worden binnen de implementatie traject is het maken van een user story 🤨
Denk dat het logischer is dat deze actie gedaan wordt in de planningsfase. Maar goed.. wie ben ik?

Maar toen werd het realistisch.. ik ben door mijn rate limits gegaan. Dus dit project zal een paar dagen op zich moeten wachten.

Hoe een van de stories eruit ziet is toegevoegd aan deze sessie, deze is tevens bewerkt door de ontwikkelaar en reviewer met hun aantekeningen en bevindingen.

Na een periode van goed weer waar ik meer met astro fotografie bezig kon zijn was het weer tijd voor deze PoC. Ik had al alle stories voor de eerste epic gemaakt en Amelia is begonnen met de ontwikkeling van de eerste stories. Toen ze bezig was met de derde story had ze mijn hulp nodig. Wat zij gedaan heeft is dat ze eerste falende unit testen heeft gemaakt van de te implementeren feature, en waar ze me nodig voor had was om deze testen te draaien.

De limitatie hier was de kale Unity, gezien de test runner een nieuw proces start. Tenminste, dat is mij verteld.
? Ik vertrouw mijn ontwikkelaar.. 😇

Ik moet zeggen dat ik deze interactie ook wel prettig vindt. Op deze manier blijf je toch een beetje betrokken bij de ontwikkeling dan wanneer je AI alles zelf laat doen. Maar ik weet ook dat dit niet een efficiënte manier is van werken.