[Tutor] Two Problems (databases, and branching)

[Erik Price]

On Saturday, April 27, 2002, at 12:42  PM, Spotacus wrote:

> I could do that, but I was thinking of something along the lines of=20
> skipping the whole program over. An example could be something that=20
> needed a password? Not anything high calibur, but simple, like:
>
> =A0
>
> password=3D raw_input(=93What=92s the password? =93)
>
> ifpassword !=3D =93whatever=94
>
> =A0=A0=A0branch(=93:end=94)
>
> #---entire program goes here
>
> :end
>
> =A0
>
> That=92s the kind of thing I was thinking, possibly. If I used an if=20=

> statement to that effect, wouldn=92t I have to put the entire program=20=

> inside the if statement?

Hey I know exactly what you mean, Spotacus.  When I first was interested=20=

in programming, I remember learning some BASIC that let me say, "go to=20=

line 40" or something (I forget the exact syntax).  It was great,=20
because I always thought of a program as being a start-to-finish path. =20=

It let me turn that path into a choose your own adventure kind of thing,=20=

where I could tell the parser to "go to page 45" depending on what I=20
want to do.

(Come to think of it, I suppose my first programs were D&D modules I=20
wrote when I was younger -- I sort of "programmed" the way that I=20
anticipated my players interacting with my world.  I never thought of=20
that before.)

Anyway, to get back to my main point, I learned that very few=20
programming languages these days let you get away with this kind of=20
technique.  It easily gets far out of hand when dealing with programs=20
that are hundreds or thousands of lines long.  However, what you can do=20=

is make chunks of code that do very specific things, and then tie them=20=

all together using a script.  For instance:

You could write a chunk of code that describes what characters in the=20
game look like.  Merchant is one such character, he has an oily demeanor=20=

and shifty eyes.  His inventory consists of a lantern, a battle axe,=20
some rations, and he has 34 silver pieces.  You can also have this chunk=20=

of code describe how to interact with the Merchant -- you can buy from=20=

him, you can sell to him, you can pay him for a rumor or advice... you=20=

could even write code that lets you rob him of his money or something.

You can also write a chunk of code that describes a monster in a similar=20=

way.  This chunk of code could keep track of the monster's strength and=20=

the experience points you get for killing it.  Of course, the beauty of=20=

programming is that you can do whatever you want, so don't limit=20
yourself to these ideas (and I know you won't).

In fact, you can even write a chunk of code that describes a city.  It=20=

would obviously get very complex, but this is for the sake of=20
illustration -- this chunk of code contains a list of all of the=20
important buildings in the city (places that the player can go to), all=20=

of the important people in the city (such as the Merchant), and any=20
other information that you think is appropriate for this city.

Each of these chunks of code is called a class definition.  A class is=20=

simply a description.  The point is that you try to create these class=20=

definitions so that the things they describe are completely=20
self-contained.  Then you can become very flexible with how you deal=20
with these things -- for instance, you could decide that there are five=20=

cities (each uses the same class to define the city, but each is a=20
completely separate city with its own unique name, population, important=20=

buildings, important people, etc).  Since you have made the Merchant a=20=

self-contained class, you could easily create a new Merchant and put=20
this one in one of the other cities.  Or you could put the original=20
Merchant in one of the other cities.  You don't have to change your=20
entire program this way, because ideally your program will know that no=20=

matter where a Merchant is encountered (even if you coded him into a=20
dungeon), there is a specific set of things that you can do with a=20
Merchant.

These things that are described using class definitions are called=20
objects, and using objects in your programs is called object oriented=20
programming.  I just learned about this recently, but it has helped me=20=

write better code in a big way.  I now try to think of my programs as=20
being composed of things, rather than one big amorphous piece of code=20
that is tightly dependent on the way I've already written it in order to=20=

work.  For instance, using the example from above, you might decide that=20=

you want to allow players to capture monsters to use them as pets or=20
attack creatures.  You would simply add code to your Monster class=20
definition that allows this.  You don't have to go back and change every=20=

single part of your program that interacts with the Monster, you can=20
just start adding this functionality now (and if you want to add it to=20=

your earlier code you can always go back and change it).

Of course, I am using a relatively simple example, which in real life=20
would probably be very difficult to write -- it's easy to say "write the=20=

program to subdue the monster and have it fight on your side", when in=20=

reality the code to do just that would probably be very complex indeed. =20=

But the idea is the same -- that you will go far if you try to write=20
programs that are modular and "chunked" so that when changes need to be=20=

made, you don't need to go through the whole program tearing your hair=20=

out.



Erik