Script Classes for Adventure Games/Introduction

Official SCI Documentation

Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14
15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | Index

Introduction

Author: Jeff Stephenson

Date: 5 April 1988

 

Introduction

An interesting feature of object-oriented languages is that simply knowing the syntax and the primitive procedures (kernel calls) of the language does not help you all that much in the actual process of sitting down and embodying an idea using the language. The basis of object oriented programming is in the hierarchical class system — the properties of the classes, the methods which operate on them, and the inter-relationships of the classes. Thus this document, which attempts to describe the class system for the Script development system.

Note that describing the class system for Script is like trying to shoot a moving target — the classes are constantly changing, though the rate of change does seem to be slowing down somewhat. As we gain experience, the class hierarchy will stabilize, but until then keep your seatbelts fastened, since the ride is likely to be a bit bumpy.

The most important principal to keep in mind when programming in an OOPL is that classes should be embodiments of abstract concepts, not kludged code to do something that you don't feel like thinking through. Purity of programming and concept is very important in an OOPL. Since the structure and methods of a class are inherited by all its subclasses, small changes may have wide-ranging effects. On the positive side, a well thought-out class system almost seems to program itself — objects and classes which are accurate representations of the world which they are supposed to model behave logically in response their inputs. The programming process becomes a matter of telling objects how to behave rather than writing masses of complex code.

One rule of thumb is to not add a property or method to a class if it doesn't logically belong there — create a subclass instead. As an example, consider the problem of moving a number of things around the screen in unison. We might decide to represent this as a Collection of Actors (see the class descriptions below) and move the Collection around the screen. This, however, requires that we add positional properties and a move method to the class Collection and write some fairly kludgy code to keep the actors in the proper positional relationship. If we do this, however, all Collections and subclasses of Collection carry around all this baggage, which really has nothing to do with the concept of a group of things.

A better way to implement this would be to define a subclass of Collection, say a Gang, which is a kind of Collection but with the positional and movement aspects incorporated. This leaves the concept of a Collection unsullied, but still leaves us with the problem of how to keep the Actors positioned properly. But by calling this concept a Gang and thinking of it in that respect rather than as just a Collection, it occurs to us that gangs are often a collection of followers following a leader. So we add a leader property to the Gang class, which will be the object ID of the Actor which is to be the leader. Now moving the group around the screen is easy — we just move the leader and tell the followers (the elements of the Gang) to follow him:

Code:

(method (moveTo nX nY)
     (leader moveTo: nX nY)
     (elements eachElementDo: #setMotion: Follow leader)
)

We could even go on to further refine the Gang class by including code which handles a Gang without a leader by having the followers wander aimlessly about a point which is considered to be the position of the Gang.

The point here is that rather than mucking up the Collection class with a lot of irrelevant code, we created a subclass of it with the desired extra properties and methods. In doing so, we stopped thinking of it as just some sort of abstract collection and started thinking of it as a gang, inspiring the thought of adding a leader to the gang and opening the way to many possibilities.

DON'T THINK OF CODE — THINK OF CONCEPTS!

 

Notes

 

Table of Contents

 

< Previous: Table of Contents Next: RootObj Class >