Welcome to my first devlog, I would like to share some of the improvements I made to my Star Fox clone, name pending, I made with Godot.
In the beginning the main inspiration was the Star Fox game for the Super Famicom or SNES. That's why the game started out with a retro look that tried to emulate the hardware limitations of the Playstaion 1.
But after a feedback I realized that first I was spending too much time on things that were not important and second the game looked bland.
So with those two things in mind I decided to change the art style making it more minimalist and to focus more on the gameplay elements. Another inspiration for those change was this video I saw about the game n++.
There are two main things to considered, at least for now, when talking about the new art style for the game.
The first thing I decided to change was the UI, before it was kind simple, again trying to imitate the look of PS1 games. The new design is also simple but it focus more on a single color palette and the makes heavy use of hard shadows.
Those are just some initial ideas.
I'm personally I like the new design but maybe I'm little biased. I thought about naming the game i but too honest it would be better if the inspiration in n++ wasn't so obvious.
Most of the colors for the new art style come from Tailwind CSS, I'm a front-end developer after all, mainly the slate color palette with some extra colors here and there.
Personally I find the new art style better and I think the colors work really well together but have a look for yourself.
Both images were taken during tests so please igonore the visible hit-boxes and editor lines.
I may not have a name for the game yet but one of my friends named the ship "Shark-1".
On e aspect of the game that before gave me some headaches for the wrong problem were the gameplay. I was so occupied dreaming about a deep and meaningful story that I never realized the gameplay was very meh.
So with the moto of "gameplay first" I made some test levels and one thing stood out...
Again was so preoccupied with minor things that I never realized the aim was really bad. So yeah even if wrote a masterpiece no one would play a space shooter that had a terrible aiming system.
And before I can tell you about the fixes I need to explain how the aim system works so here's a quick and dirty explanation:
The position for the aim_sprite on screen is based on a vector called aim_vector,
but that causes a problem as the aim_vector is 3D and the aim_sprite's position is 2D,
so to fix that we need to unproject the aim_vector, in other convert it from 3D to 2D.
Another thing to keep in mind is that a vector has two pieces of information a direction and a length, also a vector technically has a "base" and a "tip" and The position for the aim_sprite is defined by the "tip" of the aim_vector.
From that knowledge I managed to spot three points that needed urgent fixing, it doesn't mean the aim is perfect now only that it is less painful to use.
And the three main aspects were...
As said before every vector has a length and the length for the aim_vector used to be constant, 10 to be exact, what made it hard to measure how far away a target or obstacle was.
The gif may not show it, but when I played the game the fixed length was really bad.
So to fix it I needed to change the length of the aim_vector to be based on the distance from the closest target or obstacle. Fixing it was actually easy as Godot had all the necessary tools needed, it probably took me about one hour to fix and it made a subtle but significant difference.
Again the gif may not show it, but aiming became much better.
Well the length of the vector was only half the problem the other half was it's direction. For starters the aim_vector rotates with the spaceship model and the rotation of this was calculated from it's speed.
In the end it caused the aim to be imprecise as small angles would produce coordinates too close together and large angles would produce coordinates too far apart. it would look like the aim had acceleration, in more technical terms the coordinates for the aim_sprite were not linear.
To fix it I just needed the reverse logic. First calculate the desired aim position based on the ship's speed and then update the ship's rotation based on the desired aim position. Making the aim a little easier to control.
Even though the previous changes made aiming easier one problem persisted, hitting far away targets. And of all the problems so far this one were a little tough to fix but nothing to write home about then why am I writing about it???.
I already had a RayCast3D, a collision trigger that detects when a straight line collides with something, from when I fixed the target distance.All I needed now was to get current node the RayCast3D was hitting, store it in a queue and then pop it from the queue when a shot were fired.
But that wasn't it all as the entries in the queue need a timeout so that they won't stay in the queue forever. And well that's it, right? Problem solved, right? No, not yet...
About a month ago I saw gameplay of someone playing Star Fox 64 and the person playing it mentions that the auto target locking in that game, at least some times, made it hard to get a high score.
Considering that I want to add scores and a medal for getting a high score to my game that "auto locking problem" needed to be fixed. In other words the auto lock system needs to be an opt in system.
Thankfully a had already implemented double key pressing so that pressing the arrow keys twice will perform a legally distinct rotational action in any direction. And there it was, the solution, double press A to shoot using target locking and press only once to shoot without it.
Here's the target lock in action.
But don't worry or maybe do worry as the game isn't even close to finished, now I have to find a way to make the previously mentioned legally distinct rotational action less stiff.
So yeah stay tuned if you wanna see how this projects goes.