Now serving Monster #43…

Made a nice push and got a LOT of code work done. All that’s really left in the Combat module is alteration spells (which requires retooling them for the new data design, as well as adding some new stuff like summoned creatures) and updating the combat end to include experience.

I side-stepped this weekend and worked on updating the monster data so that I could encode it from a text file instead of using a spreadsheet with DEC2HEX conversions. I’ve found this is a much easier way to update data because I can use my tool binaries to directly copy data into the files for very quick turn-around. This will be very important when I get into play-testing the combat engine, because I need to make sure monster statistics are easy to change. Right now, I’m pretty sure their health values across the board are going to be too low to make combat interesting, but we’ll see.

I had such success with my monster encoder tool, in fact, that I decided to also write one for map data as well. This has been a bit of a pain for awhile, so it was a relief to be able to write one so I didn’t have to hand-edit files with a hex editor in order to update small items. The only part of map files that’s still hand-edited is elevation data, because it’s RLE-encoded and with only a few maps having elevation, it’s easier to manage those directly than try and write an engine to do it. (I calculate the length of a map’s elevation then arbitrarily decide what sector it goes into in order to pack the data as efficiently as possible.)

Both these changes accomplished something else, the ability to refer to monsters and mob blocks in an abstract way. My mob and map data had to include monsters as fixed numbers originally, but when I renamed one and reshuffled the list they all ended up out of order. So by referring to a monster as “Ogre” instead of monster #53, it’s a HUGE reduction in time to add, subtract, or update monsters. Being able to refer to monsters that spawn by name is great because at a glance I know what monsters are assigned to a map and can make tweaks quickly and easily.

After I move some graphics around, I’ll be back on the combat module to wrap it up so I can focus on the encounter module. After that it’s a nice long debugging cycle of getting the game to run properly (fixing many bugs I’ve no doubt introduced with new code) in all it’s phases.

UPDATE:

Some mock screenshots of monster statistic screens. They can only be viewed when a particular spell is used.

This entry was posted in Coding, CRPG, Design, Screenshots, TI-99/4a. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *