How does the Code Game Challenge

Introduction

Code Game Challenge (CGC) is a competition format in which players practice writing game strategies that determine the behavior of units under their control in a certain game world. This type of competition is an eternal frequenter of more or less large programming olympiads.

In this article I will describe my vision of the device systems that make the holding of these competitions possible. I gained this knowledge when developing a similar project, which will be discussed in the second part of the article.

Vocabulary articles

Strategy - the player's code that determines the behavior of the unit.
Tact - time for which the code of all strategies will be executed exactly 1 time.
Simulator - a system that simulates the state of the game world, based on the code of strategies.
List of actions (unit intentions) - a list containing actions that the unit “would like” to perform on the current turn.

---

Content

• About Simulators
  
  • Clock
  • Real time
• AI - Project

---

About Simulators

I found 2 main approaches to the development of such systems. I worked directly with one of them. I'll start with him:
')

1) Clock

Feature: There is a system that processes each player code:

Upper level

It lies in the fact that the code of all players is sent through each simulator through a simulator that simulates the behavior of units and calculates the state of the game world. Further, the state of the game world is remembered and everything starts from the beginning. This continues until the condition for the continuation of the game is violated (a winner has been found or the bar limit has been exceeded).

Lower level

Strategy code, as a rule, has access to 2 interfaces:

1. For information on the state of the game world
2. To control a controlled unit

Analyzing the state of the game world and giving commands to the unit, the player’s strategy fills out the list of unit actions. The simulator, using these lists and information about the game world, models the game tact (performs a certain number of actions from the lists), periodically fixing the state of the game world. And so in a circle to the bitter end.

The data accumulated by the simulator can then be used to display the game match in an acceptable form.

Implementation options

1) Strategy format

Function

def move(    ,    ) if ( -  )  -   end 

+ Relative ease of implementation
- Where are the strategies to store data between measures?

Class

 class Strategy def init() #      #         end def move() #        , #     end end 

+ Easier to understand
+ Just implement data storage between requests (object variables)

2) "Wrapper" strategy

Process

The code is wrapped in a process shell. The server asks for data from the process - strategy.

+ This approach makes it relatively easy to implement multi-language support for writing strategies.
+ Reduces the number of ways to harm the server
- Difficulty of implementation

Connectable code

The code connects to the processing system (like .h files in C ++).

+ Ease of relization
- Complicated support for third-party languages ​​(the strategy is written in the language of the processing system)
(A possible solution to the problem is the use of translators)
- The enemy is already inside (requires a complex architecture to protect the simulator)

Features of the "clock" approach

• The complexity of the development script processing system
• All strategies, regardless of execution time, have equal chances for success.
• Great for match games

2) Real time

Feature : there is a resource to which the player’s code can access during its execution.

The strategy is executed in a loop on the client or server, requesting data and sending commands as needed.



Example strategy:

 class Strategy def initialize ... end def move while (true) do # ,      end end end 

Features of the approach

• Strategy time affects your chances of winning
• The main difficulty is solving synchronization problems.

pros

+ Regarding the first method, the player is more difficult to harm the server
+ A good platform for gaming sessions, not limited by time frame.

AI - Project

Story

Half a year ago, I accidentally stumbled upon a post that Code Game Challenge format competitions were held in my city. They were one-time and dated 2010. This prompted the creation of an application in which you could participate in competitions of this kind anywhere and anytime.

So AI - Project was born.

Specifications

Type of strategy: Class
Strategy Writing Language: Ruby
Method for specifying a position in space: (x, y)
Game world: square field, magicians and fireballs

What technologies were used

• PIXI.js to visualize the results of the simulator
• CodeMirror for easy browser-based code editor. The developers of this miracle gave it a very user-friendly interface.
• JQuery for exchanging code with the server and various small things
• Ruby on Rails for writing server logic and simulator

About architecture

---

About simulator

View: “Clock”

One of the main tasks of the simulator is to simulate the game world. The complexity of this module of the simulator depends only on the ultimate goal (to take into account physics or not, how complicated this physics should be, etc.). In the AI ​​- Project simulator, this module is implemented relatively simply. Below is a simplified scheme invented for this algorithm.

About game sessions

A similar in functionality mechanism is implemented in almost all match online games. It is necessary to recruit players, create a game for them, limit them in time, issue statistics at the end.

The game session is implemented in the form of a model that stores player code, status and statistics. Session is active until time runs out and exists until it is time until the last player leaves it.

The greatest difficulty in the implementation for me was the creation of a game session. Namely, how to combine N players into a game session and redirect them to their game pages.

How to do it all in one action, I at that time represented very vaguely. My solution for 2 players:

Player Code Execution

About a week ago, I, having corrected the last bug that hindered my work, decided once again to test the mechanism of the game sessions. After running the code that contained the string Game.delete_all , something went wrong. Without going into details, I’ll say that Ruby has the means to solve such problems in the form of 5-6 gems and its own defense mechanism ( $ SAFE ).

Time limit

The task with a time limit was solved with the help of an advanced JavaScript timer (displaying the remaining time for the client) and a self-made Back Ground Worker for Ruby on Rails. When creating a game session, a stream is created, which, after the time allotted for the game, makes it inactive. After that, the client cannot perform some actions (for example, sending a code).

Happy end

AI_Project