Réalisation d’un kiosque en Flash : architecture et organisation de l’équipe

Le contexte

Le but était de réaliser un jeu sur un écran publicitaire (kiosque) contrôlé avec un iPad. Avec ce type de projet, le rendu visuel place le travail de design d’interface utilisateur (UI Design) au premier plan.

Le jeu nécessitant animations et graphisme, nous nous sommes tournés vers la technologie Flash d’Adobe.

L’architecture et l’équipe

Le projet s’articule autour de trois entités :

Notre équipe de production était composée de :

• 2 designers UI/UX,
• 1 dévelopeur iOS pour la partie iPad,
• 1 dévelopeur pour la partie Game Engine.

Interconnexion entre les entités = interaction au sein de l’équipe

Le lien entre le iPad et la logique du jeu (Game Engine) doit être sans fil. C’est donc assez logiquement que nous avons choisi le WiFi. Par conséquent, le Game Engine devient un serveur (Socket TCP).

L’entité « Display » est réalisée en Flash ActionScript 3. Pour la connecter à l’entité Game Engine, plusieurs choix s’offrent à nous :

• Réaliser l’ensemble du Game Engine en ActionScript également ;
• Communiquer avec des pipes sur des handles de fichiers ;
• Réaliser un deuxième Socket TCP.

Nous avons choisi la troisième solution, ce qui amène :

1. Une plus grande séparation des entités, et donc une meilleure répartition du travail dans l’équipe.
2. Une grande flexibilité dans le choix des technologies pour le Game Engine (C#, ASP, Python, PHP, NodeJS, …), et ainsi moins de contraintes sur le profil de développeur nécessaire.
3. Une homogénéité des interfaces.
4. Un lien standard multiplateforme (dans notre équipe, certains travaillaient sur OS X, d’autres sur Windows 7).
5. Une flexibilité sur la localisation physique des entités ainsi que leur nombre (possibilité de mettre plusieurs iPad, par exemple).

Voici l’architecture réalisée :

Réaliser un client TCP en Flash AS3

Voici un exemple de client TCP :

import flash.net.Socket;

public class GameServer {

    private var mSocket: Socket = null;

    private function closeHandler(event: Event): void {
		trace("connection closed");
	}

	private function connectHandler(event: Event): void {
		trace("connected");
	}

	private function socketDataHandler(event: ProgressEvent): void  {
		trace("data rceived");
	}

    public function GameServer(listener:IGameServerServices)
	{	
		mSocket = new Socket();
		mSocket.addEventListener(Event.CLOSE, closeHandler);
		mSocket.addEventListener(Event.CONNECT, connectHandler);
		mSocket.addEventListener(ProgressEvent.SOCKET_DATA, socketDataHandler);
		mSocket.connect(CONFIG::SERVER, CONFIG::PORT);
	}
}

On pourra noter que Flash décode nativement le format JSON :

var json = JSON.parse("{\"test\"":true}"");

Tout cela parait fort simple, mais il y a une subtilité : le serveur doit répondre à une requête de Flash pour autoriser la connexion.

Ainsi, lorsque Flash envoie «  », le serveur doit lui renvoyer un « policy-file ». Dans notre cas, nous sommes dans un système fermé, notre serveur renvoie donc une configuration très permissive :

$contents = "\n";
$contents .= "   \n";
$contents .= "\n\0";
$client->send($contents);

N’oubliez pas le « \0 » à la fin !

Le Game Engine

Comme expliqué plus haut, on a l’embarras du choix en termes de technologie. Par commodité, nous avons choisi le PHP.

Voici le « composer.json » qui décrit les packages utilisés :

{
    "autoload": {
        "psr-0": {
            "MyApp": "src"
        }
    },
    "require": {
        "cboden/ratchet": "0.3.*"
    }
}

On peut noter que notre Game Engine PHP est également responsable de répondre aux demandes (HTTP/GET) de Flash pour le chargement dynamique d’images.

Flash, une élégante solution pour l’interaction avec l’équipe UI/UX

Un retour d’expérience intéressant sur ce projet est la façon dont l’équipe UI/UX était partie intégrante de la phase de développement.

Souvent, l’équipe UI/UX étudie le projet puis fournit maquettes/jeux d’images (assets) utilisés par un intégrateur, qui fera ainsi le pont entre le développement logiciel et l’aspect graphique. Ce qui amène quelques limitations :

1. Le travail de l’intégrateur est de « refaire », au mieux (selon la technologie utilisée), ce que les designers avaient créé.
2. Parce qu’il y a une différence entre ce que l’équipe UI/UX conçoit et ce qui est réellement intégrable, le résultat s’en retrouve affecté.
3. Avoir un intermédiaire limite les essais du créatif.

Ici, ce n’était pas le cas ! L’équipe UI produisait directement le projet Flash, et les interactions avec le code se limitaient à quelques « movieClip.play(), movieClip.stop() » ici et là.

La phase « intégration UI » était réduite à son strict minimum et il était étonnant de voir l’interface continuer de s’améliorer au gré des inspirations créatives des designers, alors que les développeurs avaient terminé et ne touchaient plus une ligne de code.