Data Dump

Been quiet for a couple weeks… I’ve been heads-down on writing up all the transactions for the first disk.

Here is a breakdown on the first disk’s contents:

  • Dialogue is in game text, stored in four sizes. (16, 32, 64, and 128 bytes with compression)
  • Monster data is statistics, graphic data is self-explanatory. πŸ™‚
  • Map data is uncompressed maps, map headers are metadata, elevation data is for specific maps
  • Mobs are special objects on the maps
  • Transactions are scripted commands and actions for a given mob

The width indicates the record’s size in bytes. Estimate is how many records exist. Sectors is how many disk sectors (which on the TI are 256 bytes) it will take up. This includes a single sector used for tracking. And finally the size in kilobytes. The total size, 176k!

One thing to note here is that the mob file WILL change as the game progresses, so it will be both read from and written to. The other files are all read-only. I always had it on the table to move the mob files to the game disk just in case I ran out of room, but it looks like I should be able to get all the content I want for a rough 25% of the game into a single 180k disk.

The script encoder has been working out well… it occurred to me a few days ago that it’s nearly good enough to be a shareware CRPG script engine! πŸ™‚

The process of scripting has been interesting. I’ve been adding, revising, and changing the actual script language as I go along. For example, I originally had commands to do various byte/word manipulations so that you could spell out all the game logic if needed. In practice, though, this leads to a lot of repetition of the same kind of activities over and over again. While I could apply an effect and give feedback if a player doesn’t have enough money to pay for healing, it’s cheaper and more economical to encompass this into a !HEAL script command that just gives the internal engine the values it needs. (Cost, power, etc.)

I also ended up revising text, a lot. I now have a text encoder that encodes the entire disk’s contents and assigns record values for all of them, outputting the contents to a text file. I can then copy and paste those values into my text spreadsheet, which allows me to easily assign them contextually in scripting. I found I was gradually shifting text more into the larger dialogue files (64 and 128 byte size) over time, but in the end this worked out pretty well for disk space. The only downside to text revisions was it meant I sometimes had to backtrack and update references…

I also wrote a new tool, a text formatter, which formatted all the text lines to fit a 30-column screen. I found that I was often much too “wordy” in places, and that I had to both cut down the amount of text and make it fit better on the screen.

Ideally, writing a complete tool that stores all the text, mobs, and transactions would be the best thing to do. Then if you changed text it would just dynamically re-assign it for you. I’m not really sure I want to take the time to write up such a complex tool though, it feels a bit too removed.

Eventually, I’ll need to write a “transaction player” running on the actual TI. This would let me pick and choose a transaction to “play” so I can view what it would look like in the game, with tools to set particular flags on or off. This will make testing MUCH easier.

I’m nearly done populating data, what I have left to do is populate the monster data with treasure items (item revisions and changes has been ongoing) and then figure out the mob system for graphics. My new design will allow for up to 256 unique patterns, so I need to define those at least for the first disk…

After that, it will be time to work on engine code!

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

Moving On Up

If the site looks a little different to you, there’s a reason… I’ve relocated the blog!

My WordPress blog on Yahoo has been stuck on a prior version for several months now. When I contacted their customer support, they pretty much said they weren’t compatible with the latest and that they would have it working “eventually”. During which time none of my posts propagated to the main site unless I explicitly attempted (and failed) an update. I also ceased getting emails telling me that a comment was awaiting my approval.

I’ve been unhappy with Yahoo as a host for quite awhile now… Aside from the fact the company always seems to be on the verge of Chapter 11 these days, they split off their business web hosting side into a new company called Aabaco, part of some larger futile effort to avoid taxes or leverage more money out of it. The result is poor lackluster service.

We’ve been using AWS (Amazon Web Services) at work for the last few years, and I’m impressed with their work. In particular, storage space is very affordable, and running a WordPress blog should be pretty cheap! (After the first free year of course.) So I’ve relocated there and been very happy to do so!

Fair warning, I eventually want to put up some pages for my CRPG, so I may stop re-directing the main domain to my blog eventually. You’ll always be able to find it at adamantyr.com/blog!

Posted in Blog, CRPG, Personal | 4 Comments

More Ingredients

First of all, congratulations to Sinphaltimus for being the first player to win Wizard’s Doom! Along the way to a 93 rating, he also discovered several bugs I had to fix with the final encounter… Well done!

As I’m working on the CRPG, I want to make sure that the game has enough depth in play that it remains interesting all the way to the end. Some things I’m adding and changing in design:

  • Weapons, armor and spells now use a damage type system, with slashing, piercing, blunt, fire, cold, etc. This allows for nuances like a skeleton being tougher to kill with a sword than a club.
  • Weapons now have a throwing quality, so you can throw them in combat. Most are one-time use in this manner and it leaves you without a melee weapon for the rest of the combat. Some magical weapons return to you, allowing unlimited use in this manner.
  • As part of moving item names and attributes into CPU memory, I can also have a “readied” weapon approach much like Tunnels of Doom did. So switching from a melee to a ranged weapon to a spellbook takes an action point.
  • I may expand the party size from 4 to 6, but only allow you to create up to 4 maximum to start with.
    • On that note, I may need to add a “hostel” system of some kind so you can remove characters but retrieve them later.
  • I’m considering adding an “item storage” system so you can bank extra items for retrieval later.
  • After thinking about it awhile, I think I will add in attributes and also expand out the skill sets. Because I can keep more active data in memory more easily, the calculations aren’t as crunched as they used to be. My chief concern is to avoid having any classes become automatically “better” than another.

I’ve actually completed all the regular sized monster graphics for the first quarter of the game, which was a lot of fun to do. My “monster editor” proved to be an easy and fast tool to do the work with!

The “boss monsters” are taking more time, mainly because I’m trying to get them to look just right.

I’ve also been re-working monster statistics to match my new approaches. For certain damage types, reduction applies, for others it doesn’t. That means monsters may end up with a lot more health than the players typically have, since they may have no damage reduction at all against a particular common attack.

I still need to get the transactions done for content, and I may need to create some more tools to convert text listings into binary code so I can easily update item lists, monster statistics and so forth. After that’s all done I hope I can start working on the common and travel modules and getting the game engine back on it’s feet!

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

Putting it Together

Hello everyone… Or like, both of you. Or one of you. Maybe. πŸ™‚

I’ve actually been hard at work on the CRPG for several months now… After the TI faire I got myself an AMS card, which gives the TI a megabyte of CPU memory to play with. I decided that I wanted to upgrade the CRPG to use it, so that I could do a bunch of things I wasn’t able to do before.

The biggest pain point with this is the architecture change. Most TI software wasn’t designed with segment/module coding in mind, and as a result, there’s almost no way to write them. A gentleman named Art Green did write an AMS linker way back in 1993, but it’s a bit heavier than I’d like, and it would require me to do all my compiling in emulation rather than with an external tool.

So in order to make it work right, I will have to write three different sets of source code, one for each major module in the game coupled with a common module. Then I can compile each module to fit in the original 32K confines, take the compiled code and create the necessary binaries that will be loaded into paged memory. I’ll also have to write my own custom loader as well…

This approach will let me do some things I really wanted to do but due to memory constraints couldn’t. For example:

  • Double-sized monsters, occupying 4×4 characters. Perfect for large creatures like giants and dragons
  • Multiple monsters, such as a group of bandits accompanied by a bandit captain and a rogue sorcerer
  • NPC’s who can join a party that is under 4 characters in size along your travels
  • Graphics sets, items, spells and sound effects are all stored in CPU memory for much quicker load times! (I’ve been spoiled in emulation with extremely fast speeds)

Right now, I’m working on content. I realized I needed to have some actual game content to complete, test, and refine the game engine. So I have divided the game into rough quarters, and am working on the first disk, or 25% of the game.

What have I got done?

Well, the first thing I did was rework the graphics. Now that my TI is setup and running, I was able to re-evaluate them on an actual NTSC screen. I also decided to change my approach and use more colors to make them “pop” better… something MSX games did to very good effect. I’ve been very pleased with the results! This is definitely a TI game that makes FULL use of bitmap graphics capacity.

I then completed all the maps for the first disk. This was time-consuming, as some hadn’t really been even drawn on graph paper, and only existed in concept. I also didn’t want to waste a lot of map space on a map that had only one purpose, so I was removing and adding entries all the while. I also made elevation use an option, so not ALL maps have elevation. This saves some disk space and is more efficient, since most maps don’t need it.

A big change was I’ve dropped the idea of storing battle maps on disk. As I increased the terrain types, I realized the battle map file was consuming a ridiculous amount of memory. I was aiming to keep each quarter of the game to fit on a single 180K disk, and the battle maps easily pushed it over. So my plan now is to create battle maps dynamically based on the terrain around the player. I’m still thinking about that algorithm, but with the added memory it should be doable…

I also completed all the mobs (mobile objects) for the maps, although many have empty data values for monster tiles and dialogue/transactions. My goal here was to determine how many mobs I would need, and it worked out about where I thought it would, just over a thousand for 64k of maps. As part of this, I wrote a new tool in C# to create the mob binary coding from text files. This lets me make changes quickly and easily, then just paste the entire block into a binary file.

I’ve written out all the dialogue for the first disk, although I’m constantly adding and removing entries… My compression algorithm wasn’t quite as effective as I’d hoped; it averages about 18%. But for now it works pretty well. I’d have to write some tools to find common words in my actual text blocks if I wanted to try and write a better one. A job for another day…

I’ve also decided to make monsters game disk-specific as well… It just makes sense, monsters are geographically located and if you end up repeating a few it’s not a big deal. My initial write-up ended with around 84 monsters, but that could go up or down. This is ongoing work because I decided to give monsters a full bitmap color block, which means I have to redesign the graphics to take advantage. I realized that there weren’t really any good tools to do monsters easily, so I wrote my own! Hopefully I can have some fun with it while I draw them up…

The next stage will be writing up all the transactions. I have a few done, but it will take awhile to write ALL of them… and there will be considerable cross-referencing done with the mobs and dialogue on the way, which makes it very time-consuming. I figured I’d end up with at least 2k (2048) transactions before I’m done, but it could be easily double that. Fortunately they take up very little space on disk.

Once I have all the game data done, it’s on to the engine! My plan is to get the Travel module done first, followed by Management (Inventory & transactions) and finally Combat.

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

Running the Gauntlet

Hi all!

So I went to Fest West 2017 this year, down in Woodland, WA. It was a 3+ hour drive for me to get there, but well worth it. I met a lot of great guys and saw some pretty awesome stuff. I was even able to acquire a new NanoPEB that DID work with Wizard’s Doom (Apparently my CF card reader is, in fact, busted in some weird way) and an Extended Basic 2.7 Suite cartridge. Going to a convention for your vintage computer hobby is a lot of fun and it really helps inspire you to do more with it.

So what’s my next TI project? Well, I’m taking a short break (hopefully) from the CRPG to do something a bit different, an arcade/action game. I’m also returning to assembly language, because I want to really push some limits on the TI.

Specifically, I want to write Gauntlet for the TI. πŸ™‚

Why? Well, it was far and away one of my favorite arcade games back in the day. Even as a kid I was fuming that it was available on the Commodore 64, Atari 8-bit, and Apple systems but not the TI. And then recently I discovered the ZX Spectrum and the MSX platform had it too! πŸ™ Knowing a MSX version existed though made me realize it SHOULD be possible.

The first thing I realized was I could not use the baseline TI’s memory. Every single port of Gauntlet for the home computer system market had at least 64K of RAM, and it’s needed! In particular, storing graphics and animation frames consumes a LOT of space. So I am using the SAMS card to make sure there’s plenty of RAM available. This solves some other problems as well; I can use memory-over-time solutions in several places.

The biggest hurdle is going to be updating graphics in real-time. The MSX version (which I studied in a debugger) essentially keeps the character sets static in the upper 2/3 of the screen, only changing them dynamically in the lower 1/3 for the 3 rows of graphics. They also only change patterns and not colors for animation. I want the TI version to do better than this. πŸ™‚

I’m not going to call the game Gauntlet for a myriad of reasons, mainly because there are aspects of the game I don’t like that I want to make changes to/improvements on, and I also want to port some of the fun things from Gauntlet II into it.

Currently I’m working on a prototype scrolling map display to see how it performs. The basic algorithm is as follows:

  • Store the entire dungeon map as a literal set of tiles, each tile is 8×8 pixels in size. There are a potential of 608 unique patterns, so a full word (16-bit is needed.)
    • This will consume 8192 bytes, or 8k.
    • The map has NO mobs (movable objects such as monsters)
  • Extract the viewable area from the map into a buffer space, which is slightly bigger than the screen. Wrapping occurs if it goes beyond boundaries.
    • This is refreshed anytime the map is scrolled or mob movement is done
  • Iterate through a mob array, checking if a mob is present in the viewable area. If so, copy their tile patterns to the buffer in the appropriate location.
    • Also store the mob you just placed into a “visible mob array” which stores their local coordinates. That way you can quickly decide actions for mobs that can actually move.
  • Using a “character pattern index” for the section of the bitmap video display, create a “view buffer” that uses actual character pattern values (0-255).
    • If a given tile isn’t in VDP yet, get it there, either immediately or store it into a larger buffer that’s written all in one write.
    • If you run out of patterns, reset to zero and restart.
  • Write the character pattern changes to VDP.
    • I may utilize a hybrid bitmap mode so that the upper 2/3 of the screen use the same character pattern set for better speed.
  • Write the view buffer out to the screen. This may also include updates to the bottom statistic area such as health count and score.
  • On given interrupt intervals, change the animation patterns used and update accordingly.
    • This is where it could get messy; I may need to have a separate stack array that stores the current “mob” patterns that need updating in a given block.
    • For simplicity it may be best to just do a complete linear write of patterns and colors rather than trying to do them individually.
  • Animated static tiles (like treasure chests) are only animated in color, not pattern

The big question is, will it be performant enough for an arcade game?

I don’t need the view to scroll particularly fast; if you play the arcade version of Gauntlet, which I have in emulation quite a bit, the map actually scrolls at a steady speed. Even if you are playing an Elf who moves very fast, the map speed doesn’t change. But I don’t want to see distortion or glitches while it updates either.

The question is if the animation will slow it down too much. I had a thought of having the animation patterns just be brand new characters introduced and replaced, but this will DEFINITELY overload the pattern buffers, forcing me to either clean up unused ones or redo the entire buffer from scratch more periodically.

But you don’t know until you try it all…

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

12 years (and counting…)

So what I have been up to, what am I working on, when is the CRPG going to be done? What’s going right or wrong? Time for some answers…

Real Life

In real life, work is actually going pretty well! But, if you spend all day doing software design, you’re kind of burnt out by the end of it. You’d rather read, watch TV, play video games, anything else to recharge the batteries. I also have other chores to deal with such as home care, laundry, dishes, taking care of my cat… As a result, my time to work on hobby software projects is not as much as I’d like. I need to step up efforts to win the lottery. πŸ™‚

Hardware Woes

Recently, I’ve been getting very frustrated with running TI software on the actual console. I have one of the CF card reader systems (now called a NanoPEB) but it’s been getting hard to work with. It doesn’t work with memory image files that are larger than a certain size. For example, bitmap drawing programs fail to save or load files. When I tried loading my recent Extended BASIC game it fails to load the low-memory assembly routines, giving a cryptic IO error. Argh!

The problem with vintage hardware is you’re either all in or out… you have to spend a considerable amount of time and money if you want to get a hardware setup that works correctly with modern computer systems for transferring software. I’m not sure I want to do that, because I’m just NOT a hardware guy. If something goes wrong, I can’t grab a soldering iron and fix something.

Other Projects

I got a bug in my brain to do another software project on the TI, which has been consuming more of my attention. I don’t want to say much about it yet because I’m not sure I can get it done to a satisfactory level, but it is an arcade game…

I’ve been using the TI’s advanced memory system (which I don’t have but is emulated well in Classic99) and it’s been a refreshing change of pace from the tight memory constrictions I’ve had with the CRPG. I’m even considering saying “Screw it” and just using it for that project as well! It won’t speed up work on the CRPG (content generation isn’t something more memory will fix) but it at least makes the engine work less of a trial.

CRPG Work

Things are basically about the same here.. I’m generating content. I think the big fear I have here is, am I writing good content or not? Is it lame and stupid? Reading the CRPG Addict’s experiences with various games and how some have great story lines and others are terrible has me feeling a bit under pressure to deliver something much better than old tired tropes. (“There’s an evil wizard… in a castle. Uh, slay him. Yeah.”)

Yahoo Concerns

So as we all know, Yahoo is NOT doing well… and they are my current web provider.

Sometime last year, they split their web service into a separate business called Aabaco. Unfortunately, this hasn’t improved service all that much, and I am concerned that I may be asked at some point in the near future “Hey, where did your website go?” I’d better do some local FTP copies of all my content soon…

It isn’t the first time I’ve had to relocate my blog, but I’d like to try and preserve the WordPress version of it if I can. (Not a fan of Blogspot) And I’d like to take my domain with me if I had to leave Yahoo, not sure if that is doable. If I had a choice of new webspace, I’d probably go with either AWS or Azure.

An Apology

Finally, I am sorry that I don’t update often enough. I know the CRPG work has been going on a ludicrously long time now… I really should just sit down and finish something, even if I’m not happy with the design.

I was reminded of the importance of communication recently when I saw a video on YouTube called “Whatever happened to…” concerning a video blogger I like and followed. In the last couple years their content generation of funny movie/video game reviews dropped to nothing, their Patreon account dropped from 5k/month to under 1k/month, etc. And worst of all, they have been utterly silent in social media, confining themselves to Twitter and banning anyone who asks why there hasn’t been any new content.

I don’t ask for money to do any of my hobby work, but I realized I didn’t want to be THAT kind of person. I want to make sure everyone knows where I’m at and where I want to go with things.

Posted in Blog, CRPG, Personal | 3 Comments

Dungeon Crawling

So… In the last post I mentioned working on some TI-99/4a side projects. Well, I have finished one! πŸ™‚

It is a 3D dungeon game called “Wizard’s Doom”, a spiritual sequel to the “Wizard’s Lair” and “Wizard’s Revenge” games developed by Rainbow software in the mid 1980’s.

Background

“Wizard’s Lair” was the first TI game I personally bought with my own money, ordering it from the Triton catalog. It was one of those things I would anxiously check the mail for every single day. I let out a literal whoop of excitement the day it arrived. πŸ™‚

And what about the game itself? For a game designed to run in TI Extended BASIC with no disk system or memory expansion, which means it had about 13k at most to work with, it’s pretty good. The game runs at a decent speed and has greater depth and nuance than most games produced for the TI-99/4a at the time. It was definitely worth money! The sequel is essentially the same game but with better graphics and some new twists.

The manual is very professional; the cover artwork is amazing and as far as I can tell, original. I can’t read the signature in the corner to determine the artist, but I’ve never seen it reproduced elsewhere. The manual was also not a cheap photocopy job; you can tell this because the cover has ink all the way to the edge, which is only possible if you printed it on a printer at 9×12 size and cut it down. And the cassettes and diskettes for the game had a shiny embossed label in two colors.

The games are a derivation of “Dungeons of Daggorath”; they share the same plot and basic game play. However, in comparison to that classic game, they are laughably simple… Granted, Dungeons of Daggorath is written in 100% assembly, so it has an advantage.

After 30 years, I thought “Why not write a sequel to Wizard’s Lair and Revenge? One that actually plays more like Dungeons of Daggorath in terms of depth and challenge? And uses a disk system and 32k RAM for maximum play-ability?”

And that’s how the project started…

Initial Design and Prototyping

The first step was to write my own maze generation algorithm. I’ve done some of this previously with experimenting doing a Rogue-style game, and in a Java project I did back in college over a decade ago.

The basic algorithm is: Create a 2-dimensional grid of empty squares. Pick a square, random or determined, mark that square “open”. Try and move in a random direction, and if you can, open the new square and make a connection between it and the prior square. You can either always look for empties, and back-track if you can’t find any, or just go through occupied squares. You can stop either when it runs out of chambers or have it track how many it’s created and stop arbitrarily. You can generate a lot of different styles of mazes with just a few simple changes to the algorithm in places, and it’s easy to seed with a fixed random value to generate the same maze time after time.

Studying Wizard’s Lair, I was amazed at how slow the algorithm was. It takes it several minutes to generate a maze, more than ten at some points, and other times it’s oddly fast. Part of the reason is the code infrastructure is sloppy with a lot of GOSUB and GOTO’s involved, rather than a clean linear approach. The other issue is that it doesn’t handle dead-ends well; if the maze is plotted without running into any other chambers it goes pretty quick, but once it has to deal with dead-ends it slows way down.

I wanted a fast generator, because I wanted each level to get progressively larger as you descended. I also wanted to use bit-wise operations to store directions in each chamber, which is much more efficient. (So the 1 bit becomes “north”, the 2 bit is “east”, and so forth.) I also added tracking for all open chambers by putting their row and column values into two strings. That gave me a record of chamber locations for backtracking, as well as placement of random monsters and items.

For dead-ends, I had to figure out how to handle them in a quick and efficient way. I wanted to keep the mazes from becoming too “single path” oriented, where one way just leads to a dead-end, I wanted 4-way crossings to be more common. So I put in a random check to determine if it backtracked to a prior chamber to look for new empties (using the chamber location strings) or if it just forged through an already open chamber. It also only tries once to backtrack; if it fails to find empties a second time it automatically plots through an open chamber. Playing with the randomness, I narrowed it down to a value that seemed to work and generate decent mazes that had the aesthetic I wanted.

After creating the maze, I wrote up the code to generate the 3D view. I wanted it to be faster than the original games were (which were okay but not great), but I quickly ran into problems…

The truth is, TI Extended BASIC is not very fast with video operations. At all. Drawing characters on the screen with HCHAR and VCHAR is decent in a single statement, but the overhead of calling multiple statements is much slower, creating visible drawing artifacts. I tested using static DATA statements to store positions for drawing, but it was no faster. In fact, the probable fastest method is to do direct stacked lists of call commands that use no variables, only static values.

I had some more complications as well… While doing some graphics design, I decided I wanted to use brick patterns for the dungeon walls. For the far off and middle-range bricks, I only needed two repeatable patterns. But for the close-up view, I wanted to do 2×1 size bricks, which meant I had to alternate the pattern every other row. I tested using DISPLAY AT for this and it worked, but was so slow… Taking tens of seconds to draw your view was just not acceptable.

So this got my mind going another direction… why not use assembly language for the drawing routines? And maybe more…

Assembly and BASIC

Let me give you a bit of background on this subject…

TI Extended BASIC has always had the ability to support assembly language routines. 25% of your memory expansion is actually inaccessible to Extended BASIC except via assembly routines; the 8K lower RAM area. A command was supplied (LOAD, which also doubled as the POKE command) to load assembly files directly into the 8K RAM, where you could then call them using the LINK command, passing values back and forth to assembly language routines.

However, the documentation on setting up assembly language subroutines for BASIC and Extended BASIC is, well, absolutely awful. All the information is actually in the Editor/Assembler manual but it’s so hidden that you’d never find it unless you knew what you were looking for. Also, TI Extended BASIC and TI BASIC are two separate environments (three, if you included TI Extended BASIC with and without memory expansion), and the documentation is hazy at times about the differences.

The first big issue is figuring out how to pass data into an assembly routine. This is where things get messy because you have to be familiar with how Extended BASIC stores data on the stack and how to determine if the value is a static, numeric, or string. The original documentation recommends using a library package TI provided for all your access needs. But it’s an enormous waste of generic code designed to handle every potential combination, eating up a good chunk of that 8k. Plus, TI didn’t provide source code, only binaries.

The second issue is dealing with the character set bias. TI BASIC and Extended BASIC relocate the ASCII table upwards by 96 characters because they had to make room for other things in video memory in the lower character values. As a result, any characters you want drawn you have to add 96 to in assembly.

It took a lot of reading of documentation, and even experimenting in the emulator with the debugger screen to look at memory addresses during execution, but I finally figured out how to write my own routines to extract static and variable values from a passed LINK call. It helped that I only needed numbers and not strings. I then wrote up my own video plotting routines to draw the maze sections, using a passed numeral value to indicate which section and if it was a wall or corridor, so it could branch to the appropriate routines. And it worked beautifully!

My first design used an internal buffer approach. It would draw in the buffer and not on the screen, and then output the buffer to the screen after it was completed. To my surprise, this didn’t work well. While navigating the maze, you’d push a direction button and after a notable pause, the view changed without any warning. I realized that the lack of a “feeling” of movement was the problem.

So I altered the design so that the BASIC code just calls LINKS for each section, essentially replicating what the original games did, just replacing the HCHAR and VCHAR calls with a single LINK. Testing showed that the movement issue was solved; you saw the corridor being drawn but it was acceptably fast and you had a definite sense of responsiveness.

The last issue with assembly routines in BASIC is loading them. The manuals advise you to use the LOAD command, which does work… but it’s incredibly slow. I only have around 2-3k of assembly code and it took several minutes to load in this fashion. It only needs to be done once at the game start, but having to wait 4-5 minutes for the game to finish loading isn’t cool…

Fortunately, another 99’er solved this issue years ago. Barry Boone wrote the Systex loader, which lets you take your assembly routine and merge it into an Extended BASIC program. The typical approach with Systex is to write a “loader” program which just runs your main program. You embed your assembly routines in that loader, and you’re good to go! It also has the advantage of obscuring your assembly binaries from casual viewing.

Graphics

The other advantage of going to assembly routines was I could do something else I truly wanted… monsters bigger than the original single sprite that was in the first two games.

Wizard’s Lair and Revenge used a single 16×16 size sprite for monsters; the first game even used the same monster graphic (an impish creature) for every monster in the game. This works all right, but the monsters appear very small against the larger large 3D dungeon window (which takes up more than 2/3 of the screen.)

I had already been considering using more sprites for monsters, but moving to assembly was necessary to make it a viable option.

Why? Well, TI Extended BASIC can handle sprites, but typically only when you’re just doing one at a time. The manual specifies you can control multiple sprites in a single command. But in implementation they are NOT in sync with each other. For example, telling two sprites to move at once, you can see that the second starts moving after the first one starts.

The problem is that the subroutines provided actually process sprites one at a time, doing a full video read and/or write, then looping for the next one. This makes multi-sprite operations where you either want them to be alongside each other or over-lapping very difficult to manage. In assembly, things can be done quickly and in blocks, which makes sprites move instantly, change color instantly as a group, and so forth.

I had one other issue to solve though… TI Extended BASIC has a very limited character set, and that limit still applied even in assembly. I decided to do pattern swapping when a monster was on screen so I could have the best number of 16×16 patterns (eight) available. This meant that items and other sprites that appear in dungeon corridors wouldn’t be available when a monster was present. I decided it was worth it for the better graphics. I also used the same technique when drawing the map of the dungeon; swapping out character sets so I could show a more better detailed map than the original games.

The monster graphics themselves turned out to be a bigger job than I’d imagined! I didn’t want to copy any existing game’s graphics, so I decided to draw them myself.

I started with the wizard on the cover of the manual. I drew some boxes on him and tried to approximate the pixel locations. Funny enough, as I worked, either my natural artistic ability came out or I just got lucky but he slowly changed to be slightly angled in profile.

The end result was very nice, so I decided to extend it to every other monster; find a picture online (thank you Google images!) and draw boxes on it and plot them out. Nearly every monster ended up looking radically different from their original artwork. So I didn’t feel like I was “stealing” anyone’s work, more that I was inspired by it.

Abandoned Ideas

With any project, you occasionally have an idea that doesn’t make it in… mine in the case of this project was the Speech Synthesizer.

I wanted the wizard to give an evil laugh when the player reached level 6, just to freak them out. When you actually found the Evil Wizard, he would say “Die fool!” when either you or he initiated combat. Possibly a scream of “Noo!” when you defeat him. And finally, anytime the player died you would hear the wizard say “And yet another does not return…” My own little homage to Dungeons of Daggorath. πŸ™‚

Unfortunately, creating speech on the TI-99/4a is incredibly difficult.

The first obstacle is finding software that will record audio in mono. (The TI’s sound chip is not stereo…) The second obstacle is to find software that will convert the audio file into LPC encoding that the synthesizer understands.

Fortunately, the engineers at TI who worked on the synthesizer went on to found their own company years later. And they wrote software in DOS to create the speech encoding for a variety of chipsets. The only hitch is it was packaged with a blueprint for a slightly later model of the speech core. This creates some slight misalignment but it’s surprisingly close. It also only available as 16-bit binaries, which means can’t be run on a 64-bit PC. (32-bit will go back to 16-bit, though.)

I did get test speech working, both in emulation and on the actual hardware. But a host of issues cropped up with it…

The first problem was it was very quiet on the actual hardware, as opposed to the emulator. After puzzling for awhile, I realized I’d recorded my voice using a crappy laptop microphone in an open room. So I had to re-record, keeping my mouth close to the mike. This worked, but the software I had to convert it to a mono audio file kept messing up from the volume of the recording, creating a static sound. It took a lot of tries to get a clean audio file.

The second problem was the LPC encoding. It generated a text file containing all the bytes, but it was HUGE. An evil laugh took over 600 bytes alone. My intend was to embed the code into the 8K RAM rather than load on the fly, but I was concerned at running out of memory to even store the four phrases I wanted.

Final problem… I hated how my voice sounded. I don’t have a naturally deep voice, so it was very difficult to get something that sounded like an evil wizard, and was scary. Part of that may be my bias against my voice, but still… it just sounded lame.

After all of that, I decided I would just forgo speech in the game.

Original Game Mechanics

When designing game-play, my first step was to investigate the original games and how they worked. Both Wizard’s Lair and Revenge have nearly identical design.

Wizard’s Lair has a fixed number of chambers per level, the maximum on level 4 is 45. The actual mazes can be up to 8×8 in size. Wizard’s Revenge, possibly to save memory, only has mazes that go up to a maximum of 6×6 in size. That also means there are less monsters and items in the second game.

There’s no hit mechanic in either game; you just deal damage when attacking and take it in return from monsters. Your attributes also take damage with every attack, but at a much smaller scale. (Which is why the manual notes that you may observe your attributes drop in value against “stronger” monsters…)

Monsters only have two attributes of note, their name and their power level, which is both their health and their amount of damage. The Evil Wizard has the highest power level, plus any spell that would kill a monster outright doesn’t work on him.

Items and monsters are populated off of static data lists. Each item or monster has a specified count and a minimum and maximum dungeon level they are on. Because the games were written for a 13k cassette environment, they don’t try and optimize by loading the data into arrays; instead they just read the data statements as needed. This creates the interesting effect that when moving into a new chamber, it takes notably longer for certain items to appear on the screen than others. (As it has to read/search all the data until it finds the one it wants.) Traps on items have a small percentage change of being generated.

In both games, treasure is used solely to increase “treasure points” which is used to calculate your final rating. You can essentially skip every treasure chest in Wizard’s Lair if all you care about is defeating the Wizard. In Wizard’s Revenge, chests also store food on the last few levels, which restores health. Experience points have no effect on your character at all in either game, they’re only used for ratings calculations.

Wizard’s Lair doesn’t have exits to the next level. Instead, you move on to the next level anytime you want with a command or you automatically descend after a certain amount of time has expired. If you are on the last level when this happens, you lose the game. Wizard’s Revenge got rid of the time factor and added exit chambers, a change I agree with.

Both games have some interesting fun things…

Wizard’s Lair has three separate spells that get rid of monsters immediately; VANISH, DEATH, and GRAVITY. The latter actually levitates the monster off the screen! None of them work on the Evil Wizard.

Wizard’s Revenge has very interesting traps beyond just impacting your attributes and health. One creates leeches in your backpack, filling every available space, forcing you to waste time dropping them. Another teleports you to a random position in the dungeon. And one creates walls blocking you in your current chamber; you have to attack the walls and break them down to escape!

Wizard’s Revenge also has a new instant death spell, MEDUSA, which literally turns the monster to stone. You can even leave and return to the chamber and find their statue there. (Obviously, that one doesn’t work on the Evil Wizard.) There is also a CARPET which will whisk you to the next level immediately when used. (If used on the last level you lose the game though.)

I’ve played and won both Wizard’s Lair and Wizard’s Revenge of course. A typical game takes an hour or two. The games are pretty challenging due to the randomness. The first game in particular has a pretty steep curve of power for monsters; you’re feeling cocky finishing level 1 with a club and leather shield and suddenly on level 2 you’re facing an ogre or mummy and getting pounded into oblivion. The Evil Wizard himself IS a challenge but not overly so; I found that so long as you had a magic shield (using a spell) you could beat him fairly easily.

So now on to what I want to do…

Game Goals

Early on, I wrote up a list of things I wanted in my game:

  • Character classes, so you could play the game in different ways
  • Six levels, each one progressively larger than the prior one
  • A much more useful map that shows the exact layout of the dungeon
  • A hit mechanic to go with the damage mechanic, to make combat more complex and nuanced
  • A separate spell system by which you can use magic points to cast spells. Spells now become scrolls that can be written into your spellbook or used to cast the spell
  • A greater variety of items and individual items to use
  • A greater variety of monsters, with unique abilities and graphics
  • State tracking for spell and trap effects, both positive and negative
  • A truly powerful Evil Wizard, who can actually cast spells and has a few tricks up his sleeve…

I’m happy to say I was able to implement everything I wanted and I still ended up with around 3K of memory left in Extended BASIC! πŸ™‚ The only additional feature I added was a save/load game option. This came about due to feedback from a good friend play-testing the game, who noted it was taking several hours to complete and that a save game feature would be handy.

Playtesting

This was probably the most challenging part of the design. After the game was finished, I had to fine-tune the mechanics and make sure the game was winnable.

I was impacted by an earlier game of mine, which I discovered LONG after the fact was not winnable. The final level was relying on some game physics I’d changed without realizing it would impact it. I promised myself in my future games that I would make certain they could be won before releasing them.

It took a great deal of time to get the game to a playable state. I discovered early on that it was pretty easy to make the game TOO difficult. Part of the problem was that as the designer, I am fully aware of the mechanics and of how things work, how to use items, and so forth. As a result, what seems a challenge to me is flat out impossible to anyone else! I had to scale the game back to the point that I felt slightly bored with it to get it just right.

Documentation

Since I was writing a spiritual sequel, I also wanted to create a manual for the game, modeled to look exactly like the first two game’s manuals. I intended to have a PDF copy of the manual AND to print a few copies, one for myself at least. πŸ™‚

First, I scanned the original Wizard artwork as well as the graphics for the logos and other things. I then constructed the layout in Microsoft Publisher, and wrote up the text. Since my game was considerably more complex, I ended up with several more pages.

The main font used for the text was easy to discern; Helvetica, although I had to download it for Windows from a 3rd party site. Figuring out the font used for the title was harder; I eventually hunted it down as Parsons. Publisher has an option to publish documents at PDF files, which I took advantage of to create the final templates for printing.

Because the outer cover has ink all the way to the edge, I had to find a local print shop to print the covers. Fortunately I found a decent place right in town, the only tricky bit was getting my proofs and finished materials before they closed. (No weekend hours and closes at 5, usually when I’m on the bus home…) I considered the process to be a nice trial run for when I get manuals created for my CRPG.

I had 20 copies of the cover printed. In retrospect, I was probably optimistic on the count; I offered anyone who wanted a manual one for the cost of postage, and ended up selling maybe half-a-dozen. Oh well, I still have some if anyone wants one…

Final Thoughts

I quite enjoyed the experience of writing the game. It really came together exactly as I pictured it would! And expanding my knowledge of the TI’s capabilities with assembly routines and BASIC was very awesome as well.

I’m waiting now to hear if someone else has won the game. Regrettably, I’ve gotten little feedback, positive or negative… I suppose when you write a vintage game you should be happy for what you can get though.

I also discovered recently that another game already had the title I’d chosen… Wizard’s Doom is also the name of a Commodore 64 action/strategy title game. There was a lot of overlap in game titles back in the 80’s, so I’m not too worried about someone surfacing and filing a lawsuit over the name. πŸ™‚

And my final challenge to anyone who has read this to the end…

Dare ye enter… and deliver unto the Evil Wizard his final doom?

Download: TI Game Shelf

Link: AtariAge thread on Wizard’s Doom

Link: CRPG Addict’s Review of Wizard’s Lair/Revenge/Doom

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

Autumn Update

Hey all… if there’s anyone still out there! πŸ™‚

It’s been a busy year for me… I migrated from an SDET (Software Development Engineer in Test) to an SDE (Software Development Engineer) role in my work, which seriously cut into my development time for the CRPG. I also have a vacation to Las Vegas with my girl coming up in early October. Life is as always very full…

I’ve also done some side projects in TI Extended BASIC. I’ll make some posts about them later. They HAVE contributed to the CRPG indirectly; any good game designing work always does.

Anyway, I’ve been working on content generation for the game, which primarily focuses on text and dialogue. I finally came up with a good way to store it using an Excel spreadsheetΒ  that lets me both be creative and track data sizes.

So far, the numbers are adding up about what I expected. Each game disk has four dialogue files, with lengths of 16, 32, 64, and 128 bytes respectively. My compression technique for text gives me an average of 30% compression, which lets me get fairly wordy. My biggest challenge is writing out text and avoiding lengths of 17, 33, 65 and so forth… Right now, the 64-byte records are by far the most numerous, which I expected.

I’ve also found that in the process of designing the game’s towns, people, and various quests and things that I’m making changes to the item lists. I’ve actually reduced the amount of items in the game as a result; I don’t want the game to be like Dragon Warrior where each area is just progressively stronger weapons. Instead, I want specific item types to only be found in particular towns. One town, for example, would specialize in swords, another in plate armor, and so forth.

As part of the work I’m also drawing and re-drawing maps. I just reworked one area from a fairly generic coastline area to a glen with a large lake, for example, to drive some more interesting plot line work. Drawing maps in my editors actually takes a lot longer than I expected! But that’s all part of the fun…

My goal is to try and get all the content text done by the end of the year, and at least a pencil-drawn map of everything, if not actually digitized. I’ll try and be better about updating too…

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

Piecing it Together

Happy 2016 everyone!

I’m currently working on the world maps for the game. I realized that I needed to sit down and start generating the content… all of it. Towns, people, quests, items sold, locations… everything!

The main reason why is that until I do that, I really don’t know what other things the engine might need to do. Sometimes you only discover needs when you’re writing out content and you realize “Oh… I need it to do this right here.”

Another issue is I realized that too much focus on the engine can lead to games like Gates of Delirium and The Seventh Link. Both of these are excellent Ultima clones on the TRS-80 Color Computer line, but they have no soul at all. Although I’ll give the first one some credit, at least the towns have names… I really want each region to have character and each town to be a “place” in the mind of the player, not just “town #3” that sold “weapon #4”.

The good news is that I’ve had the basic map and regions in my mind for quite some time… it’s really all about piecing it together. Because I’m not doing a big continuous world map, each world map is connected via very narrow edges or through other transitional maps. It’s very much like classic World of Warcraft prior to the Cataclysm expansion; map exits are cleverly disguised to transition you in a seemingly clean fashion.

Here’s, for example, the complete world map:

Each square is a block of 8×8 tiles, the total size of the map is slightly larger than the map of Ultima IV. However, it has significantly less wasted space, every map has at least 70% accessible area!

So right now, I’m in the process of drawing all the world maps so I can piece them together into a more cohesive whole. I’ve had several of them drawn up on graph paper (I love drawing maps with colored pencils!) for several years, so it feels good to break them out and finally get them crafted in the game! πŸ™‚ It’s actually taking longer than I expected to make each map; there’s a lot of tile plotting to do and I have to figure out exit points that align right on each map.

In some cases it’s also leading to changes. I realized I needed another map when I realized that one I drew simply wasn’t large enough to contain all the content I wanted. I may also find that there isn’t enough tiles with varied looks to make each region a little different and unique; I may end up adding more as I progress.

Here’s a sneak peak of the world map in progress… Enjoy!

Posted in CRPG, Design, RPG, Screenshots, TI-99/4a | 2 Comments

Review – Ultima II: Revenge of the Enchantress

I’ve decided to start reviewing some classic CRPG’s I’ve played here on the blog recently. Why? Well, there are things I’ve always wanted to say about some games, and it also gives some insight into where I’m going with my own CRPG design.

Our first game, Ultima II: Revenge of the Enchantress!

This game has a particularly personal meaning for me, because it was the first Ultima game I ever saw. I don’t know where exactly; my guess is that I saw it running in demo mode at a computer store, because the gorgeous tile graphics definitely are eye-catching. I was always frustrated and angry that the Ultima series weren’t available for my own computer, the TI-99/4a. Reading about Ultima games over the years, it felt like an entire world of adventure was passing me by…

I had a review of the game in an issue of Family Computing, which is an amusing read:

It’s fairly clear that the writer was going off of press materials for a lot of their claims. The text makes the game sound enormous and varied and full of places to go and things to buy and people to talk to. Plus their screenshot is perfect; it manages to capture one of the few towns in the game that doesn’t have a silly weird name.

I actually didn’t have a chance to play the game until years later, in 7th grade. My math teacher, who was also the head of the lab, had a copy of the game and let me play it. Words can’t describe how thrilled and excited I was! Then I started the game and realized I had no clue how to actually move around. After watching my character get pounded on while frantically pushing every button on the keyboard, I finally found the “/” key let you go down… only to get trapped and killed. I never thought to try the “Return” button for up, who makes “Return” do anything?

My teacher, with surprising honesty, told me I hadn’t missed a lot. He said that after awhile you were so powerful that you could kill everything in one blow, and the end game consisted of hitting the sorceress in one chamber and moving to another chamber she teleports to, over and over again. So at least he had finished the game, or at least read the solution somewhere.

He then told me something flat out bizarre; that the first town in the game had some festival going on and he couldn’t get anyone to help him, so he stowed away on a ship, after stealing a blue tassel. Ummm yeah… that doesn’t happen in the game. This is a case, I think, of a player injecting their own ideas of story in the absence of one.

I didn’t actually play the game in full until years later, when I purchased a PC and the Ultima I-VI compilation CD. I had to download the patches to make it work in modern DOS properly, and I had to live with the awful 4-color EGA graphics, but I was finally able to play it. I also played it in a Commodore 64 emulator; the version there is surprising in how they took advantage of the better color palette to make a prettier version.

If I was to sum up the game in a few words, it would be: unfinished, juvenile, simple, unrecognized potential.

To use a metaphor… Remember when you had that homework assignment due and you screwed around and didn’t do it until the very last day and was up until 4 in the morning throwing it together and it was just CRAP and you were sweating and knew everyone would see it and know…? But then, inexplicably, you turn it in and you get praise for your incredible work and you just smile weakly and wonder how you got so lucky…

Yeah, that’s this game in a nutshell. πŸ™‚

Ultima II was Richard Garriott’s first effort in programming in 6502 assembly. He spent two years on the game while going to college, which he dropped out of afterwards. Which honestly, if you’re making the kind of money he was, why would you need a degree? But I heard that when Origin later bought the source code back from Sierra for re-release, he was very reluctant for his team to see his old work, because he knew how terrible it was.

My theory is that he spent a lot of time just figuring out how to program in assembly and get basic game play up and running. Once that was all done he had run out of time to give it much content. Two years in development in an era where most games were programmed in 1-3 months meant that he had a lot of pressure to finish from Sierra.

Most of the game logic is very simple, like a BASIC program converted to assembly language. Items in the game are a simple list structure with quantity values, NPC’s just spout the same dialogue unless they’re a special one (drawn from a table), and the “three disks of content” are just extra maps that aren’t necessary to finish the game. The last point makes sense; it was the only way to add content to the game easily.

Actual game play, once you know the controls, isn’t too bad. The game is very crisp and responsive. Combat, while simple, is quick and easy. Initially you spend a lot of time stealing food and just waiting for a frigate to come along. Once you have one of those and the ship’s cannons, you’ll level up fast. The whole “time gate mystery” the manual espouses turns out to be pretty simple; the gates do open and close at intervals but their target locations are fixed, so it’s not difficult to figure out. On the downside, you spend 90% of your time grinding for gold to buy hit points and ability score increases. A hex editor would let you skip all of this in seconds.

Probably the worst thing about the game is that the 3D dungeons/towers, which is really what Ultima was originally built around, are absolutely unnecessary. The only reason to enter them is to get fuel for the rocket, and that can also be gained by just killing monsters around. So a whole portion of the game is just a waste of time. The fact that magic spells only work in dungeons or towers also makes playing a spell-casting class pointless. Ultima would continue to use 3D dungeons for three more games, which was always a detriment. (If you want a 3D dungeon game, play Wizardry. They do it the best.)

The game is also very, well, how to say this… stupid. There are tons of in-jokes and pop culture references that could only come from the slightly inebriated mind of a teenage developer. (Which, by an amazing coincidence, they did!) Most of the references now would make no sense at all to a modern audience, such as a (misspelled) magic phrase from the movie “Excalibur”.

Also, the game is set on Earth, but you can play Tolkien-style races like elves and dwarves? Not that race has any impact in the game on anything other than starting ability scores… My theory is that Garriott, in order to complete the game on time, ported his character system from Ultima I over into assembly as completely as he could.

So why wasn’t the game reviled for all of this back when it was released? Well, the fact is, for 1982, the game is REALLY impressive. At that time, more than half of your commercial games were written in BASIC and didn’t look anything like this.

The big cloth map and gorgeous box artwork can’t be ignored either; this was a game that looked quality. The fact it retailed for $60 (which adjusting for inflation would be well over $100 today) and it sold over 100,000 units meant it was a very profitable game too.

Is it worth playing? Absolutely. This game is an excellent model of a CRPG engine with potential. Had Richard Garriott had more time or more immediate expertise with assembly language and platform building, or even a team of developers aiding him, the game would would have been far better. You just have to look at the following Ultima titles to see that he was able to refine and improve his CRPG designs. Ultima II is an excellent lesson for a CRPG design enthusiast to study.

For example, I’ve looked at the executable in a hex editor and found that all of the in-game text is hard-coded. From a platform standpoint, that’s very limiting. Ultima IV and onward stored NPC text in data files, which was much more flexible. Because Ultima II loads its maps from disk, it makes sense that most of the customization of places (like the names of stores) occurs on the maps themselves using the large letter blocks; this is the one area you could be creative in cheaply with the engine design.

So where can you obtain Ultima II, besides eBay? It’s available as part of a bundle on Good Old games (gog.com) for only $6. GOG does a great job setting the games up to run correctly, using DOSBox as an emulator. You may still need to download some patches if you want better graphics. Please note that the original DOS version also has a flaw in which the galaxy maps didn’t map over correctly. I don’t think GOG has corrected this.

You can find a lot of information on the different versions of Ultima II, as well as literal transcripts from the game, at Underworld Dragon’s Notable Ultima site. This site is older than the internet and was preserved by one of the Ultima dragons for posterity. (Underworld Dragon himself has disappeared, to my knowledge.)

The CRPG Addict reviewed Ultima II early in his blog history. His initial review was harsh and critical but he later admitted in comments he was being overly judgmental of the game, probably because he was comparing it too much to Ultima III and later.

RPG Classics has had a shrine to Ultima II set up for several years now. You can find complete information on the game’s content as well as maps for every planet, town, and dungeon.

One of my favorite reviews of the game is Spoony’s Ultima Retrospective review. He notes the amusing use of the Eagle’s song “Hotel California” in numerous places in the game, as well as the cryptic nature of clues in the game. (I’ve looked, there is literally NOWHERE in the game that tells you that only the Quicksword will hurt Minax. The manual mentions it is the most powerful weapon in the game that must be earned but nothing else.)

And finally… because of the game’s personal meaning to me, there WILL be a “Port Bonifice” in my CRPG. One, I really like the name, and two, it’s one of the few places in the game that has a fantasy-style name to it. I still wonder where Garriott got it from; Bonifice was the name of a pope from the Middle Ages…

Links:

Ultima II on Good Old Games

Ultima II on Wikipedia

Underworld Dragon’s Notable Ultima

CRPG Addict’s Ultima II Review

Spoony’s Ultima II Review

RPG Classics: Ultima II

Posted in CRPG, Design, Gaming, Review, Screenshots | Leave a comment