Discussion :

[Neckara]

Pour DataPermanant, je suis confronté à un petit problème.

J'ai deux choix d'interfaces :

• XML-like
  
  • on peut avoir une hiérarchie de propriétés : pere.fils.petitfils = valeur
  • mais ce n'est pas vraiment compatible à un stockage BDD
  
  
• SQL-like
  
  • on peut faire des requetes comme "prendre tous les monstres craignant le feux" assez facilement et les performances ne sont pas mauvaises.
  • on peut créer des vues pour cacher un peu la structure réelle de la table.
  • mais cela ne permettrait pas facilement d'avoir une hiérarchie de propriétés.

Pour le stockage, je pense utiliser SQLite (je me suis trompé en disant firebird tout à l'heure ).
Je vais devoir prendre l'interface C (domaine public) et l'encapsuler correctement. Il existe une multitude d'interfaces C++ mais elles me semble pas géniales.

Le problème, c'est que je ne peux pas vraiment encapsuler la structure des tables, ce sera à l'utilisateur des tables de faire ses propres fonctions d'encapsulation de requêtes pour chaque nouvelle requête qu'il souhaite créer.

Et ce ne serait pas mal d'avoir un accès XML-like pour certaines données tout en gardant un accès SQL-like et un stockage par BDD, il faut que j'y réfléchisse.

[Hinthacy]

Après, je peux me tromper, mais dans la structure MVC que tu présentes, le contrôleur n'a pour moi aucun intérêt et fait, en raison de son fort couplage avec la vue, presque parti de la vue.

Pour moi, un contrôleur transforme les évènements qui viennent de l’extérieur en messages compréhensibles par le modèle. Il se trouve que la technologie qui enrichit les évènements utilisateur et celle qui gère l’affichage sont souvent identiques. En effet, quitte à utiliser une bibliothèque graphique pour afficher le plateau autant l’utiliser aussi pour gérer les entrées. Cependant, il est tout à fait possible de faire un jeu d’échec où la vue utilise une bibliothèque graphique et où le contrôleur utilise la console pour obtenir les commandes de l’utilisateur. Changer de contrôleur permet d’offrir à l’utilisateur une manière différente d’agir sur le jeu. Tu peux avoir un contrôleur adapté à chaque type d'entrées :

• Lignes de commande (ex : menu)
• Evènement de la souris enrichi par une bibliothèque graphique (ex : menu)
• Evènement du clavier enrichi par une bibliothèque graphique (ex : menu)
• Evènement du doigt enrichi par une bibliothèque graphique (ex : menu)
• Une composition des précédents (ex : menu)
• …

Le contrôleur peut sembler inutile parce que son travail est mâché par la bibliothèque graphique.

Tu confonds deux choses :

• la cohérence des données
• les règles du jeux

Le modèle représente et encapsule les données du jeu, ils seront toujours dans un état cohérent.
Le contrôleur, quant à lui, va demander au modèle de modifier des données après avoir vérifier que l'action est "autorisé".

Même sans parler d’MVC, un modèle est une modélisation d’un domaine. Ici, le domaine est le jeu d’échec. Le modèle doit s’assurer du respect des règles du jeu, sinon ce n’est plus qu’un modèle de plateau d’échec et ce n’est pas l’objectif.

les règles de mises à jour des donnés => le modèle met lui-même à jour les données = encapsulation, rien de plus pour moi.

• ~ "setter"

« Une tour se déplace en ligne droite » est une règle de mise à jour des données (déplacement) d’un modèle de jeu d’échec.

Bon wikipédia n'est pas une source très fiable mais j'ai :

controller : can send commands to the model to update the model's state

=> il envoi des commandes pour mettre à jour l'état du modèle, on dit bien "pour mettre à jour l'état du modèle", pour moi cela sous-entends que le contrôleur a bien "validé" le mouvement selon les règles du jeu.

Comme c’est sous-entendu, ce n’est pas la citation que tu aurais dû choisir. Je n’ai pas du tout la même interprétation de cette phrase.
Aurais-tu des citations explicites ?

[Neckara]

Pour moi, un contrôleur transforme les évènements qui viennent de l’extérieur en messages compréhensibles par le modèle.

Événement dépendant de l'UI/GUI, donc de la Vue.

Changer de contrôleur permet d’offrir à l’utilisateur une manière différente d’agir sur le jeu

Mais l'UI/GUI devra être adaptée en conséquence, on devra donc adapter la vue :

• afficher un menu
• afficher des invites sur la console
• affichage ou non du curseur
• etc.

Au final le contrôleur et la vue sont interdépendant et leur séparation n'a aucun intérêt ici vu que leur couplage est assez important.

Même sans parler d’MVC, un modèle est une modélisation d’un domaine. Ici, le domaine est le jeu d’échec. Le modèle doit s’assurer du respect des règles du jeu, sinon ce n’est plus qu’un modèle de plateau d’échec et ce n’est pas l’objectif.

Rien n'empêche le modèle de modéliser les règles et au contrôleur de les charger pour les appliquer.
Il ne faut pas oublier qu'un modèle est une représentation, une formalisation.

Le modèle est "passif", c'est le contrôleur qui va contrôler le modèle.

« Une tour se déplace en ligne droite » est une règle de mise à jour des données (déplacement) d’un modèle de jeu d’échec.

• Vue : mouvement(A10 -> A20)
• Contrôleur : modèle, qui est en A10 ?
• Modèle : une pièce dont le type est "tour"
• Contrôleur : modèle, qui est en A20 ?
• Modèle : rien
• Contrôleur : modèle, est-ce qu'un déplacement de type (0,+10) est inclus dans les déplacements d'une pièce de type "tour" ?
• Modèle : oui
• Contrôleur : modèle, déplace la pièce A10 -> A20.

Ainsi, on sépare la représentation des données de l'algorithme et des règles du jeu.

On peut alors :

• créer des bots juste en changeant le contrôleur sans changer le modèle.
  Avec ta méthode, tu ne peux pas car ton contrôleur ne connait pas les règles, le modèle les encapsulant.
• changer les règles juste via le contrôleur
  
  • en ajoutant des pièces en demandant poliment au modèle
  • en changeant les déplacements
  
  
• etc.

Je n’ai pas du tout la même interprétation de cette phrase.

Disons qu'il n'est pas écrit qu'il fait de la "translation" d'événement.
Il ne demande ne demande pas une mise à jour, mais envoie des commandes pour le mettre à jour. De plus, on voit bien que le modèle a un rôle passif dans cette phrase et qu'il n'y a nullement de sous-entendu permettant de penser que la commande de mise à jour puisse être refusée.
Sans compter que dans la définition du modèle, il n'est nullement question d'une quelconque "autorisation" de l'action.

Aurais-tu des citations explicites ?

Quitte à citer, il faudrait citer une source fiable à 100% donc citer une définition officielle du MVC.
En effet, chacun peut avoir sa propre interprétation du MVC et dans ce cas là, qui sera plus fiable qu'un autre ? Microsoft ? Sun ? Wikipédia ? Mon super prof de C++ d'IUT ?
Quelle définition du MVC prendre ? Celui de son créateur ? Celui d'un livre référence dans les DP ? Celui de la majorité ?
Pour la définition de mots français, on peut consulter le dictionnaire de l'académie française qui sert de référence, mais pour des DP informatiques ?

Et puis bon, je ne vais tout de même pas acheter un livre juste pour ça.
Le plus important n'est pas de suivre le "véritable" MVC à tout prix. Je préfère utiliser une variante ou quelque chose de complètement différent du MVC si le "véritable" MVC se trouverait être incohérent/allant à l'encontre de bons principes de programmation/autre.

Après, peut-être que j'ai raison, peut-être que tu as tords, c'est la vie.
J'ai exprimé mon point de vue et tu as exprimé le tien. Mon but n'est pas de te convaincre, et de t'imposer ma définition du MVC.
On pourrait continuer à débattre voir même partir en dialogue de sourd, mais ce sujet n'est pas très approprié pour cela.

Si tu trouve une citation de ton livre référence, tu peux le poster ici. Sinon il vaut mieux s'arrêter là ou créer un sujet dans le forum dédié.

[Hinthacy]

Après, peut-être que j'ai raison, peut-être que tu as tords, c'est la vie.
J'ai exprimé mon point de vue et tu as exprimé le tien. Mon but n'est pas de te convaincre, et de t'imposer ma définition du MVC.
On pourrait continuer à débattre voir même partir en dialogue de sourd, mais ce sujet n'est pas très approprié pour cela.

Si tu trouve une citation de ton livre référence, tu peux le poster ici. Sinon il vaut mieux s'arrêter là ou créer un sujet dans le forum dédié.

Je suis d'accord. La conversation n'avance plus. J'espère que cela pourra aider des lecteurs à se forger leur avis.
Je peux mettre en contact ma prof avec le tien, si tu veux (je plaisante).

Pour changer de sujet, tu destines ton moteur à quel type de jeux ?
Parce que j'ai du mal à voir l'intérêt d'une base de données relationnelle pour un jeu vidéo.
Quels seraient les avantages d'une base de données relationnelle ?
Tu la destinerais à quels usages (niveaux, stats...) ?

[Neckara]

Pour changer de sujet, tu destines ton moteur à quel type de jeux ?

Tous types de jeux, s'il manque quelque chose, il suffira de créer soit-même son propre module .
Après le moteur ne me semblera pas trop adapté à des jeux Java ou flash.

Attendez le 24 août et vous aurez un petit exemple de jeu .

Quels seraient les avantages d'une base de données relationnelle ?
Tu la destinerais à quels usages (niveaux, stats...) ?

Stockage de toute information devant persister au delà de l'exécution du programme.
Avec quelques avantages :

• plus rapide que d'utiliser un fichier XML
• plein de fonctions pour manipuler les données (clauses WHERE, etc.)
• on peut même créer une base en mémoire pour manipuler des informations en quantité (mais pas trop).

[Neckara]

Je viens d'ajouter SQLite au projet.

J'ai pas trop avancé dans le code, mais je me suis pas mal cassé la tête aujourd'hui pour tenter de réfléchir à la structure de la BDD que j'allais adopter.
Mieux vaut ça que de refaire sa structure 20 fois

Bref, demande je commence à tenter d'encapsuler/utiliser SQLite dans PermanantData.

[Hinthacy]

plus rapide que d'utiliser un fichier XML

Tu parles du temps de développement ou d’exécution ?

plein de fonctions pour manipuler les données (clauses WHERE, etc.)

Un fichier XML peut être requêté en XPath.

Typiquement, les données accessibles via "DataPermanant" seront chargées dans un modèle objet au lancement du jeu ?
Pour les niveaux du jeu, tu as prévu quelque chose de différent ?

[Neckara]

Tu parles du temps de développement ou d’exécution ?

Les deux, il est beaucoup plus facile d'encapsuler une bibliothèque SQL :

• connexion
• requête
• résultat

Qu'un XML.

De plus, je vais avoir besoin à un moment ou à un autre d'accéder à une "vraie" BDD si je fais un serveur ou autre.
Donc entre faire XML + BDD et juste faire BDD...

Un fichier XML peut être requêté en XPath.

En effet, mais il n'y a pas toutes les optimisations qu'une BDD peut avoir, et je doute qu'il ai aussi toutes les fonctionnalités comme les vues.
Après, il y a aussi les procédures et les droits d'accès mais qui ne sont pas gérés par SQLite.

Typiquement, les données accessibles via "DataPermanant" seront chargées dans un modèle objet au lancement du jeu ?

Pas nécessairement, il y a trois "modes" :

• des besoins d'informations très ponctuels (ex. listes des modules) où je peux me contenter de demander la liste à la BDD quand j'en ai besoin.
• des besoins d'informations qui peuvent se répéter, là ça devrait être chargés en mémoire.
• de grandes quantités d'informations à stocker pendant la partie, dans ce cas là, je créé une BDD en mémoire pour de meilleurs temps d'accès.

Pour les niveaux du jeu, tu as prévu quelque chose de différent ?

Je ne suis pas encore fixé.
Pour les IA, des scripts en LUA seraient bien mais il faudra alors que je prenne le temps de faire une interface.
Sinon, il faudra que je créé des modules d'IA.

Pour les cartes en elles-même, le SQL serait pas trop mal pour faire des "mondes ouverts".
Le top serait de pouvoir les générer aléatoirement pour "gagner" du temps, mais j'ai encore un peu de temps pour y réfléchir .

[Hinthacy]

De plus, je vais avoir besoin à un moment ou à un autre d'accéder à une "vraie" BDD si je fais un serveur ou autre.
Donc entre faire XML + BDD et juste faire BDD...

Pour les cartes en elles-même, le SQL serait pas trop mal pour faire des "mondes ouverts".
Le top serait de pouvoir les générer aléatoirement pour "gagner" du temps, mais j'ai encore un peu de temps pour y réfléchir .

Sur la plupart des jeux, les joueurs ont la possibilité de faire une copie de leur fichier de sauvegarde et de s'échanger des fichiers de niveaux. Comment penses-tu permettre ceci en utilisant une base de données relationnelle ?

[jean_kevin_musclor]

Bonjour, je n'ai strictement rien compris, c'est un moteur de quel type de jeu ? C'est un mmorpg ?

[Neckara]

Sur la plupart des jeux, les joueurs ont la possibilité de faire une copie de leur fichier de sauvegarde et de s'échanger des fichiers de niveaux. Comment penses-tu permettre ceci en utilisant une base de données relationnelle ?

SQLite est une base de données qui ne nécessite pas de processus "serveur", il est constitué d'un fichier par base qu'on peut parfaitement s'échanger.
Après, je peux toujours prévoir des fonctionnalités d'importation/exportation/échange, si je génère aléatoire prévoir une "graine" (il me semble que c'est le terme dédié ?).
Il faut aussi savoir qu'on a un module de mise à jour intégré dans le moteur, donc on pourra aussi s'en servir pour récupérer un "dépôt" de carte.

Je ne suis pas encore tout à fait fixé, mais la question est intéressant .

Bonjour, je n'ai strictement rien compris, c'est un moteur de quel type de jeu ? C'est un mmorpg ?

Hinthacy a déjà posé une question similaire il y a à peine 5 posts.
Last Engine vise, à terme, des jeux en lignes mais pas dans les proportions "Massivement Multijoueur".
Après, je progresse par étape, le réseau n'est pas encore prévu pour le moment.

Autant pour l'aspect RPG, ce serait tout à fait possible en écrivant à la rigueur quelques modules, autant pour l'aspect "Massivement Multijoueur", je ne pense pas que l'architecture du moteur soit bien adapté à des charges trop élevées.

[jean_kevin_musclor]

On dirait que c'est le flou complet ton cdc, j'ai l'impression que tu choisis des méthodes disproportionnées qui vont demander des mois de boulot, et que tu sais pas bien dans quelle direction tu pars, vu que normalement c'est la première étape du cdc, on commence par choisir la direction en définissant le point d'arrivée (description du produit fini).

Tu devrais peut-être démarrer par un projet plus simple et donc plus réaliste.
Genre déjà faire un seul jeu.
Un petit jeu de gestion en ligne genre farmville ou ogame par exemple.

Dis-toi que, pour faire un sim city multi, t'as besoin d'une seule table, la table ville, c'est tout... éventuellement une deuxième table user si tu veux faire plusieurs villes par user. Pour gérer deux tables ça m'étonnerait qu'il y'ait besoin de sortir l'artillerie lourde cmv uml et compagnie, ça c'est plutôt des méthodes de travail pour les grosses bdd des administrations.

Sinon quelqu'un parlait de xml tout à l'heure, j'ai encore plus simple: ton application serveur peut directement générer du html. Comme ça t'as bêtement le navigateur des joueurs qui leur sert de client léger, et toi tu t'occupes juste de programmer l'application serveur (et ça serait beaucoup plus facile de faire ça en java ou php, et éventuellement ensuite le porter en c++ pour optimiser le bazar s'il t'en reste le temps et le courage). C'est il me semble la façon la plus simple de programmer des jeux de gestion en ligne - et de la gestion en ligne tout court d'ailleurs, pourquoi perdre dix ans à redévelopper tout un client en c++ alors que le navigateur suffit ? Personnellement à ta place je commencerais par là.

[Neckara]

@jean_kevin_musclor : est-ce cela que tu appelles "saquer [nos] posts" ?

Enfin, si tu veux être crédible, il faudrait au minimum lire le premier post...
Tu ne sais même pas de quoi tu parles...

Tu as peut-être développé quelques projets en amateurs et même vendu quelques uns, cela ne fait pas obligatoirement de toi un bon développeur ou un bon concepteur de jeux vidéos...

Avant de donner des "conseils", renseignes-toi un peu plus sur le projet quitte à poser des questions...

[yetimothee]

Salut,
juste pour te dire que j'admire la détermination que tu met dans ce projet (c'est bô !!). Cepdnant, j''ai des remarques, j'espères que tu les liras avec attention.

Je doute en ayant lu la plupart de tes postes que tu t'attaches suffisamment au coté pragmatique de ton développement.
Le résultat compte en priorité, le reste, ma foi, on s'en tape. Que ton projet soit bourré de violation du concept de "DRY" ou bien ne soit absolument pas modulaire, l'important est qu'il te permette d'arriver à tes fins !!

De plus tu remarque très justement que tes précédents projets on échoués car tu visais trop haut, trop générique, trop théorique. Ben là tu semble faire exactement la même chose, peut-être même en pire.


Expèrience personnelle : Moi aussi j'ai adopté cette démarche, j'ai développé ma propre lib "moteur" pour faire mes jeux en C++ (un résultat du précédent w2j : ChestDefense . Ben jamais j'aurais la prétention de la refiler à quelqu'un d'autre que moi même pour qu'il l'utilise, et ce pour plusieurs raisons :
- Lorsque je programme un jeu, j'aime contrôler "tout", pas de raison qu'un autre fasse autre chose (y a peu de jeux développés en C++ sur ce forum qui n'utilisent des moteurs pas perso), ou alors la dite personne va utiliser Unity ou C#, qui sont bien plus orientés dev rapide et efficace.
- De tels moteurs existent déjà et sont surement beaucoup mieux pensés/réalisés car fait par des personnes dont c'est le boulot au jour le jour (as tu déjà essayé Unity ? Je trouve que les concepts qui sont dedans sont très très bien pensés).
- Je n'attache pas une importance énorme au soin immédiat lorsque je code pour moi, car je sais reconnaitre que je suis impatient (mon but dans la vie n'est pas de passer plein de temps à refaire en moins bien ce que d'autres ont déjà fait, mais de m'enrichir par mes expériences, que j'essaye en priorité de rendre fructueuses (j'échoue rarement dans ce que j'entreprends en matière de prog depuis quelques années, sauf dès que je suis avec une équipe qui demande l'Everest en utilisant des technologies inadaptées, bref...)).
Mais au moins ma lib, aussi imparfaite soit-elle, fonctionne, et me permet de faire mes jeux.


Enfin, je trouve que la manière dont tu as de présenter ton projet est inefficace. Je n'ai pas vraiment compris où tu allais malgré le nombre de lignes que tu as écrit, de plus, tu n'as encore donné aucun aspect "réel" de ton projet... Je veux des screens, je veux savoir où tu en es. En plus tu sembles adopter des solutions sans avoir au préalable regardé si elles étaient réalisables, et de les avoir confrontés à d'autres solutions (quelle solution par exemple te permettrait d'ajouter des modules sans toucher au programme "noyau" ? Connait tu le principe des IPC (RPC, tubes, sockets, etc) ? Partir dans cette direction (voir compliqué d’emblée plutôt que simple) est pour moi la raison pour laquelle tu n'aura pas l'endurance pour mener à bien ton projet (il s'agit là d'endurance, pas de talent, je suis sûr que tu l'as le talent, car beaucoup de tes remarques me semble le montrer (à propos du MVC, de ta conception)). J’espère me tromper, je déteste voir des projets échouer (c'est comme un râteau ), surtout lorsqu'ils sont plein de bonne volonté


Bref, je te souhaite bien du courage, et de réussir dans ta voie

PS : Fournir ton github ne nous permettrait-il pas de voir les avancés du projet via les descriptions des commits ? Utilises tu seulement un gestionnaire de sources ?

[Neckara]

Le résultat compte en priorité, le reste, ma foi, on s'en tape. Que ton projet soit bourré de violation du concept de "DRY" ou bien ne soit absolument pas modulaire, l'important est qu'il te permette d'arriver à tes fins !!

Le problème, c'est que le jeu de Go ( projet Last DunGo ) a des règles très simples mais qui sont très compliquées à faire comprendre à un ordinateur.
la première version de Last DunGo, c'est une semaine à défoncer les murs avec ma tête pour me dire "comment je vais implémenter cela algorithmiquement".

Le problème, c'est que je voulais, avant tout, quelque chose de fonctionnel.
A part quelques petits bugs, cela marchait très bien. par contre, pour corriger les bugs... même pour moi, le code était pratiquement incompréhensible.

Le but de faire "modulaire", c'est de s'obliger à respecter le principe d'encapsulation, ainsi on créée une interface puis :

• je veux corriger un bug ? Pas de problème, les classes ayant un couplage minimal, une modification n'a que peu d'effet ;
• je veux utiliser l'interface X mais je ne sais plus du tout ce qu'il y a derrière ? Ou le code était assez compliqué ? Qu'importe, j'ai l'interface.
• je découpe un projet/problème compliqués en plusieurs sous-projets/problèmes plus simples

Faire quelque chose de "concret" est très facile et très rapide. Mais corriger les bugs ou réutiliser le code existant devient beaucoup plus lent et compliqué.

De plus tu remarque très justement que tes précédents projets on échoués car tu visais trop haut, trop générique, trop théorique. Ben là tu semble faire exactement la même chose, peut-être même en pire.

Sur ces trois dernières années, j'ai fait énormément d'erreurs très variées et je ne m'en cache pas :

• viser trop haut/compliqué => constitution de projets intermédiaires
• vouloir faire "trop compliqué" pour être le plus générique possible => beaucoup de réflexion pour simplifier.
• vouloir aller trop vite et se retrouver avec du code ingérable => quelques diagrammes UML pour avoir un visuel rapide de l'application
• etc.

Je n'utilise pas Unity à cause de sa licence qui ne me convient pas.

de plus, tu n'as encore donné aucun aspect "réel" de ton projet...

Qu'entends-tu par aspect réel ?

Je veux des screens, je veux savoir où tu en es.

Le problème, c'est que tant qu'on a pas travaillé sur la partie "vue", on a pas d'éléments visuels à montrer.
Pourtant, c'est aussi une partie très importante du travail.

En plus tu sembles adopter des solutions sans avoir au préalable regardé si elles étaient réalisables, et de les avoir confrontés à d'autres solutions

J'avais, il y a quelques mois, déjà commencé à créer un moteur, qui après réflexion me paraissait trop compliqué et pénible à utiliser.

quelle solution par exemple te permettrait d'ajouter des modules sans toucher au programme "noyau" ?

J'avais commencé à me lancer dans des explications techniques mais elles étaient apparement trop techniques .

Les modules sont à voir comme des sortes de "plugins", des bibliothèques dynamiques chargées à l'exécution.
La seule chose manquante est le prototype de l'interface du module. Il faut donc ajouter un fichier d'en-tête aux modules utilisant un module implémentant l'interface X.
De là, il n'y a plus vraiment de problèmes pour ajouter un module.

Connait tu le principe des IPC (RPC, tubes, sockets, etc) ?

Je connais, mais je préfère ne pas les utiliser :

• tubes nommés ou équivalents : gros problèmes de performances ;
• mémoire partagées ou équivalents : casse-tête à utiliser avec tous les mutex, petits problèmes de performances avec des process qui seront en attente de ressources et les changements de contexte, risque d'inter-blocage, etc.
• autre solutions basées sur un flux : il faut sérialiser/désérialiser les paramètres, on a pas vraiment de vérification des types, etc. J'ai déjà testé et c'est vraiment pas pratique.

Bref, je te souhaite bien du courage, et de réussir dans ta voie

Merci, toi aussi

PS : Fournir ton github ne nous permettrait-il pas de voir les avancés du projet via les descriptions des commits ? Utilises tu seulement un gestionnaire de sources ?

J'utilise git, hébergé sur github.
Si tu regardes mes posts précédents, tu devrais voir des liens vers quelques commits.

Actuellement, je suis en attente de livraison d'un ordinateur fixe, donc ces derniers jours je n'ai pas trop touché au projet.
Dans quelques jours, j'éditerais peut être le premier post pour donner plus d'indications

[Neckara]

Bonjour,

J'ai passé ces derniers jour à installer un ordinateur fixe et à trier mes données, tous mes e-mails, à faire un peu de rangement, etc.
Cela m'a fait prendre pas mal de recul et m'a aussi pris pas mal de temps par la même occasion .

Il faut savoir que je fais ce projet pour mon simple plaisir, pour moi-même.
Depuis quelques mois, je suis parallèlement sur un projet qui est réellement utile, et qui a déjà été utilisé lors des deux dernières présentations des projets.
A côté, fin septembre/début octobre, je vais peut-être avoir l'occasion de développer d'autres outils pour developpez.

J'ai envie de faire plein de choses, mais je ne peux pas tout faire, il faut donc faire des choix.
J'ai déjà ma formation d'ingénieur avec, peut-être, cette année un double diplôme, je suis aussi responsable de rubrique, rédacteur et modérateur. Des activités qui me prennent beaucoup de temps.

De plus, je ne suis pas sûr quant à mes disponibilités pour cette année à venir.
Je pense donc qu'il est plus sage d'arrêter mes projets personnels pour me concentrer sur l'outil qui vous permet de participer aux présentations des projets.

Fin septembre/début octobre, lorsque j'aurais bien repris les cours, je pourrais voir ce que je ferais.
Si j'ai bien avancé au niveau de l'outil et au niveau de la rubrique sécurité, si finalement je ne développerais pas d'autres outils pour developpez et si j'ai encore suffisamment de temps libre, alors peut-être que je reprendrais ce projet.
Mais cela fait beaucoup de si .

Quand on veut faire autant de choses, le tout est d'arriver à atteindre un bon rythme de travail, d'en faire peu mais faire de tout régulièrement. C'est en posant les pierres petit à petit qu'on construira des montagnes.
Malheureusement, je suis comme les premiers OS : monotâche. J'ai tendance à aller à fond dans une tâche et à délaisser un peu les autres.
Au final, il faut que je rattrape le retard pris dans une autre tâche en bossant à fond dessus ce qui augmente le retard pris sur les autres tâches, c'est un peu un cercle vicieux.

Ce genre de situation n'est pas très agréable pour moi et je me retrouve à ne plus savoir que faire.

Je vais donc profiter des 26 jours qui me restent pour avancer au maximum sur certaines tâches "non régulières" et on verra bien comment cela se profile.

Je suis vraiment désolé de ne pas pouvoir continuer après un départ aussi motivant.


Merci à vous tous qui m'avez suivi dans mes différentes aventures, c'était un vrai plaisir de partager avec vous.

[LiTiL_DiViL]

Bonjour,
J'ai suivi ton post, et à mon avis même si tu abandonnes ce n'est pas grave, tu n'as ni à te justifier, ni à t'excuser. Finalement la pression tu te l'ai mise tout seul . Mais je peux comprendre, quand on veut avancer tout seul c'est pas évident de se motiver, alors on peut se mettre des pressions et toutes sortes de règles mais à mon avis si le rapport contrainte/plaisir s'inverse c'est très difficile...

Au final on grandi grâce à nos succès et mais aussi à nos échec l'important c'est d'en retirer quelques choses !

Bonne continuation à toi pour tes études, tes autres taches et tes futurs projets bien sur !!!