Making some games to test the engines

Hi folks!

We are making three games to test the engines and look the pros and cons from the trenches.

With a lack of a better name: 

• Jumper: A casual ‘five minutes’ game to compete with others for a better score.
• Survivor: A resistance game to bear waves of enemies.
• Tank Army: A strategy game to make the better army and fight with others.

Behaviors, states and events

MindShake incorporates an easy way for defining event driven application logic. In this way the user defines a series of small objects to solve specific and concrete tasks, splitting the application logic into simpler parts to be implemented in response to certain events as 'enter new frame' or 'mouse click'. We will call these objects behaviors.

Whenever an event takes place, MindShake will be who calls to our objects, which avoid the user to worry about details beyond the logic of his application.

Furthermore, MindShake incorporates a state machine, which simplifies the creation of different stages in the application like: load, boot sequence, menu, game, credits, etc.. Allowing the user should not be complicated with these details.

The user then simply define the behaviors that should be executed in each state, and it will receive the events at the appropriate moment.

Behaviors
Unlike other kinds of MindShake’s classes, which are always created using factories, such as sprites, layers, images, etc, the user must define, instantiate, and destroy, their own kinds of behaviors. For it your behaviors must inherit from one of two basic kinds of behaviors that MindShake defines:

• CBehavior: Usually associated with logic.
• CSpriteBehavior: Associated with a sprite.

CMyBehavior class: public MindShake: CBehavior

CMySptBehavior class: public MindShake: CSpriteBehavior

 Once instantiated a behavior, this should be added to the system with CBehaviorManager class, if the class inherits CBehavior, or through CSprite class, if the class inherits CSpriteBehavior.

pBehaviorManager->AddBehavior(pMyBehavior);

pMySprite->AddBehavior(pSptBehavior);

Additionally, we can walk away from our behaviors, forgetting that we must destroy them, passing a second parameter to BehaviorManager when registering the class:

pBehaviorManager->AddBehavior(pMyBehavior, true);

pMySprite->AddBehavior(pSptBehavior, true);

Thus will be MindShake who will destroy the behaviors when we get out of the application.

CBehaviors 
These behaviors are usually associated with logic. They can be used to create new behaviors, control groups of sprites, states or parties to manage the program, and so on.

CSpriteBehaviors
These behaviors usually control a single character, or the sprites generated by this, such as bullets, aides, etc..

A sprite can have as many attached behaviors as the programmer wants, so the developer can simplify and distribute the logic associated with a sprite distributing its programming between different behaviors. For example, the user can define how the player can move through the world on one behavior, and use another behavior to handle the input.

States
As already mentioned, MindShake incorporates a simple state machine that allows users to define different stages in their implementation.

To do this the user simply has to create behaviors in a given state. Subsequently the user can jump between different states using the method GotoState(state) of the BehaviorManager class.

Once inside the behavior, the user can know both the current and previous state invoking the methods GetState  and GetLastState also of the BehaviorManager class.

Events
Each behavior may receive the following events:
• InitApp
• Begin
• EnterState
• EnterFrame
• ExitState
• End
• BeginPause
• Paused
• EndPause
• MouseEnter
• MouseWithin
• MouseLeave
• MouseDown
• MouseUp
• MouseMove

InitApp
This event is called only for the behaviors that are defined when the application runs initially, or for behaviors that are created just at this moment, in the event InitApp of a behavior that is already created at the beginning.
In any case, MindShake just calls the behaviors that are not associated with any state.

Begin
This event is called only once for each behavior.
All kinds of behaviors.
For the behaviors associated with a state, shall be called the first time you enter that state.

EnterState
This event is called when entering a state.
Behaviors associated with current state.
It’s called for all behaviors associated with the state that becomes active (current state).

EnterFrame
This event is called before rendering each frame.
All kinds of behaviors.
It’s called for the behaviors that are not associated with any state and for the behaviors associated with the current state.

ExitState
This event is called when leaving a state.
Behaviors associated with current state.
It’s called for the behaviors that are associated with the state that become inactive (previous state).
This event is called in reverse order of creation.

End
This event is called when the application exits or when calling RemoveBehavior or RemoveSpriteBehavior.
All kinds of behaviors.
When you exit the application, this event is called in reverse order of creation for all behaviors. Starting with the last defined state. This event is called first for CSpriteBehaviors associated with a state, then for CBehaviors associated with a state, finally is called for CSpriteBehaviors without state and then for CBehaviors without state.

BeginPause
This event is called when the program enter into pause mode. (IDevice::GetInstance()->Pause())
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

Paused
This event is called, every frame, while the program remains in pause mode. Note that in pause mode the system does not call EnterFrame.
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

EndPause
This event is called when the program exit from pause mode. (IDevice::GetInstance()->Pause())
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.
This event is called in reverse order of creation.

MouseEnter
This event is called when the mouse enters over the sprite.
Only SpriteBehaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

MouseWithin
This event is called when the mouse is within the sprite.
Only SpriteBehaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

MouseLeave
This event is called when the mouse leaves the sprite.
Only SpriteBehaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

MouseDown
This event is called when a mouse button is pressed.
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.
For SpriteBehaviors it’s only called when the mouse is within the sprite.

MouseUp
This event is called when a mouse button is released.
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.
For SpriteBehaviors it’s only called when the mouse is within the sprite.

MouseUpOutside
This event is called when a mouse button is pressed inside a sprite and then is released outside the sprite bounds.
Only SpriteBehaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.

MouseMove
This event is called when the mouse is pressed and moved.
All kinds of behaviors.
It’s called for the behaviors associated with the current state and the behaviors without state.
For SpriteBehaviors only it’s called while the mouse is pressed and moved inside the sprite bounds.

Improving internal features

We have been some time without writing news on the blog because we are working on internal parts of the libraries and increasing performance.

By now we are working on improve the behaviors engine, and testing all the libraries to increase the reliability and security, also we are working to add support for Android.

Visit to Lemon Team Headquarters

Last week we went to the Lemon Team headquarters.
Lemon Team is an independent game developer based in Alicante, Spain, focused on Mac and iPhone game development and porting. If you are looking for a partner to develop a PC, Mac or iPhone title, or you are interested in bringing a game to the Mac, then you should to contact them at http://www.lemonteam.com/

In our meeting we consolidated a contact that we had neglected over time, since we knew each other since university.

MindShake schema

The composition of this engine is focused on the ease of use. We had seen others 2D engines and we decided to design MindShake with all the features we think are essential.
In this way we decided to have one main object called "Device", this element can provide access to all managers of low level elements, so we have them organized and they can be quickly accessed.
The object "Device" can give us access to:

• Renderer (internal element, in charge of rendering)
• Window Manager (responsible of size and position of the visual window)
• Texture Manager (internal element to ease load and manage textures)
• Scene Manager (manager of all objects that will be shown and his containers, layers, sprites, texts...)
• Behavior Manager (element to control the behaviors added on our games)
• Camera Manager (manager of all the camera objects)
• Font Manager (manager of fonts, this fonts must be created with AngelCode Bitmat Font Generator and are loaded as textures)
• Kinematic Manager (manager of kinematics objects)

Some of these objects will never be used by the user, like the renderer, the window manager or the texture manager that are only necessary for set some options or get information from the system. But others will be intensely used, like the Scene Manager that defines all the elements present in the world, or the Behavior Manager that handles the behaviors of the diferent details of our world.

Embedded Tremor

Today we embedded a reduced subset of Tremor library, an optimized integer-only implementation of the OGG Vorbis decoder, thought for embedded devices.

Then, now we have our fourth optional library:

• With OGG Vorbis embedded.
• With Tremor embedded.
• Without OGG Vorbis nor Tremor embedded, that permits you to link with the original libraries or your own implementation.
• Other one without any OGG Vorbis support (small size).

This version takes only 97 KB in size.

Embedded OGG Vorbis

We are noticed that there are some people who are bothered with the fact of have to link with multiple libraries (libogg, libvorbis and libvorbisfile) only for have support for another audio format.

For this reason we made a reduced ogg vorbis library subset only for decode it. And then we included this code inside BrainWave. We said reduced because it is only 135 kb in size.

Note that the sizes of these libraries are (MinGW GCC 4.4.1):

• libogg_static: 15 KB
• libvorbis_static: 1313KB
• libvorbisfile_static: 28 KB

Total: 1356 KB

Due to the fact that there can be some people that maybe want to use these 3 libs for his own purposes, or because there will be some people that maybe don’t want ogg support at all, we made three separated libraries:

• One with OGG Vorbis embedded
• Other one without OGG Vorbis embedded that permits you to link with the original libraries.
• Other one without any OGG Vorbis support.

In this way, the BrainWave users can select the best choice for his app.