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:

If you remember in our previous posts, I first defined the different actions states that the Ninja would have. First Little Ninja walked and jumped, and later he double-jumped, hanged on walls, and walked on cliffs. So, what’s left?

Running

Running is crucial in most fast-pased action games, and fairly easy to program. Basically, when the users taps the same direction twice and holds the button, the character will go from WALK -> RUN, which is essentially the same as walking except it’s a different animation, and the moves faster (x * 2, or twice is fast in our case):

If you watch carefully, jumping while running allows the Ninja to jump farther (again, twice as far as opposed to the normal jump), and if you hold the same direction he will keep on running after jumping. Another detail is that, if the Ninja runs for a little while and stops, instead of going from RUN -> WALK, his transition will be RUN -> BREAK -> WALK. Did you notice it? This small details polish the platform engine and will allow the Ninja to move swifter and smoother. He’s a stealth Ninja after all!

Ducking and sliding

Before thinking about sliding (dashing), for the last 30 years, most 2D platform games slide by holding the JUMP key while you’re holding DOWN — or ducking. Ducking was one of the states that I should have programmed firsthand, but since it had no particular use until now, I decided not to do it. You reap what you sow they say!

Anyway, life lesson aside, ducking is fairly simple: the character will start the DUCK animation and reach the DUCK state while you’re holding the DOWN key, but if you release it will start to un-DUCK (aka: stand up) and reach the IDLE animation.

Anyway, while Ninja·kun is ducking, pressing the JUMP key will allow him to SLIDE, useful for sneaking in small places, squishing wild frogs, etc. Take a look:

As you can see, Yuan decided that a simple Megaman 3 sliding “animation” was not enough, and decided to create a very funny animation that I thought would never work. Worked like a charm to my surprise. Anyway, eventually the Ninja will be able to slide while running and do some other fancy moves, but for now, enjoy the new video with all the new Ninja features:

That’s it for today, hope you enjoy it and don’t forget to subscribe to our content and follow our progress closely!

Last time we saw Little Ninja running and jumping, and I promised to make him walk in slopes and hang in walls (after all, we’re talking about Little Ninja™ here). Well then it’s time to learn about Little Ninja’s new moves!

Walking on slopes (terrain angles)

The first thing I’ll solve today is having the Ninja walk on different terrain angles. As of now, there are three terrain types if you remember, but Mr. Ninja can only walk on two of them as for now:

When the Ninja walks on flat terrain, his X position changes (left and right). Well, what happens when he walks on slopes? His Y position changes, too (up and down)! In the 45° slope, for every X+1 pixel he moves Y+1 pixels, while on the ~26° slope, for every X+1 pixel, he moves Y+½, (but remember that pixels can’t be divided).

An important aspect is knowing when his Y position changes. For this, we have to use the sprite’s CENTER position. Whenever the Ninja jumps on a slope his Y position must be calculated too based on his X.

New Ninja States: Wall Hang and Double Jump (somersault flip)

A Ninja that can’t hang on walls or randomly somersault in the air defying all physics laws is definitely not a skilled one!

Anyway, wall hanging was pretty simple to do: Basically, when the Ninja hits a wall and you hold the direction on the d-pad (right in that case), he’ll hang on the wall and slide.

As for the double-jump, after performing a normal jump, jumping again while hanging in mid-air makes Little Ninja perform what is normally called a “double jump”, allowing him to move a little higher and a little further too!

Well, besides these two new states and slopes, I also added background scrolling, which I’ll try to explain more detailed later on. And as always, here’s a video (well GIF actually) of Little Ninja in action!

It’s starting to feel very versatile with the new moves and I’m sure that as soon as he runs and slides things are going to get even more exciting. Stay tuned for more Ninja action!

Today’s post talks will be about how to design the most basic parts of a platform game engine. On our last post, I finished a simple Map Editor, now it’s time to put Ninja Stick Figure into action!

Defining the Ninja Action States

Most of you are probably thinking about defining the most basic and generic objects (EG: the main character, enemies, bullets, items, etc.), but since this game is supposed to be simple, we’ll jump right into the main character, Ryuuhi, since I’m more interested in developing the platform engine. For a more complex and bigger project, this definitely wouldn’t be the best approach.

Anyway, the first thing I have to think about are the different states that our Ninja has:

Every state is self-explanatory so there’s not much to explain. Defining how states work is easy, IDLE happens when you don’t press any button, WALK when you press Left/Right, JUMP when you press the “Jump” button, and so on. For now, I won’t be using the ATTACK state since I’m only interested in how Little Ninja interacts with the terrain, not with other objects. Anyway, it’s important to associate an animation with each state, as well as a transition between states: for example, the character may go from IDLE to WALK, but can’t go directly from JUMP to WALK. Anyway, this can be done with a simple Enum:

enum NinjaAction
{
    NJA_Idle = 0,
    NJA_Walk = 1,
    NJA_Turn = 2,
    NJA_JumpStart = 3,
    NJA_JumpHang = 4,
    NJA_JumpEnd = 5,
}

Enums are very simple but work well on cases like this. This way, if I need to define another state or need to change its number for any reason, the rest of the code stays clean. For example, the IDLE animation would be ninjaAnimation[NJA_Idle], which is easier to understand compared to ninjaAnimation[0]. As for  Jumping, three different states were defined: the part where Ryuuhi ascends (Start), the part where Ryuuhi doesn’t move and descends (Hang), and the part where he falls (End). In good theory, all states should have a generic outcome when you enter and exit a state, but as I said before, I’m more focused on game mechanics right now.

Note that Ryuuhi is facing to his LEFT on all the images. This means that, besides states, it is important to define the state’s direction too.

Action #1: Walking

Walking is fairly easy on flat terrains, since it only changes the sprite’s X coordinate while you hold Left or Right. Just as a note, when you press the opposite direction, the Ninja goes from Walking -> Turn -> Walking (opposite direction). It’s important now to define how he collides against walls, so we need to understand what a collision box is:

The Sprite Frame is the actual image that I am drawing on screen, while the Collision Box defines how the ninja interacts with the terrain. In this case, it’s important to understand how the two different boxes differ. It would look really bad if I used the sprite frame as a collision box since Little Ninja would “bump” against walls from a faraway distance, which is not what we want:

Now that’s more like it, right? Basically what we need to do is find out what tile is next to the Ninja, depending on the direction he’s facing. If said tile is a Solid wall, then it means that he cannot walk. If not, then he can walk through (if you want me to explain a little further let me know).

Anytime you press the Left or Right directions, he changes his state from IDLE to TURN/WALK. We then ask if he is able to walk in said direction, and if so, his X-coordinate changes.

Action #2: Jumping

Jumping is a trickier than walking, since jumping (in reality) is not a linear function because of physics (read: gravity). The jump starts fast, and slow downs towards it peak until is starts to fall:

Applying a real physics formula is possible, but most platform games just use a small number of linear formulas (and so does Little Ninja) since the result is more predictable and it actually looks better. Games usually have an extended hang-time, the “floating” feeling and, as you can guess, this the case of Little Ninja too.

Anyway, I recorded a GIF of the actual game running:

(For those using Internet Explorer, the GIF probably runs a little slow, please use Firefox if possible!)

Anyway, the animation above pretty much wraps up everything I explained and more: I didn’t get to explain collisions against the floor and falling.

Little Ninja is finally moving and that’s it for today, next time we’ll probably see him hanging on the wall and walking on slopes. Hope you enjoy the article!

The game will sport a very japonesque look, featuring a lot of rocks, rivers, waterfalls, exotic trees, and cerulean skies. (Which pretty much renders our “keep it simple” useless…)

As for Ryuuhi, I still haven’t fully decided on the final look he will have, but he now has several animations, all running at full 30 fps. I swore I would never animate anything at that rate again after Wind and Water. But oh, well.

I also made this new tileset so that the engine Hao is making will look prettier, but he hasn’t even used my old new tileset!! Anyway, here it is.

Well, that’s it for today. Tomorrow I’ll keep experimenting with the animation. This project is advancing much faster that I expected, and I had a lot of fun playing with Hao’s preliminary engine!!

If you remember last time, we were in the process of  defining what was important for Little Ninja’s new Map Editor. If you haven’t read the last article, it’s a good idea to take a look at it since I’ll be taking off right where I left it

Map Terrain Design (Part 2)

Last time we were overviewing the different terrain angles. After taking a look at my favorite platform-adventure games, I decided to keep three types of angles, remember?

One may think that most platform games have a wider array of possible angles. However, in fact, I came to realize that a great number of games only use the 45° and ~26° inclination — Cave Story or Metroid, for example.

Now that I have chosen the three types of angles, it’s time to choose the different terrain directions. Fortunately, this is a very easy choice as tiles can only be transformed (rotated or flipped) into four different configurations, creating the following set of tiles:

Now that we have terrain type, angle, direction, we’re all set to start making our Map Editor™ ! Before starting, let’s do a test-run on our current terrain:

As you can see, the combination of tiles allows a quite versatile design, while keeping it “simple”. While our Ninja trap does not look too smooth, remember that this is our mask! Further addition of foreground tiles will do the trick, believe me (I can’t wait for Yuan to give me some tiles). Actually, Yuan has already started drawing the prototype sprite art for Little Ninja.

Map Terrain Structure Overview

So, let’s review what we have until now: each tile contains information about direction, angle, and type of terrain. From a technical side, I decided to use:

2 bits for direction (2 ^ 2 = 4 combinations)
5 bits for angle (2 ^ 5 = 32)
5 bits for terrain type (2 ^ 5 = 32)

That gives us a total of 12 bits. In order to fill 2 bytes (that is, 16 bits), we have 4 bits left: we’ll use them for special cases. So, what’s a special case? I don’t know, and that’s exactly why I’m saving those 4bits.

For now, the only important types of terrains are empty and solid tiles (character collides against them), with all the variation of angles and directions. This is my tile palette for now:

Our transparent color is always magenta (aka: ugly pink), but from now on I’m probably not gonna use it because, as the name implies, it IS ugly. Anyway, our Map Editor’s interface is quite simple: a simple editor where you choose the width and height of the map, select a tile from our tile palette, and draw tiles on the actual map!

Anyway, the editor is finished (for now) and here’s a video:

Oh, I also added a grid as well as a foreground grid. Nothing complex but certainly useful. The Save and Open functions are crucial since we need to load the map on the actual game code. It’s just a simple file with information about each tile, as well as the width and height of the map. I’ll be using my test.map for the next part.

Anyway, that’s it for today. Next time I’ll be loading the actual map on the game, and start adding the most basic player controls (walk and run). The current map editor clearly needs a lot more work, but that will come later

What do you think about it? Please let me know if the post was too long or simple, etc., or if I should describe the programing-related issues more clearly. Thanks!

Back on the drawing board, we decided to make a “small” game project which we could handle leisurely. So we chose to expand one of our previous projects, namely “Little Ninja” or “Shounin Ryuuhi”, a Ninja platformer.

First of all, I took the original main character and did an overhaul so that he would still be small (which is the idea), but versatile to animate. This is the result:

I haven’t decided on the final look yet, but this is probably what I will stick to.

Also, we decided to make a new “terrain interactive” engine, and we chose the following angles for tiles:

This is because a 45 degree angle is a perfect one-pixel diagonal line, and the other ones are perfect two-pixel diagonal lines. Any other irregular lines will need too much work to look elegant. This is a preliminary tileset to make the map editor a little easier on the eyes.Instead of just “pasting” the character on top of any terrain, we will make him really interact with it. So the little Ninja stands and acts differently depending on the inclination of the plane:

Finally, I made this “Stick Ninja” to test the animation flow and interaction. His name is Chopsticks the Ninja™. Having so much terrain interaction means a LOT of animation on my part. So there goes our “simple” game project…

As you probably noticed, Wind and Water: Puzzle Battles for Dreamcast was released early this month, so we decided to start a new simple platform-adventure game, codename: Little Ninja!

Since Wind and Water was a very extensive and ambitious project, we want to keep this one simple. We’re mostly focusing on engine development, programming, scripting, as well as graphical issues that need to be resolved. Little Ninja may become the stage for our new big platform/adventure project, but for now, we’ll try to keep it simple, and we really hope this time we don’t mess it up We’ll be documenting the whole development process, both from my side (programming), as well as the artistical and musical part — Yuan’s part.

What is Little Ninja anyway?

少忍龍飛 (Shounin Ryuuhi — Young Ninja Ryuuhi) is an old Yuan Works project:

That’s an old screenshot taken from the Yuan Works website. We’ll be remaking it from scratch, but the basic idea still applies.

Map Editor and Tile Design

Before starting to program directly on the game, there are several tools that need to be done beforehand. Fortunately, all animation and image editors used for our past project were dramatically improved while we were working on Wind and Water, however, one of the tools that is not too flexible is W&W’s map editor:

Wind and Water does feature a map (usually compared to Super Mario Bros 3), but we need something more complex this time. It’s time to design a map editor then!

First of all, most, if not all, maps contain two important parts:

Tile graphics contain what you actually see on the screen (the visual part). More like a geographical map. This includes background, foreground, animated tiles, etc.

Tile information contains how the characters interact with their surroundings: where they walk, items they grab, etc. Like the political divisions.

Tile graphics vs. Tile Information

For now, the visual part is not important, after all, that is Yuan’s work. We’re here for the Tile information, what I like to call the map’s mask (Note that I am using the term mask in an incorrect way, but that’s the way I like it. In a metaphorical way, the idea of the mask still applies… at least for me!)

Anyway, in the above example, the red part represents the main character’s sprite location, the green part represents a collectible item, while the orange one represents an interaction (in this case, a sign). On a final version of the map editor, these are important bits of information, however the part that I’m most interested in right now is the blue one — the map’s terrain information.

Map Terrain Design

For now, let’s focus on letting the character walk, jump, fall, and so on, since starting from anywhere else would be pointless (there’s no use on letting the character slash enemies without knowing where to walk). For Little Ninja, we’ll be using tiles of 16×16 pixels, so my first constant inside the project is

MapTileSize = 16

Instead of using the number “16″, I’ll use the constant MapTileSize. This way, if we’re creating another project or we decide to change our maps to say, 8×8 tiles, we just need to change the constant. Basic stuff, but incredibly useful.

As for the terrain information let’s have a look a the terrain types I thought of so far:

From left to right: empty (character can walk or jump through), solid, platform (same as solid but the character can walk through), water, and spikes (instant K.O. — like Megaman). I’m not 100% sure if spikes should be an actual terrain type or not.

Now that we have terrain types, we need to be able to create hills and slopes, or we will be rewinding videogames back to the Mario 1 era (not sure if it’s good or bad though):

Here are some slopes I thought of. From now on these are the terrain angles. I’m guessing it’s not too important to have that many different angles, so I’ll only be using 45°, ~26°, and ~63°. I’ll leave it open just in case I need more.

Anyway, that’s it for now. On my next post I’ll begin with the map editor and hopefully take a video of how map editing should be done. Don’t forget to subscribe to our RSS feed or email, and stay tuned for Yuan’s post on the art side!