Game dev #05: c'est le spawn, de votre VIE.

 Salutations, voyageur !

 

LE BLOC DE RÉCOLTE EST ACHEVÉ ! Et ce n'est pas une mince affaire que de le proclamer bordel de uc §§ Si je devais utiliser une métaphore pour décrire ce segment de développement, c'est qu'on était partis pour une petite randonnée tranquille dans les collines, avec un jambon-beurre et un pepsi dans le sac. Une tempête s'est levée, on a aperçut en exclusivité la première meute d'ours bruns EVER qui cherchait de la viande fraîche pour se nourrir, pour finalement se retrouver emportés par un glissement de terrain et revenir à la maison un mois plus tard EN PORTANT LES CORPS EN DÉCOMPOSITION DE NOS GUIDES NATURE AAAAAAA-

 

La note de patch

"Un monde ouvert procédural avec des milliers de ressources à gérer, c'est toujours un super projet pour commencer le game dev." - littéralement personne sur Terre.

Pour vous remettre en mémoire les objectifs de ce segment numéro 5, nous avions comme but d'implémenter la génération des biomes sur notre carte de jeu, de placer procéduralement toutes leurs ressources ainsi que de les rendre récoltables (soit à la main, avec un outil, et au travers de deux mini-jeux en ce qui concerne les arbres et les gisements de pierre).

1) Dessine-moi un marais: Tout commençait bien avec l'élaboration d'un code de génération de biome, inspiré d'une version créée il y a presque un an. Le principe est simple: on génère des splatmaps procédurales sur une texture 2D, où chaque canal couleur d'une texture correspond à la présence, ou non, d'un biome. Par exemple, ma première texture stocke la présence de prairie (rouge), forêt (vert) et bleu (plateau). La seconde gère les rivières (rouge) et les marais (bleu) (des images de ces textures sont disponibles un tout petit peu plus bas dans la compilation de GIF et d'images du bloc).

On assemble ces deux textures avec un algorithme de priorisation, et tada, on obtient une magnifique carte 2D de la répartition de nos quatre biomes principaux et de notre rivière. Une fois ces informations stockées au chaud, on utilise un shader custom qui associe le canal couleur de chaque texture à un visuel de biome. On l'applique au mesh du sol de notre monde, et voilà, on marche sur des feuilles dans les sous-bois, ou sur de la boue dans les marais. En bonus, on s'est même permis de diviser le mesh de la carte en chunks plus petits, qui sont masqués par occlusion lorsqu'ils s'éloignent trop de la caméra du joueur. Pas besoin de calculer le rendu graphique d'un bout de terre que ne vous voyez pas.

Côté données, une fonction nous permet rapidement de savoir à quel biome correspond un point précis sur la carte. Cela nous permet de savoir où instancier nos ressources pour chaque biome. La méthode est simple, les paramètres sont faciles à changer dans un écran de personnalisation de carte, et les résultats sont immédiatement disponibles à la prévisualisation - bref, tout va bien.

2) Je récolte fort, moi monsieur, je récolte: J'ai ensuite attaqué l'extraction des ressources en elle-même. Après avoir joyeusement créé mes arbres et mes veines de pierre avec trois meshs collés ensemble avec du scotch, j'ai programmé les classes de récolte, dont une spécifique aux plantes, qui nous servira plus tard dans la gestion de leur croissance et de leur reproduction.

L'ensemble des ressources récoltables peut, pour l'instant, se classer dans les catégories suivantes:

- récoltable à la main, avec un très court délai (fleurs, plantes au sol, une ruche...)

- récoltable à la main, un peu plus long, et en quantité limitée sur chaque ressource (les branches fines d'un arbre, les petites pierres d'un gisement)

- récoltable uniquement avec une serre-faux, qui permet d'exploiter complètement le noeud (détruire un buisson large par exemple, ou débiter un tronc tombé au sol)

- et les récoltables spéciaux, j'ai nommé les gisements de pierre, et les arbres matures, qui ont besoin d'une serre-faux et qui ont en exclusivité un splendide mini-jeu chacun. Ce mini-jeu est optionnel, mais le réussir permet de remplir une barre de récolte qui vous donne des ressources bonus et qui peut grandement accélérer la récupération de ressources.

La serre-faux est un outil polyvalent manié par les vyrrlins. Vous n'aurez jamais à jongler entre pic, hache, houe, faux, marteau et j'en passe: la serre-faux est universelle, et sa qualité comptera beaucoup dans la productivité de son propriétaire.

On a donc tout un système opérationnel de récolte où votre personnage s’attelle à sa tâche et débite peu à peu les objets qu'il est possible d'obtenir sur une précieuse ressource naturelle. Ce système est robuste et devrait être là pour durer, même s'il sera possible d'ajuster certaines mécaniques pour qu'elles aient un feeling fluide dans le jeu complet.

3) Et là, j'ai planté 3 500 chênes sur ma carte: Une fois codés mes splendides arbres dont les troncs majestueux chutent au sol, ainsi que mes gisements de pierre qui éclatent en vomissant leurs blocs bruts, j'ai essayé de les instancier procéduralement dans mes biomes.

J'ai donc, avec mes gros doigts, codé l'algorithme pour les placer sur ma carte. J'ai fait ça bien, avec une densité spécifique à chaque ressource, des espacements moyens, des coefficients d'agglomération pour essayer de faire en sorte que certaines s'instancient par paquets. J'ai bien implémenté une vérification supplémentaire pour éviter que les ressources ne se chevauchent entre elles. Et fière de moi, j'ai tout lancé, full speed no fear sur mon PC dont la configuration date de 2017 (ne vous inquiétez pas que si vous rencontrez des problèmes de performance dans le jeu final, je les aurais vus bien avant vous).

Eeeeeet ma fenêtre de jeu a chuté de 140 fps à 70, avec des creux à 50, voir moins, dans ma forêt de pins sur nos plateaux. Des sueurs froides ont commencé à couler sur mes tempes alors que j'observais le nombre total de nœuds dans l'arborescence de la scène - plus de 20 000, au bas mot. Sur une carte de 500 mètres de large, quand la version finale en fera au moins deux fois plus. 

J'ai compris qu'on allait avoir un léger problème.

Le premier, c'est le nombre absolu de nœuds dans l'arborescence. Même s'ils n'ont pas de process actif, et qu'il n'y a rien qui itère particulièrement dans leur liste, ça ne peut pas être bon pour la performance d'avoir autant d'objets 3D existants en jeu.

Le second, plus concret, c'est que cela représentait entre deux et six MeshInstance3D par ressource à afficher, PLUS leur collider à gérer comme corps physique indépendant. Même avec des modèles extrêmement simples, l'occlusion et les matériaux partagés, la charge est trop lourde à porter pour le processeur et la carte graphique. Alors je ne voulais pas imaginer ce que ça donnerait avec des vrais visuels texturés plus tard.

Après m'être roulée en boule quelques heures dans un coin de la pièce, j'ai décidé que ce résultat était inacceptable, et je suis repartie à la reconquête de tout ma gestion des ressources, la bave aux lèvre. Je me suis armée des deux leviers massifs d'optimisation rendus disponibles par Godot : j'ai nommé les MultimeshInstancers3D, et le PhysicsServer3D.

Car voyez-vous, les nœuds dans l'arborescence de la scène sont une façon très pratique et commode pour gérer des objets ponctuels (notamment nos créatures). Mais en ce qui concerne nos six-cent buissons de baies sauvages, ces nœuds deviennent très superflus et inefficaces. J'ai donc dissous tous mes Node3D et mes ressources sont devenues intégralement "immatérielles", et plus spécifiquement, orphelines. 

- Leurs meshs sont gérés par des MultiMeshInstancers, répartis en grille de 3x3 sur la carte. Chacun d'entre eux s'occupe d'afficher les X instances de la ressources aux positions, rotations et échelles demandées. Les MultiMeshInstancers sont de petites merveilles d'optimisation qui permettent de regrouper des milliers de modèles en un seul appel de rendu au lieu d'un par instance (comme c'est le cas avec un MeshInstance3D classique). Et en activant l'occlusion sur ces objets, les carrés de ressources trop éloignés deviennent invisibles pour économiser du temps de rendu.

- Leurs colliders sont directement créés et stockés par le PhysicsServer3D - une classe plus bas niveau que les CollisionObjects, et qui permet de manipuler les corps physiques et leurs formes in-game. Sans la couche logicielle des nœuds de scène, cette gestion est rapide comme l'éclair. Lorsqu'une créature se heurte au tronc d'un arbre, ou que votre personnage détecte une ressource récoltable sous votre souris, c'est l'une des forme de ce corps physique de ressource qui est reconnue sans passer par l'arborescence in-game.

Chaque instance de ressource est associée au même index pour ses meshs, son collider, ou ses données. Donc, quand je demande le saule n°32 du carré haut-centre de la carte, mon système sait exactement où sont stockés ses visuels, son collider, et ses informations de plante. Il n'y a plus aucun Node3D qui existe dans mon arborescence.

Le système n'est au final pas le plus complexe qui soit - mais j'ai du repartir de zéro pour gérer mes ressources et je n'avais jamais manipulé autant d'objets sous forme abstraite. Il y a certes une couche de complexité supplémentaire par rapport aux nœuds, mais le gain de performance est inouï. J'ai retrouvé mes 140 fps fluides et ma récolte de ressources fonctionne parfaitement. Je sais désormais que si j'ai besoin d'optimiser l'affichage des objets tombés au sol, ou de mes zones de collisions de linceul, je sais exactement vers où me tourner.

4) Ce n'est pas fini mon bro: Me voilà à genoux, pleurant des larmes de joie et remerciant tous mes dieux funestes d'avoir résolu mon épineux problème de performance. Mais vous savez ce qu'il se passe lorsque vous abattez un arbre, et que son tronc tombe à terre ?

IL EST SENSÉ BLOQUER LE PASSAGE, voilà ce qu'il se passe §§ Et de toute façon, vu qu'au segment prochain on va commencer à placer des bâtiments et des objets sur le chemin, il fallait bien qu'on gère le rafraichissement du pathfinding, qui, comme le reste, n'est pas "automatique olololz".

Si mon IA est codée à la main, j'utilise le système natif de navigation de Godot pour faire trouver leur chemin à mes créatures. Il fonctionne très bien sur terrain plat, mais jusqu'ici, je n'avais pas vraiment à me soucier du mesh de navigation (les polygones qu'utilise le système pour déterminer quelles aires sont accessibles et quel est le plus court chemin vers un point donné). Il était calculé au lancement du jeu pour correspondre aux extrémités du carré de la map, et ensuite, tout le monde l'oubliait.

J'ai donc demandé au code de mettre à jour le navigation mesh à chaque chute d'arbre pour que mes entités évitent correctement l'obstacle, et, SURPRISE, LE JEU FREEZE ALORS PENDANT DEUX SECONDES COMPLÈTES.

Le NavigationServer3D parcoure toute l'arborescence de la scène pour collecter les points et les faces des meshes, et les positionner sur 500x500 unités de carte. Le processus verrouille le thread de calcul principal, et le jeu est complètement bloqué le temps que l'opération se termine. Aïe. 

Après une nouvelle heure en position latérale de sécurité dans le bureau, et une bonne goulée de la documentation du NavigationServer3D, j'ai décidé, comme pour l'affichage des meshes, de fractionner mes régions de navigation en de nombreux chunks connectés, pour qu'ils puissent être mis à jour indépendamment les uns des autres. J'ai passé Godot en version 4.3 profiter d'une connexion fluide entre ces chunks, en jouant avec leurs limites de baking et leurs bordures.

Le résultat, est le suivant:

- Je calcule séparément mes données de navigation du sol, des ressources, et des obstacles instanciés, et je cache ces données abstraites sur un nœud manager (sous forme de NavigationMeshSourceGeometryData3D). Je vais directement récupérer toutes mes informations de géométrie via le script et pas par l'arborescence de scène. Le gain de performance est déjà considérable.

- Ces données sont réunies, à volonté et virtuellement sans coût, en UN SEUL mesh pour toutes les régions de navigations. Elles réalisent ainsi toutes leurs calculs sur le même ensemble de points et sont cohérentes entre elles.

- Lorsque j'ai un changement à effectuer, je ne recalcule mes données que pour le type d'obstacle concerné (une ressource virtuelle, ou un Node3D instancié), et je ne demande un rebake QUE pour les régions locales, concernées par la mise à jour (4, tout au plus, si l'obstacle traverse la frontière entre plusieurs régions).

Leur taille était faible (et plus précisément, leurs BAKING BOUNDS étant restreintes), la mise à jour prend en moyenne 30 ms et tout est fluide. Les cheminements de mes créatures changent en temps réel si quelque chose se met en travers de leur route.

5) Les détails bonus: En prime, nous avons corrigé plusieurs bugs en pagaille, assuré la bonne reconnaissance de tous les colliders dans le navigation mesh (certains troncs, trop peu larges, ne bloquaient pas le passage des créatures), amélioré la visibilité des FX provisoires d'attaque, et préparé toute la base de notre arbre de ressources.

Le commentaire

Ce bloc de développement est, de loin, celui qui m'a le plus appris à propos de Godot. MultiMeshInstancer3D, PhysicsServer3D ou NavigationServer3D - les trois sont des classes exceptionnelles qui devraient être les outils primaires d'un développeur souhaitant maîtriser de larges quantités d'informations et des cartes de grande taille. 

Bien sûr, les nœuds resteront indispensables - pour mes vyrrlins, mes bâtiments, mon soleil ou mon UI - qui se comptent sur les doigts d'une main. Mais je suis impressionnée des gains de performance et du contrôle accru procuré par ces classes qui, au final, n'ont rien de très sorcier à utiliser. J'avais vu des exemples de bullet hells ou des animations procédurales de bancs de poissons, où les nœuds deviennent impossibles à optimiser - mais je ne pensais pas qu'on aurait besoin de systèmes abstraits si tôt dans la construction de Lampyre.

Jusqu'à preuve du contraire, afficher toutes ces ressources sur une aussi grande carte, est pour l'instant mon plus grand défi d'optimisation - et on l'a franchi - DEUX FOIS, si on compte mes embrouilles avec le navigation mesh. Il faut bien comprendre que si je n'avais pas trouvé de solution à ces embûches, il aurait été quasiment impossible de continuer à développer le jeu tel que je l'imagine aujourd'hui.

Je ne me fais pas d'illusions sur le fait que nous tomberons sur d'autres joyeusetés imprévues, comme l'implémentation du système de sauvegarde (il arrive bientôt lui o__o j'ai peur), ou quand il sera temps d'optimiser les shaders de végétation et les assauts des ombres. Mais pour l'instant, on a vaincu avec brio ces murs qui sont apparus devant nos nez, et j'en suis très contente.

Quand j'aurais un peu sorti la tête du guidon des systèmes de récolte, je pense que je pourrais commencer à réellement apprécier nos mécanismes d'instanciation et d'extraction des ressources, qui, à l'heure actuelle, me permettent d'ajouter rapidement n'importe quelle plante, gisement, objet, à ma carte, et à mon jeu.

La suite

Maintenant qu'on est ressortis secoués (chokbars ?) mais plus forts de ce terrible bloc, nous pouvons enchaîner avec l'un des POURQUOI on extrait des ressources, j'ai nommé, la construction !

Un prémisse de base de Lampyre est la fondation de votre propre enclave pour abriter vos villageois et combattre les ombres. Et, oui, même si vous faites le margoulin et que vous essayez de jouer sans alliés, vous devrez toujours avoir un logis et des ateliers pour espérer détruire les autels de corruption. Alors, il me tarde d'implémenter ces mécaniques de placement et d'édification de structures. 

Les mots d'ordre sont toujours les mêmes - simplicité, cohérence, satisfaction. Placer une structure doit être facile, choisir ses matériaux agréables, et progresser dans le chantier régalien. Et, évidemment, ce sera également un plaisir d'assigner vos villageois aux chantiers et de les voir emmener les matériaux pour bâtir votre village.

Attention, j'ai bien dit construction, et pas fabrication. Nous nous intéresserons au raffinage des ressources et à l'artisanat dans le bloc suivant - pour le moment, je vais instancier mes matériaux raffinés comme un gros rat dans mon environnement de test pour bâtir mes édifices (elle hackou le jeu pour son propre confort §§ woaow §).

Les fonctionnalités à implémenter pour ce bloc numéro six, sooooont...

- une interface, ou un menu de construction de structures - possiblement accessible via l'autel du village

 - l'implémentation du concept de bâtiment et des presets principaux de structure (pas de construction de murs intégralement libre, il n'y a que peu d’intérêt à cela - la personnalisation sera en revanche très poussée sur les matériaux, les décorations, les sols, les objets...)

- le placement d'une structure (de son chantier) sur la carte, incompatible avec des obstacles, avec rotation et prévisualisation instantanée

- la progression organique et visuelle d'un chantier, avec l'apport de ses matériaux de base et leur travail

- les éléments des bâtiments doivent avoir une durabilité dépendante de leurs matériaux, et la possibilité de se dégrader, voir de se casser (une pièce ou un atelier n'étant plus fonctionnel si trop abimé)

- on doit pouvoir réparer les bâtiments et les structures

- si un bâtiment ou une structure est totalement détruit, on doit pouvoir récolter et recycler ses débris qui barrent la route

- je souhaite, à la fin de ce bloc, être en mesure de construire un preset entier de bâtiment avec des murs et du sol, une structure plus légère (e.g un atelier de taille de pierre), et des structures accessoires (lit, lanternes, pile de bois)

- il est possible qu'on ait alors besoin d'un shader custom pour s'assurer que le joueur soit visible, même derrière des murs ou sous un toit (il le faudra de toute façon pour voir ce qu'on fait au travers du feuillage dense qui sera présent dans les forêts)

 

Et nous verrons bien si d'autres besoins pointent le bout de leur nez ; en espérant ne pas reprendre le même mur d'embûches que pour les ressources (je vais leur optimiser leur uc aux bâtiments, il n'y aura aucun nœud superflu C'EST MOI QUI VOUS LE DIS).

Les visuels du schnaps

Et hop, compilation de nos GIF essaimés sur Twitter. Paradoxalement, il n'y en a pas tant que ça en comparaison du temps que nous a pris ce chapitre de développement, car le plus gros de la refonte de la gestion des ressources est littéralement... eh bien, invisible. C'était le but.

1) Mes premiers jets de splatmaps procédurales, qui définit la rivière (rouge) et les marais (bleu). La rivière est simplement une courbe 2D que je fais avancer depuis un bord aléatoire de la carte, au travers du terrain en évitant soigneusement le rond central avec l'autel. Les marais peuvent paraître grands mais en réalité, ils sont ensuite confinés à une distance maximale de leur rivière.

 2) Les fameuses splatmaps pour mes biomes ! Sur la première image, les deux carrés avec les tâches fluo sont mes deux textures les plus importantes: celle de gauche définit les surfaces de prairie (rouge), de forêt (vert) et de plateau (bleu). Celle de droite, la rivière (rouge) et les marais (bleu). Utiliser les canaux de couleurs sur des textures me permet de stocker 5 informations différentes sur chaque axe XY de ma carte en 2D !

Ces deux textures sont ensuite combinées dans un shader maison qui définit, pour chaque point de la carte, QUI a la priorité. Il applique aussi des règles supplémentaires comme limiter la distance maximale des marais à la rivière, ou rendre obligatoire le biome prairie dans un périmètre donné autour de l'autel.

Le résultat est appliqué aux plans qui dessinent le sol de notre jeu !

 

 

 

3) Nos première récolte de ressources tout simples: des fleurs ! Pour des petits éléments, nul besoin de serre-faux, et les objets vont directement dans votre inventaire si il y a de la place.

 

 

 

4) La première coupe d'arbre, avec un twist inattendu. J'ai appris la manipulation des Transform3D à la dure dans ce bloc.

 

 5) Le premier affichage maîtrisé du panneau de mini-jeu - encore sans mini-jeu. S'assurer que tout s'affiche bien, qu'on puisse le quitter en s'éloignant ou en appuyant sur échap...

 

 

6) Le mini-jeu de récolte de gisement de pierre ! Casser les surfaces colorées remplit la barre de bonus (orange). Arrivée à 100%, le gisement éclate automatiquement et vous donne jusqu'à 30% de matériaux bonus en plus. Vous pouvez aussi ignorer le jeu, et attendre que la barre de vie (verte) descende à zéro.

L’intérêt de ce système c'est que ce QTE peut largement être customisé et enrichi de fonctionnalités (combo streaks, vitesse, forme du curseur et des zones à casser, points chauds à éviter, variations selon la qualité de votre outil ou vos points de compétences). Les gisements les plus simples seront une formalité à briser, tandis que vous pourrez tenter votre chance avec les plus solides si vous jouez le jeu.

Quand ce seront vos PNJ qui récolteront les gisements, ils essaieront aussi de remplir la barre bonus, en fonction de leurs propres compétences ! Les meilleurs mineurs et bucherons seront fort productifs.

7) Mes modèles de ressources provisoires. On ne peut pas faire plus "placeholder" - mais avec l'affichage de plusieurs meshes pour faire une seule ressource, je me suis assurée que mon système sache gérer des instances complexes dans le futur.

8) La période post-PLS, où j'ai décidé de refondre tout mon système d'affichage vers les MeshInstancer3D et le PhysicsServer3D. Je testais ici la reconnaissance des arbres par notre personnage-joueur. Ce système de détection a par la même occasion été optimisée, que ce soit pour les ressources, les objets au sol, les ennemis...

9) Ballade matinale dans mes biomes optimisés. Les plaisirs simples.

 

10) J'ai aussi dû adapter l'affichage des barres de vie des ressources orphelines ! Il est important de pouvoir voir si un arbre ou un gisement a déjà perdu des points de vie, ou si sa barre de récolte bonus a commencé à se remplir. Ces barres de vie, auparavant fixes pour chaque nœud, sont maintenant éphémères, et se détruisent une fois leur durée d'affichage expirée.

 

11) Le drame des NavigationMesh. Même en ayant enlevé mes ressources de l'arborescence, le rafraichissement bloque encore le jeu pendant plus d'une seconde. En en prime, le collider du tronc est ici trop petit pour "percer" le mesh, et être considéré comme un obstacle.

 

12) Mise à jour des régions de navigation, après refonte et cache des données. Ici je m'amusais à instancier aléatoirement des "cubes" géants d'obstacle sur la carte. L'ombrelgin qui me suit est là pour me confirmer que le pathfinding des créatures fonctionne correctement pendant les rafraichissements.

13) Une chute d'arbre fluide ! VICTOIRE ! Il fait un trou dans le navigation mesh, et les créatures éviteront de se coincer comme des débilus sur son tronc.

14) Le dernier test du bloc de développement. Une aube tranquille de récolte sous escorte armée.

Comme d'habitude, vous pouvez me suivre sur @Ariatowl pour avoir des nouvelles régulières du développement. Je code quotidiennement, et je n'hésite pas à ouvrir mon gros bec pour m'esbaudir de mes polygones qui s'agitent sous mon commandement.

Prenez soin de vous, on se voit quand tout cela est codé !

Game dev #04: et l'aventurier décida soudainement d'encombrer ses sacs

 Salutations, voyageur !

 

 

Nous voilà à nouveau ici, pour célébrer la complétion de notre quatrième bloc de développement de Lampyre, qui était dédié aux bases de l'inventaire et du ramassage d'objets. Le but était d'apprivoiser la construction d'UI (interface utilisateur) au travers de Godot, et de permettre aux créatures de transporter des objets sur elle (dans leur sac), ainsi que dans leurs bras !

 

 La note de patch

Comme pour les blocs précédents, les fonctionnalités se sont étendues un peu plus loin que ce qui était initialement prévu. Revoyons ce qui a été fait en une courte liste:

1) Et le loot fut créé: Les objets sont maintenant une classe à part entière dans Lampyre. Il peuvent être instanciés dans le monde du jeu où il tombent à terre, ou bien être passés comme information au travers du code (dans les sacs, les coffres, les tables de butin...). Ils ont un nom, un poids, une description pipou, peuvent s'empiler à plusieurs ou rester uniques. 

Comme dans de nombreux jeux où le butin est important, maintenir la touche ALT enfoncée affiche clairement le nom de tous les objets au sol autour de nous.

2) Un seul maître, pour contrôler tous les blings: Pour faciliter la gestion des objets instanciés sur la carte, ils sont regroupés sous un node gestionnaire commun qui s'occupe de leur création et destruction dans l'arbre de la scène. Par exemple, lorsque l'on souhaite supprimer le modèle d'un objet instancié de la carte, c'est ce dernier qui relaie cette demande par signal au master node, qui s'occupe de son cas. Oui, c'est un peu comme passer un post-it à un enfant, pour indiquer à son parent qu'il doit aller le noyer dans la rivière. Mais cela optimise l'instanciation des objets. Ne jugez pas mes systèmes infanticides.

3) Viens dans mon sac, ou viens dans mes bras:  Un objet peut être ramassé par une créature de deux façon : soit dans un sac, s'il est assez petit, et si la créature possède un inventaire. Soit il doit être porté, limitant les actions de la créature tant qu'elle l'a dans les bras. Tout le système d'affichage de commandes a été révisé pour permettre au joueur de ramasser les objets proches, soit en s'en approchant, soit en passant directement la souris dessus pour les sélectionner.

4) Do you even lift, bro ?: Chaque créature a un score de force qui détermine la quantité d'objets qu'elle peut porter dans ses bras, ou la taille par défaut de son inventaire. Cette statistique est limitée entre 0 et 10 pour les vyrrlins (de 0 à 100 kg portés dans les bras), mais techniquement, elle peut monter jusqu'à 20 pour les créatures les plus imposantes. La force permet aussi de calculer la rapidité avec laquelle une créature ramasse un objet lourd (entre 0,5 et 2 secondes selon le score et le poids de l'objet), mais aussi la pénalité de vitesse infligée quand elle est chargée. 

Porter plus de 70% de sa capacité en charge draine l'énergie (cela ne vous fait pas lâcher les objets, mais peut vous mettre dans une situation délicate si des ennemis vous abordent soudainement), et à 100% et plus, tout retombe au sol. Le joueur est averti de ces limites lorsqu'il passe sa souris sur des objets soulevables (instruction en jaune = va provoquer un drain d'énergie, et instruction en rouge = va tout vous faire lâcher).

Enfin, il est évidemment impossible d'utiliser le dash, d'attaquer ou d'esquiver en portant des objets. Prendre des dégâts a une chance sur deux de faire tomber un objet de la pile que vous portez. À tout moment, le joueur peut instantanément lâcher sa charge avec un raccourci.

En outre, j'ai fait en sorte que le choix d'auto-attaque soit mémorisé avant le port d'objet. Si vous aviez désactivé vos auto-attaques avant de commencer à porter des objets, vous conserverez votre mode passif en les lâchant, jusqu'à ce que vous indiquiez le contraire. Cela vous évitera de décocher une flèche malencontreuse sur un ennemi que vous tentiez de ne pas blesser.

5) Des sacs ! Plein de sacs !: L'interface pour tous les inventaires du jeu est fonctionnelle ! De loin la partie la plus chronophage (plus d'informations par la suite sur ce segment), je vous passe les détails à propos des comportements classiques d'une fenêtre d'inventaire de RPG ; sachez juste que toutes les créatures ont un inventaire par défaut, dont la limite en poids est à nouveau dépendante de sa force. Les structures comme les coffres ou les stations sont également des inventaires, manipulables comme nos sacs.

On peut déplacer les objets, les scinder, les organiser automatiquement, les rechercher grâce à un petit champ d'input. Les raccourcis sont toujours affichés pour ne jamais être perdu. On peut aussi balancer des objets dans la flamme éternelle de notre autel, ou carrément y jeter des piles d'objet lourds. Je souhaitais un moyen de se débarrasser de façon permanente des objets, mais je me voyais mal permettre au joueur de détruire des armes ou des armures en métal au milieu de nulle part - je trouve cette solution élégante, même s'il y aura des mécaniques de recyclage plus satisfaisantes dans le futur !

6) Ma passion pour les coffres et les tas de bois: On peut ainsi stocker les objets : soit dans des contenants, comme les coffres, pour les petits objets. Soit sur des stations adaptées pour les objets les plus lourds. Entendez par station, un endroit où ces objets sont stockés pour être protégés, et/ou emmagasinés pour servir à un autre but : des armes stockées sur un râtelier, des buches de bois qui attendent d'être travaillées à un atelier de menuiserie, un ballot de foin qui attend d'être mangé dans une auge de créature...

Le joueur peut facilement et librement récupérer ces grands objets de leur stockage, en les sélectionnant directement avec la souris.

Additionnel) G pa fé, déso: Dans la catégorie de ce que nous n'avons finalement pas implémenté, nous avons le message d'erreur global (dash impossible, inventaire plein...) car il n'est pas encore indispensable, et son adaptation future n'est pas complètement claire dans mon esprit. Et ensuite, la partie bonus où on devait essayer d'instancier un rocher pour le miner et récolter ses ressources: je suis en train de peaufiner les détails des systèmes de récoltes et préfère inclure ce bloc (haha ! LOL ! CE BLOC ! LA PIERRE, MAIS QUEL HUMOUR EDJ rFEDUH<) dans le prochain segment de développement. 

Le commentaire du développeur sauvage à propos du segment de dev

Je ne m'en cachais pas, et je l'ai mentionné en débutant cette phase de code: implémenter mes premières interfaces utilisateur sous Godot me faisait un peu peur. Je n'ai aucune idée de la tronche des outils UI sous Unity ou sous Unreal Engine, mais sur Godot, la principale qualité avancée par l'éditeur à propos de son interface UI est l'adaptabilité, via son système de containers intelligents.

C'est un peu comme si on vous demandait d'éteindre un incendie dans le Gard en vous promettant que la peinture rouge de votre lance à eau est faite avec des ingrédients bio-responsables: c'est super chouette, mais ça ne répond clairement pas à vos angoisses principales.

AKA, gérer les clics de l'utilisateur. Sélectionner et glisser des éléments. Provoquer des réponses dans la logique des contenants. Il n'y a aucun preset, ni filet. Il faut coder chaque réaction. Finalement, en progressant lentement, j'ai fini par apprivoiser la bonne hiérarchisation des nœuds de contrôle pour faire une belle UI adaptative (yay !). Mais aussi à comprendre comment me servir des signaux de ces contenants, et du focus de la souris qui passe au-dessus, pour créer une interface fluide à manipuler.

Même en sachant que je débutais sur l'UI, je ne m'attendais pas à ce que cette partie soit si chronophage. Comme pour de nombreux autres systèmes présents dans les jeux vidéos, c'est en codant qu'on se rend compte de la quantité phénoménales de normes et de règles implicites qu'une simple interface de sac se doit de respecter, pour ne pas frustrer l'utilisateur.

Tout pouvoir fermer en cliquant ailleurs sur l'écran ("barre-toi la fenêtre bordayl, je suis attaqué §§"). En appuyant sur échap. Ouvrir automatiquement le sac en même temps qu'un coffre, mais permettre de garder le sac ouvert en fermant le coffre. Appuyer une fois sur échap pour fermer les panneaux d'UI, une seconde fois pour le menu principal du jeu. Illuminer les icônes interactifs, au bon moment, et les griser pour ne pas induire le joueur en erreur lorsqu'ils sont inactifs.

Le design de l'UI est un travail à double-tranchant: lorsque quelque chose ne réagit pas comme vous l'attendez, vous le voyez (ressentez, même) tout de suite. Mais une erreur, ou un choix d'ergonomie malavisé, peut rendre un panneau immédiatement pénible à utiliser.

Une interface bien pensée transforme la gestion de ses ressources en un plaisir. C'est vraiment un but important pour Lampyre, que ce que vous exploitiez autour de vous soit agréable à manipuler, transporter, ranger. Des automatisations vous permettront de mettre vos alliés à contribution, en leur demandant de gérer automatiquement des stocks, ou de ranger de façon ordonnées tout votre fatras acquis lors d'une journée d'expédition. Mais cette quête de satisfaction doit commencer dès la besace de base du joueur, dont le contenu est ici manipulable de simples clics.

Ce système d'inventaire est là pour durer. Il va supporter tout le reste de nos mécaniques de fabrication et de récolte, et j'en suis très contente. Si l'on pourra sans doute y apporter des améliorations au fur et à mesure, les commandes actuelles sont robustes. J'ai pour le coup très hâte de faire un saut dans le temps pour arriver au moment où l'on pourra lécher son design final (ce n'est pas sale) et en faire quelque chose de BEAU, en plus de fonctionnel.

Parce que pour l'instant, bon. Il fait exactement ce qu'on lui demande, ok. Mais il a pas pris la peine de se changer après s'être occupé du barbecue pendant trois heures sous le soleil, si vous voyez ce que je veux dire.

 

Je peux d'ailleurs aussi fièrement proclamer que, comme attendu, ce bloc de développement est le moins *visuellement* impressionnant de tout ce qu'on a pu faire jusqu'ici, bien que ce soit celui qui ai prit le plus de temps à compléter.

Aucune surprise, et je ne suis pas du tout démoralisée par cet état de fait. Ce qu'on vient de faire était délicat, et un inventaire qui fonctionne bien va devenir un pilier pour le reste du développement.

Le rythme de développement est très bon, il s'est même amélioré au fil du temps. Je n'ai pas fait le compte exact des heures passées mais nous sommes certainement à plus d'une heure de travail concentré quotidienne (souvent supérieur à l'heure et demi en réalité, hors week-end où le nombre d'heures est démultiplié). Lampyre est maintenant une habitude consolidée, et j'essaie de profiter d'autres créneaux de temps chaque jour pour développer mes idées, et les visuels !

La suite

Nous quittons un instant nos sacs et nos tas de bois (oui ce sont des bûches dans ma tête, laissez-moi rêver :'|), pour faire un usage maximal des objets que nous faisons désormais tomber au sol. Aucune déviation du programme: nous allons nous attaquer à la création des principales sources de matériaux de la carte, et de leur récolte.

Le but est d'initier la récupération de bois, de minerais, et d'autres biens naturels sur la carte. Et de pouvoir progressivement débloquer les fonctionnalités du bloc suivants: la construction.

Les fonctionnalités visées, pour ce bloc numéro cinq, sont donc...

*tousse tousse*

- l’initialisation de l'arbre technologique du jeu: quelles ressources existent, dans quelles variations, et avec quelles caractéristiques importantes pour la construction et l'artisanat.

- la création et la répartition rudimentaire des biomes sur la carte de jeu (je précise que cette fonctionnalité a techniquement déjà été codée début 2024 et mise de côté, mais je vais devoir la réviser et être sûre que ses systèmes s'intègrent bien à la structure actuelle de mon code).

- l'apparition des ilots de ressource sur la carte, selon les biomes, à sa création. Optionnel: programmation de leur renouvellement (repousse des arbres, ré-émergence des pierres). Il est probable que je réserve la gestion de la croissance des végétaux pour la future partie cultivation !

- la récolte complète de chacun de ces types de ressources, réalisée à mains nues, ou à l'aide de l'outil polyvalent et unique des vyrrlins de Lampyre, provisoirement nommée serrepic. Inclut toutes les étapes à effectuer par le vyrrlin pour en extraire les matériaux obtenables SANS station d'artisanat.

 

Cette liste semble courte, mais ne vous y trompez pas, les techniques de récolte vont être un minimum interactives et différentes pour chaque grand type de ressource (j'ai dit un minimum, il faut trouver l'équilibre entre simplicité et superflu ; il n'est pas question d'enchaîner cinq QTE à chaque fois qu'on souhaite désosser un buisson).

Cette partie a également la particularité d'être un peu plus riche que les précédentes en matériel théorique, puisqu'il faut éviter de se planter lourdement sur l'organisation des ressources à gérer dans le jeu. C'est toujours à la fois excitant, et un peu angoissant de poser les fondations de ce genre de systèmes. Je prépare mes meilleurs organigrammes d'artisanat.

Les visuels du schnaps

Et maintenant, le fourre-tout visuel de notre récapitulatif, j'ai nommé les GIF de développement (issus des clips que je poste régulièrement sur twitter) !

 

1) Les premiers objets tombés au sol, et les premiers ramassages ! À ce moment là, il n'y avait pas encore d'inventaire. Je demandais juste à chaque pièce ramassée de disparaître dans le néant. 

Notez la sélection automatique de l'objet le plus proche, ou bien de celui survolé avec la souris (pour peu qu'il soit également assez proche pour être ramassé, bien sûr). Ce système sera appliqué pour la majorité des actions contextuelles du jeu, afin d'avoir des inputs fluides et rapides.

Appuyer sur ALT met en évidence tous les objets en affichant leur nom et leur quantité, comme dans tout bon jeu où le loot peut être abondant et/ou caché au sol (les Diablo, Baldur's Gate 3, et j'en passe des dizaines d'autres).

2) Première tentative de faire automatiquement regarder le modèle du joueur VERS l'objet qu'il ramasse. Sauf que ce dernier est par terre, et que notre modèle de vyrrlin provisoire est une patate géante. Donc... HEADBANG.

3) Pour correctement tester la gestion des commandes de proximité, j'ai balancé tous les objets à proximité de la flamme de l'autel. Sans survol particulier de la souris, c'est toujours la commande qui concerne le bâtiment qui prime (ici, allumer sa torche). Mais on doit toujours pouvoir sélectionner du loot tombé devant, avec le curseur de la souris, pour ne pas qu'il reste inaccessible.

 

4) Essai de placement d'un objet lourd dans les bras du joueur. Peut-être que je me suis loupée sur la première implémentation de la rotation de la charge. 

5) On porte des objets lourds en pile ! Yay ! Il n'y avait encore aucune pénalité de vitesse de déplacement à ce stade, donc on pouvait tranquillement courir pleine vitesse avec 35 kg dans les bras.

On peut sans problème transporter plusieurs types d'objets lourds à la fois. Ils forment un pile organique sur la créature. Seul compte le poids total pour déterminer ce qu'elle peut soulever.

6) Application de la pénalité de vitesse de déplacement quand on est trop chargé, ainsi que du drain progressif d'énergie quand on porte +70% de sa capacité (barre cyan en haut à gauche). 

Notre capacité de charge lourde n'a aucun rapport avec le poids de notre inventaire (sac à dos). J'ai souhaité mettre ce drain d'énergie pour ajouter une dimension de risque à se surcharger: si vous ramenez des ressources au travers d'un coin sauvage de la carte, s'accrocher à votre butin devient risqué si on vous attaque (un manque d'énergie signifie automatiquement moins d'esquives ou de dash disponibles).

Notez la commande contextuelle "carry" en surbrillance rouge, sur le dernier objet. La couleur indique que soulever cet élément va vous faire dépasser votre capacité de charge totale, et que vous allez tout lâcher par terre si vous persistez à vouloir le porter.

 

7) Le sac à dos du joueur, qui se remplit d'objets ramassés au sol. Les icônes placeholder jaunes, représentent un type d'objet qui est empilable. Clic du milieu sur ces piles les scinde automatiquement en deux. J'aime beaucoup ces actions de gestion simples, par clic, grandement inspirées de V Rising (d'autres jeux fonctionnent similairement, je n'en doute absolument pas).

8) Diviser les piles par deux est pratique, mais parfois insuffisant. J'ai donc développé ce mini-panneau accessible avec clic du milieu + ALT. Il permet d'indiquer la taille exacte de la pile que l'on souhaite obtenir, soit en la tapant, soit en cliquant sur les signes d'augmentation/soustraction de valeur. World of Warcraft utilise ce système fort pratique depuis longtemps.

9) Lâcher les objets en les glissant en dehors de l'inventaire. Rapide, pratique, indispensable.

La simulation physique, et l'apparition à une position aléatoire autour du joueur renforce cette délicieuse petite impression de chaos. J'imagine déjà avec des vrais modèles d'objets texturés.

10) La destruction d'objets ! Comme mentionné précédemment, je trouvais important de pouvoir détruire des objets de façon permanente. Mais pour ajouter une petite touche de roleplay, j'ai décidé de rendre ça possible... par la flamme de l'autel.

L'inventaire du joueur a donc cette option représentée par un icône de flamme sur sa gauche. Elle devient active quand on est assez proche de l'autel. Y glisser des objets les détruit de façon permanente ; un petit encadré vous décrit l'action lorsque la souris survole l’icône de flamme.

11) Le bouton de tri automatique. Un autre indispensable. Il réorganise tout le contenu de l'inventaire pour agréger les objets similaires, et rassembler toutes les piles isolées qui peuvent l'être.

12) La petite fonction de recherche intégrée à l'inventaire ! Elle ne fonctionne pour le moment que pour son propre contenu, mais on pourrait bien l'imaginer fonctionner pour les deux inventaires ouverts en même temps à l'écran. 

J'ai hésité à implémenter cette fonction pour le prototype, mais je la trouvais fort utile, même à des fins de débug (chercher des objets spécifiques dans un sac bien rempli, à l'aide). Et elle aurait définitivement existé dans la version finale du jeu, dans tous les cas.

13) Les premiers coffres ! Étant eux-mêmes des inventaires, ils bénéficient de toutes les fonctions qui ont été précédemment codées. 

Avoir son inventaire, et un contenant ouvert à l'écran, débloque deux nouveaux boutons : le transfert rapide (je balance tout dans l'autre sac), et le transfert que j'appelle "de complétion". Déjà présent dans beaucoup d'autres jeux, il vous permet de rapidement bouger les objets qui sont déjà présents dans l'autre sac. E.g, un coffre contenant des pommes. J'appuie sur le bouton, et toutes les pommes de mon sac y sont transférées. Les autres objets ne bougent pas.

Il y a un autre type de transfert automatique que je souhaite implémenter dans le futur : le transfert par catégorie. Vous pourrez définir un coffre comme un contenant spécifique pour une ressource ou un genre d'objet ("bois", "fruits", "soie", "tissus") et ce boutons rangera automatiquement tous les éléments de votre inventaire qui rentrent dans les conditions indiquées.

Déplacer un objet d'un contenant à l'autre ne demande qu'un clic droit.

14) Les dernières fonctionnalités implémentées: jeter des charges lourdes dans le feu de l'autel pour les détruire, et les stocker sur une station adaptée. Par station, j’entends tout bâtiment qui acceptera ces objets pour les conserver en sécurité, ou les utiliser pour l'artisanat ou la consommation.

Merci à vous de suivre mes pérégrinations logicielles ! Le prototype monte en puissance et on continue directement notre lancée dans les mécaniques principales du jeu. Je commence également à me chauffer pour produire des concepts et key art visuels, un peu plus attrayants que mes patates non-texturées qui portent des cylindres. Mais quand le temps est limité, la programmation prime toujours.

Vous pouvez me suivre sur twitter (@Ariatowl) pour avoir des nouvelles régulières du développement.

Prenez-soin de vous, à la prochaine !

Revue de livre : Hyperfocus, de Chris Bailey

 Salutations, voyageur !

Nous nous retrouvons aujourd'hui pour une seconde revue de livre. Je vous avais parlé des bibles Deep Work (Newport) et Flow (Csikszentmihalyi), que j'espère bien avoir les balles d'acier, et l'esprit fougueux de présenter un jour sur ce blog. Mais j'ai récemment été surprise par un autre ouvrage relatif au bien-être : Hyperfocus, de Chris Bailey, publié en 2018.

Pourquoi surprise ? Je ne vais pas vous mentir, le domaine littéraire du développement personnel est un sous-bois, constellé à part égales de bouquets délicats de crocus printaniers, et de monticules de caca de sanglier. Si les deux vous promettent fragrances et graines de fleurs en abondance, je vous assure que vous préférerez mettre les mains dans le premier plutôt que le second.

Bon nombre d'ouvrages ont des prémices intéressants, mais sont ravagés par des promesses absurdes et un étalage d'axiomes philosophiques qui les rendent impraticables ou indigestes (coucou The Moutain Is You, de Brianna Weist, qui explique 150% de vos tares par des traumatismes sous-sous-sous-enfouis de votre vie antérieure inconnue et qu'il faut exorciser pour accomplir votre destinée épique), ou bien glacés avec une bonne couche de capitalisme américain et autres méthode magique pour gagner de la thune et devenir heureux, car avoir l'argent est bien évidemment un pré-requis du bonheur (non).

 

Merci, Brianna. Ravie de savoir que si je ne déterre pas mes traumatismes enfouis, je peux aussi bien me passer la corde au cou car je n'arriverai JAMAIS à faire mieux dans la vie, simplement en m'améliorant un peu chaque jour.

 

Pour être parfaitement claire, ces livres sont très populaires (tah le nombre d'évaluations Amazon), et je ne doute pas une seule seconde que beaucoup s'identifient aux descriptions qu'ils contiennent. Ils donnent sans doute une bouffée d'optimisme et de réflexions à un grand nombre de lecteurs (ce qui est toujours mieux que du jus de dépression). Mais je ne les recommanderai jamais à quiconque aurait besoin de conseils en développement personnel, surtout s'ils commencent leur recherche pour aller mieux ou progresser dans ce qu'ils aiment.

Toute cette bave verbale pour vous dire, qu'en téléchargeant l'extrait de Hyperfocus sur mon Kindle, je m'attendais à une autre compilation vague et moralisatrice ou à une nouvelle méthode infâme pour "changer sa vie ! OMG !! prenez une douche froide tous les matins et buvez de l'épinard broyé ! unleash ur productivity potential §§§".

ET BIEN PAS DU TOUT. J'avais tort, UNE FOIS DE PLUS.

Monsieur Bailey (béni soit cet alcool) nous offre ici une mise en lumière de l'attention, au travers de deux prismes principaux pour mieux évoluer dans sa vie : "l'hyperfocus" (comprenez l'hyper-concentration"), et le "scatterfocus" (la concentration "éparpillée", comme les M&M's que je viens de faire tomber sur le parquet parce que j'ai du beurre sur les mains).

 

Un bref résumé du livre

Comme son nom l'indique, Hyperfocus base tout ses préceptes sur la gestion de votre attention. L'ouvrage nous présente d'abord une représentation spatiale et imagée de cette capacité d'attention, une denrée limitée, mais cultivable, chez n'importe quelle humain.

Il se scinde ensuite en deux pour présenter un duo de modes de concentration, que l'on devrait apprendre à maîtriser pour avoir une vie riche et productive : l'hyperfocus, et le scatterfocus.

L'hyperfocus est un état couvert et étayé par de nombreux autres livres. C'est un état d'attention maximale et soutenue, portée sur une seule tâche, qui nous fait produire le maximum de ce que l'on est capable de créer en tant que singe évolué. Le planifier, l'encourager, l'entraîner avec la méditation, et éliminer un maximum des distractions qui peuvent nous dérailler de cette intensité mentale : les conseils sont variés, et bien qu'ils soient parfois redondants à d'autres guides (Deep Work, Make Time, Atomic Habits...), ils ont le mérite d'être présenté sous le spectre de cette capacité d'attention. Ce qui met en lumière certains leviers comportementaux invisibles dans les autres œuvres.

Le scatterfocus est pour moi le sujet le plus unique dans Hyperfocus. C'est un autre état d'attention, dispersé et régénérateur. Partout ailleurs, les auteurs mettent toujours en exergue la concentration soutenue. Elle se retrouve en opposition avec le fameux "repos" (au final rarement décrit autrement que "c kan on travay pa lulz !"), où il faut recharger son énergie, et ne pas consommer du contenu digital comme un maniaque. Mais quid de la créativité, et de ces moments où votre esprit bondit d'idées en idées, alors que vous regardez votre jardin avec un verre de thé glacé dans la main ? Ces inspirations, obtenues en marchant, ou sous la douche ? Monsieur Bailey appose un identifiant à cet état d'attention libre, opposée à l'hyperfocus, mais loin d'être oisif ou inutile. Vous laissez votre esprit rebondir entre les idées et les concepts, soit de façon libre pour capturer l'état de votre mental et planifier votre vie ; soit autour d'un sujet en particulier, pour générer des associations nouvelles et vous apporter des façons inédites de régler vos problèmes (et de créer !).

Cette définition du scatterfocus permet de mieux visualiser cet état alternatif à la concentration intense, et on se rend compte d'un seul coup qu'il est même nécessaire et naturel, quand on planifie notre vie, ou quand on a besoin d'idées innovantes pour un projet.

Le ton se veut pratique mais sérieux, bienveillant, et est étayé par de nombreuses études retrouvées dans d'autres livres de développement personnel - même si ici, leur quantité et leur pertinence sont un peu plus légères, et servent un propos un peu plus libre de la part de l'auteur (libre, mais qui s'entend plutôt bien).

Le maître-mot de l’œuvre est finalement l'alternative : une façon différente, mais très appréciable, de voir l'attention et la gestion de sa concentration au quotidien.

 

Bons points pour l'ouvrage:

 - clair et concis, ton neutre

- emphase sur l'adaptation et l'expérimentation personnelle

- prise de position plus nuancée et justifiée qu'ailleurs, sur le fait d'être multi-tâches (parfois, ça fonctionne tout à fait, mais pour des cas très précis et intentionnels)

- vision ludique et fraîche de la capacité d'attention

- on met le doigt sur un aspect privilégié à améliorer dans ses journées avec le scatterfocus : prendre du temps de réflexion libre pour capturer ses idées, et même poser les pré-requis indispensables à nos projets créatifs (là où l'hyperfocus n'est plus du tout adapté)

- bonne relecture, et bon substrat de réflexion, même si on n'adhère pas à toutes les idées

- très bon complément à d'autres livres traitant de la productivité et du bien-être

 

Défauts et points négatifs:

 - concepts et conseils parfois redondants, surtout pour sa dernière partie, et en ce qui concerne l'hyperfocus et la maitrise des distractions (si vous avez lu d'autres ouvrages de ce style, vous allez reconnaître plusieurs stratégies bien connues)

- inspirations parfois sorties du chapeau, ou très personnelles pour l'explication de certains effets ; toujours conserver sa bonne louche de critique avec soi

- ne traite pas vraiment le sujet du repos, ou des phases sans hyperfocus ni scatterfocus (impossibles à maintenir 100% du temps)

- bienveillant, mais apporte encore un propos malvenu et pas assez nuancé sur l'utilisation du temps libre : on dirait que si vous ne l'utilisez pas pour apprendre à coder du Python, ou pour avoir une licence d'économie, qu'est-ce que vous faites de votre vie, ololz ?? Passer du temps avec votre famille, ou vous allonger 45 minutes pour regarder un match de rugby dans la semaine ? MAI VOU ETE FADA OU KOI ?? BILEVESÉES INSOUTENABLES AAAAAAA-

 

À qui ce livre s'adresse t-il ?

En tant que graphiste, je souhaite conseiller cet ouvrage à toute personne qui a besoin de créativité dans ses activités (pas forcément de la peinture ou de la narration hein - ça peut être de la stratégie, du développement, de la gestion d'équipe...). 

Même si vous avez l'impression d'avoir une bonne capacité de concentration, et de bien museler vos distractions, la description du scatterfocus m'a aidée à retrouver ce processus qui existait déjà dans ma vie, mais qui avait tendance à être écrasé par l'hyperproductivité : se poser confortablement devant un tableau, une forêt, une place fourmillant de vie. Et réfléchir de façon détendue à notre journée, ou à notre projet en cours. 

Ce qui ressemble à de l'oisiveté, est en réalité une étape cruciale de tout processus créatif. Vous ignorez naturellement les distractions inutiles pour cultiver vos idées et votre personnalité. Et vous ne reviendrez à votre bureau que gonflé d'inspiration et d'énergie, pour progresser, et atteindre vos objectifs.

J'ai redonné une place de choix à ces moments dans mes journées, pour imaginer en détail l'univers de Lampyre et ses mécaniques. Ce travail de réflexion libre me permet d'innover et de construire un monde original à vitesse folle ; comme je le faisais quand j'écrivais des nouvelles à tour de bras, il y a quinze années. L'état de fait parait très idiot à constater. Mais quand on met trop d'emphase à travailler le nez collé à l'écran ou à la table, on en oublie que des fois, il faut regarder l'horizon pendant une heure comme un demeuré pour produire des idées géniales.

Prenez soin de vous, à la prochaine !