[Click here for the video version]
Hello everyone and welcome to this weeks game development log on The Stars Our Destination, a turn-based strategy flight game. To make up last weeks lackluster update, I gave myself a lot more tasks for this week. Let’s get into it.
This was long overdue. Well I say that, but I actually had it hidden deep in the commented code weeks ago due to whatever priorities I had at the time. I had to get rid of the terrain and make the mountains separate objects to make it easier to code. Currently the ship doesn’t take damage (though the code for that does exist), but it does tell BattleUserInterface script to flash red when the ship is hit.
That’s step one though. Just flashing red wouldn’t sell that the player has taken a collision head on all that well, so camera shake that stuff. Now it looks like it really hurts.
Last step (for now anyway), was adding a knock-back. This was a tricky thing to implement. Going back to Start Fox 64 (take a drink) it doesn’t knock-back the player in the traditional sense since the vehicle is always moving. It adjusts the Y position mostly.
I made few float variables for the timer and timer limit, Initially it was instantaneous, but that makes it a little jarring when the ship needed to readjusted. So I just made another float that increases or decreases to make it move smoothly, and only for the Y positioning. So now the player ship has a good damage knock-back to be polished upon whenever I need to.
Another big part of Star Fox 64 is the wings. I already had it so that the ship will descend regardless of player control, but I had yet to make it apparent the wing was taking damage, or that the ship was struggling to still fly aside from a little wobble.
This time I made it fly diagonally when losing either wing. If the player loses both it will reorient and it’s just be the wobble to show the uneasiness. Though the only problem that I know of is that when I barrel roll it’s awkwardly slanted when I stop since I adjusted the Z rotation. One step at a time.
The big problem I had with the camera was when the ship was boosting it was too far. This was because when I refactoring everything a few weeks ago to get the U-Turn and Somersault working. Long story short, the camera linearly interpolates (or lerping) to the ship, so I just increased the follow speed. So it zooms back enough, at least to me. Let me know what you think.
In the last developer log the ship deflected bullet as it was stationary for testing reasons, now was the time to test it out in motion. The best course of action for me was to make some stationary spawners, with gizmos to make them visible, then just fly straight into them.
It didn’t feel great till I lowered the barrelRollTimerLimit variable, which determines when the player can barrel roll again. Now it feels great, at least to me, going to be getting some outside feedback soon.
And lastly making the bullet more visually distinct. Of course none of the visuals are official, I just needed something to break up the grey monotony.
Keeping a house clean is a habit, and it’s the same with software architecture. I cleaned up the easy TODO:’s, and adding Tooltips in the scriptableObjects. I can’t keep a house clean, so I do the software thing instead.
Next on the list is to get an enemy working. Basically flying, have it’s own flight path, follow player, attack and all of that. Along with some other tasks I have planned for a minimal test demo with a beginning, middle, and end. That’ll be it for this week, let me know if you have any questions or feedback take care of yourselves and have a good week.