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:
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:
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.
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.
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:
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:
And a 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:
Meanwhile our concept guy was busy cranking out more drawings.
Here’s a bit of a milestone. Our favorite character:
And a hawk was added:
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:
Clearly backgrounds were needed. Here’s more concepts for that:
The terrain was looking pretty crappy so we switched to 3D models for them. Here’s some 3D modelling tests:
Then background elements were created. These are drawn as sprites in the engine:
And powerups:
Putting it all together gave some really good results:
Some HUD work being done:
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!
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.
- 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.
I thought I’d take some time to highlight the absolute greatest feature of the Donkey Tech 1 (DT1) engine… the visual scripting system.
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
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:
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.
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.































