Thursday, 26 January 2012

Mais je voudrais te donner de l'argent !

Ce n'est pas que je ne veux pas donner d'argent à une personne qui le mérite et qui m'apporte quelque chose, c'est que je ne peux pas le faire.

Oui, cette phrase est trop catégorique, et même fausse. Je "peux" le faire. Mais à quel prix, et sous quelles conditions ? Je vais essayer dans ce billet d'exposer ce que je considère maintenant comme un des problèmes de base de notre société. Commençons par un petit retour en arrière...

Dans l'temps...

Avant, dans un monde sans technologie de l'information et de la communication, nous avions des contacts qui impliquaient une présence physique. J'entendais un chanteur dans la rue ou dans une salle de concert, j'allais au théâtre voir une pièce ou j'écoutais un poète déclamer ses vers. Toutes ces activités ne pouvant être faites qu'à une distance "humaine" de l'autre, il était simple de remercier monétairement l'autre : je pouvais lui donner de mon argent, quelques unes de mes pièces d'or ou de bronze durement acquises. On utilisait notre argent physique (notre "monnaie"), dont nous étions les uniques propriétaires, de la façon que nous voulions.

Gardez ce point en tête, j'y reviendrai.

Puis vint l'Internet

En évoluant, en créant et en adoptant de nouvelles technologies de communication, nous avons au fur et à mesure retiré la nécessité de proximité physique des échanges culturels. L'écriture a certainement été la première étape, il y a bien longtemps, en permettant de transmettre du savoir entre deux êtres humains sans qu'ils ne soient nécessairement en contact physique. L'imprimerie a sublimé cela. La radio a continué ce processus, puis la télévision, et bien entendu l'Internet qui vient supplanter toutes ces technologies. Aujourd'hui, j'écoute ma musique sur Spotify, je télécharge les films que je veux voir, les séries aussi, je regarde de temps en temps des émissions de télévision en différé sur le net, je télécharge mes livres, je lis des blogs, je regarde des vidéos sur YouTube, je joue en ligne... La majorité de mon activité culturelle passe par mon ordinateur et l'Internet. Est-ce une bonne chose ? J'estime que oui, parce que je crois que sans l'Internet, j'aurais tout simplement infiniment moins de culture. Cependant, ce n'est pas sur ce point que je veux débattre.

Il y a une question qui revient très souvent en tant qu'argument d'opposition au partage : l'argent. En partageant l’œuvre d'autrui, je lui coupe les vivres, je lui retire sa dignité d'être humain et je le condamne à la misère. C'est vrai : en refusant de cautionner et de participer à un système que je n'apprécie pas, je coupe une partie des revenus des artistes que j'aime. Cela reste cependant à pondérer, tant on sait aujourd'hui que les "éditeurs" (au sens large du terme, donc qui comprend aussi bien les majors de l'industrie musicale que les producteurs hollywoodiens) ne respectent pas les-dits artistes et ne leur versent qu'une part infime de l'argent que j'aurais, moi, payé. Ploum exprime très bien dans un récent article les raisons qui me poussent moi aussi à vouloir sortir de ce système, lire Pourquoi je suis un pirate !

Pas d'argent... Pas d'argent !

Donc, le cœur du problème reste tout de même là : moi, je ne donne plus d'argent aux gens que j'estime. La question que je me pose maintenant, c'est "Pourquoi ?" Moi je suis un gars honnête, je suis content de profiter de toutes ces magnifiques créations de mes contemporains, et j'aimerais les encourager en leur donnant un peu de mon argent. Alors pourquoi ne le fais-je pas ?

J'ai récemment été confronté à une telle situation : je voulais acheter un des excellents livres de Thierry Crouzet. Le problème, c'est que le livre en question n'était achetable que par Paypal. Ayant choisi de ne plus utiliser les services de ce dernier pour des raisons éthiques, je me suis retrouvé dans une situation qui est en fait incroyablement commune : il m'est impossible de donner mon argent à quelqu'un sur l'Internet. Pas réellement impossible, mais tellement compliqué que c'est proche d'impossible. Et pour que ça soit un tout petit peu (mais pas trop quand même) plus simple, je dois sacrifier une partie de mes convictions et de ma liberté.

Et c'est à mon avis sur ce point très précis que se trouve un de nos plus gros problèmes, et une des plus grandes victoires des puissants, ici par le biais des banques. Le paiement en ligne est intégralement contrôlé par les banques. Il est impossible aujourd'hui de procéder à un seul échange d'argent en ligne qui ne soit pas tracé, vérifié et stocké quelque part. Et le pire, le pire, c'est que ce n'est même pas simple ! Payer par carte bancaire en ligne est un parcours du combattant ! Les banques ont donc réussit le tour de force de nous emprisonner dans un système où elles contrôlent tout. Finie la monnaie qui partait on ne sait où, finie la pièce de 2€ que tu donnes à ton prochain et qui échappe à sa taxe de 5% pour la banque : dans le monde numérique, tout échange monétaire est tracé et taxé. En entrant dans le numérique, nous avons perdu une de nos libertés : celle de donner librement notre argent à une personne qui est dans notre proximité. Et le fait que dans l'Internet nous soyons tous proches les uns des autres ne justifie pas cette perte, bien au contraire.

Une limite technique

Je voudrais pouvoir donner mon argent à qui je le souhaite, en ligne, de manière simple. Comme je peux donner un billet à un chanteur de rue, je veux pouvoir donner 5€ à Lady Gaga ou à DEF. Cette impossibilité technique est une atteinte à nos libertés.

Cependant, comme je viens de l'écrire, c'est une limitation principalement technique. Il nous est donc possible de créer des solutions à ce problème. Et il y en a déjà ! Regardez BitCoin, le projet de monnaie numérique décentralisée : en utilisant ce système, il est possible de transférer de l'argent sur l'Internet de manière simple, sécurisée, et surtout de manière libre ! Personne ne peut vous empêcher de faire une transaction licite dans ce système.

Seulement le système BitCoin n'est pas parfait : comme beaucoup de systèmes à portée sociale, il faut que beaucoup de gens utilisent, ou au moins acceptent les BitCoins pour que ça ait un vrai impact. Je ne crois pas que ça soit le cas aujourd'hui, et c'est très dommage. Cependant, il ne tient qu'à nous de faire que ça change...

Friday, 23 December 2011

Comment est propagée la pensée unique

Bonjour les amis !

Aujourd'hui je souhaite vous faire découvrir un morceau de reportage très intéressant. Intitulé, comme ce billet, "Comment est propagée la pensée unique", il présente via des interviews comment les industriels ont imposé leur vision du monde, leurs règles, leur modèle de pensée.



Je vous laisse apprécier, et en tirer les conclusions que vous souhaitez. Je me suis personnellement rappelé le discours de mes professeurs de Fac d'informatique qui nous disaient qu'ils nous préparaient pour le monde du travail, qu'ils nous enseignaient certaines matières parce que c'est ce que les entreprises veulent.

Ça rejoint également un TED Talk que j'ai vu il y a quelques temps sur l'éducation, dans lequel Sir Ken Robinson expliquait que le système educatif tue la créativité des enfants. Voici d'ailleurs la vidéo en question, elle date de 2006 :

Lisez, pensez, partagez !

/-)

Source : http://www.jmp.net/2011/12/comment-est-propagee-la-pensee-unique/

Sunday, 18 December 2011

Component Entity Manager for JavaScript games

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:

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! /-)

Tuesday, 15 November 2011

Examples of how to break long lines in Python

I recently started learning Python, and as I am a bad student, I didn't follow the coding style PEP8 recommends. So I'm currently in the process of rewriting all of my code to follow PEP8, and that basically means breaking long lines. I ran into several cases where I didn't know how to break my line, and the Internet doesn't seem to be very helpful about this. But fortunately my awesome coworkers are, so here are some examples of cases I had to deal with, and how I ended up dealing with them.

Before I start showing examples, I just wanted to outline the few rules that matter here about PEP8:

  • Lines must not be longer than 79 characters ;
  • Use 4-space indentation for blocks ;
  • Alignment matters ;
  • The rest of the rules is well described in the PEP8 documentation.

Breaking an if statement

if condition1 and condition2 and condition3 and condition4 and condition5 or condition6:
    do_stuff()

At first I did something like this:

if condition1 and condition2 and condition3 and condition4 and condition5 or \
   condition6:
    do_stuff()

It seemed better to me mainly because that way the second line of conditions is not on the same indentation level than the content of the block, but my coworkers convinced me that using parentheses instead of backslashes is better. Reasons are backslashes are not "pythonic", and the use of parentheses shows the limits of the conditions.

Here is what I then thought would be the best solution:

if (condition1 and condition2 and condition3 and condition4 and condition5 or
    condition6):
    do_stuff()

But it's still not perfect as the block is aligned with conditions, and it makes it difficult to differenciate them. I believe now the best way to go is the following:

if (condition1 and 
    condition2 and 
    condition3 and 
    condition4 and 
    condition5 or
    condition6
):
    do_stuff()

Assert

assert condition, "This is a very long error message because I like to be verbose when I describe assertion errors with this content: %s" % variable

Becomes

assert condition, ("This is a very long error message because I like to be "
                   "verbose when I describe assertion errors with this "
                   "content: %s" % variable)

Or when the condition is long:

assert condition1 and condition2 and condition3 or condition4, (
    "This is a small error message. ")

Other examples?

If you ran into similar examples and couldn't find a documented solution on the Web, please share them in the comments and I'll add them here!

Wednesday, 24 August 2011

Concours Ganuta

Je suis récemment tombé, via un tweet de Karganis, sur le site du concours Ganuta, et j'y ai découvert deux-trois petites perles que je voudrais partager avec vous aujourd'hui.

Kaolao le puissant Glypheur Aztèque

Tout d'abord Kaolao, un jeu développé par les étudiants de Gamagora, la formation pour le jeu vidéo lyonnaise. Mon pote Raf' Voulzy a participé au développement, et si je n'ai pas encore testé le jeu moi-même, je vous invite à regarder cette vidéo de présentation, puis à télécharger la démo du jeu depuis leur site.

Urbhaine

Urbhaine est un court métrage réalisé par Ludivine Berthouloux, étudiante à l'école Emile Cohl. Ça raconte l'histoire d'une fille qui accumule de la haine à cause de la vie en ville, des gens qui l'entourent, des aggressions... Et qui se créé un démon en conséquence.

Beauté Fatale

Un autre court métrage, par Johanna Falaschi. Je suis pas du tout fan des graphismes, et la chute est un peu trop évidente, mais j'ai trouvé ça plutôt original.

Pour clore ce brillant article, je vous invite à aller visiter le site du concours Ganura, et à voter pour Kaolao parce que c'est top moumoute.

Tuesday, 12 April 2011

Adrian chez les Américains : la Saga Exclusive

Je sais pas vous, mais moi je kiffe ce titre ! 

Bon, j'ai l'impression de ne parler que de ça en ce moment, mais en même temps, je ne pense qu'à ça. Donc bon. Autant que je continue d'en parler. 

Je pars ce vendredi pour les USA, en Californie, et plus précisément à Mountain View, pour faire mon stage de fin d'étude en tant que Web Dev chez Mozilla ! Je vais certainement continuer à partager ici mes expériences techniques (ici et sur le blog de programmateur a priori), mais pour tout ce qui concerne ma vie de tous les jours, les photos, les petites histoires et autres banalités qui n'intéressent pas forcément le lectorat de ce blog, j'ai créé un autre journal en ligne : http://stwaladinde.lqbs.fr/


La Californie...

Allez un peu de technique pour justifier tout ce que je dis : ce nouveau blog est motorisé par PluXml, un système de blog très simple sans BDD (tout est enregistré dans des fichiers xml, d'où le nom), qui possède les fonctions de base qu'on attend d'un blog, et qui a surtout l'énorme avantage d'être très très très rapide. Je suis totalement bluffé par le temps de chargement des pages, comparé à Wordpress ou DotClear c'est vraiment flagrant. 

Mais il faut avouer qu'on est quand très en deçà d'un WP en ce qui concerne l'étendue des possibilités, et surtout en terme d'interfaces d'administration. Mais bon, ça reste vraiment bien, un peu geek (j'adore devoir écrire mes billets en HTML :D ) et amplement suffisant pour un petit blog. 

Prochaine émission, prochaine édition, en direct des Etats-Unis. 

À la revoyure ! 

Liens :

Monday, 4 April 2011

Ideonimbus reprend du service

Bonjour jeunes (et moins jeunes) amis ! 

Vous vous souvenez d'Ideonimbus ? Ce site qui vous permet de partager des idées ou des concepts avec le monde entier ? Eh bien le projet a été quelque peu "mort" pendant pas loin d'un an, jusqu'à la semaine dernière : en effet, à cause d'un bug, je ne recevais plus les annonces des nouvelles propositions d'idée. Du coup, j'ai cru que le site n'intéressait plus personne... Et j'avais tord ! 

Vous pouvez donc d'ores et déjà retrouver sur Ideonimbus deux nouvelles idées : des combats épiques contre des boss humains, dans la catégorie Jeux vidéo et proposé par moi-même, et une idée pour trouver l'âme-soeur dans son département, proposée par terral dans la catégorie Vie courante

Allez, je vous fais même un peu de teasing : l'idée de demain est de Florence (ma chère et tendre, dont l'entreprise, Graphisphère, gère votre communication (OUI CECI EST DE LA PUB :D ), et ça parlera de Mezzanine ! ;-)

Et surtout, n'oubliez pas : partager vos idées rend beau, et noter ou commenter celles des autres rend aimable ! 

Monday, 21 March 2011

Fightly Game Engine : un moteur de jeux web libre

Amis lecteurs, bonjour ! 

J'en avais parlé il y a quelques temps (plus de 6 mois maintenant), j'ai travaillé ces derniers temps sur un projet nommé Fightly. Comme ce projet a subit pas mal de changements, commençons par un peu d'histoire pour que les choses soient claires... 

blog-fightly.png

La vie d'un projet

Tout commence il y a environ un an, Gandi offre des noms de domaine gratuits, et j'acquiers fightly.fr et fightly.com avec dans l'idée de faire un jeu de stratégie très simple. Je garde le concept dans un coin de mon cerveau, jusqu'à ce que je découvre les WebSockets : je code quelques essais simplistes de jeu de stratégie sur carte hexagonale, et je fais des tests de communication par WebSocket. Ça me botte bien, donc j'approfondis le concept du jeu, et je lance une première campagne de recrutement en juillet dernier, sur le Site du Zéro et bien d'autres sites spécialisés : [Jeu Web] Fightly

À ce moment, l'idée est de créer un jeu web de stratégie au tour par tour, au concept simpliste, avec pour ambition de faire un projet réalisable par une équipe amateur. On y travaille donc pendant les deux mois de vacances, puis vient la rentrée scolaire, et le rythme ralentit pendant quelques semaines. Et j'ai là une occasion sur laquelle je saute : faire passer ce projet dans le cadre d'un projet universitaire, et ainsi pouvoir travailler sur un projet que j'ai lancé et donc que j'affectionne, et être noté pour ça ! 

Avec l'aide de Pierre-Antoine Champin, enseignant-chercheur au LIRIS et avec qui j'avais déjà travaillé, qui accepte de jouer le rôle de "client", nous remanions le projet : l'objectif sera de créer un moteur de jeu web de stratégie au tour par tour, libre, exploitant des technologies récentes du Web Ouvert, et d'implémenter une démonstration simple de ce moteur. Je recrute 4 collègues de formation, et nous voilà partis ! 

Fightly Game Engine

Venons-en donc au projet en question, et reprenons-en les objectifs. Le coeur c'est de créer un moteur de jeu, donc un outil permettant de construire et de faire tourner un jeu vidéo. En réalité, le terme "moteur de jeu" est peut être mal adapté. Ce serait plutôt un framework, puisque notre application fournira les briques de base pour créer un jeu. Il serait intéressant de débattre sur ces noms : est-ce qu'un moteur de jeu est une spécialisation de framework ? Quoi qu'il en soit, l'idée ne change pas : on fournit un ensemble de fonctionnalités de base, dont on sait qu'il constitue la base d'un certain type de jeu, et on facilite donc le développement de ce type d'application. 

La première subtilité ici est qu'on s'intéresse uniquement aux jeux Web : on n'est plus du tout dans le même cadre que les moteurs de jeu "classiques" (par exemple, le Unreal Engine, le Cry Engine ou le Gamebryo), la structure de base de l'application change totalement puisqu'il faut gérer avant tout une architecture client / serveur basée sur les protocoles du Web. On cherchera donc à fournir une application gérant les connexions de clients, l'envoi et la réception de données via le réseau, le tout étant réalisé avec un client qui s'exécute dans un navigateur. 

blog-wesnoth.jpg
Battle for Wesnoth

Deuxième point important, on se limite à un certain type de jeu bien particulier : les jeux de stratégie au tour par tour. Pensez Civilization, Dofus, Heroes of Might and Magic ou encore Battle for Wesnoth. Notre but est donc de faciliter la création de ce type de jeu dans un navigateur : gestion de parties, des tours, des joueurs, des unités, des combats entre unités, etc. Là où le Fightly Game Engine se différencie d'un moteur de jeu classique, c'est qu'il sera largement extensible. À la manière d'un framework comme jQuery, il sera possible d'ajouter des modules au moteur, pour en étendre les fonctionnalités. Nous avons l'ambition de fournir un outil avec lequel il ne sera pas nécessaire de savoir programmer pour créer un jeu : vous choisissez les modules nécessaires à votre jeu, vous les configurez pour qu'ils répondent à vos attentes, vous écrivez vos règles dans un format défini par le moteur et vous n'avez plus qu'à lancer votre serveur et à attendre vos premiers joueurs. 

Bien entendu, s'il sera possible de ne pas programmer, tout sera fait pour qu'un développeur puisse étendre ou modifier le comportement du moteur de manière simple. De même, on cherchera à faciliter grandement la création de modules, puisque c'est par eux que le moteur grandira et deviendra réellement intéressant pour les créateurs de jeux. 

Ce projet est libre, c'est-à-dire que vous pouvez, à tout moment, en lire les sources, les modifier, les redistribuer, selon les termes des licences. Notez cependant que le jeu n'est pas encore explicitement sous licence (il est donc encore soumis au droit d'auteur), mais qu'il sera très certainement distribué sous double licence MIT et GPL

Enfin, le Fightly Game Engine utilise des technologies émergentes du Web : les WebSockets pour une couche réseau solide et performante, Canvas côté client pour l'affichage, HTML5 et CSS3, du JavaScript côté serveur avec Node.js, et bien d'autres. Nous souhaitons profiter de toutes ces nouvelles possibilités techniques pour fournir un outil puissant et robuste, permettant la création de jeux de plus en plus poussés, qui profitent de l'énorme avantage du Web : ils marcheront sur toutes les plateformes disposant d'un navigateur récent. 

Où en sommes-nous ?

Le projet Fac est terminé, et si nous sommes loin d'avoir atteint tous nos objectifs, nous avons su créer quelque chose d'exploitable. Ce n'est pas encore un moteur à proprement parler, c'est plutôt une application configurable. Etant donnés nos délais et le peu de temps que nous pouvions consacrer au projet, nous avons du couper beaucoup de choses, et aller au plus rapide pour pouvoir avoir un résultat présentable. Nous avons donc une démo de jeu, très simple, dans laquelle les unités s'affichent sur une carte, et les joueurs peuvent les déplacer chacun à leur tour. Un bon début à mon avis, et une bonne base de code. 

Si vous souhaitez en savoir plus sur le travail que nous avons effectué durant le projet Fac, je vous invite à lire les documents que nous avons produit : le cahier des charges, la veille technologique et le dossier bilan. Ou un zip contenant les trois

Cependant, ce que nous avons réalisé est très loin d'être terminé. Nous n'avons pas résolu de nombreuses problématiques clés du projet : comment rendre le moteur générique et extensible, pour permettre d'ajouter ou de retirer des modules ? Comment gérer les dépendances entre ces modules ? Comment gérer les correspondances des modules côté client et côté serveur ? 

Il reste donc beaucoup à faire, il y a des défis très intéressants à relever, en terme d'architecture générique et extensible, en terme d'application orientée réseau, en terme de moteur de jeu, en terme de performances côté client, et bien d'autres choses encore. Voila pourquoi j'en viens au... 

Recrutement

Je pense qu'il est nécessaire de travailler à plusieurs sur ce projet, pour plusieurs raisons. D'abord parce que j'aime travailler en équipe. Ensuite parce que mes seules compétences ne me paraissent pas suffisantes : j'ai besoin de gens meilleurs que moi en architecture logicielle et en performances JavaScript, qui sont deux points clés de ce projet. Et enfin parce qu'on réfléchit bien mieux à plusieurs, surtout sur des problèmes complexes. 

Je recherche donc des coéquipiers pour travailler avec moi sur le Fightly Game Engine. Il y a trois axes majeurs pour le développement immédiat du projet, qui sont les suivants :

  • Architecture : Réflexion sur l'architecture du projet, mise en place de solutions adaptées à nos besoins de généricité et d'extensibilité. 
  • Communauté : Mise en place d'outils favorisant la création d'une communauté autour de notre logiciel libre. 
  • Développement : Refactoring du code sur des bases saines, mises en place de bonnes pratiques, correction des bugs existants, amélioration constante de la documentation, ajout de nouvelles fonctionnalités.

Je cherche en priorité des gens relativement compétents, avec une bonne expérience en JavaScript, en jeu vidéo ou en gestion de communauté libre. Bien entendu, le travail serait bénévole, le projet étant libre et n'ayant pas pour but de générer, de lui-même, des bénéfices commerciaux. 

Pourquoi participer à ce projet alors ? Pour l'intérêt des difficultés techniques à surmonter. Pour participer à un projet que vous estimez et que vous voulez voir aboutir. Pour avoir l'occasion de travailler sur une application dont les performances sont critiques. Pour approfondir vos connaissances en JavaScript, en jeu vidéo, en Web. Pour expérimenter le travail en équipe amateur (dans le sens, qui travaille sur son temps libre). Ou pour toute autre raison de votre choix ! 

Si vous êtes intéressé ou que vous avez des questions, n'hésitez pas à me contacter via les commentaires de ce billet, via ma page de contact ou directement par mail : adrian@gaudebert.fr

- page 11 of 21 -