Waiting on the Post

Stack em up!

Okay, all pre-ordered collector’s editions have been mailed! Going forward, I’ll be shipping them individually rather than waves. I just received my last order of game boxes, which means there will be around 100 or so collector’s editions. I don’t plan on doing more, so get them while you can!

If you want the custom cartridge and/or disk, there will likely be a delay in shipping your order. I have to order the cart boards and chips separately,Β  and with floppy disks I’ve been recycling old disks IΒ  got a pile of (thanks Ciro!), but it’s a roll of the roulette wheel if they’re usable or not…

Part 2 of Making a CRPG will be coming next… with a focus on scrolling maps!

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

Making a CRPG – Part 1: Infrastructure and Platform

In this, the first part of several, I will talk about the creation of Realms of Antiquity for the TI-99/4a home computer. There will be technical, narrative, and designer content, with plenty of side-treks. Strap yourselves in!

I should add that these articles are likely to be very “crunchy” with technical detail. The intended audience would have some passing knowledge of assembly language as well as being CRPG enthusiasts. If you want more detail, program listings, algorithm definitions, by all means post and ask!

The best place to start? The platform it was built upon, and the infrastructure of how the code drives the program. And on that note, the number one best resource EVER is the TI Tech pages. They were an awesome and useful resource with my project!

The Platform

A big reason that there was a distinct lack of good software for the TI until well after the home computer division was cancelled in 1983 is the processor that drives the TI-99/4a, the TMS9900 microprocessor, released in 1976.

It has occasionally been called the “first” 16-bit processor, but that claim is disputed by IBM and Motorola. It’s VERY different from the 6502, arguably the most popular and well-known microprocessor of its era, in a multitude of ways:

  • 3mz clock speed, around 3 times the speed of contemporary processors
  • 16-bit instead of 8-bit
  • Can do register-to-memory, memory-to-register, or even memory-to-memory operations
  • Big-Endian (high byte first, then low byte, going left to right)
  • Hardware unsigned multiplication and division operators
  • No native stack implementation
  • No memory page addressing; no “zero page” concept
  • 15-bit address line, so it accesses 32,767 “words” of 16-bit size
    • Byte operations are handled via special op codes
  • 16 CPU general purpose registers available
    • Instead of hardware registers, they are relocatable anywhere in CPU memory using a workspace pointer
    • You can have as many register sets as you want; this effectively replaces a “stack” concept, as you can use registers as a means to pass values
    • Only a few registers have special uses
      • R11 is always the return address for a branch and link
      • R12 is used by the communications register unit (CRU) for special purposes; the SAMS card needs this for page swaps
      • R13-15 are used for context switches. They store the return address, workspace address, and status register from the prior context

Because opcodes are 16-bit, TMS9900 assembly uses more memory than a 6502 line-by-line, as instructions can run anywhere from 1-3 words (2-6 bytes). But you save memory because you can do in one instruction what takes several on other processors.

To use a car analogy, if a standard 8086 processor is your typical car, the TMS9900 is a Cadillac. Big luxurious driving, but kind of expensive and fuel-consumptive. πŸ™‚

Memory

The TI-99/4a has a 16-bit addressing range, for 64k total.

Unlike other architectures, none of this addressing space is used to map video; the VDP chip has it’s own 16k of dedicated RAM which is accessed through memory-mapped ports. These ports only allow you to read/write bytes, not words. This bottleneck is the cause of much anguish and annoyance on the part of TI programmers. It can and HAS been overcome; the singular most impressive work in this area in my opinion is Mike Brent’s “Dragon’s Lair” for the TI-99/4a, which runs on the base console and renders all the original videos in a fairly decent rendition on TI’s bitmap mode.

The base console only has 256 bytes (!) of CPU RAM, nicknamed the “scratchpad”, which is fast 16-bit memory. Most of the time, it’s best to locate your register set here. Some values in the space are used by internal processes but most of it is available for your use. TI’s Parsec cartridge (which features horizontal pixel bitmap scrolling) had to locate it’s scrolling routine in the scratchpad for maximum speed.

If you have the 32K memory expansion, you get two large blocks of CPU RAM, a lower 8K block and the upper 24k block. This RAM is accessed with a slower 8-bit multiplexer, which adds wait states when accessed, so many 99’ers try and move time-critical code into the scratchpad for best performance. My personal experience has been the slower speed is not really an impediment unless you’re doing something really over the top.

So where, you ask, are memory pages, like Apple and Commodore have? Well, there aren’t any in the base TI architecture. The only page switches occur with some cartridges, which have their own 8K space. That’s where the SAMS card comes in.

Reverse-engineered from the never-released TI-99/8 architecture, the Super Advanced Memory System (SAMS) card allows you to swap out 4K pages anywhere in the addressing space that RAM exists, just using some simple instructions to configure it. These pages don’t even need to be unique; you technically could assign the same page twice in two different places. The base SAMS card gives the TI 1MB of memory, or 256 pages, which is a bounty of space to play in!

But how to write code for such a system? Well, that’s the tricky bit…

Assembly

One thing to call out is that Realms of Antiquity is written in 100% assembly language. It’s reasonable to ask why, when high-level languages could be utilized to simplify maintenance and understanding.

Well, for one, because I wanted to. πŸ™‚

Second, If I was writing a game for modern computers directly, I would not hesitate to use a high-level language. Besides being easier to manage, the most important thing about them is they can be compiled for different architectures. If I wrote a game in Java, I know it will run on a PC, MAC, or even Linux without any problems, and regardless of what kind of chipset or hardware are present.

But for a classic retro computer? You know the hardware and how it works and how to optimize for it. If you need speed and performance, assembly is the way to go. Any high-level language may apply a software pattern that works but could have been implemented with less memory or better efficiency.

Loaders

The TI-99/4a differs from a lot of other microcomputers of the era in that assembly language isn’t readily accessible with the base console. TI BASIC completely blocks access to it, TI Extended BASIC offers some access to load and run but no assembler is provided.

Most 99’ers use the Editor/Assembler to do their work. It was the big package deal, requiring the full system (disk drives, 32K expansion) to use. It had both a text editor and assembler, and two disks of utilities. They even threw in the complete source code for one of their games, Tombstone City.

Now on the TI, there are two kinds of assembly binaries:

  • Tagged-object code
    • Can be loaded anywhere in memory
    • Can co-exist with other object code and ran independently via name
    • Can refer to each other using assembly directives
  • Fixed-binary code
    • Only loads to specific memory locations
    • Stored as “memory images” with a maximum size of 8K per image minus six bytes for a header value
    • Loaded as a chain of files to fill up the entire memory space
    • Usually called “EA5” format as they were loaded using the Editor/Assembler cartridge’s option #5 “Load Program File”

Most 99’ers write assembly programs to start with as tagged object code. They are then converted to fixed-binary files using a utility. Programs load much faster this way as it loads them as 8K segments directly into memory.

As for how to load a SAMS program, which occupies more space than the 32K RAM? We’ll get to that in a bit. First, we go into…

Modules

So in the summer of 2017, I made the decision to convert Realms of Antiquity to use the SAMS memory card. As part of this, I had to figure out HOW to use it effectively.

The only assembler ever written for the AMS was an extension of a popular macro assembler called “Ragtime”, written by Art Green. I’ll give him credit; he did create an entire assembler/linker/loader platform which could utilize the card. But I had already been using a cross-assembler on the PC for speed and efficiency so I didn’t really want to try and compile everything on the TI in emulation.

So instead I read the documentation on how it built modules that were linked to each other and I figured out the pattern.

The first thing with any program in modules to do is identify your “root” functions that absolutely are needed everywhere. These form the basis of your “root” module, which always is present in memory and is accessed by everything. Then, figure out how many other modules you need. Ideally, if the root module and another are loaded, you should always be able to fit it into the existing address space. (Which on the TI is 32k, split into the 8k and 24k blocks.)

For Realms of Antiquity, I wanted the 8K block for data pages only, utilized by the modules for various functions. So I split the upper 24k into two modules, the root module and then potentially four other modules:

  • Start Module (Contains the title screen, character creation, music player and data, and end game sequence)
  • Travel Module (Contains the code for travel mode, includes map loading and mob interactions)
  • Manager Module (Contains the code for inventory, stat screens, and complex transaction management)
  • Combat Module (Contains the code for combat mode)

I later added more modules and sub-modules:

  • Encounter Module (Contains the code to generate battlemaps, as well as end battle management such as chests, traps, rewards, etc.)
  • FX/Scan Module (Contains all the code to create FX for combat, sprite based effects, as well as the code to create the monster stat screen. Only swaps out the last 4K page of the Combat or Encounter module.)
  • AI Module (Contains all the code to determine monster actions. Only swaps out the last 4K page of the Combat module.)

The sub-modules occurred as modules got full and I didn’t want to try and create a whole new module. This made me realize after the fact that I could have done a better job splitting up functionality and making smaller modules instead of larger monolithic modules. A good lesson for future projects!

So how to compile it? I just created several batch files to execute my cross assembler at a combination of the root module files and each targeted modules files, effectively compiling them as separate binary files. I then created some utility programs that copy the binary code out into the program binary file in specific locations for each module.

Memory Map

Here’s a picture of my file and memory map:

The greyed out areas are pages that are technically assigned to ROM addressing space at start-up time. That is the default mode for SAMS; pages 0-15 are just assigned consecutively. So that means after the program has started I can freely use those pages for data.

Pages 2-3 are the 8K lower memory space which means they are switched as needed for different functions. Pages 10-12 are always the root module. Pages 13-15 are the alternate modules. Everything after those is raw data used by the game, up to page 53. I use page 64 onwards for storing saved game data in memory while you play.

So how to get this into the SAMS card? The E/A loader certainly can’t do this. Time for a custom loader…

Custom Loader

The first issue to deal with is getting a loader in the right place. The default location for most assembly programs is the start of the upper 24K block. That’s not ideal here, though, because we want the root module there and if we swap it out at any point in the loading process the loader code will be lost! So we make sure it’s located in the lower 8K RAM instead. This is achievable by using an opcode called AORG (Absolute Origin) to relocate the program there.

The loader has to be self-contained, so it contains not just the loading code itself but subroutines for reading and writing to VDP. This is necessary beyond just updating the screen; the TI device service routines (DSR) which the disk system utilizes requires you to use buffer space in the video memory. This curious design is likely because on a base TI console that was the only RAM memory any architect could rely upon being there for buffer. Unfortunately that means all data has to be read from the VDP back into CPU memory.

The loader loads 8K chunks of data from the program binary at a time into the upper RAM, which are assigned to the requisite pages. It updates the page assignments on each pass, so each 4K blocks ends up in it’s correct page. With 44 pages of data, or 176k, it takes a bit! I originally designed my loader to read in 12K blocks from the program binary, but I found in practice this didn’t work, even when I was certain the VDP memory was freed up. I have noticed that TI was biased towards 8K blocks as a maximum size.

For the cartridge ROM, I have a different approach. I use 8K ROM pages to store the program, using 2K of the space for the loader and 6K for program segments. This is necessary because you aren’t guaranteed what ROM page a cartridge starts on, so you have to replicate your root code in every page. It does a direct CPU to CPU memory copy from the ROM page into the upper 24K page space with page swaps in a similar fashion. This is one reason the cartridge is by far the fastest way to load the game, no VDP in the middle of the process!

And here ends Part 1. In Part 2, we will start looking at specific modules and routines and going into excruciating detail on them!

 

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

Packing, Stacking and Mailing

Been nearly a month since release, and I’m overwhelmed by the response and feedback! Thank you everyone who purchased the game, and I hope to see more as word spreads.

I did an interview with The Lost Sectors on YouTube on Friday, you can view it here:

I also received the cartridge boards and EPROMs from my source to create the custom cartridges for Collector’s Editions, so I have everything I need now to start the mailing! (Formatting floppy disks and copying data is by far the slowest part of the operation. Thank goodness my drives are holding up for the task.)

Each Collector’s Edition will have all contents inside the game box, and will also be shrink-wrapped for added protection. I purchased custom mailers from ULine that fit the box perfectly as well. I’ll be taping them up thoroughly, especially for international shipping. Customs forms will identify it as “merchandise” worth $20 U.S. to avoid high duty fees and delay. Everyone will get emailed a tracking # for it as well. I’ll start on them this week and try and get them all out by the end of the week.

As for what’s next for the blog?

Well, my next TI project at some point! I plan to do a few small-scale ones that I’ve had on my mind. I wanted to do a true assembly version of an old BASIC program I wrote “Aperture”, just to learn the ins and outs of doing a platformer. I also every year around Christmas get a bug to write a game with shopping and having to pick up gifts in a department store and navigate around rude senseless people.

My next big project will be my Gauntlet clone, which will require the SAMS card. I have some particular technical limitations and challenges I have to make sure are achievable with it. I also have a Roguelike on the brain… Something that’s a mix of Rogue, NetHack, Warriors of Ras, and similar.

I may also take some time on the blog detailing the actual coding and design work that makes up Realms of Antiquity. My blog over the years has a lot of details on it, but a linear step-by-step set of posts of “How was it made?” and “Why this and not this?” may be educational for some.

Happy gaming to all! And be sure to check out Nox Archaist, another retro CRPG for the Apple II!

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

Release!

Well I didn’t quite make Christmas… But I did get it done in 2020!

Realms of Antiquity

Realms of Antiquity: The Shattered Crown is now released! Digital edition is available immediately, collector’s editions are in pre-order and will ship late January/early February.

I’ve put together a website for it here, you’ll find links to the store to purchase it on the product page:

http://quixotic.adamantyr.com/

I’ve created a topic on AtariAge as well, as an additional resource for questions and information.

Excelsior! Time to see how long before I have to release a new build…

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

All I Want for Christmas

Wow… It’s amazing to be here. On the cusp of release! My plan is to do so next month, in time for the holidays. πŸ˜€

I’m currently working on the “release candidate” code, which is me playing a game all the way through myself, and fixing stuff on the way. I’ve found enough substantial changes to make it worth the time and trouble!

A change I recently made was to “pad out” transaction scripts and mob files to a near 2-bit value. This gives me a little buffer space at the end of each transaction for changes later after release that won’t alter the address location in the disk file. Without that, any minor change would require a player to start the game over from scratch, something I’d like to avoid.

The game will be sold through a fellow 99’er and a good friend’s website at ArcadeShopper. He sells a lot of great retro equipment and software for a variety of platforms, and hey, anything I can do to pay back a bit to the community is great!

My… precious…

As part of release, I’ve also been working on the tangibles. The game will have a full digital release, of course, but you can’t have a classic CRPG without a collector’s edition!

I’ve had a game box custom-created by BoardGamesMaker, which is large enough to fit all the Collector’s Edition contents. They do excellent work, albeit with a bit of lag time. The unit cost is VERY high though, and so I probably will have to have boxes printed in small numbers, even though I’d save money with bulk.

The manuals I originally had printed by Lulu, but I decided I wanted to get a slightly better one printed locally at a print shop I’ve done business with before. They did an excellent job with both the manuals and reference cards! Sadly, I decided this after I’d ordered a batch of 50 from Lulu, so I guess I’ll have spares to sell…

The cloth map wasn’t something I’d sure I’d even be able to do, until a good friend and fellow retro CRPG developer suggested Spoonflower. I was able to print 9 maps on a yard of fabric for a relatively low cost. I then engaged a professional seamstress with years of experience (Thanks mom!) to help me baste and hem the edges.

It would come as no surprise to any retro-enthusiast that there are many who want the game on ACTUAL old-school media, namely cartridge and floppy disk. Of course, this presents some challenges…

The cartridge is the game’s executable loaded onto a cartridge for faster loading. This also removes the need for any of the other requisite cartridges to run the game. A fellow 99’er has offered me a good bulk rate deal on assembled boards with EPROMS, and I have several dozen old TI carts I can recycle the case for. However, the game loads just fine from disk as well, and the cartridge ROM can be put on an SD card for a modern-cartridge peripheral called FinalGROM. So at some point I’ll probably say “No more carts.” I had cartridge labels printed up in two styles at StickerGiant.

Floppy disks are interesting… They are no longer manufactured, and aren’t something you can 3D print. So working disks can be a bit of a pain to find. Plus my game is pretty big, it requires three double-sided double-density (360k) disks to store. And you can’t use high-density either, they won’t work with the older disk drives or controllers.

Fortunately I got an offer of some old user group disks from an enthusiastic supporter, and I bought some from Greg as well. And anyone who just wants labels because they have their own disks they can use I’ll provide them. (3 1/2″ disks I can’t do anyway… that particular combination for the TI is very rare.)

How many collector’s editions will there be? Unknown… I had dreamed of only selling 99 at most, but I thought that was unlikely to happen. Now, though, seeing the enthusiasm of the retro community I don’t know, it could get that high. Either way, there will be a point where I’ll say “I’m done, digital only going forward.”

Stay tuned for a link to the website in the next couple weeks!

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

Inch by Inch

Well we are officially into the last third of the year, four months left in 2020 to keep my New Year’s resolution to release the game in 2020…

This post coincides with the release of beta 33. (If you’re asking what happened with 32, it was an internal release that followed 31 hastily due to a game-breaking set of bugs, and wasn’t announced.) One of the testers has successfully won the game, albeit with me providing several fixes ahead of them. So I’m feeling very confident that we are close to completion!

The changelist for 33 is huge, I made a lot of updates and fixes based upon tester feedback. Besides fixing obvious bugs or issues, a lot of it is also polishing the design. I ended up changing one spell (Terror) so it impacted all enemy units instead of just one because the spell was almost useless otherwise. In a lot of classic CRPG’s the spells tend to be more for show than actual practical use, and I want to avoid that.

Another change in 33 was a total revamp of the monster’s AI. I originally intended to keep it simple. But I found that many of the stronger “boss” creatures or opponents with spells were just so random and stupid with their use of them that battles were easy to win and kind of dull.

Some of the changes made:

  • I added a new monster trait, pounce, which allows a monster to jump right next to an opponent

  • I updated targeting to be based upon distance to unit and a “threat” level. So the character who hangs back throwing fireballs is eventually going to get targeted.

  • Some monsters are smart, and also consider how wounded characters are as part of the threat assessment.

  • For buff and healing spells, monsters consider if they or any allies need them before casting them.

  • For debuff spells, monsters consider if the target already has it. I was getting tired of the plains dragon constantly hitting the same target with its sleep breath over and over.

  • For any spells that affected locations, the monster now determines how many enemy and ally units are impacted. That way they pick the best direction or location for maximum impact and minimal friendly-fire.

I’m hopeful this will make combat a bit more interesting, since you spend a lot of time in any CRPG engaged in it. πŸ™‚

So let’s hope 33 proves to be a success and from here on out it’s just spit and polish to the first release candidate. I am still doing some balance checks with the economy. The early game seems good but the latter game there was way too much much money and not enough things to spend it on.

That NPC looks like a switch?

That army looks like a staircase?

Terror spell works pretty well…

Posted in Beta, CRPG, Design, Screenshots, TI-99/4a, Video | 3 Comments

Summer of Testing

And here we are in July, in what is proving to be the most “interesting” year of the new century so far. And I don’t mean that in a complimentary fashion. πŸ˜›

My 45th birthday is coming up this week, and sadly I’ll have to spend it at home alone. My family (my mom’s birthday is the day before mine, my brother’s a week after mine) all live in Yakima county, which if you’ve been reading the news, has the highest rate of infection and positive cases for the entire west coast. This doesn’t surprise me in the least; the county’s population is very neanderthal conservative and pretty much ignored all the state government’s emergency mandates until just a month ago.

Even though my family is being ultra-safe, we decided it’s better I don’t come come over to visit until things improve a bit. (I’ll have to deliberately self-quarantine myself coming BACK, just as a precaution.)

And meanwhile, testing continues. And continues. And continues some more!

Beta 29.4 is nearing the end of it’s cycle and 30 will be coming shortly. One of my testers has been both enthusiastic and thorough, and it’s really helped with finding content bugs and even code bugs. I really wanted 30 to be the last beta build, but we’ll see how that goes.

The engine feels like it’s getting pretty solid now. Although… there is some signs there may be some subtle and inconsistent bugs in the code somewhere. After several hours of play, testing started to see little “glitches” on the display, and crashes when interacting with mobs. A game restart cleared up the issues. These could take awhile to hunt down, unfortunately…

One example was a bug with teleport in combat. It crashed the game, but not every time. I eventually had to use a debugger dump to figure out where it was before it went crazy, and it turned out the data table storing the address for the “teleport” routine was getting over-written by monster pathfinding algorithms, as they were next to each other in memory.

I also had to make changes to content when it came to altering maps. I have script and mob types that alter map tiles, but I had to greatly reduce their use. Why? Because they reset after you reload. This creates situations where a player may get trapped. This is something I never noticed in my own testing because I wasn’t playing a “save/reload” style a typical player would.

Both my level curve and monster stats needed adjustment as well. My main tester easily got the party to level 11 (out of 16) without even touching several areas of content, and generally found the bosses easy to defeat if they didn’t have any special attacks. I’d rather err on the side of “too easy” than “too hard” though.

One thing this whole process has made me realize is with any complex system (like a CRPG), the amount of testing is staggering. You could get away with less testing, if you have a much more simple system, but you may not end up with that great of a game.

Also, it’s important to leave your ego out of it. As a game designer and coder, you may get feedback you don’t like hearing. I wasn’t convinced that floating values for damage was necessary, and it was a pain to implement, but I did it. And I’m glad I did so now. Good testers make for a great game!

Posted in Beta, CRPG, Personal, Screenshots, TI-99/4a | 2 Comments

15 Years of Development

Title Screen
Early Title Screen

In May of 2005, I graduated from college with my Bachelor’s in Computer Science. At the time, I had started preliminary work on my CRPG, having decided that working on something original and new was better than trying to port over other games. (Which, in this case, was Chris Crawford’s Eastern Front 1941 for the Atari 8-bit systems.) My first task was to create a scrolling engine, using line of sight blocking. I wonder if every top-down CRPG starts with this?

So, with this month, it’s been 15 years. Yikes.

So it’s been an interesting couple months. I was furloughed from work for six weeks, as a cost-saving measure as the company re-oriented itself for a new and uncertain future. I’m back working now, thankfully, but I’m definitely keeping my eye on how things go.

Despite having nothing but free time, development has been slow. Stressing out about potentially needing to find new work in the middle of the worst crisis the country has experienced in over a century is not very conducive to creative thinking. I did get beta 28 out, but I still have a lot of script testing to do.

A few new features made their way into beta 29, based upon tester feedback:

  • A “return to town” effect, which will take the party back to the last place they rested. Or the starting location, if they haven’t yet. There is both a spell and an item that can do this. Some maps can’t be escaped from this way, because the game requires you to be “trapped”.
  • Floating damage indicators on the battlemap screen. The damage inflicted appears as little floating digits briefly. I pushed back on this a little, not seeing the need but one of the testers said they were so focused on the battlemap they never saw the numbers displayed below.

I still have script testing to do in several more locations, so I’m trying to buckle down and get that done. I want to make beta 29 and/or 30 the LAST beta build before a release.

After that, I have to figure out how I will distribute it. I was originally going to just put it up free for download, but I’ve been realizing that doing so would be wrong. A lot of work goes into a game like this, and to set the expectation that it should be free just because it’s on a vintage system is a bad idea.

As a look back, here’s some screen shots of the early game development to enjoy!

Statistic Bars
Early engine design, different appearance!
Screenshot #1
Early look. Not a lot of mixed colors used… Maps also had names
Screenshot #2
A lot of the basic graphics were done long ago
Screenshot #5
Dungeon walls changed, stopped trying for 3D isometric perspective
Screenshot #8
Combat was similar, but I was running out of screen space…
Posted in Beta, CRPG, Personal, RPG, Screenshots, TI-99/4a | 4 Comments

Beta Blitz

Crazy times…

I’m hunkered down in my home working remotely as we wait out the worst of the coronavirus. Even though our original plans to attend Emerald City Comic Con in Seattle were cancelled, we did end up doing a “hotel staycation” that was very fun and timely; many of the places we went are now shut down for the rest of the month.

You’d think that would mean I’d have plenty of time to work on the game, but my more immediate concerns were making sure that all of us had the supplies we needed to weather the coming weeks without having to use spare socks as toilet paper. πŸ˜‰ Hopefully that should change this week, as I pick back up on the work.

Beta testing has been ongoing for just over four months now, and we’re up to build 27, and 28 should be coming soon. My “major” version number indicates that a new saved game is needed, while “minor” means that only the program binaries and support files need to be changed and that saved game files can be preserved.

That was something I hadn’t honestly anticipated. Having testers have to play through the same content over and over again quickly erodes interest, even when it’s critical to do, such as when a major change to the engine is introduced that fundamentally affects gameplay at all levels.

Unfortunately, it’s hard to avoid. Because I may add or remove text or mob data for fixes or expansions, every single internal address updates as well. This means old saves end up wildly inaccurate and wrong. Plus, saved games actually alter and change the data as they go along, which makes conversion difficult and not worth the time to do.

I’ve also discovered, to my own disgust, that a LOT of scripting is just not working right in places, or has small annoying issues. This is because I never had a chance to play through it and bullet-proof it. I was hoping the beta testing could expose this and make it easier to fix, but in practice because it often blocks the testers and forces a restart, it’s been better for me to just play the content myself and make sure everything is working right. Then anything they find are the small outliers or details that just slipped by but aren’t breaking.

However, I’ve been very pleased with the progress with the game’s improvements. Lots of excellent interface changes made their way in, based upon feedback. I re-wrote the monster pathfinding to make boss monsters move more adroitly and with greater challenge. And several dungeons got major overhauls to make them easier, harder, or just more interesting.

So my next steps are to drop my “super party” (who are max level and can blow through monsters easily; I’m not focused on testing combat/game balance) into some new areas and make sure all the scripting is solid and working as intended. My goal is to make sure in beta 28 there is no areas I haven’t personally checked out.

My goal was to be done by May, and that may still happen. It all depends on how things go! Everyone stay safe out there.

Posted in Beta, CRPG, Personal, TI-99/4a | 3 Comments

Goodbye 2019!

Another year gone, another year the CRPG is not done… Bah! However, it’s NEARLY done. πŸ™‚

Beta testing has been ongoing for over a month, and it’s been going well. A lot of bugs and changes introduced to make the game better, and I know it will get done next year for certain. I’m hopeful I can get it done well before May, which would mark the 15 year anniversary of when I started this project.

Wow, 15 years…. where does the time go?

Back in May 2005, I was graduating college and preparing to move to western Washington to pursue a career in software development. I had dug my TI out of the basement a year or so earlier because working on code had re-awakened so many old ideas and plans. I quickly discovered that the old hardware was difficult to work on, and moved over to emulation for development. (Classic99 even then was an impressive piece of work that functioned extremely well!) I completed a few projects in assembly, and got started on some others, when I decided to take the plunge and work on a full-on CRPG.

It took a year or so to even get to a state where I could say there WAS a game being made. I did a lot of prototyping in the first few years. The first big challenge was replicating the line-of-sight algorithm from Ultima, and a scrolling map. At this point, I created my original website, “Crafting a Vintage CRPG“, which was a predecessor to this blog.

And from there on, it’s been on again, off again year after year… I’m pleased to finally be able to say though it will be done. I am honestly looking forward to sharing this work with everyone, and I hope that people find the game fun and that it helps bring some attention to a very seldom considered vintage computer. πŸ™‚

So what did we accomplish in 2019? Let’s see…

  • I completed the content for the other three world disks. (Mostly. I’m still wrapping up the final dungeon and adding some new content)
  • I completed the combat engine and did some very heavy testing of it
  • I added large-size creatures to the game
  • I started using GitHub to maintain my code base, which has done a lot for efficiency
  • Created the game map in Campaign Cartographer
  • Wrote up the manual and reference card, using stock art purchased from DriveThruRPG
  • I started the beta test with a small selected group of testers
  • Based on testing feedback, I re-added an old favorite features, offhand weapons for rogues

The bulk of the year was spent on content, but I consider that a good thing. If your content isn’t interesting, it isn’t going to keep gamers interested. πŸ™‚

So what’s next? Finish the beta testing, finish the game, get it out there! To quote the 10th Doctor, Allons-y!

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