All blogs / Architecture of building a tournament for game playing agents

Architecture of building a tournament for game playing agents

May 16, 2021 • Matthew Duong • Engineering • 1 minutes

Architecture of building a tournament for game playing agents


I built a game playing agent tournament. To give some context this wasn't entirely from scratch. I had the benefit of learning from the previous tournament which had a few flaws.

December 2020 tournament


The previous tournament was written in python3 with the rough architecture above. It worked roughly like the following:

  1. A participant would write their agents in python3. They would implement a get_action function which the game would call each tick. The function would pass in game_state as a parameter and participants could do computation on that to evaluate what would make a good move.
  2. These would run as a python subprocess for some level of isolation.

v2 architecture


The main problems with this design:

  1. Fair resource allocation between agents since the agents and game ran in the same process.
  2. Lack of support for other languages.
  3. Lack of similarity between tournament and dev environments. Participants were unsure of how
  4. Participants had to send in requests for specific libraries to be included on the production tournament environment running machine (eg. pandas / numpy).

April 2021 tournament


The new ran three docker containers; one for each of the agents + game server and the communication channel was over websockets. The webapp / game ui also connected and served as a visual and debugging aid for the game.

v2 architecture

The new iteration was designed with the previous considerations in mind:

  1. With complete isolation of resources one agent spinning up too much CPU would have no impact on the other agent. It would also prevent issues where an agent would slow down the game.
  2. Any language that can be run in a Linux host could now be run in a docker container.
  3. Exact CPU count + memory allocation could be defined for containers and since the submissions were self container as long as it ran in the dev environment a participant could guarantee it would perform the same in the actual tournament
  4. As long as a participant knew how to build their image, they could bundle whatever dependencies / libraries and binaries they wanted.
Subscribe to get the latest posts in your inbox:
Tackle the world's most exciting artificial intelligence challenges with the community.
SitePoint LogoGeneral Assembly LogoHackathons Australia LogoDSAi Logo
Interested in sponsorship?
Sponsorship Enquiry Form
© 2022 Coder One Pty Ltd | Contact | Privacy