Réunion du 2011-02-02








télécharger 27.93 Kb.
titreRéunion du 2011-02-02
date de publication08.06.2018
taille27.93 Kb.
typeRéunion
ar.21-bal.com > comptabilité > Réunion
Comptes rendus Itération 2 (02 fev- 16 fev)ddgivre.png

CR (compte rendu) réunion du 2011-02-02 :


Ordre du jour :

- Daily
- Composantes
- Post-mortem

- Objectifs It2
- Estimés
- Répartition des tâches

- Planification prochaine réunion

- Composantes :

On garde Entity pour l’instant, et on verra si le besoin se fait sentir de rajouter plus de spécificité.

Gameplay ? Composante personnage / classe Personnage / classe personnage dérivant de Entity ?

Plutôt composante Personnage + une Vivant et une autre NonVivant.
Terrain : solution alternative : Ogitor.
TP Patrice :

  • UML + diagramme de séquence (Tout le monde)

  • IA : locale, déterministe, tout dans la composante AI pour comportement individuel + IA globale omnisciente (singleton) (FB)

  • Stratégie de com’ : (JC + FO)

    • Raknet, UDP, « Synchronize Controller » (JC)

    • Cas général : évènement I/O + Évènement du jeu (énigmes, etc …) (JC)

    • Synchronisation : dans les zones tampons + cas de désynchro en jeu. On envoie tout le gameplay, la physique, l’IA (états, etc…). On prend le client hôte comme référence. (FO)

    • Serveur en avance sur les clients (5-10 frames) (JC)

    • Compression de gros volumes (FO)

  • Sécurité : (JF)

    • IP spoofing, DDOS, usurpation d’identité auprès du serveur

  • Changement de scène : (JF)

    • Zone tampons, sans possibilité de retour pour l’intérieur

    • Animation extensible pour la transition intérieur/extérieur

  • Composantes : (FL)

    • Entity/Component, pourquoi ? (motivations)

    • Quelques exemples (cf mail Patrick B.)

    • Solutions de rechange /évolutions envisagées

Post Mortem Itération 1 :


Bons points

Points d’amélioration

+ Wiki : bonne amélioration

+ Efforts bien répartis






Objectifs Itération 2 :



Afficher un modèle dans une petite scène

Faire bouger localement le modèle (physique + I/O)

Implémenter la partie réseau
It3 :

Personnage contrôlable (gameplay + components)

BSP
It4 :

IA de base

Construire map

Animation
It5 : Version pré-alpha

1 classe, 1 pouvoir, 1 arme

Map vide

IA de base
- Tâche :

Livrable Patrice

Boucle d’affichage -> GameEngine

Architecture + Entity

Ogre3D

Traitement des I/O

Physique + lien avec Havok

Réseau
- Fil rouge :

BSP

Assets

Doc outils (Havok, …)
- Patricek:

ElapsedTime fixe pour déterminisme?

I/OManager

NetworkM



Format local

Data

NetStruct

- Prochaine réunion : Lundi 7 Février 13H00.

- TP0 Patrice

- Check UML

- Diagramme de séquence

- Documentation

- Daily
Décisions :

- On continue d’utilise le wiki

- On garde le modèle Entity. Si le besoin s’en fait sentir on adapte selon les recommandations de Patrick B.

- Création du backlog et répartition des tâches selon les objectifs

CR (compte rendu) réunion du 2011-02-07 :


Ordre du jour :


- Daily

- Maj UML + remarques

- Diag séquence TP0

- Rapport TP0 comm

- Docu outils

- Architecture :

- CManager+CFact+Entity :
_MatWorld : Matrix4 ou Node*? A voir lorsque le Graphic Engine sera plus avancé.

_Au final 2 solutions possibles pour création destruction des components :

  1. Création par l’entity qui renvoie un Component* puis initialisation à l’extérieur avec un cast. Entity appelle la destruction.

  2. Flag dans la component (Entity* à 0) pour savoir si elle doit être supprimé au début de la prochaine boucle avec un for_each des managers. La création est en dehors de l’Entity puis add (pas de couplage entre Entité et CompManager). Suppression des méthodes register et unregister dans la CompManager. Remplacer par Create et Destroy.


On garde la deuxième.
_Rajouter isA(ID) dans les components. Déplacer l’enum dans la classe Component en public.

_Pool : à parler plus tard…
- GraphicEngine vs GameEngine :

GameEngine : coordinateur. Il fait le transfert entre les modules (pour la fenêtre et le root par exemple, il peut demander à un module de lui donner pour le passer à un autre).
- I/O :

Ajouter fonctions par rapport au CEGUI.

Envoyer keyPressed au network.
Input hardware et software envoie cette structure au network :


Struct

{

___ type;

Struct content

{

}

};
Protocole intermédiaire + protocole réseau.

Traducteur + manager

GameMode si CEGUI pour savoir si envoi réseau.
- Réseau : message directement transmis de client->serveur aux autres clients avec le numéro de la frame à laquelle exécuter la commande.
Question Patrice

Serveur décide si quelqu’un est désynchronisé.

Client annonce qu’il y a désynchronisation.

- Prochaine réunion : Mardi 8 Février 13H45.

- Diag séquence TP0

- Rapport TP0 comm

- Docu outils
- Diagramme de séquence :

Réseau

Exécution locale


Décisions :

- Composantes créées où il faut (à l’extérieur de l’entity). Le manager détruit à chaque début/fin de boucle les components avec un pointeur nul vers l’Entity parente. Une Entity détruite met le pointeur de toutes ses composantes vers lui-même à 0.

- GameEngine : rôle de coordinateur.

- Input hardware + software -> Translator : structure envoyée au Network définie.

- Réseau : message directement transmis client->serveur->tous les clients. Message exécutée à la frame déterminée par le serveur (frame client + constante)

- Désynchronisation : 2 solutions. Responsabilité au serveur ou au client. Choisir.

CR (compte rendu) réunion du 2011-02-08 :


Ordre du jour :


- Daily

- Maj UML + remarques

- Diag séquence TP0

- Rapport TP0 comm

- Docu outils

Ajout de sujets :

- Frames réseau et pulsation

- Envoie d’actions/intentions/touches + gestion clavier

- Gestion des pertes

- Resynchro

- TP0 plan :

Synopsis (FL)

Diagramme

Réseau (JC)

Synchro + Sécu + Chargement de scène (JF + FO)

IA (FB)

Prog par composantes (FL)

- Mise à jour de l’UML + Diagramme de séquence

- Docs outils :

Florian a enfin retrouvé sa mémoire! Liens vers OgreMax à mettre sur le wiki.

- Réseau :

Envoi d’intentions d’action

Frame rate hardcodé serveur

Elapsed time local relié au framerate serveur envoyé au début

Clients peuvent envoyer s’ils sont en retard

Initialisation du jeu en fonction d’un timestamp…

Retard framerate, préviens serveur et compense sur la suivante si possible

Framerate min et max (25 / 60) : on commence à 60.

Clients peuvent demander à augmenter, diminuer framerate

Si message arrive en retard chez un client, resynchro demandée.

Décisions :

- Plan du TP0

- Envoi d’intentions d’actions

- Frame rate hardcodé côté serveur (min 24/max 60) et ajusté sur demande des clients

- Elapsed time local

- 1er niveau d’alerte : 1,5 fois temps d’une frame -> message pour baisser le frame rate.

- 2ème niveau d’alerte : message en retard : demande de resynchronisation.

similaire:

Réunion du 2011-02-02 iconRéunion du 2011-01-10

Réunion du 2011-02-02 iconRéunion du 23-03-2011

Réunion du 2011-02-02 iconCr (compte rendu) réunion du 2011-01-17

Réunion du 2011-02-02 iconCr (compte rendu) réunion du 07-04-2011

Réunion du 2011-02-02 iconRapport de la reunion du 16 fevrier 2011

Réunion du 2011-02-02 iconRéunion du 1er étage jeudi 26 mai 2011

Réunion du 2011-02-02 iconCr (compte rendu) réunion du 2011-01-24
«On est tjs à la recherche de nouveaux talents, de femmes et de bière. Posez vos cv en sortant !»

Réunion du 2011-02-02 iconCompte rendu de la reunion du jeudi 30 juin 2011
Pour la troisième fois consécutive, je dois ouvrir le carnet noir. Je pense tout particulièrement à Laurent villani, qui n’est plus...

Réunion du 2011-02-02 icon07/2011-09/2011: Trading Support Unit – Middle Office Transversal...
«Le système financier japonais: une remise en cause de lintermédiaire financier»

Réunion du 2011-02-02 icon2011 tiemele 01/01/2011 Groupe de Diagnostics Groupe de Diagnostics...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com