Jump to content

The Legend of Beryl Reichardt


Recommended Posts

You know--- playing Ultima IV and V over the past few days has proven something to me.... Graphics do not an RPG make!!! The story and plot of these two games are so clean that it could have been done as a roguelike or "ASCII-only" and would have been just as great!!! I found a website called Abandonia.com that has dozens of marvellous DOSBOX compatible oldschool top-down and ASCII-only RPGs available for free download... It has really been an eye opener to see how loved these games are, even though they are so limited graphically. It just means that a game with well thought out and implemented graphics can be even THAT much more extraordinary! I'm very excited to continue development of this game and see where I can go with it... It will more than likely be a few-->several months before it's complete, but I know that if I keep this spirit, it will be all I want it to be. :)

Edited by Opry99er
Link to comment
Share on other sites

Yes, sorry, I think those are the ToD stairs. But they ARE nice. ;)


You'll do better anyway. I dig the stuff you've already done for LOBR, and am glad to tell you once again that your monster designs are excellent, as are your characters. And you've got it right that the highest priority is gameplay - roguelikes have no graphics at all and are very immersive and absorbing. Get the game right and the graphics are secondary (though graphics as good as yours will only add to the experience).

Edited by The Codex
Link to comment
Share on other sites

Thanks Codex!!! I really appreciate your words. =) I'll be working on some new stuff tonight... graphics-wise. Gotta do some graphics to keep my head straight. Might work on stairs--- but I'm not sure I can do better than the ToD stairs.


Anyway, at this point, the focus is in developing a 3 dimensional array to handle all my regular enemies. If I have 5 worlds (Forest, Desert, Mountain, Cave, Dungeon) and 9 Monsters in EACH world who each have 5 attributes. This would be a 3 dimensional array (5,9,5). I'm still trying to wrap my head around this concept, but as far as I understand, the 2nd and third members of the array are completely dependant on the previous member for direction. Maybe that doesn't make sense how I said it... Let me give an example


CHICKEN$(2,3,2) **12 total possibilities


Let's say that the first member here (with a value of 2) represents two chicken restaurants::





And then the second represents the "types" of chicken






The third represents how you receive your chicken


1)In a box

2)In a bucket


This may be over-simplified, but it is just an example. If you say "I got a box of chicken," then the two logical questions are "what kind of chicken did you get"? and "where did you buy it"?


So, here are all the possible scenarios for our chicken example


KFC chicken :: Grilled :: In a box (1,1,1)

KFC chicken :: Grilled :: In a bucket (1,1,2)

KFC chicken :: Original :: In a box (1,2,1)

KFC chicken :: Original :: In a bucket (1,2,2)

KFC chicken :: Crispy :: In a box (1,3,1)

KFC chicken :: Crispy :: In a bucket (1,3,2)

Church's Chicken :: Grilled :: In a box (2,1,1)

Church's Chicken :: Grilled :: In a bucket (2,1,2)

Church's Chicken :: Original :: In a box (2,2,1)

Church's Chicken :: Original :: In a bucket (2,2,2)

Church's Chicken :: Crispy :: In a box (2,3,1)

Church's Chicken :: Crispy :: In a bucket (2,3,2)


Now, if you apply this three dimensional array to my current needs for my enemies, you're looking at the potential for 225 possibilities!!!! Fun fun fun... If I've misunderstood this concept, please chime in... I'm hoping I have a grasp of it, since I'll be starting the implementation within the next week. =) Thanks



Link to comment
Share on other sites

Of course it wouldn't matter if the two chicken stores sold different types of chicken... Would it?


KFC sells Grilled, Original, and Crispy while Church's sells Crispy, Barbecue, and hot.... It would still be the same deal.... Since the first member describes the name of the chicken hut, it would be understood that it's

menu could be different---would not affect this array except what the values represnt in the "big list" of chicken types, right??


I'm getting hungry.

Link to comment
Share on other sites

Can I get grilled catfish instead? :P


You've got it, especially with your follow-up comment about arrays containing different values in the same positions. It's the positions that matter. Here's a long essay on arrays if you are interested.


Let's start with the basics and go through how this works. I'm going to use Java-ish code syntax here, because it's clearer to read than BASIC for things like this. But I can translate it to BASIC later if you like.


A one-dimensional array is essentially a list. We'll start with a broad list, that of categories of lifeforms.


LIFE$ = { "Animals", "Plants", "Fungi" }


The {} curly braces indicate a list, or array, of values. Using the above list, and going with the TI convention that arrays start with 1, our array equates to this:


LIFE$(1) = "Animals"

LIFE$(2) = "Plants"

LIFE$(3) = "Fungi"


Okay, say we make this a two-dimensional array. This means it's an array of arrays, or conversely a list made up of lists. With this we can store logically grouped items. Let's continue with the lifeforms, only this time we're going to store classes of lifeforms, each in their appropriate grouping.




{ "Mammals", "Birds", "Reptiles", "Fish" },

{ "Trees", "Flowers", "Grasses", "Algae"},

{ "Mushrooms", "Molds", "Rusts", "Shelf Fungi" }



Now the first index of the array indicates an inner array. Our previous values are no longer single values, but are themselves lists, like so:


LIFE$(1) = { "Mammals", "Birds", "Reptiles", "Fish" }

LIFE$(2) = { "Trees", "Flowers", "Grasses", "Algae"}

LIFE$(3) = { "Mushrooms", "Molds", "Rusts", "Shelf Fungi" }


To get a single value, we have to specify the position of the inner array, and then the position of the item within that array. For example, "Mammals" is in the first inner array, and it's the first item, so:


LIFE$(1,1) = "Mammals"


"Reptiles" is also in the first inner array, but in the third position, so:


LIFE(1,3) = "Reptiles"


"Algae" is in the second inner array, in the fourth position:


LIFE$(2,4) = "Algae"


and "Molds" is in the third inner array, second position:


LIFE$(3,2) = "Molds"


This is still one big array as far as the program is concerned. It simply has two levels of nesting, so you need two indexes to specify any single value within it.


Okay, so, a three-dimensional array. As you might guess, it's an array that contains as its members a bunch of two-dimensional arrays. Let's build this one from the bottom up this time, and use your game monsters as an example. The lowest array here is ATTRIBUTES, since that's what describes a single monster type. If we made a one-dimensional array of monster attributes, it would look like this:


MONST$ = { "Skeleton", "10", "5", "25" }


For this example, we'll say this represent Name (Skeleton), Hitpoints (10), Defense (5), and Gold (25). So if we want to know how much gold this monster is carrying, we ask for the fourth value in the array:


MONST$(4) = 25


This works, but the downside is that you have to have a separate array for every monster. That sucks, not just because it means coming up with a lot of unique array names, but because it means you have to check each one individually everywhere you use them. BY NAME. That sucks hard.


What would make things easier? How about a two-dimensional array, which represents all the monsters in a game world. Let's create a two-dimensional array for the Desert world, of all the monsters that can appear there:




{ "Skeleton", "10", "5", "25" },

{ "Whirlwind", "8", "4", "10" },

{ "Scorpion", "12", "6", "30" },

{ "Djinn", "20", "2", "100" }



Now if we want a monster's ATTRIBUTES array, it's just one of many entries in this two-dimensional array, like so:


MONSTERS$(1) = { "Skeleton", "10", "5", "25" }

MONSTERS$(2) = { "Whirlwind", "8", "4", "10" }



And if we want to know the Hitpoints of a Scorpion, we get the Scorpion's array (the third one), and the Hitpoint attribute from that array (the second value):


MONSTERS$(3,2) = 12


The way to think about this array is that the the first index represents what OBJECT you want, and the second index the VALUE. In this case, the number of the first index is what monster (1 is Skeleton, 2 is Whirlwind, etc) and the second index is what attribute (1 is Name, 2 is Hitpoints, 3 is Defense, etc). The actual values in the arrays are all different, but the INDEXES (those numbers in the parantheses after the array name) always represent the same kind of thing.


MONSTERS$(X,1) = monster X's Name

MONSTERS$(X,2) = monster X's Hitpoints



Whew, I'm exhausted just typing all that. When you've had a chance to read it and ask questions, I'll walk you through the final part - making this a three-dimensional array of all the monsters in the entire game. Unless, of course, all this just undid your learning and you never want to see an array again. :ponder:

Edited by The Codex
Link to comment
Share on other sites

Sorry about that, I probably could have been more concise, given that you already have the fundamentals down. Don't stress over this too much, just take little bits in and use it as a reference if you want. And above all ask questions, even if it's just to confirm your thinking.

Link to comment
Share on other sites

Okay--- I have re-read this and re-read this.... I am pretty solid on 2 dimensional arrays. :) Lets say I have to make 3 stops at stores on the way home and pick up 4 specific items from each store--- I would have 3 shopping lists of 4 items each...


Grocery Store




-Maple Syrup

Hardware Store




-Duct Tape


-Hash Brown

-Sausage biscuit

-Diet Coke


If I wanted ti find Diet Coke, I would look on my third list, 3rd position....


A "list of lists". Yea?

Edited by Opry99er
Link to comment
Share on other sites

Yep, that's right. And say you wanted to change the first item on your second list (you realised you need screws, not nails). This bit of XB would show that happening:


150 PRINT LIST$(2,1) !This prints "Nails"

160 LIST$(2,1) = "Screws"

170 PRINT LIST$(2,1) !This prints "Screws"




Now a third dimensional array just means you are grouping things at one more level. Let's say you're a professional on-demand delivery driver. You take orders for any of five items from up to three different stores, and your business consists of four major clients. You add one more dimension to your array, which represents which client a bunch of shopping lists are for.


DIM LIST$(4, 3, 5)


The first index is the client ID, the second index is the store ID, and the third index is which item to buy. So your data could be something like this (we'll just do the first two clients and two items from each store):



- CompUSA

--- Diskettes

--- Modems

- OfficeMax

--- Toner

--- Printer Paper

- Arbys

--- Beef & Cheddar

--- Curly Fries


- Design Depot

--- Expensive chairs

--- More expensive tables

- Hot Topic

--- Black shirts

--- Black pants

- Starbucks

--- Grande latte

--- Cinnamon biscotti


Array-wise, things now look like this:


LISTS$(1) -> IBM

LISTS$(2) -> Apple


LISTS$(1,1) -> IBM's first store, CompUSA

LISTS$(2,3) -> Apple's third store, Starbucks


LISTS$(1,3,2) -> IBM's third store, the second item on that list, Curly Fries

LISTS$(2,1,1) -> Apple's first store, the first item on that list, Expensive Chairs


In practice you normally only ask for the items themselves, which in your game will be the monster's attributes. But the other two indexes let you group them logically and refer to them conveniently. For your game let's say there are six worlds, each with eight monsters, each of which has four attributes (NAME, HP, DEF, GOLD):




A partial list may look like this:


Desert World

- Monster #1

--- NAME = Skeleton

--- HP = 10

--- DEF = 2

--- GOLD = 5

- Monster #2

--- NAME = Djinn

--- HP = 15

--- DEF = 4

--- GOLD = 25

Ice World

- Monster #1

--- NAME = Frost Giant

--- HP = 24

--- DEF = 5

--- GOLD = 50

- Monster #2

--- NAME = Ice Drake

--- HP = 60

--- DEF = 12

--- GOLD = 500


Now you can reference any monster's attribute by knowing what world it belongs to, and what it's monster number is. What's the NAME of the second monster is the first world? Since NAME is the first attribute, it's:


MONSTERS$(1,2,1) -> Djinn


How much GOLD does the second monster in the second world have?


MONSTERS$(2,2,4) -> 500


Basically, you can read the array as MONSTERS$(W,M,A), where W is world number, M is monster number, and A is attribute number. Then you just need two variables which tell you what world the players are currently in (MYWORLD = 1), and which monsters they are fighting (MYMONST = 2), and your code has instant access to those attributes.


One array to rule them all, one array to bind them...

Edited by The Codex
Link to comment
Share on other sites

One array to bring them all and in LOBR bind them!!!!! Great stuff.... This will be fun. :). Thanks for all your help Codex--- truly... You're one of my guri. :). These next 3 weeks should be QUITE productive, I imagine. :)

Edited by Opry99er
Link to comment
Share on other sites

  • 2 weeks later...

I've been working my tail off for the past 2 weeks and have had NO TI time... I just today finally had time to clear my mind and DL some of the contest entries. Some pretty incredible stuff there--- really. Anyway--- aside from that, I have to say I received a good kick in the ass when I played Codex's LOBR spinoff game... He's done more in 30 lines than I've done on this whole game--- and it's been in concept stage for a year now. Anyway--- I am putting my monsters into a data array, my quest items in another, and I think I'll just finish that up before I start thinking about the next task. BTW, my target date for completion is Christmas this year.... Obviously you can't force or rush these things, but i work better and more efficiently on a deadline. :) Keep encouragement coming--- I need it!!!!

Edited by Opry99er
Link to comment
Share on other sites

One dimensional array: visualise as a straight line:


Looks like this:

|        |  1  |    2  |  3   +

Two dimensional array, visualise in your head as a grid:


|       ARRAY       |
|   | 1 | 2 | 3 | 4 |
| 1 |   |   |   |   |
| 2 |   |   |   |   |
| 3 |   | 9 |   |   |
| 4 |   |   | 4 |   |

Three dimensional arrays: Visualise as a cube:

DIM ARRAY$(4,4,4)

|      ARRAY$       |
|   | 1 | 2 | 3 | 4 |
+---+---+---+---+---+ |
| 1 |   |   |   |   | | |
+---+---+---+---+---+ | | |
| 2 |   |   |   |   | | | |
+---+---+---+---+---+ | | |
| 3 |   |   |   |   | | | |
+---+---+---+---+---+ | | |
| 4 |   |   |   |   | | | |
+---+---+---+---+---+ | | |
 +---+---+---+---+---+ | |
   +---+---+---+---+---+ |


Link to comment
Share on other sites

Willsy--- that ASCII diagram is pretty cool!!! The concept is still a bit fuzzy to me, but I'm learning. More than anything, I need to just focus and get all this stuff hammered out so it can be examined and scrutinized... That's the only way I'm gonna get anywhere in this game. :)

Link to comment
Share on other sites

Owen, understanding arrays is an exercise in abstract thinking. There are endless analogies out there, and you just need to keep reading them until you find one that works. Eventually though, you will use the analogy less and less as you understand more.


Technically (and not considering the internals of any given language) the computer stores arrays as a big block of continuous data, no matter how many dimensions are defined.



Metaphorically, try this analogy:


A one dimensional array of 5 bytes:

Index (subscript) | 0 | 1 | 2 | 3 | 4 |
Array Data          x   x   x   x   x

Note that indexing (also call "subscript") starts at zero, usually. So the maximum index *value* into the array is 1 less than the number of elements.


You use a subscript value to access the data at that location:

DIM A(5) :: A(0)=2 :: A(2)=15 :: A(4)=99

Now the array looks like this:

Index (subscript) | 0 | 1 | 2 | 3 | 4 |
Array Data          2   x   15  x   99


A two dimensional array uses two subscripts and is like a piece of graph paper:

   | 0 | 1 | 2 |
| 0 | x   x   x
| 1 | x   x   x
| 2 | x   x   x

DIM A(2,2) :: A(0,0)=7 :: A(1,1)=8 :: A(2,2)=9

   | 0 | 1 | 2 |
| 0 | 7   x   x
| 1 | x   8   x
| 2 | x   x   9


Internally the computer is still storing this array as a continuous block of data. A good example of this is the screen name table in the VDP. The screen is 32x24 characters for a total of 768 characters (bytes) to put a character anywhere on the screen. In VDP RAM, the first 32 bytes of that data are the first row of the screen, and are referenced 0 to 31. The 33rd byte is the first character on the second row. So indexes 32 to 63 are the second row (remember, the screen is a continuous 1 dimensional array), and so on. You can take a row,col value and find the screen location like this:


((row - 1) * 32) + (col - 1)


The subtracting of 1 is because in BASIC row,col values are usually 1 to 24 and 1 to 32, however the screen name table (and usually arrays even in BASIC) start at zero. If you maintain your row,col values from 0 to 23 and 0 to 31, then the formula is easier:


row * 32 + col


On the 99/4A, what is called a "row" is the Y value, and the "column" is the X value. But in XB, the row is designated first so if you are using variables called "X" and "Y", you have to write "Y" first and that usually looks funny since you normally want to write X,Y not Y,X... Anyway, I digress...


In assembly language, you will have to deal with the screen as a 1 dimensional array, so it is good to understand how a 2D array is stored and accessed as a 1D block of bytes. Let's show our 3x3 array above as a 1D array:

| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
 7   x   x | x   8   x | x   x   9

I added the row separators so you can see where the data is. Now, the same formula works for our array here as the screen. For example, the XB statement we used to set the "8" value: A(1,1)=8 can be calculated like this:




rd=3 (row dimension is 3)


index = row * rd + col

index = 1 * 3 + 1

index = 3 + 1

index = 4


So you see above that an index (subscript) of 4 is exactly where the "8" was stored in the 1D array. In high level languages like XB, the language does this conversion for you, but in assembly (and various other languages), you have to do it yourself. Of course you can provide yourself with simple helper functions to do the conversion, but realize that there is always overhead in doing the conversion calculations. One of the nice things about lower level languages is that they allow you to trade off between performance and programmer convenience.



Dimensions over 2.


Additional dimensions simply add additional level of "reference" to get to some data. Like this:


1D = a row (or list) of data

2D = many rows of data (like graph paper)

3D = many pages of many rows of data (a stack of graph paper)

4D = many folders, each holding a stack of graph paper

5D = drawers of a cabinet, holding many folders, each holding a stack of graph paper

6D = many cabinets with many drawers, holding many folders, each holding a stack of graph paper


See, it is not so tough. To get to any single square on a piece of graph paper, I need 6 pieces of information:


1. The filing cabinet number

2. The drawer number in that cabinet

3. The folder number in that drawer

4. The page number in that folder

5. The row on that page

6. The position in that row (i.e. the column)


So: DIM A(3,5,10,2,32,24)


That would be, 3 filing cabinets with 5 drawers each. In each drawer are 10 folders. In each folder there are two pieces of graph paper, each with a 32x24 grid that represents the character tile layout of the screen.


You can get the memory requirements by multiplying the values, which in this case would be 230,400 (255K), which obviously would not work on the 99/4A, especially since each element of the array in BASIC is not a simple byte.


We could easily add more dimensions to the array just by saying we have "rooms" full of cabinets and building full of rooms (the Library of Congress comes to mind.) Think of a card catalog at the library as a 3D array: rows and columns of drawers, each drawer holds many cards. However, each card in of itself has additional information that could be a 1D array, like title, author, location, etc., so really a card catalog is at least a 4D array that you already know how to use since you were 10!


Oh, by the way, XB supports up to 7 dimensions max. The stuff at each dimension can be anything you want, lists of monsters, items in rooms, etc. Just visualize how you would track the information in real life, then modify to the computer. All this is just data modeling and a very similar process is used when designing databases. Just keep in mind that you really want to prevent duplication of the same information at different dimensions. For example, you would not make the same screen layout and stick them in different folders.


Hope this helps,


Edited by matthew180
Link to comment
Share on other sites

Matthew, that's the best analogy i've seen so far--- well the one that equated the best in my own head anyway. I've been working on some stuff the past couple days--- this is my last night in Georgia, then I FINALLY get some time off!!! :) Reichardt, Im coming for you, boy!!!!

Link to comment
Share on other sites

Alright--- so I've been talking with the fellas on the TI list. Here's the next move--- design the entire map for the first world, however many characters necessary. Then, work out a "zoom" function to show a screen at a time, depending on the position of my character. Not true "scrolling," but think Zelda. Tursi made it pretty obvious how to accomplish the implementation, so that's the next step. :) Very exciting times. I need a PC tool. :). Paint might work. I need a program that I can manipulate a 120x160 screen on a grid/graphing paper type feel. Then I need to be able to break each tile into an 8x8 character. What programs would you suggest? This is the beginning of the real development, and I'm very excited--- Oooooh, fun times!!!

Edited by Opry99er
Link to comment
Share on other sites

Alright--- so I've been talking with the fellas on the TI list. Here's the next move--- design the entire map for the first world, however many characters necessary. Then, work out a "zoom" function to show a screen at a time, depending on the position of my character. Not true "scrolling," but think Zelda. Tursi made it pretty obvious how to accomplish the implementation, so that's the next step. :) Very exciting times. I need a PC tool. :). Paint might work. I need a program that I can manipulate a 120x160 screen on a grid/graphing paper type feel. Then I need to be able to break each tile into an 8x8 character. What programs would you suggest? This is the beginning of the real development, and I'm very excited--- Oooooh, fun times!!!


Technically the tool was developed for the C64, but Cartograph may suit you. It uses the same 2K of character patterns that the TI-99/4a does, and the size goes up to what you need.


Check it out here:




Link to comment
Share on other sites

Thanks Adam!!! I registered to their forum and asked about using this program for the TI. I wonder if (since the screen res is different) it will be compatible with the TI as far as hex data and maintaining a proper 120x160 map.... By that I mean, "I wonder if it's hardwired for their screen dimensions." We shall see! :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...