Python et jeu de gestion

a marqué ce sujet comme résolu.

Salut,

Le langage idéal je ne sais pas (est ce que le langag idéale existe ?) cependant ça me semble être une bonne idée pour plusieurs points:

  • il est facile de programmer en python (mais c’est aussi facile de faire du grand n’importe quoi)
  • il y a des bibliothèques pour faire des jeux
  • il y a beaucoup de gens qui utilisent ce langage, dont aussi une grande partie que font des jeux avec

En plus, selon ton niveau python me semble un bon choix car si tu es débutant tu auras la possibilité de progresser vite et si tu es expérimenté tu pourras facilement utiliser des notions avancées de python.

+2 -0

et autre avantage il est cross-platform :-)

rocketter

Il est cross-platform, oui et non, je suis partagé de dire ça parce qu’il faut quand même un interpréteur python sur la machine cible. Là, où on pourrait avoir un binaire que l’on peut copier d’un ordinateur à l’autre.

Donc oui, python est cross-platform (comme presque tous les langages) mais ton application finale ne le sera pas vraiment. Pour avoir du vrai cross-platform en python, à mon sens, il faut freezer le projet (avec cx_Freeze par exemple) ce qui te permet d’avoir un seul fichier qui pourra fonctionner sur plusieurs ordinateurs.

Je ne suis pas sur d’avoir la bonne réponse mais c’est mon interprétation.

+0 -2

il faut freezer le projet (avec cx_Freeze par exemple) ce qui te permet d’avoir un seul fichier qui pourra fonctionner sur plusieurs ordinateurs.

pyoroalb

Non, ce n’est pas une bonne pratique, ce n’est pas la manière de packager une application Python.

j’envisage de créer un jeu de gestion dans un futur plus ou moins proche, concernant le langage je souhaitais essayer avec Python, pensez-vous qu’il soit le langage idéal pour ce type de jeu ?

Qu’entends-tu par "jeu de gestion" ? Pourrais-tu le décrire ?

Parce que cette dénomination est très vague, ça peut aller d’un truc basique comme l’entraîneur ("basique" au sens de l’interface) à un jeu à la sim city en passant par Marrons glacés Tycoon (Non, ce jeu n’existe pas, mais ça serait un jeu où on commencerait par tenir un stand de marrons glacés jusqu’à développer un empire mondial du marron glacé. Bref…).

Autre détail qui va beaucoup jouer dans le choix de la techno, plutôt 2D ou 3D ?

Par ailleurs, que vises-tu comme plateforme ?

Spontanément, dans l’absolu, si ton projet est vraiment LE jeu lui-même plutôt que l’apprentissage d’un langage ou apprendre à coder des jeux en général, j’aurais plutôt tendance à te rediriger vers un moteur comme godot, par exemple.

Par contre si ton but est d’apprendre à programmer dans un langage qui peut faire plein de choses, y compris des jeux, et que ton jeu est un projet court-moyen terme pour parvenir à cette fin, alors oui, Python est un bon choix.

+1 -0

il faut freezer le projet (avec cx_Freeze par exemple) ce qui te permet d’avoir un seul fichier qui pourra fonctionner sur plusieurs ordinateurs.

pyoroalb

Non, ce n’est pas une bonne pratique, ce n’est pas la manière de packager une application Python.

entwanne

Pourquoi ce n’est pas une bonne pratique ? Quels sont les inconvénient ?
Quelle est la bonne manière de packager une application Python ?

+0 -0

Pourquoi ce n’est pas une bonne pratique ? Quels sont les inconvénient ?

Parce que cela implique de livrer l’interpréteur et tout l’environnement Python en plus de ton soft, ce qui est lourd, et globalement du gaspillage : si tu installes 10 applis freezées, alors tu te tapes 10 fois le runtime et la bibliothèque standard.

La bonne façon de packager pour Windows, c’est de la packager the hard way, avec un installeur qui vérifie la présente ce Python, dans une version compatible, sur le système, et qui propose de l’installer le cas échéant.

Cela dit, j’aimerais bien tempérer le débat :

  • Packager une application correctement pour Windows est tellement une plaie que le freeze semble quand même acceptable : ça ne fait jamais que 10 ans qu’on attend de disposer d’une méthode standard et simple à l’utilisation pour distribuer proprement une appli Python sous Windows. Au bout d’un moment ça me semble complètement hallucinant, vu le faible coût du ticket d’entrée de Python, de persister à forcer les gens à se palucher l’écriture d’un installeur Windows : les gens veulent que leur programme tourne sur la machine cible, rien de plus, et si le plus facile est également le plus sale, ce n’est pas leur faute, mais plutôt une pierre dans le jardin de la communauté Python qui a échoué à produire une solution techniquement propre et facile à utiliser.
  • Ce n’est pas du tout le sujet ici.
+4 -0

Ouais, mon point c’était que cx_freeze aura pour effet de produire des exécutables qui ne seront justement pas cross-platform, alors qu’un projet de base publié sur le PyPI l’est.

Le problème de Windows est qu’il est difficile d’y installer des programmes via pip.

Bonjour,

j’envisage de créer un jeu de gestion dans un futur plus ou moins proche, concernant le langage je souhaitais essayer avec Python, pensez-vous qu’il soit le langage idéal pour ce type de jeu ?

rocketter

Si tu te demandes si Python est adapté d’un point de vue performance pour un jeu de gestion, je dirais que ça dépend et qu’il faudrait nous en dire plus.

En ce moment, je passe ma vie sur OpenTTD, un jeu de gestion dans lequel on peut faire un réseau de chemins de fer, et faire tourner des trains dessus. Clairement, les grahismes du jeu ne pompent pas les resources de ma machines. En revanche, aussi bête que cela puisse paraître, il faut quand même « simuler » les réseaux ferroviaires en simultané pour que le jeu marche, et ça me gratte beaucoup de CPU (c’est une simulation après tout). Cela implique de calculer un nouvel état à chaque quantum de temps du jeu, incluant la position de chaque train, de chaque entrée d’argent, de chaque sortie d’argent, de la population de chaque ville, etc. Tous ces éléments sont bien sûr corrélés les uns aux autres, ce qui ne rend pas les calculs triviaux ! Si je mets en avance rapide, il faut faire les même calculs, mais il faut les faire 3 fois plus vite ! Et, là, je peux te dire que mes ventilos tournent à fond. Ce jeu est écrit en C. Si le moteur de simulation avait été écrit en Python pur, ça aurait été vraiment compliqué, d’un point de vue des performances.

Tout ça pour te dire qu’un jeu de gestion, ça peut parfois demander pas mal de performances aussi, même si ce ne sont pas des performances graphiques (cela étant de toute façon bien géré par les moteurs de jeu Python qui bindent avec des couches OpenGL).

+1 -0

Intéressant tout ce que vous dites, pour répondre sinon aux différentes question, j’envisageais un jeu dédié à la gestion d’un cinéma, et je le voyais comme un jeu en 3D isométrique. Mon but est principalement d’apprendre un langage ; apprentissage qui passerait par la conception d’un jeu auquel j’aimerais jouer. Je souhaitais utiliser un langage populaire et facile en terme de prise de main, C++ c’est un peu l’usine à gaz qui ne m’attire pas des masses, et java ne me semble pas non plus le plus adéquat, restait Python.

Alors…

Si ta problématique c’est d’apprendre un langage, alors utilise celui que tu veux. Essaie d’en utiliser qui sont utilisés de préférence dans l’industrie du jeu-vidéo.

Si ta problématique c’est créer un jeu, pourquoi ne pas te tourner vers un moteur dédié à ça et ne pas te soucier du langage à utiliser ?

Ou pourquoi ne pas partir sur quelque chose de simplissime au début quitte à faire quelque chose en python, sans trop te soucier de la partie technique ?

Je parle en connaissance de cause. J’ai voulu écrire un moteur de MMORPG en 2D et je me suis cassé la gueule (même si le projet n’est pas mort pour autant, je suis passé à autre chose en attendant d’y revenir pour revoir mes ambitions à la baisse). Parce que j’ai mis la charue avant les bœufs, à savoir :

  • je voulais faire du C++ ;
  • je voulais apprendre à utiliser Boost ;
  • je voulais apprendre à utiliser SFML ;
  • etc.

Alors que ça aurait dû être :

  • je veux faire un jeu un peu à la façon de Zelda ;
  • je veux ajouter quelques mécaniques de sorts ;
  • je veux ajouter une interface pour consommer des objets ;
  • je veux apporter une dimension multijoueurs.

Tu vois l’idée ? ;)

Je crois sincèrement que développer un jeu de gestion de cinéma en 3D iso ne te sera pas de tout repos. Aussi, si ton objectif réel c’est d’apprendre un langage, je te dirais de te concentrer sur un projet moindre pour débuter (pourquoi pas un snake ou un bomberman ?). Tu connais le dicton : celui qui court deux lièvres à la fois ne prendra rien.

À toi de voir, et surtout, je te souhaite beaucoup de courage dans tes entreprises.

Alors que ça aurait dû être :

  • je veux faire un jeu un peu à la façon de Zelda ;
  • je veux ajouter quelques mécaniques de sorts ;
  • je veux ajouter une interface pour consommer des objets ;
  • je veux apporter une dimension multijoueurs.

Désolé pour le second HS, mais ça n’aurait pas fonctionné facilement dans ce sens non plus.

Pour un MMO, ton approche initiale de gérer le réseau dès le départ, et de créer un serveur dès le départ était de très loin la bonne approche. Par contre, tu as totalement raison pour le reste : ton autre priorité #1 au début du jeu est de soigner la base du gameplay (le CCC: Character Control Camera).

+1 -0

Pourtant, au fur et à mesure du développement, je me suis rendu compte que j’aurais dû commencer par le client du jeu alors que c’est la dernière pièce par laquelle j’ai commencé, et surtout je me suis aperçu ensuite que je pouvais très bien faire la partie client sans passer par la partie serveur.

De surcroit, sur la partie serveur, j’étais parti sur quelque chose d’inutilement complexe au début, et ça m’a plutôt pas mal pénalisé par la suite.

Même sans ça, à l’heure actuelle, il n’y a aucune ligne directrice précise au regard du gameplay. C’est bien ce qui m’a fait défaut et c’est pourquoi j’insiste sur l’importance d’avoir à la fois un projet modeste et une idée aussi précise que possible sur ce vers quoi on veut aller.

Tout le contraire de ce que j’ai fait. :)

La bonne façon de packager pour Windows, c’est de la packager the hard way, avec un installeur qui vérifie la présente ce Python, dans une version compatible, sur le système, et qui propose de l’installer le cas échéant.

Packager une application correctement pour Windows est tellement une plaie que le freeze semble quand même acceptable 

En même temps ce n’est pas comme si le problème n’était pas exactement le même avec Java, Ruby, et plein d’autres.

LE seul qui gagne à ce niveau là c’est C#, car c’est le seul qui a 99% de chances d’être déjà installé.

ET on fait quoi avec toutes les applications basées sur des technologies web qui utilisent Elektron ou NW.js ? C’est pareil: on se retrouve avec 36 copies de Chromium et tout le monde s’en fout.

Sorry pour le HS…

+2 -0

En fait je trouve ça pertinent. Mais la solution serait-elle alors de passer par C# ?

C’est une possibilité. Disons qu’avec C# tu as un avantage certain pour ensuite distribuer ton jeu sous windows. C# est très probablement le langage le plus utilisé actuellement pour faire des jeux si on exclut C++ (il est peut-être même devant en fait, j’ai pas de chiffres), et il y a unity, un framework complet et populaire.

Après, comme l’ont déjà dit les autres, si ton premier but est d’apprendre, choisis avant tout un langage qui te plais; le reste tu t’en fous. Tous ont des avantages et des inconvénients à divers stades, mais quelque soit ton choix, tu mettras un bon moment avant d’atteindre des limites qui le remettront sérieusement en question. Donc pour l’instant, fais-toi juste plaisir.

Peut-être que comme moi au final tu te rendras compte que ce qui te plais le plus, c’est pas de coder le jeu, mais le moteur !

Pourtant, au fur et à mesure du développement, je me suis rendu compte que j’aurais dû commencer par le client du jeu alors que c’est la dernière pièce par laquelle j’ai commencé, et surtout je me suis aperçu ensuite que je pouvais très bien faire la partie client sans passer par la partie serveur. De surcroit, sur la partie serveur, j’étais parti sur quelque chose d’inutilement complexe au début, et ça m’a plutôt pas mal pénalisé par la suite.

Si tu veux mon avis, le réseau est la partie de loin la plus compliquée à gérer dans un jeu.

Les latences et les déconnexions peuvent arriver à n’importe quel moment pour plein de raisons différentes volontaires ou non, c’est compliqué de tester tous les cas possibles, et quand on peut tester c’est ch#### à mourir de le faire.

Il faut pouvoir gérer tout ça: des rage quitters aux pannes de courant, en passant par les routeurs récalcitrants et les pirates en herbe. LE tout en faisant le maximum pour que la partie continue le plus longtemps possible.

S’il y a quelque chose à retenir en ce qui concerne le réseau, c’est la suivante par contre: tu as tout intérêt à rendre le client le plus idiot possible. C’est le serveur qui doit commander. Le client doit juste être là pour afficher ce que le serveur lui demande et lui renvoyer les entrées.

+1 -0

Rhaaa, c’est ma faute, j’ai lancé le HS. Mais je le trouve intéressant !

C’est une possibilité. Disons qu’avec C# tu as un avantage certain pour ensuite distribuer ton jeu sous windows. C# est très probablement le langage le plus utilisé actuellement pour faire des jeux si on exclut C++ (il est peut-être même devant en fait, j’ai pas de chiffres), et il y a unity, un framework complet et populaire.

Je crois que pour les gros jeux console et AAA, C++ est encore devant. En tout cas je sais que les jeux de Naughty Dog sont en C++, pour référence.

Si tu veux mon avis, le réseau est la partie de loin la plus compliquée à gérer dans un jeu.

Les latences et les déconnexions peuvent arriver à n’importe quel moment pour plein de raisons différentes volontaires ou non, c’est compliqué de tester tous les cas possibles, et quand on peut tester c’est ch#### à mourir de le faire.

C’est tellement vrai ! Quoique je trouve pas ça si chiant. Disons que c’est un vrai défi. Par contre le fait de transférer toute l’autorité au serveur permet de gérer une bonne partie de cette complexité : ça permet notamment de réduire très efficacement les possibilités de triche, et de réduire la plus grosse source de problèmes à essentiellement une question "qu’est-ce qui se passe quand la connexion tombe entre le client et le serveur ?".

Pour gérer le reste (les latences, notamment), il existe des solutions qui sont maintenant bien documentées (numéroter les ticks du serveur, interpoler/extrapoler pour garder une animation fluide sur le client, …).

+0 -0

A propos du modèle client-serveur, le fait d’avoir un client le plus léger possible permet aussi de simplifier la maintenance et les évolutions.
En effet, on peut introduire de nouvelles fonctionalités juste en modifiant le serveur.
A l’extrème, on utilise un navigateur comme client.

+0 -0

Perso, moi j’utiliserais python, car ceux qui ont linux ont souvent python installé, et ceux qui ont windows, il suffit de convertir le jeux python en executable windows grace à un programe free qu’on trouve sur le net, me souviens plus du nom, un truc dans le genre "python2exe" je crois. Qu’en pensez-vous ?

Lol, pour le jeu de simulation marrons glacés ;)

Au fait, je pense qu’il faut faire la différence entre un jeu de simulation et un jeu de gestion, le premier est plus complexe et consommateur de ressources que le second.

+0 -1
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte