Quick Update

Gotten quite a bit of ground covered since my last post… All the bugs I first encountered are fixed, but there’s plenty more to deal with. πŸ™‚

I took a brief side-trek to write myself some console applications in C# to help with my work. My original method of compiling the game was as follows:

  1. Build each module source using A99, creating an object file
  2. Using Classic99, load the object file into memory, then dump the memory into a binary file
  3. Copy the memory sections with program data into my program file where they are loaded from

Not TOO bad, but I was quickly running into annoying problems, like anytime I changed code significantly in the root module, I had to also build the start module or things stopped working there. (Because addresses were offset from expected values.) And the fact I had to navigate with the mouse to do loading and debugging in Classic99 slowed me down quite a bit too.

Fortunately, Mike Brent helped out by sending me a simple object to binary program he’d thrown together. I was able to adapt it into a new binary for my purposes that translated the object file into a straight binary file, removing the need for Classic99 in the process entirely.

Then I wrote another console app that did binary copying from one file to another, only requiring you to supply base addresses in both files and a length. That lets me copy the resultant binaries into my program file directly. So now I can compile, build and create the program file all by clicking a single button!

Right now I’m debugging the statistic screens. I discovered that I hadn’t populated real values for item data at all, so that was my first fix. Besides that, mob movement seems weird; my monsters aren’t chasing me and they’re moving across water and other “inaccessible” tiles.

All you can do is just deal with each problem one at a time. Sooner or later you WILL fix them all.

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

Stop and Go

Debugging in assembly language is rather like being a plumber…

You have this pipe, and it’s full of gunk, debris, hair, and other bits of nastiness. It also has various redirects, T sections, valves, andΒ  a bunch of other things. All you want is to run the water into it and have it come out into a bucket at the end. But EVERY time you do, the water gets blocked and stopped somewhere, and you spend minutes finding the blockage and correcting it. Then you get a few inches further, then bam, another block. Find, fix, and again… And again… AND AGAIN…

So I’ve been trying to get the game to launch again with a newly created character. After much sweat and toil I FINALLY got this:

Not quite right… Better than crashing

Let’s see, where to start…

  • Your character is supposed to be on an elevated cliff, so he should be able to see over the mountains
  • The water pattern is wrong, animation must be messing up
  • Two status effects are indicated active which shouldn’t be active at all
  • Why is the stamina bar down from full a bit?
  • Two of the options are displaying as characters instead of text
  • You can’t move or do anything
  • And finally, the sound is going berserk upon launch, when it should be silent

Time to cinch up the overalls and grab the wrench…

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

Demo Anxiety

Back from Con, it was a blast! Meeting David Tennant and Billie Piper was especially cool. πŸ˜€

Back on the game, I decided to step back from combat engine work for a bit and get the rest of the game functioning. At the moment it doesn’t even come up to a playable state, and I’ll want that for the convention next month. I spent a few hours dealing with various errors caused by some refactoring I did (the debugging tool in Classic99 is PRICELESS in this regard) and got the character creation and introduction fully functional again.

And it went total black screen when it tried to launch the game… it turns out none of my map data was in place. πŸ™‚ So I’m working on getting that all populated.

I’m also re-working my elevation system. I had intended to store the data uncompressed but I realized I could actually compress it VERY easily and store it in a much more efficient way in sectors with offsets. Since there are only 4 elevation levels, I can store them using RLE with a single byte indicating up to 64 characters for a given elevation.

The big issue there is writing a tool that will let me define elevation for the various maps without losing my mind… I originally was going to incorporate it into my map/light editor but it’s complex enough that breaking it out into it’s own tool is the best idea.

One nice accomplishment was finishing my transaction and mob tools so now ALL text in the game is embedded with the transaction scripting and mob definitions. Now I can add and remove text easily and just rebuild the entire thing in seconds. That’s going to be very useful for content creation and fixes down the road.

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

Con Bound

A quick update…

I’m going to be at Emerald City Comic Con for the next four days, enjoying myself! Always a nice way to recharge the batteries.

My revisions for levels/experience and bit-delimited text are largely done. I then decided to make some tools updates. Combat work is proceeding slowly because I need to make sure I have sufficient graphics space for all the map types I want to make… I have to take into account content that is not actually completed yet.

Originally I had text encoding separate from mob and transaction encoding, which meant I had to hand-update everything if a change was made. I realized that this was unsustainable, so instead I modified my script encoding to allow me to insert text directly into the scripting code:











Mobs are the same, as some are merely single-line text providers. The biggest issue was I had to change my common delimiter from commas (which text can have) to pipes (which I don’t use.)

I also intend to give “names” to transaction blocks so that I can reference them in my mob file by name. That way if a given transaction increases or decreases size, the reference remains the same.

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

Revisioning and Ranting

Work continues, but I had to take a step back and revise code…

I’m revising all my code to use bit-delimited text as much as possible. I was able to use a lot less data tables for constructing interface screens, which reclaimed some memory and is, honestly, much more elegant.

I also made a major change to the game structure, adding in levels and experience. My main decision there was I wanted to provide some way for players to feel like combat is worth going through. Attaining a new level will increase health and stamina and give you a skill point, which can be used to raise any skill you can find a trainer for. Level requirements are, like Ultima IV-VI, exponential. So the maximum level you can have is level 10, which would take awhile to reach. Completing side quests and main quests will also give you both experience and skill points, so it’s not the sole method of advancement.

I think I’m still on track for a playable demo by Fest-West ’18, fingers crossed! One thing I am very glad about is that I have never asked for donations or money for this work, nor have I ever considered using crowd-sourcing. Case in point…

I am going full disclosure here. I’ve seen plenty of times on the Internet where people talk about drama and problems but then don’t disclose any details or say “Oh everyone knows about it” or “Read the forums/comments if you want the story”. I feel differently. Someone screws me and I’m going to tell you EXACTLY who it is so you don’t give them money.

I am one of the top tier investors on the Judge’s Guild “City State of the Invincible Overlord” reprint Kickstarter. The project was slated to be completed in December of 2014. It is four years past the original date. The project updates are just full of excuses as to why they haven’t finished it. (Moving, new job, sick family, etc.). They also mentioned they are trying to offload the project to an external company or group to complete.

I’m honestly really angry about this. This is the 3rd Kickstarter project that has failed to deliver anything that I’ve invested in. I’m seriously contemplating never using Kickstarter again. Talk to me AFTER you’ve delivered your product and are selling it retail, thank you.

The first Kickstarter that let me down was a massive dungeon module/setting by James Maliszewski of Grognardia. At some point in development his father passed away. He shut everyone out and refused to hand the project over to someone else for over a year. When he finally did, the new group immediately offered refunds to anyone who wanted them, which I took.

The second was the Knights of the Dinner Table Live Action series. It was produced by the infamous Ken Whitman, who afterwards I researched and discovered has been cheating gamers since the 80’s. I’m honestly more angry at Jolly Blackburn for NOT disclosing his history than at Mr. Whitman himself. Ken delivered three videos, one of which has awful audio problems, and then disappeared. I’ll never get my $50 back on that one.

Anyway, back to my own work… I’d like to do up game boxes and feelies and whatnot for it, but in the event they cost more than I can put out on personal funding, I may consider using a buy-in or crowd-source to do it. But I’m going to make sure the game is done first AND that I can meet the deadline I set. I won’t be one of those guys. You get very few chances to retain trust in business endeavors.

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

Bits and Battlemaps

Continuing my work on the combat module, and finishing up the start module! Some updates…

While studying a hex dump of Castle of Tharrogad for the Color Computer 3, I noticed an interesting data pattern… All the text strings had a curious high-value ASCII character at the end instead of the expected letter. I realized that they were using the topmost bit as an end-of-line indicator.

Most “strings” in assembly either use a length value (A byte typically, which means your string can be a maximum of 255 characters) or a null terminator at the end of the string. (typically a 0-byte) In the case of both methods, every string takes up it’s characters in memory + 1. But with a bit-delimited method, it takes up exactly it’s size!

Now you may ask, quite fairly, what does one byte per string matter? Even on a vintage system it’s not THAT much. But in practice, I found I was wasting a lot of instructions to populate the necessary registers to write text to screen. Plus, using the standard multiple byte write routine, you would have to push the length byte into a register then shift it to make it a word value, resulting in burning six bytes of instruction space for EVERY text string.

I wrote a specific text-to-video routine which looks for that bit, and only stops writing when it encounters it. It also can move through entire blocks of sequential text, so that I can only set two values (screen address and text address) at the start, and just change the screen pointer for the rest! The result is my interfaces can be built much more efficiently in memory without a great deal of trade off in performance.

I also made some adjustments so that I could start using compressed text in memory for the Start module. This became necessary as raw uncompressed text pushed the module size to close to the limit. I reclaimed over 2K in space by using compression and the natural text block writing system the game natively uses.

For the battlemap work, after writing out various designs and trying different edge cases, I think I finally hit upon a workable method. Here’s how it will work…

A few years back, I wrote a TI-BASIC game called Aperture, a simple version of Portal. (Which you can find on the TI Game Shelf.) It features 16 different levels with a wide variety of features. How did I do it? I used a procedural generation process, storing different drawing operations such as horizontal line, vertical line, box, and so forth, as well as placement of special objects. Each level took up a couple hundred bytes of dataspace on average; the more complex the level design the more it took.

I realized that this kind of system would work for battlemaps too. When you want to draw features in a two-dimensional format, you’ll find most linear compression methods are very binary; either they are fantastically good or extremely inefficient. This defeats that making the complexity of the screen the only limitation.

The design is as follows:

  • Each tile has a “code” indicating it’s general type such as grass, hills, forest, and so forth
  • Up to 16 character patterns are loaded from memory for the battlemap, some are indicated as “open” spaces and others as “blocked”
  • The various patterns (relatively stored as 0-15) are drawn and plotted. Some methods will scatter patterns at random
  • If you have blocking tiles surrounding the player, these tiles are used to draw “walls” for dungeon and building corridors
  • For each map, a common “wall” and “floor” are stored in the map array data in the event that it can’t determine an exact type

My rough calculations right now show that I should be able to store all the battlemap generation data in around 1 kilobyte. That should be workable!

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

A Preview

A new video… the title screen with music!

Work on the combat module is proceeding slowly… I have to solve the battlemap generation problem, which is a totally new design.

I also did some clean-up work with my external tools. I originally had allΒ  my graphic sets in separate files that were loaded individually into memory. Since they are now part of the program file for the entire game, it made sense to update my tools to just read/write from that file directly. Same thing with the title screen as well. Then any changes made are immediately in game to without having to copy and paste hex data. πŸ™‚


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

Mischief Managed

The manager module is code complete! And with about a kilobyte to spare…

I suppose I shouldn’t be too surprised it managed to take up nearly 12k… building interfaces and controls is by far the most expensive operation in any application. I ended up moving party re-ordering into the travel module. I had originally envisioned a separate page with animation and stuff, but I was able to build something much cheaper in memory and simpler in design.

A lot of the interface focused on only permitting options that were doable. A good example is equiping items. The interface requires you to remove items before it lets you equip something new in the same slot. Why? Because if you had, for example, a 1 handed weapon and shield in the offhand, equiping a two-handed weapon drops two items into your backpack, not one, and if a player had no space for the additional item, it would get lost, or cause an error of some kind.

Another example, if the item in question isn’t usable by the class, you’re not even given the option to equip it. The same goes for trading items. If you’re in a solo party, you can’t give anything away. If it’s a two-man party, your trading partner is obvious.

Next phase, combat! This will be interesting, besides reclaiming and rectifying the older code base, I also have some new code to write:

  • Generate character set graphics dynamically for each map
  • Generate battlemaps dynamically for each battle based on underlying terrain
  • Allow for multiple monster types for different stats
  • Allow for large monster types that occupy four squares instead of one, and must be targetable as a single entity

Cry havoc… πŸ˜‰

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

Manager Mayhem

A short update, work is continuing but more slowly due to real life…

For starters, I attended a convention in Portland last week, which was a lot of fun!

Unfortunately, I managed to pick up an ear infection in the last couple weeks that’s been slowing me down, both on hobby time and at work. I’m on antibiotics now so hopefully that will nip it in the bud soon.

The manager module is filling up fast, I only have around 2K and change left. I’ve decided to cut a feature, which was in-game storage of items, which would have been facilitated at various buildings in the major cities.

The problem is that the amount of code necessary to build and control an interface is significant. I have to complete the critically necessary components (like party management and player inventory control) before I can think about adding bells and whistles. In fact, that’s more the kind of feature that would come out of play-testing, if item management proves to be a problem.

After all the major game code is complete I may be able to move about/juggle some specific features into different modules and add new ones. The travel module has space to burn, potentially. (Although I am still not sure where the End Game code will go…)

The CRPG Addict has been playing an older game “Deathlord” recently, and having a very frustrating time of it. You can read his latest post about it here. It illustrates the importance of not just completing a game, but designing it well. A good game is like a good story; pacing is everything.

On the side, I’ve also been writing and re-writing portions of the content on the later disks. My early maps and places definitely have had the most time spent on them, and the latter not as much. A particular concern for me is to avoid repetition; having the same kind of character, story arc, or quest elsewhere is not all that fun. Tying it all together and making it a cohesive whole is paramount.

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

Happy New Year

Happy 2018 everyone!

I didn’t get quite as much done as I’d hoped, but I did make some significant progress on the CRPG.

I finally finished the title screen! I may still go back and tweak it a bit later, but right now it looks good enough to ship with if needed.

I also completed the musical opening, although I still need to integrate it into the program. I’m still going to do some work there as well; there’s a bug where after the song is completed there is a last little “bing” of notes from a source unknown. I also want to soften the volume on it; it’s rather loud on the hardware even with the P.E. Box on.

Code-wise, I completed the Travel module, all that remains is the sailing portion which is tied into the manager module. I’ll no doubt have many bugs and issues to work through once I run it, but at least it’s code complete and it compiles without error.

The manager module is a bit of work, because I’m throwing out most of what I’d done previously and starting fresh. For statistics screens, I originally loaded screens from disk and then populated them with values. This time around, I’m generating the screens completely in code. (Yes, I COULD store them complete screens in memory, but see below on that.)

I’m hoping that transaction code will remain mostly the same with just some tweaks. I figure I have at least a couple multi-hour sessions ahead before I can call the Manager module code complete.

My goal is to keep the program file, which is loaded in chunks into the extended memory, at 128K. This is to keep the base disk size for the entire program at 180K, because there are still a LOT of 99’ers who lack disk controllers capable of more than that. Disk controllers are mostly TI on eBay these days, and if you don’t get an 80-track modification done to them they’re limited to 180k.

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