Making A Text Dungeon Crawler On the Commodore 64: Part 5 Catching Up

So, I took a couple days off from my Commodore 64 BASIC dungeon crawl to take breather from the project, a little breather, and to work out how I was going to handle the movement and other factors that are needed to make a dungeon crawl.

In my attempt to "save memory" I decided to use a one dimensional array to store my room data and, even worse, I stored strings instead of integers in my array. Something like:

10 DIM RM$(100)


Now the reason this is bad is because it's hard for me to find the edge of the east or west border. To move east I simply add 1 to the players location. To move west I subtract one. (PL is equal to player location.)

1000 REM MOVE EAST
1010 PL = PL + 1
1020 REM FIND EDGE CODE GOES HERE
1030 RETURN
1040 REM MOVE WEST
1050 PL = PL - 1
1060 REM FIND EDGE CODE GOES HERE
1070 RETURN


It is very difficult to find the edge of the play field when a single dimension array is simply a big line of memory. It's harder to work with.That means, in order to find the edge of the screen I have to write a lot of IF-THEN statements which takes up a lot of my precious RAM and takes up a lot of time.  I figure if I'm going to use RAM I should make my life easier and use a two dimensional array.

10 DIM RM$(10, 10)


This would give me an appropriate coordinate system to play around with and let me do east-west border checks.

1000 REM MOVE EAST
1010 PX = PX - 1
1020 IF PX < 0 THEN PX = 0
1030 RETURN
1040 REM MOVE EAST
1050 PX = PX + 1
1060 IF PX > 9 THEN PX = 9
1070 RETURN

Now you might have noticed that I call my player location variable PX instead of PL. The reason for this is I now need two variables to track location. Hence I now use PX and PY for the position of the player.

The last thing I want to touch on is the lack of an object. I didn't touch on this in the video since it was already running around 10 minutes long but I did want to mention something about it.

An object is, for better lack of a term, a collection of variables. It is also a new kind of variable. For example in C I can create a structure (struct) that holds several variables at once. If I was making an RPG I could do

struct character
{
     char *name;
     int strength;
     int dexterity;
     int wisdom;
     int stamina;
};

The "int" variables hold integer values and the "char" variable would hold a string. This makes life easier for programmers since you can start modeling real life things such as a CRPG character in our example above. I could use it like so.

int main()
{
    struct character player

    player.name = "Steve"'
    player.strength = 15;
    player.dexterity = 12;
    player.wisdom = 8;
    player.stamina = 19;

    return 0;
}
As you can see I have all the variables I need contained in the struct called player. Commodore 64 BASIC doesn't allow for this. So, in my case above I have two variables that will keep track of the player's coordinates: PX and PY. Even worse, I'm limited to only two letters or a letter and a number for variables names so it is hard to keep track of what variable belongs to what entity (player or monster) To me this feels wrong but unfortunately there is nothing I can do about it. I could always use more arrays.

10 DIM CX(10), CY(10)
In this example C stands for creature. I could always use the first index in the array CX(0) to represent the player character and the rest to represent the other creatures in the game. It's a fairly simple solution and I think I may try it.