Discussion :

[Neckara]

Bonjour,

Je pense que vous me connaissez déjà, pour ceux qui ne me connaissent pas, je suis le type qui ouvre un sujet sur ce forum tous les 6 mois en disant à quel point il a appris de ses erreurs, qu'il s'est amélioré et que cette fois c'est la bonne. Il poste quelques nouvelles pendant 1-2 semaine, revient de temps en temps pour se plaindre de ne pas avoir assez de temps puis on a plus de nouvelles pendant quelques mois avant de revenir créer un nouveau sujet.


Et bien devinez quoi… J'ai appris de mes erreurs, je me suis amélioré et cette fois c'est la bonne !


Plus sérieusement, au lieu de créer un nouveau sujet à chaque fois, je pense n'en utiliser qu'un seul pour dire un peu ce que je fais pendant mes soirée de dev et pourquoi. Donc je fais un peu ce que je veux, je passe 2 soirée à dev sur LastGo, je dis rien pendant 5 mois et je passe une soirée sur Last_nom_du_nouveau_projet_révolutionnaire.
Ainsi, j'espère éviter de flooder le forum de sujet et vous permettre de mieux vous y retrouver. C'est mieux que d'avoir une petite dizaine de sujets traînant dans les bas-fond du forum.

[Neckara]

LastGo est une sorte de jeu de plateau en 3D.

Mais j'ai un petit problème de développement :

• si je code uniquement la logique du jeu (ie les règles), j'ai beaucoup de travail sans pouvoir montrer grand chose. Ce n'est pas très valorisant non plus.
• si je m'occupe de l'interface graphique, cela a tendance à prendre beaucoup de temps. D'autant plus si je veux utiliser emscripten pour vous montrer facilement le résultat de mon travail écrit en C++11 via navigateur.

J'ai trouvé une petite solution, de la 3D en console :

Joueur 1 contre Joueur 2.

Vous la voyez la 3D ?
C'est la représentation d'un cube de 3x3 en 3D que j'ai généré à partir d'une "carte" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
static const std::string map = {
    "          o p q                \r\n"
    "          | | |                \r\n"
    "        d-0-0-0-f              \r\n"
    "          | | |                \r\n"
    "        e-0-0-0-g              \r\n"
    "          | | |                \r\n"
    "    d e   0-0-0   g f q o p    \r\n"
    "    | |  /| | |\\  | | | | |    \r\n"
    "  a-0-0-0-0-0-0-0-0-0-0-0-0-a  \r\n"
    "    | | | | | | | | | | | |    \r\n"
    "  b-0-0-0-0-0-0-0-0-0-0-0-0-b  \r\n"
    "    | | | | | | | | | | | |    \r\n"
    "  c-0-0-0-0-0-0-0-0-0-0-0-0-c  \r\n"
    "    | |  \\| | |/  | | | | |    \r\n"
    "    h i   0-0-0   k j n m l    \r\n"
    "          | | |                \r\n"
    "        i-0-0-0-k              \r\n"
    "          | | |                \r\n"
    "        h-0-0-0-j              \r\n"
    "          | | |                \r\n"
    "          l m n                \r\n"
 
 
};

L'avantage, c'est qu'en à peine 1h, j'ai une interface graphique (sans rien derrière) qui me permet de vous montrer tout ce que je fais. De plus, si je veux rajouter des éléments graphique, rien de plus simple, c'est très rapide. Le seul problème, c'est que la coloration ne passe pas sur emscripten .
Donc je peux me concentrer sur l'essentiel : la logique du jeu.
Une fois fini, je pourrais passer tout le temps nécessaire à réécrire l'interface graphique.

Un autre avantage, c'est que c'est très pratique pour le débogue, j'ai une vision d'ensemble, que je ne pourrais pas avoir si j'étais en 3D. En effet, je ne pourrais pas voir les faces opposées du cube.


Je reconnais que j'ai légèrement triché pour la coloration.
Je ne tiens pas compte des "liens" pour les relations de voisinages entre deux "cases" (ie "0"). Mais ce n'est pas le plus important pour le moment, le tout est d'avant tout avoir un affichage.

Ainsi, je peux commencer à écrire la représentation de l'état du jeu. Puis le tester en l'affichant.
Ensuite tester l'évolution de l'état du jeu et enfin écrire les règles du jeu.


Et vous, avez-vous déjà utilisé un affichage "simplifié" pour vos jeux 3D afin de faciliter leur développement ?

[Iradrille]

Vous la voyez la 3D ?
C'est la représentation d'un cube de 3x3 en 3D que j'ai généré à partir d'une "carte"

J'ai aucune idée de ce que je regarde, il est de quelle couleur le cube ?

Et vous, avez-vous déjà utilisé un affichage "simplifié" pour vos jeux 3D afin de faciliter leur développement ?

Pour du jeu non (j'ai jamais créé de jeu donc forcément...), pour le reste oui, tout le temps. L'interface graphique / l'affichage je m'en occupe à la fin.
Un affichage console (voir aucun affichage et allez fouiller avec un débogueur) est souvent suffisant.

[Lady]

Ce serait plus simple pour se représenter le cube avec une police "carrée" (hauteur = largeur) mais c'est effectivement intéressant la représentation à plat.

Alors que faut il te souhaiter : Aller cette fois c'est la bonne !! (Ou pas ...)

[Neckara]

J'ai aucune idée de ce que je regarde, il est de quelle couleur le cube ?

En gros, c'est un cube "déplié".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
   F5
    |
F1-F2-F3-F4
    |
   F6

Chaque face est un carré de 3x3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
0-0-0
| | |
0-0-0
| | |
0-0-0

"1", c'est quand le joueur 1 a joué sur un "0", et "2" quand c'est le joueur 2.
La couleur délimite un "groupe" de "1" ou de "2" "voisins".

Pour les lettres, grosso-modo si on a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
0-a
a-0

Cela veut dire que les deux "0" sont voisins. Cela m'évite de devoir faire de longues lignes composées de "-" ou "|" qui se croisent.
Quand tu découpes un cube dans du papier, c'est en gros les petites languettes que tu vas coller pour avoir un cube en 3D.

Ce serait plus simple pour se représenter le cube avec une police "carrée" (hauteur = largeur)

Très bonne idée . Il faudra juste que je change la configuration du terminal pour faire mes tests ou que je trouve un moyen de le faire via une API quelconque sous Linux.

[maeiky]

Où en est le développement de LastEngine? Y a t'il des sources disponibles?

Personnellement je préfère que tu remonte les vieux sujet, au lieu que de créer un sujet pêle-mêle, car tout ce que tu as écris peu être consulté en rapport avec celui -ci.

À moins évidement que tu ne fasse que des petits projets sur un coup de tête.

[Neckara]

Où en est le développement de LastEngine?

En pause/abandonné.

C'est un projet très coûteux en temps de développement. J'ai malheureusement moins en moins de temps libre. Sans compter qu'en plus du développement, il faut en plus écrire de la documentation, des tutoriels, etc.

De plus, il est très difficile d'y travailler juste 1h ou 2h quand l'envie m'en prend. Déjà parce qu'il faut se replonger dans le code, et ensuite parce que je ne peux pas vraiment avancer en 1h ou 2h. Il faudrait que je puisse me prendre tout un après-midi, régulièrement, pour que ce soit vraiment "confortable".

Je préfère donc me pencher sur un jeu "tout bête" sans prise de tête pour me la vider.

Y a t'il des sources disponibles?

Je n'ai pas mis les sources en lignes, mais si tu es intéressé, on peut en parler sur Skype.
Quitte à te donner les sources, et en l'absence de documentation, ce serait bien que je t'explique rapidement le fonctionnement.

Normalement, le système de module était fini, il manquait plus qu'à encapsuler des bibliothèque ou à écrire les premiers modules vraiment utiles pour la création de jeux.

À moins évidement que tu ne fasse que des petits projets sur un coup de tête.

Mon but n'est pas vraiment de présenter directement mes projets, mais de dire ce que je fais et pourquoi. Je pense que je vais surtout travailler sur LastGo, mais je ne garanti pas que demain je passerais à autre chose.
Je ne veux pas écrire sur un sujet dédié au projet, déjà parce que j'en crée un à chaque reboot d'un projet. J'en ai donc déjà plus d'une dizaine, dont certains bien enterré dans ce forum que je ne pense pas être capable de retrouver .
Mais surtout, je ne veux pas avoir à faire "vivre" un tel sujet de présentation, à essayer de donner des nouvelles régulièrement. Je veux vraiment coder sur un coup de tête :
"fuck les cours, dev powaaa !!!" *envoie balancer ses cahiers à l'autre bout de son 20m²*.

Si j'utilise un sujet dédié, je vais me sentir obligé d'avoir une progression régulière, et je ne le veux pas ni ne le peux. Ce que je veux aussi, ce n'est pas forcément dire ce que j'ai codé, mais surtout dire pourquoi je l'ai fait de cette manière ou pourquoi j'ai pris cette décision. Je trouve que c'est un exercice intéressant.

[Dabou Master]

Je trouve que c'est un exercice intéressant.

Pour l'instant .

[maeiky]

À ce que je voie ton projet LastEngine semble être la base de tout.

Il est vrai, que dans un premier temps je suis passé de "Last Dungeon" à "Last DunGo" à "Last Engine" à "Last Escape".
4 projets en 4 ans, c'est pas énorme.

Le premier changement de projet était nécessaire, "Last Dungeon" étant beaucoup trop ambitieux.
J'ai fini un prototype jouable de "Last DunGo", mais je voulais le réécrire plus proprement avec un moteur d'où "Last Engine".
Après, ce moteur, il faut l'écrire, le tester et l'éprouver, d'où "Last Escape".

Je n'ai donc que deux projets pour le moment : "Last Engine" et "Last Escape" que je fait évoluer en parallèle.
En effet "Last Escape" utilisant "Last Engine", bosser sur "Last Escape" revient à écrire et tester des modules pour "Last Engine".

Donc en développant LastGo (Last DunGo?) tu dévelope LastEngine, ce qui te semble une tâche énorme, mais en réalité tu pourrais te concentré que sur Last Engine qui me semble prometteur.

Où en est le développement de LastEngine?

En pause/abandonné.

C'est un projet très coûteux en temps de développement. J'ai malheureusement moins en moins de temps libre. Sans compter qu'en plus du développement, il faut en plus écrire de la documentation, des tutoriels, etc.

Pourtant tu semblais dire que ce n'était que quelques centaines de lignes de code :

Mais le noyau doit être le plus indépendant possible sinon c'est le serpent qui se mord la queue.

Enfin bon :

le noyau du moteur, c'est quelques dizaines de lignes ;
le système de module c'est relativement petit et il n'existe pas de normes C++ à ce sujet. Pas sûr qu'il existe de bibliothèques matures équivalentes.
le noyau de tests, c'est quelques centaines de lignes, mais d'un autre côté, je pense que j'invente 2-3 trucs ^^.

Concentre toi sur un seul projet et tu ne manqueras pas de temps.

Donne lui une LastChance ...

[Neckara]

À ce que je voie ton projet LastEngine semble être la base de tout.

C'était à la base mon idée initiale. Mais comme développer le moteur est trop coûteux, je développe pour le moment LastGo sans m'appuyer sur aucun moteur.

Pourtant tu semblais dire que ce n'était que quelques centaines de lignes de code

Le cœur du moteur, oui.

Mais derrière, il faut tout découper en modules, donc avoir une certaine rigueur. Dans l'esprit du moteur, si je veux utiliser une bibliothèque externe, il faut que je l'encapsule, tout cela demande énormément de temps. Sans compter les tests, les tutoriels, les push sur le git, la communication, c'est beaucoup trop de travail pour moi.

Là je veux juste me détendre quand j'arrive à me trouver un peu de temps libre, et faire un petit jeu/prototype sans prise de tête. Après, je ne dis pas que si je développe un autre jeu, je ne vais pas factoriser du code ou découper en module. Ce serait une autre approche pour créer LastEngine.
Mais je ne garanti rien, pour le moment, je code juste sur un coup de tête.

mais en réalité tu pourrais te concentré que sur Last Engine qui me semble prometteur.

Merci

Je ne peux pas me concentrer uniquement sur le moteur sans l'éprouver, il faut que je teste, voie de quelles fonctionnalités j'ai besoin, si elles sont agréable à utiliser, etc.

Concentre toi sur un seul projet et tu ne manqueras pas de temps.

Je n'ai pas de temps même pour un seul projet.

De plus, LastEngine demande plus de temps que LastGo à cause des encapsulation de bibliothèque etc. LastGo me motive aussi un peu plus et me paraît plus valorisant pour moi-même que LastEngine. C'est plus confortable, j'en tire plus de plaisir.

Si je code un peu pour LastGo, c'est surtout que je peux y passer 10 minutes un soir sans aucun problèmes. Avec LastEngine, c'est impossible, ne serait-ce que le temps de retrouver où j'en étais exactement depuis la dernière fois.
L'autre raison pour laquelle j'ai choisi LastGo, c'est que j'ai réussi à me passer le l'aspect 3D qui me bloquait un peu et qui me fait gagner énormément de temps.

Donne lui une LastChance ...

Je ne peux pas, je me fais déjà plus de 50h (dont 40 à 47h de cours) par semaines, et cette semaine, je vais devoir me faire du 70h (dont des cours que je dois suivre via internet, des TPs/devoirs, et des révisions pour des exams qui arrivent…).
Mon temps libre, c'est quand je me dis "fuck les cours" ou que je pars courir pour me bouger les jambes.

Dans quelques mois, années, peut-être, mais pas aujourd'hui.

[Neckara]

Pour l'affichage, ma classe GamePrinter demandait à chaque affichage l'état du jeu à une classe GameState.
Cela m'a permis d'avoir très rapidement un aperçu de l'interface graphique que j'aurais. Mais ce n'est pas très optimal dans le sens où je dois tout reparcourir et tout ré-afficher à chaque fois.


J'ai donc supprimé cela et donné à GamePrinter quelques fonctions que je peux appeler :

• poser un pion ;
• fusionner des groupes de pions ;
• détruire un groupe de pions.

Ainsi, je peux avoir un petit buffer dans GamePrinter et ne modifier que le strict nécessaire avant d'afficher ce buffer. C'est donc beaucoup moins coûteux. Mais ce n'est pas tout.

Déjà, je n'affiche plus un état donné du jeu, mais un événement. C'est à dire que je peux donner du sens à ces événements, au lieu d'afficher bêtement ce qu'on me demande d'afficher. Je peux ainsi éventuellement afficher une petite animation lors de certains événements, par exemple jouer un son quand on pose un pion.

Mais si j'envoie un événement à GamePrinter, je peux aussi lui envoyer le contraire de cet événement.
C'est à dire appeler "retirer un pion", au lieu de "poser un pion", c'est à dire annuler une action.
Et si je mets un événements et son inverse au sein d'une même structure, j'ai une action que je peux faire, défaire et refaire. Et si j'ai un ensemble d'actions, j'ai un historique !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class History
{
public:
    History();
 
    class Action {
    public:
        virtual void redo(void) = 0;
        virtual void undo(void) = 0;
        virtual ~Action() = default;
    };
 
 
    void execute(Action & action);
 
    void undo();
    void redo();
    void redoAll(int time = 0);
    void undoAll(int time = 0);
private:
    std::stack<Action *> m_history;
    std::stack<Action *> m_canceled;
};

C'est à dire que je peux revenir en arrière, "aller en avant"… et pourquoi pas enregistrer une partie, et la rejouer plus tard sur un autre ordinateur, comme si vous regardiez un replay !
Cela prend beaucoup moins de mémoire que d'enregistrer ou envoyer l'état complet du jeu, ce qui peut être aussi très intéressant pour d'éventuelles parties en réseau.

C'est très aussi très pratique pour mes tests/déboque, je peux m'en servir à créer des robots très basiques dont les actions sont déjà déterminés à l'avance.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
int main(void) {
 
    cli::GamePrinter gp;
    gp.setMap(map);
 
    History history;
 
 
    new Action::PutPawn(gp, 0, 1, history);
    new Action::PutPawn(gp, 1, 1, history);
 
 
    std::set<cli::GamePrinter::PedestalID> ids;
    ids.insert(1);
    new Action::Fusion(gp, 0, ids, 1, history);
 
 
    new Action::PutPawn(gp, 9, 1, history);
 
    std::set<cli::GamePrinter::PedestalID> ids2;
    ids2.insert(9);
    new Action::Fusion(gp, 0, ids2, 1, history);
 
    std::set<cli::GamePrinter::PedestalID> ids3;
    ids3.insert(0);
    ids3.insert(1);
    ids3.insert(9);
 
 
    new Action::RemovePawns(gp, ids3, 1, history);
 
    history.undoAll();
 
    while(1) {
        history.redoAll(2000);
        history.undoAll(2000);
    }
}

@Cirrus Minor : t'as vu ? moi aussi j'ai découvert les gif

Et vous, utilisez-vous un système d'historique similaire dans vos projets ?
Si oui, dans quel but l'utilisez-vous ? Annuler des actions ? Enregistrer des parties ? Jouer des parties pour déboguer ?

[Cirrus Minor]

@Cirrus Minor : t'as vu ? moi aussi j'ai découvert les gif

Héhé, tu vas voir, on peut plus s'en passer !

Sinon, je trouve que c'est une bonne idée de te concentrer sur le jeu.
Programmer un moteur/framework de jeu ou une bibliothèque multimédia, c'est très intéressant, mas c'est un boulot ultra-chronophage et interminable (n'est-ce pas maeiky ? ).
De plus, je pense qu'il y a plus de chance que des personnes jouent à ton jeu (quand tu auras un prototype jouable) que de personnes qui utilisent ton moteur - sans vouloir juger ce que vaut le tien, il y a beaucoup de développeurs qui publient leur moteur/framework, mais sans trop de succès en raison de ceux qui se sont imposés depuis des années, qui sont bien documentés, qui ont une communauté, etc...

[Neckara]

Je suis très motivé ces derniers jours (ou plutôt pas motivé pour bosser…).

Désormais, je mets en valeur le dernier pion posé (ou retiré lors d'un "undo").

Je viens aussi d'ajouter quelques événements :

• passer son tour ;
• abandonner ;
• changer de tour ;
• terminer la partie ;
• changer le score ;
• désigner le vainqueur.

Certains événements restent limités, par exemple, je ne donne pas de classement à la fin de la partie.
D'un autre côté, je ne fais pas l'interface finale, juste une interface de dev/test.

Certains événements sont fortement liés, par exemple "passer son tour" induit un "changer de tour". Mais je garde GamePrinter aussi bête que possible, il fait ce que je lui dit de faire sans se poser de questions. Ce sera à moi, lorsque j'écrirais les règles, de lancer "changer de tour" lorsque je lancerais un "passer son tour".
Ceci permet de garder GamePrinter aussi simple que possible, mais surtout de ne pas lui donner de règles qui pourraient par la suite se retrouver erronées dans des conditions particulières. De plus, ce n'est pas à la classe d'affichage de gérer les règles, ce n'est donc pas sa responsabilité.


Je suis sûr que Player 1 triche…

[maeiky]

Programmer un moteur/framework de jeu ou une bibliothèque multimédia, c'est très intéressant, mas c'est un boulot ultra-chronophage et interminable (n'est-ce pas maeiky ? ).
De plus, je pense qu'il y a plus de chance que des personnes jouent à ton jeu (quand tu auras un prototype jouable) que de personnes qui utilisent ton moteur - sans vouloir juger ce que vaut le tien, il y a beaucoup de développeurs qui publient leur moteur/framework, mais sans trop de succès en raison de ceux qui se sont imposés depuis des années, qui sont bien documentés, qui ont une communauté, etc...

Je suis d'accord, surtout en voyant le succès de ton jeu, j'aurais sans doute pu faire un jeu complet en beaucoup moins de temps. Si j'aurais su dès le début tout l'effort requis, je ne me serais jamais lancé dans une idée aussi folle

Ça dépend aussi du fait d'arrivé à trouver de l'aide ou pas, du coup la tâche serait bien plus aisé.
Mais trop d'effort y ont été apporté pour tout abandonner, ça prend juste le courage pour aller jusqu'au bout.

Faire un jeu apporte une satisfaction rapidement, on voie directement le concret de la chose. Il faut tout de même partir sur une bonne idée et juger la faisabilité, car un jeu peu facilement se vouer à l'échec également.

Mais je disais cela, car il me semblait que le moteur LastEngine était presque fini.

[Neckara]

Ça dépend aussi du fait d'arrivé à trouver de l'aide ou pas, du coup la tâche serait bien plus aisé.

Personnellement, je perds souvent plus de temps à rechercher de l'aide ou en ayant de l'aide que sans.

Mais là j'avance super vite, bien plus que je ne l'aurais pensé, ne pas avoir d'interface graphique et de ne pas prévoir tous les cas particuliers (plusieurs joueurs/équipes), me fait progresser très vite.

Mais je disais cela, car il me semblait que le moteur LastEngine était presque fini.

Un moteur est jamais réellement fini .

[Neckara]

Bonjour,

Vous l'avez remarqué, je ne suis plus très actifs ces derniers jours. Je n'ai pas vraiment travaillé sur le projet LastGo depuis, je n'ai pas donné de nouvelles pour les archives de projets ou les JD Lives.
Je vais donc faire un petit point ici.


Pour ceux qui ne me connaissent pas, je suis 3 formations en même temps et je souhaiterais continuer par une thèse. Pour proposer une thèse, un labo public doit proposer un sujet et un candidat afin de recevoir les subventions nécessaires. Le classement du candidat influe sur la possibilité du labo pour avoir les subventions ou non. Un mauvais candidat ferait baisser le labo dans la "liste" qui risquerait alors de ne pas avoir les subventions.

Bon, rien de bien grave, il suffit juste d'être dans les premiers, rien de vraiment nouveau. Sauf que pour une des thèses que je vise, j'ai un concurrent, je dois donc essayer d'être "meilleur" que lui, qui ne fait qu'une seule formation, pour me donner plus de chances, donc fournir beaucoup plus travail et faire tout ce qui est travail facultatif. À côté, j'ai des projets d'école et je suis un peu en retard sur l'un d'entre eux.

Sachant que derrière le temps passe très vite et que j'ai quelques problèmes à travailler efficacement les WE. Donc pour le moment, je préfère éviter de travailler sur des projets "extra-scolaire". Je vais cependant essayer de finir ce que j'avais commencé pendant les vacances de noël.
Ce n'est pas tant que je n'ai pas le "temps" pour cela, mais que je ne me motive pas assez pour travailler les soirs et les WE, je n'ennuie et ne veux rien faire. Je pense que je suis juste un peu fatigué, pour la première fois je n'ai pas eu de vacances de la Toussaint donc n'ai pas pu en profiter pour me reposer. Heureusement noël arrive.


En théorie, tout devrait être fini début mars, moment de mon début de stage. ~40h de stage par semaine, un peu de travail à côté pour les rapports et de révision pour une de mes formations. Éventuellement de la recherche de thèse et un peu de travail les soirs/WE pour le stage. J'espère que j'aurais un peu plus de temps "libre" et que je serais un peu plus motivé pour travailler et donc aurais un peu plus de temps pour des activités annexes.

Après c'est 3ans de thèses puis des post-doc / travail de recherche… je ne sais pas du tout s'il sera facile de tracer une limite claire entre travail en semaine et vie privée/projets annexes les WE. C'est un peu difficile car je ne bosserais pas pour un patron, mais avant tout pour moi-même, pour publier des articles, aller à des conférences, avoir des subventions, etc. Le problème n'est pas tant de se reposer le WE, mais de culpabiliser ensuite de l'avoir fait alors qu'on a tant à faire (et ensuite de culpabiliser sur le fait de passer plus de temps à culpabiliser/s'en vouloir qu'à travailler ).

Plus sérieusement, il faut juste que je gère un peu mieux mon temps et qu'éventuellement je me repose. Et j'espère que d'ici mars, j'aurais moins de problèmes, moins de choses à faire et donc plus de temps pour moi sans culpabiliser et serait un peu plus reposé.


Donc pour ce qui est prévu, je vais publier une vidéo du JD Live pour noël et distribuer une version de l'archive jeu pour noël, mais ne pense pas retravailler dessus d'ici mars. Me connaissant, je vais très certainement péter un plomb d'ici là et travailler tout de même dessus pendant un WE .
Début mars, je pense que j'aurais un peu de temps libre, donc je risque de retravailler dessus, à voir si cela durera.

N.B. Je pense que je dois avoir plus de posts pour me plaindre que je n'ai pas assez de temps pour mes projets que de posts pour présenter mes projets.

[Dabou Master]

Oui donc en gros tu as juste besoin d'une petite équipe de volontaires pour conserver une dynamique.
Et non je ne me propose pas, j'aimerais déjà avoir le temps de faire ce pour quoi j'ai donné ma parole que je n'arrive pas à tenir actuellement ...
Je te souhaite bon courage, mais je pense que tu devrais lancer un appel à l'aide dès maintenant car viendra un moment où tu n'auras même plus la force de le faire .
Le temps on ne l'a jamais plus arrivé à un certain stade, il faut sacrifier des choses pour en faire d'autres à la place. Prends l'exemple de Vetea tiens, lui il a décidé d'arrêter de dormir/manger/respirer pour faire toutes ses activités annexes .

[Neckara]

Le temps on ne l'a jamais plus arrivé à un certain stade, il faut sacrifier des choses pour en faire d'autres à la place. Prends l'exemple de Vetea tiens, lui il a décidé d'arrêter de dormir/manger/respirer pour faire toutes ses activités annexes .

Étonnamment, cela marche plutôt bien.
Sans plaisanter, gagner 2 à 3h par soir, c'est presque gagner un mini-week-end, cela réduit le stress, on est moins fatigué donc on peut se coucher plus tard. Oui, Neckara vient d'apprendre qu'on pouvait se coucher après 21h et ne pas être fatigué le lendemain matin.


Actuellement, il doit me rester 3 semaines de cours et 2 d'examens, autant dire que j'ai beaucoup à faire. Mais alors qu'on se tapait parfois des journées de de 10-12h, 6j/7 (soit plus de 60h/semaine), les trois dernière semaines sont plutôt light (~28-32h, ).
Je pense maintenant que vous comprenez pourquoi je me lance dans des projets, les abandonne, les reprends, etc. On a des périodes très chargées, d'autres plus tranquilles, mais on ne le sait jamais vraiment à l'avance.


Bref, je ne sais même plus si je re-re-reprend ou re-re-re-reprend LastGo, j'ai un peu perdu le compte. C'est juste pour passer un peu le temps, coder quelques minutes si l'envie me prend (ou plutôt si j'ai pas envie de bosser).


Identification des étapes

Je viens donc de rouvrir le projet et je repasse derrière l'imbécile qui a tout mis dans un même dossier sans aucun diagramme de classe !
Je suis un peu perdu, je ne sais plus où j'en suis. J'ai plein d'idées, je sais ce que je veux à la toute fin, mais c'est trop de choses à penser et à prendre en compte.
Pour m'y retrouver, je fais un petit schéma des différentes étapes nécessaire à la réalisation du projet :

Puis, au fur et à mesure de mon avancement, j'écrirais pour une étape, les conditions permettant de valider cette étape. Par exemple, pour "règles du jeu", je listerais les règles.

Le gain est triple :

• en sachant à quelle étape je suis, je pourrais à tout moment savoir ce que j'ai fait et ce qu'il me reste à faire. Je ne serais plus vraiment perdu ;
• quand je suis dans une étape, je ne pense qu'à l'étape en cours, je ne me projette pas trop dans le futur et ne pense pas aux étapes suivantes ;
• je ne peux qu'avancer. Je ne peux pas revenir sur les étapes précédentes ou ajouter des conditions pour l'étape en cours. S'il y a des choses à ajouter, cela fera l'objet d'une nouvelle étape. Donc si j'ai une superbe idée, je la note et ne la regarderait qu'à la toute fin, plutôt que de modifier continuellement mon code à l'arrivée de chaque nouvelles idées.

Comme il y a des jours où on a absolument pas envie de travailler, continuons.


Un petit Trello pour les tâches


Je vais me créer un Trello pour détailler chaque tâches :

Le principe sera assez simple :

1. Je prend la première tâche de la liste "A faire", ici "Diagramme de classe" et la glisse-dépose dans la liste "En cours".
2. Je fais la première tâche.
3. Je déplace la première tâche dans la dernière liste, ici "V0.0 Reprise du projet" et la "coche" dans la tâche récapitulatif, ici "V0.0 Récapitulatif".
4. S'il reste des tâches dans la colonne "A faire", je recommence en 1.
5. Si toutes les tâches ont été faites, je déplace la tâche récapitulatif dans la dernière liste.
6. Je place la dernière liste avant la liste "A faire"
7. Je créé une nouvelle liste de tâche puis remplis la liste "A faire"
8. Et je recommence en 1.

Au final, cela devrait donner quelque chose du genre :

Voilà, maintenant, quoi de plus simple pour voir où on en était, ce qui a été fait, ce qu'il y a à faire et ce sur quoi on s'était arrêté d'un simple coup d'œil ?


Mise à jour du git


Mais après une pause de quelques mois, parfois difficile de se rappeler de tout ce qu'on avait.
Je vais donc ouvrir le README.txt du projet et ajouter toute ces nouvelles informations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Reprise du projet (23/01/2016)
 
Plus d'informations ici : http://www.developpez.net/forums/d1546580/applications/developpement-2d-3d-jeux/projets/petites-soirees-neckara/#post8509881
 
 
Plan : /doc/Steps.png
Trello : https://trello.com/b/0z1wshYY/last-go
Github : https://github.com/LastProject/LastGo

Inutile d'en faire plus pour le moment.
On va donc mettre à jour ces informations sur le github, et je me rend compte que je n'y ai jamais rien poussé dessus .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
cd /tmp
 
# On récupère le dépôt
git clone https://github.com/LastProject/LastGo
 
# On ajoute nos fichiers
cp -r CheminDeMesFichiers/* /LastGo
git add CMakeLists.txt doc/ README.txt src/Desktop/
 
# On donne un nom de commit explicite
git commit -m "V0.0 Reprise du projet : commit initial
 
Sources et documentation"
 
# On donne ses informations
git config user.name Neckara
git config user.email Neckara.LastDungeon@gmail.com
 
# On pousse tout cela sur github
git push
 
# On remet tout à sa place
cp -r /tmp/LastGo/* CheminDeMesFichiers
cp -r /tmp/LastGo/.git CheminDeMesFichiers

Quoi de plus facile pour écrire la description du commit en se basant sur le Trello ou d'écrire un changelog à partir du Trello et des commits ?

Et voilà, on mettra ensuite à jour le github après chaque tâche réalisée. Un avantage non négligeable sera de pouvoir revenir en arrière si on fait une bêtise comme supprimer des fichiers importants par erreur ou l'ajout d'un bug dont on arrive plus à retrouver l'origine.

Le git n'est pas parfait, mais nous aurons tout notre temps pour l'améliorer quand le projet sera plus avancé.


Le diagramme de classe et de séquence

Très pratique d'avoir deux écrans pour avoir d'un côté notre diagramme et notre IDE. On essaye de rester simple et de ne pas trop rentrer dans les détails, on ne mettra que les méthodes et les attributs les plus importants.

Ouf, c'est bon, les souvenirs me reviennent. Mais ces histoires d'Action et UserAction me semble encore un peu flou, ne nous privons pas et faisons un diagramme de séquence alors.

Donc un utilisateur créé une action utilisateur UserAction (e.g. Pass, PutPawn, GiveUp). Il soumet cette action au Controler.
En fonction des règles du jeu et de l'état du plateau, le Controler va créer une ou plusieurs actions (e.g. GiveUp -> EndOfGame -> SetWinner ou Pass -> EndOfGame -> SetWinner).
Quand une Action est créée, elle s'enregistre dans un History qui va l'exécuter. Permettant ainsi d'annuler ou de rejouer des actions par la suite ou de les enregistrer. Lorsque l'action s'exécute, elle utilise IGamePrinter pour modifier l'affichage du jeu.

On pourrait aussi imaginer un historique pour les UserAction. Notons-le pour plus tard.


Et on termine cette tâche

Sur le Trello, je créé une colonne "idée" et j'ajoute "UserActionHistory".
Je déplace ma tâche "diagramme de classe" dans "V0.0 Reprise du projet" et la coche dans "V0.0 Récapitulatif".

On va aussi mettre à jour notre github :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
cd CheminDeMesFichiers
 
# On regarde les dernières modifications
git status
 
# On ajoute les fichiers modifiés
git add doc/*
 
# On fait un commit explicite
git commit -m "V0.0 Reprise du projet : Diagramme de classe
 
Diagramme de classe et de séquence (UserAction et Action)"
 
# On pousse le tout
git push

Et voilà, il ne restera plus qu'à déplacer quelques classes et je pourrais commencer les choses sérieuses.

[Neckara]

Voilà, c'est un peu tout pour ce soir. (ouais, c'est bizarre de terminer la soirée à 17h20 )

J'ai pas mal édité le post précédent et beaucoup détaillé ce que je faisais. Je ne sais pas si cela vous plaira ou non, de toute façon je m'en moque, je fais ce que je veux .

On se retrouvera dès que j'aurais à nouveau la flemme de bosser
(Donc assez vite je pense)

[Neckara]

Découper en package

Bon, rien de plus simple, je regroupe ce qui va ensemble sur mon diagramme de classe :

Maintenant, il me suffit de déplacer toutes les classes d'un package dans un même dossier et le même namespace (e.g. Controler.Action -> /src/controler/action et controler::action). M'assurer aussi que chaque classe a son propre fichier. On va éviter d'avoir toutes les actions dans la même classe par exemple .

Pour déplacer ou renommer les fichiers, j'utilise la commande git mv src, […] dest.

Nous allons renommer Action en IAction et UserAction en IUserAction, leur fichier d'en-tête sera alors iaction.h et iuseraction.h.
Nous pourrons alors utiliser action.h et useraction.h pour y inclure tous les header des dossiers action et useraction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#include "putpawn.h"
#include "setwinner.h"
#include "setscores.h"
//…

Pour supprimer des fichiers inutiles, j'utilise la commande git rm -f fichier.

Comme j'ai des fichiers de même nom (e.g. action/giveup.h et useraction/giveup.h), je n'oublie pas de modifier le haut des fichiers :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#ifndef USERACTION_GIVEUP_H
#define USERACTION_GIVEUP_H

Et un petit refactoring pour la route

Avant de terminer la V0.0 et commencer la V0.1, nous allons effectuer un petit refactoring. C'est à dire revoir le code que nous avons écrit et chercher à l'améliorer en vue de l'étape suivante.

Je voulais faire un historique de UserAction, mais comme la prochaine série d'étapes sera sur le contrôleur et le modèle, je n'ai pas à toucher à la vue.
En revanche, pour mes actions, je leur passe à chaque fois un History et un IGamePrinter et il faudra aussi que je lui passe un GameState.
Dans ce cas là, il est tout aussi simple de lui passer une structure contenant les trois, qu'on pourrait appeler "ControlerContext".
Au lieu de contenir un History, un IGamePrinter et un GameState, Controler pourrait contenir un ControlerContext et le donner à chaque création d'actions. Encore mieux, si les champs de ControlerContext sont privés, on pourra garantir que seul Controler pourra créer des Actions.
Comme c'est un élément commun à chaque Action, on va demander à IAction de s'en occuper.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
namespace controler
{
    namespace action{}
 
    struct ControlerContext final
    {
    private:
 
        ControlerContext(model::GameState & gameState,
                         view::IGamePrinter & gp)
            : m_gameState(gameState), m_gp(gp)
        {}
 
        model::GameState & gameState;
        view::IGamePrinter & gp;
        History history;
 
        friend class Controler;
        friend class action::IAction;
    };
}
 
namespace controler
{
    namespace action {
 
        class IAction {
        public:
 
            IAction(ControlerContext & context) : m_context(context)
            {
                m_context.history.execute(*this);
            }
 
            view::IGamePrinter & gamePrinter(void){ return m_context.gp; }
 
            virtual void redo(void) = 0;
            virtual void undo(void) = 0;
            virtual ~IAction() = default;
        private:
            ControlerContext & m_context;
        };
 
    }
}
 
 
namespace controler
{
 
    namespace action
    {
        class EndOfGame : public IAction
        {
        public:
            EndOfGame(ControlerContext & context)
                : IAction(context)
            {
            }
 
            virtual void redo(void) override  { gamePrinter().endOfGame(); }
            virtual void undo(void) override  { gamePrinter().endOfGame(); }
        };
    }
}
 
// créer une action :
new action::EndOfGame(m_context);

On n'oubliera pas de mettre à jour notre diagramme de classe et de pousser le tout sur github

Aller, on se revoit pour le début de la V0.1


Représentation de l'État du jeu

On va travailler sur la partie Modèle. Dans un premier on représente le jeu sous forme d'un diagramme très simple.

L'état du jeu, c'est un plateau qui contient un ensemble de socle et de groupe de joueurs. Les socles ont des voisins et on peut y poser un pion. Un ensemble de pion est un groupe de pions qui appartient à un joueur. Un joueur a un score.
Pour le moment, je créé les classes sans les méthodes.

Pour les méthodes de GameState, je ne peux pas m'inspirer de l'existant. Controler fixe les règles du jeu, les actions comme PutPawn sont donc bien cohérentes. Dans IGamePrinter, on ne demande pas d'afficher un pion en plus, mais d'afficher le fait de poser un pion (afficher le pion, jouer un son, afficher du texte, etc.), cela reste donc toujours cohérent.
En revanche, cela n'a aucun sens dans GameState. "Poser un pion" ne signifie rien. En revanche, nous aurons besoin de savoir si un socle possède un pion ou non, si c'est le bon joueur qui joue, … Les méthodes seront donc créées au fur et à mesure qu'on écrira les règles de jeux.

Je commence donc à écrire les règles de manière très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    bool Controler::process(const view::useraction::PutPawn & userAction)
    {
        // C'est son tour ? Il a encore le droit de jouer ?
 
 
        // Il peut jouer ici ?
 
        new action::PutPawn(m_context, userAction.dest, userAction.player);
 
        // Des fusions ?
 
        // new action::fusion()
 
 
        // Des pions mangés ?
 
        // new action::removepawns
        // new action::setscores
 
        new action::NewTurn(m_context, userAction.player, 0);
 
        return true;
    }

Et petit à petit, je remplace les commentaires par du code. Par exemple "C'est son tour ?", je vais introduire de nouvelles notions à mon GameState grâce à de nouvelles méthodes.

Tests Unitaires

Je pars donc de règles très simples que je complexifie petit à petit. On va donc faire de la DDT (TDD en anglais).
Je pars du cas le plus facile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
static void putPawnSuccess(void) {
 
    INIT();
 
    assert( ctrl.submitAction( new view::useraction::PutPawn(0,1) ) );
}
 
 
RulesUnitTests::RulesUnitTests()
{
    putPawnSuccess();
}

avec un code minimaliste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
bool Controler::process(const view::useraction::PutPawn & userAction)
    {
        new action::PutPawn(m_context, userAction.dest, userAction.player);
        new action::NewTurn(m_context, userAction.player, 0);
 
        return true;
    }

Je vais ensuite essayer d'écrire un test qui échouera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
static void putPawnNotPlayerTurn(void) {
 
    INIT();
 
    assert( ! ctrl.submitAction( new view::useraction::PutPawn(1,1) ) );
}

Et j'ai une erreur : "void putPawnNotPlayerTurn(): Assertion `! ctrl.submitAction( new view::useraction:utPawn(1,1) )' failed."

Je vais donc ensuite améliorer mes règles afin de ne plus avoir cette erreur puis je recommencerais jusqu'à avoir écrit l'ensemble des règles.