Réunion du 2011-01-10








télécharger 43.81 Kb.
titreRéunion du 2011-01-10
date de publication30.03.2017
taille43.81 Kb.
typeRéunion
Comptes rendus Itération 1 (10 jan- 25 jan)ddgivre.png

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


Ordre du jour : Organisation + Définition concept

- Itérations de 2 semaines qui commencent et se terminent le mercredi (mardi si mercredi occupé). Réunion du mercredi : aprem au milieu de l’itération, matin + aprem au début/fin itération.

- Estimés : on continue le poker planning.

- Wiki : pour travaux communautaires sur un même document.

- Jeu :

  • Coopératif

  • Incorporation de classes

  • Se déroule dans le monde du rêve

  • Abilités pour chaque classe (évolue, XP d’équipe)

  • IA ennemie uniquement (par vagues, checkpoints, …)

  • Multi caméras au choix du joueur

  • Loot et objets (loot instantané sans animation)

  • Monstres spéciaux

  • Mort : chaque joueur choisit de se faire revivre. Quand il revit, la fréquence augmente.


- Notes :

Barre d’ondes cérébrales : de 100 à 500, chaque pouvoir de l’architecte augmente la fréquence. Plus la fréquence est haute, plus l’équipe est « harcelé ». Arrivé à 500, l’équipe a perdu.
- Prochaine réunion : Mardi 11 à 11h. Ordre du jour : Classes de personnages + Premier scénario

Décisions :

- Itération de 2 semaines sauf la 1ère jusqu’au premier rendu.

- Estimés poker planning : on continue.

- Utilisation d’un wiki.

- Définition du concept du jeu.

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


Ordre du jour : Classes de personnages + Premier scénario

Classe

Concept

Armes

Pouvoir

Architect

Modifie l’environnement



Bouclier ?

- Ratelier d’armes (zone)

- Lumière (temp)

- Cubes

- Tourelle


Ghost

Discrétion/Sniper

Sniper/Gauss

- Invisibilité (temp)

- Marquer la cible (zone, temp)

- Peut voir le chrono des vagues d’ennemis

Soldier

Bourrin

Shotgun/ Machine Gun/ Melee

Liste d’armes (mélée, arme principale, grenade)

- Augmenter dégâts (temp, zone)

- Poser munitions (zone)

- Grenade


Mentalist

Pouvoir mentaux

Mind blast (dégats -, cible unique)

Explosion (dégats moyens, zone -)

- Assomoir (zone)

- Arrêt du temps (zone, temp)

- Télékinesie

- Conversion (temp)

- Plus le stress augmente, plus le cooldown des habilités est long.

- Chaque personnage aura une lampe torche pas puissante.

- Effet de grain lors de l’arrêt du temps.

- Augmente niveau d’alerte si énigme échouée

- Vague déclenchée si augmentation de niveau de stress

Jeu en lui-même :

- Comateux

- Champion de boite à savon dans le coma : sauvez-le !

- Forêt : (ennemis à partir d’un certain point, pas direct au début)

- X chemins différents (1 ou 2 ennemis)

- Epreuve : passer au travers d’un campement

- Porte (couleur/switch) -> dans le bâtiment. Arrivée dans un sas : porte ne s’ouvre que si les 4 sont arrivés.

- Intérieur :

- 2 énigmes (au plus) :

  • Dans le noir avec des questions aléatoires (+ agression)

  • Enigme musicale


Décisions :

- 4 classes retenues

- Scène extérieure (courte) dans la forêt, scène intérieure (longue) dans un bâtiment

- 3 énigmes + 1 boss final. A chaque fois, purification de la zone.

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


Ordre du jour :

- Conventions

- Résumés

- Brainstorming titre

- Débat PhysX / Havoc / CEGUI

- UML

- Présentation du 28 Janvier
-Conventions :

Camel case : afficherObjetCaca();  variableAllo;

Nom de la classe : Commence par une majuscule. 

Membres de classe : avec m en préfixe
ifndef NOMDECLASSE_H

constantes MAJUSCULES

macro MAJUSCULES
foo()

{

code

}
Indentations : TAB
Mots clés public, private, etc collés a gauche et regroupés

Header de classe : Auteur(s), Date de Création, Description

\brief pour les fonctions/classes pas claires

Commentaires sur SVN à chaque commit !

- PhysX vs Havoc : à déterminer le plus tôt possible…

- UML :

Modulaire / Programmation par composants : tout le monde d’accord là-dessus.

Switch entre les modes de jeu caméra dessus/FPS.

Les 2 modes accessibles à toutes les classes. Définir plus précisément chacun pour chaque classe…
Architecte génère des cubes (un seul, mur, pyramide). Génère les cubes à une distance fixe au dessus du sol. A priori ils pourront exploser. Architect et psionicist pourront placer les objets en vue de dessus, les objets se mettant à une distance fixée au dessus du sol ou objet en dessous.

Fenêtre de débug, console en mode débug? Voir la fenêtre de François du semestre dernier.

XML default et non default à intégrer.

Penser à l’IA bientôt !

- Présentation :

Equipe (personnes) + artistes

Projet (concept de jeu)

Architecture et remarques pertinentes + job artiste

Outils (les non-obligatoires)

Conclusion + Apéro !

- Prochaine réunion : Mercredi 19 Janvier 2011 10h45.

- Poursuivre débat sur les librairies

- Réseau

- UML

Décisions :

- Conventions établies

- PhysX vs Havoc : il faut se décider sous peu !

- UML : début d’architecture

- Plan approximatif de la présentation établie

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


Ordre du jour :

- Poursuite du débat sur les librairies

- Design module réseau

- UML plus poussé


  • Librairie :


CEGUI vs Mygui :

CEGUI, besoin d’utiliser les sources d’Ogre et de compiler tout en même temps. Outil de création pas très facile. Mygui a l’air pas si pire. Pas encore testé. A confirmer.
Havok vs PhysX :

la discussion continue…



  • Design module réseau


Cas de joueurs séparés ? Comment gérer la physique impliquée par cette séparation?

Serveur dédié ou hôte? Si serveur dédié en parallèle du client (sur la même machine), le calcul de la physique est-il vraiment x 2 ?

Comment faire la synchro des clients avec le serveur? On ne peut pas envoyer le monde physique entier…


  • Prochaine réunion : Lundi 24/01 à 13h.


Décisions :

- Serveur dédié ou hôte : à déterminer.

- Se pencher sur le problème de la synchronisation.

- Choisir entre CEGUI/MyGui et PhysX/Havok.

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


Ordre du jour :

- Librairies

- Présentation

- UML
- PhysX vs Havoc : PhysX acccessible mais peu complet sur la partie animation. Il reste pas mal de choses à rechercher pour savoir si il dispose de tout ce dont dispose Havok.

Havok semble bcp plus complet sur certaines parties (Animation notamment) mais plus complexe. Il demandera plus d’investissement de la part de l’équipe pour découvrir la doc.

Choix (sauf gros problème) : Havok.

- Présentation :

0- Intro

1- Equipe (personnes) + rôle

2- Projet (concept de jeu)

3- Architecture et remarques pertinentes

4- Outils (les non-obligatoires)

5- Conclusion + Apéro !

  1. Intro : FO

  2. Nom, champ d’action, autres : ALL

  3. Concept : FL. Réseau, environnement… Basé sur classes de personages (lvl) / armes / pouvoirs

Classes :

JC : architect

FO : ghost

FB : soldier

JF : psionicist

Gameplay :

JF : Coop

FPS / + ou – god view (alien swarm, lara croft)

Enigmes (Lara Croft)

Vagues d’ennemis (L4D)

JC : Niveau de stress (ondes cérébrales)

IA/Gestion des cas :

FO : Pas d’IA allié, IA ennemie (2 types d’ennemis).

  1. FO : UML basique. Débat réseau : serveur dédié ou hôte ?

  2. FL : Ogre, CEGUI, Raknet, FMOD, Havok. Si possible Hammer, assets HL2.

  3. FB : Conclusion. Mettre un tableau récapitulant minima, maxima de notre projet. Mettre le lien vers le wiki. « On est tjs à la recherche de nouveaux talents, de femmes et de bière. Posez vos CV en sortant ! »

- Gestion des cas :

Si 4 joueurs : 1 classe différente par personnage. Si 8 : un homme/une femme par classe. Pour un joueur, pas de restriction.

- Serveur dédié ou hôte ?

Poser la question concernant le calcul de la physique sur la même machine qui serait à la fois client et serveur.

- UML :

Voir le wiki, page de cette réunion

- Prochaine réunion : Mardi 25 Janvier 2011 16h-17h.

- UML
Décisions :

- Sauf gros problème, on prend Havok !

- Plan de la présentation et répartition

- UML un peu précisé

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


Ordre du jour :

- Daily

- Questions Patrick

- Présentation

- Question :

Intervalle de synchro (prédiction, interpolation, ping compensation)

Dédié vs Hôte : dédoublement du traitement physique (si hôte)

Programmation par composante

Physique située où ?

IA située où ?

- Prochaine réunion : Mercredi 26 Janvier 13H30.

- UML

Décisions :

- Questions pour Patrick

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


Ordre du jour :

- Daily

- UML

- Présentation

- UML :

Network :

Transmettre tous les events (y compris mouse) + GameMode

Si problème synchro : on resynchronise tout le monde/le pauvre type en retard ? Synchro sur hôte.

Resynchro dans les zones tampons/durant les pauses si on en fait.

Noms des joueurs à l’init de la partie

L’hôte décide quand le partie commence.

Physique : locale

IA locale et spawn des ennemis déterminé aléatoirement par le serveur (juste seed ?)

Position initiale des joueurs déterminés par leur numéro client.

Bouton magique pour le resynchro (les joueurs doivent peser sur une touche).

Prog par composante :

Entity ::vector

ComponentFactory : une seule, singleton.

ComponentManager : a un vector de toutes les components de son type.

- Prochaine réunion : Jeudi 27 Janvier 13H00.

- Présentation

- UML

Décisions :

- Network avec le serveur qui transmet les évènements et resynchronise à l’occasion.

- Programmation par composantes : Entity avec vector+ Component Manager + ComponentFactory

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


Ordre du jour :

- Daily

- Retour sur la présentation

- UML

- UML :

- Chaque classe de component :

ID static

Méthode virtuelle pour récupérer l’ID (pas static)

- Lien entre les components :

  • On passe par l’entity

  • Méthode pour récupérer « tel component » (paramètre ID)

  • Enum global pour regrouper les ID

- Factory + Manager :

- Se poser la question : doublons de composantes ? Enabled/Disabled (toujours une seule active)

- Attribut de chaque entité : ID. static int ID qui s’incrémente à chaque création d’objet. Manager d’ID ?

- Serialize : méthode de chaque component

- Deserialize : méthode dans un singleton
Components :

Physics :

  • Attribut : Agent

ManuallyMoveable :

  • transform()

Graphic3D :

  • Attribut : model3D (conteneur)

  • draw()

Graphic2D :

  • draw()

Billboard :

  • Attribut : texture

  • draw()

Network :

  • Sert à récupérer toutes les entités à envoyer sur le réseau par le component manager.

IA :

  • Attribut : FSM

I/O


Pour Patrick :

Factory + Manager

For_each(begin(), end(),…)

Doublons et enable/disable

Deserialize
Idées de gameplay :

  • Pouvoir de fear

  • Ennemi marqué par le pouvoir du ghost s’enfuit

  • Pouvoir de scale



- Prochaine réunion : Mercredi 2 Février 10H00.

- Composantes si nouvelles idées

- Fin d’itération

- Début d’itération
Décisions :

- Factory et Manager templates

- Serialize : méthode de chaque component

- Deserialize : méthode dans un singleton

- Chaque classe de component représentée par un ID (enum global pour les regrouper)

- Chaque Entity marquée par un ID

- Quelques composantes énumérées

similaire:

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

Réunion du 2011-01-10 iconRéunion du 23-03-2011

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

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

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

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

Réunion du 2011-01-10 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-01-10 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-01-10 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-01-10 icon2011 tiemele 01/01/2011 Groupe de Diagnostics Groupe de Diagnostics...








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