I start building a .Net application from scratch. This video focuses on planning and setup for the project, creating a GitHub repository, and setting up the development environment.
I spend the hour capturing requirements for the townsfolk generator application. I discuss functional and technical requirements, we even identify some possible code-level entities, while working through the cards in the Github Project.
Architecting a software system involves analyzing requirements, focusing on volatility, and creating reusable components to avoid future code changes. I talk through these concepts while I identify the main ideas we’ll be coding later.
This afternoon I created a simple architecture diagram and set up the .NET solution and its projects in VS Code. While creating the diagram, I talked about the importance of closed architectures, and the five archetypal components we usually deal with in software development.
This morning, I set up project references in C# and dotNet, documented component dependencies, and created contracts for the dice engine in our MVP project.
This afternoon I spent the hour creating a dice rolling component in C# with testing and contract design. I also talked about test-first development and interface implementation.
This morning, I filled in the tests I identified yesterday, and started building the actual Roll() method on the DiceBag class. Things went well until one of my tests revealed a flaw in my component’s design. I was able to quickly correct that mistake, and get back in the groove with minimal pain.
This afternoon I improved the test class for the DiceBag. I parameterized the tests, and added a special “TestCaseGenerator” class that creates many combinations of data that I could pass to the DiceBag, allowing me to get much better coverage of many of the possible cases I might encounter. Sweet!
This morning, I described and then added a couple more tests that we can use to validate the next change to the DiceBag component. We want to optionally provide adjustments that are applied to the dice roll, and between the tests and the needed code changes, we got it done!
This afternoon I “improved” the tests we created this morning, allowing variable permutations of Dice, DiceCount, Modifiers, and runs per permutation. Unfortunately, I mistyped a loop definition and almost got pulled into a black hole. It’s ok. I fixed it, and now it’s working nicely.
This morning, I started the last few unit tests we’d need to prove that we can roll with Advantage or Disadvantage. I got those working in the component, and made plans to finish up the DiceEngine in the afternoon.
This afternoon I added the last couple tests, giving them parameters and making sure they don’t run extra iterations needlessly. The DiceEngine is done, committed, and pulled into the main branch up in GitHub. I then started adding a simple console application that exposes the DiceRolling capability as its own thing.
This afternoon I started sketching the Detailed Design for the TownsfolkManager and its artifacts. I talked through the particulars of the Domain Problem, but the steps I took can apply to any software development project.
This morning, I added a couple more classes to the GameTools.Framework library, then brought them in as properties on my Townsfolk class. Once that was done, I started thinking about Choosing the Species for my NPC, and began exploring the concepts of RuleSets.
This afternoon I talked briefly about circular references and dependencies, and then continued exploring the Ruleset concept, iterating and experimenting with different ways of organizing the code within those .Net projects. After a short period of time, I landed on a strategy for this, and got things buildable again. Tomorrow, we explore Dependency Management.
This morning, I talked a little bit about Inversion of Control, the Dependency Inversion Principle, and Dependency Injection. I then refactored the console application to support manual dependency injection and made changes to the TownsfolkManager class to allow me to pass instances of worker components into it. Then I got tangled up in my own abstractions.
This afternoon I backed up a little and talked about some of the common pitfalls we run into when developing small parts of large ideas. I then refocused on only the pieces I need to get going today for the NPC generator, instead of letting myself get distracted by unplanned use cases. I finally got everything slotted together with a little help from .Net’s reflection capabilities.
I have the NPC’s Species getting picked at random now! I had to implement a new Randomizer utility that simulates shuffling some cards and picking one, but that was a snap because of the way we have the solution organized. No more hard-coded Elveses!
I replaced the manual Dependency Injection I’d originally used in the Console app with the “official” DI package from Microsoft. Then, I was able to apply the same concepts I did for the Species lists to Backgrounds. (It was WAY faster this time!)
This morning, I decided I needed to clean up the output so that it’s a bit (a LOT) easier to read on the console. This led to creating what I call a Utility Framework library, where I’ll put all the gooey low-level stuff that I’ll need to use throughout this application (and others…) The back half of the video is me getting started on customizing the JSON serialization and formatting.
I spent the whole darn session getting the Serialization working just right. I don’t spend a ton of time directly manipulating json, so this wasn’t a smooth development session at all, but I eventually got it figured out, and now have a MUCH cleaner output. So much cleaner that I can paste the simple JSON into a ChatGPT window with some instructions, and it gives me back a basic description of an NPC.
After yesterday’s success with tidying the output from the NPC Generator, my Project Manager (me, it’s one of the voices in my head,) told me to pivot to adding AI generation capabilities NOW, instead of waiting for all the Ruleset work to be done. The planning I did during the first few videos meant that I could make that pivot without tears. This video shows me adjust the Static Architecture for the application, and start adding in the .Net projects that will let me add AI without altering anything I’ve done already.
This afternoon, I focused on adding the Access component that will let me call a Language Model from my application. I built that, a Manager to act as the “front end” of the AI Subsystem, and integrated this into the main application. I was able to run the console app, and see that the LLM is responding to the hard-coded prompt I’d used as a test.
This morning, I got the AI to accept the JSON object with the basic NPC information in it and return a pretty good looking description. Problem is, it leaks D&D details into my AI Subsystem, and we dont’ want that.
This afternoon, I on making the AI portion of the system more reuseable, and getting ready to pull all the domain specific code out of it. I ALMOST got to the finish line, and will complete that part tomorrow morning.
This morning, I cleaned up the AI subsystem, getting all of the D&D stuff out of there, and back into the area of the solution where it belongs.
I focus on some User Experience improvements by splitting the process of generating an NPC into two parts: Getting and Displaying the Random Attributes, and then prompting the user to opt in to generating a Text Description using the AI Components. Then I started adding in a way to let me choose the Species of my NPC, rather than leaving everything to chance.
This morning, I finished adding the code to let me choose from the list of Species when generating an NPC. Getting incrementally better each session! Adding the choices for Background and Vocation was going to be more of the same, so I did that work offline.
This afternoon, I worked on the internal code that applies the selected Species, Background, and Vocation to an NPC. It was a bit of a struggle, and I fell down a bit of a rabbit hole, but I did catch myself and backed out to a simpler solution just before the end of my time.
This morning, I added gender and pronouns to the species templates, with room for customization of each species within a Ruleset if desired. I then got those template attributes applied to the Character being created. (I currently plan to leave this part random, at least while we’re still dealing with a Console Application.)
This afternoon was a long one. I started off by explaining how I use a GPT service to read, analyze, and quickly research aspects of the Character Creation solution domain from the D&D 5e SRD. Then, I added SpeciesTemplate properties to handle getting the height, weight, and age for the different Character Species. Finally, I got those template attributes applied in the TownsfolkManager by adding more code to the ApplySpecies method of the TemplateWorker class.
In this stream, I brainstormed as many “missing things” as I could, and made notes. Then I put the high priority missing things on a new slide, grouped them, and talked through the order in which I should get them done. Looks like getting some more tests in place, and then automation is the order of the day.
I got started setting up some automated Contract Tests for the TownsfolkManager component. I didn’t get too far, because the product I used last time I needed to to this is no longer supported for new versions of .Net. It’s alright though, I found a replacement and…
I was able to get the first batch of Feature Scenarios generated into Step methods. I added some Mocked Dependencies, and ran into a problem because some of those dependencies are inherited from Base Classes, rather than Implemented from Interfaces, and you can’t mock base classes.
I got the attempts to mock base classes turned into “Fake” child classes and was able to get the first Scenario test passing. Then, I started looking into running my tests outside of Visual Studio, in particular, getting some good, useful output from them so I can start adding automations. More homework to do on that front, so we’ll return tomorrow and start making things happen as if by magic!
Wednesday night, I got the app prototype running on my MacBook (Yes, WITH the local AI!!!) and took it with me to D&D night so I could show off to some other local DMs. Of course I ran into edge cases that crash the app, so this morning, I talked mostly about defects, accountability, and how I intend to prevent these kinds of things goig forward. Am I going to ELIMINATE getting egg on my face? Of course not, but there are some things I can do to protect myself from myself. ;)
Automation means DevOps, and DevOps means getting out of my comfort zone. Yeah, this was not a fun stream for me. YAML and Shell Scripts and no useful debugging tools beyond log files? No thanks. I’ll do it if I have to, but I doubt I’ll ever ENJOY it. (I did eventually get it working, after much head scratching and cursing.)
This morning, I was able to demonstrate the Automated Build & Test Github Workflow, and of course it failed because of the same letter case mismatch problem. Bright side? I know how to fix it, and demonstrated that. I show a cool local utility I found that gives me a Test Coverage report that I’ll use to keep myself honest, and wrapped up for the morning.
Making y’all watch me adding tests to the solution for the next bunch of sessons would be boring as heck. Imma do that offline, and share the results on Monday. This afternoon, WE ADDED A UI PROJECT after discussing my tech choice, and why. (Blazor means I can mostly stay in .Net & C#, with only minimal JavaScript.)
Added the dependency injection I needed to be able to get the basic NPC attributes from the Townsfolk Manager into the Blazor UI. It ain’t pretty, but it works. I also added a button to generate new NPC attributes on demand.
I discuss and implement a simple example of the Model-View-ViewModel (MVVM) pattern. We’re going to be using this a lot, but I’m starting off SUPER SIMPLE, and working iteratively. My goal is to make slow, but steady progress through the UI work. It’s been awhile for me.
This morning, I added another button to take the basic NPC data the system generates and get the AI Description, just like we did in the Console App. Again, first pass is ugly, but I’ll work on getting it prettier as we go.
Pushing the AI button makes it feel like the application freezes, because there’s not indication that it’s actually doing anything. I started implementing a “loading” overlay for the interactive part of the app, but it was being WAY harder than I thought it’d be.
I demonstrated the working “Loading” overlay, and discussed that the AI output really wasn’t well suited for display as-is. I redesigned the way the AI parts will be held in memory, and started modifying the ViewModel and code behind it. This is in prepartaion for changing the way the AI returns the output.
I finished the adjustments to the ViewModel and its support classes, and then moved onto getting the LM prompt template adjusted to return JSON instead of plain text. GenAI models can be stubborn, and sometimes do things we dont’ want them to do.
More prompt engineering during this video. I eventually decided to add a string manipulation function to rip the markdown code fences the Language Model is adding despite my best efforts at telling it not to. By the end of the video, I had the AI generated NPC atrributes displaying in a way that I’m MUCH happier with.
I planned to start adding some drop downs with selectable options for the initial NPC generation and discovered that I was painting myself into a corner, so stepped back and started some actual UI Component design, rather than just adding MOAR CODE!!!! I’ll finish my design thinking and note taking this evening, and talk through the plan I make in the next video.
In this session, I focus mostly on how to break apart the UI for the NPC Creator into smaller, easier to think about and develop components, starting with a View Attributes component.
I got the View Attributes component added to the new create-npc page, and plumbed out to the backend Generation services. I add the button that calls the language model to the View Attributes component, and got it rendering as I want it to.
In this session, I started out with a user options component that wasn’t rendering, so I had to take a step back, and start from bare minimum. I got a heading to render, then I got a select list added and populated from the actual collection of Species. I left off there, intending to finish that up in the afternoon session.
This session saw me finish adding the other user selectable NPC options to the UI and the UI Control code. I got those selections going to the request to Generate an NPC, and coming back as NPC attributes. Then I spent some time wrkign on styling, using Bootstrap classes.