
ToolUp Tuesday - #6
Chris and Matt bring their game application components together in this ToolUp Tuesday session. They start by reviewing the existing services — the Go-based player decisions API and the .NET world event engine — and identify that the player state service may be redundant now that Dapr handles state management. After clarifying their data model through use case documentation in Markdown, they define the game loop: players enroll, world events fire on a tick schedule, players submit decisions, and the engine reconciles state. The bulk of the session focuses on integrating Dapr’s state management API into the .NET player state service, implementing save, get, and delete state operations backed by Azure Table Storage. They also tackle VS Code debugging configuration, setting up launch.json and tasks.json for multi-service debugging with Dapr sidecars. The session ends with inter-service communication via Dapr working, setting up the next episode for cross-service calls between Go and .NET.
Related Content

ToolUp Tuesday - #5
Chris and Matt refactor their Go player decisions API, restructuring packages and project layout. They compare the Gin and Gorilla Mux HTTP frameworks, explore Go interfaces and dependency injection patterns, and discuss unit testing and mocking strategies in Go.

ToolUp Tuesday - #4
Chris and Matt dive into Go (Golang) for the first time on stream, building a player decisions REST API for their game project. They explore Go fundamentals including structs, pointers, packages, and the Gin HTTP framework while comparing Go patterns to C# and .NET conventions.

ToolUp Tuesday - #3
Chris and Matt build the world events engine in .NET, connecting it to the Player State models via project references. They design a state machine architecture for the game engine, discuss action points as a game mechanic, and plan the player decisions API in Go for the next episode.