Jo's kitchen

Blur effect

2012-03-15T04:42:00.000+01:00

What I said in my previous post about shaders in D is sadly not up-to-date, so I want to bring something new. Here is a little project testing

Derelict3
OpenGL 3+ API
Multipass post-processing effect via shaders and render-to-texture
D builder for SCons
SCons targets

Eventually, it results as a program blurring a restricted zone of an image.

Blurred cow on a sharp photo.

Get the project on GitHub.

Environment:

install CMake
clone and compile GLFW using CMake: git://glfw.git.sourceforge.net/gitroot/glfw/glfw
obtain DevIL's libraries (packages exists): http://openil.sourceforge.net/download.php
install a D2 compiler: http://dlang.org/dmd-windows.html
clone Derelict3: https://github.com/aldacron/Derelict3.git
configure your D2 compiler to append the path to Derelict3 (in sc.ini with DMD2)
install Python 2.7 and SCons

Derelict3

Derelict3 is the new version of Derelict, a project providing wrappers in D for C libraries. It is though an alpha version, so consider using Derelict2 if you really want to pacify your boss.

The hearth of this project is DerelictGL3, which wraps OpenGL up to the latest version 4.2. I'll take about OpenGL in the next section.

In order to use OpenGL, we have to create a window and its OpenGL context. Derelict3 provides two libraries: SDL2 or GLFW3. Both are new versions in development, so once again, the code may break up at any moment. As I used DerelictSDL last time, I tried to stay on this library. That was a bad idea: SDL2 is not able to open a OpenGL 3.2+ context for now. So I give DerelictGLFW3 a try. This time it works up to OpenGL 3.3, my graphics card doesn't seem to accept any higher version. Both libraries have somewhat similar concepts, so it was not a big deal.

I finally used DerelictIL, a wrapper of the image library DevIL, to load a picture as OpenGL texture. Loading is then really easy, it only consists of a function call. Again, this may not fit to production environments, as the textures should be compressed on some low-level format which are much more efficient. But for test purposes, it comes in handy.

The wrapper code is very lightweight, it's easy to dig into files to find functions' prototype or constants. It also seems easy to make a wrapper over any library, next time I'll try that. However I regret that the files contain no documentation, and even no name for the function parameters. As they wrap libraries in development, prototypes may change compared with the libraries' official documentation. Then don't be surprise if it doesn't match.

OpenGL 3+

I was playing with OpenGL at a time where shaders didn't exist. As new versions come, the API changes, sometimes radically. As such, glBegin and glEnd are now deprecated, view and projection matrices are now handled by shaders... well, let's learn the modern OpenGL from scratch. Sadly, a lot of resources on Internet still use old methods, or a mix of old an new ones...

I don't plan to deliver for the mass market, so I target version 3.3 (but I'll understand if you target a lower version). Shaders have also to declare GLSL version 330.

My goal was only to blur parts of an image, but this can be extended to simulate depth of field for example. This is entirely a post-processing effects, so it involves shaders. The basic idea for the effect is to get a blurry version of the image, and to mix it with the original, sharp version, with a blending factor depending on the position of the pixels (in my case, it is related to the mouse cursor position). This is obtained in one pass, but getting a blurry photo itself involves two passes (explanations), so we end up with three passes: horizontal blur, vertical blur, and mix.

When involving several passes, the output of a pass shall be the input of the next pass, except for the last pass which can render directly on the screen. This is known as Render to Texture (RTT for short), indeed the output of a pass is written to a texture, which in turn will feed the next pass. RTT requires a framebuffer defining the output textures. In this case, there is only a single output, the color of each pixel, but one may also define the depth buffer or render on several textures. I don't want to explain further, a lot of tutorials already exist.

Feeding a pass with a texture eventually means simply apply the texture on a quad covering the whole screen space. I used to draw quad with four vertices, but a friend told me a simple triangle large enough could cover the screen as well, even being better for the graphical pipeline (not verified). To render faces using the new API, we need to set a vertex buffer object, an UV buffer object and an index buffer object. On top of that, a vertex array object retains the states, so it will be easier to restore them in the rendering loop. Again, I don't explain in detail, lots of sites already do. The loop is really straightforward: bind a framebuffer, the correct texture, and a shader program, render the quad and voila the texture contains data for the next pass.

Shaders are not complicated. Vertex shaders don't do anything related to the post-processing effect in itself, everything is in the fragment shaders. Below is the code for the horizontal blur, inspired from an article on GameRendering.com. The shaders in that article have a little flaw: the sum of all coefficients is 0.98, resulting in a small but noticeable darkening. The following code fixes this problem by adding two new samples with coefficient 0.01.

#version 330

in vec2 texCoord;

out vec4 fragColor;

uniform sampler2D texture;
uniform vec2 resolution;

void main() {
    float blurSize = 1.0 / resolution.x;
    
    vec4 sum = vec4(0.0);
    sum += texture2D(texture, vec2(texCoord.x - 5.0 * blurSize, texCoord.y)) * 0.01;
    sum += texture2D(texture, vec2(texCoord.x - 4.0 * blurSize, texCoord.y)) * 0.05;
    sum += texture2D(texture, vec2(texCoord.x - 3.0 * blurSize, texCoord.y)) * 0.09;
    sum += texture2D(texture, vec2(texCoord.x - 2.0 * blurSize, texCoord.y)) * 0.12;
    sum += texture2D(texture, vec2(texCoord.x -       blurSize, texCoord.y)) * 0.15;
    sum += texture2D(texture, vec2(texCoord.x                 , texCoord.y)) * 0.16;
    sum += texture2D(texture, vec2(texCoord.x +       blurSize, texCoord.y)) * 0.15;
    sum += texture2D(texture, vec2(texCoord.x + 2.0 * blurSize, texCoord.y)) * 0.12;
    sum += texture2D(texture, vec2(texCoord.x + 3.0 * blurSize, texCoord.y)) * 0.09;
    sum += texture2D(texture, vec2(texCoord.x + 4.0 * blurSize, texCoord.y)) * 0.05;
    sum += texture2D(texture, vec2(texCoord.x + 5.0 * blurSize, texCoord.y)) * 0.01;
    
    fragColor = sum;
}

As I write, I remark that blurSize is constant for all fragments so that I could have made the calculation in the vertex shader. Anyway it's not very optimized.

SCons

I used DSSS last time. This project hasn't been updated for years, still compiles using D1 (discontinued by end 2012)... so let's try something else. As I use SCons for my C++ projects, I've though it would be great to use the same system. Luckily, it has built-in support for D!

Building a D program is the same as for a C++ program:

env.Program('bin/program', Glob('src/*.d'))

Really easy. The compilation flags for DMD are however quite different than GCC, pay attention.

Another thing I never did is to specify targets, that is, being able to run 'scons release' or 'scons debug'. This is well-handled with Alias, the trick is to retrieve the return value of Program or any other builder. I've separated each target in its own SConscript, partly because of the VariantDir. To pass a value through a SConscript, use Return. Besides, 'scons .' builds everything, so 'all' is a simple alias to '.'.

debug = SConscript('SConscript.debug', variant_dir='build/debug', duplicate=0)
release = SConscript('SConscript.release', variant_dir='build/release', duplicate=0)

Alias('all', '.')
Alias('debug', debug)
Alias('release', release)
Default(debug)

That's all for this project!

Veggie Might

2012-01-31T14:41:00.000+01:00

As I announced last week, I participed once again in the Global Game Jam. Sadly, our game was not ready at the end of the 48 hours, but there are still some lessons to draw. Moreover, we are planning to continue its development, so version 2 would be presentable.

The game is entitled Veggie Might. This is a MMO game where armies of Baron Broccoli and Count Carrots fight for... well, nothing at this time, but we've thought to bases to take over in a Domination mode. Anyway, we wanted to represent a huge, endless battle a la Lord of the Rings, and this is the link with this year's theme Ouroboros.

We used HTML5 and WebSockets. The idea is to let the players enter the battle as soon as possible. As such, we don't wanted them to download and install the game, it would have been an extreme barrier to the player amount. Therefore with HTML5, they just have to visit a web page and they're ready to go. Moreover, the other programmer and I were pretty new to this world of real-time online games, so we were willing to cross the gap.

The server was programmed in Java. I wanted rather to use Node.js to iterate faster, but I was angry whether it would support the overhead of 1024 players. Maybe it wasn't the proper question at the time, but anyway, it worked. The server is basically in charge of relaying one player's messages to the others (we didn't bother that much with security).

Server and clients communicate via WebSockets, on the server we used TooTallNate's WebSocket library. It works as expected, that is, the user sends and receives messages like with any other network library. Our messages were JSON encoded, there is no need to design a binary protocol in a prototyping phase.

The client uses LimeJS, a framework handling graphical scenes, events and sounds. The scene is a tree of nodes, Sprites being a particular node type. This translates well into HTML where the scene is a tree of DIV, and is very similar to Flash programming.

LimeJS is actually a library to use with Closure. Basically it is a JavaScript to JavaScript compiler, and that reminds me my work on libfirm (and that I also have to continue this work...). It adds a system for including other files that JavaScript misses a lot.

I wanted to do the client side to see the problems related to prediction and collisions. I've already done a project handling these problems, but wasn't in charge of that part. I guess it's useless to tell right now how I've done it as it's not working properly. One thing to note, however: I worked with a mockup server, actually a false WebSocket interface which simulates a server. This was very practical since I didn't have to wait the features on the server to be ready before making my own code. Therefore I'll always recommend to work with mockups on projects related to network.

The artist worked with an incredible interactive pen display. He drew in Flash, allowing to quickly see animations. The exported SWF sequence was transformed into a PNG sprite sheet with SWFSheet. The anchor point was buggy and I had to handle it outside of the animation controller.

I recommend two games from my location: Quadd for the hardcore gamers, and Backdraft for the softer ones. Both of them were made with Unity3D. A programmer on Backdraft told me that Unity3D was hard to use for a pure 2D game. Special ovation for the group from Toulouse which has spent the whole event doing paper prototyping.

A last word about the event: you, as a creator (programmer as well as artist), really have to attend to this kind of events. You'll learn a lot. And don't try to stay awake, particularly at the beginning. By sleeping, the brain will continue to work on your ideas, and this is much more efficient.

As I said, we are willing to continue the development, so stay tuned!

Bunt

2012-01-26T05:08:00.000+01:00

I had to participate in the current Experimental Gameplay Project's competition: some games will be shown at the Stattbad Gallery in Berlin! Bunt is my prototype in response to the theme Five buttons.

Windows users: play this game with no installation! (quick play)
Mac and Linux users: huh, you still need to install Löve2D and play this version.

Bunt means multicolored in German. Indeed the game is all about interactivity with colored objects. In addition, bunt is four letters long, and the game uses four primary colors. Each key from 1 to 4 is assigned a color. By pressing a key, the player interacts with objects of the corresponding color. The goal is to touch every star in the level to go to the next one.

What are those interactions? Something simple, easy to understand, funny to use, and ultimately allowing to solve crazy puzzles. It was important that each object has a different interaction, otherwise it would be like "eh look, something new! But actually you already know it." During playtests for a previous unreleased prototype, we've seen that players enjoy discovering new elements of gameplay. This is an extreme illustration of this concept.

I started the competition with the intention to develop a puzzle game where rhythm helps to solve the levels. The base would be little pixels a la 8bit depicting sound frequencies. Keys would allow to interact with these pixels, to move them in different directions. But then I thought it would be very limited. So, let's add more things to interact with. Hey it's cool! Let's go further, all the buttons do the same interaction. And eventually I dropped the 8bit stuff for a colored design. So, quite different from my first thoughts.

Press blue or yellow and the crate will fall.

Levels present a simple situation. The player should immediately understand what to do to reach the stars. For instance, the second level contained just the frog at the beginning. Two friends tested the game and were stuck here. At the second level?! Damn, was it not so obvious that a frog can jump in rhythm? No it wasn't. So I added a little trampoline, and it became evident that the frog could jump with impetus (it was also more logical, a frog can't gain impetus just by itself). Levels are also designed to be short. Well, the last ones may require some experience, but the first ones are very short, and this creates a little addiction to the game in the same way that WarioWares.

Level design actually starts before the first level. The first thing the player sees is the menu. "Play the game with these keys", each key has a color, there are colored balloons... let's press 2. Oh, the balloon blows up! This is the very first understanding of the gameplay: pressing a key will blow up balloons of the corresponding color. The first level comforts this idea, and introduces the star (it may not be sure what the star actually does, but the next levels will ensure that they have to be touched by something). The second level has a frog instead, and introduces the notion of pressing keys several times on precise moments. The third one uses another color, showing that the principle are the same for all keys, and needs the player to press the key for a finite duration. And so on... almost each level adds some element to the game.

The player should quickly understand that he can restart the level when he can't reach the stars anymore, but that this is no punishment. At first, I made a in-game menu, appearing when the player presses 5. Then, the key 2 allowed to restart the level. A friend told me it was too long and besides the menu was useless. True. So let's just press 5 to restart, and press longer to quit.

Colors were chosen mainly to change between levels. In addition, there is a physical constraint: the game is meant to be played with five big grounded plots, and players can't press both on 1 and 4 at the same time. Therefore keys are often used in pairs. Moreover, the most difficult levels use keys on the right, because the Restart key is closer.

Once again, I've developed this prototype with Löve2D. As this game heavily relies on physics, I've used Box2D (included in Löve2D). I've understood why Magnetic glues sometimes bugs (I won't fix it anyway). The reason is well documented: "Using Shape:destroy when there is an active remove callback can lead to a crash. It is possible to work around this issue by only destroying object that are not in active contact with anything." but I haven't clearly understood what it means. Simply do not delete any shape which is in contact. The solution I've chosen is to remove entities by moving them outside the screen and to save them in a separate list until they are no contact with them (therefore I increment a variable in the add callback and decrement it in the remove callback).

Entities are just containers for a set of components. Almost all objects have a body component (physics) and a sprite component, furthermore the interactive objects have a logic component which basically allows for custom scripts related to interaction. But... I feel like it misses something. On Magnetic glues I've separated the concepts of behavior and game object, but I've added a huge overload with a signal-slot system... Needless to say, I've sometimes hacked the game engine (aka break the encapsulation) to keep things simpler. The last level with the puzzle is a hack of both the game engine and game principles, but I've thought I need to break the game before the end, to calm down the player.

The graphics were made with Inkscape. The background was inspired from Angry Birds. The green, open landscape adds nothing to the level itself, yet it subconsciously relieves the player. For me too, because finding and designing objects for mostly two uses is exhausting... The little GFX and SFX clues were very easy to add, yet it makes the game more attractive. Although I'm still not proud of the sound design and I'll work on that on the future prototypes.

As a last anecdote, there are two alternative control schemes. The first is to use keys from F1 to F5, because I've wanted to play the game like a guitarist in Frets on Fire. It also seems that Löve doesn't support the keys 1 to 5 very well under Linux, but I currently can't verify. The second input method is to use a Xbox controller, as it uses the same colors for its buttons. Any other button restarts the level. By the way, the order of colors (blue, green, yellow, red) was chosen because of the button disposition on the controller and the Dance Dance Revolution transfer function.

Don't forget: Global Game Jam next week-end!

Revenge of the Christmas tree

2011-12-23T01:26:00.000+01:00

With some people of the GameLab Karlsruhe, we made the game Revenge of the Christmas tree for the exhibition Oh Tannenbaum! which takes place in the Karlsruhe University of Art and Design. The development was especially interesting since we made it within five days with a dozen of person with a very relaxed project management.

Download the game for Windows or Mac.

The game is a beat'em up, where players control Christmas trees fighting against students. At the end, player characters face the Übertree, a huge, nasty Christmas tree, who set university's directors in captivity. Well, don't consider the story that much! Nonetheless, we won a special award for merits in ecological sustainability and deceleration, but I guess it's a joke from the jury ;)

The game has been created with OpenBOR. It's a game engine specialized for beat'em ups, having ports on Windows, Mac... and several consoles such as Dreamcast, Wii and PSP! In addition, it does not require coding skills (though coding C-style scripts improves engine's default behaviors), so it may be a good start if you want to make games on such platforms. Although I have to say that you'll need good pixel artists...

Programming a level is quite easy: basically it consists in defining the position of each entity (enemies, obstacles, and so on) in plain text files. The engine already handles the AI for the enemies. But the supertree had predefined attack patterns and required a script to completely bypass the movements given by the engine. We coded a simple finite state machine, allowing it to move, to switch animation or to drop bombs.

The graphics are GIF files. Images for an entity must have the same color palette to save ROM space and processing time (the engine focuses a lot on performance because it targets limited platforms). As always, an entity is defined in a text file and basically contains a list of available animations (which are themselves defined as a list of images). An offset can be declared with each image, that way they are consistent with the logical position of their entity. In the same way, images can have bounding boxes, attack boxes... While a simple image editor may suffice for these images, cut-scenes are animated GIF and an animation editor would be useful.

We really lacked communication. It began as a classic Waterfall project (I was not the manager!) where artists deliver assets to be used by coders to build the game (by the way, coders design the level). The first graphics we received were PNG and as I said we needed GIF. Shadows were drawn on the images, but the engine already has its own ones! Even after that all artists have switched to GIF, the palettes were not coherent and I had to handle this problem until the end. Well, it would have been better when the artists would have asked to the coders details about what they have to do before (agile!). Hopefully, after figuring out these issues, the project ran better and we achieved to release the game for the exhibition.

By the way, Jen and Jan have made their own game, Schmück-Shooter, playable online. It's a third-person Christmas tree shooter, where the player has to decorate Christmas tree with a gun throwing Christmas balls and gifts. Nasty trees appear randomly and quickly move toward the player character. Sadly, nothing highlights these appearances and the players were very confused. It has been developed with Unity3D, allowing to make it quickly... and Playmaker, to develop even faster. Playmaker is a visual state machine editor, allowing to drive logic with blocks and arrows instead of lines of code. I haven't tried it yet, but visual scripting is so more convenient for game designers... Available in the Unity Asset Store.

Kaleidoscope

2011-11-20T15:38:00.001+01:00

I'm proud to release my own programming language Kaleidoscope! With this powerful language, you can define functions, which can call another functions, add or multiply values, and... well, that's it. But look at this fabulous example:

# imports
extern input()
extern print(v)

# magic function
def transform(a, b)
    a * a + 2 * a * b + b * b

main
    print(transform(input(), input()))

Just kidding. This project is only a tutorial, and aims to use libfirm, "a library that provides an intermediate representation and optimisations for compilers. Programs are represented in a graph based SSA form." Since I'm writing my master thesis on this theme, I've wanted to dig into a tutorial to understand the core concepts.

Moreover, I used Bison / Flex for the first time, and this is pretty fun to program!

Note: Kaleidoscope comes from a tutorial written by the authors of libfirm, which is sadly not up-to-date with the latest versions of the library.

Parsing the code

The code needs to be cut into semantic tokens: it's the role of Flex. It is a lexical analyzer generator, that is, you define token rules, and it creates a C function which can match these rules.

For instance, given the rules

"+"
    { return '+'; }

-?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?
    { return DOUBLE_LITERAL; }

[A-Za-z_][0-9A-Za-z_]*
    { return IDENTIFIER; }

Flex will produce a function which transform the following code

foobar + 42

into this series of token

IDENTIFIER, "+", DOUBLE_LITERAL

Quite easy. Then comes Bison, a parser generator. Once again, you define rules to translate tokens into C code, and the generated parser will do the job. Here is an extract of the rules I use:

expr : DOUBLE_LITERAL
        {
            // constant value
            num_expr_t *expr = (num_expr_t *)malloc(sizeof(num_expr_t));
            expr->next = NULL;
            expr->which = EXPR_NUM;
            expr->val = $1;
            $$ = (expr_t *)expr;
        }
    | IDENTIFIER
        {
            // variable
            id_expr_t *expr = (id_expr_t *)malloc(sizeof(id_expr_t));
            expr->next = NULL;
            expr->which = EXPR_ID;
            expr->name = $1;
            $$ = (expr_t *)expr;
        }
    | expr '+' expr
        {
            // addition
            bin_expr_t *expr = (bin_expr_t *)malloc(sizeof(bin_expr_t));
            expr->next = NULL;
            expr->which = EXPR_BIN;
            expr->op = '+';
            expr->lhs = $1;
            expr->rhs = $3;
            $$ = (expr_t *)expr;
        }
    ;

which parses an expression.

As you see, I do not generate the final graph here, instead I construct an abstract syntax tree (AST). I used this solution because when parsing an expression, the context is still unknown, especially the function the expression belongs to. The AST would be something like:

{
    "which" : EXPR_BIN,
    "op" : "+",
    "lhs" : {
        "which" : EXPR_ID,
        "name" : "foobar"
    },
    "rhs" : {
        "which" : EXPR_NUM,
        "val" : 42
    }
}

when represented in JSON :)

Constructing the graph

Before parsing the code to compile, I initialize the libfirm library, and create a program representation inside the lib. Parsing shall complete this program with nodes, which describes the program in a logical way.

When the tokens EXTERN, DEF or MAIN are parsed, I create a new function prototype. MAIN has its own prototype (no parameters, returns an int), whereas EXTERN and DEF have custom prototypes depending on the function they declare (parameters and return value are double).

Moreover, DEF and MAIN define a function body, which is an expression. Actually, it's the previously constructed AST. So the tree is traversed to construct nodes. Here is the representation of the function graph for the first example's "transform" function:

transform: (a, b) -> a*a + 2*a*b + b*b

A function has basically three blocks: a start block (prototype, etc.), a body block, and an end block. In the start block we see that the function takes two parameters (nodes 75 and 76) and returns only one (node 72). Green nodes are just links between blocks, unfortunately you'll have to guess these links.

Note that the graph has been automatically optimized: the "2 * a" has been translated into "a + a" (node 84), which may be faster.

Generating the assembly file

Once the parsing is done, the program is transformed into another language (libfirm cannot directly generate executable file, it relies on assemblers to do this complex task). Here is the x86 assembly for "transform":

# -- Begin  transform
    .p2align 4,,15
.globl transform
    .type transform, @function
transform:
    .p2align 4,,7
    /* .L66: preds: none, freq: 1.000000 */
    pushl %ebp                       /* ia32_Push T[217:33]  */
    movl %esp, %ebp                  /* be_Copy Iu[220:36]  */
    fldl 8(%ebp)                     /* ia32_fld T[189:11]  */
    fld %st                          /* ia32_fpush ANY[229:45]  */
    fmul %st(1), %st                 /* ia32_fmul E[192:14]  */
    fxch %st(1)                      /* ia32_fxch ANY[230:46]  */
    fadd %st, %st                    /* ia32_fadd E[193:15]  */
    fldl 16(%ebp)                    /* ia32_fld T[194:16]  */
    fxch %st(1)                      /* ia32_fxch ANY[231:47]  */
    fmul %st(1), %st                 /* ia32_fmul E[196:18]  */
    faddp %st, %st(2)                /* ia32_faddp E[197:19]  */
    fmul %st, %st                    /* ia32_fmul E[198:20]  */
    faddp %st, %st(1)                /* ia32_faddp E[199:21]  */
    movl %ebp, %esp                  /* ia32_CopyEbpEsp Iu[224:40]  */
    popl %ebp                        /* ia32_PopEbp T[225:41]  */
    ret                              /* be_Return X[171:22]  */
    .size transform, .-transform
# -- End  transform

That's it. Have fun with Kaleidoscope!

Pirates

2011-10-25T16:38:00.000+02:00

Some words about the prototype we developed at the Devmania 2011 on the theme Pirate. I don't provide links to download or play it because I don't feel I own it, read further.

Edit: all the games are available on the Devmania's website!

We were a team of four. Our game was just named Pirates (as many other ones). It was a vertical side-scrolling game where the player controls a ship and has to connect islands appearing randomly at the top of the screen in order to build a peer-to-peer network between them. Some enemy ships try to cut this cable, but fortunately you can shoot them with your cannons before that happens.

The main drawback of the meeting was the lack of network connection. I couldn't have imagined a meeting of computer fans would provide no internet access. Well, now I can conceive it and therefore I will always put an Ethernet cable in my bag, and always attend to meetings with a switch. You should do the same as well!

That implied we had to work with the only tools we had on our laptops. Because I developed Magnetic Glues on it, I still had the installation file of the Löve2D framework, so we decided to use this tool. Moreover, the documentation can only be found on internet, so the prototype provided a valuable starting point despite of its complexity, which has been dramatically reduced.

Because we would not easily communicate our code (no version control), I thought it would be better to reduce the number of programmers and instead to produce some artworks. I am no artist, I can't produce great drawings, but the others have found them fun, so it's not a big waste of time. I mainly used Inkscape.

Unfortunately I can't explain what they did on code because I took no interest to see it. I could just say that a common error has been repeated: at the end they rushed to provide instruction screen and to package the files. Anyway, I was not very productive on the project and I don't feel being really part of it, that's why I didn't uploaded it. Maybe a group member will do.

Presentation of our game.

Embedded terminal in websites

2011-09-06T01:02:00.000+02:00

I release today jquery.terminal, a jQuery plugin to embed a terminal in web pages. It has several base commands and can be customized in order to add application-specific commands. It has a powerful operator mechanism to group command together (allowing to pipe commands and more combinations). And it is very, very geek.

Try the demo online!

I first coded this plugin two years ago, when Aurélien asked me for a terminal to administrate a game he made, without having to build a web interface. I thought it was a good idea and build a system which requires JavaScript and PHP to execute commands on the server side. Last weekend I found this code, and because I dropped PHP in favor of "all in JavaScript!" for months, I wanted to rewrite it. Here is the result!

I really love the command flow, that the outputs of one command serve as additional arguments for another one. With real computer terminals, there are two input methods: arguments in the command line, or the standard input. I made here life much more easier: a single input way. Actually, it has been designed as a data stream with filters which can map values to other ones.

It is the first time I build an execution tree. Because the syntax is really easy, it was not so difficult to parse and collect information. It mainly relies on state machines with a really few number of states. Another solution would have been to use a BNF grammar and a JavaScript parser. I don't know if it exists one, and anyway I thought it was too heavy. However, the final code is more complex to read, thus to maintain, than if it used BNF.

Follow the development on GitHub.

Support for translation in CouchApps

2011-09-04T18:03:00.000+02:00

I released two jQuery plugins I made for a CouchApp: jquery.tr ans jquery.couch.tr. These plugins allow to easily provide translation for your CouchApps. I was disappointed that until now CouchApps could only display text in one language (mostly English).

jquery.tr is a generic plugin, that is its use is not restricted to CouchApp and you may use it with other applications (although other more convenient plugins exist in that case). jquery.couch.tr is just a binding with CouchApp API. I have split the project in two plugins to keep a generic part.

A fixed dictionary is used, so you can be sure of the relevance of your translation. By default, dictionaries shall be files inside the evently/widget directory, with language as name. The files contain either a JSON associative map, or a function which returns such a structure. With that function, you can choose different sentences according to parameters, e.g. to make them agree with numbers.

This is not a full support for internationalization though, it can't change interface or css direction attribute. It's still your job to handle these application-specific cases.

Integrating those plugins with your existing CouchApps is straightforward. Add <script> references to the plugin files (you may use jquery.cookie as well, if you want to keep the last language used). Then, call $.tr.language(language); to set the language which is use for further translations. Therefore, you may want to reload displayed widgets (for instance, $('#account').trigger('_init'); will reload the account widget)

To illustrate the abilities of those plugins, I changed the default account and profile widgets (they should be included in any CouchApp) and translated the sentences into French. I can't say more than: it works!

Note that I use jQote2 as template engine rather than Mustache, which is so far not in the official repository, you should pull changes from this fork to import the feature. jQote2 allows to translate sentences directly in the template (view), whereas Mustache forces to translate them in the data function (controller), and I found the first case better.

Follow the development on GitHub.

Introducing shaders in D

2011-08-21T00:04:00.014+02:00

Update 3/15/2012: This code is quite old, consider my new article Blur effect, which uses Derelict3, OpenGL3+ API and SCons.

Last weekend I was at the Evoke, the largest German demoparty held in Cologne. I will release a story about this weekend, because it is the first time I go to a demoparty. Demos heavily rely on shaders to take advantage of the calculation power of GPU. But actually, I never wrote a shader program. I met another newbie, and we were willing to write some shaders and the associated OpenGL program to load them during the event. But because it would be too simple to do it in C++, I wanted to test the D programming language.

At first sight, D may look like C++. Well, its syntax is based on the C/C++ and it is quite easy to learn for developers used to this language family. But D improves some features of the C++, and sometimes it just breaks the old legacy. I would say it's to compare with C# and Java, but in another direction. I can't tell right now the advantage of D over these two languages because I'm inexperienced, but maybe after some prototypes...

Update 22/8/2011: here's what Nical told us about D:

it compiles VERY fast (productivity++)

you don't suffer from the C/C++'s horrible include system (productivity++)
the syntax is much clearer than C++ and is easy to parse for static analysis tools (software engineering++)
the behaviour of the language is more concistent than C++'s (ninja coding++)
it encourages unittesting (TDD++)
by design, the language does not let you do dangerous things unless you explicitly want to
it has true support for parallel programming
it is awesome
it is fast (you can even turn off garbage collection in critical portions of code)
it has awesome metaprogramming facilities (that C++/boost is not likely to have any time soon) and full compiletime introspection (on top of which it is easy to build run time introspection)
and a thousand of other things that makes you realize that C++ is a powerful but inconcistent, error prone, ambiguous and unproductive language.

Lacks a little bit of visibility on internet, some tutorials and dedicated libraries, though (yet it can use any C library).

I didn't want to write tutorials on this blog, but we had pain to install the environment and do a basic program, so I write the procedure we followed. This is for Windows and uses

DMD (the DigitalMars D Compiler), a famous D compiler
DSSS (D Shared Software System), a build system which automatically computes the dependencies between libraries and programs
the libraries SDL and OpenGL via Derelict2, a project aiming at creating D bindings of C libraries.

Installing the environment on Windows

You also have to install a SVN command-line interface because DSSS uses it during the installation. TortoiseSVN does NOT have this interface. I installed Win32SVN.

Go to http://www.digitalmars.com/d/download.html and download the dmd Windows installer on top of the page. Launch the installer: it asks you to choose components to install. Check D1 and D2. Uncheck dmc unless you really want it. Continue the installation.

Once installed, open a terminal: press the keys Windows + R, type cmd and validate.

C:\Users\MyUserName>

Checkout the DSSS' repository somewhere, but avoid C:\dsss as you will understand later. In this example, I use the directory D:\Code\dsss.

C:\Users\MyUserName> d:
D:\> cd Code
D:\Code> svn checkout http://svn.dsource.org/projects/dsss/trunk dsss

Type the following lines (the original ones are in Makefile.dmd.win). You may change the installation path at the last line.

D:\Code> cd dsss
D:\Code\dsss> copy rebuild\defaults\dmd-win rebuild\rebuild.conf\default
D:\Code\dsss> rebuild\rebuild.exe -full -Irebuild sss\main.d -ofdsss_int
D:\Code\dsss> dsss_int.exe build
D:\Code\dsss> dsss.exe install --prefix=C:\dsss

Change your PATH (see http://www.windows7hacker.com/index.php/2010/05/how-to-addedit-environment-variables-in-windows-7/ for example) by adding the directory C:\dsss\bin and removing the directory C:\D\dmd\bin. It's a little bit crazy, because dsss has to be compiled in D version 1, but then we want to use it with the version 2. You may remove the directory C:\D\dmd as well because we don't use it anymore.

Close the terminal and open a new one (to take the new PATH into account). Checkout the Derelict2's repository (I still use D:\Code).

D:\Code> svn checkout http://svn.dsource.org/projects/derelict/branches/Derelict2 derelict

Compile the wrappers for SDL and OpenGL.

D:\Code> cd derelict
D:\Code\derelict> dsss build DerelictSDL DerelictGL
D:\Code\derelict> dsss install

And you finally have your environment. Phew!

Interfacing SDL and OpenGL with D

The bindings Derelict provides are very useful. They allow us to use the functions and constants as if it was written in C++.

Here is a simple program we made, based on this tutorial, refactored and expanded to load the shaders.

module main;
 
private 
{
 import core.time;
 import core.thread;
 import derelict.sdl.sdl;
 import derelict.opengl.gl;
 import derelict.opengl.glext;
 import derelict.opengl.glu;
 import std.file;
 import std.stdio;
 import std.string;
}
 
class Shader
{
 private GLuint shader = 0;
 
 public ~this()
 {
  glDeleteShader(shader);
 }
 
 public bool loadShaderFromFile(GLenum type, string filename)
 {
  try
  {
   shader = glCreateShader(type);
   string code = readText(filename);
   return loadShader(code);
  }
  catch (Exception)
  {
   return false;
  }
 }
 
 private bool loadShader(string code)
 {
  const char* ptr = code.ptr;
  int len = code.length;
 
  glShaderSource(shader, 1, &ptr, &len);
 
  glCompileShader(shader);
 
  return true;
 }
}
 
class Program
{
 private GLuint program;
 
 public this()
 {
  program = glCreateProgram();
 }
 
 public ~this()
 {
  glDeleteProgram(program);
 }
 
 public void attachShader(Shader shader)
 {
  glAttachShader(program, shader.shader);
 }
 
 public void link()
 {
  glLinkProgram(program);
 }
 
 public void use()
 {
  glUseProgram(program);
 }
 
 static void useFixed()
 {
  glUseProgram(0);
 }
 
 public GLint getUniformLocation(string name)
 {
  return glGetUniformLocation(program, toStringz(name));
 } 
}
 
class Display
{
 private uint height;
 private uint width;
 private uint bitsPerPixel;
 private float fov;
 private float nearPlane;
 private float farPlane;
 
 private Program program;
 private GLint timeLoc;
 
 private double time;
 
 public this()
 {
  height = 800;
  width = 600;
  bitsPerPixel= 24;
  fov = 90;
  nearPlane = 0.1f;
  farPlane = 100.f;
 
  time = 0;
 
  DerelictSDL.load();
  DerelictGL.load();
  DerelictGLU.load();
 
  setupSDL();
  setupGL();
 
  DerelictGL.loadClassicVersions();
  DerelictGL.loadModernVersions();
 
  setupShaders();
 }
 
 private void setupSDL()
 {
  SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER);
  SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
  SDL_SetVideoMode(height, width, bitsPerPixel, SDL_OPENGL);
  SDL_WM_SetCaption(toStringz("D is the best"), null);
 }
 
 private void setupGL()
 {
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  gluPerspective(fov, cast(float)height / width, nearPlane, farPlane);
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity();
 }
 
 private void setupShaders()
 {
  Shader vertexShader = new Shader();
  vertexShader.loadShaderFromFile(GL_VERTEX_SHADER, "shader.vert");
 
  Shader fragmentShader = new Shader();
  fragmentShader.loadShaderFromFile(GL_FRAGMENT_SHADER, "shader.frag");
 
  program = new Program();
  program.attachShader(vertexShader);
  program.attachShader(fragmentShader);
  program.link();
  program.use();
 
  timeLoc = program.getUniformLocation("time");
 }
 
 public static void cleanup()
 {
  SDL_Quit();
 
  DerelictGLU.unload();
  DerelictGL.unload();
  DerelictSDL.unload();
 }
 
 public void update(double dt)
 {
  time += dt;
 
  glUniform1f(timeLoc, time);
 }
 
 public void render()
 {
  glClear(GL_COLOR_BUFFER_BIT);
 
  glBegin(GL_TRIANGLES);
 
  glColor3f (1, 0, 0);
  glVertex3f(-1, -1, -2);
  glColor3f (0, 1, 0);
  glVertex3f(1, -1, -2);
  glColor3f (0, 0, 1);
  glVertex3f(0, 1, -2);
 
  glEnd();
 
  SDL_GL_SwapBuffers();
 }
 
 public bool event()
 {
  SDL_Event event;
  while (SDL_PollEvent(&event))
  {
   switch (event.type)
   {
    case SDL_QUIT:
     return false;
     break;
 
    case SDL_KEYDOWN:
     if(event.key.keysym.sym == SDLK_ESCAPE)
     {
      return false;
     }
     break;
 
    default:
     break;
   }
 
  }
 
  return true;
 }
}
 
int main()
{
 Display display = new Display();
 
 TickDuration lastTime = TickDuration.currSystemTick();
 TickDuration newTime;
 TickDuration dt;
 
 while (display.event())
 {
  newTime = TickDuration.currSystemTick();
  dt = newTime - lastTime;
  lastTime = newTime;
 
  display.update(dt.length / cast(double)TickDuration.ticksPerSec);
 
  display.render();
 
  Thread.sleep(10_000);
 }
 
 display.cleanup();
 
 return 0;
}

Save this code in a file called main.d and then compile it with DSSS:

D:\Code\shader-d> dsss build main.d

It creates an executable main.exe, which works. If you plan to extend the application, you may write a dsss.conf (configuration file for DSSS). However it will stay light because unlike in C++, D mixes code and interface, and has a module / import system thus loads automatically other source files.

But there are no shaders. Let's write them.

Simple shaders in GLSL

Note that they are not compliant with GLSL 1.30, their purpose is just to show that it works.

shader.vert (vertex shader):

uniform float time;

void main()
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color * (0.5 + 0.5 * sin(time));
}

shader.frag (fragment shader):

void main()
{
gl_FragColor = gl_Color;
}

Save them on main.d's directory and relaunch the program.

A triangle which likes to disappear.

Voilà, we have a program in D which can load shaders. I will try to do some prototypes in 3D using shaders, and maybe in a few months I'll be able to write my own demo... :D

Edit: Someone has got issues following this tutorial on Arch Linux. Eventually it worked at the end.

Magnetic Glues

2011-06-27T02:42:00.011+02:00

A Game Jam was organized during the 11th GulaschProgrammierNacht and the theme was magnetism. Here is the prototype I made in a few hours.

Windows users: quick play this game on Game Jolt (a .love version is also available for Linux and Mac users with Löve2D installed).

Download the sources in my cellar

I can't explain how the idea of making a Portal-like game appeared. Most probably it comes from the representation of magnetic dipoles, with red north pole and blue south pole, and I have quickly associated it with Portal.

I had two main goals with this prototype:

to test the physics library of Löve2D (actually a wrapper of Box2D)
to test a code architecture with entities, behaviors and components (explications below!)

Box2D is an efficient though simple physics engine. As the name implies, it is specialized for 2D physics: body's position is x, y and angle values.

An important feature for this gameplay is the ability to apply forces anywhere on the body, not only on the center (actually you may even choose an application point outside the body). But magnetic forces are omnipresent and Box2D was not designed to handle such forces. Worse, the magnetic force grows as the bodies come closer, so it is quite stressful when an object touches a magnetic glue. I limited the effect by restricting the forces to a maximal value, so they don't go to infinity.

There is a trick in the second level (the data's filename is 4 because I made it at the end). I didn't manage to handle well forces on each side. In every case, the platform got stuck inclined. So the trick is to set the body's width to the distance between the two wall's bodies minus one pixel. You may show this by enabling the debugging mode in main.lua. That way, it shouldn't rotate too much.

I said earlier that I had a discussion with Bruce about an architecture with entities, behaviors and components. I have given it a try with this prototype. Basically, an entity is composed of behaviors, and a behavior is composed of components. Theoretical examples of behaviors are "item", "movable" and "usable" while examples of components are "image", "(physical) body" and "input controller". Both entities and behaviors are game-specific, whereas components are given by the game engine. An entity may have at most one behavior of each type: having two identical behaviors makes no sense. However, a behavior may have several image or body components. For instance the player behavior has three images: the woman's body, her arm and the mouse cursor (because I thought a cursor would only appear when there is a player character).

Moreover, there are two communication mechanisms: entities may send events to other ones, and components may send signals which are connected to functions inside their parent behavior (they can't cross to other behaviors). These two mechanisms have different semantics, so they can't be merged (but I may give it a try in the future...). In theory, events are related to gameplay and may even be run asynchronously (although not in this implementation). Signals allow rather instantaneous, direct accesses to data.

But it was so complex. Entities ended to only have one behavior. In fact, entity and behavior could have been combined into a single class. And right now, just two events are sent to entities. They don't come from another entity, they are triggered by collision handlers, so I could have used alternatives not to have events. As I said, I wanted to assess the architecture, but maybe the gameplay doesn't fit well. Or maybe the way I coded it caused that, at the end, I was totally fed up with this architecture and I made some direct accesses to data... The signal system works (I'm a fan of Qt too, which heavily relies on signals-slots) but I am not sure it scales well when game engines become bigger.

A word about graphics for last. I confess I tried to copy the style of Portal: The Flash version. I made almost everything on Inkscape, using a grid to align lines. Therefore I made them quite quickly. A disadvantage of Inkscape is the y-axis which points up, and in Löve2D it points down, so I had to change the basis to set the collision boxes (I could also change it in their declaration, but it may confuse values' meaning). Each image has a "layer" to draw the background behind the objects, the cursor over them, etc.

Some things I'd change if I had to do it again:

I would really throw away behaviors, merging them with entities.
The asset format should be cleaned up.
There are some direct access to game and (physical) world (they are global). I would try to use no global variable. Maybe it's not a good practice, given that there is a single game and world.
There is a function in a level data. Perhaps it should better use a "script entity".
Some players reported a segfault. It may be related to physical bodies which seem not to be properly removed.

By the way, my game jam's favorite game is Princess by vrld (and I don't say that because I've kept in touched with him), made with Löve2D too. It was the only one to have a "story". Although very simple, the starting cut-scene and what the asteroids say took my breath away.

Coglitz

2011-06-17T03:21:00.010+02:00

Experimental Gameplay Project's theme for June 2011 is mashup and my submission is Coglitz, a mix of games I like: Cogs and Droplitz. I just thought: what would result from this combination?

Windows users: quick play this game on Game Jolt

Download the sources in my cellar (should compile on Windows, Mac OS X and Linux).

This prototype is the opposite of Lifetime: no story, just gameplay. I guess I have to see both extremes to find the right position.

At the beginning, I wanted the tiles not to rotate, but it has appeared it is just too difficult. Anyway, you can still play with no tile rotation, called "hardcore mode". It's interesting to note that I first try to rotate the tiles and then to move them when rotation made nothing; my playtests revealed that too. Well, Cogs is more intellectual than Droplitz.

I wondered if I could make it on Flash, using Stencyl or haXe. It's actually a typical Flash game. I've finally made it in C++ because I discussed with Martin about doing some improvements on the sound design, and he heavily relies on FMod. Therefore I used SFML and it works well. It includes wrappers on top of OpenGL and OpenAL, as well as classes to handle windows and input. It also provides network and parallel computing classes, but I haven't used this part of the framework. But I have to say: avoid SFML for a tile-based game! As you may see, the tiles are not perfectly aligned, though I attempted to fix it. Among other things... Update 6/22/2011: Rémi gave me a hint to this problem (as always he was right): SFML "smooths" images by default, actually by doing some linear sampling. I disabled that for the tiles and it looks better. Sorry for this incomprehension, SFML may work for tile-based games! I keep the old screenshot to let you compare (and because I'm too lazy to change it).

As I tried to code it with iterations, I built some things which were later removed, in order to simplify them. For instance, the coglitz used at first a path system to move, a graph with points and edges fixed on the tiles. With the introduction of tile rotation, I thought it was too complex to maintain this system, and I replaced it. Now the tiles are simply described (image, and whether they have a pipe on each of their sides) and coglitz move along the axis (it may introduces some floating-point errors, but that's not important there). But as I was in a hurry to get things done, I didn't refactor as much as I wanted. I should clean the code in the next few days. Don't read the code right now.

I made the graphics the last day. It didn't need to have nice tiles before. I found wood is a nice theme, and the design quite easy to do. Tiles in Cogs are already made of wood, and it just fits with the gameplay.

But I take back what I said last time: I took two days more to do Coglitz than I needed for Lifetime, although with far simpler graphics. So I deduce: if you want to do a game, it doesn't matter whether it has good graphics, good gameplay or anything else. All you need is a clear vision of what you expect. Pretty reasonable, huh?

PS: the rabbit is just a joke for a friend. And yes, it's feature creep. Too bad.

Update 6/21/2011: Some things I'd change if I had to do it again:

There is no entity system and I feel quite bad about that. At first it was great because I didn't want to lose time adding generic behavior when there is no need for it, but at the end there are too many dependencies (worse, cycles!) between the objects. It could have avoided hours of search for segfaults. So I would put some system to isolate the tiles and the coglitz. When a tile moves or rotates, an event is sent to drop coglitz on top of it.
Maybe the tiles and the board (actually the game) should share the same interface to give coglitz directions to follow. In the current implementation, I manually set the motion of a coglitz when it appear, then on every tile it checks the available directions and whether there is a collector at the bottom. With an interface, there would be no difference. It would make the code for the movement easier.
Last but not least, I would do another game, because this one is really not fun to play. Well, I knew it, and the goal is to test experimental gameplays, but it's not so rewarding.

Lifetime

2011-05-27T17:55:00.010+02:00

Lifetime is my first submission for the Experimental Gameplay Project. The theme was Zoom (May 2011) and it might be hard to make the connection at first sight. But this is what the theme inspired me.

And I know this is no business practice but I don't want to pitch you the game.

Windows users: quick play this game on Game Jolt

Go to my cellar to download the game

I have to say I am quite disappointed with this prototype. The artworks are for young children (though I wanted so), the code must be the ugliest one I made (I haven't wanted that!), and story is so simple. However, I did it so it would be stupid not to release it. Even if I failed to do a great prototype, I learned some lessons at least, and hopefully I will overcome them in my future games.

I encountered some problems with my vision of entities made up of components. Among other component types, a GraphicComponent is only able to show a single image. And an entity can only have at most one instance of each type. What happens if an entity want to have several, independent graphical representations? Because I wanted the possibility to show two images at the same time during a cutscene. Finally this never occurred, but I still coded a class which is not part of the entity principle. I recently discussed with a friend about the entities in Warcraft/Starcraft and I will try next time to change a little bit my design.

This was my first prototype with real dialogs. As I am quite influenced by my programming experience with NeverWinter Nights, my dialogs ended to be some generic containers used to launch scripts (there are dialogs which only run a function, with no text). But I didn't wanted to give a whole structure where just a text is required, so the format has become a mess. I will sanitize that problem in future prototypes... or just use fewer dialogs.

I also realized that, when you are a developer, the bottleneck is everything but the code... therefore I won't do another game based on graphics before a while! There are 119 images in this game. The children's style helped to get them faster, but it's still a lot of work when you aren't an artist (achieved in four days along with studies!).

Update 6/21/2011: Some things I'd change if I had to do it again:

I would integrate the cutscenes into the entity system. The main reason is to avoid dealing with different systems on the same game. Rémi suggested that cut-scenes could be composed of several entities, one for each image, and another serving as a controller, reading a track and sending events to the entity-images. Another possibility is a component which can draw some images at the same time, but I guess it's trickier.
For the same reasons, I would put the dialogs into the entity system. Here one entity should be enough for the whole game, actually it would only have a DialogComponent. Sending an event "playDialog" to the entity "dialog" would load and play the dialog given as parameter.
To allow the previous points, I would have to write another Transform component. The current transform is influenced by the camera, but the entity-images and the text need to be independent of it, though they have still a position on screen. The goal is to have both game and UI using the same entity system. It would allow some tricky mechanisms, such as a button sending an event to the player-entity. But I don't really know how to split entities, i.e. draw the game entities at first, and then the UI in a second pass. Let's think about it.
The dialog format should not change, but using some helper functions I could hide the format to the designer/writer. I expected to work alone, but Brice copy-edited the dialogs and he had to deal with that mess.
If I had time, I would try to apply a low-pass filter on the music. Some players reported unpleasant ticks. I can't prefigure what it would result.

The Split-Up Game

2011-05-22T23:49:00.010+02:00

This is the game we made during the Global Game Jam 2011 with Rémi and Fabian, on the theme Extinction.

More advertising and download instructions at the official page (supposed to run on Windows, Mac OS X and major Linux distributions)

The idea took quite a long time to rise, but we wanted to try making an experimental gameplay (well, that is the goal of such prototypes, isn't it?) about relationship. Teammates felt excited about making a game that could really break up some relationships... no comments :)

We wondered which technology we would use: HTML5 or Lua/Löve2D. After some tries, we chose Löve2D, mainly to facilitate asset management. This is a fabulous framework to create prototypes, as I have continued to use it for this purpose. In short, this framework allows to render 2D graphics and other primitive shapes (actually using OpenGL), sounds using OpenAL, keyboard/mouse/joystick input, and even physics simulation with a binding of Box2D. It uses Lua as programming language, therefore considerably accelerates the development... it would be impossible to do such a prototype in C++ within the same time. You should give it a try. Other prototypes mainly used Unity3D and Flash.

Fabian did a really great job doing the assets. He (Rémi helped him too) modeled the rooms in 3D, then exported the scene with an orthogonal view as an image, and finally touched them up. Yeah there are some tricks, you might see that the room walls are slightly curved. But the result is amazing. The rooms are seen with a small angle, making the illusion of perspective, whereas the characters are straight because they have to turn in every direction and it was actually easier to do so.

Bedroom, first room of the game.

The development was quite iterative, with no formal process. As we were grouped on the same tables and were only two developers, it was easy to discuss about our design and code. This might have annoyed other teams... Our design used two entity classes, Room and Item. Room is a description of a room, with their collision boxes (simple axis-aligned box collisions, no physics). Item is quite generic, actually a container for components which were described in the resource file for the room (Lua file too, no deserialization!). Finally, we used Mercurial to version and share the code between us.

Beginning of the game. Some items are drawn over the background. But other interactions actually happen with items with no special graphics, like the library.

It was my first real prototype, and now I love them. Such "contests" are a great occasion to learn about development by prototyping first. Because time is limited, one has to focus on the most important features to have a final package which works and is fun to play. Someone said agile?