ゲキヤバランナー

Our game, 2 Fast 4 Gnomz just went onto the Japanese market, now it's called ゲキヤバランナー, that means Gekiyaba Runner, or "crazy runner" in other words. Our publisher is Flyhigh Works.

http://flyhighworks.heteml.jp/games/gekiyaba/

2F4G @ Nintendo 3DS

The next game that I've been working on in QubicGames was released in the U.S. and in Europe. It's actually a port of 2 Fast 4 Gnomz from WiiWare to 3DS, but as a matter of fact the game was made from scratch. The new version is greatly improved. My role was project management and programming (both engine - new QubicGames engine for 3DS platform, with stereoscopy, and gameplay). The game got really good reviews - usually between 7/10 and 9/10 - including:

• Nintendo Fuse (7/10)
• Nintendo World Report (7/10)
• Nintendo Station (9/10)
• Nintendo Life (7/10)

Some screenshots here (click):

And the trailer:

Fake Snowflake Shadow

Some time ago I was walking at night in a dense snow fall. I won't talk about my mood, but I was walking alone, nobody was around and I had some time to think, or rather to observe what was happening around. I was really excited about the shadows that where casted by snowflakes. They were dancing everywhere around, like small spiders running through the snow. Something beautiful, honestly. Of course, I mean shadows that are casted by something like street lamp. Now the problem is - how to simulate them? Of course we can cast each shadow accurately. But there are some obvious problems, and when I say problem I mean performance. I think I don't have to explain what problems are connected to shadowing complex particle system with multiple lights (just imagine the deferred shading with all those particles outside buffers, problems with transparency, or FR with multiple pass particle drawing, crazy). And also, there is some possibility, that you render your flakes (or even more possibly - rain) as post process. Sure! It is possible to do it in a straight way, but we wouldn't be game developers if we wouldn't look for some fakes ;) So how can we add some fancy shadows on the snow, that will look like drunk spiders? As you can expect, I'm not going to talk about any physically accurate solution. Look at the image first.

The upper part of the image is a 2D ortho projection of the world, the Source is our street lamp, green line is the ground. The lower part is meant to be the top-down view. As you can see, when the snowflake is close to the lamp (high), it's shadow is casted far from the center of the lamp cone, and it's movement dx1 is quite big. Then, when the snowflake falls and is close to the ground, it's movement dx2 decreases and position get's closer to the center. The situation shown here is utopia, because the flake falls straight down, with const speed. But, what it shows is that the shadow will be tending towards cone center with decreasing speed. This is a very important observation. Now, let's look at the right side. The snow is falling by some trajectory and in successive time periods it is located in P0, P1, P2 and P3 positions. The rule is quite the same, its shadow in time (T0-T3) tends towards cone center with decreasing speed, but we have to remember that this speed will not decrease monotonically, but will be varying. There even may be a situation, when T(n) is farther from cone center than T(n-1). When we look from top at the problem, we also have to add some variation in the other axis (due to air drag, the flake doesn't move straight), we can assume that shadow moves over some simple spline, directed towards S' (cone center) and with variably decreasing speed. The Lambda area is some small area around S', where shadows tend to dissapear (i think that making them bigger and more transparent would look good). You have to include this Lambda area if you don't want your shadows to dissapear suddenly. That's what I've observed in nature - flakes don't go towards strict cone center, but towards some area, because the light bulb isn't a point, but a volume.

Ok, I think that the idea is simple and obvious, so now - how can we simulate this? There are many possibilities, like:

• Particle system used only for shadows
• Post process stage shadowing
• Animated textures (even on low-end hardware, but I won't call any exact names ;P) with texture projection
• etc.

What you can take from this note is the general behaviour of snowflakes. Their movement is partly predictable (or at least its schema), and by reproducing it you can achieve some eye-candy scene.

2 Fast 4 GNOMZ

This is the second game in Gnomia world, look at the first one. While GNOMZ was a multiplayer game, 2 Fast 4 GNOMZ is an exclusively single player game, just like the previous one - made by QubicGames for WiiWare service. This time our goal is to run through the world of Gnomia to find a woman and, of course, collect socks. There are four characters that you can morph into, that's why there is '4' in the title. The game is quite indie in style and is strongly related to Bit.Trip Runner and Super Meat Boy in a matter of difficulty. Our goal was to create a game that is really a challenge, only for hardcore, oldschool gamers. My role at 2F4G was project management and lead programming. There were 11 people working on this title development, including programming, visuals and audio.

GNOMZ on the market

I can proudly say, that my youngest child - GNOMZ, was finally published on WiiWare, USA. Read more at gnomzthegame.com. You can also buy the game, visit nintendo.com

I can also say, that Gnomia is such an inquiring world, that we are allready working on another title that is going to be placed there. This has been already announced on nintendolife.com by Michał Dys, our PR fella ;)

With or without GPU, that is the question...

This post just represents my thoughts about how people get into some hi-tec trap. They know how to create some eye candy effects, like fish eye or chromatic aberration with GPU shader with 5 lines of code or less - that's cool. But when it comes to a situation when people don't have those shaders for their support, they get confused and say "that's impossible, you can not create such effects without modern GPU" and that's bullshit. A good example is the platform, that I'm currently working on - Wii. I can not say anything more technical about this platform due to some legal rights, but I can say (and everybody know it) that it's rather a low-end hardware. Let's get back to those effects that I've mentioned. You can create some approximation (simple fake, but that's what graphics are all about, ain't it?) using simple linear texture filtering - just create a grid of quads with regular mapping and distort their positions in some manner. With fish eye - just create radial distortion with strength proportional to distance from center of the grid. It looks quite good and is extremely cheap both in performance and implementation.Chromatic aberration - draw red channel on such grid with horizontal distortion with some strength, then green one with 2/3 of this strength and blue one with 1/3, mix them using additive blending et voila!

As a conclusion - this can be really simple, just don't ever think that something is possible only on new GPUs or CPUs or whatever, stay open-minded :) I think that this is quite what low end hardware demoscene is all about.

Class method as template parameter

I had an interesting problem that can be solved using a little bit tricky C++ code. Imagine a singleton that holds some pointer to a class that has many methods with identical params, but different purposes. Now, imagine you're creating some wrapper for this class in some other class (the first one was a ID3D11Device in my case, so I didn't modify it) and your code is also identical, despite this single method call. You can obviously copy paste this problem, creating n-times more lines of code. But this is an ugly solution, so below I paste the nice one. Class A is the ID3D11Device, class B is my wrapper. In my case fun1 was enough (i knew A type while implementing this), but because i find this useful - i paste code for case with unknown A type. Of course in practice, fun1 and fun2 would be big functions with this single call embedded somewhere deep.

struct A {
void a(int param) { std::cout << "a " << param << std::endl; }
void b(int param) { std::cout << "b " << param << std::endl; }
};


struct B {
template< void (A::*F)(int) >
void fun1() {
A* a = new A; // obtain A, this may be singleton or anything else
(a->*F)(1);
delete a;
}


template< typename T, void (T::*F)(int) >
void fun2(T* t) {
(t->*F)(2);
}
};


int main() {
B b;
b.fun1< &A::a >();
b.fun1< &A::b >();


A a;
b.fun2< A,&A::a >(&a);
b.fun2< A, &A::b >(&a);


return 0;
}

The only aspect that may need some explanation at the moment is how to pass ID3D11Device method marked with STDMETHODCALLTYPE as template parameter. Notice, that STDMETHODCALLTYPE is just a macro for __stdcall. We can pass this additional keyword using syntax like:

template< HRESULT (__stdcall ID3D11Device::*CreateShader)(const void*, SIZE_T, ID3D11ClassLinkage*, ID3D11VertexShader**) >
bool load_(const char* filename) {
...
}

Ok, now for the real example - the code will be a little bit more tricky, because we have to use derived template param as param for functions used as template params, blah, compliacted - look at the code :)

template< typename ShaderType >
class Shader {
protected:
ShaderType* shader;
public:
Shader() {
shader = NULL;
}


virtual ~Shader() {
if(shader) {
shader->Release();
}
}


template< HRESULT (__stdcall ID3D11Device::*CreateShader)(const void*, SIZE_T, ID3D11ClassLinkage*, ShaderType**) >
bool load_(const char* filename, const char* entryPoint, const char* shaderModel) {
...
}


template< void (__stdcall ID3D11DeviceContext::*SetShader)(ShaderType*, ID3D11ClassInstance* const*, UINT) >
void bind_() {
...
}
};


class VertexShader : public Shader< ID3D11VertexShader > {
public:
__forceinline bool load(const char* filename) {
return load_< &ID3D11Device::CreateVertexShader >(filename, "mainVS", "vs_4_0");
}


__forceinline void bind() {
bind_< &ID3D11DeviceContext::VSSetShader >();
}
};


class PixelShader : public Shader< ID3D11PixelShader > {
...
};


class GeometryShader : public Shader< ID3D11GeometryShader > {
...
};


class DomainShader : public Shader< ID3D11DomainShader > {
...
};


class HullShader : public Shader< ID3D11HullShader > {
...
};


class ComputeShader : public Shader< ID3D11ComputeShader > {
...
};

Of course you may decide to make load and bind virtuals, and to pack them into some kind of manager - this is just a design decision, whether you want to automate use of those classes. In such case design would get a little bit more complicated. My load is virtual, bind isn't. Additionally, VertexShader is strongly coupled with VertexLayout (ID3D11InputLayout), which is created while loading, so my structure looks something like this: