Briley Witch RPG Diary – 14/12/2017

Okay, it’s time for an update for my C64 RPG. I’ve been a bit quiet recently, working through lots of cutscenes for my game. But there have also been some technical changes, thus this blog post.


Changes.

I’ve decided to change the mapping system I’ve been using for the game. I was using a tile-based system, but have changed it to a pure block system. What does this all mean?


Well, my map editor uses blocks for the background, each block 2×2 characters. These are used to form a block map. To save memory, I’d decided to use a tile map in the game, a tile being 2×2 blocks. Therefore, each tile represents 4×4 characters. On export, the map editor could scan the block map, create the tiles from 2×2 block patterns, and thus export a tile map. Advantage of this: instead of loading a 90×90 block map, a tile map would be 45×45 tiles, reducing the map size down to 25%! Quite a saving! But, there is the memory overhead of storing the tiles, and I’d allocated space for 256 tiles max. That’s 1K of extra RAM. Combined RAM usage of tile map and tiles: 3K.


So tile maps are great, right?


Well, they do cause problems. For a start, one of my maps, the main Maepole village map housing the Baxter’s residence, managed to use up all 256 tiles! Every time I rearranged the map to gain back some tiles, I’d add more graphics and hit the limit again!


And I still had plenty of characters spare in my character sets, thanks to my 64 char inside/outside swapping system I implemented earlier. But if I added more blocks, I’d add more tiles… Aaaaagh! Sometimes pushing boundaries is a bitch!


But in my quest to make the maps larger, I’d just made more distance for the player to traverse when all they want to get from point A to point B. Plus, it’s harder to make the maps more interesting when they are larger… More interesting means more blocks, and more tiles… and me hitting my tile limit over and over again…


Solution: ditch the tile mapping and instead use just a plain block map. More RAM on the block map, sure, but a lot less headaches!


I’ve reserved a 4K block of RAM for the mapping system. With a tile map that equated to 2K for the tile map, 1K for the tiles, 512 bytes for the blocks (128 max), 256 bytes for the daytime colour attribute table, and another 256 bytes for the PUCrunch buffer/night-time colour table. That would mean a max tile map of 45×45 tiles, or 90×90 blocks. But with a block map, I can move the colour attribute tables to elsewhere (using up 512 more bytes), leaving 512 bytes for the blocks, and 3.5K of RAM for the block map. This gives me a maximum block map size of 64×56. Yes, smaller than before, but also quicker for the player to traverse.


So I’ve gone through all the old maps, reducing them in size where possible. The largest map I had was 74×74 blocks, but with a bit of tweaking and a lot of moving of sections, that’s now down to a size that’ll fit.


Just.


But I’m so much happier now! Okay, so I had to go through the pain of fixing all the cutscenes (due to sections being moved around), but that wasn’t too bad. I’ve played through the entire game (well, as much as I’ve coded so far), and it feels much better now.


I’ve also changed the mapping system to handle interiors better, the exporter able to use the zone list to throw away unused areas of the map and thus save more precious RAM. The exporter also tells me how much RAM the map uses, so I can immediately see if it’ll fit or not.


Block Swapping.

One major advantage of using a block map is I’m now able to swap blocks on the map. So, if I need a house to have a closed door, I can do that! With a tile map that was pretty much impossible, as any attempt to add more tiles would push me over the limit.


Since I use what I call Interaction Points (IPs) on my maps, to implement block swapping, all I had to do was code a new IP type: block swap. So now I have the following types: draw, interact, trigger, and map swap.


I’m using my Enables system (a system-wide accessible 128 byte array of flags/values), and this controls the on/off state of the block swap.


I can have either one-block or two-block swapping, the two block variety being used right now for the doors. Now, I can close doors on houses I don’t want the player to be able to enter, thus controlling the flow of the game better.


The map swap system is triggered either by calling a screen refresh subroutine, or when the screen is “rolled in”. Since I can’t fade the screen, I use a roll-in / roll-out function; this is the best time to swap blocks in the block map, when there’s nothing being displayed.


The new block swapping system opens up all sorts of possibilities. One of these is for treasure chests:


[image error]Closed / open chests using background block swapping.

Instead of using a sprite, I can now just tweak the background, swapping between a closed chest block and an open chest block; also frees up a couple of sprites! I’ll be using this new system as much as I can; once changed, blocks on the block map use zero processing, and less sprites!


No, I’m Not Procrastinating!

No, honest, I’m not! Okay, so it feels a bit like it sometimes, but I’d rather get the correct systems in place now than have to alter everything later. RAM is still a concern, my game code RAM down to 6K.


I keep telling myself I’ve lost at least 512 bytes due to the new block map system, but will benefit massively later! Plus, I’m making full use of the cutscene system, the ability to load a block of 4K of text/code/data from the cartridge for bespoke parts of the game a major plus! I keep adding new cutscenes, but I’m guessing that’s the nature of a beast that’s an RPG. Still, RAM is a worry, so I’ll just have to keep a good eye on it…


Right now I’m about to get back to finishing the Day 2 code, the part where Briley has to brew mint tea to help the villagers. Almost done with that, so next step will be the Day 3 code, a re-visit to see old witch Branwen. Day 3 is also the point where Briley gains all her witch powers, so that’ll be lots of fun! Good thing is, I’ve already coded the magic system and most of the combat system, so hopefully I don’t need to code any more major systems.


I’ve still got a long way to go, but I feel like I’m making progress. Plus, I’m loving coding this game! Overcoming obstacles I love to do, pushing the boundaries of what’s possible as hard as possible. I still question if I’m mad coding this game, but then I know I’m mad! Well, fun loving crazy mad!


Okay, back to coding…


 •  0 comments  •  flag
Share on Twitter
Published on December 14, 2017 15:34
No comments have been added yet.