In the last post I started some of the rocky terrain that will be found in the game. The following tileset is a rather traditional approach to drawing a rocky “square” landscape in a stage:

If you look closely, you will notice that some of the tiles repeat themselves periodically. This helps the game save memory and at the same time creates a very comfortable “tile loop”. As you can see, those two lines of tiles are exactly the same.

The trick is making them connect smoothly. To give even further variety, many tiles can be replaced with different looping tiles which serve as matching pieces. They can also be combined differently to avoid a constant look! For instance, we can edit some of the tiles to make a secret entrance more obvious to an observing player without compromising the look of the game.

By making nice-looking and flexible tilesets with many unique features, we can make terrain that obeys all the classic video game rules and limitations, but still manages to breathe life to the different locales of the game.

The screen in a traditional 2D video game is generally divided into smaller pieces called tiles. These tiles are often 16×16 pixels, although other sizes also exist. Here’s an example:

Familiar, isn’t it? Many Famicom/NES games looked like that. In this image the tiles are pretty obvious, but there are several tricks to make them less apparent. One of them is creating fluid loops where it is hard to tell where the tiles join. Consider the following rock tileset I made for the game:

When I join them together it is very difficult to tell that they are tiles, and not a continuous drawing:

See? This makes the individual tiles much harder for the eye to spot. It also gives a natural feel to the game, instead of a blocky checkered look. You can even make a nice cycle with just one tile. Practice and a little experimentation is all you need.

Something that also helps camouflage the tile-look is giving a little depth to the tiles. For instance, I can draw the top of the rock to make it look like it isn’t absolutely flat:

Of course, these tiles are for cosmetic purposes only. Ryuuhi cannot walk on top of them. They only serve give the illusion of depth. This way we respect the engine but cheat a little bit visually.

As a result, we get a flexible, natural looking tileset that matches the style of the game without compromising the elemental engine and saving memory. It is also a good idea to take on or two tiles and make some kind of landmark, or special feature that will not only make a certain part of the map unique, it will also help a player recognize where they are. But more on that later!

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!

Unfortunately, this approach requires a lot of observation and time to draw. For instance, this tree branch was “constructed” very much like a real branch. It has detailed individual leaves and is irregular and full of accidents. This gives it a much more organic feel.

Notice how it almost looks like the branch actually grows in the construction. The same is applied to the rock patterns that I’ve been drawing for the game. In nature, they don’t shape up chaotically, but rather in very complex ways, and you’d need advanced mathematics to calculate them. This actually means you have a lot of freedom to draw freehand and imagine the geometry any way you want because nobody will know the difference, but remember to keep the light source consistent!

In normal tile-based games these details are usually stylized into a generic shape, giving it a more anime look, for instance the trees in 2D Zelda games. Here’s a tree I worked on for a former project. The advantage is that it is easily recyclable and fits perfectly into any 16×16 tileset, making it very comfortable to implement into map design.

This game will actually be a combination of both, but there will be many visual treats to make every single surrounding unique.
Well, that’s it for today. Merry Christmas to you all!

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!

Notice the two frames marked with an arrow. They are extra ugly frames that not only look bad, they don’t let the motion flow correctly/convincingly. Not that 0.05 seconds of screen-time are particularly visible, but we want to make this look as good as possible, don’t we?

Also, when you’re animating something, if you detect/suspect any errors early on, it’s important to correct them right away. Otherwise they will haunt you, turn more difficult to correct later on, or in worst scenario generate even more errors.

I also made a slash animation:

This kind of motion is not found in nature or traditional animation. And the way it is animated is exclusive to pixel art. With this kind of “special effects”, you have the freedom to experiment a little, but keep in mind the timing of the movement. Remember that is has to be functional in a game!

I have some more animations, but they’re too long to post here!

But as a bonus, I corrected one of the aforementioned frames while writing this post:

Looks much better, doesn’t it?

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…