Dev d'un GTD

Depuis que j'ai décider de coder mon moteur de jeu, il m'arrive la même chose qu'avec beaucoup de projets : la motivation du début tombée, je n'y touche plus.

C'est un beau problème psychologique commun que j'ai là. Heureusement, il y a des solutions qui existent.
En parcourant le net avec des mots clef du genre "motivation" "procrastination", je suis tombé sur pas mal d'articles donnant des conseils visant personnes à tendances dépressives. De très bon conseils la plupart du temps, que j'applique souvent déjà depuis longtemps. Mais le conseil le plus intéressant et récurrent que j'ai pu trouver est celui d'utiliser une technique Getting Things Done (GTD).

Bon OK. Pour un geek comme moi le meilleur moyen d'appliquer ca est d'utiliser mon ordinateur. Et donc on tombe sur pas mal de logiciels, du genre Remember The Milk.
Problème: j'ai déjà utilisé ce logiciel et déjà tenté de résoudre mon problème avec. Ca n'a pas du tout marché. Le problème, c'est qu'il faut se fixer soi-même des dates limites. Généralement, les dates limites marchent bien avec moi. Sauf que la façon dont je les gère est celle d'utiliser le stress généré par l'approche de la date pour me motiver à bosser. Et je stresse car j'ai des ennuis si jamais je ne fait pas ce qui est à faire. Donc quand c'est moi qui me fixe une date limite, qui plus est sur un projet totalement personnel (le moteur 3D ici), la date n'a donc aucun sens et je finis par n'avoir rien fait.

Donc je me pose un instant pour réfléchir. Ce que je veux, ce n'est pas rendre quelque chose mais faire quelque chose. Donc avoir un système qui me dise de devoir faire telle ou telle tache tel ou tel jour. Un emplois du temps quoi.

Et si au final je ne fait pas la tache? Je n'ai pas envie que cette tâche soit reportée tout comme c'est le cas avec Remember The Milk. De plus, si elle reportée avec l'état "en retard" et qu'elle s'accumule avec toutes ses jumelles suivantes, tout cela perds encore de son sens et je finis par effacer toutes les taches et oublier le projet.

Donc je veux une tache récurrente, qui puisse être ratée, même complétée à un certain pourcentage. Voilà ce que ca a donné!


Code couleurs des tâches :
- Vert : pas à faire ce jour là
- Bleu : complétée à 100%
- Orange : entre 20% et 80%
- Rouge : en dessous de 20% (ratée)
- Cyan : A rapporter

On se rend compte que je n'ai pas beaucoup bossé sur le projet depuis longtemps ... Mais j'ai une bonne excuse, c'était justement pour programmer ce GTD.
En tout cas, le résultat est probant pour le ukulélé! J'ai énormément progressé cette semaine. Sauf que raconter ce détail sort du contexte du blog.

Avancement

Une note rapide pour présenter l'avancement du projet :

Rien de mieux qu'une image pour expliquer ça. Les classes entourées de bleu représentent celles avec un début d'implémentation. Cette couleur signifie que l'idée générale du rôle de la classe et son interface est présente dans le code, donc rien de complet, juste "prêt à être rempli".
D'autres couleurs sont à venir pour représenter un meilleur avancement, donc! Et puis le diagramme lui même peu changer parfois.
Ce qui est sûr, c'est qu'on se rend bien compte qu'il faut beaucoup de boulot pour achever tout ça. Car même ce petit bout d'avancement nécessite du temps.

Mes prochains objectifs sont:
- Implémenter quelques classes de graphismes
- Implémenter les classes InputDispatcher et InputUpdated
- Afficher deux ou trois cubes et pouvoir en contrôler un!

Ca demandera donc au minimum huit nouvelles classes. Ca fera donc probablement seize nouveaux fichiers. Raah, c'est pas le plus marrant d'écrire juste de la structure. Et ca prend du temps également. Allez, une grande inspiration et puis je m'y met.

Moteur de jeu 3D

Allez hop-là un nouveau message ... parce que j'ai envie. Non pas que je suspecte ce blog de revenir à la vie mais bon, y'a des jours comme ca, on est d'humeur à faire des updates.

En réalité, la seule raison qui me pousse à faire ça est que je me suis remis à la programmation. Les examens de Teesside étant terminés depuis longtemps, la glandouille des vacances n'étant pas applicable (en plein mois d'Août, ah bon?), peu de choses sont donc en travers de ma route pour que ma motivation s'épanouisse.

Pour faire court, j'ai commencé un nouveau projet. Un moteur de jeu 3D, rien que ça. Ceci n'étant pas une mince affaire, j'ai d'abord commencé par m'organiser un minimum. Alors j'ai produit ce diagramme de classes :


Pour les curieux ignorants, c'est fait avec le logiciel StarUml.
Les normes UML ne sont pas totalement respectées, il y aura certainement plus de classes que ça au final, mais l'idée générale est présente.

La plupart des composants habituels sont là pour un moteur 3D standard. On distingue plusieurs groupes :
- Le coté matériel
- Les graphismes
- L'acquisition de données
- Le monde virtuel

Il ne pas confondre le matériel vidéo et les graphismes ici (même principe pour le son et input). Les classes "device" sont là pour faire abstraction du système utilisé. Pour "VideoDevice" par exemple, j'utiliserais certainement OpenGL. Mais il pourrait être remplacé par n'importe quoi, comme DirectX. Les classes de graphismes utilisent seulement la même interface.

Là où ça devient curieux, c'est que les graphismes sont actualisés (héritent de la classe "FrequentlyUpdated") en dehors du monde virtuel. J'ai voulu séparer clairement ces choses là. Et c'est même plutôt logique d'après moi. Mais il faut quand même qu'ils affichent quelque chose, d'où l'idée d'une classe "Feedback", qui contiendrait tout ce qu'il y a à savoir sur le coté visuel de ce monde virtuel.
Voilà un petit diagramme pour mieux comprendre :


(là pas de secret, c'est fait avec Paint)

Ca a l'air on ne peut plus logique non? C'est un cycle symétrique! (j'invente, ca sonne bien) . Le principe "une entité communique avec le monde" en ressort. L'intelligence est séparée de la réalité. L'intelligence stimule la réalité et la réalité stimule l'intelligence en retour. "L'intelligence" ici étant une entité, comme le joueur ou une IA.
Malgré mes faibles connaissances de communication réseau en temps-réel, je vois là le potentiel d'adapter facilement ce système pour du multijoueur en ligne.

Bon mine de rien je m'emballe un peu. Je suis certainement en train de réinventer la roue, comme toujours. Sauf que je n'ai pas vraiment lu, vu ou entendu quoi que ce soit qui ressemble à ce principe de "feedback". Si vous lisez ce post et que vous connaissez un quelconque article traitant de cette idée, faites-le moi savoir!