DemiSel 61a576fc1d Revert "Revert "Revert "Revert "Revert "Premier essai shader mais jte jure jcomrpend rien\n(est-ce que ça marche même antislash n sur git ?) bref le shader est dans Effects/wMaillage machin truc""""" | 4 år sedan | |
---|---|---|
FreeCam | 4 år sedan | |
.gitignore | 4 år sedan | |
README.md | 4 år sedan |
Pour rappel, le jeu est un party game (coop local en écran scindé) où les joueurs s’affrontent dans une arène. Le concept étant que les joueurs s’affrontent au dessus du vide et peuvent s’aider de plateformes (blocs) comme couverture, pont, escalier, … Ils essayeront de se faire tomber dans le vide. Ils poseront eux-même les plateformes en question. Pour cela le jeu se déroule en 2 phases, une première où les joueurs naviguent dans la zone de jeu en feefly pour poser des blocs dans un temps imparti, chacun d’eux dispose du même inventaire de blocs qui pourra être déterminé aléatoirement. Une fois le temps écoulé, les joueurs prenennt le contrôle d’un avatar et se mettent à faire la bagar en vue FPS. Ils disposent d’une arme qui tirent des projectiles infligeant un recul aux entités dans un certain rayon au point d’impact. Au bout d’un certain temps de jeu les blocs commencent à disparaître aléatoirement. A ces règles de base peuvent s’ajouter plein de briques de gameplay (des modificateurs de parties, choix de différentes armes, possibilités aux joueurs d’ajouter leur propres blocs via des fichiers de modèles 3D, configuration de la partie : durée des phases, taille de l’inventaire, …).
Le but du Repo est de servir de laboratoire pour créer divers prototypes, tester différentes mécaniques et les mettre en commun. On pourrait faire un autre Repo pour tout ce qu’on décide de valider afin d’avoir une version propre de notre jeu quelque part. Dans un monde professionnel on utiliserait des branches DEV et PROD mais vazy comme c’est chiant (bon j’ai fini par faire une branche DEV mais j’ai la flemme de retaper le readme). Les différents aspects du jeux peuvent être traités différemment dans un premier temps. Un projet Unity peut servir à tester le développement d’une phase de jeu (Build ou Bagar), le développement des armes, le développement d’un game master qui gère les différents joueurs, l’enchaînement des phases etc., les différents menus de l’application etc…
Essayons d’en voir le bout un jour.
Au fait, si t’as lu jusqu’ici, tu tournes ! Haha c’est ce que j’aurai dit si j’étais un connard d’Enibien