Présentation
Battle for Moscow est un wargame qui se joue sur un plateau de taille 14×11 à cases hexagonales. Le jeu se veut une reconstitution très abordable de la bataille de Moscou (opération Typhoon) après l'opération Barbarossa.
Battle for Moscow est mon premier wargame, autant dire que je ne sais pas du tout y jouer. Ce qui est sûr c'est qu'il fait une certaine unanimité parmi la critique que ce soit ici ou là, là, là, là, là, là, là, là, ou là.
Première étape
Au départ Battle for Moscow est un print-&-play paru dans un game-magazine.
Fort heureusement il existe aujourd'hui aussi en version boîte.
Pour ma part j'ai choisi l'option print-&-play. Pour l'instant c'est encore loin d'être jouable comme vous pouvez le voir sur cette photographie :
Remarque : les 39 pions ont des gommettes sur les deux faces. C'est le même principe que le matelas été/hiver, les caractéristiques des unités sont différentes suivant la météo.
Deuxième étape
Avant même d'avoir terminé la création de mon plateau de jeu, j'ai déjà commencé d'entreprendre la conversion informatique. La première étape consiste à régler le problème des hexagones. Mon expérience de la programmation m'a appris que tout est plus facile quand tout est carré. Alors comme je ne cherche pas la difficulté pour la difficulté j'ai rapidement décidé que tout deviendrait carré.
Remarque : ça ne change que le graphisme. Ça ne change rien du tout au jeu car les colonnes de cases carrées seront décalées verticalement de façon à permettre jusqu'à 6 cases voisines.
Graphiquement le défi consiste à afficher le maximum d'informations sur la case (terrain, défense, coordonnées) et sur l'unité présente dessus (type, potentiel de combat, capacité de mouvement, taille, identification) en un minimum de place à l'écran. Jusqu'ici je m'en sors pas trop mal.
Un extrait du plateau de jeuCi-dessus, le 24ième Panzer Korp et le 23ième Fußvolk Korp ont franchi la Vyazma Defense Line et menacent la ville de Rzhev (1ière case 6ième colonne sur le plateau de jeu).
Encore deux petites vignettes :
Marque pour la position de départ
d'une unité allemande.
Marque pour la position de départ
d'une unité soviétique.
Voilà, il ne me manque plus que les rivières (qui circuleront entre les cases) et les lignes ferroviaires (ce que je redoute le plus).
Si vous avez des suggestions pour améliorer mes graphismes, surtout n'hésitez pas.
Je suppute que nombre d'entre vous peuvent mieux faire qu'un bête programmeur OCaml/C.
Si vous pensez que des cases hexagonales seraient plus esthétiques et/ou plus compactes alors prouvez-le par l'exemple.
Vu que tu as décalé tes colonnes, les cases carrées semblent tout à fait satisfaisantes.
Pour les graphismes, il te faut absolument un 'tain de truc en 3D tout laid qui fera ramer même le plus bourrin des ordis ! Nan ?
Pourquoi est-ce que les lignes ferroviaires sont un problème ?
Il n'y aura pas de 3D. Et ça ne fera rien ramer de tout parce que je compte bien y jouer sur mon eeePC 701.
Le problème avec les lignes ferroviaires c'est que je ne sais pas comment les dessiner.
D'ailleurs déjà avec les rivières je ne sais pas trop comment m'y prendre.
Je sais juste qu'elles vont faire des coudes à angle droit, mais je pense que ça valait quand même le coup de tout mettre au carré. Autrement on perd très vite beaucoup de place alors que l'écran de mon eeePC ne fait que 800×480
À propos des rivières j'ai du faire des recherches pour retrouver les noms illisibles sur la carte. Il s'agirait de Oka, Ugra, Upa, Moskva et Dniepr. Affaire classée.
Pourquoi ne pas dessiner les chemins de fer comme sur l'original ? vu que tu n'a pas d'impératif de pouvoir modifier la carte, les éléments de "décor" peuvent être totalement inamovibles.
Mes rivières sont moches. Tant pis. Je donne la priorité à l'avancement. Graphiquement il ne me reste plus que les voies ferroviaires.
Les principales cases à voie ferroviaire.
Certes il reste encore d'autres cases spéciales à dessiner mais je m'approche du bout du tunnel.
Le Bashar a écrit :
En fait je pourrais très bien poser mes unités directement sur la carte originale. C'est une question de goût : autant imprimée elle rend plutôt bien (quoique pas toujours très lisible), autant à l'écran je la trouve fatigante à l’œil.
Les tuiles de terrain
Le programme de rendu
Astucieux et expéditif, comme j'aime
(* ocamlopt.opt -o B4M -w s -I +lablgtk2 lablgtk.cmxa B4M.ml *) let window = GMain.init (); let wnd = GWindow.window ~title:"Battle for Moscow (demo)" () in wnd#connect#destroy GMain.quit; wnd let area = GMisc.drawing_area ~width:870 ~height:684 ~packing:window#add () let drawing = new GDraw.drawable (area#misc#realize (); area#misc#window) let pixrow ysrc = drawing#put_pixmap ~ysrc ~xsrc:0, drawing#put_pixmap ~ysrc ~xsrc:60, drawing#put_pixmap ~ysrc ~xsrc:120, drawing#put_pixmap ~ysrc ~xsrc:180, drawing#put_pixmap ~ysrc ~xsrc:240, drawing#put_pixmap ~ysrc ~xsrc:300 let plain,forest,defense,city,city_defense,moscow = pixrow 0 let plain1,plain2,plain3,forest1,forest2,forest3 = pixrow 60 let plain4,plain5,forest4,forest5,forest6,forest7 = pixrow 120 let plain6,plain7,plain8,plain9,defense1,defense2 = pixrow 180 let defense3,defense4,defense5,defense6,defense7,defense8 = pixrow 240 let tiles = [| plain;plain2;plain;plain;plain2;plain;plain;plain;forest;plain4;plain; forest3;forest;forest;city;plain7;plain;forest;forest;forest3;forest; forest;plain2;plain;plain;plain2;plain8;city;forest;forest;plain2;forest; forest3;plain;plain;plain4;forest;plain;plain5;forest;forest4;plain; defense;defense2;defense;defense5;defense;defense;defense;plain8;city;forest1;forest1; city;plain1;city;forest;plain;plain;plain;plain4;plain5;plain; forest;forest5;forest;forest2;plain;plain;plain9;forest6;plain;plain2;plain; defense;defense2;city_defense;defense;city_defense;forest6;plain;plain;city;plain; forest5;forest3;plain3;plain9;forest6;forest;plain;plain;plain4;plain;plain; defense3;defense8;defense6;defense;plain;plain;plain;plain4;plain;plain; plain;defense4;moscow;defense1;defense1;defense1;city_defense;plain6;plain;plain;plain; forest7;plain3;defense7;plain7;plain;plain;plain;plain;plain;plain; plain4;plain2;forest2;plain2;plain5;plain;plain;plain;plain;plain;plain; plain3;plain3;plain3;forest;city;plain7;plain;plain;plain;plain |] let pixmap,_ = GdkPixbuf.create_pixmap (GdkPixbuf.from_file "tiles.png") let exposed _ = let width = 60 and height = 60 in let x = ref 2 and t = ref 0 in for i = 1 to 7 do let y = ref 2 in for i = 1 to 11 do tiles.(!t) ~x:!x ~y:!y ~width ~height pixmap; y := !y + 62; incr t; done; x := !x + 62; y := 34; for i = 1 to 10 do tiles.(!t) ~x:!x ~y:!y ~width ~height pixmap; y := !y + 62; incr t; done; x := !x + 62; done; false let main = assert (Array.length tiles = (11+10) * 7); area#event#connect#expose ~callback:exposed; window#show (); GMain.main ()Je ne suis pas très satisfait du résultat qui fleure bon le jeu 16 bit alors que je visais plutôt un style état-major militaire.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Ceux qui sauront dénicher le téton discret qui se cache dans cette copie d'écran rébarbative recevront le nom et le photoset complet de ce délicieux modèle féminin qui prend sa douche.
Je trouve déjà ça chouette comme rendu ! La génération est complètement aléatoire, chemin de fer et villes comprises ?
En 63 lignes ça serait assez fort
Le contenu de la carte correspond au tableau
De plus il y manque les coordonnées des cases, les noms des villes, les rivières, et le marquage des zones de départ.
let tiles =...(de la ligne 26 à la ligne 39), c'est une 'quadrature' de la carte du jeu qui à l'origine est à base d'hexagones. Il faut bien admettre que la transformation la rend méconnaissableComme je ne suis pas satisfait je repars sur une autre base qui consiste à prendre la carte d'origine et à la manipuler pour la rendre :
• plus lisible à l'écran
• redimensionnée afin que chaque unité soit bien placée au centre d'une case
Tout comme me l'avait suggéré Le Bashar.
On dirait qu'il manque les rivières sur ta carte non ? c'est pas ça qui la rend méconnaissable ?
Sinon je ne sais pas trop ce que tu entend par "carte d'état major" mais si c'est un truc réaliste, ce n'est pas ce qu'il te faut pour un jeu comme ça. La carte IGN avec tout plein d'infos c'est pas très lisible.
Voilà, après un petit détour par Windows (pour retoucher l'image à l'aide du logiciel IrFanView), retour sur Linux pour faire le programme simplissime que j'aurais du faire il y a de ça 3 semaines.
"carte d'état major" pour moi ça renvoie à ces films de WWII où l'on voit les généraux de la Wermacht affairés autour d'une table géante et qui déplacent des unités miniatures à l'aide d'un râteau en bois. C'est surtout de l'imaginaire en fait, parce qu'on ne voit jamais clairement la carte.
À force de fouiner j'ai fini par trouver un freeware en vis-à-vis (sans IA) pour Windows 95.
Le débit est très faible mais comme le fichier n'est pas volumineux...
Par contre vous êtes prévenus, c'est un authentique jeu Windows 95 qui va pourrir votre répertoire Windows/System avec des tas de dll et autres composants Active X obsolètes et inutiles (sans parler des failles de sécurité qui vont avec). Pour éviter ça je l'ai installé sous Windows 98se. Je n'ai pas testé pour vous toutes les autres alternatives (QEMU, WINE, ...). Démerdez-vous ou passez votre chemin.
Je vais prudemment passer mon chemin
Dommage, aujourd'hui on est bien moins emmerdé avec un jeu dos pur qu'avec un jeu Win95/98 ...
Sinon utiliser la conf Virtual PC de GamesLover : http://www.gameslover.ch/index.php?option=com_content&view=article&id=125&Itemid=88
[EDIT] C'est un gag ?
@Human Ktulu : désolé pour ta configuration Virtual PC, comme j'ai encore un Windows98se tu penses bien que je ne vais pas m'aventurer à tester des machines virtuelles.
Maintenant j'ai assez de recul pour affirmer que je ne mènerai pas ce projet à son terme. Comme on apprend aussi de ses échecs je vais vous en expliquer les raisons.
Raison n°1 Je n'ai trouvé qu'une petite poignée de publications scientifiques sur le sujet. J'ai même trouvé un graphique qui montre clairement que le wargame ne suscite aucun intérêt universitaire (voir article ISMOR). L' explication de base c'est que l'armée américaine ne croit pas à l'utilité des wargames en situation réelle de combat. D'où un manque de financement car les USA sont le premier pourvoyeur mondial de la recherche et le ministère US de la défense en est de loin le premier contributeur direct ou indirect. Quant à la défense européenne, et bien vous savez tous qu'elle n'existe pas.
Raison n°2 Celle là est plus subjective. Les quelques rares publications (voir un autre article ISMOR) existantes renvoient au recuit simulé (simulated annealing) ou même aux algorithmes génétiques.
Or ça ne me convient pas du tout.
Pourquoi ? Pourquoi est-ce que je refuse de programmer du recuit simulé ou (pire) un algorithme génétique ? Parce que ce sont des modèles stochastiques.
Mes préventions:
En clair il est très fortement probable que ça ne marchera pas du premier coup et ce sera un véritable chemin de croix pour parvenir à une certaine performance pour laquelle aucun minimum n'est garanti.
Alors oui, peut être qu'un jour quelqu'un publiera du wargame en logiciel libre qui sera basé sur un recuit simulé, un algorithme génétique, un réseau bayésien ou que sais-je encore, mais ça ne sera pas moi.
Edit: Le réseau hiérarchique de tâches (Hierarchical Task Network) est une autre option qui a le mérite d'être fondée algorithmiquement. Malheureusement cela consiste essentiellement à scripter lourdement l'IA. Du coup à chaque faille découverte il faut colmater avec une rustine (qui peut éventuellement apporter d'autres failles inattendues, à l'instar du blindage des postes de pilotage de l'aviation civile).
Autre obstacle concret: Pour écrire une bonne IA il faut obligatoirement être un bon joueur ce qui suppose de jouer de nombreuses parties contre des adversaires aguerris et assez pédagogues.
En résumé: je suis convaincu, comme me l'avait prédit Le Bashar, que les wargames sont des jeux pour des humains contre des humains et qu'une IA ne peut y faire que piètre figure.
Précision: Quand je dis "aucun fondement algorithmique" c'est un peu comparable à l'affirmation de Sbirematqui selon laquelle 0.99999... = 1. La démonstration qu'il me fait est correcte. L'affirmation est donc vraie. Mais comme la démonstration est de l'analyse cela en fait une vérité analytique. Ça ne deviendra une vérité algébrique que lorsqu'on trouvera une démonstration par l'algèbre.
Pour aller plus loin: Neats versus scruffies.
Croyez-en un programmeur qui a perdu beaucoup de temps privilégiez toujours le neat contre le scruffy.
Je viens de reprendre ce projet abandonné il y a 1 ans, dont je n'avais réalisé que le peu de graphisme. Parce que c'est plutôt fun, moins d'algo et plus de programmation système (en GTK 2.24).
Dès que j'aurai compris le Drag 'n' Drop en GTK2 je devrais pouvoir présenter quelque chose de sympathique. Notamment en direction de Kyradax, afin qu'il puisse :
@Kyradax : je vois que Fedora est GNOME + KDE. Pour choisir un Toolkit c'est très simple : GNOME est basé sur GTK tandis que KDE est basé sur Qt5. Et pas la peine de te fier aux apparences en choisissant le plus tape-à-l'œil, ils sont thémables, l'apparence n'a aucune importance car elle est customisable.
Autre astuce : si le nom commence par un G alors c'est probablement en GTK (comme Gnumeric ou gFTP ou Geany) tandis que si le nom commence par un K alors c'est probablement en Qt (comme Konqueror ou KDevelop ou Kompare ou Kommander ou KolourPaint).