Transacting Scripts

My focus remains on turning out a working and complete demo of the game… I’ve written a bunch of code I haven’t even had a chance to test yet. And I’m currently working on plotting out a long-neglected portion of the game; complex transactions with NPC’s.

I’m doing SOME stuff that isn’t entirely practical. For example, I’m finally working on finishing the title screen. I had always been stymied by the fact I didn’t really want to take the time to plot out the thing in a paint program. (ESPECIALLY in TI-Artist, which is incredibly painful to use for pixel plotting. Multi-color mode, blech!) I finally found a low-tech sneaky way to do it… Transcribe the character graphics myself by the naked eye into the bit patterns and hex-edit them into a Paint N’Print file. (Paint N’Print is my favorite editor; the zoom mode is perfect!) I can then colorize it later in the paint program.

So, about those transactions…

I decided early on not to have a text parser in the game. (Basically, a cursor which would allow you to enter key words.) My decision was based upon two things:

1. Text parsers are a pain to implement and error check in assembly language
2. Too much like Ultima

How can being like Ultima be bad? Well, Ultima IV is actually very simplistic; there is a maximum of 32 NPC’s in each town, and each one has a single 288 byte record to store all their conversations. (Except for special NPC’s like Lord British and Hawkwind, of course.) If you look, the actual depth of each character is shallow; each character only has two potential keywords beyond the baselines (name, job, health) and a single question and virtue that is affected by it. Ultima V is slightly more complicated with the day and night cycles and NPC schedules, but conversations are largely the same structure.

Also, there’s a certain degree of “I want this to be MY game, not just a copy of Ultima.” There’s been too poor-man copies of Ultima over the years (Gates of Delirium comes to mind…) and I want my game to stand out as something that is entirely itself.

Another aspect of my design is, I want the game world to CHANGE based on the player’s actions. All too many old CRPG’s have worlds that largely remain the same, even after the player has accomplished things. You save the town and they’re STILL talking about the danger?

So, there are two kinds of NPC’s in the game, simple and complex. The simple ones are much like the NPC’s in Ultima III; they have a single response they say and nothing more. There will also be map flags for each area so that if you have achieved certain goals, they say different things.

Complex NPC’s though, are another matter. For those, I’ve had to create my own little scripting language.

Essentially, each complex NPC has a set of local flags (one byte’s worth, one of which is always the “visited/revisited” flag) and a set of transaction records, each one word (16-bit) long. If the average length of these transactions ends up being a consistent size I may just convert them to longer records and live with a little wasted space.

Each word has a code indicating either an action or a query, with a variant amount of data after it. For example, it may check that a certain flag is set. If so, it moves to the appropriate spot in the transaction string using a positive/negative offset value, and continues transaction processing from there. It can display messages, set up options for the player to select from a list to determine a series of next results. And it can give money (or take it), items, or make changes to the party and player data as needed. A veritable transaction engine!

Here’s an example of how it may look:

TRANSACTION

OPEN:
IF Visited_Flag    (4)
    DISPLAY Intro (4)
    SET Visited_Flag (2)
    BRANCH Options (2)
ELSE
    DISPLAY Revisit (4)
    BRANCH Options (2)
OPTIONS:
    OPTION Question_1, Question_2 (10)
    SELECT Option (2)
    IF Option_1
        DISPLAY Read_1, Read_2 (6)
        BRANCH OPEN (2)
    IF Option_2
        DISPLAY Take_1 (4)
        SET Quest_Item_0 (2)
        CLEAR Mob (12)
        END Transaction (2)

Total: 58 bytes (29 words)

In fact, as I was designing the system, I realized that I could use it to replace some things in game. For example, I originally had fountains as a stock object in game for dungeons and places, that would have variant effects upon you. But I’ve been leaning towards removing them as a more “gamey” object more appropriate to old-school first-person dungeon designs, and I realized that I didn’t even need to HAVE special code for them. I can just make a fountain a transaction if I still want one!

I did briefly consider integrating shopkeepers into the same transaction system, since it’s already going to be doing a lot of heavy lifting. I decided against it in the end, though, because with shopkeepers, I have much more predictable data structures. That will let me write much more streamlined code to handle the transactions for those.

The only pain point with this approach is that coding the actual scripts up is going to be a pain. Since all the offsets are going to be localized and fixed, that means they will need to be updated with any changes. I’m going to initially try and set up an Excel spreadsheet to store this for me so I can (hopefully) just copy out a clean hex string to paste, but we’ll see how it goes…