Most of my time on the project today was spent working on rehauling a lot of the game’s engine, so there isn’t too much to actually show off. But it’s coming along well!
I quickly put together the enemy projectile stuff yesterday, and one of the things I didn’t like was the way the enemy fireballs targeted the player. I basically let the fireballs live for 100 game ticks and made it so that the fireballs would reach the player’s position in exactly those 100 ticks. I did it this way because the math was easy, but it actually seemed pretty dumb when you were really close to the enemy and they’d shoot a fireball that would move super slow and last forever.
So, to fix that, I employed my old pals from high school, geometry and trigonometry. As a professional translator I’ve never had much use for the maths and the trigs and the calculus stuff, but I loved that stuff back then so it was pretty easy to apply it even after all these years.
Basically, I wanted the fireballs to move one pixel at a time, no matter what, and continue to fly past the player’s spot if the player moves before it arrives. To figure out how much to move the fireball on the x axis and how much to move it on the y axis with each clock tick meant I had to do some angle trickery.
A handy trick in case you’re ever making a game – you can get the angle of something by doing the arctangent (sometimes called inverse tangent) of the length of the opposite side of the triangle divided by the length of the adjacent side of the triangle. Using that, I did some other inverse trig stuff to figure out the answer I needed.
The problem I encountered was what if the player is exactly lined up on the x or y axis? That could result in a divide-by-zero problem, so I wanted a better way to handle it. Plus, I find it hard to believe the Zelda 1 programmers implemented this same thing using trig functions – on the NES that’s some heavy math to do (or at least a lot of ROM space wasted storing trig tables).
So I approached it from a geometry standpoint and did some simple algebra to figure out an equation I can use. It works perfectly, although I have to go in and assign negative or positives to the results manually.
You can see the result of all that math in action here!
See? People say all the time that math is never useful in real life – that’s because math is actually good for making fireballs.
Anyway, my resulting equation involves division and taking the square root of something, both of which are tough to do on the NES and cycle-intensive, so I still don’t believe that’s how they did it in Zelda 1. I *know* there has to be a cleaner, more optimized equation for this, if anyone knows, please share! It’s not often I get to mess with math, I forgot how nice of a puzzle game it can be 🙂
While on the subject of projectiles, I was like, what if we made an enemy like a dog or a flower that shoots bees at you? Mainly I said it so I could try to make a different kind of projectile at some point, a sort of homing projectile maybe.
So Poe drew up a sunflower animation and, using the custom actions thing I did for the eye ghost yesterday, I made a new enemy that acts differently from all the rest of the current enemies. So that’s a good sign of how that design is coming along.
While I was at it, I made it so that some enemies will fly back when hit, while some won’t. And then I made it so that if you hit an enemy and it doesn’t die, it’ll flash briefly and make a sound so that you know you did damage it. It’s spiffy.
A big thing that’s been bugging me is how to organize all the graphics and sounds and make it so that these assets are easily available to the things that need them. Before, I had to do some crazy parameter passing to get the assets to where they needed to go.
To fix this, I’ve started on a GameContentManager class that’s very basic, but by having an instance of it made at the start, I can then just pass a reference to this object around. This simplifies things a lot AND makes the source code make more sense.
Right now, the only downside is that I basically end up loading everything at the start, and I can’t unload it until the game’s over. I can probably add that feature in, but having to reload stuff on the fly can possibly cause stuttering and other issues. I’ll just have to try it out, but if I were to make a much larger game this basic solution wouldn’t really work.
Currently no downloads as the engine is still being reworked. I’ll probably have other rehauls to do later too, like the tile system and the collision system. I just hope this doesn’t kill the roll I’m on.