\documentclass[a4paper]{article}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}

\title{Présentation du projet Hégémonie}
\author{}
\date{}

\begin{document}

\maketitle
\newpage

\section{Le projet}

\subsection{Présentation}

Notre objectif premier, à travers Hégémonie, est de produire un jeu libre de qualité et de devenir un projet GNU. Le {\it«~It sounds good.  Yes, we will be interested in this as a GNU package~»} de RMS\footnote{Richard M. Stallman} semblant plutôt encourageant dans ce sens.
Nous avons aussi établi un partenariat avec Nekeme prod.\footnote{http://nekeme.net/fr}, qui est une association ayant pour but de promouvoir les jeux libres : ceci en partenariat avec la FSFE France\footnote{chapitre français de la Free Software Foundation Europe - http://france.fsfeurope.org} et l'APRIL\footnote{Association Pour la Promotion et la Recherche en Informatique Libre - http://www.april.org}.

\subsection{Gameplay}

Le {\it gameplay} d'Hégémonie se situera entre XPilot et Mario Kart, mais ceci dans un univers maritime. Les cartes seront fortement typées afin de donner de l'attrait à l'univers environnant, et permettre des ambiances et styles de jeux très différents entre cartes. L'affichage se fera en 3D temps réel, et le jeu sera orienté multijoueur en réseau.


Nous nous efforcerons d'équilibrer le jeu de sorte qu'il soit aussi accessible pour le novice que pour le joueur expérimenté. Nous réaliserons ceci à l'aide d'un savant dosage de la difficulté, notamment au travers d'un système d'évolution des navires et du jeu qui proposera un accès simplifié au novice, et un vrai challenge pour le joueur expérimenté.

\subsection{Technologies}

Notre développement sera basé sur les technolnologies suivantes.

\begin{description}
\item[SDL] qui prendra en compte l'affichage, le son, et les événements utilisateurs
\item[OpenGL] pour réaliser le rendu 3D
\item[Objective-C] sera notre langage de programmation, nous l'avons choisi pour sa simplicité, sa compatibilité avec le C et les outils habituels de programmation, et parce qu'il s'agit d'un langage orienté objet puissant
\item[l'environnement GNUstep] allant de pair avec le choix de l'Objective-C, celui-ci va nous permettre de réaliser simplement l'intégration avec le langage de script, la serialisation/déserialisation de données sous forme binaire ou textuelle (pour les fichiers de configuration), la création rapide d'interfaces graphiques, et la distribution d'objets. Ces points ne sont qu'une rapide et incomplète illustration des avantages de l'utilisation de GNUstep et de l'Objective-C par rapport à des choix plus conventionnels (C, Java, C++).
\item[GNU Guile] nous utiliserons ce langage de script pour la définition des cartes, types de bateaux, types de bonus, ..., ce qui permettra une grande versatilité et une grande extensibilité, entrainant par exemple la possiblité de redéfinir le comportement d'un type de bateau.
\end{description}


\section{Participants}

Notre projet se compose de 9 programmeurs, 2 graphistes 3D et 1 musicien, dont parmi nous 4 graphistes «~traditionnels~» (2d, webdesign...), dont 8 étudiants en maîtrise d'informatique à Poitiers :

\begin{itemize}
\item Cyrille Gautard
\item Damien Genet
\item Nicolas Beauger
\item François Largeteau
\item Gabriel Boudes
\item Léonard Vimond
\item Michaël De Checchi
\item Nicolas Viaud
\end{itemize}

et 4 étudiants extérieurs à la fac :

\begin{itemize}
\item Armand Marcireau
\item Antoine Joubert
\item Samy Kanoun
\item Philippe Audinet
\end{itemize}

\section{Modules programmation}

\subsection{Moteur réseau}

Cette partie est assignée à Nicolas Viaud et Michaël De Checchi.

\subsubsection{Description}

Cette partie du projet est centrée sur le développement de la partie réseau, c'est-à-dire: la synchronisation des différents objets entre les machines, la tranmission d'événements entre machines (collision, changement de direction, etc.).


L'architecture réseau sera celle habituelle, clients/serveur : un serveur est créé lorsqu'une partie est créée, les joueurs qui veulent se connecter à une partie existante étant les clients. Chaque joueur qui a lancé un serveur est l'administrateur de ce dernier : il est la seule personne autorisée à modifier certaines caractéristiques de la partie.


Il nous faudra aussi nous occuper de l'aspect sécurité du jeu. En effet, il faudra empêcher les joueurs non-administrateur de tricher. Le serveur doit pouvoir vérifier l'intégrité des informations et n'accepter que les comportements prévus de la part des clients. Cependant nous ne nous faisons pas d'illusions sur le fait que nous ne pourrons pas complètement protéger le jeu.

\subsubsection{Connaissances utilisées}

Pour réaliser cette partie, nous allons utiliser les connaissances apportées par notre cours de Réseau (partie Client/Serveur).

\subsubsection{Connaissance apportées}

La réalisation de ce projet va nous permettre d'acquérir de nouvelles connaissances en matière de réseau. Comme par exemple, la synchronisation des objets, la gestion des problèmes temporels liés au réseau (ex : latence).


De plus, ce projet nous permettra d'acquérir une vraie expérience pratique de la programmation objet, et de faire face aux différents problèmes qu'elle pose.

\subsubsection{Mise en oeuvre}

Une partie du module réseau reposera essentiellement sur l'utilisation des objets distribués en Objective-C.


Nous utiliserons aussi directemnent des connexions en UDP, lorsque les problèmes de latence seront primordiaux.

\subsubsection{Objectifs}

Dans un premier temps, notre objectif sera la gestion du jeu en local, pour ne pas avoir à gérer les problèmes de latence et de désynchronisation. Puis nous pourrons étendre la gestion du réseau à des parties sur internet, à une base centrale du classement des joueurs, et à une gestion massive du multijoueur.


\subsection{Moteur jeu / Moteur physique}

Cette partie est assignée à Damien Genet et Philippe Audinet

\subsubsection{Description}

Cette partie permettra de gérer la logique du programme, et le comportement des différents objets.


Le moteur de jeu se doit d'être suffisament flexible pour répondre à nos besoins et permettre une certaine extensibilité. Notre but est aussi de séparer au maximum la logique du programme du reste des modules, de sorte que celle-ci puisse être facilement remplacée pour produire un nouveau jeu. Dans le même état d'esprit, l'intégration des moteurs physique et de collision, sera réalisée de sorte qu'ils puissent eux aussi être réutilisables.


\subsubsection{Connaissances utilisées}

Cette partie va permettre de valider aussi bien nos connaissances en génie logiciel que celles en programmation objet, connaissances qui seront essentielles pour répondre aux besoins de l'architecture de cette partie.

\subsubsection{Connaissances apportées}

Cette partie nous permettra d'étendre nos connaissances à l'étude d'un nouveau langage et des possibilités que permet celui-ci et la bibliothèque qui lui est associée, comme par exemple : l'extensibilité au travers d'un langage de script, la sérialisation intégrée...

\subsubsection{Objectifs}

Le développement de cette partie sera réalisé par étapes, en commencant par la définition de l'architecture et de son intégration avec les autres modules, suivie de la gestion des collisions et du moteur physique.

\subsection{Affichage du terrain}

Cette partie est assignée à Nicolas Beauger et Gabriel Boudes.

\subsubsection{Description}

D'une part ce module doit permettre d'extraire les données concernant le relief d'un terrain, ainsi que diverses informations (couleur, texture, ...) fournies par un fichier et d'en faire une structure de données affichable.


D'autre part, il servira aussi à afficher un terrain en 3D à partir d'une telle structure, selon un certain point de vue (position et orientation de caméra, éventuellement angles d'ouverture du champ de vision).


Pour faciliter la création des terrains, nous allons aussi réaliser un éditeur de cartes.


\subsubsection{Connaissances utilisées}

La réalisation de ce module aura comme support le cours d'infographie de ce semestre. Bien sûr, les connaissances acquises en ASD et cours de programmation seront également utiles.

\subsubsection{Connaissances apportées}

Nous allons être amenés à compléter les connaissances du cours d'infographie. De plus, cela nous fournira une expérience concrète dans ce domaine.

\subsubsection{Mise en oeuvre}

Nous aurons à convenir de structures de données raisonnables pour l'affichage du terrain, de façon à n'exiger ni trop de mémoire, ni trop de puissance CPU, tout en conservant un affichage fluide (mais il y aura des choix à faire, car on ne peut pas tout avoir).


Il nous faudra aussi décider de la manière dont seront codés les fichiers contenant les données de relief d'un terrain. Pour l'instant, nous avons pensé à utiliser des fichiers d'image : chaque pixel de l'image représenterait un point d'un maillage régulier du terrain, la valeur d'un pixel donnant l'altitude du point associé.


Pour ce qui est de l'affichage nous hésitons entre la représentation en voxels qui permettrait d'avoir une bonne profondeur d'image et une grande finesse du terrain, au détriment d'une forte utilisation de temps CPU, et la représentation sous forme de maillage polygones qui serait accélérée par la carte graphique. Nous prévoyons de proposer plusieurs résolutions d'image, pour améliorer la fluidité et le {\it gameplay} sur des machines dotées de plus ou moins grandes ressources.

\subsubsection{Objectifs}

Le choix du mode de rendu reste à faire, nous allons procéder à des essais avant de prendre une décision définitive.

Dans un premier temps nous nous occuperons de l'affichage d'un terrain simple, puis nous pourrons étendre le moteur à l'affichage de différents effets graphiques, comme le plaquage de textures, effets d'ombre de lumière.

\subsection{Affichage objets / animations}

Cette partie est assignée à François Largeteau et Léonard Vimond.

\subsubsection{Description}

Cette partie consiste à charger les objets et les animations 3D au format MD3 (Quake 3) conçues par les infographistes, et à les afficher.


Chaque fichier contiendra différentes animations correspondant aux états de l'objet : explosion, tir...

\subsubsection{Connaissances utilisées}

Ce module fera appel à nos connaissances en infographie et en algorithmique.

\subsubsection{Connaissances apportées}

Pour ce module il faudra nous initier à la compréhension de code extérieur, et d'un format de fichier.

Nous utiliserons aussi la bibliothèque OpenGL pour l'affichage des objets.

\subsubsection{Objectifs}

Nous allons commencer nos premiers prototypes par le chargement simple d'objets et leur affichage. Puis nous nous occuperons de la prise en charge des animations.

\subsection{Effets spéciaux}

Cette partie n'est pour l'instant pas assignée, et sera sûrement développée par l'équipe de l'affichage des objets / animations.


Elle consistera en la gestion de tout ce qui ne touche ni à l'affichage des objets, ni du terrain, comme par exemple : l'affichage du ciel, de la mer et des effets de vagues, des trainées, des explosions, météo...

\subsection{Interface utilisateur}

Cette partie est assignée à Cyrille Gautard.

\subsubsection{Description}

Cette partie concerne l'interface entre le joueur et le jeu. Elle est composée d'une interface graphique et d'une partie permettant de gérer les événements des périphériques d'entrée (souris, clavier, joystick).


L'interface graphique regroupe tous les éléments permettant au joueur de sélectionner des options, d'afficher des informations. Pour cela, nous avons décidé d'implémenter notre propre bibliothèque de {\it widgets} (menus, boutons, conteneurs d'image, etc ...). Le but étant de produire une bibliothèque simplifiée proposant un minimum de {\it widgets} adaptée à l'univers du jeu vidéo.


La partie gestion des périphériques permet de transmettre au moteur de jeu les actions du joueur selon le périphérique d'entrée.

\subsubsection{Connaissances utilisées}

Cette partie fait appel à notre expérience en génie logiciel, notamment pour la modélisation du diagramme des classes de {\it widgets}. Nos connaissances en IHM nous seront aussi utiles.

\subsubsection{Connaissances apportées}

Une partie de l'interface sera codée en Guile, pour une question de simplicité et de modifiabilité.

Nous aurons aussi à mettre en oeuvre de nouvelles connaissances en programmation graphique et multimédia : OpenGL, SDL.

\subsubsection{Mise en oeuvre}

Le rendu graphique utilisera OpenGL. L'interface sera thèmable et construite à partir de scripts (en Scheme)
   
Pour la gestion des périphériques, les événements seront gérés gràce à la bibliothèque SDL (Simple Directmedia Layer).
 
Les parties à effectuer sont :
\begin{itemize}
\item Conception/Modélisation.
\item Implémentation des fondements de la bibliothèque.
\item Implémentation de la gestion des événements.
\item Implémentation de la partie rendu graphique des objets.
\end{itemize}

\subsubsection{Objectifs}

Nous espérons, pendant la période de projet, finir la conception et implémenter la majeure partie des fonctions de la bibliothèque. C'est-à-dire les objets graphiques de base.


La partie gestion des périphériques devrait être aussi terminée au cours de la période de projet.


\subsection{Éditeurs}

Cette partie n'est pour l'instant pas assignée, et sera sûrement développée par l'équipe d'affichage du terrain.


Elle consitera en la création d'un éditeur de carte, ainsi que certainement un éditeur de propriétés pour les différents objets.


\subsection{Moteur IA}

Cette partie n'est pour l'instant pas assignée, et dans un premier temps seule une «~intelligence limitée~», comme pour les missiles à tête chercheuse, sera nécessaire. Une vision plus ambitieuse du jeu pourra peut-être nous amener à développer une vraie intelligence artificelle pour la gestion de robots\footnote{joueurs non humains} par exemple.

\subsection{Moteur audio}

Pour l'instant cette partie n'est pas non plus assignée étant donné qu'il s'agit d'une partie non critique du jeu. Son développement sera envisagé lorsque le projet aura atteint une plus grande maturité.

\section{Modules artistiques}

Pour information nous citons ici les modules qui ne sont pas liés au développement logiciel.

\subsection{Modélisation 3D}

Cette partie est assignée à Antoine Joubert et Samy Kanoun.

\subsection{Musique / Effets sonores}

Cette partie est assignée à Armand Marcireau.

\section{Conclusion}

Ce projet nous apportera une expérience d'un développement conséquent, que nous mènerons de bout en bout : de la conception, aux tests finaux. Il nous offrira aussi une expérience certaine dans la gestion de projet.


Un autre bénéfice du projet, sera la collaboration avec diverses associations du libre, afin de promouvoir notre projet et le jeu libre.

\end{document}