Thursday, February 25, 2010

Conditional Commands for Rusher Game Framework

I showed one of my classmates the Command Utility for Rusher Game Framework. He gave me a quick thought about conditional commands, which execute different commands depending of different conditions. I thought the idea was great, so when I turned on my laptop I directly rushed into creating conditional commands for Rusher.

Below are the conditional commands that are now available in Rusher, which is now version 0.5 Alpha.

If Command

The If command executes a "true subcommand" if the return value of the test function is true, otherwise the alternative "false subcommand" is executed. Additional parameters for the test function can be passed as an array.

While Command

The While command repeatedly executes a subcommand until the test function returns false.

DoWhile Command

Pretty much like the While command, the DoWhile command repeatedly executes a subcommand until the test function returns false, except that for the first time the subcommand is always executed regardless of the test function.

For Command

The For command is consisted of two subcommands: the "initCommand" is executed first, then the "loopCommand" is executed repeatedly until the test function returns false.

Switch Command

The Switch command contains a index function, which returns an integer, and an array of subcommands. It executes the subcommand in the array corresponding to the index returned by the index function.

Repeat Command

The Repeat command repeatedly executes a subcommand for a specified number of times. This command basically does not count as a conditional command, but it certainly is equally useful.

Tuesday, February 23, 2010

Scene Manager for Rusher Game Framework

The scene manager for Rusher Game Framework is now complete. It makes use of Rusher's Command Utility to achieve scene transitions, i.e. intro and outro.

One engine core contains one scene manager, which is accessed from the Engine.sceneManager property. The SceneManager.setScene() method sets the current scene for the engine core. The scene transition is handled by the Scene.introCommand and Scene.outroCommand properties. When the engine core is switching from scene A to scene B, the outro command of scene A is executed, the intro command of scene B is executed, and then finally the scene transition is complete. This scene transition command structure was inspired by Progression Framework.

Here are some code snippets for the scene transition. You can view the final result here. Click the black square and watch the scene manager do its work.

The document class is quite simple. It starts up the engine core and sets the scene to a HomeScene object.

And below is the code for the HomeScene class. It extends the Scene class and assigns two command objects to the introCommand and outroCommand properties. The _block property simply holds a reference to a Sprite with a square appearance.

The intro command makes the block fade in from zero alpha and a random position to another random position, while the outro command fades out the block to zero alpha and another random position.

The AddChild command adds the block to the container sprite. The TweenNanoFrom command is making use of the from() method of the TweenNano class from GreenSock Tweening Platform. The Trace, SetProperties, AddEventListener, RemoveEventListener commands do what their name suggest: tracing messages, setting properties, adding event listeners, and removing event listeners, respectively.

When the block is clicked, the scene tells the SceneManager to switch to another scene, in this case, still another HomeScene instance.

There are more commands integrated with GreenSock Tweening Platform not shown in this example: TweenLiteFrom, TweenLiteTo, TweenMaxFrom, and TweenMaxTo. I believe their names tell you everything about what they do.

I'm quite happy with how the Command Utility turned out. Managing how the program flow by using parallel and serial commands is very easy, and, more importantly, it is achieved with simple, clean, and readily maintainable code.

Sunday, February 21, 2010

Command Utility for Rusher Game Framework

I've added a Command Utility to Rusher Game Framework. Each engine core now has a reference to a CommandManager object; this object allows you to execute commands, be it single commands or composite commands.

There are two types of composite commands: ParallelCommand and SerialCommand. The parallel command executes all its subcommands simultaneously, while the serial command executes its subcommands sequentially. Also, each command has a delay property (the time a command "waits" before execution), which you may make use of to have advanced control over the command execution timing.

Here are some code snippets for Rusher's Command Utility.

This TraceCommand class is a very simple command consisted of a delay time and a trace message. Note that the execute() method is where all your command goes, and the complete() method should be called when the command is finished.

Here's the document class. The two commands "ps" and "sp" are a parallel command with a serial subcommand and a serial command with a parallel subcommand, respectively. The first constructor parameter of the parallel and serial commands is the delay time, and the subsequent parameters are subcommands.

This shall trace out "ps0", "ps1", "ps2", "ps3", "sp0", "sp1", "sp2", and "sp3" sequentially with a time gap of one second. The complete source code for this example can be found here.

One engine core is supposed to be used for one game level, or one scene in a game. I'm aiming for creating a utility for handling the entire game, including opening, menu screen, main game, ending, credits, etc. The Command Utility is just one part of it. You can think of it as something similar to Progression Framework.

Friday, February 12, 2010

Arrow Walker Example for Rusher Game Framework

Oooh. Look at the fresh new logo I made :p

View SWF
View source

I've written a tutorial on the basic usage of PushButton Engine. It demonstrates how to create a simple 2D arrow-key-controlled game character (well, if you'd call an arrow a character).

This time I'm going to recreate the exact same example, but using Rusher Game Framework, which is my own experimental game engine inspired by PushButton Engine.

This is the document class. The Player entity is the keyboard-controlled character, and the Scene entity is in charge of update the arrow display object's position and rotation according to the Player entity's 2D spatial data.

The engine core with the key "main" is obtained through the Engine.getInstance() method. Entities are added to the engine through the Engine.addEntity() method. The Engine.stage property must be set to a valid Stage reference in order to enable keyboard and mouse signal capture. And the engine core's main loop is invoked repeatedly through the Engine.clock.tick() method, by the enter-frame event.

This is the Player entity class, consisted of three components: 2D spatial data, render target, and controller.

The 2D spatial component contains data for position, rotation, and scale, while the scale data is not used in this example.

The render target component holds a reference to a target display object whose position and rotation will be updated according to the spatial data, accomplished by setting the render target component's positionRef and rotationRef properties to PropertyReference objects that reference the spatial data by name. The useOwnContainer property is set to true, so the display object remains in its original container set up in Flash IDE, instead of being added to the renderer's internal container sprite.

The controller component listens for keyboard signals and updates the 2D spatial data accordingly.

This is the Scene entity, which is pretty much consisted of a single component: the renderer component. This component updates the spatial value of display objects referenced by render target components.

Here's the Controller component that updates the arrow's position. The onTick() method declared in the ActiveComponent superclass is invoked on each main loop call. The engine property is a reference to the engine the owner entity is added to.

Note that the s variable is set the a value of SPEED * time. The time parameter passed to the onTick() method is the elapsed time between two main loop calls in seconds. Multiplying the SPEED constant by time, the arrow will be moved at the speed of 400 pixels per second, independent of the frame rate. So if the frame rate is set to, say, 30 fps, instead of the original 60 fps, the arrow will still move at the speed of 400 pixels per second.

Okay, this is kind of the basic usage of 2D spatial data, render targets, renderers, and active components for Rusher Game Framework. Next time I think I'll post some sample code for using Rusher's Box2D package.

Rusher Game Framework

I have been very quiet lately. That's because my friends and I are busy preparing for the Creative Game Design Contest held by Gamer. The theme of the contest is "Escape", and that's the only limitation. There's no limit on the game genre and gameplay.

Originally, I was thinking of using PushButton Engine. However, as Ben Garney, the creator of PushButton Engine, points out in the forum, that he is still working on transforming the engine from single-core to multi-core. My game requires a multi-core game engine, so I decided to develop a light-weight component-based experimental game engine myself. This is the advent of Rusher Game Framework. There's no stable build available in the Downloads section, but you can grab the latest revision from the SVN repository. There are two primitive examples available in the "tests" folder.

The name Rusher comes from a character I designed when I was in high school. Here's what Rusher looks like. Rusher is still in alpha, and I think it'll become beta after we release our game.

Since Rusher is component-based, it's rather easy to extend custom functionalities. Rusher already has a built-in Box2D component package, which works with Box2D 2.1a, the latest version. I developed this Box2D package because we're working on a 2D platformer.

Here I'll briefly demonstrate some code snippets for Rusher.

Similar to the Multicore version of PureMVC, each core is referenced by a key. The Engine class servers as the facade of the game framework, pretty much like the Facade class in PureMVC. The getInstance() method is how you get a reference to an engine core.

Instead of providing something like a start() method, I'd prefer make the user call the main loop function manually, just like what I did for Stardust. Each engine core has a reference to a Clock object. The Clock.tick() method must be called repeatedly to keep the engine running. This method can be directly used as an event listener, just like the Emitter.step() method in Stardust.

The Entity class represents a game entity, be it concrete as a character or abstract as a game scene. An entity is consisted of multiple components, each representing a basic module of data or behavior. The ActiveComponent class represents a behavioral component that is to update the entity repeatedly. The ActiveComponent.tick() method is called in each main loop iteration. For this to work, the entity must be added to the engine.

Each component has a name property, so that it can be referenced by name. One entity cannot possess two or more components with the same name. To reference the data (or properties) of a component from another component, the PropertyReference class is used. The concept of the PropertyReference class is actually from PushButton Engine. Referencing components and properties by name is very convenient and flexible. For instance, you can swap a component containing 2D spatial data with another special component with 2D spatial data, which works with Box2D, not interrupting the 2D rendering components which reference the 2D position data by name.

Alright, this is pretty much I can say about Rusher so far. I'll post more details about Rusher once it's matured.