The Legend of Beryl Reichardt

[sometimes99er]

Those stairs are quite good as they are. They’re like sometimes solid and sometimes up against a wall. Magnificent !

[Opry99er]

Thanks sometimes!!! I think they'll do fine!

[Opry99er]

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 March 4, 2010 by Opry99er

[The Codex]

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 March 4, 2010 by The Codex

[Opry99er]

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::

 

1)KFC

2)Church's

 

And then the second represents the "types" of chicken

 

1)Grilled

2)Original

3)Crispy

 

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

 

Owen

[Opry99er]

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.

[The Codex]

Can I get grilled catfish instead?

 

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.

 

LIFE$ =

{

{ "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:

 

MONSTERS$ =

{

{ "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" }

etc

 

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

etc

 

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.

Edited March 5, 2010 by The Codex

[Opry99er]

Holy freaking God, man.... There aren't enough bottles of scrubbing bubbles in all the world to get all my brains off the walls over here--- I'm gonna need a bit of digest time.... I

[The Codex]

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.

[Opry99er]

No-- your example is good, I'm sure.... I'm just not prepared to handle the concept as yet.... Give me the rest of today--- I'll have something for ya.

[Opry99er]

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

-Apples

-Oranges

-Cheerios

-Maple Syrup

Hardware Store

-Nails

-Plywood

-Screwdriver

-Duct Tape

McDonalds

-Hash Brown

-Sausage biscuit

-Diet Coke

-coffee

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

 

A "list of lists". Yea?

Edited March 5, 2010 by Opry99er

[The Codex]

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"

 

Easy-peasy!

 

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):

 

IBM

- CompUSA

--- Diskettes

--- Modems

- OfficeMax

--- Toner

--- Printer Paper

- Arbys

--- Beef & Cheddar

--- Curly Fries

Apple

- 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):

 

DIM MONSTERS$(6,8,4)

 

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 March 5, 2010 by The Codex

[Opry99er]

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 March 6, 2010 by Opry99er

[Opry99er]

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 March 20, 2010 by Opry99er

[Willsy]

One dimensional array: visualise as a straight line:

DIM COLOR$(3)
COLOR$(1)="RED"
COLOR$(2)="GREEN"
COLOR$(3)="BLUE"

Looks like this:

+--------+-----+-------+------+
|        |  1  |    2  |  3   +
+--------+-----+-------+------+
| COLOR$ | RED | GREEN | BLUE |
+--------+-----+-------+------+

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

DIM ARRAY(4,4)
ARRAY(3,2)=9
ARRAY(4,3)=4

+-------------------+
|       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 |   |   |   |   | | | |
+---+---+---+---+---+ | | |
 +---+---+---+---+---+ | |
   +---+---+---+---+---+ |
     +---+---+---+---+---+

[The Codex]

Good deal mate, hope you kick into high once you're back from the gig archipelagos.

[Opry99er]

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.

[matthew180]

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:

 

row=1

col=1

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,

Matthew

Edited March 22, 2010 by matthew180

[Opry99er]

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!!!!

[Opry99er]

Home!!! Its Beryl time, you guys!!! I'm offering a 20 million dollar bounty for the head of the Doppleslicer!!! That S-O-B has killed Beryl's father!!!

[InfernalKeith]

Home!!! Its Beryl time, you guys!!! I'm offering a 20 million dollar bounty for the head of the Doppleslicer!!! That S-O-B has killed Beryl's father!!!

 

I demand to hear speech in this game. "Hello. My name is Inigo Reichart. You killed my father. Prepare to die!"

[Opry99er]

Hahahah!!!! There WILL be speech, I promise you. . Yessiree, with Willsy's knowledge of speech and his Brit accent, this one will be a winner! Hehehe....

[Opry99er]

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 March 30, 2010 by Opry99er

[+adamantyr]

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:

http://arkanixlabs.com/

 

Adamantyr

[Opry99er]

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!