Anti cheat measures in Lumberyard/AWS game tech


Is Lumberyard/AWS game tech inherently prepared with anti-cheat features or does security mainly depends on the developer’s security, networking, session management, etc skills?

Can you please give advice, examples on good practices for multiplayer projects on AWS game tech infra?


Thats a big open question as so much depends on how your game is structured/designed etc and also what “anti-cheat” means to you and your game.

  • Does this mean mechanisms to report and block cheaters?
  • Is it to detect and block aim bots?
  • Is it to ensure server side authoritative correction of modified client data? ie lag compensation

As AWS doesn’t offer a games as service platform (ie a 1 size fits all approach to running games in the cloud) theres no central point for this type of technology, you have to decide what matters to you and your game. Even GameLift (server hosting in the cloud) does not interface at the level in which any latency/lag/position compensation is modeled.

There are some links to examples here: about how some companies have built “anti-cheat” like features on AWS.

Much of what you need is not specific to AWS but obviously you could use AWS to help with some of it (ie theres probably some really cool ML based cheat detection things folks have built).

I will see if theres anything publicly available about what Crucible did (as they may have written things up about their approach here) and ask around to see if there are other anti-cheat/designing multiplayer game guides for AWS that I don’t know about.

1 Like

I’m sorry for this too broad and open question. I’m new to server programming and security and probably asked too soon. But huge thanks to you that you still gave some concrete stuff for me to chew on. :slight_smile: looks like a lot of useful reading.

In my case the game is not a shooter, but a deck builder/turn based strategy. So i think my game doesn’t have to handle the probably most difficult cheats like aimbots and lag related manipulations.

You wrote this in your reply for another question of mine in a different thread:

For mutliplayer, typically you don’t trust the client, they make requests to the server and it maintains state and decides if it should ‘honor’ the request.

My intial idea is that:

  1. The beginning of each match the server would:

    • validate the decks from each player and store it in server-side state,
    • then generate a randomized list of them, and update clients with card lists with the first X visible cards for them.
  2. After this when the current player performs an action with a unit, the client would send a request to the server and the server would:

    • validate the request (whether a given action is issuable with the selected unit, does the current position and stats of selected unit match with the stored state on server, etc)
    • if the request deemed valid:
      • it updates server side state for current player
      • modify server side state of the other player
      • sends update to the client of the other player
  3. Similarly in case of card draw(s), at the beginning of a new turn or during the given turn the client would send a request to the server and server would:

    • validate request (like if current player can check/draw multiple cards in the queue, etc) if the request is valid then:
      • update card queue and played card list on server side
      • update hand list on client side

This is roughly the idea. With my current understanding, this solution has to be cheat proof. Of course i can easily be wrong, so any comment on pointing out missing key element or flaw in this design is highly appreciated.

Looking forward to that as well, thanks!

As an infrastructure for Multiplayer products, you can check out the AWS GameLift.

Yea, thanks! Im aware of it.

1 Like