The Forge Before the Kingdom

Before I could start with the brainstorming session I had to pick so called techniques. I was quite overwhelmed with all the possibilities.. I had no idea what to pick. So I went for the Role Playing and the What if scenario’s techniques, since I thought if would make sense within this experimental PoC.

I used to love playing those old school strategy games like, Warcraft I, II and III, Command & Conquer series, Knights And Merchants and SpellForce I and II. Where nowadays the complexity of Factorio and the crafting system in the sadly abandon game Ashes of Creation really gives that sense of accomplishment.

So I started the brainstorming session with Mary. I told her a small statement that I wanted to see a PoC with the influence and inspiration of the above games. To my surprise it became a conversation with the her, where she started asking questions on how my plans would be executed and what was expected to happen within the PoC boundaries. I must say, it became quite an interesting conversation with a much deeper sense of the core game pillars to be shown within the PoC.

In the end Mary even wrapped up the two sessions I had, with an interactive HTML page (amongst others) to visually show what the sessions outcome was. This HTML is added as an artifact to this development session.

So the next thing to do was to create a product brief that turns the brainstorm session into a document with a focused aim of pursuing the goal the brainstorm set. I wasn’t really sure what to expect, but it turned out, this was just an automated task that didn’t need any human interaction as Mary did all this. She produced a functional design like document that fully scoped out the PoC, explaining who the stakeholders are and what the core player experience should become.

I would imaging such document would be quite huge when an actual game would be build.

The product brief has been added as artifact to this session.

Getting answers from me was a bit different, John first made assumptions where he could. And if he couldn’t he left a bunch of open questions for me to answer. Those questions were quite in the detail already, like “What rewards should the quests give?” or “How long should the morale bonus be active?”. It makes sense to know those details before production, but the amount of such questions was quite impressive.

After the initial draft was completed, John cross-referenced the original input to see if ideas or constraints were dropped. And he found a couple.
When all this was done, we ended up with 19 FR’s and 6 NFR’s. Thats quite decent for a small PoC i would say 😊

The final product requirements document is added as an artifact for this session.

Generating the mockups for the UI was not quite an interactive session, mainly because I don’t think the visuals has a high priority for a PoC when the main goal of the initial PoC is fully technical. So Sally did exactly what was expected. She made a clean UI that’s good enough for now.

But this step would take so much more time when this would be a real game since there would be so many different user experiences she has to deal with and mockups to create 😆

The mockups are added to this session.

To generate the Game Design Document (GDD) John pulled the previous build Product Requirements Document (PRD) and made the GDD out of it. What I initially thought those two are similar.

I guess I was wrong.. wouldn’t be the first time 😇
The PRD defines what the PoC must deliver and how we know it satisfies its purpose; the GDD defines what playing it is actually like.

For this Poc it means:

• The PRD says things like “crafting takes 30 seconds”, “inventory has 10 slots”, “the player can equip a sword”, and “Tim must be able to explain its combat effect.” Those are functional requirements, constraints, and acceptance signals.

• The GDD connects those requirements into a coherent player experience: the fantasy, pillars, moment-to-moment loop, unit control, combat rules, recipes, progression, encounter layout, visual/audio feedback.

• Architecture later defines how Unity systems implement that design.

So the chain is roughly: PRD = required outcomes and boundaries → GDD = gameplay design → architecture = implementation structure.

John also made a first setup of the epics layout for production.

The final GDD and the development epids are added to this session.

Wow.. a lot of stuff just happened during this session. Winston was on a roll. The final architecture file was quite big for such a small PoC. It contains the major core systems explained, coding conventions, implementation patterns, testing/project structure. Besides that he make 96 rules that applies to the architecture.

At times its quite mind blowing what the output is these agents generate 🤯
When i see this, im quite excited on the actual implementation of this PoC.

The architecture and the project context documents are added as artifacts for this session.

After Winston was done, a verification job was run that validated all the files and its content, and it found a staggering 31 issues across the whole line. Guess I need to talk to some agents to get this fixed.

John fixed all the development epics. There were some missing functional requirements that didn’t turned into or wasn’t covered in the epics.
He also made the stories underneath the epics.

Sally fixed from misalignments within the UI/UX designs. It turns out there is a whole validation process for the UI/UX, guess I should have run that after Sally made the UI/UX after the first session 😅

And Winston fixed the missing architecture links. The review was expecting the architecture document on a different place.

After the spint planning was completed it was finally time to start with the implementation.. or so I though.. I find it strange that the first task that needs to be done in the implementation progress is to create a user story 🤨
Think it would make more sense that this action was setup during the planning phase. But yeah.. who am I?

But then reality hits.. I hit my rate limits. So guess this project is on a hold for a couple of days.

How one of the stories looks like is added to this session, this is also edited by the developer and reviewer with their notes and findings.

After some nice weather where I was doing more with astrophotography, it was time to work on the PoC again. I already made dev stories for the first epic, and Amelia started developing the first stories. When she reached the third story she needed my help for some reason. What she did here was to make failing unit tests first before implementing the feature, where she needed me to actually run the test runner and report back the results of those tests.

The limitation here is the out of the box Unity, since the test runner would start another editor process. So I’ve been told.
I do trust my developer.. 😇

I must say, that I do like this kind of interaction. It does give you some sense of doing something then to let AI do all development. But I know its not that efficient like this..