Adding Sprites to the Layer

The logical choice to organize sprites is to add it to your Game Layer. Now, you may also add your sprite at the Scene level. However, you might want to add other layers on the Scene layer, so it is better for you to separate all sprites into its own sprite layer.

This video shows you how to add your image sprites int a Sprite File. You then add all the sprite files into the layer. You can then view the sprites in the layer.

One note is that, you need to create a rather high resolution sprite with this method. This is because your sprite will have blurring effects when viewed in the scene if you have a low resolution sprite.

Check out this video for better understanding:

Adding Game Layer to Game Scene

Hi all

If you are familiar with game programming, it is normal to add a layer to the scene. The layer will be used to add objects/sprites, or just a background.

In TumeriQ, it is recommended to add layer on the scene. In this example, I showed 2 ways to add a background:

1. Add the background directly to the scene
2. Create a Layer, and add the background to the Layer. You then add the Layer to the Scene.

Check out the following video for better understanding :
 

Game Design Workshop : Now everyone can design a game

On 28 March 2015, 10 brave souls entered the StartupHub @ Putrajaya office at Menara PJH, Presint 2 to attend the Game Design Workshop delivered by Syamsul, a relatively unknown speaker from Nusantara Software. Some of them came as early as 9.30 am despite the event started at 10 am. Some came from far away state of Melaka where they have to drive a good 2 hours of the PLUS highway – plus tolls.

At about 10.15 am, StartupHub@ Putrajaya manager, Eddie, gave an opening speech to welcome everyone, and handed over the event to us . When we started the event, there was an uneasy, unsettling feeling. Everyone looked stiff, perhaps due to the weekend mood, or just that they were surrounded by strangers at early morning.

Early morning presentation

 We started the event by giving the preview of games, and have activities all the way until lunch. By lunch, we were all immersed into the energy of designing the game. Every participant was passionate about designing the best games. We were so into it until we delay our lunch by a few minutes. By lunch, everyone was having a good time – scouring the meals, and get to know each other. Those who brought their business cards, they traded cards with each other – networking time.

After lunch, we felt that the energy that we had previously has somewhat lost. In the midst of the odour of the chicken curry, the energy that we had in the morning was melting away and dissipating into thin air, quietly flowing out towards the closed door of our fantastically decorated office.

What was a very energetic group had became somewhat passive with diminishing passion. As we browse through the materials, we couldn’t help but thinking, why the lunch has reduced much of our energy?. Should the lunch’s job is to boost energy? Is it because the rice, chicken and vegetables ? Why?

Lunch set

Perhaps the lunch was heavy, but the chicken curry was too delicious to ignore we devoured them with much passion, just like we devoured all our spartan materials in the workshop.

Fortunately, the diminishing passion due to the post-lunch effect did not last long. The participants gained back their strength and soldiered even stronger through the workshop. The energy began roaring, and we were back in the full mood of designing games. By now, we have started designing our video games. We tested the games, and each of them take their task creatively. Everyone displayed an exceptional level of teamwork that we have almost entered a state of euphoria.

Indulging in activities 

By 4pm, we wanted to end the workshop. However, there were still many unsettling questions about many things on games. We’ve also showed the demo of some of our creations, especially our game platform TumeriQ, in the workshop. Many eager for more.

Things went on until 5pm where we have to call it a day. After bidding farewall and promise to keep in touch, we parted ways.

We hope the participants enjoy the workshop, just like we enjoy organizing it. Special thanks goes to StartupHub team for being awesome event organizer.

What did they say about the workshop:  

“Informative & Fun”

 “It is simple and easy to understand, balance practical & theories”

“It was a good experience. The presentation was good and easy to follow”

“ …. no bad stuff .. all good”

What you need to know about Game Design

Publishing games require us to master several disciplines such as programming, music, story-telling, etc. However, do you know that you don’t need to know everything to design your own game? Let’s try to demystify several things surrounding game making activities:

1. You don’t need to be a programmer

To create a game, you need to have a creative force. However, you don’t necessarily need to be the one who program it into your favorite platforms. You can hire programmers or just team up with friends who know programming to create your game.

2. You don’t need to be a graphics artist

Graphics artists learn various skills throughout their formal education to create illustrations for the games. To acquire the skills might take a long time. If you have a game idea, you don’t need to be a graphics artist. All you need to do is brainstorm with the graphics artist about various things that you have in mind such as characters, environment, etc. The graphics artist will produce it for you.

3. You don’t need to be a musician

Audio is important in the finishing of your game. However, you don’t need to be the one who create the final audio. You can team up with the real musicians to craft the music for the game. All you need to do is to collaborate with them to produce the audio before releasing to public. 

4. You need to be the game designer

It is easy to copy existing games and change the graphics and make it your own. However, over time, you need to acquire some specific skills to create your own game title so that people remember playing it, and of course, spending money on it. The moment they play the games, they know that it is your creation. This is what we are striving for as game designers. And this is all what you need to be.

If you want to know more about Game Design, please register to the workshop:

http://www.eventbrite.com/e/game-design-workshop-for-beginners-putrajaya-tickets-15971653646

Let’s be creative today!

Getting started with TQ Community version

Grab TQ Community version here . Once downloaded, include in your project and compile. If you have issues with Box2D and kazmath libraries, make sure that you include the following in your project’s Build Setting  -> Search Path -> Header Search Path :

<path to your project/TumeriQ/libs

and set it to “recursive”.

And you’re all set to build your next great game app!

 

TQ+ userguide: Built-in Game Play Management

Most game will handling and manipulating one or a few of the following game play aspects in order to make the game interesting:
1. Score
2. Lives
3. Game state
4. Time

Games are interesting when you are accumulating scores while protecting lives and chasing against time.

TumeriQ makes it easy to manage these game play aspects by encapsulating them into TQGameplayController.

Score and Lives

TQGameplayController allows you to manipulate score and lives either by manually modifying them:

// gameplay is an instance of TQGameplayController
gameplay.score += 500;
gameplay.lives += 1;

Or by utilizing gameplay events. TQGameplayController allows you to define rules that are triggered when certain gameplay events occur on specific object and will modify score and lives accordingly. Example below is a rule that add 500 score and 1 life when any object of class “Bonus” and subclass “Little star” is hit:

[gameplay addRuleWithName:@"Get bonus little star"
forEvent:@"EVT_OBJ_HIT"
andObjClass:@"Bonus"
andObjSubclass:@"Little star"
andDeltaScore:500
andDeltaLives:1
withPriority:0];

A few rules can be added to and will be kept by a TQGameplayController instance until they are being cleared by calling [gameplay removeAllRules].

To actually trigger the rules, you just have to call:

[gameplay triggerGameplayEvent:@"EVT_OBJ_HIT" onObject:object];

Where object is an instance of a class that conforms to protocolby implementing two methods “objClass” and “objSubclass” which return NSString. TQGameplayController will find the gameplay rule with matching gameplayEvent, objClass and objSubclass and modify the current score and lives based on the rule. By using this mechanism, you don’t have to perform the checking of the object and event manually. Just pass these two parameters to this method and TQGameplayController will take care of the score and lives based on the rules you have defined earlier.

Manipulating score and lives is not very useful if you don’t display the changed score and lives to the player. Therefore, TQGameplayController supports having a delegate that will be informed of the changes. The delegate needs to conform to protocoland implements the following methods:

- (void)onGameScoreChanged:(TQGameplayController*)gameplay withScore:(int)score {
// display to player
}

- (void)onGameLivesChanged:(TQGameplayController*)gameplay withLives:(int)lives {
// display to player
}

Furthermore, game state automatically changed to GAME_NOLIFE when lives become 0. Head to the next section to read about game state.

Game State

During the game play of a game, there will be many states such as “playing”, “paused”, “victory”, “game over” etc. Depending on the states, some elements of the game will change, for example during state “paused”, some or all of the animations, touch inputs, sounds and background music that are currently playing or in action will be suspended, and later resumed when the state changes back to “playing”. Rather than creating a separate ivar to keep track of the state, TQGameplayController is already built-in with such ivar.

gameplay.state = GAME_PAUSED;

The following are the available game states and descriptions:

GAME_INIT
The initial game state. Also the state that the gameplay will be in when [gameplay reset] is called.

GAME_PLAYING
The state of playing. The game logic should always use this condition before accepting user inputs. From GAME_INIT state, you can call [gameplay start] to change to this state.

GAME_PAUSED
The paused state. You can use [gameplay pause:YES] to change to this state, and [gamepley pause:NO] to change back to GAME_PLAYING.

GAME_TIMEUP
Will be automatically set when count down becomes 0. More on game play time aspect in the next section.

GAME_VICTORY
To be used by game logic when the player won the game. You can call [gameplay triggerVictory] to change to this state.

GAME_OVER
To be used by game logic when the player lost the game. You can call [gameplay triggerGameOver] to change to this state.

GAME_NOLIFE
Will be automatically set when lives becomes 0.

GAME_QUIT
To be used by game logic when the player voluntarily quit the game. You can call [gameplay quit] to change to this state.

GAME_EDITING
To be used by game logic when the player enters edit mode.

GAME_LOADING
To be used by game logic to indicate that the game is in loading mode.

GAME_PLAYING2
A custom state of playing. Use this state to indicate special mode of playing if your game play has different play mode (e.g. the battle mode in an RPG game).

GAME_PLAYING3
A custom state of playing. Use this state to indicate special mode of playing if your game play has different play mode (e.g. the battle mode in an RPG game).

GAME_PLAYING4
A custom state of playing. Use this state to indicate special mode of playing if your game play has different play mode (e.g. the battle mode in an RPG game).

GAME_PLAYING5
A custom state of playing. Use this state to indicate special mode of playing if your game play has different play mode (e.g. the battle mode in an RPG game).

GAME_STATE1
A custom state to be freely used by your game logic.

GAME_STATE2
A custom state to be freely used by your game logic.

GAME_STATE3
A custom state to be freely used by your game logic.

GAME_STATE4
A custom state to be freely used by your game logic.

GAME_STATE5
A custom state to be freely used by your game logic.

The delegate of a TQGameplayController will be informed on game state change through the delegate method:

- (void)onGameStateChanged:(TQGameplayController*)gameplay fromState:(TQGameplayState)old_state toState:(TQGameplayState)new_state {
// do something when the state changes to a certain state
}

Time

TQGameplayController automatically keeps track of time for you as long as the game state is GAME_PLAYING or its variants GAME_PLAYING2, GAME_PLAYING3, GAME_PLAYING4 and GAME_PLAYING5.

TQ+ Userguide: GameFlow

The sequence to create a game with TQ+ goes like this:

First, when the AppDelegate starts, it will kick-off GameFlow. GameFlow is responsible to control the sequence of the the Scene.

A scene is implemented using a Layer class, often starts with TQMultiTouchLayer.

To get an idea to use GameFlow, let’s go through the game starting from it starts up at AppDelegate class implementation :

#import "AppDelegate.h"
#import "MyGameFlow.h"

@implementation AppDelegate

- (void)start {
	// Calls gameFlow singleton class and start
    [[MyGameFlow instance] start];
}

In our implementation class of the GameFlow class, we can simply call the first scene we want to show (usually a Menu scene).

Inside MyGameFlow.h, we define the class:

// defines your interface / class derive from TQGameFlow 
@interface MyGameFlow : TQGameFlow {
    ....
}

Inside the implementation (MyGameFlow.mm), we call a scene to start:

- (void)start {
    [self startScene:[MyMenuScene scene]];
}

You can define MyMenuScene as a TQMultiTouchLayer and add some sprites on top of the Layer.