Engine's Components

I'll give a basic description of the job role of each engine component. Remember this is just a description of the components and what they do. In order to see the full picture you will have to read the code documentation.

Core components

Game Class. This is your main game class. When you write your game you will have to inherit from this class and implement several important functions in your derived class. These functions are essential to your game progression. You'll be able to load components that your game needs before being able to play it, and you can pause it from here and resume the execution.

Scene Class. Normally a game is composed of several scenes or levels. When you want to write a new scene in your game you will have to inherit from this class. You'll be able to load components that your scene needs before being able to play the scene, and pause and resume it.

World Class. The world class holds the most important features of the scene's world, like gravity. Your world object holds the entities of your scene, say enemies or even the player himself. You have to inherit this object to create a world for each scene. With this concept you can create multiple worlds for the same scene, so you can implement fancy concepts and different realities by changing the world of the scene, possibly by using a different gravity or even different objects to interact with.

Entity Class. The base class for most entities that you will build in your game. It carries the most essential information the engine needs to keep in hand: position, dimensions, current collider and the current bitmap. This class has several flags that you can enable or disable to help you debug through the game, or show and hide entities. It's important to derive from this class when you intend to create an object that is going to be shown on screen. Entity has a lot of the important operations defined for you, like render and update.

Physical Entity. A special version of Entity. It carries the information required by every entity that would move on screen, hence the name. This normally stores information like mass, speed and acceleration. If you intend to create an entity with the ability to move you will have to inherit from this class. You have a function responsible for updating the physics of the game, aside from the update function itself that you can use for animation, for example.

Collider. An interface that you would normally implement when you want to use colliders in collision detection. There is a class I implemented from this interface named RectangleCollider, since I needed to do collision detection among rectangles in a game - because if you think about it, rectangle-to-rectangle collision detection is the most common type.

SoundManager. Responsible for playing, pausing and stopping sounds. This area was one of the most frustrating parts of Android development for me. I don't think the guys at Google did a great job with the sound modules, because while I was programming and testing this I saw a lot of awkward errors that were out of my hands to fix, so I did a few tricks to get the sound working. One trivial thing to note is that you have to load the audio files before use, and my advice is to load them a long time before you use them. Machines that are going to play them have different processors and may take longer to decompress some audio streams than others.

SpriteAnimation. The base class for most of your frame-based animations. You will have to derive from it in order to make a new animation. You get to configure the speed of the animation and some other options.

Timer. Probably one of the most important parts of the engine. I'm sure that you will use it a lot in order to achieve timely-set events like enemy instantiation and the like. It's very basic but it works fine.

GUI components

Text Object. One of the entities used to display text on screen. It's a good opportunity to use this class to display debug messages that change rapidly, like frames per second. You will not need to inherit from this class unless you're looking to do something quite fancy.

Button. If you want to put buttons in your game, for a simple GUI task or for use in the game itself, you can use this class. You will need to inherit from it to create custom buttons with specific behavior. At the time of this writing there are three events supported:

• Button Down, when a button is clicked.
• Button Up, when you raise your finger after clicking the button.
• Button Hold, when you keep holding a button for a certain duration.

The GUI components work fine, but you can still use Android's GUI classes.

Input components

Event Packet. An event packet is a concept I really liked from my experience with SDL. For each event that occurs the engine captures it and adds it to a special queue made just for events. Then you as a programmer can extract events from the queue and handle them the way you want. This class normally holds the important information of a single event, like touch events and key events, which are the common ones on mobile phones.

EventQueue. A special type of queue that holds the events initiated by the user. For the time being the engine supplies you with a single event in each frame, so at best when your game runs at 60fps your game will handle 60 events per second, which is pretty reasonable.

Extra components

ViewDimensions. Only useful if you're trying to get the dimensions of your screen, in case you need to know the resolution of the device the game is being run on.

FPSCounter. Displays the number of frames per second. It was meant to serve as a debug class and an indicator of the performance of the game. At the time of this writing I can tell you that this class may not function properly all the time - I need to do some investigation myself.