Propositions pour le gameplay

Ok pour moi aussi. Je serais peut-être en retard d'une dizaine de minutes par contre. On se retrouve au bâtiment 6 ? (l'amphi risque encore d'être plein si on y va directement...)

ok rdv à 12h au bât 6

parfait

Trois autres trucs :

A)

- Les ponts vont nous emmerder, dans la mesure où il y a plusieurs trucs à gérer :
+ le fait qu'il faille plusieurs images en fonction de l'orientation du pont. Soit on règle ça dans le programme (c'est moche, vu que cela supprimerait tous les avantages des fichiers de données), soit en créant plusieurs types de pont (mais c'est vraiment du bricolage aussi...). En tous cas, le fait de gérer ça proprement demanderait pas mal de boulot supplémentaire, dont on peut se passer volontiers vu le travail à faire sur l'IA
+ il faut rendre impossible les déplacements du pont vers d'autres cases lorsqu'on est au milieu. Ça fait donc des règles spécifiques au pont, ce qui là aussi complexifierait aussi la conception du schmilblick (faire un truc gore n'étant pas le top non plus...)


B)

- Il y a une faille dans le système de combat tel que je l'ai proposé. Admettons que l'on soit dans un cas de ce genre, où l'équipe de droite est normalement en position de force face à l'équipe de gauche, et où la carte forme un "couloir" de 3 cases de haut :

	200*Archer	300*Fantassin	1*Fantassin	3000*CavLourde
Cdt	200*Archer	300*Fantassin	1*Fantassin	3000*CavLourde
	200*Archer	300*Fantassin	1*Fantassin	3000*CavLourde

Ce qu'il se passera :
- les cavaliers routes attaquent et tue un fantassin de chaque.
- les fantassins bleus se séparent : les groupes de 1 fantassin sont reformés
- les archers bleus attaquent
et ainsi de suite.

Il est totalement impossible pour les rouge de gagner alors qu'ils sont largement plus forts. Ils se feront juste massacrer à petit feu tant qu'ils n'auront pas abandonné... Bof.

Quelques solutions :

1 - Faire ce que Seb avait il me semble dit je ne sais plus quand : ne pas faire passer l'attaque nécessairement après les déplacements. Une première version pourrait donc être :
- soit un groupe pouvant se déplacer de 5 cases. S'il se déplace de 2 puis attaque, il pourra encore se déplacer de 3 cases.

Le problème est résolu, mais c'est pas top pour le réalisme : égorger 100 archers et courir 10km prend normalement plus de temps que simplement courir 10km... On pourrait arranger ça de cette manière :
- remplacer les points de déplacement par des points d'action.
- ne pas changer les règles pour les déplacements
- dire qu'un combat coûte aussi des points d'action.

Mais en faisant ça, on se retrouve à ne pouvoir attaquer que si on ne s'est presque pas déplacé, ce qui n'est pas forcément super non plus (se déplacer pour attaquer reviendrait à offrir l'initiative à son adversaire, donc ça encouragerait l'immobilisme).

2 - Ajouter la règle : Lors de la division d'un groupe, il est il interdit que la case du groupe de départ ou celle du groupe d'arrivée soit collée à groupe ennemi. De cette manière, dans l'exemple que j'ai donné les bleus ne pourront pas interrompre l'avancée des cavaliers. Par contre, le problème n'est résolu qu'à moitié : il suffirait que le joueur bleu ait une rangée de fantassins seuls en plus pour qu'il se présente à nouveau...

3 - Ne permettre que des divisions prédéfinies. Exemple : ne pouvoir diviser un groupe qu'en deux parties égales. Là le problème est totalement résolu (le joueur bleu serait obligé de perdre à chaque tour un nombre considérable d'unités), mais par contre, on perd quelques possibilités de gameplay.



Je préfère de loin la troisième solution pour plusieurs raisons :
- créer une interface avec zone de texte avec SDL ou SFML, c'est super chiant. Si l'utilisateur ne peut pas choisir de quelle manière il divise ses groupes, on évite ce problème. L'interface n'en devient que plus agréable d'ailleurs (la souris suffit).
- pour une fois, ça fait moins de code que prévu, au lieu d'en ajouter
- je ne vois plus vraiment en quoi le fait de pouvoir diviser ses groupes comme on veut enrichirait vraiment le gameplay, puisque les possibilités offertes permettent avant tout de tirer parti des faiblesses du jeu (tous les petits trucs pas top, mais inévitables, du fait que l'on ait un plateau de jeu au lieu d'un espace continu)

Voilà... S'il y a des choses ou des problèmes auxquels je n'ai pas pensé, faites signe...

C)

Comme je le disais au point précédent, faire des interfaces avec SFML, c'est chiant (ça le serait autant avec SDL hein), et en plus, ça n'apporte vraiment rien au projet. Si on fait une interface un minimum compliquée nous permettant de régler la résolution, etc, ça va nous faire perdre beaucoup de temps pour rien. Il y a une chose qui me tenterait nettement plus :
- Ne pas faire du tout de menus avec SFML. Le programme lance directement le fichier de scénario balancé en argument.
- Créer une mini-appli C++/Qt ou Java/Swing par exemple, permettant de choisir un fichier de scénario, et de lancer le programme principal en appuyant juste sur un bouton. Ca c'est juste pour qu'on ne se fasse pas chier à entrer les arguments à la main à chaque fois
- pour le reste de la configuration, un fichier de configuration tout con :

fichier config.ini :
###############
resX=1024
resY=768
fullscreen=false

profondeurIA=2
###############

Alors oui, il y a de la configuration graphique mélangée à celle des algos, ce qui est un peu moche. Je suis plutôt d'avis que l'on s'en fout dans ce cas, vu que ce n'est qu'un détail sans incidence sur 99.9% du code, et que de toute manière on n'aura pas beaucoup de paramètres... Mais bon, on peut séparer aussi...



ps : je n'étais même pas parti pour faire un pavé en plus...

A => osef c'est pas primordial, on peut mettre une bande de terrain la ou on avait mis un pont ca va pas nous tuer.

B => j'hésite entre la première et troisième solution... parcque justement faire plusieurs groupes de 1 paysan peut être une stratégie pour ralentir l'ennemi pour gagner ne serrais ce qu'un tour pour les archets, ou permettre a des renfort de venir défendre le capitaine. Puis si on règle les points d'action correctement on devrait pouvoir se déplacer et attaquer sans trop de problème. De plus ca permettrais dans le cas d'une mêlée d'éclater plusieurs groupes dans le même tour de jeu. Par exemple dans ton exemple je vois pas pourquoi ca prendrais 3 jours aux cavalerie lourdes d'éclater 3 groupes de 1 fantassin. une seule devrait pouvoir s'en occuper en un tour de jeu.
Et la solution 3 m'intéresse pour le coté feignasse de la chose =D


C => heu on peut pas faire ca dans le même programme avec une fenêtre QT pour le menu qui lance le moteur de jeu et sa fenêtre SFML quand on commence une partie ? nan parcque ne pas avoir de "retour au menu principal" et devoir quitter/relancer le jeu a chaque fois risque d'être un poil lourd ^^'

On peut mettre du SFML dans un Widget Qt, mais ça m'a l'air un poil chiant, et graphiquement ça serait bizarre. Euh par contre si on garde la fenêtre de menu ouverte quelque part, relancer le jeu ne prendra pas plus d'une seconde (+ le temps de choisir le scénario, que l'on aurait aussi avec un menu intégré). Pour faire une interface intégrée à la fenêtre, il y a des trucs bien mieux genre CEGUI. Mais la seule chose que je connais de cette librairie, c'est son nom... On en revient donc aux prises de tête dont on pourrait se passer...

Autres trucs pour aller dans le sens d'un "vive la troisième solution" :
- si on peut "se déplacer et attaquer sans trop de problème" comme tu dis, ça veut dire que le coût d'une attaque est presque nul.
- en mettant en place des points d'action, soit on fait une interface à laquelle un non-initié (le prof par ex) ne comprendrait rien (avec des questions du genre "mais pourquoi j'ai pas le droit d'attaquer ce tour-ci, ça marchait pourtant à celui d'avant ?"), à moins d'afficher les coûts des actions. Mais dans ce cas, on ne pourrait pas se permettre d'afficher des flottants, donc il faudrait augmenter les points d'action de manière à ce ça ne soit plus nécessaire (multiplier par 4 dans le cas présent). Mais en faisant ça, on se retrouverait avec des déplacement ayant au minimum un coût de 4... Il faudrait aussi montrer à l'utilisateur quel est le coût précis de chaque action, mais comme il faudrait faire en sorte qu'une attaque ne coûte pas toujours la même chose (affronter 1 soldat et 10000, c'est pas la même chose), donc l'utilisateur ne saurait jamais vraiment s'il peut faire quelque chose ou pas. C'est sûrement gérable, mais à quel prix ? (en termes de temps de prise de tête puis de développement)
- Multiplier le nombre d'attaques possibles en un tour, c'est multiplier le nombre de choix que doit traiter le min-max (et il risque déjà d'être bien trop élevé si on galère sur le pré-traitement des données).
- J'ai oublié le temps d'écrire le reste !

Je suis aussi largement pour la 3e solution. Ne serait-ce que parce que je ne vois aucun intérêt à diviser un groupe en 2 groupes non égaux.
Ca m'appelle aussi une autre question : met-on une limite au nombre d'unités que peut représenter un groupe d'un certain type ? 100 000 cavaliers sur une seule case, ça ne me paraît pas souhaitable Dans ce cas, que fait-on dans le cas d'une fusion de groupes qui dépasse la limite autorisée ? Le surplus est-il perdu ? (Ce n'est pas si moche, il y a des jeux où ça se fait, et ça oblige le joueur à faire ses fusions avec un peu d'intelligence.)

Pour le menu principal, le must serait de le faire de façon graphique en SFML. Mais si les interfaces de ce genre doivent devenir une prise de tête, un bricolage en Qt qui choisit le scénario et charge la fenêtre de jeu est suffisant... pour un TER. Si on faisait un vrai jeu, ça me paraîtrait quand même une solution dégueu, il faut bien le dire ^^

Pour les déplacements/attaques, ce que je préfère : un déplacement et une attaque pour chaque groupe d'unités, dans l'ordre que préfère le joueur. Je ne peux pas vraiment le justifier, c'est juste que j'aime bien ce concept. On pourrait aussi faire intervenir des points d'action, mais ça risque d'être un poil complexe à expliquer et à faire gérer par l'IA (et ça me fait plus penser à du JdR qu'à du jeu de stratégie).

On peut sans problème se passer de limites dans la taille des groupes, vu que le jeu ne permettra pas de créer des unités : si on ne veut pas de groupe > 1000 par exemple, il suffira qu'on ne mette pas plus de 1000 unités d'un type donné dans nos fichiers de scénario.

Tout à fait d'accord pour l'interface. Le prof a quand même été plutôt clair quant au fait que l'objectif principal est l'IA, et de toute manière, on serait totalement incapables de faire un (bon) jeu complet en 3 mois

Les déplacements comme tu le dis, je ne sais pas trop... Je vois un cas où ça pourrait être sympa :
- un groupe est pris en sandwich par plusieurs autres
- il voit que l'un des groupes est très faible (donc le blocage est plutôt foireux)
- il le dégomme, ce qui crée une ouverture.
- il s'en sert pour fuir les autres groupes, ce qui serait impossible en mettant les attaques forcément en fin de tour.

Par contre, je n'aime pas trop le fait que ça "spaghettise" un peu le gameplay... (tous les déplacements puis toutes les attaques, c'est quand même bien plus simple)

Et puis ca ferait chier pour les attaques en groupes. Toutes les attaques en même temps permet de régler ce problème très simplement.