Comptes rendus Itération 1 (10 jan- 25 jan)
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é
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…
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 !
Intro : FO
Nom, champ d’action, autres : ALL
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).
FO : UML basique. Débat réseau : serveur dédié ou hôte ?
FL : Ogre, CEGUI, Raknet, FMOD, Havok. Si possible Hammer, assets HL2.
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 :
ManuallyMoveable :
Graphic3D :
Attribut : model3D (conteneur)
draw()
Graphic2D :
Billboard :
Network :
Sert à récupérer toutes les entités à envoyer sur le réseau par le component manager.
IA :
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 |
