Tilting at Windmills

Well, turned out that work did NOT slow down… so it’s been rough to find time to do a lot of coding.

I also managed to break a crown (one of those things they put on teeth) which made life interesting. My dentist sounded more put out about it than I was; dentists as a group are very quality-driven.

I did some file creation work and editing; I changed around some of my item graphics, and also had to totally redo my item list. The list is now dynamically sized with pointers in the main program to where specific items are located. This makes it nice for the demo, as I can size it to only have what’s IN the demo, and nothing more.

I’m also doing some thinking on the control systems. What I have in my current demo code (0.40) is just will-fit-and-works code. Ideally, what player is active determines what actions are possible. And this system carries into the combat engine as well, so it makes perfect sense to have one code block for this and just have it populate and branch based on the current state (travel or combat).

The code for the new statistic screens is mostly done, as are the new backgrounds, so maybe this weekend I’ll be able to make my 0.4a travel demo. I’d feel more comfortable if that was working well before I continue with combat work.

Had an enormously busy week at work, so it was difficult to find time to do a great deal of coding work… the crunch should end by mid-next week though, so I should be back on track.

Right now, I’m doing a lot of re-spec work. Starting the combat engine required me to decide on some fundamentals, and doing so causes the travel engine to see some major changes.

For example, I cut down the number of files, which freed up VDP memory that I could use for other things; I added another 256 bytes to the sound table which will hopefully let me get a few more nice sound effects. (I noticed I was missing a “victory” jingle.)

A big one was the addition of an FX data file. This contains 32-byte data segments that store the special effects data that’s used by spells, monster special abilities, etc. It’s amazing when you sit down and realize that tracking individual elements that go into an effect can take up so much space! Since they’re only used one at a time, it makes perfect sense to shunt them off to disk.

Unfortunately, this is pretty dry work… likely, I will make a version 0.4a, which will basically be the same as 0.4 except using the new file system and stat screens.

Of course, I could just continue coding the combat engine, but because I’m making it into a stand-alone program to testbed the combat balance, it’s important I keep the two portions of the game engine in sync with each other. Otherwise I’m in for a lot more work later to try and merge them together.

I changed pace a bit this evening, and went back to the travel portion of the engine to change the statistic screens.

I’ve cut out a lot of complexity, so that means I’ll be burning a lot less memory on these. I also compacted the data nicely so most of it fits on a single screen, rather than many.

The skill system has been dropped; I just don’t have the memory for a complex open-ended character system. So we’re back to classes, which can be hard-wired. No worries, there will be 9 to choose from, which should make for rich gameplay opportunities.

Here’s a mock-up of what the final new screen should look like. The code I’ve written tonight should produce this, but I’m sure they’ll be some debugging. Plus it’s dependent upon certain files and data tables being complete to work.

Wow, I guess I must be motivated. I started on my combat engine code on Friday evening, and next thing I knew it was 5am in the morning. I worked some more on it on Superbowl Sunday, several solid hours. And no, not even close to done.

I took my original code from version 0.40 and copied all the source files. I then started adding to and making new ones for the combat engine elements. It’s going to make it difficult to keep track of how large the code block is getting, but I can always re-arrange source later to see on a listing how large it is.

Since combat is such an integral part of a CRPG, I don’t want to sacrifice a lot. However, I may find myself paying for some of my earlier feature ideas; having over 20 different state variables for different spell effects may bite me now. I’ve already decided to store spell names on disk and only pull them in as needed, and there may be other optimizations down the road. Anything to avoid having to load the combat engine as a module.

A very useful tool has been ASM99, a PC assembler that assembles source into TMS9900 code. I’m not using it directly with emulation, but it helps me find all the bugs before I go to the trouble of loading the code into disk images for assembly on an emulated TI.

Of course, all it finds are typos and other simple syntax errors. It won’t tell me if I got the wrong word here or there, or if I’ve set myself up for a cascade crash effect. For that I have to actually run it on the system and see. I usually spend a lot more time debugging and hunting down problems than I care to, mostly because I lack sophisticated debugging tools. PC99 has an onscreen debugger which is useful for the really hard to track ones. I get the most mileage, though, by just code reviewing; it’s usually not that difficult to spot what’s going wrong, or to throw in some checks to catch a bad number.

I got a busy week at work, but I’ll probably end up doing a little work every evening. Hopefully by next weekend I’ll have something running I can put some screenshots up of.