Been a while since I did a diary update, so it’s about time for one.
Recently, I’ve been coding a few SHMUPs for a little break. First came Neutron, a 16k cartridge entry for a competition.
Then came Soul Force, a side scrolling SHMUP very much inspired by ThunderForce IV, a game I used to love to play. Soul Force did kind of grow into a monster of a game, featuring 20 different stages each with bosses and loads of enemies, plus tons of music to compose. Took far longer that I first thought, but the end result is something I’m really proud of.
And next came Zeta Wing, a vertical SHMUP inspired by the old arcade game Gemini Wing. Zeta Wing is all finished and will be released on September 25th, 2020.
Back To Briley!
But now I’m back to working on Briley! Latest changes have been to the player movement code. You see, when I started this project, the player could move anywhere by a pixel amount, which did cause me quite a few issues with background collision detection; I had some cases where there were narrow enough gaps for the player to get stuck, plus collision detection against sprite objects was a bit of a pain and had been largely ignored.
Plus, I had some character wobble when passing through narrow passageways 1 block high due to the way the background detection worked. To get around sharp corners, I had a system where if Briley walked left/right, any obstacles would “nudge” Briley either up or down to steer her around the corner. This works fine for avoiding bushes and posts, but not narrow passages, inducing a character wobble as the character is nudged up and down on alternating frames.
So I had a look at a few other of my favourite JRPGs on the Megadrive and noticed one thing they shared in common: all character movements were block based. What this means is when the player initiates a movement, the character will walk a full block width (16 pixels) before stopping.
Well, upon seeing this, I knew mine had to do the same. There are many advantages of this:
- Background collision detection becomes block based so is not just easier, but way more efficient as the code only needs to check if a block is clear once a block move has completed (which is once every 16 pixels moved).
- It makes it much easier to interact with objects and people as the player is always lined up with the interaction target.
- There’s no “wobble” when traversing narrow passages.
- Player can’t get stuck by parts of the background.
As a result of this, it became trivial to add collision detection with people; before moving, the code just has to check if a person is standing in the destination block, and if so, block the movement.
The only downside to the new code is that most of the cutscenes will now need adjusting (and I have loads) as some of them leave the player at a non-block aligned position. Oh well, a small price to pay for a change that makes life so much easier…
Cartridge Space Issues
In the past I was concerned about remaining cartridge space as that was disappearing fast! After a little investigation, I discovered a problem with my ROM file packer. You see, ROM banks on a C64 cartridge are 8K in size, so all my files have to be packed into 8K chunks.
But there was a problem where if all the files in an 8K bank added up to exactly 8K, an extra empty 8K bank was added to the cartridge, thus wasting precious space. After fixing that, I can now report 399K space used out of a maximum of 512K.
According to my game flow I’m currently working on day 19 of 25 (the game is divided up into “days”), so there should be enough space for the rest of the game. I still have more maps and sub-quests to add, so I still need to keep an eye on space, but I’m confident it will all fit. Besides, I can always do another text pass and cut down some of the longer cutscenes to something a little bit more concise.
Okay, back to the game…