Welcome back I'm glad to see you again. Last time I promised a playable demo but unfortunately I got too ahead of myself. The game is not even in it's alpha state, so sorry but there will be not playable demo for now.
Bad news out of the way here's the good ones...
I would like to start by showing some of the models I made for some of the different guns you can equip.
Plasma Bomb Shooter / Plasma Blaster / Missile Launcher.
Most of the new gun models were inspired by OGame a web based idle game I used to play every day when I was a teen. If you take a look at the planetary defenses you may spot some of the inspirations.
But making the game wasn't the only reason I changed the models for the guns they also helping test the...
Now some of the guns you can equip will actively aim towards the object your spaceship is aiming at giving them a more "realistic" feel. I mean as realistic as spaceship can be.
It took some time to implement and debug but their movement it's mesmerizing.
Some of the guns have a limit on how low they can aim that's why they may look weird when targeting something too far down. This system can not only be used in the guns you equip but will also be used in the various turrets you will encounter.
While play testing the game I realized that some form of terrain was needed, firstly because that allow us to have a more varied selection of enemies like tanks, turrets, walking robots, etc.
Secondly because the more I play the game the more I realize that it's fun comes from chaos, having not only enemies but also buildings and other scenery to destroy.
Well since I'm no 3D artist I decided to leave the burden of creating the terrain to the computer. Although I want to I can't go into detail about terrain generation in general, but here's a great article about it and also a great one about smooth noise.
As you may know from games like Minecraft, Terraria and even Dark Souls loading and generation a complex terrain are difficult and costly tasks. Sure the noise texture helps, but that's only a small piece of the puzzle.
A common way of fixing said problem is by dividing the terrain into smaller pieces, called chunks, that can be loaded or unloaded when needed, that way the computer has only a few objects to care about freeing up it's resources.
Since 4XX is a very linear game I decided to divide the terrain into strips where each chunk is a collection of strips.
Here's two chunks next to each other.
So as the level progress new chunks are added to the end of the terrain, positive z direction, and the entire terrain is scrolled backwards. That way I can create the illusion of a vast terrain without torturing the CPU that much.
New chunks are added as old ones are unloaded.
Having a chunk system also allows me to vary the kinds of terrain and to define what kinds of structures and enemies can be spawned.
Having a mesh for each chunk is half of the problem the other half is it's collision shape. Creating the mesh was quite simple and straight forward thanks to the SurfaceTool object.
Sadly the collision shape would be harder as there are a lot of options to choose from (see Inherited By). At first I tried the naive approach of creating a ConvexPolygonShape3D for each x and y coordinates in a chunk.
Of course that didn't worked as single a chunk of size 100x10 would have 1000 objects to control. I knew this method was a bad idea, but I wasn't expecting the 5 fps I got when testing it with only 10 chunks.
At least the naive approach gave me some idea on how to do it properly.
ConcavePolygonShape3D vs HeightMapShape3DAfter doing some research I decided to go with the ConcavePolygonShape3D at first I generated one collision shape for each x coordinate in a chunk, and it worked the FPS was finally at 60.
Then I got curious and decided to create a single ConcavePolygonShape3D for each chunk, I though that would be a bad idea as the shape would be more complex.
But actually that change halved the time each frame took to be computed. Yeah, apparently having a single complex ConcavePolygonShape3D was way faster than having multiple simple ones.
Then someone on Reddit pointed out the HeightMapShape3D a collision shape made specifically for height maps and terrain generation.
Indeed the HeightMapShape3D did created the right collision shape, but the collision detection was glitchy and that collision shape doesn't support overhangs and caves.
In the end the single and complex ConcavePolygonShape3D method won.
There more things I want to talk about, but I gonna leave it for the next time, this devlog is already too long.
Maybe next time we will have nicer looking mountains and caves...