Building a Boardgame in Azure

This blog post is part one of what I expect is going to be a large series. It’s my opportunity to build stuff in the Azure Cloud while ending up with a cool online playable game. It’s a board game, played against others. The game is not even half-way finished and I don’t know when it’s going to be finished. I don’t want to spend all my spare time. In this series, I will blog about my progress, how I designed the game from an architectural perspective, and how I solved problems as a (C#) developer.

The game plan

The plan is to build an online board game that can be played with four players. I want to host the system and persist all data in the Azure cloud. I pretty much know what I’m doing in Angular, so that’s going the be my front-end system. My backend system is going to be written in C#, but since the architecture is not complete yet I don’t know for sure which services I’m actually going to use. Part of building this game is using and getting familiar with Cloud Services in Azure so we’re definitely going to touch those and use services as required. I’m using a personal budget for this project so keeping the costs as low as possible is a must.

The game itself

The game itself is a Parcheesi like game. There’s a board with pawns that move from a start position to a finish position. The player who first brings all the pawns to the finish position wins. That’s Parcheesi in short. This game is a little bit different. This game (which actually exists by the way) is called Kees and is played in teams. Players on the same team sit across the table from each other. Also, the dice are removed. We’re using playing cards instead. Each card has it’s own power. And of course, there are a couple of more rules, which will be handled in a later stage.

Technical requirements for players

To allow as many people to play the game as possible, I need to have the least technical requirements as possible. For now, it seems as I can get is done in the browser, so let’s go for the latest version of Chrome, Edge, Firefox and / or Safari for now.

Functional requirements

The system must be resilient and thus handle outages well. The game must scale enough to handle larger traffic in case required. The system must be very maintainable. A CI/CD pipeline is mandatory. Each feature finished in the development environment will be deployed to test & production automatically. This also brings us to the infrastructure, which will be deployed using Azure’s native ARM template.

Security

Users will identify themselves using an identity provider, probably Azure AD, Auth0, or something like that. I think I will expose one API which can be called from the front-end system. I don’t know if it’s actually going to be a single API, or maybe more and use API Management there. Also, it may be a good idea to put all resources that don’t need to be exposed in a VNet. I have the least experience there, so that’s going to fun.

The idea on my mind

Architecture Plan Now what I have in mind for now, and be careful this is really subject to change is the following. I’m going to write an ASP.NET Core Web API, which will be called from the front-end system. Authentication and authorization will be checked and validated there. Also, this API will be able to read from persistence. So querying materialized views will be its thing. This API will also handle creation and update operation requests but doesn’t handle the operations itself. So I’m basically thinking of a CQRS-ish solution where commands (or messages if you like) are sent to a messaging system after validation. An Azure Functions project will watch topics and / or queues and handle operations. This Azure Functions project will also update the materialized views served by the Web API.

Caching

I also may need some sort of caching. Basically on the materialized views. I’ll probably spin up a Redis Cache system for now and store the views for x time and fetch the views from persistence if not available in the cache.

Security

I’m familiar with Auth0 as a login provider, so I’ll probably go for that. Although I do need some stuff to learn, so it may be a good idea to move to Azure AD. The VNet part is going to be implemented when stuff is sort of running.

The awesome experience

To make the user experience best for players, I need the SignalR Service so I can update player views when something happened. Basically, the game is a turn-based game, so if other players make a move, you still want to be updated on what happened instead of having to refresh over and over again.

Step by step

Since I didn’t open-source this project (yet) and I don’t expect any PR’s from the community, I didn’t build a backlog. Steps to take are pretty much on my mind and the paperwork is just way too much for now because I’ll never be writing code if I do maintain a backlog and task progress.

Step one

The first step is going to be creating a project structure and be able to run the API and maybe also the Functions project in Azure. This means adding projects to a solution, adding test projects so I can actually test stuff, provision the infra using ARM, and deploy everything to Azure.

Step two

Step two is going to be allowing users to log in (and / or register). I don’t really want a registration page. Just log in using any well-known provider and you’re good to go. Also, I want users to be able to log out.

Step three

This is going to be a step in which you can invite other players to become friends. I don’t want any player data out in the open, so I’ll generate some sort of code, let’s call it a ‘Friend ID’, which you can use to invite friends and receive friendship invitations. A friendship request has to be accepted. And once a new game is started, the user can choose which friends to play with. This means that at the beginning, you can only create and play a new game if you have three friends. The game is played using a fixed amount of four players, so that’s you and three friends.

Step four

Start thinking of gameplay…. not there yet…

Last modified on 2020-06-25