rewind a écrit 3425 commentaires

J'utilise un entity system

Et alors ? Est-ce que ça te plaît comme manière de penser ? Je vois que tu as déjà pas mal de code, ça m'impressionne. Et que tes composants sont tout petits, tu n'as pas peur d'avoir trop découpé ? Il y a des choses, je me demandais comment j'allais faire, je pourrai m'inspirer de tes techniques ;)

C'est ce que j'ai cru comprendre et je me suis à un moment posé la question :)

Tu peux prendre ton temps pour la réponse, je ne vais pas trop vite ;)

Et je me suis trouvé une autre excellente excuse pour eviter d'entrer dans un projet qui me prendra beaucoup de temps.

Oui et non. Je n'ai pas beaucoup de temps non plus, donc j'essaie d'avancer lentement mais sûrement. J'ai une liste de choses à faire qui s'allonge donc, ça devrait aller pour m'occuper un moment. Si quelqu'un me rejoint à un moment, ça devrait aller avec tous les articles et toute la documentation que j'écris au fur et à mesure.

Il est développeur de jeu, c'est forcément quelqu'un de bien ! :P

Le code est disponible sous les termes de la version 3 de la GPL et les ressources sous les termes du contrat Creative Commons dans sa variante paternité, partage à l'identique, en version 3.

Pourquoi ne pas avoir tout mis sous GPLv3, code et données ?

Nous l'avons utilisé principalement pour des jeux de plates-formes mais nous pensons qu'il peut très bien être utilisé pour d'autres types de jeux, par exemple pour des jeux vue de haut.

Ce qui manque pour ce moteur de jeu, c'est de la documentation. Parce que, oui, c'est peut-être possible de faire d'autres types de jeu, mais si on veut se faire une idée plus précise, on peut difficilement. Sans compter qu'il y a des choix qu'on pourrait questionner comme le fait de ne pas avoir choisi Box2D pour le moteur physique (y a-t-il une raison particulière ou c'est juste un petit NIH ?)

Après sur le papier, ça a l'air intéressant, ça offre tout un tas de fonctionnalités sympathiques. Et ça donnerait presque envie de plonger dedans et de contribuer. Je pense que quand j'aurai fini mon jeu, je jetterai un coup d'œil, j'aurai un peu plus de bouteille sur les problèmes et les solutions et je serai sans doute plus utile que maintenant.

C'est bien ça, une nouvelle version de nanimstudio ! Du coup, ça tombe bien que tu montres cet exemple parce que j'avais une question à propos des animations à une seule frame. Je vois ici que tu mets la durée à une valeur arbitrairement grande, est-ce que c'est la bonne façon de faire ?

Le choix d'une vue en 3d isométrique nous a amené à choisir Tiled pour l'édition des niveaux. Là aussi c'est un choix par défaut, car il n'y a pas beaucoup d'alternatives sur ce "marché".

En fait, plus j'y pense, plus je me dis que Tiled fait soit trop de choses, soit pas assez. Tiled pourrait être un simple logiciel pour construire des cartes et rien d'autres. Le fait est qu'il sait faire d'autres choses comme mettre des formes sur la carte. Mais du coup, ces formes et leur signification dépendent beaucoup du jeu qui va les charger. Et donc, il y a une phase de conversion à faire dans tous les cas. On peut s'en sortir plus ou moins bien avec les propriétés associés aux objets mais ça devient vite lourdingue.

En fait, Tiled devrait être un composant parmi plein d'autres (qui n'existent quasiment pas) pour créer un moteur de ressources de jeu. Mais ça demanderait beaucoup de boulot, notamment normaliser les besoins des jeux de manière à peu près générique. Tout ça, c'est généralement refait dans chaque jeu, et c'est de la perte de temps je trouve. On pourrait aller beaucoup plus loin. L'autre solution, c'est d'utiliser un moteur de jeu complet, avec tous les inconvénients que ça engendre.

Ma bibliothèque laisse le jeu faire le chargement lui même.

Oui, j'ai fait pareil pour libtmx. Même si en C++, on n'a pas un truc plus ou moins standard pour charger les images (à l'inverse de Java), je me dis que les bibliothèques graphiques savent faire ce genre de chose, et le font toutes différemment, donc laissons ce travail facile à l'utilisateur. La seule difficulté, c'est de calculer le bon chemin jusqu'au fichier (puisque les chemins sont déterminés en fonction du fichier courant).

Et maintenant ça marche, mais il me semble que ce genre d'opération n'est pas très très propre.

Dans ce cas, il me semble que c'est pkg-config qui fait mal son boulot. Dans ma manpage de pkg-config, tu as une liste des répertoires qui sont visités à la recherche de .pc.

La suite : avec gcc 4.7, j'ai compilé libtmx (cmake, make…). Résultat (…)

Je pense que la libstdc++ qui est avec gcc ne devait pas être tout à fait complète. Je crois que je vais mettre une dépendance gcc >= 4.8. Le ifdef marche avec gcc 4.6 cependant.

Et pour finir (…)

Celui-là, on me l'a signalé par ailleurs. Je vais regarder ça.

Pour libtmx, on me demande d'installer tinyxml2. Fait via le git du projet, mais n'est pas reconnu.

D'après ce que je vois, pkg-config n'a pas réussi à trouver le .pc de tinyxml2. Je pense que tu as dû utiliser autre chose que CMake pour contruire et installer tinyxml2, parce qu'il y a bien un .pc dans les sources.

Quatre dépendances dont la plupart ne sont pas dans les grandes distributions. Tu vas t'amuser lors de l'empaquetage.

M'en parle pas :D Mais de manière générale, je trouve qu'il y a assez peu de jeu dans les distributions. Dans Debian, par exemple, il n'y a aucun paquet qui dépendait de SFML 1.6 !! Et je ne parle pas de Box2D qui est packagé comme un goret. Donc, je me dis qu'il faudra que je trouve un moyen de fournir un binaire.

Je vais avoir un besoin de cross-compiler pour le jeu que je développe et pour lequel j'aimerais bien fournir une version Windows à moyen terme. Je pensais que j'allais devoir me coltiner le montage d'un environnement de dev sous Windows et que ça allait être très galère. Donc, quand j'ai vu ton projet, j'ai crié hourra et j'ai essayé pour voir si c'était facile. Réponse : oui, c'est facile !

Maintenant, comme je n'en ai pas besoin dans l'immédiat, je peux attendre la correction du bug. Si ça prend du temps cette correction, j'appliquerai ton astuce pour que ça marche. Mais en tout cas, je pense que je vais adopter ta solution de cross-compilation pour Windows. Elle m'a convaincue.

Du coup, j'ai essayé avec le build 20131004 mais j'ai le même bug. Je crois que je vais m'arrêter là pour l'instant et attendre que ce bug soit résolu.

J'ai essayé mais en fait, ça ne résout rien, parce que ça vient de ce qui est déjà compilé par Mingw-w64, donc il faudrait tout recompiler Ming-w64 et vérifier que ça fonctionne. Parce que je pense que le bug est corrigé dans le trunk.

Je confirme que c'est assez naturel. Par exemple, pour SFML qui n'est pas dans le dépôt, j'ai décompressé les sources de SFML-2.1, j'ai installé les dépendances nécessaires à SFML :

crossroad install freetype-devel
crossroad install glew-devel
crossroad install libjpeg-devel
crossroad install openal-soft
crossroad install libsndfile-devel

Et ensuite, j'ai essayé de compiler. Bon, j'ai eu le bug cité ci-dessus mais je suis sûr que sinon, ça marche !

Est-ce que ce ne serait pas lié à ce bug aussi ?

T'utilises quelle version de MinGW-w64?

La 3.0.0 donc plutôt récente.

J'ai testé un peu et j'ai trouvé ce que je pense être un bug. Le répertoire .cache/crossroad/prefix n'est pas créé et à un moment, ça pose problème, ça finit en exception.

Sinon, pour le reste, j'ai installé ming-w64 sur ma Debian (unstable) et j'ai pu compilé quelques trucs, sans souci. J'ai installé des paquets depuis les dépôts Fedora, sans problème. Mais à un moment, il y a qqch qui a dû mal se passer et je n'arrive plus à compiler, je me retrouve avec une erreur :

/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/lib/crt2.o:
dans la fonction « __tmainCRTStartup »:


/tmp/buildd/mingw-w64-3.0.0/build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/../../mingw-w64-crt/crt/crtexe.c:285:
référence indéfinie vers « _set_invalid_parameter_handler »

Et même les trucs que j'avais réussi à compiler, ça ne marche plus. Je ne comprends rien. Si quelqu'un a eu le même genre de blague, ça m'intéresserait de comprendre.

Si tu ne voulais que faire un jeu quelconque du moment que ça te permet de combler ton envie de faire un jeu et de le faire grâce au système à entités, tu ne chercherais pas à (je te cite) "changer des habitudes" de jeu.

C'est beaucoup dire. Il faut pondérer tout ça, ça n'a pas le même poids.

On ne la retrouve pas dans tes "généralités", là où elle devrait être.

C'est parce que j'ai pas encore pushé. Je me suis rendu compte via la discussion au dessus qu'il n'y avait pas de description globale, ou plutôt qu'elle était incomplète. Du coup, je l'ai complété, exactement de la manière dont tu dis.

En lisant donc pour la première fois ce que tu considères comme étant un "thème" j'ai été agréablement surpris, mais me suis vite rappelé que ça avait déjà été proposé : incarner un "méchant".

C'est en ça que ce n'est pas original. Jouer un méchant, j'ai fait ça dans Dungeon Keeper il y a 15 ans, donc non ce n'est pas nouveau. Dans les RPG, c'est plus rare. Maintenant, je n'en fais pas un truc vraiment différenciant par rapport au reste. Disons que ça donne un peu de sel et que ça permet d'imaginer d'autres choses que ce qu'on voit habituellement. Mais au final, ça va sans doute être très classique.

Le premier problème c'est que ça ressemblera bien vite à l'atroce levelling qu'on connaît tant dans les mmorpg : on progresse pour débloquer de nouveaux sorts, qu'il faudra ensuite arranger à sa guise, utiliser intelligemment pour espérer évoluer dans les strates de difficulté ultime. Bref, ça peut faire fuir, voire attirer un public que tu ne vises pas du tout.

C'est pas un peu la mécanique de base de tout RPG ? Avec plus ou moins d'insistance mais globalement, dans tout RPG, tu as un système de levelling où tu progresses. Je ne dis pas que c'est le centre du jeu, et ça ne l'est pas d'ailleurs.

Le second c'est comment faire en sorte que le joueur se sente vraiment dans la peau de quelqu'un qui avait des pouvoirs costauds et de ce fait naisse vraiment en lui le désir de les retrouver.
Donc il faudrait peut-être que tu évites tout ce qui pourrait amener le joueur à se sentir passif.
Proposer au joueur de vivre brièvement ces grands pouvoirs avant leur perte en guise d'intro pourrait aussi pousser le joueur à les convoiter ardemment tout au long de l'aventure.

Oui ! Je vais faire une cinématique en 3D de 15 minutes pour décrire ça ! Non, je rigole :P Plus sérieusement, je ne me fixe pas ce genre d'objectif qui me semble trop haut. Faire un jeu jouable et plaisant, ça sera déjà bien. Et pour cette partie, quelques monologues en début de jeu devraient faire l'affaire dans un premier temps.

Troisièmement ça sonne plus comme une histoire à lire que comme un jeu où l'on va être surpris par la chute scénaristique.

C'est plutôt normal. C'est un scénario. Et je pense que ça va transparaître dans le jeu, il y a une certaine linéarité. Mais je veux aussi éviter le tube scénaristique (façon FF13). Si je peux faire un truc à la FF12 (tu es assez libre de te balader mais il y a un gros fil conducteur), ça m'ira. Mon fil conducteur, c'est qu'elle veut retrouver ses pouvoirs.

Pourtant d'office on se retrouve à en faire l'opposé (aider des villageois), ça risque de déboussoler, au pire frustrer d'emblée. Qui plus est le joueur y est contraint pour progresser.
Ensuite les autres personnages lui indiquent presque gentiment (c'est ce qui ressort de tes grandes lignes de scénario) une source de pouvoir à emmagasiner. Y'a pas un moment où la vieille se dit que y'a anguille sous roche ?

Bon, ok, je peux sans doute changer cette partie trop gnangnan. Mais après, ça sert aussi à mettre l'ambiance (l'héroïne montre qu'elle déteste ça). Au départ, elle est vulnérable donc elle n'a pas trop le choix : si elle fait de la merde, elle va se faire attraper.

Et au final le protagoniste (et le joueur) se retrouve berné et… fin ?!

Bah oui. Déjà là, je vais devoir écrire pas mal de lignes de dialogues pour ce que j'ai prévu. Donc, pour l'instant, ça ira comme ça.

L'histoire est intéressante, mais beaucoup de joueurs risquent d'être définitivement déçus par l'expérience qui n'a pas été celle qu'ils attendaient.
Pourquoi ne pas amener ça plutôt dans le jeu ? Et proposer quelque-chose de différent à faire ensuite ?

Parce que sinon, qu'est-ce que je vais faire pour la version 2.0 ? :P Non mais sérieusement, je veux rester dans le simple, donc bon.

C'est vraiment plus un journal de bord et ta progression risque d'être très intéressante à suivre.

Voilà, c'est ça. C'est comme un blog sauf que c'est au milieu de tout le reste de linuxfr.

À ce sujet, tu as déjà tous tes épisodes de prévu ou tu carbures davantage au feedback des linuxfriens ?

Tous non. Quelques uns oui. J'ai déjà quasiment les deux suivants qui sont bien délimités. Je me dis qu'un épisode toutes les deux semaines, c'est un bon rythme. Ensuite, j'ai des idées et des liens à proposer pour des épisodes plus lointain. Et après, je prend en compte l'avis des linuxfriens, évidemment, sinon ça ne servirait à rien d'écrire ici. Le tien m'intéresse parce qu'il semble être très critique (mais je le prends bien hein).

Le problème est que, sans traiter l'expérience, tu risques de mettre tes lecteurs désireux de concevoir un jeu sur la mauvaise voie.
Quelqu'un de mal avisé se dira après lecture qu'en fait oui, on peut concevoir comme ça, pour le trip - ce qui rejoins les développeurs qui se dispensent de graphistes ou leurs imposent leur projet. Pour l'entraînement d'accord.

Je pense au contraire que ça ne pose aucun problème. Tout le monde fait la différence entre un jeu développé tout seul, en amateur, et un jeu vidéo à destinée commerciale, développé par une équipe de manière professionnel. C'est un peu comme si tu disais à un gars qui fait un soft dans son coin en amateur qu'en fait, il s'y prend mal parce que les pros en entreprises ne font pas comme ça. Là, ça s'applique à un jeu vidéo mais peu importe, le principe ne tient pas. Ça ne peut pas se comparer. Je pense que je ne m'y prend pas si mal que ça pour un premier jeu, j'écoute les conseils et je les applique à mon échelle.

Julien Jorge t'a poussé subtilement (même si ce n'est pas voulu) à en rédiger un en te parlant de l'inconvénient qu'il a vécu sans, et ce que tu en fais pour le moment c'est y déposer tout ton scénario et tes personnages, ton univers.
Il est bien question de techno à la fin, mais je ne vois pas vraiment de mécaniques.

Ce document n'est pas définitif, je travaille encore dessus. Donc qu'il manque des choses, c'est plutôt normal. Ça va se résoudre petit à petit.

C'est donc bien TON jeu vidéo que tu conçois. Et la démarche est intéressante vraiment, mais il y a des choses vraiment importantes à poser pour compléter ta série. =)

Justement, j'attends les commentaires pour compléter ce qu'il y a à faire. Après, ça prend du temps et je vais lentement. Ce qui a un avantage, c'est que je peux corriger assez tôt dans le processus.

J'ai souvent du mal à m'exprimer et je pars dans pas mal de longueurs, je tiens dons à m'excuser si le ton peut parfois paraître trop accusateur.

Pas de problème ;) J'avais surtout l'impression qu'on ne se comprenait pas bien sur les finalités de ce projet.

Je ne saisis pas ce que tu proposes via Akagoria.
Est-ce juste une excuse pour appliquer le système à entités ou c'est vraiment censé aider à concevoir un jeu vidéo ?
Dans ce dernier cas il semble manquer une étape vitale, que j'ai peut-être loupé dans tes deux premier épisodes mais je ne me souviens pas avoir lue.

J'ai raisonné de la manière suivante : 1 j'ai envie de faire un jeu, 2 les systèmes à entités, ça a l'air rigolo pour faire des jeux, 3 et si j'utilisais ça pour faire un jeu ? Rien de plus.

Avant de citer les quatre étapes de S. Lambert, peut-être faudrait-il savoir ce que tu veux offrir au joueur. C'est ce dernier le plus important, alors que tu justifies ton concept de jeu dans l'épisode 2 par trois raisons qui sont grandement rapportées à toi.
Tu es tout à fait en droit d'aimer et préférer le RPG - bien que ce choix de design ne soit pas non plus justifié de ce fait - cependant ton projet ne semble pas avoir d'intérêt qui le distinguerait d'un autre.
Ce n'est pas ton cas, mais évite à ton projet d'obtenir une telle image. Parce que professionnellement parlant il ne semble pas sérieux, et perd donc en crédibilité.

Non, mais je ne compte pas en vivre de ce projet. J'ai un métier qui me satisfait complètement. Je fais ce projet pour m'amuser et en même temps, je partage cette expérience ici (et apparemment, ça a l'air de plaire aux usagers de linuxfr). Effectivement, mon jeu n'est pas révolutionnaire, et il n'a pas l'ambition de l'être, ni dans son thème, ni dans sa réalisation, ni dans rien en fait. Oui, les trois raisons se rapportent à moi, parce que je fais ce jeu pour moi avant tout. Si d'autres y jouent, très bien, sinon, c'est pas bien grave, ça ne va pas m'empêcher de dormir. C'est juste un passe-temps, ça n'a pas vocation à devenir autre chose, notamment un projet professionnel. C'est peut-être de là que vient ton incompréhension.

Dans la bible que tu as écrite d'après conseil - je salue au passage Julien Jorge pour sa participation à ta série, qui mérite qu'on s'attarde dessus pour les réflexions qu'on y apporte justement - ça se sent encore plus.
Dans les généralités je ne relève que des mots-clés pour moteur de recherche. Tu attaques le scénario direct après !
On ne peut même pas parler d'Argument Clé de Vente puisqu'il n'y a rien qui indique que l'utilisateur va vivre une certaine expérience.

Ça tombe bien, je ne veux pas le vendre. Donc, pas besoin d'argument de vente. J'essaie d'avoir une organisation efficace (parce que le temps est une denrée rare donc autant ne pas le gâcher) et donc je prend tous les conseils qui me sont donnés par ceux qui ont déjà fait des jeux (et c'est bien à ça que sert cette série d'article, partager l'expérience) et j'essaie de les appliquer. Si je le fais mal, et bien on me le fera remarquer et j'essaierai de corriger.

Je ne te demande pas de devenir du jour au lendemain un game designer pour le bien de cette série, mais il faudrait peut-être aussi parler de l'importance étymologique du nom de ce "métier".

Je n'ai jamais prétendu être game designer et je ne compte pas le devenir.

Alors certes tu n'es pas game designer, me diras-tu. Or il va falloir essayer d'en être un, ou d'en trouver dans le cadre de cette série.

Pourquoi ?

Deux défis se proposent à toi : jeter ton projet (c'est connu, les GD suppriment leurs "dix premiers projets" ') ou, plus ardu, conserver le genre et tes idées (y'en a des sympathiques je trouve) tout en y accolant une expérience qui les justifie - du moins le genre.

La première solution est évidemment complètement exclu. Et je ne comprend pas bien la deuxième.

Mais surtout je te conseille L'Art du game design, de Jesse Schell, enfin traduit.

Je me l'achèterai peut-être, on verra, mais ça sera plus pour ma culture que pour l'appliquer dans le cadre de ce jeu.

Je me souviens d' un temps lointain ou linuxfr etait plus un bande de potache a rigoler tous ensemble, certe a troller mais gentiment, sans insulte.

Ensuite, Zenitram est arrivé…

Quand on est le dernier, on est forcement le plus vieux.

C'est la dernière en date, pas l'ultime. Qu'elle soit vieille, ça lui permet de passer pour inoffensive, et ça permet qu'elle ne se batte pas contre Kalista.

Ou un demi-dieux, ou une sorcière, au choix. Je n'ai pas d'autre exemple qui le viennent spontanément.

Oui, le grand boss de fin méchant, mais là du coup, ça va pas marcher ;)

Oui, je n'ai pu regarder mes mails sur cette adresse hier. Et du coup, je t'ai répondu !

Ce qui me gène dans le scenario, c'est qu'on pourrait remplacer "sorcière" par "fée clochette" sans changer grand chose. Les "beurk" peut-être…

Justement, aider les villageois, ça va être un passage obligé au début et ça va être déplaisant pour elle (d'où les beurk). D'ailleurs, ça va aussi se voir dans les contacts avec les animaux, dans le sens où les animaux présumés méchants ne vont pas l'attaquer tandis que les animaux présumés sympas vont l'attaquer systématiquement. Donc, très vite, on va voir que ce n'est pas une héroïne comme les autres.

Si je contrôle une sorcière, je veux empoisonner l'eau du puits, négocier avec les esprits et les démons, pas aider des villageois !

Oui, oui, ça va être ça, mais ça doit rester aussi un peu humoristique. Du coup, ça va foirer souvent.

Pis franchement, moi j'aide le nécroment contre quelques services !

En fait, ça dépend. Tu as le choix entre l'aider mais derrière, tu n'auras pas l'information que tu cherches, ou ne pas l'aider (ce n'est qu'un obstacle sur la route). Et puis potentiellement, le nécroment, il est plus fort que toi, donc tu vas plutôt chercher à l'éliminer après lui avoir soutiré toutes les informations (et un petit parchemin magique), ça fera un concurrent de moins. Elle est méchante mais elle est égocentrique aussi !

Sur l'univers justement, tu vois ça comment ? Merveilleux nordiques avec trolls, elfes et gobelins ? Médiéval avec korrigan et chevalier ? Antique avec muses et mânes ? Autre ?

Plutôt ultra caricatural mais détourné pour que ce soit drôle. Genre le dragon à la fin (parce qu'à la fin il y a toujours un dragon, non ?), il est juste blasé d'être là, il est énervé qu'on le dérange. Genre la princesse Mikith, elle est complètement naïve et elle plane à 10000m dans sa tête. J'hésite à mettre des elfes et des nains parce qu'en vue de haut, ça ne va pas rendre des masses.

Sinon, un détail : Tokiann est la dernière héritière ou la doyenne seulement ? Le paragraphe à son sujet semble se contredire.

Les deux ! C'est la doyenne de l'Académie de Magie mais aussi la dernière héritière de la Guilde des Mages, c'est une sale cumularde !

En tout cas, ça c'est de la bible scénaristique !

C'est la trame grossière, il manque encore pas mal de détails (d'où tes questions et d'autres avant). Il manque encore pas mal de quêtes annexes qui vont colorer encore l'univers (et où il y a moyen de pratiquer la caricature à outrance).

Mais si tu dois mettre à jour la position de tous les chats/lapin/vache de la map à chaque frame, c'est ton moteur de jeu qui va pas trouver ça simple :)

Oui, ça j'ai bien compris la problématique ;) Et je comprends le principe de la solution et je partage entièrement l'analyse. Yapluka implémenter !

ça coûtera moins cher que de faire des calculs de distance avec le joueur. Ce qu'il faut c'est un moyen de les "exclure" du système quand elles sont trop loin (et plus dur, les ré-inclure quand on se rapproche)

Calculer la distance avec le joueur peut se faire assez simplement, avec la Distance de Manhattan, norme 1 pour les matheux, ou avec la norme infinie. Une autre solution, c'est de partitionner l'espace et de ne se concentrer que sur la portion actuelle, genre avec un Quadtree.

Il manque le nécessaire dans ta roadmap :)

Lister les éléments c'est bien, mais tu les implémentes quand ?

Je préfère lister tous les éléments avant de faire les étapes. J'avais commencé à faire les étapes mais en fait, j'avais oublié des éléments, et du coup, j'étais obligé de modifier les étapes. Conclusion : je liste d'abord les éléments (je pense qu'il m'en manque quelques unes) et ensuite, je fais les étapes.

Sur une map2d c'est extrêmement simple de faire une règle de trois (ok, c'est un peu plus :) ) pour savoir quelle partie afficher. Ne t'en prive pas surtout si tu veux faire des maps infinies après.

Oui, je vais mettre ça en place rapidement.

De la même façons, il n'est pas obligatoirement nécessaire de mettre à jour toutes les entités du jeu. Si un garde fait les cent pas pour garder une porte, ça ne sert à rien de mettre à jour sa position si il est à deux écrans du joueur.

Là, ça me paraît moins simple de prime abord. Notamment parce que ça veut dire que tous les systèmes qui font des mises à jour d'entités doivent avoir accès à la position de l'entité. Il faut que j'y réfléchisse pour voir comment mettre en œuvre ça de manière à peu près propre.

Si le tmx change tout le temps

Il ne change pas du tout au tout. Disons qu'à chaque version, il peut y avoir quelques petites modifications qui peuvent devenir chiantes à maintenir. De toute façon, ça ne change pas le reste de ton raisonnement. Mais il faut du coup créer et documenter les formats internes. On peut utiliser protobuf comme le fait devnewton, ce qui permet d'avoir un fichier lisible et compréhensible du contenu des fichiers.

C'est d'ailleurs ce que rewind fait avec son script es_make pour générer le système d'entités

Tout à fait ! Mais là, c'est pour éviter d'écrire du code redondant.