Platformer Engine: Inside + Mini Update

Been sometimes since I last wrote here. Been kinda busy, especially with my new computer, which needs a lot of love to be properly used ^^

Well, what about my Platformer Engine? Like I said, I’m kinda busy, so there isn’t much of an update to be put here. But it is wrong to say that I haven’t done anything, since actually, a lot has been changed inside the engine. You see, since I was focusing on the actor, my code has been focused on Class Actor as well, making it more “Procedural” and less “Object Oriented”. So I decided I need to restructure it before I add more feature, and here we are.  Anyway, I’ve been showing some screenshots of the engine before, so this time, some diagram describing what restructure I have made should suffice.

Classes in Platformer Engine

First off, classes. This hierarchy here exploits the inheritance feature C++ give, so we can separate the much more generic code, like position and velocity to the parent class (Entity here in my engine)  and the specific code like Artificial Intelligence and Input Processing to the child class. This would helps us in focusing a specific task to a specific class, so we don’t need to worry about changing other part of the engine and ruining everything. At first this might sound tedious, but as the program grows, it will help a lot in reducing the complexity of your codes. And besides, it looks cool ^^

Anyway, other than this classes, there are also other classes, one example is Sprite class, which is a member of Class Entity (which makes it also a member of all Entity child classes) that handles image and animation. Another one is World class, a class that handles interaction between objects of different classes (say, like handling how a bullet damage an enemy) and Map class, a class made for handling map and tiles.

Seems pretty neat, huh? But all convenience comes with a price. Even though separating codes into classes helps us in solving problem, another problem rises. It is how to process interactions between those different classes, especially when they are blind to each other. It is much like building a computer, even though we have several awesome component, without any way to make them work together, they are useless. So, if a computer uses a motherboard to connect different components, I use World Class to handle classes interaction.

This diagram shows the engine main process, and how it is separated to different classes.

A detailed Input > Process > Output diagram

As you can see, there are 2 main parts here, the Game Engine, and the World Class. This is how I apply the Input > Process > Output formula to the engine, where Game Engine handles the input and output part, while World Class handle the processing part. So, basically, Game Engine is the outer layer where the human player interacts with game, while World Class is the game world, where everything in-game happens and processed.

Let’s take a closer look at World Class, code-wise, we can see that it is divided into two, the member part, and the procedure part. Objects (like enemies, actor, pickups) are members of the world class, so the part that process the members are referred as the member part, while the procedure part refer to the procedures used to handle interaction between the members. You can see that there’s a lot of transitioning between classes, from Objects Class to World Class, etc. Many of these transition used pointer, like collision checking used pointer to access an entity rectangle, but some also used public access procedure, like projectile class used a specific read-only procedure to access character’s private data.

Now, an example of how all this process worked. First of all, we’re checking for player input, say, the player gives a “go to the right” command to the game character. This input is then transferred to the Actor Class, which must process and validate the input given. If the input is valid, it is then translated into a State (I’ll describe this “State” thing some other time, since it is useful for a lot of things, so I might expand it). Then the World Class take over, it will start processing each object, like Actor object, Enemy objects (processing it’s AI),  projectile objects, etc. These processes actually take place internally within each class, because it only needs to handle itself. Then, after each object has been processed, World Class will proceed with handling interactions between objects, like projectile hitting an enemy, the actor picks up a power up, and also collision checking. After all the processes are done, each object updates their sprite class to match their actual data.  And then, the Game Engine takes over again, taking the updated sprite data and displaying it to the screen.

Whew, that was some long description. No wonders, I spent like, 3-4 days to restructure the program, encountering some difficulties in translating from procedural paradigm to object-oriented. So, it is best if you plan ahead and implement classes and the like as early as possible, because restructuring a program after it has grown complex is much more difficult.

For the closing, how about a teaser screenshot:

The X Buster (Not charge-able though)

Yeah, I’ve been working on the shooting system. As of now, I have the basic done, but I need to expand it for other stances, like shooting during jumping, etc. And I also need an enemy class to test the damaging system @.@

So, my to-do list would be:

• Multiple shooting stance (climbing, jumping. etc)
• Optimizing tile collision system (kinda buggy now)
• Adding enemies
• Adding projectile damaging system
• Adding scrolling system to the map editor

There’s only a week of holiday left, how far I can go I wonder…