SpaceShooter (name pending) View Screenshots The real purpose of this project was to start applying polymorphism, inheritance and encapsulation in my class structure. If done correctly, in the end I could have an engine which has functionality portable across my future games. I’ve structured my engine as such: The Unit class represents nearly all objects which are drawn to screen. These units all share many common attributes, such as their x and y positions, the width, height and directory of the image which they are drawn from, as well as common functions like draw() and kill(). Some of the Unit subclasses, for example, are the Ship, Projectile, and Item drops. Of these subclasses, though, the only one which has any further complexity is the Ship class. Since the game will allow for the player ship to be edited part by part, the Ship class itself has to be made up of separate parts. This is where the structure begins to form some kind of a containment hierarchy. What I have is a ShipPart class whose subclasses are each of the types of parts available. Now any given Ship will contain pointers to ShipPart objects, which are either null or point to an actual instance, depending on the customization of the Ship itself by the user. But this only really allows for the adding and displaying of the parts; what about their functionality? Originally, the Ship was one class which did not contain ShipParts and thus had full control over all its “ship functions “, such as moving, firing, etc. Now, instead, each ShipPart that a Ship contains is given control over its own function. That is to say that the main body of the ship will control movement, while the weapon will control the firing. In order to do this, I have what I call Behaviour Modules. Taking one step further into this containment hierarchy, each ShipPart will have pointers to the type of behaviour module it controls. Each Module itself has sub-modules, if you will, which specify the sub-type of that module. So, as an example, the MovementModule defines a way that the Ship will move, and the subclasses of it are Linear, Stationary, UserInput, etc. Each ShipPart will then be constructed with the appropriate subtype of each Module. Finally, summing all of this together, what we have is a Unit class which is broken up into several types of Units drawn to screen. The Ship unit is made of several parts, and each of these parts contains control over some type of the Ship’s behaviour. This simplifies the task of always having a properly functioning player Ship in terms of coding, since attempting to fire will not work unless the Ship has a weapon, and if it does, the way it fires is completely handled by the weapon itself, and leaves little to the Ship. The final setup looks like so: This is essentially the engine structure that I am aiming to achieve. Of course, a lot of this is still theoretical, and has yet to be applied and tested, so it may change. Nevertheless, I’m sure that I will learn a lot from it! Back