summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLudovic Pouzenc <ludovic@pouzenc.fr>2013-01-12 18:52:31 +0000
committerLudovic Pouzenc <ludovic@pouzenc.fr>2013-01-12 18:52:31 +0000
commitb7170017579327db1f1816cc518f8af99beeb0e1 (patch)
treead6788b6485aae15d5b6a5291aebc1f86877dfb0
parentea5e9410fb2262cece0ba6af67616e292bdaaa1a (diff)
download2010-netlemmings-origin/trunk.tar.gz
2010-netlemmings-origin/trunk.tar.bz2
2010-netlemmings-origin/trunk.zip
Deux fichiers jamais commités car écrit un jour dans un train...origin/trunk
git-svn-id: file:///var/svn/2010-netlemmings/trunk@221 077b3477-7977-48bd-8428-443f22f7bfda
-rw-r--r--doc/archi.txt2
-rw-r--r--doc/conception.txt27
2 files changed, 15 insertions, 14 deletions
diff --git a/doc/archi.txt b/doc/archi.txt
index d14bf63..d11739e 100644
--- a/doc/archi.txt
+++ b/doc/archi.txt
@@ -5,7 +5,7 @@
Pour l'instant la structure n'est pas vraiment encore là. Ya deux grosses procédures "client" et "serveur".
L'idée c'est que lemmings peut se jouer en réseau à exactement deux joueurs (au delà c'est chiant, et seul, c'est pas en réseau). Donc, l'archi quon aura tout le temps c'est :
-1 serveurs, et 2 clients connectés dessus pour une partie donnée.
+1 serveur, et N*2 clients connectés dessus répartis dans N parties.
On pourra faire de sorte que le serveur gère plusieurs parties en parallèle, mais c'est pas une préoccupation pour l'instant, juste une idée à garder sous le coude, une porte à ne pas se fermer.
Le client pour l'heure n'a pas d'interaction avec l'utilisateur, ça envoi juste des trames ethernet de tests. A terme, la procédure client() devrais lancer l'IHM qui permet de se déclarer à un serveur, choisir un autre mec connecté et un level, et lancer une partie.
diff --git a/doc/conception.txt b/doc/conception.txt
index 4376a64..3aae8f9 100644
--- a/doc/conception.txt
+++ b/doc/conception.txt
@@ -1,11 +1,11 @@
-= Conception =
-== Modules ==
-=== Communs ===
-==== Events ====
+====== Conception ======
+===== Modules =====
+==== Communs ====
+=== Events ===
Le module events permet de gérer une liste d'évènements qui correspondent a des actions d'un joueur.
A un instant donné e.eventTick (daté par le client source de l'évènement), le client e.clientId a généré un évènement de type e.type.
-Les informations complémentaire de l'évènement dépendent de son type :
+Les informations complémentaires de l'évènement dépendent de son type :
* eReady : Signifie que le joueur sur le client en question signale qu'il est prêt à commencer une partie
* eTimeSync : Le client signale l'état de son horloge et attends une réponse du serveur pour se synchroniser. Ces évènements sont gérés si la fréquence des actions de l'utilisateur ne suffit pas à garder une synchronisation suffisante.
* eLemAction : Signifie que le joueur a donné un ordre a un des ses lemmings
@@ -14,10 +14,10 @@ Les informations complémentaire de l'évènement dépendent de son type :
Le module permet de gérer la liste d'évènements, de la trier chronologiquement (utilisé par le serveur), de la sérialiser et désérialiser pour la transférer via le réseau et comporte un méchanisme d'accès exclusif (eventListLock/eventListUnlock).
-==== Utils ====
+=== Utils ===
Ce module regroupe toutes les fonctions "techniques" commune au serveur et au client : gestion des logs, fonctions mathématiques.
-=== Timing ====
+=== Timing ===
Fonctions communes à l'algorithme de synchronisation des horloges des clients par rapport au serveur.
Chaque client respecte le pseudo-algorithme suivant pour sa boucle principale de jeu :
TANTQUE (partie_en_cours)
@@ -28,16 +28,17 @@ FIN TANTQUE
drift_ms est une variable partagée entre le thread principal de jeu (lecture uniquement) et le thread de réception des messages réseaux (mise à jour selon les champs e.eventTick et e.serverTick) via la fonction updateDriftOnEventReception() du module timing.
wantWait est une variable pouvant être affichée pour suivre le comportement de l'algo de synchronisation du temps, mais n'est pas nécessaire au fonctionnement.
-==== Game ====
+=== Game ===
Module contenant la logique du jeu pour passer d'un instant (tick) au suivant. L'état des animations et lemmings sont mis à jour.
-==== Netgame ====
+=== Netgame ===
Module embarquant les primitives qui vont bien pour manipuler les structures de données de data_network.h permettant de gérer l'état des parties réseau. Ce module continent aussi les primitives d'envoi et de réception des évènements réseau
-=== Serveur ===
-=== Client ===
-==== Graphic ====
+==== Serveur ====
+==== Client ====
+=== Graphic ===
Toute la gestion de l'affichage, les primitives pour plaquer les sprites et des tests au pixel.
-==== Loader ====
+=== Loader ===
Module gérant le chargement d'un niveau (utilisé dans un thread par le client pour être asynchrone avec thread d'affichage).
+