Our first game is out!

(copied from Lucera's blog)

We are very happy to announce that finally our first game is out!

Its name is LittleGame. It's an educational-entertaiment game for kids. It contains four games and it's cheap, please buy it!

Here is the app description:

The game is vital in many aspects of social, emotional and intellectual development of children and has a significant impact on academic learning. It is one of the most powerful vehicles that children have to good try and learn new skills, concepts and experiences. The game can help children develop the knowledge they need to connect meaningfully with the challenges they discover in the school.

The children's game is an activity that can be approached from many points of view, one of them is education.

LittleGame incorporates four different games designed to develop different abilities of children:

- Pairs:
  - Develop the capacity of attention.
  - Facilitate a strategy of memory through image association.
  - Develop the skills of classification, recognition and assimilation of concepts.
  - Develop the capacity of short-term memory and to form partnerships and relationships.

- Silhouettes:
  - Ability to object recognition.
  - Discrimination of shapes, colors, sizes and positions.
  - Ability to play models.
  - Analysis, hypothesis, comparison, trial and error.

- Mazes:
  - Develop the skills of children and their powers of observation.
  - Improves concentration.
  - Develops creative thinking and constructive.
  - Increases dexterity.
  - Develops sensitivity, imagination and creativity.
  - Improving the development of perception.

- Sudokus:
  - Stimulates and enhances their math skills, logic and critical thinking.
  - Excellent learning tool that helps strengthen the skills of reasoning and calculation.

Alea jacta est

(copied from lucera blog)

Finally we finish our first game in time and submit it to iTunes Connect. Now we can only wait the validation process from Apple.

Maybe now is time to end the port of our libraries to Android and submit it to Android Market.

Unfortunately, as we do not have an operative web, we don't have an easy way to distribute our application for Windows, Linux or MacOSX. Although in this case would have to redo the graphics to higher resolution.

In any case, our Christmas holidays begin!

Merry Christmas to all!

We are back

(copied from lucera blog)

Hi!

After theese days trapped in bureaucratic issues, finally we are back to work.
We want to finish our last game and we want to publish it before Christmas. We are conscious that there is a lot of work ahead to be able to finish the game but we think it will be posible.

Wish us luck!

Trapped in the bureaucratic spiral

(copied from lucera blog)

The last week there have been no news because we were involved in bureaucratic issues and we are attending an intensive course in management and business administration that will finalize the next week.

This has prevented us from making great advances in recent days, despite of that, we have been making some small internal changes and we have been testing some of our latest features added.

Improved layer system

(copied from lucera blog)

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

(copied from lucera blog)

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

(copied from lucera blog)

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
5. ...

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

(copied from lucera blog)

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

(copied from lucera blog)

MindShakes provides an easy way to communicate between different behaviors through messages.

When you are splitting the logic between different behaviors, you don't need to worry about how these behaviors will handle their visibility. If you need that several behaviors communicate, you can use the IBC system.

All behaviors have a virtual method to be used to receive messages from the behavior manager. The name of this method is "Notification". A behavior only can receive notifications for those messages for which it has been registered. To do that you must use the method "RegisterNotification", from the behavior manager, where you must specify the notification id and the behavior instance that will receive the notification. Then, when the method "SendNotification", from the behavior manager, will be invoked, the "Notification" method, for each behavior that has been subscribed to this message id, will be invoked.

Notice that you must overwrite the "Notification" method on your behavior, if you want to handle any notification.

Making some games to test the engines

(copied from lucera blog)

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

(copied from lucera blog) 


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.

Unify blogs

As you know we started with 3 blogs, one per each engine (MindShake 2D engine and BrainWave sound engine) and one for the project. We have realized that it is not comfortable for the users to see our progresses. For this reason we have decided to unify all the blogs.

All the next post will be on lucera-project.blogspot.com.

See you there!!

Unify blogs

As you know we started with 3 blogs one per each engine (MindShake, 2D engine  and BrainWave sound engine) and one for the proyect. Now we realized that it's is easy more to read and to manage to have only one.

Next post will be on lucera-project.blogspot.com

See you there!!

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.

Layer & Camera System

MindShake includes support to add layers and cameras, with no limits, you can create as many objects as you want.
MindShake includes managers for layers and cameras who handle this data, so you can easily add new objects. Later to easy access to these objects, you can store the reference or give them a name, so you can ask the managers to recover one object with that name.

By default all layers created are configured to adjust to camera renders. If the user want to have a serie of static sprites on the screen, the common way is to put them on a layer that is ignored by camera transformations.

To create a usable sprite layer you need one instance of the scene manager and then invoke the method AddSpriteLayer.
That is done in this way:

//Obtain an instance of scene manager
pSceneManager = IDevice::GetInstance()->GetSceneManager();

//Add and modify a new layer
pLayer = pSceneManager->AddSpriteLayer();
pLayer->EnableCameraTransformations(false);

With this example you see how to create a new sprite layer and modify it to ignore the cameras, so any sprite created into this layer will be shown relative to the upper left corner of the screen.

With the layer created you can now add one or more cameras to view diferent parts of our world.
When we add a new camera it is important to tell it the size and position of the viewport (the region where the camera content will be seen) and the dimensions of the world (the region where this camera can move).
Now you can see one example of scroll.

//Obtain an instance of camera manager
pCameraManager = IDevice::GetInstance()->GetCameraManager();
    
//Add and modify a new camera
pCamera = pCameraManager->AddCamera2D();
pCamera->SetViewPort(0, 0, 320, 240);
pCamera->SetWorld(0, 0, 640, 480);

If our window have a 320x240 size, with this example you will see a scroll effect when move the camera around the world, because it have double size than camera viewport.

It is easy to create more cameras, you only meed to set the viewports in order to view them correctly, for example you can split the screen with three cameras, two of them at the top and one at the bottom.

//Add and modify a new camera (top left)
pCameraTopLeft = pCameraManager->AddCamera2D();
pCameraTopLeft->SetViewPort(0, 0, 160, 120);
pCameraTopLeft->SetWorld(0, 0, 640, 480);

//Add and modify a new camera (top right)
pCameraTopRight = pCameraManager->AddCamera2D();
pCameraTopRight->SetViewPort(160, 0, 160, 120);
pCameraTopRight->SetWorld(0, 0, 640, 480);

//Add and modify a new camera (bottom)
pCameraBottom = pCameraManager->AddCamera2D();
pCameraBottom->SetViewPort(0, 120, 320, 120);
pCameraBottom->SetWorld(0, 0, 640, 480);

Now you can move the cameras with the SetPosition method and every viewport will automatically show the camera content.

Behaviors

MindShake includes a behavior engine that allows the users to easily create custom 'event driven' logic, per full game or per sprite, that can be reused in various games.

In this way the user can split logic into several behaviors, defining initialization code (BeginSprite), defining simple actions for events like mouse clicks, per frame process 'EnterFrame' for single sprite or whole game, etc. Furthermore, the user can reuse the same behavior into multiple sprites.

For example, in a platform game, the user can define a behavior to control where a sprite can walk, fall down in case of having no ground under their feet, rising stairs, etc. Then the user can attach this behavior to all the sprites that are able to walk on the platforms.

MindShake layer system

MindShake has a great layer system. The user can add and shuffle Sprite Layers, Text Layers, Tile Layers and in a future version 3D Layers (like new StarCraft II from blizzard).


The user can apply some transformations directly over the layer or over its content.

Bitmap Font Generator

Bitmap Font Generator will allow you to generate bitmap fonts from TrueType fonts. The application generates both image files and character descriptions that can be read by a game for easy rendering of fonts.

MindShake can load bitmap fonts generated with this tool.

Thanks AngelCode!

What is MindShake?

MindShake is a lightweight multiplattform 2.5D game engine.
 
In it's first alpha version it will run on several operating systems including Windows 95, 98, NT, 2000, XP, Vista, Linux, some others *nix, MacOS X and iPhoneOS and it will work on several compilers including GNU GCC 3.x - 4.4 and Microsoft Visual C/C++ 6.0 - 2008.

MindShake joins Lucera-Project

MindShake is part of Lucera-Project