Hey everyone :) more progress on our 2D Platform Engine! In our last post, Alejandro talked about Physics and Collision Detection between sprites and the terrain — namely, how the Ninja interacts with the map terrain.

Our next step was creating Jump Through Platforms – or JTPs, which are basically platforms where the sprite can jump through but will land, and by pressing  a combination of keys, which in our case is double-tap Down or [ ↓ ↓ ] (since we are using [ ↓ + Jump ] for ninja sliding), the sprite will fall through the platform. It’s easier to explain on video:

Adding JTPs greatly increases the gameplay experience. So, how are exactly JTPs implemented in-game?

Adding JTP’s to the Map Editor

The first step is to be able to actually draw them in the Map Editor, else we won’t be able to test them ^^, as I mentioned some time ago when I started the Map Editor, we have different angles, directions, and terrain types. These are the different types of angles and directions we have currently implemented:

As for JTP’s, as you saw on the video, we have various inclinations too, so in this case, what we do is just change the “terrain type” bit. This is how it looks like now:

enum Mask_Terrain
{
	Empty = 0,
	Solid = 1,
	JumpThru = 2
};

In our current Map Editor, JTP’s are just represented by gray tiles, so this is how part of our map looks like:

On another note, the Map Editor has been improved considerably, it’s more efficient and some small but useful features have been added (like a thumbnail). Will talk about it on my next post :)

Back on track, as you can see, the actual JTP’s are one full tile in size. It does look kind of confusing when you see it on the editor, but do remember that actual graphics will go on top of what I call the map’s mask or terrain information. I did create a simple graphic for the platforms in-game.

So now that they’re added and saved on our new map, it’s time to implement them in game:

Collision Detection for JTP’s

Before getting into JTR’s, let’s take a rough look on how Solid tiles look like:

Collision-wise, the red lines indicate the collision planes, while the direction of the sprite when it collides into the tile surface is marked by red arrows. So, by adding both of these tiles together, this is what you get:

So how to JTP’s look like? They are actually the same as their solid equivalent, with all the collision planes removed (grayed out) except for the top one:

So again, adding the two tiles together would create two collision planes.

So, what happens when a sprite jumps from below, on top of a JTP? At first it looks like it will trigger a ceiling collision and it may look like there should be a special case programmed for this, however, remember that collision only occurs from the direction the sprite is coming from (marked with the red arrows), so in this case only floor collisions are triggered. And voilá! There’s still one last issue regarding JTP’s:

Falling off from platforms

The final issue regarding platforms is if the sprite should be allowed to fall off or from platforms using a key combination. Usually, this is done by using the [ ↓ + Jump ] combination — however, as we want the Ninja to be able to slide while on a JTP, we have decided to use the [ ↓ ↓ ] combination, which is also pretty standard in 2D platformers:

That pretty much wraps it up. If you noticed carefully on the video I posted above, Ninja-kun can now Slash, so our next step will be creating sprite-to-sprite collisions and hitboxes, or creating movable platforms. Which would you prefer to have implemented and which do you think poses more of a challenge?

Finally, again, don forget to follow us on Facebook and Twitter.

Happy gamedev and video gaming!

I’ve been meaning to write something explaining some of the physics and collision detection behind Little Ninja for awhile now, but I really wanted the engine to be at a point where the movement of the ninja and his interactions with the terrain were pretty much finished. This way I can share not only the basics of writing a physics engine for a platformer, but also the many adjustments that have to be made to make it feel and look authentic. The last couple of days I’ve probably spent more time running and jumping around the terrain than actually working on the physics for the game (the fact that Yuan Hao has greatly improved the map editor making it very easy for us to create new maps has a lot to do with this). This makes me feel confident enough in the current state of the game’s engine to share it with the interwebz.

Little Ninja’s Universe

I’ll use the word sprite to talk about the characters in the game sometimes (including the Little Ninja). Sprites are pre-rendered 2d images that are integrated into a larger scene used in videogames mainly to display characters on screen.
The game is tile based, each tile consists of a square of 16×16 pixels (pixels are the smallest controllable element of a picture represented on the screen). We’re using pixels as the unit of length, as I will be for the rest of this post.
Little Ninja runs at 60 fps (frames per second), which means that the screen is refreshed 60 times every second. Frames are used as the unit of time.
A horizontal speed of 7 (pixels per frame) means that on every frame, the ninja moves 7 pixels to the right, if it were -7 he’d be moving the same distance to the left. Similarly, a vertical speed of 5 means the ninja is falling at 5 pixels per frame, and -5 means he’s moving up 5 pixels on each frame.

Lateral Motion

This is the first thing that needs to be taken care of, but also the easiest. Assuming infinite acceleration (meaning the character will transition from an idle position to full speed as soon as its detected that the button to walk or run is being pressed), this can be done by changing the position of the character in the map based on its lateral speed. This process is called integration:

void Physics::IntegrateSprite(Sprite * sprite)
{
    sprite->x += sprite->speed.x;
}

This function is executed for every sprite on every frame, so all that needs to be done for a sprite to move horizontally is set its speed value.

Vertical Motion

Integrating a sprite vertically is slightly trickier, since (unless it’s a flying character) gravity should always affect its vertical motion. Given our units, gravity should be expressed in p/f² (pixels per frame squared). Now, I hate squared units, they make everything seem much more complicated than what it really is. A gravity on Earth of 9.8m/s² just means that each second, a free falling object’s speed increases by 9.8m/s; the speed increases 9.8 meters per second every second (hence 9.8m/s²). Simulating gravity just means increasing the sprite’s speed by a constant number on every frame before it’s integrated. For a character to jump all you need to do is set a value for its y speed and let the integrate function take care of the rest:

void Physics::IntegrateSprite(Sprite * sprite)
{
    sprite->x += sprite->speed.x;

    sprite->speed.y += sprite->gravity;
    sprite->y += sprite->speed.y;
}

Notice that instead of having a global value for gravity (which would be more realistic), I’m using an attribute of the sprite. What this does is allow us to create characters that fall at different rates (or not at all); take Street Fighter’s Dhalsim for example, all it takes for his jumps to feel so floaty is a smaller value for his gravity.

One adjustment you might have to make is setting a terminal velocity. If the character is jumping off a platform that’s too high, the speed quickly becomes too great for the player to handle, so it’s important to set a limit to the y speed:

void Physics::IntegrateSprite(Sprite * sprite)
{
    sprite->x += sprite->speed.x;

    sprite->speed.y += sprite->gravity;
    if (sprite->speed.y > sprite->terminal_velocity)
        sprite->speed.y = sprite->terminal_velocity;
    sprite->y += sprite->speed.y;
}

You can apply this to lateral movement as well if you want to have your character accelerate, these are the things that make each game or even character within a game feel unique. Mario for instance takes quite awhile before reaching max speed when walking while Mega Man changes from idle to max speed instantly.

Collisions

One thing you might notice in the code of the integrate function is that it just moves the sprite based on its x and y speed with no regard to the its surroundings. If there’s a wall in front of the sprite there’s nothing that’ll stop it from going right through it. Collision detection and response deals with this issue. This article deals only with collisions between sprites and the terrain since collisions between sprites are being handled quite differently and will be described in a later post. For the sake of simplicity, I’ll talk about the ninja as if he were a single pixel.

To maintain the illusion of a solid world, two things need to be done when a sprite is integrated:
1. Detect collisions
2. Handle collisions

Detecting collisions: The Broad Phase

Collision detection can be further divided into two stages: the broad phase and the narrow phase.
During the broad phase the map where the sprite moves must be analyzed and the tiles where it could have collided due to the movement during the frame must be determined. Take the following instance of a sprite moving from point A to point B within a map:

A safe way to determine the tiles that need to be checked during the narrow phase is to enclose the sprite’s range of motion within a box, using the position of the pixel prior to and after integration as vertices:

The tiles the box intersects with (highlighted in yellow) are selected for analysis during the narrow phase:

The Narrow phase

This takes place within a tile, where it is determined if and how a collision between the character and a particular line within the tile took place. I’m gonna use a tile with a 45° slope to exemplify how this is done in Little Ninja, since collisions against slopes are usually the hardest to deal with in platformers. The tile consists of 3 lines, all of which will be defined internally by a normalized vector n (an arrow of length 1 that starts at the origin and points perpendicularly at the line) and a distance d, which is the distance from the origin to the line following the direction of n. The normal of the sloped line in the tile would look like this:

Now take these two cases: in the first one (A) the sprite lies above the line, in the second one it has phased through it (B). The positional vectors of the sprites are drawn pointing towards them (the components of which are just the sprite’s coordinates).

Now, I’ll add the normals back, and project the positional vectors of each sprite on the normal of the tile, in both cases d’ will represent the magnitude of the projected vector:

Notice that in A, d’ will be larger than the previously defined d (distance from the origin to the line), while in B, d’ will be smaller. Since n is a unit vector, d’ corresponds to the dot product of the positional vector of the sprite with the normal of the line. Now for some more pseudocode:

void Physics::narrowPhase(Sprite * sprite, Tile * tile)
{
    for( each line in the tile )
    {
        // distance from the origin to the tip of the projected vector
        // dot product of the sprite's position with the line's normal
        distance = sprite->x * line->n.x + sprite->y * line->n.y

        // collision detected
        if ( distance <= line->distance )
        {
            // reposition the sprite to fix the collision
        }
    }
}

Collision Response

When it’s been determined that a sprite has penetrated a solid surface, it must be repositioned outside of the line’s bounds. The shortest distance between the sprite and the tile’s line where the collision took place will be in the direction of the line’s normal. The distance the sprite must travel in that direction to reach the outside of the line is the difference between d and d’, I’ll call that distance r:

Since n is a unit vector, the components of a vector in the same direction with a size of r can be obtained simply by multiplying the compoenents of n by r:

void Physics::narrowPhase(Sprite * sprite, Tile * tile)
{
    for( each line in the tile )
    {
        // distance from the origin to the tip of the projected vector
        // dot product of the sprite's position with the line's normal
        distance = sprite->x * line->n.x + sprite->y * line->n.y

        // collision detected
        if ( distance <= line->distance )
        {
            // distance the sprite must be adjusted in the direction of the normal
            response_distance = line->distance - distance;

            // the sprite is repositioned outside the line
            sprite->x += response_distance * line->n.x;
            sprite->y += response_distance * line->n.y;
        }
    }
}

Walking Uphill

The great thing about using this method to resolve collisions is that it solves the problem of a character walking up a slope very elegantly, take for instance the following 2 sprites walking into a ramp and how the collisions are resolved.

As you can see, after the collision is resolved in both cases, the lateral distance traveled by each sprite is reduced depending on the slope of the hill and the lateral speed of the sprite. This means that characters in the game will not be able to run up ramps as fast as they can run on flat ground, but the rate at which they run will still be related to their speed. This creates a very nice effect that feels very natural when playing, here’s how it looks like in Little Ninja:

Drawbacks of the method

There’s a lot of things that we’re used to in video games that aren’t based on real physics but do make the games more enjoyable. A lot are obvious (like being able to change a character’s trajectory mid-jump), but some are a bit harder to notice and fix. Take the following collision and response:

The response makes perfect sense, if a sprite just completed a running jump and lands on the ground it’s important to maintain the lateral movement to keep the flow of the game steady. Let’s now take a look at exactly the same diagram rotated 45 degrees:

If a character standing on a slope jumps straight up, when he falls back down the response will push the sprite down the slope a few pixels. This makes as much sense as the previous case from a physics point of view, however we’re not used to this behavior in video games. Any gamer who barely makes a jump into a sloped surface only to be pushed back by the physics engine to his death will probably smash his controller against the screen. It is clear that this case must be handled differently: the x position must be maintained and all adjustments must be made solely in the y axis.

To do this it’s necessary to figure out the y component of the vector I’ve highlighted in blue in the following image:

Notice that if the vector a is projected on the normal of the line, the magnitude of the resulting vector will be r (a value we have already calculated). So the vector a satisfies the following equation:

We also know that the x component of the vector a is 0 (since it points straight upwards), if we solve for the y component of a we get:

Which is quite simple and fast to compute!

void Physics::narrowPhase(Sprite * sprite, Tile * tile)
{
    for( each line in the tile )
    {
        // distance from the origin to the tip of the projected vector
        // dot product of the sprite's position with the line's normal
        distance = sprite->x * line->n.x + sprite->y * line->n.y

        // collision detected
        if ( distance <= line->distance )
        {
            // distance the sprite must be adjusted in the direction of the normal
            response_distance = line->distance - distance;

            // the sprite's x position after the collision is resolved is calculated
            newX = sprite->x + response_distance * line->n.x;

            // check if the lateral motion is undesirable
            if ( x was moved in the opposite direction of the sprite's speed)
            {
                // x is unchanged, only y is altered
                sprite->y += response_distance / line->n.y;
            }
            else
            {
                // collision is dealt with normally
                sprite->x = newX;
                sprite->y += response_distance * line->n.y;
            }
        }
    }
}

Is that all there is to it?

Nope. I didn’t want this post to grow too long so I didn’t mention a bunch of things that you’ll probably need to take care of if you’re working on a game (collision boxes, internal edge collisions, elastic collisions, etc). The best sources I’ve found so far are Paul Birth’s blog and Christer Ericson’s book Real-Time Collision Detection if you’re really interested in the subject.

We’ll keep the blog updated whenever we run into anything interesting during the development process. If you have any questions, comments, or ideas you want to share please post them in our comments section! Don’t forget to follow us on Twitter and Facebook!

Thanks!

“Unofficial” artwork by Yuan-Hao

A lot of devving has been done in these weeks — essentially, most collisions have been resolved by Alejandro, and we now have generic sprites (which can be bosses, bullets, and the Ninja himself) that interact with a Physics class, which makes programming for us much easier.

(Oh and, my above sketch has nothing to do with the post, but I thought it would add a nice touch :) it’s unofficial artwork though — if you can call it like that, since I am not the official Yuan Works artist. I did work as a pixel artist many moons ago and designed most of the W&W manual though!)

Types of Cameras

On to the Game Camera, I wanted to emulate what I have seen in most classic 2D platformers before thinking about our own game camera, so I nailed four types of cameras for now:

enum CameraType
{
	Locked,    // Fixed (x, y) coordinate -- does not follow target
	Centered,  // Target is always centered
	Forward,   // Camera "looks forward" depending on the target's direction
	Smart      // has its own life!
};

First three types are pretty straightforward. Last case — the Smart Cam is the one I wanna talk about, but let’s see how the Centered Cam looks first:

Camera will try to keep the target centered. Only thing you have to be careful is if the sprite is at ”edge” or boundary of the stage, in which case the camera shouldn’t move. Something like this will do (click to see the code):

case CAM_Centered:

    // Our camera's upper left-most (x,y) will be:
    camera.x = sprite->x - camera.width / 2;
    camera.y = sprite->y - camera.height / 2;

    // Check if camera(x,y) is inside of the Stage boundary.
    if (camera.x < 0)
        camera.x = 0;

    if (camera.x > Stage.width - camera.width)
        camera.x = Stage.width - camera.width;

    if (camera.y < 0)
        camera.y = 0;

    if (camera.y > Stage.height - camera.height)
        camera.y = Stage.height - camera.height;

If you’re doing a basic platformer, I recommend implementing this camera first, as this may be enough for what you want to do or test. Metroid Zero Mission on GBA almost exclusively uses this camera (except for secrets and some other minor details). You may notice that when the player is at the boundary, the camera won’t keep him centered, it will adjust to the left-most upper pixel of the Stage.

Some stuff may arise with this type of camera:

1. Even if you move a little, the screen will scroll (scrolling doesn’t look so good in small screens sometimes)
2. When the target sprite is running too fast, it’s hard to keep track of what’s coming
3. It’s hard to hide secret areas on the map (think of DKC or any Metroidvania)

#1 and #3 are harder to solve, so let’s solve #2 first…

Forward Camera: Look ahead!

As  most enemies will come facing you, rather than from behind (well, it’s a Ninja, so who knows!), this camera will always show a bigger area in the direction which the player is facing. Here’s how it looks:

In this case, the camera will follow the direction the Ninja is facing, and will show 96 pixels forward, so 60% of the screen will be in front. However, note that this introduces another variable, you will need to have a scrolling speed, because if the screen scrolls too fast, you’ll get dizzy pretty quickly <^^< , so you’ll need to keep a scrollingDestination(x,y) and a scrollingCurrent(x,y) coordinates. This is how the scrolling code looks:

//
// Scroll the screen if dest and current are different:
if (scrollDest.x != scrollCurrent.x)
{
	if (abs(scrollCurrent.x - scrollDest.x) > scrollSpeedX)
		scrollCurrent.x += M_sign(scrollDest.x - scrollCurrent.x) * scrollSpeed.x;
	else
		scrollCurrent.x =.x;
}

if (scrollDest.y != scrollCurrent.y)
{
    if (abs(scrollCurrent.y - scrollDest.y) > scrollSpeedY)
        scrollCurrent.y += M_sign(scrollDest.y - scrollCurrent.y) * scrollSpeed.y;
    else
        scrollingCurrent.y = scrollingDest.y;
}

This solves issue #2, however, if you quickly turn left and right, the screen will scroll like crazy, something that, again, can be undesired for smaller handheld screens.

Smart Camera

The final solution is to implement a Smart Camera, the name’s a little pretentious ;) but in reality this camera just tries to mimic the natural flow of someone following us with a real camera. This video by Shaun Inman explains how Mario’s camera works and you’ll see it’s pretty ingenious — it is nicely implemented by said author in this video. So here’s a video of how Little Ninja’s Smart Camera looks:

On to explaining what this camera features: Whenever the sprite moves inside of the blue box, scrolling won’t occur. So if you turn a lot to the left and to the right, the screen won’t scroll too much, and the screen has sort of an acceleration parameter where if you don’t move, the camera doesn’t move too much either. This idea was inspired by Kyle Pulver’s Camera. Do check it out — you’ll see why it’s so important to have a smooth and natural-feeling camera.

You’ll also notice that Ninja is almost centered, but when you start running, the camera will accelerate again and look forward, allowing you to see more terrain for incoming exploding flying birds or projectiles, and as soon as you slow down, the screen scrolls back to you.

As for top-down scrolling, this is much trickier and I didn’t do too much tweaking, but basically, scrolling is fast if you are falling down, but if you jump to a top platform, scrolling will occur slowly — this allows us to feel a little hang when the player jumps to a very high platform. However, if you start running, the camera quickly gets back to you and starts scrolling much faster.

Yay! So is this the ultimate platformer camera?

Nope, it’s not in its final version! And actually, this camera may not be suitable for all situations, bosses will definitely need their own defined camera, auto-scrolling and scripted cameras will also play a big part, but this last camera has allowed us to have a better feeling of a high speed platformer.

The final issue, #3, as Kyle called them “Camera blockers” (secret rooms) can be partially solved with a smart camera, but will definitely need scripting wired to the map editor.

If you notice in this video there are new actions (double jumping and sliding while running), and most collisions have been fixed — Ninja can now run downhill, which is a great improvement as Alejandro did not have to force the code and managed most of it with collision detection formulas, instead of having to hard-wire individual cases. He’ll be talking about that that as soon as collisions are perfected.

So far, we’re liking the fast-paced action and the camera is helping a lot. What’s your take on it? Do you prefer exploration or fast-paced action? Let us know in our comments, and if you wanna get in touch with us, don’t forget to follow us on Twitter and Facebook!

Hi everyone, welcome back to the Yuan Works DEV blog! ^^

We are slowly bringing Little Ninja back on his feet, as well as our GameDev blog, with information of what’s happening behind the scenes.

Regarding some questions you may have or that we usually get asked a lot (IE: “Will this game run on my favorite console”, or, “Is Little Ninja your next big project?”), we’ll be addressing them at the end of this post. For now, on to the Engine!

Game Engine update, and a new member in our team!

One of the most important aspect of a good platformer is how smooth it is played, as you may remember in previous posts, mechanics like running, sliding, double jumping, and wall hanging were pretty much functional. However, physics and collisions were temporarily implemented just for the Ninja itself, so adding a new enemy or player would mean having to program each of them separately.

The solution was to start working on a solid Physics and Collisions Engine, which programmer Alejandro Di Mare, is currently working on. He’s working on game mechanics and general development too, but as for now this is one of our priorities, while I (Yuan-Hao) will be working on tools and editors, as well as porting old tools from Wind and Water to Little Ninja.

Anyway, we’ll be posting with more details on that later :) Here’s a short video of Little Ninja’s new collisions as well as the Map Editor. Jumping physics have been improved too:

Old collisions have been removed for now, but the new ones will work with all sprites, so as soon as it’s done, adding enemies and real gameplay will be quite easy!

What about the graphics?

Speaking of enemies, Yuan-Hsi decided that a Ninja without a Nemesis is not a real ninja! So here’s some WIP of a new sprite:

Graphics are not as important for now, as the three of us are more focused on engine and gameplay mechanics, but it’s always a treat to get a hang of the look and feel :)

Future of Little Ninja

For some time now, we’ve received some questions regarding Little Ninja, as well as a lot of support from fans. Thanks! It’s actually your support that got us back into working on Little Ninja, and what will shape its future!

Will Little Ninja run for  [ insert your favorite console here ] ?

Little Ninja technically run on whatever Wind and Water worked for, as we are using the same architecture. So that means: Windows, Linux, Dreamcast, and Linux-based portable devices like Pandora and the GCW. Technically…!

Yay! So will it be released for my [beloved console] !

That’s a whole different story! =D Each different release needs a lot of work, testing, and porting. For example, W&W’s Dreamcast manual was 50 pages long, and designing the whole packaging took a long time! The game was also translated 100% to Japanese.

Wind and Water’s packaging for Dreamcast

We’re not even sure if it’s going to be our big project or if it’s going to get released — we’re not thinking about that yet, it’s too early for that!

So why don’t you guys Kickstart or open preorders or do some funding? What about newer systems?

When W&W was released, things were different! Android was not so popular, Steam was not as big as it is now, and Kickstarter probably didn’t exist.

We’re aware of all the options, but to tell the truth, we enjoy the process of making games — we love making them, even though there are hardships to endure.

Little Ninja is on a very early stage of development, and we wanna show you guys more of Little Ninja, and think less about how we’re gonna make it happen.

Let’s worry about making a fun game, all we ask from you guys is your support and feedback! This will all shape up the future of Little Ninja – let us know what you think, share it, follow Yuan Works on Facebook, we’re retaking our Twitter account, and if you blog about us, don’t forget to let us know! (English, Español, 中文, 日本語, Italiano, un peu de français, or any other language we don’t speak is fine!)

Updates will be coming, and thanks for reading!

We’d like to tell you that we’ll be holding the raffle for the 5 Full Set Avatars today Sunday.

We have great news too, Online tests are going very smooth on Windows, Linux, and even Pandora! Here’s a video courtesy of PokeParadox (thanks!)

And! We’ll be doing some online beta testing tomorrow! Join us so we can test-load the server, on our online chat:

irc://irc.freenode.net#windandwater

Or, if you don’t have IRC (like me!) click here:

http://www.wind-water.net/chat

The raffle and online testing will begin today Sunday Feb 20th. We’ll be on the channel from 11PM GMT to 5PM GMT, we’ll hold the raffle first and then get ready for some online beta testing!

Just wanted to tell you that Wind and Water now has in-game Mouse Support as of version 1.05, download from our main website!

The video also shows how Full Set Avatars work (in case you don’t know, for $10 or $15 you can be a part of our game and play with your own W&W-styled avatar based on yourself!)

Here’s the video:

If you want to appear on the game, for a limited time you can grab your own avatar and support us! We’re also raffling 5 Custom Avatars at our Forums, participating is easy but you have little time left!

We’re also working on a Linux version which is available for beta test on the forums (the game works 100%) will soon be released.

Wind and Water has been reviewed at TIG Source and was tagged by indie developer Derek Yu as “Highly Recommended”! (Thanks Derek!) This means more players will be able to enjoy W&W, which is now free, and hopefully we’ll have the new online scoreboards and online beta testing running soon!

What do you think about mouse support?

Yuan will be explaining how to clear Stage E05 (which is pretty far ahead on the game in case you hate spoilers!) as well as explaining about the mouse. Basically you use the left and right clicks to rotate the pieces, which we thought wouldn’t work so good but it’s actually quite nice :)

Comment to let us know what you think about it (and let us know if you’d like to beta-test the mouse version too, we’ll be uploading a private W&W beta around here!)

Wind and Water around the web!

Since our release of W&W less than a week ago, the game has been mentioned on tons of sites around the web!

The game was quickly catched by the original GP2X users, the GP2X Spanish community, Open Pandora, as well as many many Dreamcast sites, DreamAgain (in French — thanks Edd!), was also reviewed as one of the best 5 DC indie games (thanks Barry and cube_b3 from Senile Team!), the Dreamcast Junkyard, and by KingBuzzo from the DC Scene too!

We’ve also hit sites like indiegames.com, retrocollect.com (thanks Cauterize!), RPS, the TIG source forums, sites in languages that we understand — Spanish, Portuguese, French, and Italian too, some that we don’t have a clue about like Polish!

We’ve even read about someone who is actually in The Final Stage (in French), so we’re expecting people to see the final ending this weekend and keep enjoying the game :)

Here’s a fan made video edit with custom BGM from the first W&W mini-game, Sunset Driver:

We’re very grateful with everyone sharing the news about W&W, and with our first 2,000 downloads and lots of feedback, we’re closer to making W&W Online Battles a reality!

If you know of websites, own a blog, participate in forums, or know friends, via Facebook or anything that might be interested, please let them know about the game! And don’t forget to participate on the Forums too and win a chance to have a free Full Set Custom Avatar!

We’ll bring you more of Yuan Works in the next few weeks, so keep tuned! :D

Here’s the trailer:

Visit Wind and Water Puzzle Battles to download the game and for more info!

And if you’d like to support us, you can get a Custom Avatar based on you:

Sprites appear in-game:

Click here for more information on how to get a sprite and support us!

Please let others know about W&W (in forums, in your own website, in game news sites), download the game, comment about it and, if you can, support us! We really need others knowing about the game which will mean that we can keep working on the Online/Net play version of W&W (which we’re hoping to release if W&W gets popular enough) as well as our other projects such as Little Ninja.

Also, we’ll be giving out 5 Full Set sprites for FREE for W&W players, click here for more information on how to win one!

Happy gaming!

Trying to make 3D look unmistakably 2D brought some problems on 3D graphics software. Since properties such as the ones I’m looking for are seldom (if at all) used, even if they are very basic, it was rather tricky.

First of all, it was a pain removing all the light on the characters and the scene. Rendering software uses so ugly default lights which were hard to remove. Since the first part won’t be shaded whatsoever, this was necessary to make 3D indistinguishable from a sprite based game.

Also rather quirky to set up was a completely orthographic camera (pseudo perspective used in blueprints and the like, which has no depth). I had to highjack one of the available ones that are supposed to be for scene control only. Needless to say, this is the closest to true 2D. Now I’m only missing a pixel perfect way to render things, and I will TRULY have 2D in a 3D environment.

What I’m particularly proud of are the lightning-fast rendering times. Usually, one single frame can take anywhere between 5 to 20 minutes, or even more, depending on the software settings and the complexity the computer has to calculate. At 1024 resolution, production quality (read that as ultra souped-up), any one frame from my scene renders in 2 to 3 SECONDS!!!!! YES, SECONDS. Other lighting tests like final gather work nice and fast, but I can have a similar effect with far less resources.

I also started to work on the animation. The 2D character already has a lot of animation done, including a super fluid walk cycle at 30fps, which I almost NEVER use, except for action based animations. Well, come to think of it, many Wind and Water animations were 30fps, so I take that back. Look at all those frames for just a walk cycle! The 3D character has to be “rigged” which basically means equipped with a virtual skeleton that allows it to move. It sounds like a pain, and yes, it actually is.

There are only two characters, one is 2D pixel art (of course), and the other one is in THREE (yes, three) dimensions!

The character design for the pixel character (code name “Square”) is my traditional work, so nothing too deviated from the norm:

However, for the second, less traditional character, I used a more traditional approach, sketching various poses and trying different designs (a step now unnecessary to me for pixel art).

Also, I had fun using color pencils and watercolor, media I seldom have a chance to use now =3

Then came the fun part… translating the character to 3D… It was kinda hard to keep all the weird “anime” angles visible on the model, which will be kinda low poly for that nostalgic PS1 look we all love…

Lastly here’s a turn table on the preliminary model for the 3D character, code name Polly. Polygon, Polly. Get it? Yeah, I’ll shut it now: