XERVONAUT
A WIP game made with Godot Engine
About the game
Xervonaut is a sci-fi action game where the player must complete deliveries in a futuristic city using a flying vehicle, all within a limited timeframe.
The concept is taken from games like Crazy Taxi, but involves delivering cargo/boxes instead of transporting people to different locations.
From movies like Blade Runner, I took the idea of multilevel, vertical cities that can be navigated with flying vehicles.
The vehicle controller is based an abandoned space game project I was working on in early 2024.
The design challenge
Since I am a programmer and not a game designer, I can create most of the mechanics I want with ease, but I lack the knowledge of basic design concepts and practices, so creating the flow for a whole game is a real challenge.
Thus, armed with my most powerful weapon: common sense, I came up with a simple game loop that could let me complete my very first game on my own, without ending up with a spaghetti project lacking direction.
The Game Loop
The first step was to identify the basic game elements (Player, Box, Box Spawner, Delivery Point). Then determine the basic Game Loop:
- Box spawns in Box Spawner
- Player picks up Box
- Player delivers Box in Delivery Point
Loose conditions:
- The Player's vehicle crashes. There is no health system, colliding with the environment is enough to make the car explode. This is also helps reduce overall complexity of the project.
- Time is up
There is no win condition, instead, the player has to deliver as much boxes as they can within the given time.
Once the core game loop is defined, I can start writing its logic with pseudocode. Since gdscript is quite simple, in my case it is easier to write code in its propper syntax directly.
Camera and controls:
I want to make the game controls as simple as possible, that's why I made a fixed camera.
Ideas for further development:
Punish the player for slow driving. The slower the player drives, the faster the time/fuel runs out.
The Panopticon Document
Godot 4 lacks of a built-in tool that displays the relations between every element on the project. If you want to explore the way every element interact with each other (i.e collision layers, scenes/code related to the game loop, etc), you have to open each element involved, reading the configuration or code and understanding the links between them and how they work together.
For example, if I want to know which objects collide with Player, first you have to open it and check which layers/masks are associated to it, then check scene by scene the ones that have the necessary layer configuration to collide with Player.
This is a cumbersome task that can be solved by having a graphic document where every relation is detailed and visible from a single place. I call this document "The Panopticon".
Exploring the collisions of every relevant scene with this document would look something like this:
Root:
Layers: 1
Masks: 2
BoxDetector:
Masks: 3, 4
Root:
Layers: 3
Root:
Layers: 2
...
More information the document contains:
- Scenes (Each one contains the references to their relevant children nodes and collisions).
- A description of the game loop with pseudocode of the involving scenes.
- Autoloads (Game managers).
- Directory structure.
The biggest advantage is having all the relevant project information visible in one place, although the disadvantage is that the document has to be updated manually and constantly.
Level Design
I have zero experience in level design. So I struggled to create a decent fun levelwhere the driving and flying experience feels fluid.
I made some preliminary buildings in Blender and tried to shape a city. But I wasn't pleased with the result, the traveling experience around the city ended up feeling dull.
I also tried to make platforms resembling flying streets, stacking them in multiple levels, and separating them with buildings. But again, I failed and the result was boring.
So i made modular paths and with them I made streets and placed the buildings that I made in first place around them. This solution works, both artistically and technically. When the player is flying around the city, the experience feels fluid and convincing.
As for the Box Spawners/Delivery Points placement, I decided to place all of the spawners on one side of the map, and all of the deliveries on the other side. So the player has to allways travel from one end of the map to the other in order to pick up/deliver boxes.
Current design issues:
There is a problem with these modular tunnels, if I place a Box Spawner or a Delivery Point inside these paths, it is really hard to fly into and out of them. This leads to an interrupted flow when the player has to dive into these paths to collect/deliver a Box since the space there is too narrow (and will probably be obstructed by traffic in the future).
Certainly, placing spawners or deliveries here is not unacurate, since it is not mandatory to pull over the vehicle to get into these tunnels, but affects the overall difficulty of the game considering that not all the players could be skillful enough to do it. Moving the pick-up/delivery points to another place would not solve the problem either, because the level would be left with an unused area.
It will be modified in the future.
I found another problem when placing the Box Spawners/Delivery Points on the rooftops. In this case, sometimes it is needed to do a full stop in order to elevate the vehicle and accessing these areas, screwing up the flow of the game...
I opted for a "medium verticality" spawner/delivery placing. The pick-up/delivery points elevation is tweaked in a way where there can't be found on the rooftops, nor in the ground. Like so, it is not necessary to fly neither too high, nor too low in order to reach these points.
Mistakes I made so far
- Not recording development times
- Underestimating level design