Halfway Point

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.

Posted in Coding, CRPG, Design, TI-99/4a | Leave a comment

Working On It

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!

Posted in CRPG, Design, Personal, Screenshots, TI-99/4a | 1 Comment

Crickets…

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!

 

Posted in Blog, CRPG, Design, Personal, TI-99/4a | Leave a comment

Demo Video

Here is a video someone recorded of me giving a presentation of the CRPG.

Damn I need to lose some weight…

Posted in Blog, CRPG, TI-99/4a, Video | 7 Comments

Fest West 2018!

When: Saturday April 28th, 10am – 5:30pm

Where: Vancouver Public Library, Klickitat Room, 4th floor

Hope to see you there!

 

Posted in Blog, TI-99/4a | Leave a comment

Character Resume

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…

 

 

Posted in Coding, CRPG, Design, Screenshots, TI-99/4a | Leave a comment

Cut Off One Head…

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.

Posted in Coding, CRPG, Design, TI-99/4a | 4 Comments

Slants and Wraps

It was a frustrating weekend filled with regressions and complex problems to solve…

The travel module is by far the oldest code in the game. Iterations of it go back all the way to 2005. As a result, some things that DID work long ago weren’t working now.

Boats, for example, were completely broken. At some point I completely removed my original code, so I had to re-write it from scratch.

A big part of that was that I decided not to have your boat “carried” by moving water. The main issue is that it breaks the turn-based nature of the rest of the game, and it also requires checking for moving water tiles on an interrupt.

Light was another broken part, I found every single cave I went into was fully lit. I investigated and discovered I had never re-integrated light properly after changing the LOS algorithm. This lead to a two-day maddening exercise where a few simple code changes BROKE the LOS algorithm and I had to chase down why.

But the worst thing this weekend was slants and wraps.

I designed the map engine to allow me to project maps not only in squares or rectangles, but also as rhomboids, a slanted rectangle. This means making sure that when both you and mobs move, they move with correction to the X axis in relation to the Y to account for the slant. It also affects placement of mobs in the map window. The short explanation here is, you NEED your  Y differential because you need to calculate what actual window thresholds are per line. It took a lot of experimentation and code cycling to get this right.

The other thing maps can do is wrap. Normal map mode just extends the last character on the edges to infinity; stepping off the map forces a reload to a new map. Wrapped mode means it projects to the other edge, and creates a closed loop. Projecting the map isn’t too bad, but mob placement once again gets complex; you have to account for the fact that a mob and you could be at opposite ends and thus extremely close, not far away.

On the plus side, transactions are working well. I got the gambling module working great, and buying and selling works too.

Next on the list, I have to fix up some other services (healing, identifying) and make sure the new inventory system (removing and using equipment and items) works as intended.

Posted in Blog, Coding, CRPG, Design, Screenshots, TI-99/4a | 3 Comments

A Quick Word

My work at converting the dialogue system to sectors instead of records is complete! Now all incidental text for a given set of mobs is stored with the mobs themselves, and transaction text is with the transaction codes.

Effectively, you only need three pieces of data and a sizable buffer space to do variable-length records in a sector system: The base sector to start in, an offset value in that first sector to start your data at, and a number of sectors to read. In my case, my VDP file buffer has a maximum size of 4K, which is 16 sectors. More than adequate for my needs, it fits neatly in a single page of AMS memory, and I can bit-pack the sector count as a nybble (4-bits) and use a single word to store both a base sector and sector count.

I tested it on the hardware tonight and it was VERY fast… loading a map or transaction takes a few seconds, but after that it doesn’t have to refer to the disk at all and pretty much generates the text instantly.

Onward with the bug fixing… At this point, I don’t think I’ll have combat ready in time for Fest West. But I think I can get most of travel and management done. We’ll see…

Posted in Coding, CRPG, Design, TI-99/4a | 4 Comments

Do-Over Dialogue

So… I need to re-engineer my file system for dialogue.

I hadn’t loaded the current game executable on my actual TI in awhile, so I decided to try, mainly to make sure I hadn’t introduced any problems. Initially I had to fix my file creation tools to make sure sectors were padded out properly; TI99Dir wasn’t happy with incomplete sectors when copying to disk images.

After that, the game ran well… until I reached my first bit of dialogue. Quick pause as it accesses the disk, and a single message pops up. Okay, not too bad. Go to my first complex conversation… and it’s literally taking 2-4 seconds to load EACH LINE OF TEXT. Including your dialogue options, which pop in like snails one after the other.

It’s my own fault, because I forgot a critical fact. Limit your single file accesses as much as possible. The overhead of opening, reading, and closing a file is not too bad if you do it once, but if you’ve designed a system that requires constant access to different files, you got a problem.

My first thought was, why not pre-fetch all dialogue for transactions? Well, no, that won’t work. It would STILL have to access each individual record, which means you’d offload the sluggishness to the beginning.

The answer is simpler than that… don’t store dialogue in separate files. Store it WITH the pertinent data you’re loading. Then you only do an open/read/close operation once. As long as you have the buffer space for it, you can read in all the data at once. CPU memory is NO concern with the AMS, I can earmark pages to store data.

This means abandoning the record file system and using direct sector access as well. So I’ll need to re-write my content tools to generate tight and compacted sectors of data with offset values and delimiters. It will be a LOT of work to re-write but the end result should be a much better experience on the actual hardware.

It also makes me realize my original non-AMS design, which relied heavily on off-loading data to disk, even things like item names, would have ran like a snail in Doc Martens on the actual hardware. I’d have been so disappointed and frustrated if I’d continued down that path!

Some disadvantages is I lose the ability to avoid duplicate text. Your common dialogue options, for example, will either have to be replicated in every data block, or I will need to consider a “common/custom” system so it can read options from memory for common ones (Buy, Sell, Leave, etc.) and from the data block for custom ones.

The other problem is waste space has the potential to be worse; I may end up with a lot of unused bytes in a given sector because I simply don’t have anything to fit in there. I think I already had a lot of waste though in the current file system, so it may not be too bad. I won’t know until I assemble a new model and see how the numbers look.

Finally, one particular data set (mobs) will require me to save the data BACK to disk. That means preserving the original sector data for saving. Mostly house cleaning concerns, although if my mob files get larger due to storing text data, it may push them beyond the game disk’s size. I may have to abandon the idea of making the game work with 180K DSSD disks and go right to 360K required.

Best roll up the sleeves and get to it then…

Posted in Coding, CRPG, Design, RPG, TI-99/4a | 1 Comment