lundi, 8 avril 2013

Soviet VS Asteroids

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:

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!

mercredi, 31 octobre 2012

Web Game Workshop: Creating a Game with Crafty.js

Earlier this month, I gave a workshop in Lyon to teach people how to create Web games with the now famous Crafty.js framework. 13 people attended (out of 15 open places), which appeared to be a good number: I could really help everyone and answer all the questions I received. It was a really good experience, but a short one sadly: we only had 2 hours (30 minutes being me talking about Crafty), and it's really short to be able to actually create a playable game. I think with an hour or two more some people could have had something playable.

Anyway, I created a bunch of content for that workshop, and I wanted to share it. So here it is!

Presenting Crafty.js

I spent the first 30 minutes of that workshop talking about Crafty.js, what it is, what it can do, and how it works. As usual, slides without the actual talk are not really good, but at least you will find some code examples and links to various resources in there. And who knows, maybe someone could make good use of these slides someday?

Creating Web Games with Crafty.js

Workshop: Coding a Web Game

My plan for the coding part was to come with 3 game ideas that people could work on, to provide some help (basic algorithms, some graphic resources) and to give them a working version in the end. That's what I did: I created a simple Snake game, a kind of Fruit Ninja and a Side Runner. After my presentation, I showed the 3 games I coded and asked people to pick one and start working on it. Most people picked the simplest one (some assuming it was the snake, when it was actually the Fruit Ninja clone in my opinion), and no one picked the Side Runner which was certainly harder and mostly impossible to do in less than 2 hours.

After an hour and a half of intense coding, documentation reading and some debugging (I had a few mistakes in my slides sadly), we had some snakes moving and some fruits falling!

I made a simple page with all the resources needed for this workshop:

The Crafty Workshop Awesome Page

There you can find:

  • links to the base template in github or as a zip file
  • short help with algorithms
  • graphics
  • and my own implementation of each game

I really enjoyed doing this, and I wish I can do it again someday! Thanks to everyone who attended and thanks to the Game Dev Party association for organizing this event.

Make Games, Not War /-)

dimanche, 18 décembre 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! /-)

mardi, 15 novembre 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!

lundi, 21 mars 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

jeudi, 18 novembre 2010

Introduction au contexte du jeu vidéo par navigateur

Bonjour à tous !

Je vous avait parlé ici-même, il y a quelques temps, du projet Fightly : un jeu par navigateur de stratégie au tour par tour, dont le but est d'exploiter des technologies récentes du Web pour amener une expérience de jeu avancée dans un navigateur, le tout en utilisant des technologies de l'Open Web. Eh bien ce projet a quelque peu changé, puisqu'il s'est coupé en deux parties : la création du jeu en lui-même est mise en pause, pendant que l'on travaille actuellement sur un moteur de jeu web qui fournira une grosse base au développement de Fightly. 

Un des gros avantages de ce découpage, c'est que le moteur sera libre, relativement générique, et très extensible. Il aura donc pour but d'être utilisé par vous, développeurs de jeux web ! Et puis aussi par moi, quand même ! :) L'autre avantage, c'est que ce projet est développé dans le cadre de mes études en Master 2 Technologies de l'Information ! Nous sommes donc 5 à travailler dessus, et Pierre-Antoine Champin, enseignant-chercheur à Lyon, a accepté de jouer le rôle de client, et nous guide donc sur le développement de ce projet. 

Je reparlerai plus en détail de ce projet, il y a beaucoup de choses à faire et à dire. Aujourd'hui, je vous livre un texte que j'ai rédigé en introduction du cahier des charges de ce projet, et qui présente le contexte de ce projet, et pourquoi il apparaît viable actuellement. 

Le Jeu vidéo

Le marché du jeu vidéo s’est beaucoup développé depuis l’arrivée de l’ancêtre Pong ou du célèbre Tetris. On joue aujourd’hui à des jeux de plus en plus beaux, demandant de plus en plus de ressources à nos machines. Mais on voit aussi d’autres utilisations du jeu vidéo arriver : le Serious Gaming, par exemple, est une branche en pleine expansion en ce moment. Le Social Gaming également, représenté activement par les nombreux jeux basés sur Facebook et ses possibilités en terme de diffusion.

Si on s’essayait à une catégorisation rapide des jeux vidéo, voici ce qui pourrait ressortir : les jeux consoles, les jeux PC “classiques”, les jeux en ligne (MMO en tous genres compris). Dans cette dernière catégorie, on trouve beaucoup de types de jeux différents : les MMO dans le genre de World of Warcraft, les jeux multijoueur comme Counter Strike ou Team Fortress, les modes multi des jeux principalement solo, et les jeux par navigateur.

Les jeux par navigateur

Le jeu par navigateur, ou Browser Game en anglais, se joue par définition dans un navigateur Internet. On retrouve donc dans cette catégorie les jeux “Facebook” cités plus haut, la majorité des jeux en Flash, mais également un très grand nombre de jeux que nous appellerons les Jeux Web, puisqu’ils se basent sur les technologies du Web ouvert. Quelques exemples de jeux web relativement connus : Ogame, Travian, ou le français Hordes.

Ces trois exemples ne sont cependant pas représentatifs de la diversité que l’on trouve dans les jeux web. Les jeux d’élevage virtuel, par exemple, sont extrêmement nombreux sur le Web. À quoi est due cette profusion de jeux web ? Majoritairement à la simplicité d’accès du développement web. Faire un jeu web, en soit, c’est développer un site web. Or, avec des technologies très répandues comme PHP, HTML et CSS, avec toutes les ressources que l’on trouve autour de ces dernières (il suffit de regarder les tutoriels du Site du Zéro pour s’en rendre compte), il est très simple pour une personne un peu motivée de créer son propre jeu web.

Malheureusement, s’il est simple de créer un jeu web “basique”, les développeurs sont rapidement limités par les technologies qu’ils utilisent. Il est quasiment impossible de faire du temps réel avec PHP, le couple HTML / CSS n’est pas adapté à l’affichage d’effets spéciaux ou d’animations complexes, et si l’arrivée récente de frameworks JavaScript comme jQuery a permis de repousser un peu ces limites techniques, cela ne résout pas le problème.

Les technologies du web

Il existe une solution simple aux limitations techniques actuelles des technologies web : se tourner vers le futur et utiliser de nouvelles technologies, pas encore éprouvées, mais qui permettent d’aller beaucoup plus loin dans la création de nos jeux web.

HTML 5, la nouvelle mouture du langage de description des pages web, apporte au développeur un très grand nombre de fonctionnalités clés : le temps réel dans le navigateur avec les WebSockets, les manipulations graphiques avancées avec le SVG et les Canvas, la vidéo et le son avec Video et Audio, et bien d’autres.

La version 3 du langage CSS offre elle aussi d’alléchantes nouveautés : les animations, les transitions, les polices particulières, ainsi que tous les effets graphiques amplement simplifiés.

Objectifs du projet

Toutes les avancées actuelles du web ouvrent indéniablement les portes à des jeux de plus en plus impressionnants, de plus en plus profonds, le tout se passant dans un navigateur ! Il faudra cependant du temps pour que les développeurs maîtrisent tout ceci, pour que des outils facilitant l’utilisation de ces technologies apparaissent, et donc pour que l’accès à toutes ces possibilités pour nos jeux devienne simple.

Voici donc où se place ce projet : notre objectif est de fournir un outil complet, permettant de créer de façon simple et rapide un jeu profitant des dernières avancées en matière de technologie web. Il constitura un ensemble d'outils qui fournissent un cadre de développement et des fonctionnalités permettant d'implémenter tout ou partie d'un jeu.

Je serai ravi d'avoir vos avis éclairés sur cette introduction ! Peut-être ai-je raconté des bêtises, peut-être ma vision des choses est-elle fausse, trop orientée, ou idéaliste... Quoi qu'il en soit, si vous avez des commentaires à faire, ils sont tous les bienvenus ! 

À bientôt pour la suite de nos aventures ! :)

mardi, 9 novembre 2010

Plugin jQuery : des éléments de même hauteur

Bonjour ! 

Je vous livre aujourd'hui un bout de code qui vient de m'être utile, et qui permet d'obtenir des éléments de même hauteur. A priori, pour résoudre ce problème, on utiliserait des display: table; et display: table-cell; sur les éléments concernés. Grâce au plugin jQuery que je vous présente, les choses sont bien plus simples : le plugin calcule la plus grande hauteur des éléments concernés, et aligne tous les éléments sur cette hauteur. 

Le problème

sameheight_problem.png

Ce qu'on veut

sameheight_wanted.png

Solution

Le code d'origine est de Adham Dannaway, sur son blog cre8ivecommando : Equal height columns using jQuery. La version qui suit est légèrement améliorée, puisqu'elle permet de passer en paramètre le type des enfants à redimensionner.

Voici le code HTML utilisé pour cet exemple : 

<div class="boxes">
<div class="box">
<h1>Col 1</h1>
<p>Integer lacus orci, eleifend non semper ac, dictum ut urna. Donec sed lacus ligula, nec varius nisl. Cras eleifend porta varius. Nunc porttitor, dui ut scelerisque tincidunt, lorem nulla semper odio, non laoreet nisi dui id lorem. </p>
</div>
<div class="box">
<h1>Col 2</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi non dolor eu enim aliquam cursus. </p>
</div>
<div class="box">
<h1>Col 3</h1>
<p>Lorem ipsum stuff... </p>
</div>
<div>This div isn't a box ! </div>
</div>

Intégrez à votre page HTML la bibliothèque jQuery, puis ajoutez le code du plugin qui suit : 

/* Plugin to make variable height divs equal heights */
$.fn.sameHeights = function(childrenSelector) {
$(this).each(function(){
var tallest = 0;
$(this).children(childrenSelector).each(function(i){
if (tallest < $(this).height()) { tallest = $(this).height(); }
});
$(this).children(childrenSelector).css({'height': tallest});
});
return this;
};

Il ne vous reste qu'à appeler cette fonction sur les éléments qui vous intéressent : 

$(document).ready(function() {
$('.boxes').sameHeights('.box');
});

Notez que le paramètre de la fonction sameHeights est optionnel : si vous ne mettez rien, la fonction prendra tous les enfants sans distinction. Ce paramètre m'a été utile pour pas appliquer la redimmension à un <div class="clear"></div> contenu dans le <div> parent. 

Voili voilou ! J'espère que ça vous sera utile ! Un grand merci à Adham Dannaway qui a partagé cette astuce. :)

Liens

PS : navré pour l'indentation, j'ai encore du boulot à réaliser sur mon blog... 

jeudi, 22 juillet 2010

Un serveur WebSocket en Python

Bonjour les gens !!

Bon je sais, ça fait un bail, mais voila, c'est ça aussi la vie d'un blog, y a des hauts et des bas ! 

Aujourd'hui, j'vais vous parler de deux choses, qui sont liées. Tout d'abord, je lance un nouveau projet de jeu vidéo, un jeu web (ou browser game) pour être précis. Mon annonce sur le Site du Zéro présente bien le projet, je vous invite donc à aller la lire si vous êtes intéressé. 

Pour résumer, le jeu sera un jeu de stratégie en tour par tour, faisant s'affronter des unités typées médiéval (infanterie, archerie, chevalerie) sur une carte constituée de cases hexagonales, le tout en vue 2d isométrique. Le but est de faire un jeu simple d'accès, permettant à un joueur de faire une partie rapidement, juste avec son navigateur (sans nécessiter de plugin quelconque), et sans avoir à gérer des tas de trucs avant de se lancer dans la partie. 

Voir le Game Concept Document de Fightly

Techniquement, le jeu utilisera HTML, CSS et JavaScript pour la partie client, PHP pour la génération des pages et Python pour le serveur de gestion des parties. L'intérêt est l'utilisation des récentes WebSockets, actuellement implémentées dans Chrome et Chromium uniquement, mais pour lesquelles il existe des fallback. Je vous ferai bien une présentation détaillée de l'utilisation des WebSocket, et pourquoi c'est top moumoute, mais non. J'vais plutôt vous balancer quelques liens intéressants sur le sujet : 

Et on en arrive au deuxième point : dans le cadre de ce projet, j'ai développé un début de serveur permettant de communiquer avec une page web via les WebSockets. Chez le client, on a un code JavaScript assez classique, qui utilise la très simple interface WebSocket. Et du côté du serveur, j'ai donc développé un serveur en Python qui créé les connexions, reçoit les messages des clients, les analyse et les traite comme il faut, puis renvoie aux clients le nouvel état du "monde". C'est assez étonnant de simplicité, d'autant que j'ai commencé à apprendre Python environ 3 jours avant de réussir à faire ce serveur. Bon faut avouer que je ne suis pas parti de rien, j'ai repris le code de Eneko Alonso, donné sur son blog : More WebSockets, now with Python!

Tout ça pour en venir au point intéressant : j'ai décidé de partager avec vous la partie qui gère les WebSockets. Elle est orientée objet, utilise un thread pour chaque client (donc pour chaque connexion), et vous permet assez simplement d'ajouter votre propre comportement lors de réception d'un message. 

Voir le projet python-websocket-server sur GitHub

Bon, c'est le premier truc que je fais en Python, donc y a surement des erreurs. Mais j'espère que vous saurez me les faire remarquer ! :) Je sais par exemple que je ne gère par l'arrêt du serveur par interruption, et que c'est un problème car le serveur ne s'arrête pas tant que tous les clients ne sont pas déconnectés (puisqu'il y a encore des thread en cours de fonctionnement). Je sais également que je pourrais faciliter l'utilisation du code en ajoutant un mécanisme de fonction callback, mais je sais pas encore faire ça en Python, donc ça viendra plus tard ! ^^

Actuellement, le code est celui d'un chat très simple. A chaque fois qu'un client envoie un message, le serveur le renvoie à tous les clients. Pour tester, lancer le server.py dans une console, et accédez à la page index.html depuis votre localhost. Ouvrez cette dernière dans plusieurs onglets, et envoyer un message dans l'un d'eux. Vous devriez voir apparaitre le message sur toutes les autres fenêtres quasiment instantanément. 

Pour ajouter votre propre comportement, modifiez le code de la fonction onreceive de la classe WebSocketClient (websocketclient.py). Il est aussi possible que vous ayez à changer la configuration du serveur dans le fichier config.py. 

J'espère que ce code pourra être utile à certains d'entre vous. Et bien sur, si vous avez des questions, n'hésitez-pas ! Passez à ma grotte ! Laissez-moi un message ! 

- page 1 de 4