Sunday, January 23, 2011

Moving to a New Blog

I’ve registered a new domain, and I've moved to a new blog.
Future posts will be posted there.

Friday, January 7, 2011

Stardust 1.3 Released!



Stardust project homepage

Finally! Stardust version 1.3 is released!

I've updated all the examples, so they all work perfectly with the new particle handlers.

I'm currently working on the integration of Stardust and Minko, a new 3D engine that will support the Molehill APIs. Paq is working on the integration with Alternativa3D and Away3D, whilch will also support the Molehill APIs. I'm really looking forward to Stardust being used in Molehill-powered applications (especially games, of course), enriching the visual experience with 3D particles!.

Monday, January 3, 2011

Particle Handlers for Stardust 1.3



Stardust project homepage

As a quick notice, Paq has joined the Stardust development team. He'll be working on plugins for Alternativa3D and Away3D, and Japanese localization. Horray!!

I'm currently working on the most important new features of Stardust 1.3, switching from renderers to particle handlers.

Previously, the particle data in Stardust are read and visually presented by the Renderer class, whose particlesAdded, particlesRemoved, and render methods take in ParticleCollection objects as parameters, and traverse them to retrieve particle data, resulting in almost twice the processing overhead for particle traversal.

I've found this extra traversal effort quite unnecessary. Since a complete traversal of the internal particle collection of each emitter is already done in each emitter step, so why not "embed" the rendering process into the emitter step? This is how I came up with the idea for particle handlers.

The skeleton of the ParticleHandler class looks like this:


The stepBegin method is invoked at the beginning of each emitter step.
The stepEnd method is invoked at the end of each emitter step.
The particlesAdded method is invoked when a new particle is added to the emitter.
The particlesRemoved method is invoked when a dead particle is removed from the emitter.
The readParticle method is invoked when a particle is fully updated by all actions.

You may override these methods to create your own handlers. The concept is quite similar to that of the renderers, only that particle handlers do not require extra (and unnecessary) particle collection traversal. Everything is done in one single traversal.

A particle handler is assigned to an emitter through the Emitter.particleHandler property, which is quite straightforward:


You may find the similarity between the code above and the use of its renderer counterpart:


Not until I finished the ParticleHandler class did I realize how easy it is to implement a polling station as a particle handler, favoring those developers preferring polling over events.

For your information, a polling station is like a passive database. You access the data only when you need to, which is the opposite to an event system. An event system, as most Flash developers are already familiar with, is an active database, "pushing" data to you whenever there is new data available.

Some framework is designed to better work with polling stations rather than event systems. Thus, I've written a PollingStation class that works as a polling station, recording all the relevant particles in each emitter step, and exposing an interface for data polling.

Saturday, November 27, 2010

My Weird Dream - Thriller Game Story Concept

I was taking a siesta in my girlfriend's house, and I had this very weird dream. The story of the dream was bizarre yet inspirational. It might serve as a game or movie concept. I thought I should type it down before I forget it.

So here goes my dream.

***

My girlfriend and I were some sort of secret agents sent by the government to investigate a mafia overload. We managed to get invited to his party held at his mansion, as undercover guests of course. His mansion was located in a small remote village in deep mountains, so it took us hours to drive there.

It was a very dark night. The mansion was extraordinary, like the ones you see in most movies. Most of the guests consisted of mafia members, and so began our investigation throughout the mansion.

Somehow I was noticed by a guard. He gave me a full tap-down and found my concealed gun, so our secret operation was blown. My girlfriend and I were held and watched by guards in a small room, with their boss standing aside planning how to torture and interrogate us. Both of us could simply thought about our hopeless future.

Suddenly, that was when something really wrong went on.

Without any warning, the entire village experienced a complete black-out. We could hear the screaming form the guests from everywhere in the mansion. We could even hear the shrieking voices from the entire village in the mountains, as if they were chased and attacked by some unidentified beings.

Then the lights came back.

The mansion was a mess. Shattered glasses, plates, and furnitures were scattered everywhere. Most of the guests were gone, and the rest were just too terrified to even say a word, with their mind completely left blank, not knowing what exactly to do next. People who managed to get to the garage and tried to drive away from the mansion, from the village, all mysteriously ended up either crashing into obstacles or falling into cliffs, with no survivors.

The mafia boss, my girlfriend and I, and the guards watching us, were the only people left who had remained conscious and were all thinking what to do next. Then we heard the sound.

Like thousands of high-pitched squeaking mice all coming at once, we can feel a swarm of unknown beings approaching extremely fast from outside of the mansion window.

"Quick! Shut the windows!" I yelled.

Two of the guards rushed to the open window and slammed it closed. But they were not fast enough. Some of the creatures leaked into the room. They were huge bats, or at least I thought they were. Those black-winged creatures soared in the room, attacking all the people inside, trying to bite us with their fangs and mauling us with claws.

I told the boss and the guards that this was not the time for making enemies. They should free us immediately so that we could work out a way to survive. And so my girlfriend and I were untied. Each of us picked up what we could find as a weapon in the room.

After a lot of yelling and wielding, all of us managed to kill every single flying creature in the room, shivering and panting.

"So, I think we DO need to cooperate in order to live." said the mafia boss.

It seemed that the the entire village had been wiped out, and we were the only survivors, for we could hear not a single voice from the village outside of the mansion.

"Yeah, I think so." I said.

And so began our escape from the mansion.

***

This is where my dream ended.

I can still remember us fighting our way through some unearthly and carnivorous creatures in my dream. It was as if those creatures were kind of manifestation of the fear and nightmare of each of us.

This can be some inspiration to a thriller adventure game. I hope more idea could come along.

Friday, October 22, 2010

MicroPlanet Game Concepts

Currently I'm training in the School of Political Warfare, since I've passed the test for political officers. After two more months of training, I'll be working in the army as a political officer, hopefully having a much better and easier life than other ordinary soldiers.

In case you don't follow me on Twitter, I'm accepted into DigiPen's Bachelor of Science in Game Design program. This means I'm going to learn some real hard-core game development skills from the professionals after I get out of the army. I think I shouldn't waste my time on the boring and hollow training classes in the School of Political Warfare, so I've been constantly sketching game concepts in classes.

Recently, I've come up with this game concept, called MicroPlanet. The story takes place on a galaxy of microscopic planets, where there are bunny-like fungus creatures trying to expand their territory and fighting against opposing tribes.

Here's the first concept art I've drawn.
(Click on the image for larger view)


Basically, it's a 2D real-time strategy game. The player can only control the creatures, making them gather resources and building stuff, in order to expand the colony and destroy opposing tribes. The creatures cannot directly attack those from the opposing tribes, and vice versa. They can only build weapons, such as tanks and missile silos, to destroy enemy structures. Each tribe has a main building that produces new fungus creatures. When this building is destroyed, the game is over.

Below are some concept arts for the main menu screen. The smaller two on the bottom are two different designs for the main menu options.

Here are some quick sketches for various units, resources, and buildings.

And below are some more sketches. So far I've come up with three different types of resources: thermo energy, water, and metal. Thermo energy core are like miniature suns floating in the air; the Thermo Absorber is a ring-like structure that absorbers the thermo energy radiating from the core. On micro planets, water appears as floating blobs; the Water Station gathers water resource from below using an erect pipe.

There are two types of planets: solid planets and gas planets. There are some planet-specific buildings and resources, which I'm still working on.

On the top left you can see a quick concept sketch of the in-game screen, where a minimap is present and the character is selected.

That's it for MicroPlanet concept so far. I'll go as far as I can when I'm in the army, and I'll try get directly down to some coding when I'm home. Or at least I could do some CG concept arts.

Saturday, August 7, 2010

My One-Year Compulsory Military Service

I'm about to fulfill my compulsory military service tomorrow (August 9), and it ends in mid-July 2011. During my service, I can only have web access perhaps every one or two weeks, or even longer. So the updates and fixes to my projects will become far less frequent than normal. You may still email me if you've got any problems with the projects. I don't guarantee a quick response, but I'll reply as soon as possible.

I've applied for the "Bachelor of Science in Game Design (Fall 2011)" program in DigiPen. The result will come out several weeks later. I hope I could make it :)

P.S. I've shaved my head for the army, and it takes only 10 seconds to dry it after shower!

Sunday, August 1, 2010

Using MVC Pattern in Rusher



Rusher project homepage

Rusher is now version 0.6 Beta. One of the most important changes is the extraction of entity-related code from the Engine class into the EntityManager class. So instead of writing things like:

you write:

I've also added a new MVC Pattern example. Actually, it was one of my experiments to try implementing the MVC Patern in Rusher. This one turned out nice, so I've committed it to the repository. This example is simply a proof of concept, and I might find out other better approaches to using the MVC Pattern in Rusher.

View example demo
View example source

This example is a very simple painter application, consisted of a color chooser, a clear button, and a bitmap canvas where you can draw with your cursor.

The entire application is represented by the Context class, which extends the Entity class. There are four components added to this entity: Signaller, Model, View, and Controller.

Context


The Context class is pretty simple. It creates four components and adds it to itself. Another important modification to Rusher in version 0.6 is the one-clock-cycle-delayed invocation to the Component.onAdd() method. In this way, the order in which the components are added to the entity does not affect whether accessing other components in a component's onAdd() method yields a null value.


Signaller


The Signaller component is pretty much a "signal hub" consisted of several CJSignals signal objects. These signal objects dispatch application events listened by other components. Also, other components can cause these signal objects to dispatch events.


Model


The Model component contains the underlying application data, a BitmapData object representing the canvas. Also, this component defines several public methods that modifies the bitmap data. These methods allow users to change the line color, move the drawing pen position, draw a line, and clear the entire canvas.


View


The View component constructs and displays the visual representation of the application. In addition, this component listens for the mouse event dispatched by these display objects and relays these events to the signal objects in the Signaller component.


Controller


The Controller component listens the signal objects in the Signaller component and maps them to command objects. These command objects invokes the public methods provided by the Model class to modify the underlying bitmap data.


Finally, below are the command classes.

This is the LineColor command that changes the line color.


This is the MoveTo command that moves the position of the drawing pen.


This is the LineTo command that draws a line.


And this is the Clear command that clears the entire bitmap data.


You may view the source of this example in its entirety here.