Mon jeu de grande stratégie sans nom pour le moment

[Tomaka17]

Dans la série des "jeux sans nom pour le moment", voici le "jeu de grande stratégie sans nom pour le moment".
Comme son nom l'indique, il s'agit d'un jeu de grande stratégie. En d'autres termes, un Civilization-like, Europa-Universalis-like, Total-War-like.
Vous choisissez une date de départ parmi celles proposées (pour l'instant uniquement 1815, mais idéalement six dates de -301 à 1947) et jouez en temps réel l'une des nations existantes à ce moment-là de l'histoire.

Le jeu se joue en temps réel (comme dans un jeu Paradox) et non au tour par tour.
Actuellement la vitesse de croisière maximale est de 7,5 jours par seconde, soit 49 secondes par an, ou encore 110 ans toutes les heures-et-demi.
Mais on peut évidemment ralentir le jeu et mettre en pause à tout moment.

Je ne vais pas détailler le gameplay pour l'instant, parce que c'est long à écrire et que ce n'est pas figé. Quelques caractéristiques principales :

- La carte du jeu n'est pas découpée en provinces. Tous les éléments, comme les armées, les routes ou les bâtiments, peuvent se placer à n'importe quel endroit et ont une zone d'effet. À noter qu'en réalité ce n'est pas tout à fait vrai. Il y a quand même un système de cases, mais le but est que celles-ci ne soient pas visibles.

- Le jeu simule en continu la production, l'acheminement et la consommation des ressources.
Par exemple s'il manque des ressources quelque part, votre population peut se révolter. S'il manque des armes à l'endroit où se situe un armée, celle-ci combattra moins bien.

- L'aspect militaire ne nécessitera pas beaucoup de micro-management.
Globalement si vous gagnez une guerre c'est parce que vous êtes bien préparés et non pas parce que vous avez mieux manoeuvré que l'ennemi.

J'ai volontairement choisi des aspects de gameplay compliqués techniquement.
C'est un domaine que je maîtrise bien, et je pense que ça va beaucoup me démarquer des autres jeux du genre.

Vu qu'il y a des screenshot plus bas, je préfère vous prévenir tout de suite : toutes les images sont expérimentales. Les graphismes sont pour l'instant pas la priorité.
J'ai commencé à mettre en place tout le système de rendu, entre autres pour voir si c'était fluide ou non, mais il y a des tonnes et des tonnes d'adjustements à faire avant ça ne devienne joli.

Voilà donc un petit screenshot de l'écran de sélection du pays :



Voilà pour illustration la production de nourriture en Europe, encore très "pixélisé" pour le moment :



(ainsi qu'une petite vidéo pour prouver que c'est du temps réel)

L'écran de diplomatie :



Le processus de colonisation :



Une invasion de l'Espagne (oui il y a des tanks en 1815) :

[Grhyll]

Waw c'est ambitieux ! Mais déjà pas mal avancé Bon courage !

[Da-Soth]

En effet, créer un Grand Stratégie en indépendant c'est ambitieux mais au moins ça a le mérite d'être original.

Je ne peux que te souhaiter le meilleur pour ton projet.

Et tu as raison de te concentrer sur le moteur. Dans ce genre de jeu, le reste est accessoire.

[Tomaka17]

C'est ambitieux, mais cette fois-ci j'ai bien prévu le projet.
J'ai une idée précise à 90% de la façon dont je vais coder ou designer chaque aspect du jeu et du gameplay (j'ai écrit un doc de ~600 lignes pour le gameplay), ce qui est très important pour ne pas pédaler dans la semoule.

En revanche ce qui m'embête le plus c'est le design de l'UI. Je suis absolument nul dans ce domaine. J'ai beau essayer, tout ce que je créé est moche.
C'est assez embêtant, car par exemple tout le système de recrutement de soldats est pour l'instant bloqué par le fait qu'il faut que je design l'UI de recrutement.

Idéalement il faudrait que je trouve quelqu'un qui fasse tout ça à ma place, mais je ne sais pas trop comment m'y prendre. Je n'ai pas envie de dépenser des sous là dedans pour payer un pro, mais d'un autre côté je trouve ça malhonnête de payer les gens en promesses.

[Grhyll]

Après c'est pas non plus urgentissime de régler ça, j'imagine ? Tu peux rester avec ton UI placeholder toute moche le temps de développer le jeu, et le jour où tu as quelque chose de jouable, qui plaît aux gens (y aura bien des hardcores qui testeront tout ça même avec une UI pourrie), tu pourras voir si ça vaut le coup de payer quelqu'un pour avoir une belle UI pro.
Après, payer les gens en promesse, ça me paraît pas forcément malhonnête, si on part du principe que tu fais toi-même ce projet en bénévole, c'est à l'artiste de voir s'il a le temps/la motivation de s'investir dans un projet sans retour assuré. Ceci dit, dans ce cas, c'est mieux pour toi d'avoir un produit le plus fini possible déjà avant de passer par là, histoire de ne pas faire faire plein de trucs à un artiste pour un jeu qui ne serait finalement pas fini.

[Poussin Joyeux]

Beau projet que je vais suivre attentivement!

[Nattefrost]

Nice, curieux de voir la suite !
Et j'imagine que c'est écrit en... Rust ?

[Tomaka17]

Et j'imagine que c'est écrit en... Rust ?

Tout à fait. 100 % pure Rust.

Et ça marche puisque j'en suis toujours à 0 plantage pour l'instant.

[tompalmer]

C'est moche mais interessant, comme tout projet amateur qui se respecte

[Tomaka17]

Ah mais je compte le rendre joli ! C'est juste pas la priorité.
Mais j'ai déjà fait quelques essais.

Avec un terrain réaliste :



Un peu trop de spéculaire :



Avec des arbres, mais là le GPU ramait sévère :



Une shadowmap :

[Tchey]

Chouette ! Moi aussi j'en veux un à moi, mais pour le moment je suis juste bon à suivre un tuto pour faire un pong !

Curieux de voir l'évolution de ton projet.

[elfangor]

Super !

je vais suivre ce projet avec intêret !
Est-ce que tu as quelques informations techniques à fournir ? Par exemple les librairies utilisées (Piston ?) Ou même par exemple avoir ton cargo.toml

Hâte de voir la suite en tout cas.

[Darkath]

C'est ambitieux, mais cette fois-ci j'ai bien prévu le projet.
J'ai une idée précise à 90% de la façon dont je vais coder ou designer chaque aspect du jeu et du gameplay (j'ai écrit un doc de ~600 lignes pour le gameplay), ce qui est très important pour ne pas pédaler dans la semoule.

En revanche ce qui m'embête le plus c'est le design de l'UI. Je suis absolument nul dans ce domaine. J'ai beau essayer, tout ce que je créé est moche.
C'est assez embêtant, car par exemple tout le système de recrutement de soldats est pour l'instant bloqué par le fait qu'il faut que je design l'UI de recrutement.

Idéalement il faudrait que je trouve quelqu'un qui fasse tout ça à ma place, mais je ne sais pas trop comment m'y prendre. Je n'ai pas envie de dépenser des sous là dedans pour payer un pro, mais d'un autre côté je trouve ça malhonnête de payer les gens en promesses.

C'est quoi le moteur du jeu ? Les outils d'unity sont par exemple relativement simple a utiliser faire une UI pas trop dégueu.

Mais apres malheureusement l'UI, ca prend beaucoup de temps (donc d'argent si c'est pas toi qui la fait) pour un jeu de stratégie.

[Tomaka17]

Mon Cargo.toml :

[dependencies]
bmfont = { git = "https://github.com/tomaka/bmfont-rust", branch = "parse-heights" }
cgmath = "0.7.0"
chrono = "0.2.16"
glium = "0.13.3"
hprof = "0.1.3"
image = "0.4.0"
immi = "0.1.1"
lazy_static = "0.1.15"
noise = "0.1.5"
rand = "0.3.0"
rodio = "0.3.0"
rustc-serialize = "0.3.0"
time = "0.1"
toml = "0.1.23"
wavefront_obj = "2.0"

[build-dependencies]
pocket-resources = "0.3.2"

- - - Mise à jour - - -

C'est quoi le moteur du jeu ? Les outils d'unity sont par exemple relativement simple a utiliser faire une UI pas trop dégueu.

Ben tout est fait main !
Ça peut paraître fou mais au final c'est pas beaucoup plus long qu'avec un vrai moteur quand on sait ce qu'on fait.

Et mon problème c'est pas tellement de coder l'UI, pour ça j'ai une petit lib qui fait de l'immediate mode très simple à utiliser.
Mon problème c'est vraiment de dessiner et de placer les éléments.

[BourrinDesBois]

Salut, chouette (et ambitieux!) projet, bon courage à toi!

[Tomaka17]

Quelques améliorations esthétiques :

[tompalmer]

J'enlèverais le bump mapping si j'étais toi, c'est beaucoup plus simple d'embellir du plat, c'est plus lisible, etc ..

[Tomaka17]

Au contraire je pense que c'est plus joli avec du relief.
C'est vrai que pour certaines infos le plat est peut être plus lisible. Mais d'un autre côté l'action va globalement se dérouler sur les terrains non-montagneux de toute façon.
Par contre quand on fait des manœuvres militaires, je pense qu'au contraire il est utile de voir où est le terrain accidenté.

Mais ça ce sont des choses assez faciles à changer, donc je verrai en temps voulu. Il est facile de faire apparaître ou disparaitre le relief en fonction du mode de carte par exemple.

[Tchey]

Pour le moment le bump mapping est hideux (je préfère le plat), et je ne pense pas que tu devrais communiquer sur l'aspect graphique à ce stade du développement.

[tompalmer]

Pas la peine non plus de briser ce pauvre Tomaka sur un prototype

Courage !

Par contre le seul jeu qui a tenté le globe en 3D pour s'échapper de Mercator est Superpower. Et j'avoue que c'est un peu chiant a manipuler par rapport a un planisphère.

[Tomaka17]

L'objectif niveau graphismes c'est d'arriver à quelque chose comme les Total War :



C'est à dire qu'on aurait un terrain réaliste, et les informations se mettraient en overlay par dessus.

[tompalmer]

Dans ce cas passe en planisphère.

[Tomaka17]

Ah bah non !

[tompalmer]

Remember : https://www.phonealchemist.com/es/en...2-superpower-2

[Tomaka17]

Je l'ai installé tout à l'heure suite à ta remarque (je l'avais dans ma bibliothèque steam pour une raison inconnue), et le fait que le globe soit en 3D c'est vraiment le cadet des problèmes de maniabilité de ce jeu.

[Roscopolo]

Ça vaut le coup de tester et c'est pas la mort à changer si ça foire. Le but n'est pas de faire un clone de truc ou muche. Et puis 80 days a très bien réussi avec un planisphère, même s'ils ont adopté un plus haut niveau de zoom.


Par contre mon enthousiasme est refroidi par le scepticisme lié à l'utilisation d'un moteur perso. Parce que même si tu avais vingt ans d'expérience dans la création de moteur, tu devrais quand même investir des milliers d'heures pour un simple moteur de base, et gérer des milliers de problèmes chiants liés à des bogues sur de vagues cartes graphiques inconnues et la version japonaise 9.12 d'OSX. Des trucs emmerdants à mourir pour un dév et qui ne seront jamais résolus, pourriront la vie des utilisateurs et sont la garantie d'avoir à gérer une communauté hostile, des mails d'Al Qaida et, pire, des youtubers furieux. Et vu que le relationnel occupe déjà 26h par jour dans la vie d'un indé...

Non seulement un moteur est un gouffre temporel mais il y a pire : le moindre changement prend des heures, des jours ou des semaines alors qu'il faut pouvoir itérer rapidement pour tester et jeter ! C'est un très gros problème. Tout ça pour un résultat inférieur à celui qui serait obtenu en deux jours avec Unity et fonctionnerait partout et même sur le web (trois à six mois pour terminer l'ensemble de la partie graphique - peaufinée, testée, déboguée, optimisée).

Pour moi en 2016 soit on développe un moteur, soit on développe un jeu, mais pas les deux en même temps. Je présume donc que tu voulais développer un moteur. Après tout chacun a commencé ainsi.

[Tomaka17]

Techniquement je ne peux pas ne pas utiliser de moteur perso. Unity n'est juste pas capable de faire ce que je veux faire.

La gestion de l'économie du jeu et des ressources consomme plusieurs centaines de mégaoctets qui doivent être organisés en mémoire de façon à être cache-friendly et avec des caches pour accélérer certains accès. Une partie des données est calculée par le GPU, avec une organisation du code faite pour éviter les problèmes de synchronization.

Si je fais ça de façon naïve (avec une bête boucle for qui traverse toutes les cases) mes essais ont montré qu'il fallait plus de 120 millisecondes par frame rien que pour gérer les ressources (soit 0.5 frames par seconde). Ce qui n'est pas étonnant car on parle d'environ 50 millions de calculs à virgule flottante par frame. Et c'est vraisemblablement les perfs que j'aurais eu avec Unity. Ces 120 millisecondes se sont transformées en 4 millisecondes après un peu de tambouille interne.

En ce qui concerne les problèmes de compatibilité, je suis au courant et je compte les résoudre en switchant vers Vulkan. J'ai commencé à developper avec OpenGL en sachant que j'allais vraisemblablement switch vers Vulkan. Et oui je connais tout le blabla sur "vulkan c'est pas pour les débutants". Je suis au courant aussi.
Ce que je n'avais pas anticipé par contre c'est que Vulkan serait retardé de deux mois, et du coup il y a quelques parties du code sur lesquelles je n'ai pas trop envie de travailler car je sais que je vais les changer.

[war-p]

Ça vaut le coup de tester et c'est pas la mort à changer si ça foire. Le but n'est pas de faire un clone de truc ou muche. Et puis 80 days a très bien réussi avec un planisphère, même s'ils ont adopté un plus haut niveau de zoom.


Par contre mon enthousiasme est refroidi par le scepticisme lié à l'utilisation d'un moteur perso. Parce que même si tu avais vingt ans d'expérience dans la création de moteur, tu devrais quand même investir des milliers d'heures pour un simple moteur de base, et gérer des milliers de problèmes chiants liés à des bogues sur de vagues cartes graphiques inconnues et la version japonaise 9.12 d'OSX. Des trucs emmerdants à mourir pour un dév et qui ne seront jamais résolus, pourriront la vie des utilisateurs et sont la garantie d'avoir à gérer une communauté hostile, des mails d'Al Qaida et, pire, des youtubers furieux. Et vu que le relationnel occupe déjà 26h par jour dans la vie d'un indé...

Non seulement un moteur est un gouffre temporel mais il y a pire : le moindre changement prend des heures, des jours ou des semaines alors qu'il faut pouvoir itérer rapidement pour tester et jeter ! C'est un très gros problème. Tout ça pour un résultat inférieur à celui qui serait obtenu en deux jours avec Unity et fonctionnerait partout et même sur le web (trois à six mois pour terminer l'ensemble de la partie graphique - peaufinée, testée, déboguée, optimisée).

Pour moi en 2016 soit on développe un moteur, soit on développe un jeu, mais pas les deux en même temps. Je présume donc que tu voulais développer un moteur. Après tout chacun a commencé ainsi.

Tu sais, ce n'est pas sale de faire son moteur perso, au moins tu peux le concevoir uniquement pour ce qu'il est censé faire. Ce qui est très difficile avec des moteur propriétaire quand t'essaie de les tordre pour faire ce que tu veux qu'ils fassent.

[Louck]

Tu sais, ce n'est pas sale de faire son moteur perso, au moins tu peux le concevoir uniquement pour ce qu'il est censé faire. Ce qui est très difficile avec des moteur propriétaire quand t'essaie de les tordre pour faire ce que tu veux qu'ils fassent.

En attendant il n'a pas tort: soit tu fais un moteur, soit tu fais un jeu. Pas les deux. Chacun est un gouffre de temps.

Sinon, il existe des moteurs propriétaires assez performant qui t'offre une certaine liberté technique. C'est au développeur de faire un peu de recherche et d'étude pour savoir si le moteur est bon pour son projet ou non .

[tompalmer]

Ce qui est vrai c'est qu'il n'existe pas de moteur sous license ou open source, de framework, de modèle, pour des jeux de ce type (de la gestion a la stratégie).

Y'a deux trois trucs de merde mais c'est tout, alors que si tu veux développer un FPS, t'as UE4, Unity, etc ...