Tilting at Windmills

What’s that title mean? That while you can drive nails and screw-in screws without tools, it’s a much longer and more exasperating process…

Tools for development are always needed. Besides my map and graphic editors, I have also wrote tools in Windows (in C# .NET) to handle some of the more automatable tasks. My text compression is an easy one; all I had to do recently to it was modify it to process a whole text fine line-by-line so that I could paste an entire block instead of one at a time.

But until I got VERY deep into design on transactions, I hadn’t realized that doing things by hand wasn’t going to cut it.

I’ve made one other decision; all NPC interaction is now tracked through transactions. This includes buying and selling items. As I was writing code, I realized it was just easier to have a single entry point for everything.

My original plan was to just hand-code the transactions myself, storing them in an Excel spreadsheet. I started to write out text files to describe each NPC and what they were doing. But as I did this, I realized how complicated it was getting. Plus, every small change would force me to re-do every single reference that was to an offset position. I would be reduced to gibbering insanity in a VERY short order if I had to do that. 🙂

The transaction system is a word (2-byte) language that tells the game what each NPC does. For example, the code to display a message on screen is “!MSG” followed by a list of dialogue codes. Dialogue is structured as “0-5”, which means dialogue file 0, message 5. If I have several comma-separated messages, it loads and displays all of them in a block.

Here’s an example of a text file describing a sage in the first town:

#Sage

?LOCAL_FLAG 0,Visited,NotVisited

NotVisited
!MSG 2-26,2-11
!LOCAL_FLAG 0=1
!BRANCH OptBuild

Visited
!PMSG Two,1-14,1-33

OptBuild
!OPTION 0-6,Q1,1-12,Q2
?QUEST_FLAG 1,OptBuild1,Select

OptBuild1
!OPTION 0-7,Q3

Select
!INPUT Select

Q1
!MSG 1-13,2-20
!INPUT AnyKey
!BRANCH Start

Q2
!MSG 2-25,2-18,1-6
!INPUT AnyKey
!BRANCH Start

Q3
!MSG 3-3
!INPUT AnyKey
!BRANCH Start

#Sage end

The # symbol is used to indicate the start and end of a transaction block. This allows me to add commentary in-between blocks if I need to; my intent is to have one large text file containing all of a disk’s transactions for processing.

When in a block, there are two kinds of commands, actions (!) and queries (?). Queries check values and branch to labels inside the transaction based on true/false conditions. Actions do things like display messages, alter data both in memory and on disk, start a battle, etc. Any line that has neither a ? or a ! is considered a label and gets added to a list to note it’s position in the transaction array. (For now I don’t have a “comment” symbol, but I could add one if I need to.)

Let’s go over it, shall we?

?LOCAL_FLAG 0,Visited,NotVisited

So first, we check a local flag. There are eight of them in a byte, so they are referred to by position, 0-7. Every NPC in the game has a local flag store of a byte, for tracking changes and states. #0 on all of them is being treated as the “visited” flag. This indicates whether or not this NPC has been interacted with before. This lets us have an NPC actually remember that the player has interacted with them already and respond as such. The first label after the flag number is the true case, and the second is the false case.

NotVisited
!MSG 2-26,2-11
!LOCAL_FLAG 0=1
!BRANCH OptBuild

If the player has not visited the Sage before, he has a few greeting messages. The visited flag is then set to 1, and we branch to the OptBuild label. After this, the player won’t see those messages again. When the player leaves the map, all the existing mob data is saved, including the new flag states, so returning later won’t restore them to blank.

Visited
!PMSG Two,1-14,1-33

If you have visited him already, he has a follow-up greeting. !PMSG is actually a “plural message” command. Given that the size of the party is entirely determined by the player, I wanted a message system that could deliver multiple messages based on how big the party is. The keyword “Two” indicates there are two variations, a single and a multiple. The first message is the singular party member version, the second message is the multiple party member version. There is also a “Three” version for cases where an NPC may say “You”, “Both of you” or “All of you”.

OptBuild
!OPTION 0-6,Q1,1-12,Q2
?QUEST_FLAG 1,OptBuild1,Select

OptBuild1
!OPTION 0-7,Q3

The !OPTION command specifies a number of dialogues and branches that are choices for the player to make. These are added to a local memory stack for processing later. Two are added for two questions that are always available to ask. Then we check the status of a quest flag (#1) to see if it’s true or false. If a particular quest has been completed, we add a third option.

Select
!INPUT Select

The !INPUT command pauses the dialogue and waits for the player to choose one of the pre-determined options.

Q1
!MSG 1-13,2-20
!INPUT AnyKey
!BRANCH Start

Q2
!MSG 2-25,2-18,1-6
!INPUT AnyKey
!BRANCH Start

Q3
!MSG 3-3
!INPUT AnyKey
!BRANCH Start

So for each option, the Sage has a different set of messages. It then waits for the player to press a key, then branches back to “Start”. This hard-coded label is always the beginning of the transaction.

#Sage end

And that’s the end of the transaction block. So I run my parser on it and I end up with this:

05 00 0E 04 0E 02 20 1A 20 0B 13 00 01 14 0F 00 10 0E 10 21 11 02 00 06 00 2A 10 0C 00 34 06 01 22 28 11 01 00 07 00 40 12 01 0E 02 10 0D 20 14 12 00 01 00 0E 03 20 19 20 12 10 06 12 00 01 00 0E 01 30 03 12 00 01 00

72 bytes, or 36 words, to define the entire transaction!

Transactions are all stored as 2-byte records in one large file per disk. Looking over my initial calculations of size for different things, I will end up with a couple thousand records per disk. If sizes remain at a consistent amount, I may also increase the record size and pad out some of them with zeroes for quicker load times. (I don’t think it should prove to be a particular problem; the TI disk controller loads an entire sector into VDP anyway so as long as transactions don’t cross sector lines it will remain fairly fast.)

Now I just need to write up the code to process the transactions and do all the displays… fun fun!

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…

So I decided to switch things up a notch, and move over into monster A.I.

Why? Well, the FX spell system is now definitely working, the only tasks remaining are to implement and test out each spell individually. This won’t actually take too long. The only real complicated bit left is the alteration spells that cause battlefield changes, like creating a wall of fire.

I’m more concerned right now with removing a lot of the short-cuts and implementing the full pipeline for combat. This means actually checking for victory conditions, determining treasure, and returning back to travel mode cleanly. And as part of that… monsters actually doing stuff!

So my original architecture for monsters was, well… very ambitious. I had four different intelligence levels, the highest of which would consider spell casting as a “high threat” and target that character specifically. Every monster would have “aggravation” counters to determine who pissed it off the most. Spells would include at least two offensive and defensive spells: a ranged attack, a close attack, a self defense and an ally defense. And finally every potential action a monster would take would be weighted on priority and the best one selected each turn.

Then I realized how much code space it would take up to implement all this. I currently have around 8k of space left for code, and I still have a LOT of other stuff to implement. Creating the simplest and easiest monster A.I. to start with and then adding to it and updating it later when all the major pieces are done makes a lot more sense.

Plus, on screen, all a player is going to see is a monster take a step towards them. All that cleverness will be invisible and undetectable. Is there really a difference between a monster making a ranged attack on a character because it was the most properly weighed action, or just at random?

Plus, I don’t really want the combats to take a long time. Playing Ultima IV made me realize that when you have an awkward interface and no way to skip a lot of things, the combat can really become a hassle. (Get into a battle with reapers. You’ll see what I mean.)

And finally, it’s very VERY possible to make the monster A.I. just too damn good. If monsters all target the character who just threw a fireball at them with ranged attacks, that character won’t be alive long. It’s a general truth in most computer games that it’s pretty easy to write artificial intelligence that’s TOO good. You want it fun and challenging, not bone-grinding difficult to impossible. (Unless you’re playing Wizardry of course…)

The new simplified A.I. is pretty simple. A monster finds the closest target enemy unit and either moves towards them, targets them with a ranged attack, or targets them (or their location) with a special attack/spell. The one thing I need to add in and figure out is when a monster should use a close attack. A dragon breathing fire, for example, will want to have the player very close, and preferably none of its companions in the way!

I’m in a frame of mind now that before I release another demo, I should have as much of the game implemented as possible. That means not just the A.I. but also all the town services and everything needed to actually play the game. I really want to FINISH the game engine and start focusing in earnest on actually writing the story and designing the game itself.