Post feature RSS Programmer: Carlos García Cordero

Interview with the members of the development team at Rebel Act Studios.

Posted by on

Programmer: Carlos García Cordero

I studied Mathematics in the Complutense University of Madrid, when I finished I taught programming in an academy for other Mathematics students and translated several books from English to Spanish. This does not mean that I have a good English, those books were technical ones and their English was very easy to understand. At that time, about five years ago, I had a friend who knew that Friendware was forming a development group for creating videogames, I had always liked videogames a lot (a friend and me did a videogame for the spectrum that was almost published), and so I got in touch with them.

Click to enlarge!I work with two monitors, that's the reason why the image is so wide. In the left one you can see the game window, i turned on toon render to make it a little different from most of the screen shots that you can see. Visual C++ is under it. In the other monitor is the game console and PythonWin that is the editor I use to edit Python files.

I saw a demo of an Intel product that did toon rendering and liked it a lot, later I read an article in game developer about that and decided to implement it in Blade. The basic algorithm for shading is based in the one that appeared in game developer, the rest are experiments I did. I'm quite pleased with the result. It's done at the raster level; the rest of the engine doesn't know anything about it. This limits a little the information that I can use to implement different effects; I don't want to slow the normal rendering to improve toon render. Unfortunately now I have very little spare time, we are working extra time to finish Blade. I was thinking about implementing a watercolour look, but this, as well as a line-shading mode that is half done, will have to wait until Blade is finished.

I don't know if it will be released. It's only implemented in the OpenGL raster. Blade has switched to D3D for commercial reasons and as I do this for fun, I'm not going to port it to D3D. Maybe the OpenGl raster will be released as an unsupported option (it has other extra stuff also), but I can't promise anything. It is a little more difficult to play in toon mode because you tend to look around to see the environment and when an enemy attacks, you are still looking at it saying "Its very cute!!"

In the PythonWin window (the right part of the desktop) you can see a tree with the classes and functions of that file. This file defines the basic behaviour of the non-player characters. There is a class for every type of enemy, in this file is one of the most basic classes. These classes define the call-back functions that are triggered when something happens (the character has been attacked, has seen another entity etc.), the derived classes refine the behaviour. For example, the function RespondToHit is called when the characters have been hit and launches the appropriate hurt animation, decreases the life etc.

I have done a lot of things in Blade, after all, I've been here for quite a while. I've done several tools, including the LED. I did the port to Windows (the first engine run in DOS) and I've done almost all the Glide raster and all the OpenGL raster. In the game I've done a lot of internal work. I did the entities system with their attributes and methods (well, I did the first ones, other programmers have completed it), added the scripting module with Python and the first scripts (mostly as examples), several graphic effects... and a couple extra things that I don't remember or I prefer to forget :).

The LED must be updated. It was done a long time ago and has only had a couple of bug fixes since then. The 2D/3D integration must be improved as well as the entity treatment. When the LED was done, the script system wasn't finished (by the way, the LED has a script interface, which I did as an example to see how it worked and if it was adequate for Blade) and the entities system was still in design. Although it worked very well on my Pentium 90, we have Pentium III 500's and up now, and it could use the extra power.

There are also a couple of features that have not been tested much, like hierarchical grouping. There is a Depeche Mode icon to activate the grid, I think that Enric would like it if I improve this and add an MP3 player to listen to Depeche Mode music. I think that Prodigy would be OK too :).

We use Max for the objects, Angel did an exporter to use the objects in the engine. I did a tool to Pack textures and calculate palettes, which is called BaB. Angel and me also did a compiler (well almost everything was done by Angel) that converts the maps that LED produces into the maps that the engine understands. The scripts are written with any text editor. As you have seen I use PythonWin, other people in Rebel use Visual C++ or any other one that they prefer.

You can play Blade in first person, so the engine is not tied to a 3rd person game. Most of Blade behaviour is done with properties or Python scripts. The engine is very flexible. I think it has the best physics and lightning system, as well as a very flexible biped system for animations.

The engine has several sub-engines. The physics engine is one of them. It uses mainly the mesh of the object and its mass, but there are also friction coefficients. The code for the physic engine is in the main executable, as is the entities system. So maybe we can call them the core. The graphic system is in separate DLLs. It's possible to write a raster that shows the world in a completely different way, as the toon render shows. It's possible to write a raster that uses light maps, for example.

It's also possible to implement entities behaviour or other things in separate DLLs, although we do not use this very often. You can use Python as a link to call any DLL if you want.

The geometry is tessellated for the distortion effect, but the objects aren't. Their vertices are moved depending on where they are; this is why you sometimes can see that their distortion is not the same as the rest of the architecture. This is done this way to improve the efficiency.

The water has attributes for setting the level, colour and reflection. You can also specify a callback function that is called when an entity touches it. There is also a transparency attribute, but although Angel designed it to have transparency, he hasn't had the time to implement it.

Blade does not ask a lot of the graphic card. For example, a GeForce is almost free to run with full screen anti aliasing. We have tried this and all the cards work well with Blade.

In short term, it would be easy to add Radiosity and volumetric fog to the Blade engine (we almost have volumetric fog already). In a long term, we may add a true outdoors engine, progressive detail-level, more authentic lightning...we'll have to wait and see.

I don't know what we'll be releasing, but to create new models you'll need the MAX export plugin. Also, you have to define the set of animations by script. If it's not documented, this will be very difficult. To change the damage that a weapon produces you only have to put something like this: weapon.Damage=200. This is not exact, but this is the idea. The weapons have several attributes that are defined in a script. To change their damage zones, you must define them in the mesh and use our exporter.

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.