Il est vrai que ce qu'on donne à voir n'est pas nécessairement représentatif de la manière dont on a fait le jeu. Toutefois c'est déjà ça. De plus, de par la manière dont on l'a fait (C99, limite de 80 caractères par ligne, cmake et pas un fichier d'un environnement de développement intégré pour compiler, toutes les dépendances sont stables et disponibles dans les distributions Linux hors Android et chez les *BSD, SDL2 et pas un gros moteur comme Godot, etc.), on peut le continuer d'une manière sobre (au sein de l'ordinatique), même si ça avait été fait jusque là d'une manière lourde (au sein de l'ordinatique). Mais pour les curieux et curieuses, on l'a fait avec GNU Emacs (avec peu de personnalisation et légère quand on en a fait) sous Debian GNU/Linux et Trisquel GNU/Linux avec Xfce 4 (certes LXDE ou LXQt seraient par exemple mieux, sans parler de faire sans interface graphique), mais il est vrai malheureusement des processeurs Intel et pas qui soient économes (Atom et compagnie) sans pour autant que ce soit des machines de guerre avec les standards actuels (mais si ça l'aurait été, ça n'aurait rien dit de la consommation à l'usage, car les processeurs Intel et AMD peuvent heureusement adapter leurs fréquences en fonction de l'intensité du travail qu'on leur demande). Enfin, il aurait certes été mieux d'utiliser par exemple de l'ARM ou du MIPS, mais il faut néanmoins garder à l'esprit que le plus gros du coût écologique n'est généralement pas dans l'usage mais dans le reste du cycle de vie (extraction, assemblage, transport, post-usage), donc utiliser des composants ordinatiques déjà produits est souvent mieux que d'en acheter des neufs plus économes à l'usage (mais on peut nous rétorquer qu'on aurait pu acheter par exemple un Chromebook ARM d'occasion sur lequel on pouvait installer Trisquel GNU/Linux ou le cas échéant une autre des distributions GNU/Linux recommandées par la FSF ou Debian GNU/Linux malgré ses quelques problèmes).
[^] # Re: ~~Paradoxal~~ Sobre
Posté par gnoucat2 . En réponse à la dépêche Tuxemon Tower 0 : sortie de la première version !. Évalué à 1.
Il est vrai que ce qu'on donne à voir n'est pas nécessairement représentatif de la manière dont on a fait le jeu. Toutefois c'est déjà ça. De plus, de par la manière dont on l'a fait (C99, limite de 80 caractères par ligne,
cmakeet pas un fichier d'un environnement de développement intégré pour compiler, toutes les dépendances sont stables et disponibles dans les distributions Linux hors Android et chez les *BSD, SDL2 et pas un gros moteur comme Godot, etc.), on peut le continuer d'une manière sobre (au sein de l'ordinatique), même si ça avait été fait jusque là d'une manière lourde (au sein de l'ordinatique). Mais pour les curieux et curieuses, on l'a fait avec GNU Emacs (avec peu de personnalisation et légère quand on en a fait) sous Debian GNU/Linux et Trisquel GNU/Linux avec Xfce 4 (certes LXDE ou LXQt seraient par exemple mieux, sans parler de faire sans interface graphique), mais il est vrai malheureusement des processeurs Intel et pas qui soient économes (Atom et compagnie) sans pour autant que ce soit des machines de guerre avec les standards actuels (mais si ça l'aurait été, ça n'aurait rien dit de la consommation à l'usage, car les processeurs Intel et AMD peuvent heureusement adapter leurs fréquences en fonction de l'intensité du travail qu'on leur demande). Enfin, il aurait certes été mieux d'utiliser par exemple de l'ARM ou du MIPS, mais il faut néanmoins garder à l'esprit que le plus gros du coût écologique n'est généralement pas dans l'usage mais dans le reste du cycle de vie (extraction, assemblage, transport, post-usage), donc utiliser des composants ordinatiques déjà produits est souvent mieux que d'en acheter des neufs plus économes à l'usage (mais on peut nous rétorquer qu'on aurait pu acheter par exemple un Chromebook ARM d'occasion sur lequel on pouvait installer Trisquel GNU/Linux ou le cas échéant une autre des distributions GNU/Linux recommandées par la FSF ou Debian GNU/Linux malgré ses quelques problèmes).