Oct 13

It’s now been over two weeks since we submitted Tap-Fu to Apple so hopefully it’ll be out soon. In the meantime we’ve started Chapter 2. Here’s Seelan’s post about it:

Chapter 2 character at Touch Arcade

Oct 01

We figured it would be fun to post the evolution of Tap-Fu photos. It’s interesting to look back and see how the project evolved and the thought processes we went through.

The very first idea for this game came from us playing around at Virtual Apple – specifically we were reminiscing about Karateka

We were thinking that it would be great if we made a clone of it. Back in the day it was one of the most impressive games around so we had a soft spot for it. So we made a quick animated gif of the character walking so we could get an idea of how much animation would be required:

Karateka Sprite

Once we were sold on the idea, we contracted out an artist to do some character animations. Based on our input, this is among the first set of sprites that we got back. The sprites were generated from a 3D animated model with the intention of painting over them later on.

First Prototype of Tap-Fu

First Prototype of Tap-Fu

First Prototype of Tap-Fu with 3D ground plane

First Prototype of Tap-Fu with 3D ground plane

It wasn’t quite what we wanted, so we decided to explore some alternatives for a while. So we let our art designer (Rain Park) go nuts. He was only at it for a short time, but what he came up with was beautiful.

Initial Concept Art

Initial Character Concept Art

Boss Concept Art

Boss Concept Art

Since at first the game was more serious (like Karateka) the direction that we gave was mostly in that direction. Then one day Rain sent us this:

First Cartoony Character Concept

First Cartoony Character Concept

Needless to say, we were totally convinced that a less serious game was the way to go. Here’s some animation guides that he came up with:

Animation Guide

Animation Guide

Animation Guide

Animation Guide

And a background concept:

Background Concept

Background Concept

Initially we were thinking that Tap-Fu would be more of a platformer and that the Hero would start off in a town. The town is what is pictured above.

Since we decided to go for a more cartoony look, we needed a new art style. We are fans of the old school sprite games so we found another team of artists that were available to do some sprite work in Montreal. They took the concept drawings and came up with this:

First Character Sprite

First Character Sprite

Meanwhile our concept guy was busy cranking out more drawings.

Bandit Concept

Bandit Concept

Ninja Concept

Ninja Concept

Another Bandit Concept

Another Bandit Concept

Background Color Test

Background Color Test

Boss Concept

Boss Concept

Architecture Concept

Architecture Concept

Trainer Concept

Trainer Concept

Here’s a bit of a milestone. Our favorite character:

Female Ninja Concept

Female Ninja Concept

Female Ninja Concept

Female Ninja Concept

And a hawk was added:

Hawk Concept

Hawk Concept

Around this time, the level and tech design started getting a little bit bloated. Since we were doing a platformer, we realized that there was still a ton of work ahead. In the interests of getting the game completed faster, we decided that we would shift the project from “Tap-Fu adventure” to “Tap-Fu Arena” and focus on smaller levels. This would greatly simplify the AI and gameplay and would probably be more fun. A few weeks after that we put in the story mode which was a nice balance between the two.

This is the first time we put sprites in the game:

Sprites in game

Sprites in game

Clearly backgrounds were needed. Here’s more concepts for that:

Background Concept

Background Concept

Background Concept Test

Background Concept Test

The terrain was looking pretty crappy so we switched to 3D models for them. Here’s some 3D modelling tests:

First 3D Ground plane

First 3D Ground plane

Better 3D Ground Plane

Better 3D Ground Plane

Then background elements were created. These are drawn as sprites in the engine:

Props Concept

Props Concept

And powerups:

Candy!

Candy!

Putting it all together gave some really good results:

Starting to look familiar

Starting to look familiar

Some HUD work being done:

HUD Test

HUD Test

After all of this, the rest is mostly just polish. Sounds, from our sound guy Dan,  were added. The HUD was finished. The menu system became fully functional. A little bit of music was added to the title. Hundreds and hundreds of gameplay tweaks to get it perfect were done.

We hope you enjoy it!

Sep 30

Here’s a thread about Tap-Fu at Touch Arcade:

http://forums.toucharcade.com/showthread.php?t=27527

Sep 29

Here’s some interesting tech facts about Tap-Fu:

  • Created from scratch over a 5 month period
  • 443 individually crafted character sprites (128×128 each) in 7 1024×1024 textures (loaded as 16 bpp). No PVR compression on sprites.
Full Tap-Fu Sprite Sheet

Full Tap-Fu Sprite Sheet

  • Environment textures are all PVR compressed (4bpp). Six 512×512 and four 1024×1024 textures.
  • Main theme 0.6 MB .caf file. Streamed from file.
  • 87 unique sounds. Uncompressed .wav (PCM) files with varying bitrates tweaked by hand. Steamed from file via OpenAL
  • Streaming levels (for story mode)
  • Engine is 100,000+ lines of code. Game specific code is 10,000+ lines.
Sep 29

I thought I’d take some time to highlight the absolute greatest feature of the Donkey Tech 1 (DT1) engine… the visual scripting system.

The Visual Scripting System in DT1

The Visual Scripting System in DT1

Many developers seem to be steering towards integrating Lua, Python, etc into their game projects with the hope that it’ll streamline the game creation process. I did it too. An earlier version of the engine had full Lua support. The problem is that it still forces much of the game logic on to a programmer instead of putting it where it should be – with the artists or level designers.

I decided I’d try and develop a visual, node-based, scripting system that would easily allow anyone to define complex relationships between entities in the game. Since we were targeting the iPhone it also had to be very efficient as well.

The solution looks like this: By linking the nodes together you form a graph that performs the operations that you want to do. Nodes are lazily evaluated – i.e. if you need the value of a plug at the end of a chain of nodes, all of its dependencies upstream of it are evaluated first. this is key to its efficiency.

So what does this look like in C++? In a nutshell, all a class has to do is inherit from a PlugNode base class and define it’s member functions much like this:

Plug<Vector3> _position;
Plug<Matrix3> _orientation;
Plug<TWfloat> _scale;

There’s an initialization function a little later in the .cpp file that looks like this:
PLUG_INFO(_position).Init("Position",PLUG_OFFSET(_position),plug_node_info)
.Affects(PLUG_INFO(_world_position))
.Affects(PLUG_INFO(_world_orientation))
.Affects(PLUG_INFO(_world_scale))
.Set_Input(true)
.Set_Output(true);

PLUG_INFO(_orientation).Init("Orientation",PLUG_OFFSET(_orientation),plug_node_info)
.Affects(PLUG_INFO(_world_position))
.Affects(PLUG_INFO(_world_orientation))
.Affects(PLUG_INFO(_world_scale))
.Set_Input(true)
.Set_Output(true);

PLUG_INFO(_scale).Init("Scale",PLUG_OFFSET(_scale),plug_node_info)
.Affects(PLUG_INFO(_world_position))
.Affects(PLUG_INFO(_world_orientation))
.Affects(PLUG_INFO(_world_scale))
.Set_Input(true)
.Set_Output(true);

What does all of this do? In a nutshell, the Plug template wraps the primitive type in the logic for maintaining the plug state and connections while making it behave much like a the primitive type. PLUG_INFO is simply a macro that is the object that contains static information about the plug (like name and flags). this information is constant for all of the instances of this node type. The Affects statement defines which inputs affect which outputs which is necessary in tracking dirty states for the lazy evaluation. Set_Input and Set_Output are just flags that say whether the plug is an input or an output.

I realize that details are a little scarce here. It’s meant to me more of an introduction that an exact how-to.

What kind of things can be done with this system? Well, as it turns out, a lot! Here’s a few examples:

  • The camera rig: The players position, with an offset added and going through a smoothing node to the camera’s position.
  • Opening doors: A player enters a zone which causes a timer to increment which is connected to the y-position of a door.
  • Cut scenes: All of the cut scenes in tapfu use this system. Switching between cameras, playing sounds, messages, etc.
  • Particles: Particles are completely defined by this system with new behaviors chained up in series.

All of this stuff can now be driven by an artist instead of a programmer. So if you are a programmer, do yourself a favour and implement something like this now! You won’t be sorry :)

Sep 28

I thought I’d make a few posts about the tech behind Tap-Fu. Tap-Fu was the fist game released with our game engine (Donkey Tech 1) that has been in development for several years already. The engine boasts a long feature list with a lot of cool stuff:

  • Fully customizable editor written in wxWidgets
  • Extensive Visual scripting system featuring lazy updates
  • Asset packaging system
  • Fully integrated and flexible GUI system
  • OpenGL, OpenAL, and SDL support
  • Flexible file format support for WAV, OBJ, 3DS, PNG, PVR as well as many optimized (and proprietary) formats.
  • Hot loading with all resources.
  • Sprite and Bone (GPU skinning) animation systems
  • Streaming audio sound effects with OpenAL. Streaming music system with Audio Queues or SDL
  • Streams both ASCII and Obfuscated Binary file formats for reading and writing level data. Save anywhere is fully supported.
  • Built in networking for multiplayer games over UDP. Full network serialization. (WIP)
  • Brush/BSP based level design (WIP)
  • Integrated profiling tools
  • Pluggable Renderer. Deferred shading renderer on Mac and PC enables hundreds of dynamic lights. Shadow map support
  • Hardware Shader Support. Normal mapping, Parallax mapping, etc.
  • Modern C++ programming methodology.
  • Supported platforms include Mac OS X, Windows, and iPhone
  • Very flexible particle system
  • Multithreading support including lock free container classes.
  • Unit testing framework
  • The DT1 editor

    The DT1 editor

    Using this technology, the Prototypes for both Tap-Fu, Relativity, and a few unannounced titles only took a couple of hours. This includes a full menu system, a customized level editor, save/load and a whole bunch of other features.

    Stay tuned for a few posts about some of these specific areas. There’s some neat lessons to be learned.

    Sep 26

    Well, I’ve been pretty busy lately. I’ve teamed up with the 7 cities guy to create our latest game called Tap-Fu. It turned out AWESOME!!

    Here’s the official page for it: Neptune web site

    Here’s a thread at Touch Arcade: Touch Arcade

    There’s not a whole lot about the game right now – it’s coming soon.

    preload preload preload