Using "OPEN #1:....." Help...

[Opry99er]

Starting to really think about this filing system on my CRPG, "Legend of Beryl Reichardt," and thought that this might be a topic that could be discussed on its own thread.

 

I am in need of a concise, planned out, strutured filing system for the large amounts of variables contained in this game. I could pass them all as arrays all through the program, but I know that because of the varying environments that will be built into the gameplay, I will need seperate and independant records kept on DSK. This will make the RUNning of XB programs from other XB programs (for different game worlds, character definitions, battle sequences, etc.) easy to manage. Here's what I need help on::

 

I want to see and try several different examples of how this can be used to keep track of variables using the UPDATE mode.

I have written several very small programs in XB trying out this function of XB, but nothing real extravagant. I'd like to learn to be creative with this.

 

Any suggestions you guys could make, I'd love to learn. I have the XB manual examples (p.138-140) and a few I had to debug in "Old Dark Caves"... I'm learning, but I will need to be proficient in this if I want to have an organized game engine. Thanks alot in advance. =)

 

**XB examples** (p.140) "TI-99/4 TI Extended BASIC manual"

 

 

*Example 1

 

>100 OPEN #1:"CS1",FIXED,OUT

 

 

 

*Example 2

 

>300 OPEN #23:"DSK.MYDISK.X",RELATIVE 100,INTERNAL,UPDATE,FIXED

 

 

 

*Example 3

 

>100 OPEN #243:A$,INTERNAL

 

 

 

Example 4

 

>100 OPEN #17:"TP",OUTPUT

 

 

 

Thanks!

 

 

***Edit***

 

And remember.... This is an RPG, I'm not worried about a couple seconds of load time between a battle sequence and the next "exploration" screen. I'm more concerned with "orderly" than "fast". I know we can achieve both, but my primary concern isn't the speed. =) Slow and steady wins the race, I hear.....

Edited February 23, 2010 by Opry99er

[+adamantyr]

Starting to really think about this filing system on my CRPG, "Legend of Beryl Reichardt," and thought that this might be a topic that could be discussed on its own thread.

 

I am in need of a concise, planned out, strutured filing system for the large amounts of variables contained in this game. I could pass them all as arrays all through the program, but I know that because of the varying environments that will be built into the gameplay, I will need seperate and independant records kept on DSK. This will make the RUNning of XB programs from other XB programs (for different game worlds, character definitions, battle sequences, etc.) easy to manage. Here's what I need help on::

 

I want to see and try several different examples of how this can be used to keep track of variables using the UPDATE mode.

I have written several very small programs in XB trying out this function of XB, but nothing real extravagant. I'd like to learn to be creative with this.

 

Are you planning on using Extended BASIC for all your file usage? It's not all that efficient to use for files, which is why Old Dark Caves and Legends both avoid it. An assembly routine to handle your file accesses may be the least painful way of doing it.

 

If you're absolutely insistent upon it, I highly recommend using strings for all your data, including numbers. You can use CHR$ and ASC functions to convert from string to numeric as needed, and you can compact it much better in the BASIC file system. Try writing a file out in Classic99 then viewing it in a hex editor. You'll see what I mean.

 

UPDATE and RELATIVE are your methods to access individual records. However, your fine control is still limited to the width of the record. So if you read an 8-byte record in, you have to write an 8-byte record back out.

 

Your first step should be to lay out all the data you want to store externally. Then figure out when and where you need each part, exactly.

 

It's been years since I tried to do anything complicated with the Extended BASIC file system... heck, figuring it out for my CRPG was the first major hurdle, and I'm relieved to be well past it.

 

Adamantyr

[sometimes99er]

Will this storing of variables only happen between levels/scenes ?

 

If so, I think the following will be the easier and more stable approach. You only need to write 2 functions:

 

1. Write all variables

2. Read all variables

 

The idea is, if the level needs the variable A, and the battle scene needs variable B, then you need to save and load both A and B.

 

When you write all variables, you can even let the user name the file (reuse or new). This would allow different players on the same machine and/or the same player having different states of the game (different games) on disk.

 

Edited February 23, 2010 by sometimes99er

[Opry99er]

That's fascinating, sometimes!!!

 

Adam, I noticed that Old Dark Caves has quite a bit of dsk access using "OPEN #1..." when I look at those accessed files in TI99Dir, they are very simple files that have readable an easily understandable "drawers" for value storage... I don't know what exactly is written to these files, but from what you're describing, it's not XB variable info?

 

I am not set on anything... The best and most efficient method is desired... That's what this thread is about.

[Opry99er]

I actually considered using DSK1 AND DSK2 for this... Have both drives cranking at once... One for XB programs, and one for assembly support and files. This would allow the disk controller to more quickly access multiple files and would help keep the thing organized. Much of the graphical screen draws and such will be done in assembly to speed up the process--- sort of to offset the slowness of file access via DSK. It's a thought....

[Opry99er]

As to the question about "when" this stuff will be accessed, Ive gotten as far as "between scenes" so to speak. As I move further along in planning, this requirement may extend into actual gameplay--- for instance, the battle sequence: a "random" equation will determine which enemies will be in a specific room--- with an exception made for higher level enemies--- they will not be randomized--- they will be static. This could be achieved in one of two ways--- first, this could be accomplished by a random function followed immediately by DSK access to load the room full of enemies and items. Another way would be to take the ToD approach and create/load an entire section before the player enters that section of the game. Remember the "Digging floor 1" and "Stocking floor 1" thing? This takes a bit of time, but makes the gameplay in that particular "floor" quick enough to offset the load time.... Thinking.........

[Opry99er]

In thinking more about this issue, and partly because of Karsten's suggestion about read-all, write-all idea. In the iconic RPG "Faxanadu" for the NES, they handled this issue in an interesting manner.... There was a string of characters that represented ALL the elements of the game... Gold, EP, MP, HP, EVERYTHING... This is an actual example of a Faxanadu password or "mantra"

 

gsb?8A?,INwbg3AU 4IUx0PhA

 

If an NES game can monitor all these variables with a string this simple, I shouldn't have too much trouble managing mine, right? As for loading screens, enemies, etc., I'll figure something else out there... But for managing my player variables, I think it will not be a big deal---- the real question is how to use the "OPEN #1..." to manage, load, and save the worlds, screens, enemies, etc... That's the issue I really want to address.... Thoughts?

[The Codex]

This is a kind of indirect answer, and it may not apply to XB in a useful fashion, but in my games I normally create a "state string" for all my game objects. This is a text string that encodes all that object's possible properties at any given moment. For example, a dungeon item might look like this:

 

WM401:07@12/17

 

What these values might represent are W = Weapon, M = Melee, 4 = Item #4 of this kind (a broadsword), 0 = current modification of base damage (+0 damage), 1 = current modification of base chance to hit (+1 to hit), : = separator character that tells the program that the next chunk is the item location, 07 = dungeon level, @ = character that says the next chunk is a grid coordinate, 12/17 = item is locate on the level map at x=12, y=17

 

Then I have a parser utility method that turns any string into the correct game object. (The flipside is that it also encodes any object as a string, so that it's easy to save to disk in a savegame file.) It reads the data file line by line, working out what everything represents. So in our example it gets to the above line and says "Okay, I need to create a new weapon object, it's the fourth melee weapon type, it has its damage adjusted by 0, etc". This is a simplified version of how ToDR works for example - it encodes the whole dungeon, the party, the ongoing quests, everything as a series of state strings that can then be read back in. The parser utility method just reads that file one line at a time and recreates each object encoded there.

 

Unless your game is highly simplistic, or you don't care to save every detail (monster's hitpoints, treasure locations, other volatile settings), then it is possible to describe a whole game state with a short string of characters like you describe. But a proper RPG, where the player can customise the characters and where one expects play to resume exactly where one left off, it's actually easier to load and save everything from state strings.

[Opry99er]

A very nice example! I wonder if this kind of thing is possible in XB... I like all the parameters you laid out there--- very very interesting! This is precisely the kind of input I was hoping for... So, another example... if I may--- a bit more relevant to my own game::

 

O:A:3HP:W:D:12:17

 

Here I used ":" to separate each piece out

 

O-object

:

A-amulet

:

3HP-add 3 health points

:

W-world

:

D-desert

:

12 (Y coordinate)

:

17 (X coordinate)

 

 

This is quite possible... I am just wondering how I would access and implement the information stored on DSK.... This OPEN function is kicking my ass... The XB manual is EXTREMELY vague. But I love your idea, it gives me some serious thoughts....

Edited February 25, 2010 by Opry99er

[Opry99er]

I need to write a parser utility apparently.

 

the reason I separated everything out is because a parser that checks for a ":" between every piece of the string would be easier to design... I can write that tonight!!! I guess the most important thing to do first is to come up with a string format that can handle all the different elements.... That means I need to figure out what all the elements are. Hehehe

Edited February 25, 2010 by Opry99er

[The Codex]

You've got the idea! Though I can't really help you with the disk access at the moment. I can't quite recall if the TI support random file access, or only sequential. But the colon-separated item properties is something I do myself. As you say, it makes separating the properties very easy, without relying on old school methods of hardcoding positions by saying "the first byte is always the type, the second byte...". It does mean increasing your file size a little by adding those extra characters, but there is another level you can add to this to make that increase all worthwhile.

 

The second stage of advanced object storage is a two-tiered approach, which can be called "catalogs and instances". Catalogs are top level object definitions and contain all the information about an object that never changes. Here's how a partial Catalog might look:

 

M1:Goblin:HP12:S3:X50

WM1:Dagger:D3:H1:$20

OA1:Pendant Of Fortitude:HP+3:$100

 

This Catalog contains a monster, a weapon, and an item. In this case the first state describes Monster #1 (M1), which is called a "Goblin", it has 12 HitPoints, a Speed of 3, and grants 50 eXperience when defeated. The second state is Weapon-Melee #1 (WM1), called a "Dagger", which does 3 points of Damage, is 1 Handed, and is worth $20 gold (or whatever game currency). The third item is Object-Amulet #1 (OA1), called the "Pendant Of Fortitude", it adds +3 to the wearer's HitPoints, and is worth $100 gold.

 

The nice thing about a Catalog is that you can define all these "immutable" traits once, and then recycle them in the Instances. An Instance is an actual occurrence of something from the Catalog. Let's say one level 1 of the dungeon you have 3 goblins and the amulet. You could of course store each one as a whole description string:

 

M1:Goblin:HP12:S3:X50:01@12/17

M1:Goblin:HP12:S3:X50:01@05/24

M1:Goblin:HP12:S3:X50:01@37/06

OA1:Pendant Of Fortitude:HP+3:$100:01@04/08

 

But the nice thing with having the Catalog is that each Instance can be just the Catalog ID of the object, and whatever individual settings are different for each:

 

M1:01@12/17:2

M1:01@12/17:0

M1:01@12/17:5

OA1:01@04/08

 

Now what our parser does is load the Catalog first as the authoritative list of things, and then when it loads the Instances from the current game in simply looks up the ID in the Catalog, creates an object of that kind from the Catalog definition, and then applies whatever Instance values there are. In the above example, the parser says, "First item is Catalog ID M1, that's the Monster #1, so create one of those. Now put it on level 1 at position 12/17 (01@12/17), and knock 2 hitpoints off it because the player has smacked it once already." It continues through the list, creating two more goblins at the appropriate places and with the damage adjustments on each, and then it adds an amulet to the right spot.

 

You can see how handy it is to define the majority of a object in the Catalog, since much about it will never change, and then create individual copies from that with the various changes that apply to each (location, damage, etc). Again, this is exactly how ToDR does it, with huge data lists of all the monsters and goodies (Catalogs), and short key strings in the dungeon file for each individual occurrence (Instances).

 

Hope this makes sense, it's a very object-oriented approach, which isn't XB's bag (but it is Java's). But some of this can apply to any approach, when you are looking at loading, saving, and creating complex objects from states stored to file.

Edited February 25, 2010 by The Codex

[Opry99er]

Codex--- this is a magnificent explanation of precisely what I was looking for!!! Wow!!! I have so much to learn! To your question, TI XB DOES allow random disk access. So, that might modify your advice. But in any case, I am learning a bit of Java---enough, anyway, to understand your meaning of "object oriented" programming. In my case, the "object" will be a special filing system on the diskette from which these catalogs will be drawn. Have you done any blogging on the ToDR project,other than the little I was able to read on your site? I would love to have access to your programming notes---given that they are not language-specific. . Thanks again!!! The wheels are really cranking now!

[Willsy]

But a proper RPG, where the player can customise the characters and where one expects play to resume exactly where one left off, it's actually easier to load and save everything from state strings.

 

Eaxactly. Wherever possible, simplicity should take preference.

 

I advocate a simple approach:

 

1000 REM SAVE GAME STATE
1010 OPEN #1:"DSK.TLOBR.SSTATE",OUTPUT,DISPLAY,VARIABLE 80
1020 PRINT #1:MONEY$
1030 PRINT #1:HEALTH$
1040 PRINT #1:STAMINA$
1050 REM SAVE SPELLS (PLAYER CAN "KNOW" UP TO 6 SPELLS
1060 FOR I=1 TO 6
1070 PRINT #1:SPELLS$(I)
1080 NEXT I
1090 REM SAVE CURRENT LOCATION IN MAP
1100 PRINT #1:MAP$(ROW,COLUMN)
1110 CLOSE #1

 

Loading the state is just the opposite. DV80 files are used, meaning they can be opened in a simple text editor if required.

 

If data in the files needs to be obfuscated to stop hacking, then a simple function can be written to achieve this, but small steps first. Get the data loading and saving first.

 

The other nice thing about the above 'simple' approach, is, it's easy to add to, if you need to save extra data items. Your requirements will change as the game develops, and it's nice if the impact of those changes can be relatively small.

 

M

[Willsy]

That means I need to figure out what all the elements are. Hehehe

 

Exactly. As I mentioned to you you before, a game like this needs to be PLANNED. You can't just go at it. You will code yourself down a one-way street that you may find it very difficult to reverse out of!

 

The plan can take the form of a 'formal specification' (the sort of thing I get paid to write every day), or, just a useful, go get a notebook and just start scribbling. Let the ideas flow out of your mind. I use a new notebook for each project. Make referal to notes much easier later on!

 

Take an evening to sit and chill and write out some notes. It will definately help you.

 

Think at a 'high' level first - very general stuff, what the facilities the game should offer etc. Then take each thing you have written about, and write some notes about that. Eventually you get down to the point where you have indentified your requirements enough to be able to code them.

 

Also, yoou should seriously consider using XB SUBs for you code: You aren't tied to line numbers, you can pass parameters around, it's *much* better than using GOSUB/RETURN and global variables.

[Willsy]

Codex's reply about catalogs and instances is very nice advice. It means creating new objects and items is as simple as adding them to the catalog.

 

Maybe have different catalog files, for:

 

• Monsters
  
• Rooms
  
• Items (things you can pick up)
  
• Spells
  

 

Then, if you want to add a new spell, it's as simple as adding it to the Spell catalog.

 

A couple of lines at the *begining* of each catalog file can describe it's format (how many data items etc in each record) which means a generic parser routine can be developed that can read (and write) to any of the files...

[Opry99er]

Man, we're movin' now!!! I've been planning like crazy--- in the shower, Im thinking about how to maintain variables, on the drive into town, I'm thinking about each level and how to best incorporate the battle sequences. I'm very immersed in this game, Mark, as you suggested I become. I have a new blog on my site for this game--- but the formatting is kicking my ass. Bryan said it looked like "The Valley of the Damned" in his browser. . Anyway.... My thoughts on this are really taking shape thanks to tuis forum.. I'll update later today.

Edited February 25, 2010 by Opry99er

[Opry99er]

1010 OPEN #1:"DSK.TLOBR.SSTATE",OUTPUT,DISPLAY,VARIABLE 80

 

this is the part that gets me... I'm just not sure how to format my OPEN statements to achieve my desired goal. The XB manual is vague on what this crap means and I'm just not experienced in it. This example makes sense in it's own context, but if I were to try to do something with this feature, I'm afraid I do not know the proper way to decipher all the different SYNTAXes of this function. I'll go back to the XB manual, but again, I found it to be vague, and I need a bit more info than the manual gives. . Thanks Willsy, your posts on this game have been invaluable, and I hope to hear more from you-

[The Codex]

To your question, TI XB DOES allow random disk access. ... Have you done any blogging on the ToDR project,other than the little I was able to read on your site? I would love to have access to your programming notes---given that they are not language-specific.

 

Good, random access is much nicer than sequential. You can use random access and file offsets to load your data very quickly then.

 

Sorry, I don't really have a development blog as such, like our good friend Adam does. Maybe I should start one, if only to document all the blind alleys I go down during coding. But I will try to chime in when I think I have useful development advice, and am always open to questions, though my coding style isn't necessarily one that folks should always emulate.

 

Maybe have different catalog files, for:

 

• Monsters
  
• Rooms
  
• Items (things you can pick up)
  
• Spells
  

 

Then, if you want to add a new spell, it's as simple as adding it to the Spell catalog.

 

A couple of lines at the *begining* of each catalog file can describe it's format (how many data items etc in each record) which means a generic parser routine can be developed that can read (and write) to any of the files...

 

Precisely. Once again that's how I do it in ToDR, right down to having the data format in a comment header at the start of each file. Monsters, items, character classes, room layouts, each is their own data file. And a lot of this inspiration came from the original ToD, which, although it has only one data file, does use a cataloging syntax to describe almost everything. About the only thing hardcoded into the ToD engine is the spell effects.

 

If you look at the ToDR data files Owen, or download my ToD parser and run it again one of the original modules, you can see quite clearly how the catalogs are built. It's all very close to human readable.

Edited February 25, 2010 by The Codex

[Opry99er]

Great stuff! I'm going to try to get all your Java stuff working on my new computer... It worked swimmingly in my older XP PC, but for some reason some of the stuff that worked over there isn't working on my Windows 7 unit. I updated my Java and I'm able to play Wumpus online and watch the brilliant animated sequence with the modified Mishkoff score---but can't play the game for some reason. If I had all those tools, I'm sure this process would be much simpler. If I remember correctly, the ToD toolkit was VERY cool.... I haven't looked at it in over a year though. . Howard, do you Skype?

[The Codex]

Yes I do Skype. I video Skype from home, and I have chat Skype open at work because we have a very office-and-home team here. I can send you both of my Skype IDs, though I'm a little leery of doing so because it seems that you never sleep.

 

As for the Java issues, there are a number of possible factors. One of the biggest downsides to Java is that everyone's setup is different, and sometimes people install browser plug-ins or other apps that screw up the Java settings across the board (happened here at work). Another potential problem is that version of Windows from Vista onwards have these security lockdowns in place that severely restrict execution rights and file access, so Java can also fall afoul of those (I'm still on XP so I it's hard for me to debug those occurrences). Anyway, we can chat about your issues with Java and hopefully get you up and running in short order.

[Opry99er]

Hahah!!! I DO sleep... But not much. . Too much TI work to be done to sleep!!! My Skype ID is Opry99er--- shocker there. Anyway, the tools you've written are amazing, Howard. Your efforts are largely unnoticed by the TI community, but ever since I first found your DreamCodex site, it's been a bigtime influence on me. I'm hoping we can work on projects together--- I know your knowedge of RPG development is second to none, so I very much appreciate you being here on Atariage. . When you're not at work, let me know. I'll hop on Skype and we can get this Java stuff worked out!

[The Codex]

My Skype accounts aren't exactly well hidden either. If you search within Skype for "Howard Kistler", you'll get exactly two matches - my work account (DC) and my home account (Vienna). I'll add you to my home account, since I have non-list communiques blocked (can't stand chat spam). And I'd be glad to help out on your RPG project as much as you like. Which reminds me, I need to finish the new adventure module for ToDR, which has been sitting at about 90% done on my drive for over a year...

[Opry99er]

Ooh.... New ToD adventure!!! . Can't wait!!!

[The Codex]

It's a sequel to Quest For The King, called The Black Candle. It incorporates the new stuff I added to the ToDR engine beyond the original spec. Probably the biggest change is unique items and monsters, which only occur once per dungeon and which are "named". Unique monsters can have a mob of follower monsters as well. These concepts are found in later roguelike games.

[Opry99er]

Now, Codex--- I have a couple requirements for my game that perhaps may be more difficult than originally anticipated... There are 3 or 4 enemies that MUST only occur once.... Bosses, so to speak. You mentioned that as a feature of your new game--- it's been figured into my planning for this game since square 1. My question to you is, with what you know about XB and the format I'm choosing to use, would creating single-appearance "static" characters be an issue, considering that we are using random disk access to generate 99% of the enemies on this game? It didn't strike me as an issue until just now, but since you mention it, no ToD game I remember had that feature. I suppose the "boss" could just be built in to the stage... Man, there's more to think about--- love the idea for a sequel for "Quest" though!! Long overdue.