Game Objects

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Class design.png This article covers outdated class design information!

Class design articles are stored at the wiki for legacy reasons. Most of them are outdated and they will not be updated in the future. Class design should rather be embedded into actual Code proposals.


UML Diagram



The layers here are just a means to visualize the hierarchy of the game objects in PARPG.

Base Objects Layer

Classes belonging to this layer are the basic ones. They are used to compose objects, modeling them after their real world equivalents. The Special Aggregation box in the UML diagram shows - as the name suggests - a special aggregation. Inventory belongs in the Composed layer as well as in the Base layer. It is a base class in the sense that is used to model objects, but it is composed differently. It is an aggregation of containers, and containers are an aggregation of carryable objects. Therefore it is separated visually.

Composed Objects Layer

To this layer belong classes that have been composed out of base objects to generate stereotypes. They are not concrete classes themselves, but they are logical compositions. In this case a Weapon is a carryable object. (Before it was deriving from a class called MapItem, but this one was merged with the GameObject base class. So right now the weapon is only composed out of one base class.) It is only advisable to create this kind of objects for commonly used stereotypes. If you are going to use a class on this layer only in one concrete class then you are better off with composing the concrete class directly.

Concrete Objects Layer

Here the concrete classes are located - the classes that will actually be instantiated. They have to be derived from the GameObject class for two reasons:

  • To make them new style objects. (Python stuff)
  • There are common attributes shared by all objects in PARPG, like the name of an object or its identifier.

Creation of Base Objects

The composition of a base object is very straightforward. Imagine you want to create a door. That door needs to be opened, so you need a base class for this. Openable. Base classes are required to have a boolean attribute in this style: "isOpenable" or "hasInventory". They are used to determine whether an object has those features or not. The Openable class would then, quite naturally, have two functions, open() and close(), and the current state would be represented by an boolean like "isOpened". (Maybe a clearer differentiation from "isOpenable" is necessary.) And there you go, you created your first base class.

Now if you want your Door to be lockable you have to create another base class for this. In this case it makes sense to derive it from the Openable class, because you can't just open() a Door that is locked. You would have to overwrite the open() function to introduce a check for the lock. Additionally you need to extend your class by adding functions like lock(), unlock() and if you like pick(). (Don't forget about the "isLockable" boolean parameter!)


See List of Game Objects for a (not yet) comprehensive list of game objects.

Personal tools