Adding more functionality

Adding more cars

• By default, the scr-patch comes with 10 scr cars that can be controlled with an external agent.
• To add more trainable agents (i.e. more than 10), simply make as many clones of the 'scr' cars:
  • Navigate to torcs-x.x.x/src/drivers/scr_server/.
  • Copy-paste one of the folders named 0-9.
  • Assign a new index to the car in the corresponding Makefile.
  • Re-make TORCS with the following set of commands.
• The number of trainable agents are limited by the number of available ports, which could be in 100s (starting from 3001).
• To add more 'traffic' cars, copy-paste any one of the chenyi_AI folders and modify the behavior of that car in the corresponding .cpp file. Re-make TORCS.

Re-making TORCS

Whenever any changes are made to the source code of TORCS (not restricted to the addition of new cars and modification in their behaviors), TORCS needs to rebuilt using the following sequence of commands:

make -j4    
sudo make install -j4    
sudo make datainstall -j4    

For more details, refer to the official TORCS documentation, and the official SCR-manual.

---

Implementation details

• As one can imagine, the original TORCS had the issue of the server having to wait for the next actions of each of the attached agents before rendering the next state. Because of this, the simulations would not be in real-time, since the agents' execution was blocking - if a bot takes a long time to decide what to do, it will block all the others.
• The Simulated Car Racing patch that we're also using in MADRaS re-designed the client-server application in a way that every game tic (roughly corresponding to 20ms of simulated time), the server sends the current sensory inputs to each bot and then it waits for 10ms (of real time) to receive an action from the bot. If no action arrives, the simulation continues and the last performed action is used.¹ In this way, no agent blocks the simulation for everyone else.
• The individual scripts are not pinned to individual threads out-of-the-box in MADRaS. The Linux OS assigns these processes randomly to the available cores right now, and the processes are switched-out into some other core every few ticks (based on the scheduling algorithm Intel follows).
  • The more a machine's cores are, the more evenly the processes can be distributed by the scheduling algorithm, whose sole objective in life is to utilise the available resources to the maximum extent possible.
  • For instance, if we just have one thread, then all the agents have to use that thread one-by-one till both of their computations are finished. This could possibly lead to a timeout (the aforementioned 10ms timeout), causing the server to use its last action instead of the new one.
    So with more (and jobless) cores, we expect to see a smoother performance.

_{1 Interestingly, this might introduce an additional (unintended) stochasticity in the problem, since the agent might take an action but the next state that it sees might be because the old action was used again.}