| Title: | Cyberdrive Racing |
| Date: | Oct. 2019 - Feb. 2020 |
| Genre: | Third Person Racing |
| Platform: | Windows | Controller |
| Players: | 1 to 4 (Local) |
Daniel Garelik
Luca Hölzel
Max Scheidner
Cyberdrive Racing
Yet another university project, which began life with the anouncement of a topic, which all of our efforts should adhere to. The topic which our professors settled on was "Limited Resources". An interesting choice, which lead to many great interpretations by my fellow students. While some approached it purely from a perspective of game design, restricting a player in the resources they could use to play or solve puzzles, some approached it from a more grounded point.
Often the first thing "Limited Resources" brings to mind is fossil fuels. Regardless of any political stance one might have on the topic, no one can deny the presence this topic has in peoples minds. I decided to join a group of students who aimed to create a multiplayer racing game, based on this idea. It truly struck me as odd, how often the idea of fuel is omitted from the design of racing games, so I was all ears!
With Daniel Garelik as the main artist / desgin lead, who envisioned the project, Max Scheidner as the second programmer and technical artist and Paulina Fischer as VFX artist and production manager, the team constellation looked to be productive and talented! I focused my efforts on the main structure of the code, the vehicle movement / handling, as well as any user interface design and programming.
The gist of the games story goes as follow: In a far future, humanity has settled many planets. Some of these planets were mined for their oil and natural resources, only to be abandoned later. For many years thrill seekers and adrenalin junkies have conduct underground races on some of these planets. Tuning their gliders with the little fuel the planets had left to give, these races became a spectacle for their high speeds and even higher death tolls. When the mining companies caught wind of these races, instead of shutting them down, they started sponsoring official races to promote their brand image. These are the races the players experience in Cyberdrive.
After consulting with my team mates on the possible technical avenues to take, we settled on Unity Engine / C# as our development platform of choice. While I would have preferred working in Unreal Engine for a racing game, everyone on the team was familiar with Unity. After setting up the Perforce version control depot and getting everyone signed in, I started working on a small prototype. The most vital thing in any racing game is driving / movement. As such, I stowed away the more formal aspects of spawning, memory management and general game management for later.
Gliders were settled early on as the vehicles used during the races, which provided an interesting balance between free floating propulsion and gravity. My first instinct was naturally to use the built-in physics engine, which Unity provides. I quickly modeled a mock up glider for visual clarity and began working on a simple vehicle controller, which would apply force / torque to certain parts of the collision model, if they came too close to the ground. Equally it would apply negative force to ensure continued proximity to the ground. For the first few iterations, this seemed like a good direction, however I quickly realised that I was working backwards.
Instead of implementing desired behaviour, I acted like a shepherd dog, trying my hardest to keep the physics engine from producing undesired effects. After the first week, I proposed a custom solution to my team, which would not use a physics engine, but instead calculate movement and colission in a more controlled, manual way. While rough and stiff at first, the consistency of movement and ability to test level concepts more effectively, proved that this aproach was superior for our puropses, as such I began refining and optimizing the movement / collission processes, before moving on to the next desired features.
| Prototype | Greenlight |
|
|
Once the glider movement had taken shape, I started working on other elements of the game. From the object pooling system and VFX deployment, to the general game and race manager objects, I slowly shaped the games flow and technical functionality.
While my team mate Max was working on his blender mesh generation code, I set most of these aspects of the game inplace. Once finished, he took up the majority of the work on the pathing system, which I then called and referenced for the lap counting. This was one of the best experiences in collaborative programming, which I had the pleasure of partaking in during my studies!
|
|
After all of our contributions came together, we began workig closely as a team, involving each other into our processes more and more as the project carried on. This ultimately helped us from working into directions that would either miss the original vision or would be incompatible with the other members efforts.
By the time the deadline came, not everything we envisioned had made it into the game. But even so, what we ended up delivering was a functional, fun and technologically & artistically involved racing game. The local multiplayer aspect was especially compelling during our semesters project exhibition, which drove many people to our booth, competing with their friends and staying for some feedback!
|
|
© Luca H. |