![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/10\/Stats.jpg\")
<\/p>\nBeen quiet for a couple weeks… I’ve been heads-down on writing up all the transactions for the first disk.<\/p>\n
Here is a breakdown on the first disk’s contents:<\/p>\n
<\/p>\n
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!<\/p>\n
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.<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/10\/Transaction.jpg\"){kind=spacer}
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! \ud83d\ude42<\/p>\n
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.)<\/p>\n
![\"\"](\"http:\/\/test.adamantyr.com\/wp-content\/uploads\/2017\/10\/TextExample.jpg\")
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…<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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…<\/p>\n
After that, it will be time to work on engine code!<\/p>\n","protected":false},"excerpt":{"rendered":"
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, … Continue reading