Special effects!

Have you ever wondered why next-gen games are so much more appealing than the old ones on consoles like N64 or PS1?  You may answer: That's because they run on more powerful machines.
And that's true, but that's not what makes the difference.

If you take an N64 game and port it as-it-is on the more capable Wii, it won't look any better than it did
on the old console. (That's why virtual console games have basically the same graphics of the original games).

To make a N64 game look like a Wii game would require a lot of work of replacing old textures with more detailed ones (at better resolutions which new consoles are capable of), and making more high-poly models. But what really makes the difference are shaders.

What is a shader anyway? Newer consoles have something called programmable video cards, which means programmers can directly tell the video card how they should render models, which wasn't possible on older machines. The standard behaviour would be to leave the vertex positions as they are, and render textures in a standard way. With shaders programmers can change this behaviour, for example by animating the position of models vertexes or blending the texture with an arbitrary color. More advanced uses are projections to create water effects, blur, bloom, fur and much more!

Here's some actual examples from some of my favourite video games:

In "Conker's Bad Fur Day" for N64,
Conker's fur is just a flat texture.

In its remake for XBox shaders are used
to achieve real fur effect.

In "Paper Mario 64" you can see the quality of
textures allowed by N64.
In its sequel for Game Cube, the machine
allowed better resolutions and
more characters on screen.

Back to Bombs & Penguins, one shader effect I'm currently using is rim lighting. If you have ever played Mario Galaxy, it's the effect it heavily uses to reproduce a "light on edges" effect. I'm also using a fur effect (but without shaders as I'll explain later) on this ugly bee (probabily the first boss you'll have to fight):

Fur on the right, rim lighting on the left.

Fur is achieved simply with a noise transparent texture duplicated and scaled in different layers. The result is not bad, but it could be better with shaders. However since I'm still a shader-noob and from game view fur is only slightly noticeable, I may leave it this way :)

Istead, I'm using a Cg shader for rim lighting. Reproducing this effect is simpler than you may think:

Here's what the shader does: it calculates a vector wich points from object vertex straight to camera position. Then it does a dot product between the two. If this product is near to 0 it means it is on the last part of the model the camera can see (In the example above Vertex Normal * Vector Camera = almost 0). If the dot product is positive it means the camera can clearly see that part of the model.

The shader outputs the texture color when this dot product is positive, and outputs white when it's near to 0 doing a linear interpolation to smooth out the effect!

So here's how you would do this in Nvidia Cg shader language:

Vertex shader:
 //Calculate dot product in [0, 1] range
l_faceQt = pow( 1.0-saturate( dot(vtx_normal, normalize(mspos_cam-vtx_position)) ), 2);

Pixel shader:
//Interpolate between texture color and backlight color
 float4 tex = tex2D(tex_0, l_texcoord0);
 o_color = float4( lerp(tex.rgb, k_envirLightColor.rgb, l_faceQt) , tex.a );


Out of bombs?

Last week I did some initial work on the user interface of game levels, which may still receive substantial changes as I add new gameplay features thought. Playing the first prototype of b&p I've also realized that I had to limit the number of bombs you can throw against falling objects. Obviously if you had an infinite number of them, it wouldn't be so fun, right?

But the question was.. should I just put a maximum number of bombs the player has to use wisely or should I think something else? At the end I came up with a "bomb bar" which I think is a bit more intuitive. It slowly decreases if you throw bombs too frequently. So you do have infinite bombs, but still you cannot throw them too fast. :)

The bomb bar slowly recovers if no bombs are thrown for a small amount of time, but if you want it to become full in no time you will have to get one of these bomb boxes!

 And here's a small screen shot of the first ui:


When game programming books are useful

While I was working on Bombs & Penguins I ended up being quite satisfied with the visual and gameplay elements of the game, but I couldn't really say the same to the programming architecture I came up with.

With bombs and penguins I did my first attempt to create a "game engine" in C++ in which all the library I used could fit nicely, and I may say I both succeeded and failed in this intent. I succeeded because everything was actually working fine and failed because everything was slowly getting messy and difficult to mantain as I wrote new code :)

It is true that every architecture you build/use will have some trade-offs, but I needed a better base to build my game. That's why I decided I would buy the book you see in this post and after reading it, it definitely taught me how a good architecture should be made.

That's why I decided to rewrite the game code for bombs & penguins from scratch following the model proposed by this book. Of course, I didn't copy the code proposed in the book as it is, and that would be quite pointless I think, but instead I took inspiration from it and built a much better and efficient game engine than the old one. It took me about two weeks of coding, but it was worth the pain! :)

This isn't a review of game coding complete, but I do recommend reading this book to any game programmer wishing to build a solid base for their game!

I also rethought the role of Lua scripting language in my game. Before I was using it to code the gameplay elements, but now I'm using it more as a replacement for XML to load levels and elements. That is because I program alone and I do not have any scripter working with me, so why spend a lot of time trying to fully integrate scripting in my game? I realized it's quite a waste of time in cases like mine :)


First screenshots!

I'm back!
I've been working hard on bombs & penguins lately and finally some visual result is starting to showing up :)

There are still a lot of missing assets, but all the core gameplay elements are already up and working:

This is a test level in an almost playable state. Can you guess how the gameplay will be? :)
The answer is pretty simple: You control a little penguin and you have to help him "survive" on the platform he's standing on, that is, running back and forward trying not to get hit by some falling objects!
That's not all: you will have to throw bombs at them, as they will destroy platform pieces if you let them touch the ground.

This is what the gameplay will look like, even though you can expect a lot of additions in the way yet to be done :)  (A variety of levels, and even a multiplayer mode)

And this is a small level editor I developed for this game:


Creating a game

Creating a video game is no easy task.

My interest towards videogames began when I was a little child and I've always been curious about how I could move around a 3D character, how that magic "virtual world" was actually built.

And this interest soon lead me to game programming and game design. Now that I have experience with different frameworks and tools that can be of help in creating a game, I would like to focus on an important part of a video game: the "game engine".

This term is actually a bit too general, because a game engine is made of multiple parts (or even multiple softwares) which do different tasks. There's a software for rendering 3D scenes, one for input (keyboard/joystick) control, one for physics to move things around, one for audio and many other could be added.

There are sometimes softwares that handle all or part of this tasks and are thus referred as "game engines", but many other do only one or two specific tasks and a programmer would have to choose which one to use and build a personal "toolset". (This way usually gives a better range of choices amoung different options, but is a bit harder to implement)

Here's a list of some of the software I used with their cons and pros in my opinion. :)

Panda3D is a software which takes care of 3D rendering, physics and audio and requires an avarage programming knowledge with Python.

Python is one of my favourite programing languages so I gave this software a try as soon as I found it. And it was a really good experience!

  *It uses python :)
  *It handles physics, audio and rendering out of the box
  *Very high flexibility and fast development times
  *Very good for rapid prototyping

  *Little choice on which library to use for GUI, Physics and audio.
  *May not be as fast as other rendering engines.
  *DirectX is poorly supported compared to OpenGL

Ogre3D is another top quality open source library for C++ which, however, handles only 3D rendering. This is not necessarily a bad thing because it gives you the chance to freely choose other libraries for the other tasks required by a videogame.

The programmer will have to write "glue code" to integrate Ogre with other libraries, which may require a bit of work in C++, which maybe isn't the friendliest language for beginners. :)

  *Extremely fast and reliable
  *Well structured and very nice to program with
  *Support of a wide range of shader languages
  *Seamless support for DirectX and OpenGL

  *A bit steep learning curve (May be confusing at first)
  *Slower development times compared to Panda3d (Because of C++)
  *Not suitable for rapid prototyping

Blender is an open source software for 3D editing and animations. It's a great alternative to expensive and commercial products like Maya3D.
But it's more than this. It also has its own "game engine" which requires no programming experience at all.
All the game logic is handled by "logic bricks" which are extremely easy to use. For more difficult tasks, there's a python api available.

  *Easy to use (No programming experience required)
  *Excellent for rapid prototyping
  *Very good for beginners.
  *Handles everything out of the box

  *It uses a quite slow and outdated engine for rendering
  *Definitely not a good choice for big projects
  *Logic bricks can get messy and slow for larger games

Similiarly to Ogre3D, Irrlicht is a rendering engine programmed in C++, but it can do some basic collisions and GUI.

I've not worked much with this engine so I can't really state its pros and cons but here's how this engine looked like:

  *Easy to use (Compared to other C++ libraries)
  *Reliable rendering engine
  *Support for GUI and physics out of the box

  *Does not support important shader languages out of the box (Cg)
  *Slower rendering compared to other engines
  *Its structure can become troublesome for bigger projects


blog launch


I've decided to use this place as development blog for my future projects (usually 3D Puzzle and Maze games).

I'm currently working on a new title which I temporarely named "Bombs & Penguins", and it is slowly taking shape although I've nothing to show off yet.

Even if the game itself is entirely written in C++ using libraries like Ogre3d for the graphics and Newton game dynamics for the physics, I'm creating many small development tools in python. (A level editor, a local bug tracker and so on)

Python is just impressive for this purpose, as I can come up with results which would have taken much longer if done in pure C/C++
Most importantly, it is my favourite scripting language :)