Mafia&Co: building 4 apps with the same architecture and code-sharing system

In the initial phase of working with the client, NERDZ LAB has:

• gathered all requirements
• analyzed all weak points
• examined all games systems entirely

Through these interactions and research, NERDZ LAB has identified the challenges we’ll describe below.

Architecture logic

As these are board games, they have complex sets of rules. Even a human sometimes finds it difficult to understand and calculate all game variations. It takes even more effort to transfer all those rules, logical jumps, and edge-case situations into the code language.

This was of great importance because the architecture is supposed to be appropriately structured, seamlessly scalable, and easily understood.

Live game updates

Since these are online games, any player’s action is supposed to transfer to other players. Additionally, every player’s game flow may react in different ways, depending on their role.

Besides the architectural complexity where the online game should respond to players’ actions, there’s another difficulty: reactions to internet lags and processing game interruptions.

This includes concerns relating to:

• How the games should behave if somebody has already been notified about a completed action (for instance, if the Mafia has made its choice), and the other player still has some game delays;
• How the games should behave if somebody has the internet switched off;
• How the game should behave in Race Condition – when the system should first choose event A (the Mafia has made its step) then event B (the selection of who the Mafia is), but due to the latency of event A delivery, event B has come earlier.

In all these cases, a system should react precisely and allow the players to play the games in the correct order.

Single controlling system

All 4 games have similar mechanics: nobody knows each other’s roles, and you need to unveil the Impostor; meanwhile, the Impostor is supposed to stay alive.

To reflect this unity and avoid duplication of the same logic across the 4 systems (and therefore, code redundancy), we needed to build an architecture that would share one code across all 4 applications. Any change of logic for one game would indirectly influence all four.

At the same time, we had to separate differences from this shared code system so that they wouldn’t be affected by changes made. In this way, the differences should stay unique.

This point is critical for time efficiency and to reduce system errors. It means that we write the code only once, and it’s automatically shared across all 4 games, which:

• cuts time for app development and solution deployment;
• reduces the possibility that in separate applications, the flow works differently.