Testing out a few things, like the 3rd boss. Still buggy, for example it didn’t know when it was dead.
Also got an idea for the next boss. It’s not gonna just try and kill the player, rather it’ll try to capture them in between two parts or something like that. Would fit well with the story.
Anyway, here’s a video of a test fight with the 3rd boss. I might change the cover to something the boss can destroy (maybe some shields that eventually break down and, after a few seconds, appear again). In the end the boss disappears into the wall. That is not a glitch, the boss found a piece of fake wall which I put there to test something else, and forgot to remove.
So, development was on hiatus for almost 3 years. I had issues with the game’s physics. Essentially, when the ship collides with a wall, it’s supposed to bounce off, angle of incidence equals angle of reflection, that sort of thing. However, instead it almost always bounced off exactly perpendicular to the wall, no matter the angle of incidence.
Now, I’ve previously been unable to solve this behaviour. I eventually concluded that this is an issue with Godot’s physics engine. As a result, the only solution would be to try and find someone who knows a lot more about Godot and programming than I do, and have them write completely new physics for me. Yea…
Now, thanks to the recent advances in AI, I was able to solve it. Or rather, a certain well-known LLM pointed out my actual mistake. Mr. Smartypants over here confused friction with drag and turned it up to max, when it should have been at 0.
Friction applies when two objects slide along each other (or in this case, the player along the wall). With the player’s friction set to 1, the player’s velocity parallel to the wall was immediately reduced to 0, so, of course, once they bounced off, they did so exactly perpendicular to the wall.
Right. So, moving forward, I will now go back to working on the game. My posts here will likely be more sporadic, but this is a passion project which I intend to finish.
Here’s the gist of the game’s current state
What is done:
Enemies are done
6 levels and 3 bosses are done
Interface is done
Game mechanics are done
We can save and load in between levels
We have options to change volume and rebind keys
Keyboard/mouse and controller support
What I still have to do:
9 more levels
2 more bosses
More tilesets so the levels don’t all look the same
Balancing and polishing
Music (unfortunately I don’t have the budget to hire Leonard for all the music)
Testing
Figuring out how to release it. Not sure I want to do Steam…
Bit early perhaps since there isn’t even a mission for it yet, but I had an idea for the final boss fight, so I started working on that. The music track for the fight is pretty awesome, too (Leonard again 🙂 ).
Also spent the evening implementing cheat codes. Mostly for beta testing, but I’ll probably leave them in. I’m especially happy with the input window. Cheat codes have gone pretty much out of fashion these days, but they were quite common back in the day. There were cheats for Shadow Wraith as well.
So far there are 5 cheats and one to undo all cheats. If a player used a cheat, this will be marked in their saved games.
Decided to change the player graphic. It was a pre-made model and I was told it wasn’t easy to tell front from back. Changed it to something new. It’s even animated.
Kinda like the idea of different player ships. Maybe next game.
The walls of the levels are made with tilemaps. I have, for example, a bullet that is of type Area2D and when that bullet registers a collision with the wall/tilemap, it deletes itself. Simple.
I used exactly the same way to detect a collision with a probe object that would tell the Dragon if there is something in the way or not. Basically, the dragon randomly chooses a set of coordinates to jump to and spawns a probe object at those coordinates. If the object collides with something, it sends a signal to the Dragon and suicides, then the Dragon tries again. If no signal is received, the Dragon goes ahead and jumps.
However, whatever I did, the probe would not register any collisions with the tilemap. How can it be that if you do something, it works, but if you do it again, it doesn’t? I checked the settings, they were the same. Collision mask, code, everything.
What eventually made it work was to tell the tileset to handle collisions as if it was a kinetic body rather than a static body. I have no idea what exactly that does, especially since tiles cannot move, but when I checked that box it works. Strangely enough, that was NOT necessary for the bullet thing to work.
A possible explanation would be that even though it’s the same detection (on body entered), it makes a difference wether the object moves against the collider or spawns inside of it.
Well, it works now. I just need to remember to check that box in the future. And to keep an eye out for any possible changes in behavior.
dR46o11.io.exec “Dragon” is the final enemy I’ll add to the game. This guy is able to teleport around. He’s not entirely finished yet, as he still tends to teleport into walls. Currently working on preventing him from doing that.
Also started working on the next boss. Not entirely sure wether this will be the second boss or a later one, but he’s coming along fine nontheless.
Finished a new enemy in today’s stream: the Creeper. This guy moves (“creeps”) along a wall and fires a constant laser beam. It’s more of a mix between an enemy and an obstacle. Currently thinking if I create maybe a stationary turret version of it that fires a more conventional weapon, maybe plasma bolts or something. Not sure yet, we’ll see.
Have to admit, creating this one was a bit annoying. Normally the enemies constantly do a raycast at the player to know where the player’s ship is and when it’s close enough to attack. Creeper does so, too, but it kept switching between aggro and not aggro because in like 90% of cases the raycast hit the wall instead of the player. Quite obvious in the end. Unless otherwise specified, the raycast starts at the caster’s origin. Not going to work well if the origin is within a wall. Still surprised some of them came through.
Also had the issue that I check the Creeper’s orientation to know in which directions it moves. For example, if it’s at 0°, it points upward and moves left to right. If it’s at 90°, it points to the right and moves up and down. The former worked, the latter didn’t, the check never became true. Turns out: in the inspector, the Creeper’s rotation was set at 90°. However, a quick print(rotation_degrees) revealed: in-game the rotation was at something like 89.97763°. Little bastard!
This is d4-N23R.vi.exec “Dancer”. It is not entirely clear who programmed it and why, but its mode of attack is unusual. Instead of relying on classic offensive protocols, Dancer possesses four blade-like parts that constantly rotate around its body. When it spots the player, it will charge at the player, using its blades to slice.
I originally intended it to ignore shields and immediately do hull damage, but I wasn’t sure about it.
