I am currently planning a new project. It is a card game. Users can collect cards a play against others. I started thinking about how an architecture could look.

I am a .NET fan and will use C# as my language. I also want to use Azure as my backend.

I am curious, how you would split client and backend stuff?

Would you put the whole logic (even playing rules) in the backend? That way the whole game would work as an API, different client platforms would be very thin since they only Need to wrap the API and implement the UI. Or would you only put the User specific stuff (login, Personal card deck,...) in the backend and implement the game rules on Client side. This makes the backend less complex and would create less traffic for the clients.

In addition to this I want to start with an offline POC. Do I need to consider something special or will all my NET classes be reusable in Azure later on?

  • 1
    Both? Think of a FPS game: the client has all necessary logic (game mechanics) and sends updates to the server. The server validates this against its own rules (still the same game mechanics). They probably differ in (part of) their implementations, though. Also, you could spin a local server in offline mode - that's what Quake 3 did IIRC. – user44761 Aug 15 '17 at 7:03

I would think about what needs to be synchronized in each case. If the logic is in the front end, then you have to synchronize the logic between 2 (or more) players. What happens when there are network issues and one player doesn't update? Now you have invalid state on one device. How do you detect that, and how do you correct it? If you can detect it, how do you determine which device is wrong? If the logic all happens on the server, then worst case, the UI on one device is wrong while there are network problems, but it is updated as soon as the network is back up.

Also, things that are on the server are less likely to be hacked for cheating. If my device is sending information like my score, or my abilities, then I might be able to hack my device to send incorrect information that gives me an advantage. But if the server makes those decisions, then it's that much harder to cheat (at least in that way).

I've not used Azure so I'm not qualified to answer questions about that.


I believe that logic needs to be in sync in both back and front end, however backend is more important. Imagine the scenario in which rogue user would fake requests to your server (using cards he doesn't have, using more than 1 card per turn, reading oponents card etc.) you would need this to be recognized and forbidden on backend.

However you'd need some parts of game logic on front-end to show user when their actions are not allowed without checking with server on every turn. This lowers traffic to backend and makes game experience smoother as user doesn't have to wait if he'd done correct turn.

As for online vs offline stuff, you'd need to consider things like lags in communications, player drop-offs, unreceived messages and maybe even security problems (encrypting messages). This might require building another thin layer on backend and frontend which will handle these kinds of problems, but other than that it should work the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.