Noticias

Nuevas versiones de nuestros juegos

Durante este tiempo hemos estado añadiendo muchas mejoras a nuestro motor de videojuegos y hemos querido crear nuevas versiones de todos nuestros juegos para que podáis disfrutar de ellas.
Algunas de estas mejoras son:
  • Mejoras y modernización del sistema de Render
  • Mejoras en el sistema de Texturas
  • Mejoras en todos los Window Managers (sobretodo en el de iOS)
  • Mejoras en la integración con iOS
  • Mejoras en el controlador de Touches
  • Mejoras en nuestra clase principal del motor de videojuegos (Device)
  • Mejoras en nuestra librería de carga de imágenes
  • Mejoras en nuestra librería de reproducción de audio (BrainWave)
  • Mejoras en todas nuestras entidades (Sprites, Meshes y Texts)
  • Mejoras en el sistema de materiales
  • Mejoras en nuestro gestor de escenas (SceneManager)
  • Mejoras en nuestro sistema de licencias
  • Mejoras en nuestra librería matemática
  • Mejoras en nuestro sistema de colisiones
  • Mejoras en el render de texto
En resumen, ahora nuestro motor de videojuegos es aún más sencillo de utilizar, más eficiente y se ve mejor.
Os dejamos algunas muestras para que podáis apreciar los cambios más evidentes (usando exactamente las mismas texturas):

(Pulsa sobre las imágenes para poder apreciar las diferencias)
Ahora sólo queda que Apple nos apruebe las nuevas versiones.
¡Que las disfrutéis!

CCustomMesh

Hemos añadido un nuevo objeto a CObjectLayer, se trata de una malla genérica. Por lo que, ahora se pueden combinar sprites, textos y mallas genéricas en una misma capa.

Además, una malla puede estar compuesta por submallas, pudiendo asignar diferentes formas de renderizado a cada submalla: Points, Lines, LineStrip, LineLoop, Triangles, TriangleStrip y TriangleFan.

Estas mallas son totalmente editables, pudiendo añadir y modificar en cualquier momento: VertexPosition, VertexColor, VertexTextureCoords, VertexNormal. Por último, decir que el usuario puede añadir VertexIndex si la malla no es lineal.

Como siempre será la propia clase la que se encargue de hacer el trabajo difícil.

Por lo demás, se comportará como un sprite normal y corriente.

Improved layer system

MindShake has improved its layer system.

Until now the layers were little else that an object container, but now you can: 

  • Set the layer position, affecting all the objects inside.
  • Modify layer render order.
  • Scale independently each layer, horizontaly or vertically.
  • Set its pivot, to move each layer snugly and make nice transitions.
  • Modify the layer alpha channel or colorize (tint) it, to make some cool effects.

And, of course, you can still enable camera transformation to leave the system to adjust the layers relative position and scale to do automatic parallax scrolling.

All these changes affect the contents of the layer and you can make some effects more easilly now.

Unified Layers

At beginning we mistakenly thought that was better to separate objects per kind because we thought that this way would be simpler for the users and we wanted to promote the use of layers because we think that is is a powerfull feature.

But now we think that is better, and easiest, allow the user decide how he/she wants to distribute the objects across layers.
 
In this way we unified SpriteLayer, TextLayer and 3DModelLayer (not available) into ObjectLayer. Thus, the only different layer at this point is TileLayer that is in fact wholly different from other layers.

Notes about new event StateChange

Note that if you reach a state for the first time the order of the events will be:

  1. ExitState (last state)
  2. StateChange
  3. Begin (for which behaviors associated with current state that have not been yet initialized)
  4. EnterState

For this reason we are able to make some configuration changes in this event, because it will be before than Begin

New event for behaviors

We added a new event ‘StateChange’ to allow behaviors to detect when the state will be changed. This event will be sent after ‘ExitState’ and before ‘EnterState’ to all kind of behaviors, with & without state.

Inside this event you can check the prior state and the current state, using behavior manager, to make per state changes or configuration.

IBC: Inter Behavior Communication

MindShakes proporciona una forma fácil de comunicación entre los diferentes comportamientos a través de mensajes.

Cuando se va a dividir la lógica entre los comportamientos diferentes, no tiene que preocuparse acerca de cómo estos comportamientos se encargará de su visibilidad. Si necesita que varios comportamientos comunicarse, puede utilizar el sistema IBC.

Todos los comportamientos tienen un método virtual que se utilizará para recibir mensajes del administrador de la conducta. El nombre de este método es “Notificación”. Un comportamiento sólo puede recibir notificaciones de los mensajes para los que ha sido registrada. Para ello debe utilizar el método “RegisterNotification”, desde el administrador de la conducta, donde se debe especificar el ID de la notificación y el comportamiento de la instancia que va a recibir la notificación. Luego, cuando el método “SendNotification”, desde el administrador de la conducta, se invoca la “Notificación” método, para cada comportamiento que se ha suscrito a este mensaje de identificación, será invocado.

Tenga en cuenta que debe sobrescribir la “Notificación” método en su conducta, si usted quiere manejar cualquier notificación.

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.