Micro Runners - creating a PSX-like 3D racing game inspired to Micro Machines and Micro Maniacs

Hi all! In the last few days I got busy developing a game I had in mind for some years now.
What I wanted to make is a game similar to Micro Machines/Micro Maniacs for the PSX, meaning a low poly, low res multiplayer racing game with weapons and some platforming elements.

I am not very good at keeping devlogs, and I prefer writing actual code and making actual progress istead of entering words in a virtual document, but I think sometimes the time is worth.

As I reached the first "alpha release" of the game, I would like to talk about some challenges I encountered during the development and how I ended up solving them.

First of all, 3D

This is the first game I make in fully 3D environment. Yes, I made some smaller games (if you can call em this way) but nothing compared to this. I had to make maps, texturing, make models, and so on.. quite challenging for me. And it is the first 3D game ever I make using the Godot engine, so I have a lot to learn while doing.

For the levels, I used TrenchBroom with Qodot plugin. If you don't know, TrenchBroom is an open source Quake level editor that works on a grid system. As a squared developer like I am, grids are wonderful. If I were to make them in Blender, I think I would have quit a few times already. Qodot is a Godot plugin that lets you import maps created in TrenchBroom in your Godot project: pretty nice!

This is how the map looks like in TrenchBroom:

And this is Godot after importing (and adding things like checkpoints, traps + hurtboxes, powerups...):

As you can see, TrenchBroom map is missing traps and entities in general, as I preferred to add them directly in Godot after importing.

Controller inputs

Godot Input/Action system is good. But I wanted to let the player press a button on any controller to join the game from the lobby, dinamically adding the player to the list attached to the controller he pressed the button on.
I did not find a way to do this in Godot: Input sistem let me check inputs defined in project settings, but I did not want to add every single input from every single controller in the input list. So I tried catching all inputs, but had trouble getting the force when done this way. Moreover Godot input system does tell me the device-id of the input but it gets remapped to an array starting from 0 everytime a device is connected, and I did not like this. I ended up defining all the actions for 4 controllers manually (that's why is currently limited to 4 players).

Camera system and out of camera players

This was rough. Camera in the game is dynamic, meaning it follows the players around and always tried to keep all players inside the viewport. 
At first, I kept track of the mid point of the players aka the average position on x/z axes, and centered the camera on that point. Not good. When a single player is far behind others, or even worse when the leading player is far away from the group, he goes out of the screen and cannot see the road because the camera is more likely to follow the group.
So I switched to calculating an AABB box using the 2 most distant players, and this worked. Now the camera is always centered no matter what:

In Micro Machines/Maniacs games, when a player exists the screen, 3 things may happen:
- he dies: if he is in the last position of the race
- another player dies: if the player who exited the screen is the leader of the race, the game kills the last one. This is to let the leading player see the rest of the level.

Luckily in Godot there is a node called "Visibility notifier" that can tell you if it is inside or outside the camera. I immediately attached it to the center of the player model and voilà, it sucks. This is because waiting for the player to completely exit the screen is not good at all: during his last breaths, he can not see anything because his model is almost outside of the screen. I solved this by using 4 visibility notifiers nodes, aligned on x/z axes, and checking if one of them is out of the camera. I can now move the nodes around to adjust how near the edge of the screen the player needs to be to be killed:

Well, this is all for now. If you would like to try out the game (Windows only at the moment) please check the project page.

See you!