![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/09\/shot1.png\")
<\/p>\nOkay, I spent several hours on code fixing, building, re-building, file editing, spreadsheet updates… all aimed at getting the game back on a (sort of) running basis. I also thought some new screenshots would be nice to splash around the blog.<\/p>\n
<\/p>\n
I updated the travel screen to remove numerical references to health, wounds, stamina and fatigue. I thought it was unnecessarily cluttering things up. I’m well aware that as the game designer, I know exactly how the statistics work. Because of that, I think “Why not just show all the values all the time? I need to see them for debugging after all…”<\/p>\n
It’s an easy trap to fall into to just display everything, because there’s no mystery to ME how it works. But part of a game is for the player to figure out how things work.<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/09\/shot3.png\")
<\/p>\n
I wrote a Trek game once that included a torpedo course calculator. But I realized that it more or less ruined the gameplay because it would tell you exactly what angle to use, and any guess work was removed. What fun is that?<\/p>\n
No worries, though, I won’t forget to show the numbers on the statistics screens. I’ve updated those to show the new reduced statistics. The party overview is also a quick way to see exact values if needed.<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/09\/shot2.png\")
<\/p>\n
My real focus of the debugging was to get the combat engine back to a state where I could start debugging what was going wrong with the visual displays. (Which internally is called the FX code.)<\/p>\n
Fortunately, it turned out to be pretty easy to convert the engine to an “act immediately” state rather than save actions up. I also recovered several hundred bytes of memory that was being used for action processing, although I’ll have to back later to figure out how best to make use of that.<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/09\/shot4.png\")
<\/p>\n
I’ve found the easiest way for me to debug and fix issues is to keep a notepad and pencil by my side as I run through the code. Any bug I see is written down on the list. Once I have a substantial number, or the program crashes, I go to the source to find the causes for each bug. As I fix them, I cross them off the list. Then I recompile and re-run the code, and validate that each bug got fixed.<\/p>\n
Once I got movement working, the engine felt MUCH more playable and enjoyable. I really like the effect that actions have as well; you’re left with a real tactical challenge. Do you move into position but cost yourself some fatigue? Or do you wait a turn to let the opponents come to you, and enjoy a little defensive bonus?<\/p>\n
Guarding and movement was easy. Attacking, though, proved to be extremely buggy. I finally had to find a decent breakpoint in my code (Classic99 is awesome, but Visual Studio it is not…) and halt the action to step through. And that means going through ALL the code, including the incredibly long and painful disk routines to load data.<\/p>\n
I found several issues in the FX code, including an annoying one with Unit ID’s. Each “character” on screen, both players and monsters, have a unit ID in a byte form. This lets me determine on the battle map who is where. Unfortunately, the ‘0’ value is used to indicate a movable space, but the various indexes are also zero-based. Which means every time I need to convert Unit ID to some other array, I have to subtract one from it first. And I forgot to do that in two places.<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/09\/shot5.png\")
<\/p>\n
This actually explains why behavior was so inconsistent before with hitting creatures; it wasn’t finding the creature in the expected location on the left, so the game continued, but if I attacked upwards it DID find a creature, and moved into the buggier code. Which you can see in this screenshot….<\/p>\n
Any 99’er programmer in assembly should immediately recognize what this screen means: seriously bad mojo with your video manipulation. Usually this is caused by a counter value being way off. Your routines end up overwriting all of VDP memory, which makes sound, graphics, and sprites all go haywire.<\/p>\n
At least now I know where the bugs are occurring, I just have to step through the code and find the bad values that are causing the problem. It will probably be something VERY simple. After I get basic melee attacks working, I’m moving on to ranged attacks, then spells. I also have a lot of commented out or hard-coded values for setting up the battle map and unit placement; this all needs to be replaced with working code and tested too.<\/p>\n
Oh, and at this time, I’m hovering right below 20,095 bytes of space used in the 32k memory expansion. I converted my program to use the CPU RAM space in the cartridge (located at >6000) for RAM space, so that I can spill over into the lower 8k with code. I’m pretty confident I have enough memory to complete the game.<\/p>\n","protected":false},"excerpt":{"rendered":"
Okay, I spent several hours on code fixing, building, re-building, file editing, spreadsheet updates… all aimed at getting the game back on a (sort of) running basis. I also thought some new screenshots would be nice to splash around the … Continue reading