Mario Kart Item Post 1

Overview

There are many items in Mario Kart from a banana peel that trips players to a giant mushroom that causes a player to grow in size and crush other players.

Item class

To start with a abstract item class was made which has a pointer to a mesh (can be a nullptr since not all items have meshes) and an purely virtual tick (updates the item), hitByPlayer (players reaction when hit by the item), and use (what happens to the item when it is used). This class is then inherited by all the items this, currently banana peel, green shell and mushroom have implementations.

Spawning, trailing and releasing items

When the player presses A on the controller if the player has an item in their inventory (player’s get items from colliding with item boxes) and is not currently trailing an item (an item is following behind the player).

Spawning items

The item in the player’s inventory is then spawned if it has a mesh (such as the banana peel) otherwise it is just used (such as the mushroom). To do this a spawn item function is called which takes the inventory item as an argument (inventory item is an enum). In spawn item, a switch case is done on the inventory item to determine what item to spawn and when an item is spawned an item pointer points to its address in memory for later use.

Trailing items

Then for as long as the player holds down the A button the item trails behind the player. This is done by calling the trailItem function which sets the world position of the trailing item pointer to just behind the player’s world position.

Releasing items

When the player releases the A button the releaseItem function is called which calls the use function of the trailing item pointer which since being purely virtual calls the use function from the item class that is being trailed such as the green shell being thrown in front of the player. The trailing item pointer is then set to nullptr again.

Item collision

Item collisions are handled in the collision manager but a handled in a separate function to the rest of the collisions since not all items have a mesh.

Item, player collisions

Instead items are handled in a separate function called CheckResolveItemCollisions where a vector of all physmodels and another of all items are passed in. The item vector is iterated through using a range-based for loop and if it has a mesh then it is checked with all physmodels using a nested for loop. This check includes checking to see if the current physmodel is a player by casting it to a player pointer and then checking to see if the player and item’s colliders intersect each other. If so then the item’s hitByPlayer function is called and a hit_player bool is set to true and the nested for loop is broken as no other physmodles need checking.

Item, item collisions

Once the physmodels are checked then the bool that states if the current item is checked to see if it has already collided with a player. If not then the items are looped through in another nested for loop to be checked with the current item. This check involves first checking to see if the two items are not the same. Then it checks to see that the second item has a mesh and that the two colliders are intersecting. If this check is true then both items are flagged to be destroyed which happens elsewhere in the code base and the nested loop is broken.