The combat module is finished! I ended up moving combat end determinations into the Encounter module, so that work will be completed there.
Now that I got some code space to spare, I may have a complex “You found a chest, open it?” event at the end of combat. Another opportunity to throw in some traps… 😉
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.
So it turns out that 12k was NOT enough for both combat encounter generation and management. I had 1K left and still a ton of things to write. So I’m splitting the encounter portion into a separate module.
Fortunately, this is easy to do. The “encounter” module will do the following:
It then immediately shifts to the Combat module.
Doing so has already freed up nearly 4K which should be enough to get the job done. It also nicely separates the encounter work (which has a large amount of influence from content) from the actual battle management.
This means I have to increase the base size of my program file to accommodate another module. I may add another 24K just so I have a little extra data space; I already load in 8K segments from disk so it doesn’t hurt to add extra for graphics space, sound data, or other data needs that may come up.
I had to restructure some basic models for how player data was stored as well, as it turned out it was better for combat determination to have the system treat players and monsters as agnostic entities. This required moving some data around, which will probably create some fun regression errors for me to fix elsewhere. 😛
Funny enough, I found myself nearly repeating the same mistake that Richard Garriott did in Ultima III, which was to forget to include weapon/armor values in attack/damage calculations! 😀 A big change from the prior design is now it adds in all the calculations dynamically rather than trying to store them in arrays ahead of time.
I’ve updated my Progress page to reflect the new module as well.
So, now that it is July, the year is more than half over. My intention was to have the game complete by the end of the year. Will I make it? We will see…
I changed tactics and stopped working on the encounter engine, which was devolving into creating graphics and other more content-related work. Instead, I went back to trying to convert existing combat code. This turned out to be a good idea; a lot of elements need to be figured out in the new design, plus I need to find out if my 12k segment for combat will be large enough for everything.
I had to make a few changes to the FX engine code to support boss monsters, as well as convert it to read FX data from CPU memory pages instead of loading them from disk. Fortunately the code beyond this is largely unchanged.
I also need to add support for new concepts, like summoned creatures by players. I realized I could just have them be new monsters added to the unit list, but with the “charm” effect enabled. One the charm clock runs out they turn hostile on the player.
On the subject of units, I redesigned my arrays to store the unit type (including if they are “dead” or not, a player or monster, etc.), unit graphics (A zero means they’re invisible, don’t render them on screen), and unit coordinates. (A -1 means they’re “off map”, which only players can do, fleeing the combat.) Hopefully the combination of these three will cover all my bases!
I may do one extra thing, which is have player data copied from their normal arrays into a block adjacent to the monster state blocks. I’m having to write a lot of “specialty” code to do considerations between player vs. monster, and it’s getting annoying.
I’m hoping by the end of this month I’ll have the bulk of the code converted and can return to encounter design/generation.
Another quick update…
It’s been a busy couple of weeks, and at the end of this week I’m going to ACE Comic Con in Seattle, so it’s going to stay that way!
I’ve been working on the dynamic battlemap generation. The work is going slowly because I’m designing the algorithms to create the maps in tandem with graphics updates to support them. I think the end result is going to be VERY cool but right now there’s just nothing to show off.
The combat engine is going to be a bigger job than I anticipated, because I’m also re-designing the main screen from my original code, and there’s a lot of new additions and changes from the pre-AMS code. (Multiple monster types, big monsters, and so forth.)
Update: Here’s are some mock screens of combat just for fun!
Sorry for the lack of updates recently. Work has been brutal and the weather (sunny and VERY warm) has necessitated spending more time outdoors mowing and doing basic yard maintenance.
I did a little testing and found some bugs in various places. I’ve written up some encounter code for combat to have the display tell you things like “You face a raging bear!” or “You face an acidic slime and 2 giant rats!” I encoded pluralizing monsters as a single code so that I could still have unique cases like “wolves” verses “wolf” and the typical “just add an s on the end” case.
Despite being distracted by the idea of writing a more complete version of Donkey Kong for the TI, pushing on with the CRPG work!
Here is a video someone recorded of me giving a presentation of the CRPG.
Damn I need to lose some weight…
When: Saturday April 28th, 10am – 5:30pm
Where: Vancouver Public Library, Klickitat Room, 4th floor
Hope to see you there!
Continuing to work towards the big demo at Fest West ’18… I’ve gotten far enough with my testing of the travel and manager systems I think I can safely stop testing there and see if I can get the combat module going.
That’s not to say there isn’t bugs to fix; I’m pretty sure many dungeon features aren’t working yet, and there’s plenty of bugs with content to look into as well. But with two weeks to go I’d like to take a crack at it. Worst case scenario I just leave combat disabled for the demo.
I’ve spent a lot of time tuning and polishing up the statistics screen, so let’s have a look with a comparison, shall we?
Tunnels of Doom Player Screen #1
Tunnels of Doom has a couple screens for your individual characters. They do a decent job of conveying information, and also show the portrait of the character in both a passive and attack stance.
The second screen shows a list of items you’re carrying. If the item is unknown you aren’t told what it is, just that it’s, for example, an “Untried Potion”.
Tunnels of Doom Player Screen #2
Finally, you have the party screen, which shows you how much money and rations the party has, quest items they have and how much time they have left to find them. They also provide the health and wound status of the party, using the graphic characters as a quick reference.
Some negatives about them? Well, it’s all very plain, although this is more a factor of Tunnels of Doom itself, which was written in 1982. They also are not utilizing the entire screen, only 28 columns, because at the time they were fairly certain 90% of their customers would be using an RF modulator on a TV, which tended to cut off the first and last two columns. And finally, something not conveyed by the screenshots, the screens are VERY slow to load, you can visibly see text being projected on the screen. This is because Tunnels of Doom was written in GPL, a low-level byte-encoded language that had to be interpreted.
Tunnels of Doom Party Screen
Despite the issues, I always loved the stat screens. Aside from the fact it contained needed information, it really gave the game a greater feeling of depth. When my brother and I first played we would naturally name characters after ourselves and friends and then take turns each moving our character in combat. Does that even happen with party-based CRPG’s anymore? Probably not, since the modern equivalent would be siblings playing an online game at the same time.
Player Screen #1
So, I was definitely inspired by Tunnels of Doom when I made my stat screens. Of course, I have a few more since the game has greater depth…
All the screens load very fast. I initially considered using a two-screen buffer system and doing a screen swap to guarantee clean breaks, but in practice I’ve found it draws fast enough on the same screen that you don’t notice any blips.
Every screen has the character name, level, and class at the top. Having each character have their own separate “avatar” is always good to establish a sense of identity.
On the first screen, you can see attributes, health & wounds, stamina & fatigue, move & actions, experience threshold and current values as well as skill points. Your Health and Stamina are determined by attributes, which are fairly fixed through most of the game. Level also contributes to them. Skill points are used to train up skills, you gain one every time you level plus in special circumstances.
Player Screen #2
The second screen shows all your current skill levels. Skills are determined by class at the beginning and then you can choose which skill to advance in, if you can find a trainer that will teach it… The “Affinities” is concerned with magical schools; different classes are stronger in certain forms of magic than others, at least at the beginning.
The third screen is your equipped items. Each item type in the game has an icon, so you can discern what type it is more easily than just by the name.
Player Screen #3
There’s a lot of shorthand about the items themselves, the manual will need to give explanations. The staff here, for example, has +3 to hit (on top of the skill your character has in melee) and does… Piercing damage? Hmm, bit of a bug there. 😀
Anyway, it does 1-7 points, not including a strength bonus, and is 2-handed, which means you can’t wield an off-hand item such as a shield while using it.
Player Screen #4
The tattered gown is cloth armor, and offers no significant reduction against any damage type. It does offer a +1 to defense, though, which means it allows you to evade attack but doesn’t reduce normal damage or grant any resistance to magical damage. It doesn’t slow you down though, no change to movement.
The fourth screen shows your backpack and all the items you have within it. Needless to say, and empty backpack is a sad one indeed… A major factor of game play that I have yet to test is if ten item slots per player will be enough. Other than ammunition, all items occupy a single slot, so I need to see if that doesn’t create issues.
Player Screen #5
The final player screen, which only shows up for characters with spellcasting ability, is the spell screen. This shows the spellbook currently equipped, and the spells contained within it. The beginning spellbook only has colorless or “gray” spells, the weakest as no affinity bonuses apply. It has a nice mix of utility and combat spells though. A bonus prize to anyone who can identify the source of the spellbook name…
So that’s the player screens. The party screen is very similar to Tunnels of Doom, as you can see…
Party Screen #1
At the top, we have the party’s money and rations. I have actively avoided using the word “gold” because I have always found the concept of thousands of gold coins to be a little ridiculous. In game, various NPC’s will refer to coinage by different names, but it all just becomes “money” in the end, which is a bit more abstract. Testing the economy will be interesting… I currently am only using a single word for wealth, so 65535 is the maximum amount of coins you can have. I’d like to keep it there, but it all depends on how much you got coming in and going out.
Party Screen #2+
Each character name and portrait is shown, along with their class, wounds & health, fatigue & stamina, and current active states. I followed the pattern of Tunnels of Doom by having wounds and fatigue being an amount that counts against health and stamina. I’m not certain though that the display works for this… It looks like you have 0 out of 12 health. I may need to change the labels to DMG and FTG instead?
The second screen, which is woefully empty, contains a list of quest items. There is a potential of 64 different quest items in the game, so I had to design it to allow for multiple screens if needed.
At one time in my design, I considered having a quest system. That would have been shown on the party screen as a list of tasks to accomplish. This idea ended up getting factored out though; the various NPC’s are able to give rewards of all types (money, items, experience, skill points) and given it’s a vintage game, it’s only fair to ask the player to, you know, take some notes. 😉
Okay, back to work! I got some bugs to fix still…
Working on the CRPG and fixing bugs has been rather like fighting HYDRA lately… cut off one head, and two more take its place!
I decided to convert my item and spell lists to use bit-delimited strings to save some space and bring it more in line with how I was managing in-game text. Quest items and trap names are still in fixed size buffers because I would have to create a word-size look-up table to convert them, and the byte savings would be minimal at best. Maybe later…
I definitely have to be more careful now with swapping memory pages. For example, the transactions and the item names are in separate pages, so accessing the latter means losing the former, temporarily. So in some cases I copy data into a temporary workspace so I don’t have to page-switch in the midst of another operation.
At times I’ve wished I could swap memory pages into the cartridge RAM area at >6000 to >7FFF, but that would make the game require a SuperCart. (An Editor/Assembler cartridge with at least one 8K RAM bank.) It’s not necessary and I like that the game can auto-load from Extended BASIC.
I also re-wrote my Effects engine into something less platform. In practice the original design worked, but I kept having small regression errors creep in as I tested new things. So I just made each effect a separate function, with some copious recycling and re-use. It takes up about the same amount of space, and it’s much faster too.
I feel like I’m making progress though. I need to make sure the item and inventory systems are fully functional. I also need to test every mob type, which includes traps and doors still. After that, I should be able to pick back up combat engine work.
