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.

This entry was posted in Blog, CRPG, Design, Screenshots, TI-99/4a. Bookmark the permalink.

5 Responses to Putting it Together

  1. PeteE says:

    Looking good! It’s interesting how much code gets written for the tools when working on a game.

  2. Ron says:

    I’ve kept this blog in my reader for a few years now, even if I don’t even have a TI emulator set up. I’m always excited to see a new update on the game, and it’s great to see things are still moving forward!

  3. MagerValp says:

    Oh I’m sure there are at least half a dozen of us 🙂

  4. Brian says:

    I spent many hours playing TOD on the old TI99/4a.

    Just stumbled across your blog, but will be keeping an eye on things and play away when the game is ready!

  5. Tormod says:

    I’m over her, quietly reading. :waves:

Leave a Reply

Your email address will not be published. Required fields are marked *