Kart City Racing : Midterm Devlog

What is Kart City Racing?

Kart City Racing is a game I’m developing in Unity for my college computer science capstone project.  It is a kart racing game that takes the controls and gameplay from games like Mario Kart and merges them with the open world aspects of games like Burnout Paradise.

Mario Kart is a nintendo racing game series where you play as various nintendo characters ranging from mario, to link, to kirby and more.  In it you race around in colorful go karts on crazy tracks themed after various mario games or levels.  

What we want to do is recreate this general gameplay.

Below is a video showcasing Mario Kart gameplay

Burnout Paradise is an open world racing game where all the events take place on one continuous map.  This means that the player can explore this map outside of races or events to find collectables or to just mess around.  They can then drive up to any intersection and with the press of a button they are off on a race.  All races take place on the same map they explore, so knowledge they gained from exploration helps them in the race, and knowledge from a race helps in exploration.

We want to use this exact same open world format.

Below is a video showcasing Burnout Paradise.  Pay attention to how they start and stop events.

Here is a run through of my game at the time of writing.  Pay attention to how we’re using the controls and aesthetics of Mario Kart but the open world structure of Burnout Paradise

What have I worked on?

Well I could stop the presentation there, since this is for a computer science capstone I feel like I should spend some time going over the major systems at work.

This is roughly all the main systems, classes, or key actors in this project.

Let's start on the bottom right.

Starting on the left we have the Character class.  This class acts as both a wrapper and a facade type class for many of the components that make up what we would think of as a character.  The character class is designed with the assumption that it could be controlled by both the human player or an AI bot.  

Below the Character class is the CameraManager class.  This class controls the camera and its current state, most of the time this is behind the human player's character, but during a race intro this changes to a static wide angle,  I also plan on having it change when a race ends as well.

Moving to the right we find three subclasses that the Character class has: Vehicles, Items, and the Driver Model.  The Item class hasn’t been fully implemented at the time of writing but will act as a root class for any held items the character has.

The Driver Model class handles the animations for the driver in a given vehicle.  At the moment the animations haven’t been made, but when they are this class will handle those animations.

The Vehicle class handles the actual movement of the vehicle the user is driving.

One feature we have added is the ability to switch between cars and boats on the fly during a race.

Well the cars use wheels to move around on static ground, the boats need some waves to float on.  These waves use a custom shader function, allowing them to run on the GPU for better performance.  However, the boat code is on the CPU.  So the WaveManager class acts as a bridge between both.  It sends the main wave variables to the GPU once at the start of the scene, then acts as a system the boat can query to get the current wave information to appear to float on top of the waves.  Lastly these waves use Gerstner waves rather than simple sine waves, to give them a more realistic appearance. 

Moving next to the bottom left we have the controller classes

GameController is a generic parent class that lets us control a character.  Derived from that we have the PlayerController and AIController child classes.  This allows us to set what exact actions an AI or human player is allowed to take.  For example a human player is allowed to pause the game, and AI is not.  Lastly we have the InputMapper and AIBrain classes that interact with the PlayerController and AIControllers.  InputMapper is what actually maps the buttons on the keyboard, gamepad, or whatever you use, to actions in the game.  Unity actually handles most of this out of the box.  The AIBrain is where all the AI logic will go.  At the time of writing I have not implemented any AI’s but this is how it will fit into the rest of the system.

After the controllers the two systems I want to touch on next may seem unrelated at first, and those are the SaveSystem and the UI System

The save system is incredibly straightforward.  It saves the user's progress in a ‘Save’ class that gets written to and read from a file on the device.  

The UI or user interface can be broken up into multiple widgets

Each of these widgets get loaded in or unloaded as needed.  This is handled by the UI_WidgetManager.  These widgets also need data that can come from just about any system in the game, but we don’t want to create a bunch of dependencies between all the widgets and the rest of the code.  This is where the UIBlackboard comes in.

The Item Widget displays the currently held item, this means it has to know what that item is.  The Character Class knows what the item is and can post it to the Blackboard.  The Item Widget can then read this from the Blackboard and display the correct image.  It can even subscribe to be notified when this data changes.  Since every UI Widget subscribes to the same blackboard this method scales much better than a bunch of disparate dependencies.

This Blackboard design pattern is also used by the SaveSystem in the Save class.  This lets us make the save class once and then later on in development we can keep posting more and more data to it without needing to refactor the Save class at all.

Under the hood all this blackboard is, is a dictionary with a generic value type.  Technically, this code does not compile in C#, the language we are using, but we can make a dictionary of objects and then always fill that object with a generic class that just contains a generic value.

The last systems we will look at are the red in the top left corner

The GameManager class is the highest level class in the entire project and handles functionality we need persistent for the entire game.  At the moment all it does is load and unload the GameMode classes which act as top level manager classes for the modes the game can be in.  The Race class has a subclass that contains all the static data of the race it will start.  Things like type, goals, etc.  The majority of the work done by these GameMode classes is loading or unloading the needed assets at key events, like when a race starts or ends.

And that's all the major systems in this project

Whats Next?

The next main things I want to focus on are game Juice.  That is the polish and visual fidelity of the art in the game.  Even though this is for a computer science capstone project game feel still plays an important role in the quality of a game.  AI is the other big thing I want to tackle next.  It’s not really a racing game without opponents to race against.

If you wanna play the game for yourself or check out any future builds I make just scan the QR Code.  It will take you to Itch.io, a site I’m using to post the latest builds of the game, feel free to leave any feedback or report any bugs.

And that's it for my midterm devlog. I'll be back again in December for the final presentation, hope to see you then.