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!

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

4 Responses to Data Dump

  1. Realms of Quest says:

    For my own game, I also have to plan how I will store the data on the various disk sides. While the most ideal setup will be an SD card reader connected to the VIC-20, I do intend to support the traditional 5.25″ disk drive. Side 3 of the game will contain all of the random encounter monster data and graphics. But some space is reserved there for swap files that will store the travel engine and map portion that the player is currently on. This will reduce excessive disk swappig for single drive users.

    Now with the birth of my second job and no longer being unemployed or underemployed, I don’t have as much free time to work on the game as well. I consider 45 minutes of work put in to be a productive day now. However, most of the game engine is basically done. At this point, I’m just generating content–city maps, townspeople portraits and conversations, etc, at the moment.

    • adamantyr says:

      Thanks for the comment! I lost all my page view metrics when I moved to AWS, so I had no idea if anyone was even reading the posts.

      Yeah, I’m assuming an SD card reader or other advanced system will be used on most TI’s as well… I’m using a Lotharek SD system that emulates floppy drives on my hardware. It’s pretty good, although it’s illustrating the sluggishness of the disk controller. The game will require at least two drives, one for the game disk and one for whatever data disk you’re on.

      Content generation is a great place to be in… The only reason I allowed myself a break from engine work to focus on the first game disk/25% was I realized I needed to SEE how large data files really were and make adjustments and changes to the engine itself based on data.

      Fortunately, with the AMS card and a megabyte of CPU RAM, I can do a LOT of stuff I couldn’t before. My one worry now is that if I’m not careful, the game engine itself could be TOO big to fit on disk. 😉

  2. Realms of Quest says:

    I’m always constantly reading your blog. I think it will be most excellent to see it come out and have it covered in the retrogaming media.

    I sometimes regret using a smartphone to write posts on the internet because of the mistakes that I post. I meant to say: “Now with the birth of my second child” … so I have a lot less free time to work on my passion project. But I still work on it, just a little bit at a time every day.

    I don’t use scripting for NPC conversations like you do — I just use specific text responses for keywords like LOOK, JOB, INFO, etc. Even with a simple NPC text engine like this, I do find writing dialogue to be more difficult for me than doing graphics. Perhaps it’s because I have to make sure the text is properly formatted and looks good on the screen once the data file is created. Or maybe it’s just that writing dialogue is not really my strong suit because I’ve done very little of it in my previous CRPG projects.

  3. adamantyr says:

    Well I definitely want to finish it! I was reading my own past entries and I was relieved to see my transaction system wasn’t THAT old. I think developing it was a major hurdle in the design to overcome.

    No worries on the typos and mistakes, I got the gist of it. 🙂 I’ve honestly cut back so much on how much money I spend on my hobbies… what I need more than anything is just TIME to work on them.

    I hear you on the text… I’m a pretty loquacious fellow myself, and I’ve done a lot of re-writes and cut-downs on my dialogue text. Right now a little over a third of the game disk is devoted to text, so it’s a big part of the game.

    I also have the same formatting problems. I want to avoid making a “scrolling” screen of text, although I may do that if I have to. But that means making sure that all the text for pretty much every transaction fits nicely on the screen. You do have it worse though, with the VIC-20’s 23 column screen verses the TI’s 32.

Leave a Reply

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