Mafia -1: A Serverless Multiplayer Game

Jackson Bowe
4 min readJun 8, 2022

This is the first post (of hopefully many) where I will be documenting my journey creating a serverless multiplayer game; Mafia (name not final… unless???).

I’m going to use this first post to cover the tools I intend to use and give a general idea of what this game should look like at the end. So here we go…

What is this? A quick summary:

I’m basing this game heavily on the popular table top game by the same name. It’s a social deduction game in which a majority team, the Townies, try to root out the opposing minority team, the Mafia.

This is where the “Social Deduction” aspects comes in. If a player is a member of the minority Mafia team they are allowed to see which other players are on their team. However the Townies know only that they are good and must deduce the intentions of all other players.

Mechanics

The game isn’t strictly turn based however it follows a similar principle in that there are two main states, Day and Night.

During the Day all members of the town (inclusive of the mafia members) gather to discuss what leads they have found on the Mafia. At this time they may also decide to remove a player under suspicion of being a member of the Mafia.

During the Night, the Mafia collude to kill off a member of the Town. Also, certain members of the Town can perform actions like “Follow target player tonight” or “Inspect role” etc.

Enough with the nerd stuff, tell me about the tech stack!

Heavy sarcasm :)

Tools I’m using to make this

I want the game to be playable in the web browser at this stage, although that may change in future. Also primarily using AWS for the backend.

Backend

Frontend

Open disclaimer: I am not a front end developer. Or backend…

Currently I’m making the front end with Quasar Framework — a Vue.js wrapper. It seems like a good idea based on my skill level right now. I don’t know a whole lot of Javascript or Vue, or anything about web development (but how hard can it be?).

Main reason I’m using Quasar is because it comes with a bunch of prebuilt components and really easy to follow documentation. It also lets me use the same codebase to deploy to the web and a standalone executable. This sparks joy.

The glue

I’ve named the individual backend services and frontend framework, but they’re essentially useless without a way to seamlessly integrate them together. That’s where Serverless Stack (SST) comes in.

SST is a cloud architecture development kit that lets you provision AWS Infrastructure as Code (IaC) by leveraging the base AWS CDK with improvements geared towards serverless applications.

If you’ve used any IaS providers in the past like Terraform, AWS CDK, Serverless, SAM etc I seriously recommend checking out SST. It’s next level.

Proposed backend architecture

I’ve spent a substantial amount of time trying to define exactly what “access patterns” I need for this game to work. Being serverless I’m somewhat limited by not being able to have persistent data.

My brain naturally gravitates to a web of services that are all decoupled from each other and very atomic. By that I mean I want to structure my code in such a way that it doesn’t depend on anything outside of it’s own scope.

This approach also plays nice with the structure of AWS Lambda functions, it’s just a case of how many Lambda functions should I have. Where do I draw the line? Should Lambda’s serve a single function, or a group of similar functions? I’m still not sure but I’ve committed to something and hopefully it work out.

Introducing: Lambda ‘Controllers’

Controllers is the term I’m giving to the branches in a typical Microservice setup. I didn’t want to use ‘Services’ because AWS uses that name for their things and my brain was melting.

Controllers are responsible for groups of actions pertaining to a particular resource. For example, the AuthController might control all actions relating to user authentication eg. registration/login/recovery/etc.

There’s a number of Controllers I can forsee needing now, but I’m sure more will work their way in once the project started getting more complicated. Some examples:

  • AuthController — handles registration/login/recovery/etc
  • ChatController — handles chat messages broadcast/lobby/private/etc
  • LobbyController — handles create/join/leave/etc
  • UserController
  • GameController??
  • YouGetThePointController

Depending on their requirements, Controllers can be given read/write access to the database. At this point there is no plan for Controllers to ever need to interact with each other, so if that changes in the future I’ll figure it out then I guess…

Proposed frontend architecture

I don’t know aye. I’m not a JS/Vue/Web developer so I’m planning to just “figure it out in production”.

Conclusion

I don’t particularly want this series to be a generic game “devlog” thing. The real motivation behind this project was to get familiar with serverless cloud development and I think it’s going to be a massive learning opportunity.

What I’m more interested in writing about is showing how I’ve implemented some serverless feature and provide a legitimate use case that it fulfills.

If this project sounds interesting I’d love to hear from you, especially if you see me running headlong into a classic pitfall.

Note: I’m keeping somewhat-up-to-date technical documentation for the project at https://mafia-sdg.netlify.app/.

Thanks for reading :)

--

--

Jackson Bowe

Software Engineer deep diving into serverless cloud architecture