/* Topic des codeurs couche-tard [1] */

tshirtman · Le 19/07/2010, à 20:17

grim7reaper a écrit :

Donc au final je ne suis pas sûr d'aller beaucoup plus vite que toi (mais le plus important ce n'est pas de sortir le truc le plus vite, c'est de sortir le truc le plus complet possible ). Faut prendre son temps, développez à La Rache donne rarement de bon résultat (ça peut fonctionner, mais au moindre changement ça risque de péter).

En fait, si, sortir quelque chose, rapidement c'est important, mais ce n'est pas de la rache, c'est de l'agile, bien définir les features les plus importantes, que dis-je, les plus indispensables, et les coder, avoir un truc qui marche, même si ça ne fait pas tout ce qu'on veux, juste un ensemble qui ait un sens et soit fonctionnel.

Pour le moment je me concentre sur l'interface car ça sert à rien de commencer le jeu si je ne peux pas faire de tests. Et des tests sans rien pour faire le rendu c'est pas top, d'où l'intérêt de commencer par l'interface (bon je fait pas l'interface définitive tout de suite, juste un truc basique qui me permettra de tester le jeu).

En fait les tests les plus importants ne sont pas les tests graphiques, tu peux tout à fait être certain que ton moteur est tout à fait fonctionnel sans avoir jamais lancé de partie, si chaque élément est testé face à tous les cas de bords et généraux, et que tous les tests passent…

Et donc oui, tu peut faire des tests avant d'avoir une interface qui tourne… c'est aussi de l'agile.

(bon, je n'a absolument pas appliqué cette deuxième partie de l'agile, pourtant indispensable, pour mon jeu, mais promis, je m'en mors souvent les doigts)

grim7reaper · Le 19/07/2010, à 20:44

tshirtman a écrit :

En fait, si, sortir quelque chose, rapidement c'est important, mais ce n'est pas de la rache, c'est de l'agile, bien définir les features les plus importantes, que dis-je, les plus indispensables, et les coder, avoir un truc qui marche, même si ça ne fait pas tout ce qu'on veux, juste un ensemble qui ait un sens et soit fonctionnel.

Je connais quand même la différence entre les méthodes agiles et La Rache . Oui, le développement par itérations c'est bien, ça je suis d'accord. Mais ce n'est pas une raison pour pondre un truc fonctionnel en 2h et se rendre compte 2 semaines plus tard que tout est à jeter car ça ne s'imbrique pas comme il faut avec l'ensemble.
Ce que je veux dire, c'est qu'il vaut mieux prévoir un minimum (pas tout, bien évidemment) son architecture avant d'implémenter quoique ce soit. Je n'ai jamais voulu dire qu'il fallait tout coder d'une traite (c'était peut-être ambigu, je le reconnais).

En fait les tests les plus importants ne sont pas les tests graphiques, tu peux tout à fait être certain que ton moteur est tout à fait fonctionnel sans avoir jamais lancé de partie, si chaque élément est testé face à tous les cas de bords et généraux, et que tous les tests passent…

Dans le cas général : je suis d'accord. Dans le cas présent : non.
Le truc c'est que je ne fais pas juste un Tower Defense (TD) là. Je développe aussi un embryon de toolkit en parallèle, et le TD sera une sorte de test grandeur nature pour voire s'il y a moyen de faire un truc sympa (au final, les deux n'étant qu'une mise en pratique de mon C++) ou s'il vaut mieux passer à autre chose.
Donc pour le moment, la logique veut que je commence par l'interface. Une fois qu'elle sera fonctionnelle j'attaquerai le jeu en lui-même.

Au passage, rien n'oblige à commencer par le moteur de jeu. Dans la mesure du possible, le jeu et l'interface doivent être indépendants. Un exemple parmi d'autre : NetHack (le jeu en lui même) possède de nombreuses interfaces différentes, interfaces qui utilisent des bibliothèques bien distinctes (CLI, Xlib, GTK, SDL, Qt).
Il n'y a donc aucune raison de commencer l'un avant l'autre (si on est plusieurs on peut même développer le jeu et son interface en parallèle). Cela n'est bien sûr pas valable pour tous les types de jeux.

Et donc oui, tu peut faire des tests avant d'avoir une interface qui tourne… c'est aussi de l'agile.

Ça, je suis tout a fait d'accord.

Dernière modification par grim7reaper (Le 19/07/2010, à 21:03)

helly · Le 19/07/2010, à 21:12

Ça peut se faire un constructeur qui fait rien ?
Pour les bestioles à détruire, j'ai une classe mère « Unite » dont dérivent les classes filles des bestioles.
Et j'ai rien à mettre dans mon constructeur de « Unite »
Et dans ce cas je peux déclarer ce constructeur en virtual ?

Dernière modification par helly (Le 19/07/2010, à 21:13)

grim7reaper · Le 19/07/2010, à 21:14

helly a écrit :

Ça peut se faire un constructeur qui fait rien ?
Pour les bestioles à détruire, j'ai une classe mère « Unite » dont dérivent les classes filles des bestioles.
Et j'ai rien à mettre dans mon constructeur de « Unite »

Tu parle bien d'un constructeur qui ne fait rien ?
Parce que constructeur qui ne fait rien != constructeur vide (liste d'initialisation inside).

Si le constructeur ne fait rien alors ne le met pas, laisse faire celui généré automatiquement par le compilo.
Ta classe Unite c'est une classe abstraite ?

Dernière modification par grim7reaper (Le 19/07/2010, à 21:15)

helly · Le 19/07/2010, à 21:18

Non, ce n'est pas une classe abstraite.
(outch, j'ai encore du mal en héritage )

grim7reaper · Le 19/07/2010, à 21:21

Ok, c'était juste une question comme ça. Ce que j'ai dit avant reste valable .

Dernière modification par grim7reaper (Le 19/07/2010, à 21:21)

tshirtman · Le 19/07/2010, à 21:27

si c'était une classe abstraite, lever une exception si le constructeur était appelé aurait pu être une bonne pratique.

mais ce n'est pas le cas

grim7reaper · Le 19/07/2010, à 21:36

tshirtman a écrit :

si c'était une classe abstraite, lever une exception si le constructeur était appelé aurait pu être une bonne pratique.

Totalement inutile si c'est pour empêcher son instanciation.
En C++ une classe abstraite (qui contient donc au moins une fonction virtuelle pure) ne peut pas être instancié, ça fait partie de sa définition.
Le compilateur ne te laisse pas faire, il affiche un message du genre

proof.c++: In function ‘int main()’:
proof.c++:25:14: erreur: cannot declare variable ‘toto’ to be of abstract type ‘Test’
proof.c++:14:1: note:   because the following virtual functions are pure within ‘Test’:
proof.c++:17:22: note: 	virtual void Test::print()

gnuuat · Le 19/07/2010, à 23:38

mv ./gnu{veille,dort}

tshirtman · Le 19/07/2010, à 23:49

@grim: c'était pour forcer l'implémentation du constructeur dans la classe qui hérite de la classe abstraite… mais c'est peut être géré de la même façon en C++ remarque ^^.

grim7reaper · Le 19/07/2010, à 23:57

tshirtman a écrit :

@grim: c'était pour forcer l'implémentation du constructeur dans la classe qui hérite de la classe abstraite… mais c'est peut être géré de la même façon en C++ remarque ^^.

C'est peut-être dû à l'heure ou à mes faibles connaissances en C++ (voire les deux ^^) mais je ne comprend pas le problème.
Si tu hérites d'une classe abstraite et que tu as besoin d'un constructeur tu le fais, si tu n'as rien de non-trivial à faire lors de la construction alors tu ne fais pas de constructeur (le compilo s'en charge).

Mais j'ai peut-être (probablement) mal compris.

Edit : Bon bah j'ai rien codé aujourd'hui (juste corrigé un bug) mais j'ai potassé pas mal de trucs et ça m'a ouvert quelques perspectives .
BN World !

Dernière modification par grim7reaper (Le 20/07/2010, à 00:16)

helly · Le 20/07/2010, à 00:03

BN quand même.

nesthib · Le 20/07/2010, à 00:22

plop les constructeurs !

(bon les enfants, c'est pas fini de jouer aux constructeurs en classe ?)

helly · Le 20/07/2010, à 00:26

@nesthib : tu codes toi ?

nesthib · Le 20/07/2010, à 00:29

@helly : pas à l'instant

helly · Le 20/07/2010, à 00:30

je parle dans la généralité, pas à ce moment M !

Pylades · Le 20/07/2010, à 00:34

Et merde !

Je me suis dit que ça serait bien de recommencer à coder ma bibliothèque → SIGSEGV sur un échec de malloc.

Je viens peut-être de faire une connerie à l’instant…
Pourtant, je n’ai modifié que l’interface et le programme de debug…

Bon, du coup, on verra ça demain, mais ça me fait violemment chier, je croyais en avoir fini avec ces conneries !

nesthib · Le 20/07/2010, à 00:35

helly a écrit :

je parle dans la généralité, pas à ce moment M !

ben oui tu sais bien

helly · Le 20/07/2010, à 00:37

Haaaaaa oui ! (le tdct m'a aidée)
Le langage que je veux apprendre depuis décembre et où jsuis toujours à la page 24 ¬_¬ ( ←j'aime ce smiley )

Кຼزດ · Le 20/07/2010, à 00:42

dodo, faudrait que je code, un de ces quatre

nesthib · Le 20/07/2010, à 00:44

\o/ mathieuI

Dernière modification par nesthib (Le 20/07/2010, à 01:02)

Pylades · Le 20/07/2010, à 01:04

Glob et bonne nuit…

helly · Le 20/07/2010, à 01:04

BN, jsuis pas raisonnable.

tshirtman · Le 20/07/2010, à 01:08

Pourtant, je n’ai modifié que l’interface et le programme de debug…

donc tu as découvert un bug dont tu ignorait l'existence! \o/ (sisi, c'est une bonne nouvelle).

@grim: j'ai pas fait de C++ depuis longtemps, mais en python quand on veux définir une méthode abstraite on mets une exception dedans, comme ça ça oblige les héritier à la redéfinir… j'ai pensé que c'était une bonne idée de faire pareil en C++ ^^.

compte supprimé · Le 20/07/2010, à 02:09

'nuit !

EDIT : Re-bonne nuit !

Dernière modification par Lagierl (Le 20/07/2010, à 03:06)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1351 Le 19/07/2010, à 20:17

Re : /* Topic des codeurs couche-tard [1] */

#1352 Le 19/07/2010, à 20:44

Re : /* Topic des codeurs couche-tard [1] */

#1353 Le 19/07/2010, à 21:12

Re : /* Topic des codeurs couche-tard [1] */

#1354 Le 19/07/2010, à 21:14

Re : /* Topic des codeurs couche-tard [1] */

#1355 Le 19/07/2010, à 21:18

Re : /* Topic des codeurs couche-tard [1] */

#1356 Le 19/07/2010, à 21:21

Re : /* Topic des codeurs couche-tard [1] */

#1357 Le 19/07/2010, à 21:27

Re : /* Topic des codeurs couche-tard [1] */

#1358 Le 19/07/2010, à 21:36

Re : /* Topic des codeurs couche-tard [1] */

#1359 Le 19/07/2010, à 23:38

Re : /* Topic des codeurs couche-tard [1] */

#1360 Le 19/07/2010, à 23:49

Re : /* Topic des codeurs couche-tard [1] */

#1361 Le 19/07/2010, à 23:57

Re : /* Topic des codeurs couche-tard [1] */

#1362 Le 20/07/2010, à 00:03

Re : /* Topic des codeurs couche-tard [1] */

#1363 Le 20/07/2010, à 00:22

Re : /* Topic des codeurs couche-tard [1] */

#1364 Le 20/07/2010, à 00:26

Re : /* Topic des codeurs couche-tard [1] */

#1365 Le 20/07/2010, à 00:29

Re : /* Topic des codeurs couche-tard [1] */

#1366 Le 20/07/2010, à 00:30

Re : /* Topic des codeurs couche-tard [1] */

#1367 Le 20/07/2010, à 00:34

Re : /* Topic des codeurs couche-tard [1] */

#1368 Le 20/07/2010, à 00:35

Re : /* Topic des codeurs couche-tard [1] */

#1369 Le 20/07/2010, à 00:37

Re : /* Topic des codeurs couche-tard [1] */

#1370 Le 20/07/2010, à 00:42

Re : /* Topic des codeurs couche-tard [1] */

#1371 Le 20/07/2010, à 00:44

Re : /* Topic des codeurs couche-tard [1] */

#1372 Le 20/07/2010, à 01:04

Re : /* Topic des codeurs couche-tard [1] */

#1373 Le 20/07/2010, à 01:04

Re : /* Topic des codeurs couche-tard [1] */

#1374 Le 20/07/2010, à 01:08

Re : /* Topic des codeurs couche-tard [1] */

#1375 Le 20/07/2010, à 02:09

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums