Kriegsspiel (à vos souhaits :P )

[LDiCesare]

Belle vidéo. Ca colle vraiment bien au nom du jeu en plus. Je vais y mettre un pouce sur youtube des fois que ça t'aide à avoir des vues

[Max Pictave]

Je plante mon drapeau ! Un certain esprit "Cossack" dans ton gameplay, c'est très sympa ! Hâte de voir comment ton jeu évoluera avec le temps

[franzoar]

Merci pour tous les messages sympas !

A part un ptit bug (rien de grave, juuuuuuste une fuite mémoire (ouais en fait, c'est super grave, la honte )), je n'ai pas fait évoluer le gameplay ou le graphisme sur la version présente sur itch.io.
Par contre, suite à des échanges, j'ai décidé de faire une ptite vidéo sur "comment s'organisent les unités, quand le général est loin".

Elle est là, pour ceux que ça intéresse. (ah oui, j'ai arrêté de mettre des pavés de texte, et je parle à la place, je ne sais pas ce qui est le mieux, ou le pire, n'hésitez pas à me le dire)



L'IA est pas encore au top, mais elle fait assez bien le taf' dans la majorité des cas. Certes, il y a encore des bataillons feignasses glandent encore un peu, alors qu'ils pourraient aider leurs potes qui se font démolir à 200 mètres ... mais, c'est la friction ma bonne dame, que voulez-vous, on n'y peut rien ! Oui, cet argument est indigne : je vais peaufiner ça dans les prochaines versions.

[franzoar]

Salut tout le monde !

Bon, désolé pour le retard, mais j'ai dû changer de job depuis septembre, afin d'avoir un peu de sousous ET du temps pour continuer mon ptit projet (oui, le truc au nom imprononçable :D ).
Je me suis remis sur Kriegsspiel dès février, mais je me suis embourbé dans une spirale de "j'ajoute un truc, j'en enlève, ah, et si je mettais ça en plus ? Ah mais dans ce cas il faut aussi ça ....".
En conclusion, ma communication est pas top, ce qui n'est pas très cool envers les gens qui se sont intéressés au jeu. Donc, pardon, je vais essayer de m'améliorer et de sortir des versions plus souvent.

Ah, j'ai demandé aux modos de déplacer la discussion dans le coin des développeurs. Vu le temps que va me prendre le jeu, je ne pense pas qu'il sorte sur Steam ou ailleurs de sitôt : il n'avait pas vraiment sa place dans la section des 'vrais' jeux vidéo sur PC. Merci SetaSensei pour le déplacement !

Voili voilou, tout ça pour dire qu'une version 0.10 est sortie sur Windows et Mac : https://franzoar.itch.io/kriegsspiel-7-years-war . Bon, une personne m'a remonté un écran bleu, peut être dû à mon appli, et une autre a vu une mission impossible à terminer à cause d'un bug sur le moteur de batailles. Je n'ai pas eu ces soucis chez moi, mais, je vais reproduire et corriger ces problèmes : je ne vous conseille pas vraiment de télécharger cette version avant le prochain correctif.

Les changements majeurs :

- Je tâtonne encore sur la représentation du champ de bataille. Le but est d'aller vers un style plus réaliste.
- les comportements en attaque et en défense des régiments sont mieux, le but est de les rendre plus efficaces quand le général n'est pas là pour les surveiller. Il y a encore du boulot, mais j'ai enlevé pas mal de bugs qui les bloquaient.
- les unités sont affichées comme des jetons de loin, et comme des soldats de près.

- Idem pour certaines forêts sur la carte. Il faut que je continue le boulot avec tous les types de forêts (et que j'améliore les performances de l'affichage des arbres).
- A l'affichage, les bataillons (chaque jeton sur la carte représente un bataillon) sont divisés en pelotons. Ceci est purement graphique et les pelotons ne sont pas (et ne seront jamais) gérés de façon indépendantes par le moteur de jeu.
- La rotation des bataillons prend du temps.
- L'affichage du terrain a été refait pour des raisons d'optimisation (merci au logiciel Renderdoc pour m'avoir aidé). Si vous voulez tout savoir, l'ancien algorithme avait d'abord été pensé en optimisant. Oui, j'ai fait de l'optimisation prématurée, ce qui est la racine du mal dans le monde du développement. Oui, je passe mon temps à dire à mes collègues voire stagiaires de NE PAS faire ça . Et bien sûr, cette 'optimisation' était une catastrophe au niveau du temps d'affichage .
- Le brouillard de guerre apparaît comme un brouillard (oui bon, c'est des nuages, mais ça fait brouillard quand même ? ).


Voili voilou, prochaine version majeure dans deux mois (promis, je communiquerai avant), et il y aura de l'artillerie cette fois-ci !
Si vous avez des questions sur le jeu, ou sur le projet ou la technique, je serai ravi d'y répondre !

[Bopnc]

Merci pour les nouvelles, c'est cool que tu soit encore sur le sujet.

J'ai testé ta dernière version, mais je n'ai pas de brouillard de guerre comme sur ton screen. C'est normal ?

[franzoar]

De rien ! Merci d'avoir testé !
Le brouillard de guerre s'active/se désactive avec la touche V comme .... Vog of war (bon, ok, comme Vision ).
C'est clair qu'il manque une IHM avec des icônes et les raccourcis clavier (prochaine version, promis).
Bon, les touches sont indiquées dans le tutoriel, mais celui-ci est un peu long : il faut que je les affiche ailleurs.

[franzoar]

Hop, un ptit post plus technique/retour d'expérience (chais pas si ça vous intéresse, ou si vous n'en voulez pas, dîtes-le moi dans les deux cas !).

Attention : je n'ai pas de formation théorique et encore moins une expérience professionnelle en OpenGL/3D, ce qui suit ne représente que ce que j'ai compris des outils (RenderDoc, Blender, OpenGL) que j'utilise dans le cadre d'un projet personnel. Si vous trouvez mon mode opératoire pas top ... hé bien, vous avez sans doute raison , n'hésitez pas à me le dire que je corrige au besoin (pour éviter que d'autres ne fassent les mêmes erreurs que moi).

On va parler d'optimisation de l'affichage 3D ... ou plutôt d'une de mes optimisations d'affichage 3D. Primo, qui dit optimisation, dit outillage. En l'occurence, j'en ai deux, le compteur de vitesse de calcul d'une image (ou frame), en bas à gauche de l'écran :



J'utilise un ptit PC pas du tout taillé pour le jeu pour ces tests (mon jeu est moche, il devrait fonctionner sur une machine modeste). Or, ce PC met 100 ms à créer une image, ce qui fait une moyenne de 10 FPS, pas top. Il faut donc trouver ce qui prend du temps quand une image est dessinée.

C'est ce à quoi sert le deuxième outil : RenderDoc. Il permet d'analyser l'intégralité des opérations qui mènent à l'affichage d'une image, à partir d'un univers en 3D. Il se lance avec un client graphique, et permet de lancer lui-même l'application à monitorer, via une interface telle que celle ci-dessous :



Une touche permet de faire une "capture d'écran". Ceci permet à RenderDoc d'enregistrer les actions OpenGL nécessaires à l'affichage d'une image. Il est alors possible, dans RenderDoc, de lister toutes ces actions, et de connaître leur temps d'exécution. Sur l'image ci-dessous, on peut voir à gauche une liste de ces actions, et à droite le détail d'une action sélectionnée dans la liste. Ici, l'action numéro 182 est une des plus longues. Elle consiste à afficher les vestes des soldats. La partie de droite montre les points (vertices) et les triangles qui constituent cette veste (un mesh). Il s'avère que le mesh est détaillé, et pour mon utilisation, trop détaillé :



Du coup, direction Blender pour retoucher le mesh(que j'ai acheté sur cgtrader). Il est possible d'utiliser des méthodes de nettoyage (Clean Up) pour diminuer le nombre de vertices/triangles d'un mesh. Pour ce cas là, j'ai utilisé "Decimate Geometry", qui réduit le nombre de vertices (points) sans 'trop' modifier la forme du mesh (modèle) :



Après paramètrage et application de "Decimate Geometry", la forme est plus simple, contient moins de triangles (comptés à gauche de l'image). Néanmoins, certains triangles sont à retravailler, parce qu'ils ne sont pas esthétiques, ou sont maintenant 'sous' le mesh du pantalon. Certaines parties de la veste vont disparaître si l'on ne fait rien :



Au final, j'ai gagné quelques FPS (1 à 2, c'est un début). Je vais continuer à adapter mes meshes ou mon code avec ce processus.

D'autres méthodes de nettoyage de Blender peuvent être utilisées, j'avoue que je ne les maîtrise pas toutes, mais je fais des tests pour utiliser celles qui me donnent les meilleurs résultats sans que j'aie besoin de trop retoucher manuellement les modèles.

Voili voilou, j'avoue que c'est aussi pour ce genre de posts que je voulais venir dans le coin des développeurs. Encore une fois, toute cette procédure vient d'une démarche empirique et d'auto-formation, vous pouvez la critiquer sans problème.
Elle semble aussi un peu simple, voire simpliste. Mais, dans un précédent post, j'ai écrit que j'avais commencé à optimiser du code sans même tester les performances, ce qui est une très mauvaise pratique.
Ce post décrit exactement l'inverse : test des performances, localisation d'une opération lente ou consommatrice de ressources, tentative de modification du code ou des modèles au bon endroit. Puis re-test pour voir si les performances ont bien été améliorées.

[Grosnours]

Prochaine étape, changer dynamiquement le mesh en fonction de la vue caméra et du niveau de zoom. Une vue proche affiche le modèle le plus riche en triangles, la vue éloigné le modèle le plus simple avec une transition pas trop cheloue au milieu.
Le tout pour des centaines de modèles.
Bien sur cela n'a un impact que si et seulement si c'est le GPU qui représente un goulot d’étranglement. Si c'est le CPU tu auras bossé pour pas lourd.

L'optimisation c'est à la fois quelque chose que tu dois faire au début (parce que plein de bonnes pratiques vont conditionner les perfs) et à la fin parce que tester sur un grand parc de machines va faire apparaître des choses imprévues et t'indiquer quoi optimiser, où et comment.

[franzoar]

Prochaine étape, changer dynamiquement le mesh en fonction de la vue caméra et du niveau de zoom. Une vue proche affiche le modèle le plus riche en triangles, la vue éloigné le modèle le plus simple avec une transition pas trop cheloue au milieu.

Ahah, mais j'ai déjà l'algorithme qui fait ça ! Attends ... j'ai mal lu ... tu as écrit : "avec une transition pas trop cheloue au milieu" ? Ah bah, j'ai encore du boulot

Le tout pour des centaines de modèles.
Bien sur cela n'a un impact que si et seulement si c'est le GPU qui représente un goulot d’étranglement. Si c'est le CPU tu auras bossé pour pas lourd.

C'est juste, mais je compte avoir assez peu de modèles (une infanterie classique, une infanterie légère, une cavalerie de reconnaissance/escarmouche, une lourde, une artillerie de campagne et une de siège). Le but n'est pas seulement de réduire la complexité du développement, pour me faciliter la tâche. Ce que je veux surtout, c'est que le jeu récompense les joueurs qui ont une bonne stratégie, plutôt que ceux qui connaissent sur le bout des doigts toutes les unités. Pour le goulet d'étranglement, le temps de travail du CPU est pour l'instant marginal (je le logge aussi, et ce n'était pas précisé), mais cela pourrait changer avec plus d'unités simulées. Donc oui, c'est à surveiller ...

L'optimisation c'est à la fois quelque chose que tu dois faire au début (parce que plein de bonnes pratiques vont conditionner les perfs) et à la fin parce que tester sur un grand parc de machines va faire apparaître des choses imprévues et t'indiquer quoi optimiser, où et comment.

Pour l'optimisation au début, c'est compliqué pour moi, parce qu'au niveau des connaissances 3D, j'ai débuté avec ce jeu. Donc, niveau bonnes pratiques, c'est pas ça. C'est pour cela que je préfère coder simplement la partie graphique et utiliser des outils pour optimiser au fur et à mesure. Bref, pour cette partie, j'évite d'optimiser de manière prématurée. Pour l'optimisation à la fin et le grand parc de machines ... ouaip y aura des surprises (en fait, je pense que ça va être la galère. Bon, heureusement, je n'en suis pas encore là ).

Merci pour le retour, si tu as des questions/critiques, ou des retours d'expérience de dév' de ton côté, je suis preneur !

[Grosnours]

J'ai toujours été impressionné par les devs qui se faisaient leur propre moteur de jeu vu que la création d'un jeu est un domaine si vaste et si profond. Personnellement j'aurai plutôt conseillé l'utilisation d'un outil tout fait (UE, Unity, Godot, etc...) histoire de ne pas avoir à creuser trop, mais tu sembles te débrouiller parfaitement bien sans. Tant que tu trouves tous les outils additionnels qu'il te faut (en particulier pour l'optimisation avec un tracking complet de tout ce qui se passe), tout devrait continuer à rouler.

[franzoar]

Mais tu as teeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeellement raison sur l'utilisation d'UE, Unity et Godot. J'aurais dû les utiliser pour éviter de perdre du temps. Le problème, c'est que :
- je voulais découvrir la programmation 3D, et OpenGL.
- sortir un jeu vidéo et en vivre.

Or, ces deux buts sont un peu contradictoires. Du coup, bon, je ne pense pas que ce soit le truc à faire si l'on est dans mon cas.

Cimer pour ta réponse sympa en tous cas, et oui, avoir des bons outils, c'est vital. Si tu (ou d'autres lecteurs du forum) en connais d'autres qui sont bien, chuis preneur !

[schouffy]

Pour ça, ne regrette rien, même en utilisant Unity c'est très difficile de vivre de ses jeux vidéo

[Bopnc]

Je n'y connais rien en développement de jeux vidéos, mais d'un point de vue de wargamer j'ai été surpris de voir des graphismes 3D accolés à un jeu nommé "Kriegsspiel".

J'aurais pensé plus simple d'aller à fond dans le concept et de s'inspirer de l'esthétique historique de ces "jeux". C'est à dire de faire jouer des blocs sur une carte "d'époque", qui auraient le double mérite :
- D'être simple à représenter, puisqu'il s'agit de blocs sur une carte 2d, avec sans doute quelques animations simples du genre fumées, tirs, etc.
- De claquer sa race visuellement pour les amateurs.

Un truc qui rendrait dans ce genre là : https://www.commandpostgames.com/new...iel-scenarios/



Le fait de simuler les soldats individuels en 3d lors du zoom du joueur apporte indéniablement un challenge supplémentaire.

[Grosnours]

C'est marrant parce que j'ai vraiment du zoomer sur les photos et prendre du temps pour voir s'il s'agissait de photos d'un jeu de plateau ou de screenshots d'un jeu 3D vachement bien fait

La 2D cela peut-être relativement plus simple à implémenter que la 3D (mais elle comporte ses défis spécifique) mais elle a aussi une tonne d’inconvénients. Que tu peux circonvenir pour la plupart en ayant un jeu réalisé en 3D mais montré en 2D. Typiquement pour une adaptation informatique d'un jeu de type Kriegsspiel, j'aurais tendance à imaginer un jeu fait en 3D mais qui s'utilise principalement en 2D.

[schouffy]

ça donne trop envie de faire un jeu qui ressemble à ça
Une belle texture pour la map, un peu de depth of field, un bel éclairage et pouf fini

[franzoar]

Pour ça, ne regrette rien, même en utilisant Unity c'est très difficile de vivre de ses jeux vidéo

Bon, ben, me voilà rassuré !

Je n'y connais rien en développement de jeux vidéos, mais d'un point de vue de wargamer j'ai été surpris de voir des graphismes 3D accolés à un jeu nommé "Kriegsspiel".

J'aurais pensé plus simple d'aller à fond dans le concept et de s'inspirer de l'esthétique historique de ces "jeux". C'est à dire de faire jouer des blocs sur une carte "d'époque", qui auraient le double mérite :
- D'être simple à représenter, puisqu'il s'agit de blocs sur une carte 2d, avec sans doute quelques animations simples du genre fumées, tirs, etc.
- De claquer sa race visuellement pour les amateurs.

Un truc qui rendrait dans ce genre là : https://www.commandpostgames.com/new...iel-scenarios/



Le fait de simuler les soldats individuels en 3d lors du zoom du joueur apporte indéniablement un challenge supplémentaire.

Je ne peux pas contredire ton point de vue : j'ai même commencé mon jeu dans cette direction. J'avais commencé avec une carte qui ressemble à celle d'un état major, et des jetons cubiques qui s'inspiraient de ceux du Kriegsspiel. Ce qui m'a fait aller vers le style actuel c'était que :
- le rendu graphique était vraiment austère. Ce n'est pas dû au plateau et aux pions du Kriegsspiel (les images que tu es mises dans ton message sont classes), mais au fait que le terrain ne rendait pas top. Le terrain moche, c'est dû au fait que ma carte est découpée en carrés. Or, je ne suis pas parvenu à faire des jolis carrés qui permettent de rendre une carte du type de celles des Cassini ou d'état major. Pourtant, purée, oui, ça rendrait bien ! Je pense que c'est possible, mais ... on attend mes limites techniques (pour gérer des cartes qui ne sont pas découpées en carré) et artistiques (parce que l'art et moi ...) .
- je ne suis pas parvenu à créer un ensemble de jetons qui soient à la fois lisibles et ressemblant à des jetons en bois. Il faut peut être que je retravaille ce point, ce n'est pas si compliqué je pense, et ça fera plaisir au puriste. On peut imaginer un appui sur une touche qui passe des jetons avec figurine aux jetons du Kriegsspiel. Hop, je crée une Trello à ce propos !

La 2D cela peut-être relativement plus simple à implémenter que la 3D (mais elle comporte ses défis spécifique) mais elle a aussi une tonne d’inconvénients. Que tu peux circonvenir pour la plupart en ayant un jeu réalisé en 3D mais montré en 2D. Typiquement pour une adaptation informatique d'un jeu de type Kriegsspiel, j'aurais tendance à imaginer un jeu fait en 3D mais qui s'utilise principalement en 2D.

Yep. Après tout les jeux de stratégie en 3D , s'utilisent surtout en vue de haut (donc 2D). On zoome pour se faire plaisir parfois, mais ça n'apporte pas grand chose au gameplay. (c'est mon avis perso).

[Grosnours]

Justement si on prend l'exemple des pions, tout faire en 3D est 'achement plus facile et flexible.
En 2D, tu va devoir créer au moins 4 et sans doute 8 assets par pion (suivant leur orientation), le tout parfaitement réalisé (éclairage, ombrage) et avec zéro possibilité d'afficher autre chose.
En 3D tu t'appliques pour créer un seul et unique modèle que tu pourras représenter sous l'angle que tu entends, orienté n'importe comment, avec un seul et unique éclairage et type d'ombrage a définir,

[SalsifiNoir]

La 3D c'est la 2D du futur

[franzoar]

La version 0.11 est arrivée : elle intègre officiellement l'artillerie et de meilleures animations. Bon, ce qui m'a pris le plus de temps, c'est le travail sur le moteur d'animations, le moteur du jeu qui fonctionnait avec des "ticks" de durée variable (j'avais rajouté ça, c'était pas une bonne idée ), et l'utilisation du logiciel Tiled pour faire les cartes. Il y a un paquet d'autres "trucs" dans la version 0.11. Si vous avez deux minutes à perdre, j'ai fait une ptite vidéo (en français, cheubeudeubeudeuu la Fraaaaaance!).



Je continue à travailler sur les optimisations de mesh (notamment proposées par Grosnours (un ptit pouçou en passant au grosnounours, comme disent les influenceurs)), c'est pas encore ça, mais ça avance (dans le bon sens, chais pas, mais ça avance).

[Grosnours]

Merci.
N’hésites pas à demander si tu rencontres de difficultés, avec un peu de bol on pourra t'aider. Cela fait toujours plaisir de voir les progrès d'un jeu made in CPC.

[franzoar]

Héhé, de rien. Je demanderai un coup de main si je suis VRAIIIMENT bloqué. De ce que je vois de tes posts, du passes déjà assez de temps sur des logiciels de modélisation 3D ou proches de ce domaine pour ton boulot. Je vais essayer de ne pas abuser. Mais déjà les retours que vous m'avez fait sur ce fil, c'est super : ça me sort la tête du guidon.