I have been working on Socorro for about 3 years now. It was about time that I started talking about it on this blog! With this first post, I am inaugurating 2 new tags, socorro and mozilla. I'm also going to add a language tag to my posts, so each new post will either be en or fr. This way, you can choose more accurately what kind of content you want to read from this blog. The previous links on the tags lead to the filtered Atom feeds, and I will add the mozilla feed to the Planet.

Dear readers,

I am happy to announce today the release of a new game I worked on: Soviet VS Asteroids. The game was developed during the last jam of the Game Dev Party (see the introduction of that 4th jam [fr] or a report of the 2nd edition [en]). The concept is simple: during an entire weekend, 50 people gather, make teams and work on a game, with the goal of having something to show (and to play) in the end.

Greetings, comrade cosmonaut!

This time I decided to work with my friend Aurélien Defossez, who proposed a "planet defense" gameplay. The idea is that you are in space, and asteroids are flying at you. You will need to use your weapons to destroy those nasty asteroids and survive as long as possible. Aurélien gathered a team of 6: he was managing the project and programming, along with Louis-Rémi Babé, Maxime Viry and myself. Mathieu Perez created all the sounds and musics of the game, and did a bit of code as well. Frédéric Ostéréro drew all the beautiful graphics. With this fine team and a lot of work, we demonstrated something pretty good on Sunday evening. But it was not ready for release yet. Over the last 2 weeks, we did some bug fixing, added the missing menus (things like credits or tutorial that do not matter for the demo but are needed when you release the game to the public), and polished the gameplay, mainly by adjusting the difficulty so as many people as possible can enjoy it.

And now, it is time: we believe the game is ready to be played! At this point I hope you are excited and want to download the game as soon as possible. You can do just that by clicking one of those links:

• Windows x86 (32 bits) (if you have no idea what "x86" or "32 bits" mean, this is the option for you)
• Windows x64 (64 bits)
• Mac OS
• Linux

You can play the game with your mouse and keyboard, or with a pad. Make sure your pad is plugged in before you start the game or it will not be detected. You have 2 weapons at your disposal: a rocket launcher and a laser command. You aim at asteroids with the joysticks or your mouse and the Q, A or D keys of your keyboard. If you play with a keyboard, the lasers will fire automatically, and you can shoot rockets by clicking your mouse or hitting the space key. With a pad, you shoot with LS and RS. By pressing the Tab or Enter keys, or the Y button on a pad, you enter the upgrade menu: use your money to make your weapons better, or clear the space around you if you are overrun, or place new lasers or drones around you to improve your defense.

We all hope you are going to enjoy our game! Do not hesitate to make any comments here or to share your high scores! We would love to hear from you.

If you are interested by the technical details, there you go: the game in programmed in lua, using the LÖVE framework (also known as love2d). You can find the source code on github: feel free to fork and open pull requests or issues if you find bugs. Quick feedback on lua: it's nice, but some choices in the design of the language are weird. I definitely prefer Python, but wouldn't mind working with lua again. LÖVE on the other hand was quite a pain to work with, for 2 majors reasons: missing features (no sprite system in a 2d game framework? ) and documentation. As usual, the documentation of a tool is critical and even if the API was well documented, there was almost no tutorial, and no examples of basic features or code.

Play & Enjoy!

Hi everyone!

I recently wrote a library to handle a Component Entity model in a JavaScript game. I need it for my ongoing Fightly Game Engine, which I'm trying to work on. If you don't know what the Component Entity model is, here are great resources about it:

• Evolve Your Hierarchy on Cowboy Programming
• Component based game engine design on Stackoverflow

Basically, the idea is to replace classical inheritance with composition. Your game is composed of entities, each being just a list of components. JavaScript's flexibility is well adapted to this sort of programming, as it is easy to change an object to add attributes or methods to it.

That system I implemented is highly based on what Louis Stowasser did on Crafty.js. It works on both server- and client-side, and comes with a few unit tests and examples. Let's first show you how it can be used:

How to use the ComponentEntityManager

Ok, so I like showing code instead of writing English. Here is the most basic way to use that library. First, import and instantiate the Manager:

var cem = require('component-entity-manager'),
    myCEM = new cem.ComponentEntityManager();

Then, declare a new component:

myCEM.c('HelloWorld', function() {
    this.hello = function() { console.log('Hello, World!'); };
});

Now create an entity using this component:

var hi = myCEM.e('HelloWorld');

And finally use that entity the way you like. For example:

hi.hello(); // prints "Hello, World!" in the console

Pretty simple, right? Right, we only printed a "Hello World" but still, we did so by using the Component Entity model! Now you can obviously add a thousand more components, and create hundreds of thousands entities. Let's see a more concrete example before I explain why it is useful.

A more concrete example

See example1.js on github

var cem = require('../../component-entity-manager'),
    // Instanciate the Game Engine
    myGE = new cem.ComponentEntityManager();

// Create a few components that can be used in-game
var Hero = {
    "life": 100,
    "defense": 100,
    "attack": 100,

    "hit": function(opponent) {
        var points = this.attack * 1.1 - opponent.defense;

        if (points > 0) {
            opponent.life -= Math.round(points);
        }
        return this;
    },

    "specialHit": function(opponent) {
        return this.hit(opponent);
    }
}

var Wizard = {
    // this component requires the Hero component, and
    // any entity having a Wizard component will automatically have a Hero one
    "_requires": "Hero",

    "life": 80,
    "mana": 100,

    // "Overwrite" the specialHit method of the Hero component
    "specialHit": function(opponent) {
        var points = this.attack * 1.2 - opponent.defense;

        if (this.mana > 20) {
            points += 20;
            this.mana -= 20;
        }

        if (points > 0) {
            opponent.life -= Math.round(points);
        }
        return this;
    }
}

var Necromancer = {
    "_requires": "Wizard",
    "life": 70,
    "attack": 110
}

var Paladin = {
    "_requires": "Hero",
    "defense": 150
}

// Add those components to the Game Engine so we can use them
myGE.addComponent("Hero", Hero)
    .addComponent("Wizard", Wizard)
    .addComponent("Necromancer", Necromancer)
    .addComponent("Paladin", Paladin);

// Create two entities than we can manipulate
var gerard = myGE.e("Paladin"),
    igor = myGE.e("Necromancer");

// And now play with those entities
console.log("Before we do anything: ");
console.log("  Gerard's life is " + gerard.life);
console.log("  Igor's life is " + igor.life);

gerard.hit(igor);

console.log("\nAfter Gerard hits Igor: ");
console.log("  Gerard's life is " + gerard.life);
console.log("  Igor's life is " + igor.life);

igor.specialHit(gerard);

console.log("\nAfter Igor hits Gerard: ");
console.log("  Gerard's life is " + gerard.life);
console.log("  Igor's life is " + igor.life);

How is this useful?

And how is it better than classical inheritance? Some people answered this better than I could do in other places (see the two links above), but here is the main point. When you come to have a very complex hierarchy, with lots of classes and dependencies between them, you will certainly end up having unneeded code in some of your objects. Let's say you have a few classes: Moving, Vehicle, Car. Vehicle inherits from Moving, Car inherits from Vehicle. Now at some point you want to add a BrokenCar class, to represent a car than cannot move. It seems quite logical to make it inherit from Car as it shares almost everything with it. But that is the point: almost. As you don't want that BrokenCar to move, you will have to overwrite the code from Moving, or to break your entire hierarchy. With composition, you just specify directly what you need in your object. For example, I want this object to be a Car, a Vehicle and a Moving. Or I want that other object to be a BrokenCar, a Car and a Vehicle (but not a Moving). It is more flexible and allows for a wider range of mixing.

Now about that library precisely. The main features are here: you can create components and declare them, express requirements in a component, create entities from one or several components, get entities from their components. It is intended to be used as a building block for any JavaScript game, or any JavaScript game engine. Oh and I'm pretty sure you guys can find some other use cases as well... :)

Licensing

I release this code under a simple MIT license. It's the simplest I know. I'm considering adding a GPL-ish license as well, and maybe some BSD if people ask me to. 

And the future...

There are a few things I want to add to this library: a function to get an entity from it's ID, more unit tests, more options for selectors... But what I would really, really love to hear is everything you have to say! I will gladly accept code reviews, forks, pull requests, emails, comments here... 

Hack & Enjoy! /-)