Battle Cars | April 2019 - Now

Racing Battle Royale

Game Designer (AI & System) | Project Manager

Unity | Jira | Confluence

Themes: Racing | Explosions | Urban | Cartoony

Pitch: Battle Cars is a Battle Royale car game where 64 players are confined in tracks and arenas and ruthlessly fight to the death. Violent high speed collisions, game changing abilities, spectacular tricks... In short ; total destruction until only one remains.

Battle Cars is my master's 2 project and my most ambitious project so far! Because Gun On Wheels didn't make it through the final stage for several reasons, I joined Battle Cars, the other car game of the batch as a producer and game designer (without owning the creative direction).

In order to fulfill my career goals better, while working on the project, I set myself key aspects to work on:

  1. A very strong and effective documentation, showing how effective a game designer can be on a 9 month production

  2. Powerful management tools, using Jira (linked to Source Tree) to succeed better in my job as a producer and apply the agile methodology. This software is widely used in the game industry, and I am also convinced it will give me a better overview of how a project must be organized to be effective, giving me hints if I want to become a lead one day.

  3. An emphasis on AI Design, which is one of my two main specialties in Game Design. I already have made a lot of projects focusing on either the camera or the controller, but I wanted to make one more game using AIs, and Battle Cars seemed like a perfect fit. Indeed, a game welcomes up to 64 players, but if not all 64 seats in a server are encountered, they are replaced by car AIs. The goal here is to reduce the gap between the player's behavior and the AI's behavior, in order to create a more outstanding Battle Royale experience.

Current Sprint Build (Sprint 25/32)

The project is a work in progress and features showcased in this overview might be subject to change.

Proof of Concept Trailer

Made before the official game selection in 2018, and showcasing a different universe (more aimed at desert and less urban) from what the team is targeting now, this trailer, made using Unreal Engine 4, still transmits part of the project's intentions. 

First prototype attempt on Unity

After grouped advice from a lot of trainers and specialists, we decided to stop the production on UE4 and switched to Unity, principally for physics replication purposes, since our Battle Royale is online.


After doing 2 internships at Ubisoft, I discovered how using a wiki can be a very powerful tool, allowing quick links and constant upgrades, being both more flexible and clearer than more traditional ways of documentation (powerpoints, PDFs, or google docs). Furthermore, such a tool can easily be given to externs, since we just have to give them links to go toward the subject they are interested in.

Setting up confluence is a little bit harder than other ways of documentation, but for a 9 month project, it's definitely worth it. The idea is clear and simple. The wiki is divided into 6 main pages:

  1. Game Design

  2. Art Direction

  3. Audio

  4. Engine

  5. Presentations

  6. Producing

Each page has a lead which validates any document inside of it.

More details about the documentation and production pipeline here.


Documents are organized in a tree with the 6 main pages as the bases. The closer the documents are from the main pages, the more they are high-level. The farther they are, the more they are low-level.

Example: Game Design main page (high level)

Document link here.

Intentions, abstract diagrams, loops... All those elements are depicted on high level pages, giving a clear direction of the game's design, helping us make choices when getting to lower level features.

Example: Collision document (low level)

Document link here.

Much more detailed and concrete, low level documents are meant to fully guide the production of a feature, whether done by programmers, artists, level designers etc... The template depends on the type of feature, but is usually very inspired by the atomic parameters of Rational Game Design.

Current Key Art

by Léa Lescuyer

The way we use our intentions is inspired by the pillars method of Doom 2016. Here are our pillars:

Pedal to the Metal

Forget about manners, you just need to crush your opponents.

Explosive Brutality

It's always about how hard you can hit'em. The harder the better.

No Fair Play

Forget about manners, you just need to crush your opponents.

To Show Off

Destroying feels good. Destroying with style feels amazing.

Method given during a workshop by Alexandre Mandryka

Mid-production folder

Here is the mid-production folder showing the updated vision of our game after the 2/3 of the total production, with our design, artistic, and technical direction.

Feel free to read it!

Pre-production folder

Here is the pre-production folder showing the vision of our game after the first 9 weeks of production, with our design, artistic, and technical direction.

Also feel free to read it!

Artificial intelligence

Behavior tree using state machines

Early AIs using the car controller

Even though our goal is to fill servers with only real players, it may happen that clients are missing to fill the needed 64 car slots. In that case, AIs automatically fill up the missing slots . For example, if there are only 40 clients, 24 AIs join the server.

As shown above, we’re currently using state machines. However, this has proven to be very limited if we want to challenge players. I will then tweak those AI parameters to simulate player strategies.

In game mock-up

Even though not showing the target render, polished mock-ups are very effective at showing a clear vision of important game features. Here is shown how players choose capacities, also affecting the car's overall look.

During a game session, the player must deal damage to the opponents' cars, either by colliding or using abilities. Dealing damage to other cars increases  brutality points as shown on the lower right part of the screen, giving a way for the player to add or upgrade abilities. Tricks can also be performed in order to gain nitro, be faster and hit the other cars harder!

Customization mock-up

Prior to a race, the player can create his own car preset with abilities, mapped on the X, Y, and B buttons. Apart from the skins, abilities have a visual impact on the customization, so that other players can also know the other players' abilities by reading their cars.


The management in Battle Cars is heavily inspired by the SCRUM and Kanban frameworks I testified their effectiveness during my internships at Gameloft and Ubisoft, of course reshaped in order to better fit the team's composition and scope.

My goal is to make the production as effective as possible, avoiding any useless meetings, while making sure team members have a clear idea of the current project's state.

Milestone and sprint planning

Document link here.

Since the project is made at Supinfogame during the year, every month, there is either a Jury with professionals or milestone with trainers giving feedback on the game's direction and the current prototype. Sprints are made in order to get ready for those milestones.

Milestone OKRs

Document link here.

For every milestone, features, ranged by priority, are targeted and detailed into more precise results, with team members responsible for those results. Using the OKR system, those key results are then graded from 0 to 1 during the milestone deadline, making the team able to identify the strong and weak points and better anticipate the following milestones.

SCRUM and Build pipeline

Document link here.

The whole production is based on making regular builds focusing on different aspects (levels, art scenes, 3C prototyping), that the whole team playtests together to give instant feedback. Other meetings, such as stand-ups, milestone planning, sprint reviews, and post-mortems, also happen in order to boost the team's productivity and motivation.


Thanks to the Milestone OKRs, a backlog is made on Jira, creating user stories for the team members which they can manage by themselves using a customized Kanban Board. Specific options have also been withdrawn and added in order to make the story management both simple for the team members, and detailed for me, the producer.

The Jira is linked to the confluence, allowing quick document links and story creations, but it is also linked to the versioning software SourceTree. Indeed, all stories related to the prototype are linked to commits, giving the whole team a clear idea of a feature's current state.


In order to make the production rhythm more effective and fully develop the user experience of Battle Cars, we decided to spend time on the development of a homemade launcher! It helped us increasing the playtest process, as builds are now automatically made and updated. It's also a way for the team to access the backlog, our documentation website, and agile planning.

Older Key Art 

by Léa Galinha

Other Team Members:

Anthony Rabaux | Lead Programmer

Florian Eschalier | Technical Game & Level Designer

Louis Bayard | Level Designer & Sound Designer

Dylan Fitzpatrick | Vision Owner & Gameplay Programmer

Léa Lescuyer | Concept & Environment Artist

Léa Galinha | Art Director & Vehicle Artist

Special thanks to:

Louis Houyez | FX Artist

  • LinkedIn Social Icône
  • Facebook Social Icon
  • Pinterest Social Icon
  • SoundCloud sociale Icône
  • youtubeicon

Phone: +44 7855 643168

Whatsapp: +33 6 74 73 88 09

© 2018-2020 by Matthias Johan