Day: June 6, 2025 (Page 1 of 4)

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…

Original date: August 24, 2022

The second boss is now finished. It’s probably a bit unbalanced but we’ll see.

Since 6 levels are now complete, I’ll have the beta testers take a look.

And no, it’s not a Borg cube.

Original date: August 19, 2022

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.

Oh yes, the boss I mentioned two posts ago? Done.

Original date: July 25, 2022

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.

Original date: July 06, 2022

This is the design for another boss. Not certain if it’s gonna be the second boss tho.

Behavior is not 100% finished, but it’s mostly working.

Original date: July 02, 2022

Okay… so this nearly drove me crazy.

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.

Original date: July 02, 2022

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.

Original date: June 11, 2022

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!

Original date: June 05, 2022

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.

Original date: May 31, 2022

Started working on the 5th mission. Layout and items are complete, still needs powerups and enemies. I also implemented a tripwire and powerups that act as switches.

Also fixed a bug that prevented the strafe right key from working unless it was manually rebound.