Concevoir un programme de A à Z - Page 2

Jyaif (./29) :
Un conseil qui m'aurait été utile quand je suis passé de la TI au PC et qui pourrait peut être t'être utile, c'est de t'en foutre totalement des performances. Mais vraiment quoi. Moi, même en savant que faire des optimisations prématurément c'était mal, j'avais un pincement au coeur quand je faisais un truc pas optimisé. Peut être que toi aussi inconsciemment ça te bloque et t'empêche de prendre de la hauteur.

Ah ! Content de te l'entendre dire \o/
Je me suis pris la tête à faire des routines d'affichage pour ne surtout pas afficher un pixel en trop pour gagner en frames... Jusqu'à ce que je me dise qu'en affichant une image de fond + 3 sprites je risquais pas de faire ramer ma 8400 GS

Donc j'ai repris. Oui, j'ai jamais supporté d'écrire 100 octets d'assembleur qui s'écrivent en 80 avec 30 cycles en moins. En embarqué pas musclé et pour des tous petits projets, c'est peut-être un plus. Sur PC, ça me coulera sûrement si je continue comme ça.

Jyaif (./29) :
C'est peut être ça la source du "problème", tu es trop perfectionniste?

On va dire ça, et sans pour autant atteindre le début du commencement de la perfection j'ai bien peur.

Souane (./30) :
sauf que j'aime bien coder ce qu'il est possible de coder et ensuite aviser, histoire de repousser ces questions à plus tard

Pareil \o/

Sauf que j'en ai marre de me prendre le mur à la sortie du tunnel

Souane (./30) :
Typiquement, j'aime bien commencer par définir puis coder les classes du "Modèle" (ie. les classes qui s'occupent des données au coeur du programme et non de l'interface graphique ou des trucs compliqués)

Pareil \o/ J'ai d'ailleurs déjà commencé, sans avoir écrit une ligne de spec... ça craint à mort et je le sais, mais si je ne fais pas ça, je ne fais rien.

Bon okay, on programme pareil alors

Je rejoins Jyaif, dans ce que tu nous exposes tu manques clairement de hauteur.
Personnellement j’ai compris depuis le début que tu avais besoin d’afficher des sprites sur un plan, mais je n’ai toujours pas compris ce que fait l’application au fond. Un jeu ? Quel jeu ? Avec des ennemis ? Qui sont capables de faire quoi ? Qui ont quelles caractéristiques ?

Sasume (./34) :
Personnellement j’ai compris depuis le début que tu avais besoin d’afficher des sprites sur un plan, mais je n’ai toujours pas compris ce que fait l’application au fond. Un jeu ? Quel jeu ? Avec des ennemis ? Qui sont capables de faire quoi ? Qui ont quelles caractéristiques ?

Cool

- un jeu
- de stratégie au tour par tour (plateau hexagonal, style Wesnoth)
- ...
ensuite, on avance dans quelle direction ?!?

- quelles vont être les règles du jeu ?
- y'aura-t-il une IA, ou est-ce multijoueur ?
- quelle type de représentation graphique ? (isométrique j'imagine, mais c'est pas la seule solution)

Réfléchi en terme d'objets. Apparemment il y a un plateau. Donc tu peux faire une classe Plateau qui contiendra toutes les informations qui le caractérise.

Qu'est ce qu'il y a d'autre comme objets?

J'essaye de continuer :
- le plateau est scrollable (carte plus grande que l'écran)
- il affiche donc des unités (amies et ennemies) affichant également quelques infos (a bougé/n'a pas bougé, a tiré/n'a pas tiré, etc)
- il affiche des boutons permettant d'interagir (propriétés de l'unité sélectionnée, fin de tour)
- il affiche également les caractéristiques générales du terrain sous la souris (montagne, rivière) et le cas échéant, de l'unité qui s'y trouve*

(double cross)

ok, je poste un screen représentatif et j'essaye de vous répondre

Je pense que c'est prématuré de réfléchir aux classes, il faudrait que son projet soit mieux défini avant

http://g-images.amazon.com/images/G/01/amapedia/95/63/01/A3XTLL1FJH6WC_1168281016395.jpg

Les règles du jeu sont définies : il y a différentes cases munies de drapeaux sur une map, et il faut contrôler ces drapeaux (être le dernier à être passé dessus) avant la fin du nombre de tour imparti
- Oui, il y a une IA, bien que ce soit jouable à deux (mais techniquement c'est vraiment la merde, on ne doit pas voir les unités de l'autre, chaud sur un seul écran). Mais on va dire que oui, IA ou joueur humain en face
- représentation graphique... 2D (les unités sont dessinées en 2D dans les 6 positions possibles par exemple (nord, sud, nord-ouest, sud-ouest, nord-est, sud-est). Pas de 3D réelle donc.

=> faut que je réponde aux questions de Jyaif (je veux bien donner mes idées, mais mettez-vous d'accord


PS -> ce qu'on fait là... je fais juste une description, en quoi est-ce important ? Je le connais ce jeu, je veux juste le cloner. Je veux dire que c'est sûrement important, mais que je n'en vois pas l'intérêt dans l'immédiat

Folco (./40) :
Je veux dire que c'est sûrement important, mais que je n'en vois pas l'intérêt dans l'immédiat

Pour pouvoir le découper en blocs fonctionnels pour le coder. Et tu as beau le connaître, une fois que tu mets tout au clair par écrit, tu t'aperçois souvent de petits détails que tu avais oubliés, mais qui peuvent avoir une influence importante sur la structure.

En fait je ne me rendais pas compte à quel point tu avais une idée précise de ton jeu, mais apparemment c’est plutôt clair.
Là, comme dit 0², l’idée et de bien délimiter les responsabilités de chaque entité du jeu : par exemple, les personnages, que peuvent-ils faire ? Porter des armes ? Lancer des sorts ? Se raser ? Faire du shopping ? De quelles informations sur eux tu auras besoin pour modéliser tout ça ? Leur niveau de force ou d’habileté ? Leur taille ou leur corpulence ? Leur nombre de cheveux ?

Et en premier lieu, inutile de se demander si tu utiliseras un buffer à taille fixe ou si tu alloueras quelque chose sur le tas pour gérer tel ou tel truc, on n’en est pas encore à ce niveau de détail

Moi (et n’hésitez pas à critiquer si ça vous semble maladroit), je commence par décrire toute la partie « métier » de l’application : quelles seront les données modélisées (en gros ça découle des réponses aux questions que je viens de poser un peu plus haut). Il faut se poser la question de façon un peu abstraite, être capable de prendre du recul. Par exemple, si un personnage peut utiliser un bazooka ou un M16 je note plus simplement qu’il peut utiliser une arme, enfin un objet quelconque capable de tirer).
Et comme ça tu peux hiérarchiser chaque entité de ton application en fonction de ses responsabilités et de ses fonctionnalités.
À l’issue de cette étape tu obtiens un ensemble d’entités (appelons-les « objets », allez), parfois reliés entre eux par des relations (utilisation, spécialisation, etc.) et dont tu auras identifié les responsabilités : une Arme peut tirer() et être rechargée(). Tout de suite se dessinent les classes et leurs opérations.
Ces objets constituent seulement la partie métier de ton application : les données utilisées pour représenter le monde de ton application et leurs fonctionnalités.

Ensuite tu peux te poser la question de l’interface utilisateur : où je vais placer tel bouton qui servira à activer telle action ? Comment vais-je représenter telle entité ? Quels seront les événements à surveiller ? Les clics ? Le clavier ?

Ok. Alors sachant que je pars sur un clone, je n'ai pas à définir ça, puisque c'est l'original qui s'en charge (et je le connais vraiment très bien).

Quelle est donc l'étape suivante alors ?

(tiens, je me rends compte d'un truc, je vais utiliser SDL, il faut donc bien que je tienne compte des spécifications (ou contraintes) de cette lib. A partir de quel moment ça rentre en ligne de compte dans ma conception ça ?)

(j’ai édité mon message précédant au fait)

Tu peux très bien considérer de façon abstraite la façon dont tu géreras l’aspect graphique de ton jeu, sans penser dans un premier temps à SDL, en imaginant une interface de programmation (API) quelconque. Puis tu peux implémenter cette interface de programmation en faisant appel à SDL. Ça correspond au design pattern Adapter.

Ok, vu Adapter. Pas mal en effet, ça permet de s'abstraire complètement de la manière de faire (genre on peut changer de lib graphique on ne remet pas tout en cause).

Alors allons-y. C'est peut-être pas bien, mais j'ai envie de commencer non par le moteur de jeu à proprement parler (la bataille quoi), mais par l'interface (écran de démarrage où l'on choisit ce qu'on fait : charger une partie, en démarrer une nouvelle, quitter etc...).
Il y a plusieurs écrans de ce style à concevoir, qui n'utilisent que des icones et quelques listes scrollables dans une zone donnée. Je pensais implémnter ça, parce que j'ai pour habitude de commencer par les choses simples dans mes programmes. Peut-être est-ce un tort. Le seul point commun que je vois entre l'interface de jeu et l'interface d'accueil/choix de ce qu'on fait sont les icones.

Une page de l'interface "hors-jeu" ressemble à ça : Fichier joint : (screen14.png)

J'ai donc à designer pour le moment :
- un curseur qui se ballade sur la totalité de l'écran
- des icones qu'on peut cliquer et qui réagissent au passage de la souris
- des emplacements de listes déroulantes avec deux flèches pour faire défiler le contenu de la liste
- un fond d'écran (une image fixe)

commençons par le curseur :
Si je choisis de tout redessiner à chaque frame (je descend pas trop bas en disant ça ?), j'ai juste besoin de récupérer les coordonnées du curseur() et de l'afficher()
Je vois donc une classe avec :
- les coordonnées de la souris, accessibles par les autres classes pour les effets de survol par exemple (tiens, un accesseur à écrire)
- une méthode d'affichage
- le sprite de la souris

Ensuite pour les icones, il faut :
- les afficher()
- les modifier au survol()
- les modifier en cas de clic()
- leur faire lancer un nouveau module en quittant l'actuel() une fois le clic releasé
- elles doivent connaitre leurs coordonnées à l'écran (qui est de taille fixe)
- elles doivent connaitre leurs dimensions
- elle doivent connaitre l'adresse de leur sprite

Qu'est-ce qui va (pas) ? Je descend trop bas ? J'aborde pas bien les choses du tout ? Je suis déjà trop dans l'implémentation ?

je débarque en plein milieu de la discussion, et je ne sais pas si ce point a été abordé, mais je préfère quoi qu'il arrive en parler :

il faut toujours essayer de prévoir les évolutions / améliorations / ajouts possibles au projet, et concevoir l'application en conséquence, afin de ne pas s'engager dans une voie qui serait certes plus simple au départ, mais qui pourrait devenir une impasse. Il vaut mieux parfois coder de manière légèrement plus généralise, ou prévoir l'ajout de certains paramètres afin de ne pas se retrouver le bec dans l'eau.

ceci m'a souvent éviter de sérieux problèmes lors d'évolutions de mes projets.

Ok. Personnellement, je crois que je fais ça, mais tellement que je me retrouve avec une usine à gaz capable d'écrire au laser à la surface de la lune pour afficher un simple message en console. Mais je note que sur le fond, c'est une bonne habitude, merci bien.

Folco (./45) :
J'ai donc à designer pour le moment :
- un curseur qui se ballade sur la totalité de l'écran
- des icones qu'on peut cliquer et qui réagissent au passage de la souris
- des emplacements de listes déroulantes avec deux flèches pour faire défiler le contenu de la liste- un fond d'écran (une image fixe)

Ok

commençons par le curseur :Si je choisis de tout redessiner à chaque frame (je descend pas trop bas en disant ça ?), j'ai juste besoin de récupérer les coordonnées du curseur() et de l'afficher()

C’est quoi exactement la fonction curseur() ?
Pour ce qui est de la méthode d’affichage (redessiner tout ou pas), je n’en ai aucune idée, je n’ai jamais fait ce genre de choses sur PC. Mais j’imagine que c’est ce qu’il y a de plus simple, et vu la puissance des bêtes actuelles çe ne posera pas de problème de perf.

Je vois donc une classe avec :
- les coordonnées de la souris, accessibles par les autres classes pour les effets de survol par exemple (tiens, un accesseur à écrire)
- une méthode d'affichage- le sprite de la souris

Ok

Ensuite pour les icones, il faut :
- les afficher()
- les modifier au survol()
- les modifier en cas de clic()
- leur faire lancer un nouveau module en quittant l'actuel() une fois le clic releasé
- elles doivent connaitre leurs coordonnées à l'écran (qui est de taille fixe)
- elles doivent connaitre leurs dimensions- elle doivent connaitre l'adresse de leur sprite

C’est quoi la fonction actuel() ?
J’ai oublié de le dire mais je pense que dans l’ordre il faut d’abord penser à ce que permettra de faire l’objet (quelles sont ses opérations publiques) et ensuite seulement se poser la question des attributs internes privés (là les coordonnées, dimensions, etc.), qui peuvent de toute façon évoluer sans problème au fur et à mesure du développement.

Qu'est-ce qui va (pas) ? Je descend trop bas ? J'aborde pas bien les choses du tout ? Je suis déjà trop dans l'implémentation ?

Ça me semble un bon début

Sasume (./48) :
C’est quoi exactement la fonction curseur() ?

récupérer les coordonnées du curseur()
un simple SDL_MouseGetState() sûrement (ça y est je suis trop bas, je vais m'écraser )

Sasume (./48) :
Pour ce qui est de la méthode d’affichage (redessiner tout ou pas), je n’en ai aucune idée, je n’ai jamais fait ce genre de choses sur PC. Mais j’imagine que c’est ce qu’il y a de plus simple, et vu la puissance des bêtes actuelles çe ne posera pas de problème de perf.

Ca devient chiant de devoir enregistrer différentes zones chaque fois qu'un curseur passe ou un sprite se modifie pour le réafficher après, donc je préfère refaire plan après plan. Quand je vois que ça passe sur TI, je me dis que j'aurais tort de me priver de la facilité de ce côté.

Sasume (./48) :
C’est quoi la fonction actuel() ?

C'est là que je commence à coincer en général...
Si je clique sur l'icone "choisir une partie", je vais passer de l'écran "introduction" à l'écran "choisir".
Pour ça, je change carrément de module dans mon code : une autre boule infinie dans un autre fichier (niveau mémoire, tout ce qui est de "introduction" est déchargé, et je repars pratiquement à 0, sauf éventuellement quelques trucs communs comme le curseur).
Donc il faut qu'au clic, l'icone dise au module courant qu'il doit se fermer proprement en libérant tout ce qui va bien.
Je comptais utiliser une variable locale au module, passée en paramètre à chaque icone, et contenant le contenu du module à charger. Si c'est toujours MODULE_COURANT après la gestion du clic par l'icone, c'est qu'on reste là et on continue
Si ça a la valeur MODULE_MACHIN, c'est qu'il faut libérer proprement ce qui est propre au module actuel pour revenir au "gestionnaire de tâches" par un return MODULE_MACHIN (et le gestionnaire de tache lance un autre module par exemple, voire quitte).

Tiens, rien que tenter de l'expliquer, ça me fait déjà voir plus clair (même si ça l'est pas pour vous xD)

Sasume (./48) :
J’ai oublié de le dire mais je pense que dans l’ordre il faut d’abord penser à ce que permettra de faire l’objet (quelles sont ses opérations publiques) et ensuite seulement se poser la question des attributs internes privés (là les coordonnées, dimensions, etc.), qui peuvent de toute façon évoluer sans problème au fur et à mesure du développement.

Ok !

Sasume (./48) :
Ça me semble un bon début

Yep \o/

Au fait, merci de me prendre par la main. Je fais l'exposé le plus complet de mes graves faiblesses et lacunes en info, mais j'en ai marre de finir à peu près 0 projet sur 42

Folco (./49) :
C'est là que je commence à coincer en général...
Si je clique sur l'icone "choisir une partie", je vais passer de l'écran "introduction" à l'écran "choisir". Pour ça, je change carrément de module dans mon code : une autre boule infinie dans un autre fichier (niveau mémoire, tout ce qui est de "introduction" est déchargé, et je repars pratiquement à 0, sauf éventuellement quelques trucs communs comme le curseur).

J'imagine que si j'étais bon, je n'aurais qu'un boucle infinie faisant tout, et chaque module serait un objet. J'ai du mal à en être là, mais peut-être est-ce qu'il faut atteindre niveau hauteur ?

Je pense savoir pourquoi j'ai du mal à concevoir ça :
- une icone, je la vois sans mal en tant qu'objet : c'est un petit carré à l'écran avec des images, des coordonnées, et des actions à faire dans différents cas
- un module, c'est purement abstrait. Et là je coince...

Ca voudrait dire qu'en fait, un module est une instance unique d'une classe capable de répondre à tous les évènements produits par l'utilisateur, et à afficher un rendu à l'écran en fonction de ce qui se passe. Faut continuer dans cette voie ?

Un objet peut tout à fait être abstrait, hein

Un objet, c'est simplement une instance d'une classe. Et une classe, c'est la définition d'une "catégorie" de trucs abstraits et concrets qui partagent beaucoup de caractéristiques communes.

NB : je ne réponds pas par rapport à ton exemple précis hein (je capte pas tout le vocabulaire, donc j'aurais du mal à dire...)

Model-View-Controller, ça te dit quelque chose, sinon ? (c'est encore un pattern, et il est très très très utilisé).

(cross)

Je continue, n'hésitez pas à arrêtez les dégats s'il le faut

- un module est un objet
- il récupère des inputs (souris, clavier)
- il affiche un rendu à l'écran

Chaque module a donc :

- getEvents(), qui lit et traite les évènements comme lui seul sait le faire
- makePlane(), qui prépare une frame (objet avec ses dimensions, l'adresse de l'image créée, sa position sur l'écran (ça fait peut-être pas tout l'écran))
- dispPlane(), qui affiche la frame préparée, après, par exemple, un évènement de synchro


getEvents() renvoie une valeur (MODULE_TRUC, MODULE_MACHIN)
la boucle du programme principale appellera le destructeur du module si la valeur de retour est différente de la valeur du module courant, puis appellera le nouveau module le cas échéant.

makePlane() s'occupe de construire une frame en fonction des objets graphiques présents dans l'objet module (chaque objet sait s'il doit s'afficher, où et comment)

dispPlane() est très simple, ça consiste à recopier sur l'écran physique la frame préparée auparavant


Chaque module est donc une dérivation d'une classe module de base (???)

Souane (./51) :
Model-View-Controller, ça te dit quelque chose, sinon ? (c'est encore un pattern, et il est très très très utilisé).

Oui, j'en ai lu les concepts il y a quelques mois. Sans jamais avoir fait de POO, je n'en ai absolument pas compris tous les tenants et aboutissants.

Folco (./52) :
- un module est un objet
- il récupère des inputs (souris, clavier) - il affiche un rendu à l'écran

pour ma part, j'aurais fait :
- un objet pour gérer les entrées (souris, clavier, autre)
- un objet pour gérer les sorties (l'écran)
- un objet pour gérer tout ce qui est base de donnée si tu en as
- des objet pour gérer tes module, qui communiquent avec les 3 précédents objets

Moi je ne comprends toujours pas comment ça s'implémente exactement, et je me limite à mettre le modèle d'un côté et "view-controller" de l'autre côté dans les mêmes classes, chaque classe correspondant à une fenêtre avec un contenu différent associée à une méthode qui détecte gère tous les éléments (clics, etc.) Avec des gros programmes c'est recommandé de séparer view et controller mais j'ai jamais eu le temps de me pencher sur la question

J'avais réussi à monter d'un niveau dans l'abstraction, là tu m'en demandes deux, c'est un peu trop pour moi, faut que je réfléchisse avant de griffonner ce qeu ça va pouvoir donner, mais je vais essayer

Folco (./49) :

Sasume (./48) :
C’est quoi exactement la fonction curseur() ?

récupérer les coordonnées du curseur()

Ok, ce n’est pas vraiment une opération, c’est juste un getMachin.

./50 Exactement !

Quels sont les différents « modules » possibles ?

Souane (./55) :
Moi je ne comprends toujours pas comment ça s'implémente exactement, et je me limite à mettre le modèle d'un côté et "view-controller" de l'autre côté dans les mêmes classes, chaque classe correspondant à une fenêtre avec un contenu différent associée à une méthode qui détecte gère tous les éléments (clics, etc.) Avec des gros programmes c'est recommandé de séparer view et controller mais j'ai jamais eu le temps de me pencher sur la question

C’est parfois impossible de faire autrement. Genre en Web tu as vraiment la vue d’un côté (la page Web), le modèle de l’autre (la partie métier), et entre les deux des contrôleurs qui s’occupent de traiter l’action demandée par l’utilisateurs (la requête HTTP, qui contient des paramètres comme des champs de formulaires) en faisant appel au modèle puis affichent une nouvelle vue (page Web) en fonction du résultat.

Mais en prog non Web, par exemple avec Qt, c’est vrai que le code du contrôleur est souvent dans la vue (les widgets).

pareil en swing.

j'avais réalisé ça aussi, avec un programme desktop c'est hyper chiant si tu dois séparer les controleurs, alors qu'en web ça se fait automatiquement et on peut pas imaginer un autre truc

Sasume (./57) :
Quels sont les différents « modules » possibles ?

Je dirais qu'en fait, une "page" du programme constitue un module :
- la première page, "introduction", où l'on choisit de faire un scénario, une campagne, charger une partie, voir les crédits ou que sais-je encore
- la page des highscores est un module
- la page "ouverture de partie en cours" constitue un module

mais ce sont des modules très simples, c'est pour ça que je voulais commencer par là :
- fond d'écran
- icones
- listes
- quelques sprites

Le module évidemment le plus complexe est celui du champ de bataille :
- un objet map composé de :
-> sprite du terrain
-> données (météo, date, etc...)
-> des objets cases
--> un type de terrain
--> un indice de retranchement
--> autres
--> des chaines de caractères de descriptif/coordonnées associées aux cases
- deux objets "armée"
- objets icones, sprites du hud etc...
etc...


Il me semble donc nécessaire de définir
- une classe de base comportant l'ensemble des données commune (adresse de l'écran physique et autres données, routines de base de l'affichage d'un plan sur cet écran)
- une classe dérivée pour les écrans "statiques" (highscores etc...) parce qu'ils se ressemblent globalement niveau affichage et fonctionalités
-- chaque module "statique" dérive donc de cette classe dérivée
- une classe dérivée de la classe de base pour la bataille (classe unique et très spécialisée par rapport à la classe mère)

Ca va ?