| Colorful Glue

First of all, I’m a terrible artist. My mediocre drawing skill is literally hurting my capacity to churn out games rapidly. I’d very much like to hire someone or to co-work to accelerate my projects, and I’ve been searching for talents in my local ever since. No luck so far. If you have urge to work on casual game art with an individual developer, let me know.

Whatever the case might be, I need a good art assets. More likely, I want a set of assets with unified look and feel. Everything has to be completely unified in one color scheme, one drawing style, and one feeling. The gap between my reality and the obnoxiously picky attitude to artwork quality always burdens my heart. Then all of sudden, out of blue, a ray of light is shed on me. I am subscribing iDevBlogADay, and Luke Rodgers was doing 2D artwork in Blender! That sounds so right because I know how to handle dots in 3D space with Blender and coat with skin! Since Blender thereafter handles very nicely all the curves, shadow, and highlighted area, I can bring professionally handled characters into “Catstrict 7″!

There are of course pros and cons

pros:

Once I build and skin a model, I can reuse the model over and over again until I got it right for color or shading.
Once a rendering environment is set (lights and shader parameters, Lamp and Material in Blender) I can apply them to every single graphic asset in game; letters,characters, special objects, terrain, buildings, and the list goes on.
Once a model gets bones, its animation will be handled by Blender and the outcome will be very consistent and proportional. This will save huge amount of time for creating animation sprites.

Cons:

It takes certain amount of time to model and skin. This is inevitable and usually takes longer than sketching a sprite in 2D space.
Shader and lights parameter are hard to get it right at first. I have to give as many trials as I should. This puts delay in development process.
If my skin work isn’t done properly, no matter how good my texture is, the result will look dreadful.

The downside does not discourage me because I am in a situation where the rendered results do not need gory details like usual 3D artworks do. We are talking about 320×480 (640×960) pixels screen right? Detailed wrinkles probably won’t make much difference in the end, and I should focus on big features such as big eyes, shape of face, and etc. These facts lead me to model low polygon shapes and save me huge chunk of time in the process. ( Nevertheless, it takes good five days to refresh my memory for shortcuts in Blender. Arrrrrgh!)

Here comes what I have done for last few days.

First one was tried to find out distinctive features of a cat face. Close to real cat head. Not that I want it.

I’m getting away from realistic look but close to more cartoonish style. However, he looks like a blob of bubble to me. Why your eyes are so rectangular?… Next?

First cartoonist cat head. Gah, this is horrible. I have to try again.

That’s better. But seriously, what’s happening to your nose and mouse?

Ok, This one starts showing some promise. (I named him “Hamlet”. say hi!) Let me remind of myself. ‘I am making 2D game character for small screen. I don’t need full-fledged 3D volume for the character. Something exaggerated in its characteristics with flat, curvy, and smooth look is more likely what I’m looking for.’

That one is skinned and tested with a texture. Need to fix the light and shadow.

Big, chunky bouncer dog. He should have voluptuousness, grudgy, and reserved look. hmm…

With different shader parameters and light types, I rendered few shots. Like I mentioned earlier, I can generate different looks of a character just with one model and a texture. Over and over again. If a particular setting for shader and light suit to the project theme, I can apply that to every single model I have worked without a blink. This is very handy indeed.

Of those ones, I’d like to use ones with less plasticky look and softer shadow. It looks like I have to give few more tests for shadow.

I will keep reiterating and reiterating until I get it right. In doing so, I will stack huge pile of experimental leftover. But that’s good because all those leftover will contribute to the final one eventually. Cats and dogs are just barely out of brainstorm and no, these are not even going to be used in test. Just not yet. So far, not a single one satisfies me and I think I’ll keep trying until I can hit the eureka moment.

Until then, keep it safe my friend.

update (02/28/11)
With few more trials, I finally come to a result with which I could move on.
The issue with previous renderings were that they all had the plasticky feel. Although I draw characters in a 3D editor, the result should resemble what is drawn by hands on good old 2D space. The new rendering looks a lot better to me.

Object-C provides few really cool features. Of those ones, I’d like to pay a special attention to runtime class selection and object configuration. (*There might be a precise term for this, but I’m not aware of any. If you do have an idea, let me know or point me the place to look.)

Basically, I pretty much code/ design a whole game myself. In this case, the most efficient way so far I’ve found is to have as much of flexibility as it is possible at coding/programming phase for designing actual stages later. In doing so, I recently faced a situation where I strongly wanted to use property list to load stage data. Property list is a really great option to package stage data because it is human/machine readable at the same time. Simply put, my iPhone sees what I see.

But when it comes to instantiate platforms, enemies, and whatnots from a loaded property list, you might go into auto-cruise with good-ole “switch()”. This might be ok with small number of classes. When you have, let’s say, 30 different classes you like to instantiate objects from, the switch() might grow very large, and code tangles on you. This is where “Runtime class selection” shines. Look at the code snippet of below.

//BlackNoseNinja.h
@interface BlackNoseNinja
{
	NSString *ninjaName;
	int		noseHoles;
}
@property (nonatomic,retain) NSString *ninjaName;
@property (nonatomic,readwrite) int		noseHoles;
@end

//BlackNoseNinja.m
@implementation BlackNoseNinja
@synthesize ninjaName,noseHoles;
@end


NSString *enemyNinja = @"BlackNoseNinja";
Class enemyClass = NSClassFromString(enemy);
NSAssert(!enemyClass, \
        [NSString stringWithFormat:@"%@ class does not exist", enemyNinja]);
id enemyObject = [[enemyClass alloc] init];

What this code does is basically to select “BlackNoseNinja” class based on the class name in string format, then instantiates an object from the selected class. In other words, you run a binary and you just tell it what class you want in string-formatted data such as property list. As long as there is a class you want, you’re going to have it on the fly.

Then you might wonder, “Ok, I am getting an object received with id (generic c-type object pointer). how am I going to set the attributes of the object without getting pesky warnings from compiler?” For that, we can use Key-Value Coding.


[enemyObject setValue:@"black mamba" forKey:@"ninjaName"];
[enemyObject setValue:[NSNumber numberWithInt:3] \
        forKey:@"noseHoles"];

Better yet, we can simply pass a dictionary with keys and values and the object will be ready for you.


NSDictionary *enemyNinjaProperties = \
        [NSDictionary dictionaryWithObjectsAndKeys:@"black mamba",@"ninjaName",
        [NSNumber numberWithInt:3],@"noseHoles",
        nil];

[enemyObject setValuesForKeysWithDictionary:enemyNinjaProperties];

If we’re to put all these together with a plist, we would have the following example.

//enemyNinjaProperty.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>className</key>
	<string>BlackNoseNinja</string>
	<key>properties</key>
	<dict>
		<key>ninjaName</key>
		<string>black mamba</string>
		<key>noseHoles</key>
		<integer>3</integer>
	</dict>
</dict>
</plist>


NSDictionary *enemyNinjaProperty = [NSDictionary \
        dictionaryWithContentsOfFile:@"enemyNinjaProperty.plist"];

Class enemyClass = NSClassFromString([enemyNinjaProperty \
        objectForKey:@"className"]);
id enemyObject = [[enemyClass alloc] init];
[enemyObject setValuesForKeysWithDictionary:[enemyNinjaProperty \
        objectForKey:@"properties"]];

There you have it!, dynamically selectable and configurable objects in runtime.

There are few things to keep in mind. You should select a existing class, and you should configure an object with existing, KVO compliant properties. Otherwise, you’d see a crash. Further, you can use JSON if you like to. There really is no limit as long as you have NSDictionary format of object properties.

There are a tons of cool stuffs you can do in Obj-C at runtime. I’m going to list few guides for you and hope those help.

Objective-C Runtime Programming Guide
Objective-C Runtime Reference
Key-Value Coding Programming Guide
Key-Value Coding (KVC) and Generic Programming @Theocacao

*edit : the properties you pass down to an object must be KVO compliant.

Colorful Glue

Monthly Archives: February 2011

Cats and dogs out of storm

Runtime class selection and object configuration in Obj-C