Processing est un framework permettant de créer des application rapidement en utilisant un dialecte de Java. Le principe est de fournir de quoi rapidement accéder à l’affichage, aux entrées et au son.

Processing est idéal pour prototyper une application ou un jeu.

J’ai fait un remake de « Flight Control » sans trop de difficultés.

Il faut noter que la version Android diffère un peu de la version desktop dans le sens où il y a des restrictions à respecter comme l’absence de threads.

Firewall Defense est un jeu de type « tower defense ».

Un « tower defense » ? Mais qu’est-ce que c’est ?

Wikipedia nous renseigne : Le tower defense (souvent abrégée en TD) est un type de jeu vidéo où l’objectif est de défendre une zone contre des vagues successives d’ennemis se déplaçant suivant un itinéraire ou non, en construisant et en améliorant progressivement des tours défensives.

Que va être le jeu ?

Dans notre cas nous allons simuler un réseau informatique. Les vagues d’ennemis sont les paquets réseau qui arrivent d’Internet et les défenses seront les différents modules d’un firewall.

Le jeu sera divertissant et addictif (je l’espère) mais aussi un peu didactique pour ce qui concerne les réseaux informatiques.

Les ennemis

Les paquets (ou messages) peuvent être des requêtes web normales ou sécurisées, des e-mails des requêtes DNS… Le danger vient du fait que ces messages peuvent être des spam, ou des virus. Les virus peuvent infecter les serveurs.

Les défenses

Les protections seront les différents modules d’un firewall :

• routage pour aiguiller les paquets
• anti-virus
• anti-spam
• filtrage d’URL
• proxy pour déchiffrer les paquets securisés
• …

Les modules peuvent traiter un certain nombre de messages par seconde. Il y a deux possibilités quand le module sature : soit il laisse passer les message qu’il ne peut pas traiter (mode passant) où il supprime les messages qu’il ne peut pas traiter (mode bloquant).

Dans le cas d’un « tower defense » classique, on utilise le mode « passant », c’est-à-dire que le module laisse passer les ennemis lorsqu’il est saturé.

Pour la jouabilité, il est préférable que le routage soit en mode bloquant et les modules de protection soient en mode « passant ». Dans la réalité, la plupart des modules sont en mode « bloquant » sauf certain modules comme les modules IDS (systèmes de détection d’intrusion) qui peuvent être en mode « passant ».

Les améliorations des défenses

Les améliorations sont des type matérielle :

• augmentation des processeurs pour traiter plus de messages par seconde
• augmentation de la mémoire pour permettre d’absorber les pics de traffic en gardant les messages en attente de traitement

Les améliorations sont aussi logicielle pour permettre la détection de nouveaux virus.

Les cibles (serveurs)

Les paquets arrivent d’Internet traversent le firewall et arrivent sur différents serveurs :

• serveur web (site personnel, entreprise, e-commerce…)
• serveur de mail
• serveur DNS
• réseau interne (utilisateurs)
• …

Les serveurs peuvent être infectés si des virus arrivent à les atteindre. Il faut alors les désinfecter ce qui coûte des ressources et occasionne une indisponibilité du service.

Les améliorations des serveurs

Les serveurs peuvent être améliorés de manière matérielle :

• augmentation des processeurs pour traiter plus de messages par seconde
• augmentation de la mémoire pour permettre d’absorber les pics de traffic en gardant les messages en attente de traitement

Les améliorations sont aussi logicielle pour augmenter la résistance des serveurs aux attaques.

Quelles différences avec un « tower defense » classique ?

La différence majeure avec un « tower defense » classique est que tous les paquets qui arrivent ne sont pas des ennemis. Au contraire, la plupart sont des messages auxquels il faut répondre pour gagner des points qui permettent d’améliorer les défenses.

pour sensibiliser les joueurs aux problèmes de sécurité, il sera nécessaire de « mettre à jour » les différents modules du firewall pour se défendre contre les nouvelles attaques.

Les serveurs infectés se mettront à émettre des virus et des spams qui feront baisser votre réputation.

Les scores

Chaque paquet acquitté ou e-mail reçu ou envoyé permettra de gagner des point qui serviront à financer les améliorations et permettre au joueur d’agir.

En parallèle, la proportion de messages acquittés fera évoluer la réputation ou notoriété du joueur qui recevra plus de messages à traiter.

La progressivité

Le jeu aura une série de niveaux. la progressivité sera dans les différents scénarios qui pourront aller du serveur web personnel à l’entreprise internationale.

Les objectifs

Chaque niveau (ou scénario) aura un objectif en terme de points, réputation nombre d’infection… Et peut-être un objectif de temps minimum.

L’objectif peut aussi être exprimée en nombre de messages d’un certain type à envoyer ou recevoir.

Doit-on être un spécialiste réseau pour pouvoir jouer à « The Firewall – Tower Defense » ?

Absolument pas ! Le jeu devra être accessible à tous. Pour cela, toutes les conventions seront sous la forme de codes de couleurs.

Conclusion

Le principe du jeu à été posé, le prochain article traitera de la maquette graphique.

C’est un jeu qui tourne sur Android, pour le télécharger c’est ici.

J’ai aussi fait un jeu iOS avec Codea : « Super Lunaire » qui est un jeu d’atterrissage de vaisseau dans des conditions plus ou moins compliquées.

Le site de Super Lunaire est ici.

Je vous parlerai prochainement du développement de ces deux jeux, mais aussi d’un de mes nouveaux projet : « Firewall Defense » qui est un « tower defense » mais dans le monde du réseau.

Tout cela a été possible grâce à la librairie jMonkeyEngine (JME). Non seulement cette librairie est très complète et bien documentée, mais elle bénéficie d’une communauté réactive et bienveillante (c’est en tout cas ce que j’ai ressenti à mon égard).
Plus qu’une librairie, c’est en fait un moteur de jeu complet (graphisme 3D, son, interface utilisateur, réseau…).

Vous l’aurez compris, si vous avez un projet de jeu ou d’application 3D en java alors je vous recommande chaudement jMonkeyEngine. La lecture des tutoriels (y compris en vidéo) peut paraître fastidieuse, mais c’est indispensable à mon avis pour comprendre le fonctionnement de ce moteur.

Quelle est l’architecture du moteur du jeu ?

Le moteur utilise une architecture client/serveur. Le client sert à l’affichage et à la saisie des commandes du joueur et le serveur est utilisé pour centraliser le calcul des positions des différents joueurs.

Quels sont les messages échangés ?

Les messages de service comme les connexions, le démarrage de la course… sont envoyés par TCP pour assurer que les messages arrivent à bon port. Chaque client envoie régulièrement les commandes effectuées par le joueur sous la forme d’un message UDP plus rapide mais moins fiable. Le serveur envoie régulièrement aussi les positions de tous les bateaux à tous les clients, ceci sous la forme d’un message UDP également.

Gestion des temps de transferts entre le serveur les les clients

Pour que l’affichage ne soit pas trop saccadé, le client calcule les déplacements de tous les bateaux entre deux messages du serveur. A chaque message reçu du serveur, le client met à jour la position du bateau correspondant et continue la simulation locale.

Analyse du code

Le client et le serveur partage tout le code de la simulation, mais le serveur n’a pas d’affichage.

Le serveur

Exemple de parcours :

La vidéo du parcours complet :

Pour les courageux ou les inconscients… les sources sont disponibles sur GitHub.
Par contre le code est vraiment moche, il faut encore beaucoup de remise en forme et de restructuration.
Le point d’entrée est la classe… Main.java.

Ma première idée est de déformer une grille en fonction du terrain :

La déformation est proportionnelle à l’altitude.

Pas terrible, certaines parties se chevauchent, cela ne va pas être évident d’en tirer quelque chose.

Une autre idée a consisté à ne déformer la grille que perpendiculairement au vent :

Voila, ce n’est pas parfait, mais c’est beaucoup plus près de ce que je voulais obtenir comme effet.

En faisant tourner la carte (ou le vent) on obtient ces différentes déviations :

J’ai mis quelques jours pour obtenir un effet qui me parait acceptable, maintenant il faut en déduire la direction et la force du vent.

Le départ et l’arrivée sont matérialisés par une ligne entre deux bouées. La ligne s’efface lorsque la le départ ou l’arrivée sont franchis.

Pour l’instant il n’y a pas de top départ ni de chronométrage.

Voici le parcours actuel (à rendre plus ludique rapidement).

Pour l’instant l’architecture consiste à créer une classe contenant les données pour chaque objet. Par exemple pour la classe Boat nous avons la classe associée BoatData qui est sérialisée en XML par XStream.

Je ne sais pas si, à terme, la solution sera pérenne (évolution des classes data et support des anciennes versions de fichier XML).

Le wrapper pour XStream ressemble à ça :

package com.sailboatsim.utils;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import com.thoughtworks.xstream.XStream;

public class Conf {
    @SuppressWarnings("unchecked")
    public T load(String pSection, String pFile) {
        XStream xStream = new XStream();
        FileInputStream fis;
        try {
            fis = new FileInputStream(Utils.getFilePath(pSection, pFile));
        } catch (Exception e) {
            // Default values
            return null;
        }
        return (T) xStream.fromXML(fis);
    }

    public void save(T pObj, String pSection, String pFile) {
        XStream xStream = new XStream();
        try {
            FileOutputStream fos = new FileOutputStream(Utils.getFilePath(pSection, pFile));
            xStream.toXML(pObj, fos);
        } catch (Exception e1) {
            e1.printStackTrace();
        }
    }
}

pour sauver un fichier, par exemple depuis BoatData la sauvegarde est appelée avec :

new Conf().save(this, "Boat", boatName);

et la lecture avec création d’un object BoatData :

new Conf().load("Boat", boatName);

Cette image donne le décor de la vidéo ci-dessous.

La caméra a été modifiée pour suivre le bateau en vue de derrière.

Les polaires de vitesse on été améliorées, je peux directement importer une polaire depuis le site http://www.ffvoile.net/ffv/web/pratique/habitable/ORC_IMS/certificats.asp pour l’instant la polaire utilisée dans la vidéo est celle d’un First 36.7 Racing de 2001.

Prochaine étape, gérer un parcours.

Du vent relatif (force et direction) on déduit la vitesse du bateau en utilisant une fonction dont la courbe est traditionnellement représentée sous la forme d’une polaire.

Note :

En fait traditionnellement  les polaires sont données en fonction de la vitesse et de l’angle « absolu » du vent par rapport au bateau et non en fonction du vent relatif.

Le vent relatif (celui indiqué par la girouette en au du mat) sera indiqué au joueur (vitesse et direction) le vent absolu est utilisé par le programme pour calculer la vitesse du bateau.

Pour la suite, comme la gestion du déplacement du bateau fonctionne, il faudra ajouter :

P.S. J’ai essayé de packager le programme pour webstart et pour application Mac, échec à chaque fois.

Les tutoriels sont vraiment très bien faits, on sent bien que JMonkeyEngine est fait pour développer des jeux, tout est axé là-dessus.

J’ai chargé le modèle de bateau dans JME3 :

bon ce n’est qu’un début.

A suivre…

C’est donc en Java que va être codé le jeu. Il y a du pour et du contre, mais comme j’ai déjà fait un jeu en C, je peux essayer le Java.

L’idée est de diriger le bateau en vue de haut un peut à la manière de Micro Machines, ou plus récemment BangBangRacing.

Le look est du genre cartoon.

La liste s’allonge dangereusement…

L’idée m’a même effleuré de le faire financer grâce à Kickstarter ou équivalent.

Le jeu en question est un jeu de course de bateaux.

Le but sera d’en faire quelque chose de suffisamment simple à comprendre et amusant à jouer pour toucher un peu plus de monde que seulement les marins.