The presentation that was held at GECCO 2011 about the "Demolition Derby" competition. In the competition, separate programs control the cars in a racing game being provided with local, sensor information only. The goal is to cause as much damage to other cars with avoiding damage meanwhile. The slides shortly introduce the controllers of the participants and then present the results and the winner. See also http://www.youtube.com/watch?v=YZ1Pi7V83Ao

1. Martin V. Butz Department of Psychology III University of Würzburg Röntgenring 11, 97070 Würzburg, Germany butz@psychologie.uni-wuerzburg.de GECCO 2011Competitions

2. Demolition Derbyhttp://www.coboslab.psychologie.uni-wuerzburg.de/competitions Martin V. Butz, University of Würzburg, Germany Matthias J. Linhardt, University of Würzburg, Germany Daniele Loiacono, Politecnico di Milano, Italy Luigi Cardamone, Politecnico di Milano, Italy Pier Luca Lanzi, Politecnico di Milano, Italy

3. Demolition Derby: Purpose Optimize opponent interactions Avoid being hit – run away when necessary Try to hit others at the right moment Enables (co-) optimization of interaction behavior. Fitness may be based on damage caused to other cars. Co-development of two or more competitors is possible (possibly with different approaches). 3

4. Goal & Setup Goal: Wreck all opponent cars by crashing into them without gettingwrecked yourself. Setup: Local sensor information as in the Simulated Car Racing Competition. Modifications: Sensors: Same simulated sensors – but without noise. The range of the 36 opponent sensors has been increased to 300m. Damage model: Cars do not take any damage when colliding with walls. Cars do not take any damage in the front when colliding with each other. Cars only take damage when their rear is hit by another car. 4

5. Winner Determination Arena: Large circular track (surface: asphalt; length: 640m, width: 90m) Qualifying 1-vs-1 matches evaluating all against all (winner = 1 point) Eight best controllers qualify for the final showdown. Final match: The best eight controllers fight each other. The last car standing in the final match is declared the winner. 5

6. Additional Goodies for a Quick Start Basic controllerclients for Java and C++, to easily add additional functionality to. COBOSTAR client in Java With opponent monitor that tracks opponents over time. With simple crashing strategy that targets closest car in range. Evolvable client setup that receives caused damage signal, applies CMA evolution strategy-based optimization, runs continuously with or (even faster) without visualization for as many generations as desired.

7. Entries Thies Lönneker Dep. of Computer Science University of Würzburg GERMANY Controller: DemoStar Zygmunt Horodyski Piłsudskiego 39/1 66-530 Drezdenko POLAND Controller: Spartiat

8. Entry Information Thies Lönneker Dep. of Computer Science University of Würzburg GERMANY Controller: DemoStar

10. sensors:

11. distance from start line

12. track position

13. result: 3rd person perspective

15. sensors:

16. track edge sensors

17. focus sensors

18. result: 1st person perspective

20. Opponent sensors provide information about

21. sector

24. Record the last opponent sensor readings

25. Remember information about sector transitions

26. Get opponent's moving direction from last sector transitions

28. Parameter optimization for best steering efficiency

29. Method: Covariance Matrix Adaption evolutionary strategy (CMA-ES)

33. Action SensorModel (SM) Mainclass Update model every 1min (Run Algoritmevery 1min) Action SM Collect data Send action Select one of behaviors Model M Update Controller Behavior GetAction Algoritm Zygmunt Horodyski Overview of how the controller works

35. [A] Average distance from the edge when we move back [outer edge]

36. [B] Average distance from the edge when we move back [inner edge]

37. [C] Average distance from the edge when we slow down

38. [D] Distance from the edge when we slow down

39. [E] Distance from the edge when we use brake

40. Time after controller will act like it stuck

42. Sensor:

43. Car:CAR CAR CAR CAR CAR Zygmunt Horodyski B, C A, C

44. Algorithm The Algorithm is inspired by “life” observations – and the solution is some sort of model. Referring to the reality, we don’t always think about every single move. From time to time we have to update factors that determine our behavior, in other words we’re changing our model. The select is my interpretation of tournament. Each winner of each tournament (10 in total) has the possibility to crossbreed with the best one from the previous population. Also the two worst solutions form each tournament are crossing with each other (to eliminate useless solutions). Each solution has it’s own probability of mutation based on it’s rating. Probability of mutation is checked for each parameter of solution, adding a Gaussian-distributed parameter value if applicable. Zygmunt Horodyski

45. Evaluation function The evaluation function is also related to life. In many areas of life, especially in cars and racing we know the best way, the best solution. But not always we follow that best solution, although we can calculate it. And that make as unpredictable. In my evaluation function firstly we check which one of strategies suits the situation best. Select of it is based on time to the end, current damage (ours and others), current fuel level and others. Two different strategies determine two different best solutions. Each judged solution is compared to the best one and rated. The perfect score that can be granted is for solutions is the one with 10-20% difference from the best solution. Zygmunt Horodyski

46. Controller Controller is part of program that, based on model and current state of environment, sets the action of our car. There are two different controllers, each specialized to different tasks. One that avoids damage and safes fuel (Dumbass) and the other one that tries to cause damage (Pro). Two strategies protect us from programs that learn the opponent. Firstly we select one behavior, then we calculate each Action parameter (based on the selected behavior) and then return that one to the main class. SensorModel Collect data Send action Select one of behaviors M Update Action Behavior Action Zygmunt Horodyski

48. Controller will move around the map searching for the opponent

49. [C] Charge (sd+sp)

50. If we see an opponent and it is possible controller will attack

51. [M] MoveBack (sd+sp)

52. If there is no way we can move, controller will move back

53. [B] Brake (sd+sp)

54. If it is necessary, controller will use brake to stop the car

55. [T] TurnBack (sd+sp)

56. If there is an opponent behind us and it is possible, the controller will turn back

57. [S] Strike (sp)

58. If opponent is directly in front of us, controller will attack

59. [E] Evade (sp)

60. If controller is near edge, it will evade it.EXAMPLES ON THE NEXT SLIDE (The way how it chooses can be checked in source code in DD_D_Pro and DD_D_Dumbass) Zygmunt Horodyski

62. Car:

63. Enemy:CAR CAR CAR CAR CAR CAR CAR CAR CAR T

64. Results……… 8 (2xDemoStar, 2xSpartiat, 4xBase-Client) 3 (DemoStar, Spartiat, Base-Client) 1 vs. 1

65. Results with 8 cars(2xDemoStar, 2xSpartiat, 4xBase-Client)

66. Results with Three Cars(DemoStar, Spartiat, Base-Client) … DemoStar wins… Spartiat similar to BaseClient.

67. Results 1 vs. 1(DemoStar, Spartiat, Base-Client) … DemoStar wins… Spartiat better than BaseClient.

68. Thies Lönnekerwins with DemoStar Check out the competition video online: http://www.youtube.com/watch?v=YZ1Pi7V83Ao