samυncle a écritbon après avoir lu
ceci, je pense qu'il va falloir qu'on choisisse que les unité minimale, c'est pas mal d'unité c'est ambitieux et donc si on ne prend que la base ça sera plus simple. C'est illusoire de vouloir faire toutes ces unités du moins en 2 semaines je ne pense pas qu'on y arrive
Ça, c'étaient les idées de base que je lui avais envoyé, je sais qu'il ne comptait pas la réutiliser telle qu'elle, mais sans avoir tellement plus de détails (en gros, mon truc à moi était basée sur la nature en général, d'où par exemple la présence des ours), et lui comptait recentrer ça sur l'idée de jardin (d'où
« hortus » belli).
Après, l'avantage de ce genre de jeux, c'est que si on fait ça correctement, ce n'est pas trop difficile de le rendre extensible en permettant d'ajouter d'autres sortes d'unités par la suite. Il « suffit » d'avoir une partie moteur assez souple pour accepter plusieurs comportements, et le détail des unités peut être placé dans des fichiers de conf plutôt qu'en dur dans le code.
tshirtman a écritSi on peut changer la source d'une image (si les attaquants sont animés) en cours de jeu, je pense qu'on a tout ce qu'il faut.
Un composant gtk.Image peut être mis à jour à n'importe quel moment à partir d'un fichier ou d'un gtk.Pïxbuf qu'on aurait déjà stocké quelque part.
Il faut juste éventuellement faire gaffe aux tailles si elles sont différentes (on peut fixer la taille du composant image pour être sûr), mais sinon, c'est assez simple à utiliser (en tout cas beaucoup plus que des composants plus « évolués », et ça suffit amplement à nos besoins).
tshirtman a écritOui, c'est très classique en jeu vidéo de faire ça, par contre, la grille, c'est uniquement pour les "tours" hein ? les enemis on les déplace au pixel, avec une vélocité par seconde (dx/dt, dy/dt), ok ?
Il me semble qu'on peut dire à gtk de lancer une action dès qu'il a du temps libre, au check le temps passé depuis le dernier appel, et on fait les mises à jours (déplacements, calculs de collisions / dégats, conditions de victoires, etc), et le reste, l'ui on le gére en évènementiel avec gtk, il faudra peut être créer un system d'events temporels avec durée et callbacks pour les actions complexes, mais c'est pas énorme, je l'ai déja fait pour usfk
Le plus simple, me semble-t-il, est d'utiliser la fonction glib.timeout_add : elle permet de rappeler automatiquement une autre fonction après un nombre de millisecondes fixé.
Du coup, on stocke un dictionnaire avec comme clefs les identifiants d'unité et comme valeurs les positions auxquelles on veut que l'unité se trouve, on ajoute des données dans le dictionnaire à chaque fois qu'il y a besoin de déplacer une unité, et la fonction de placement se rappelle toute seule périodiquement (genre toutes les millisecondes) pour effectuer les modifs présentes dans ce tableau, et le vider quand elle a fini.
Ou quelque chose du genre.
Niveau « grille », j'pense qu'on peut éventuellement en utiliser une dans la partie moteur, du genre pour savoir si une unité se déplace sur telle ou telle ligne pour savoir si elle se mange ou pas un projectile, mais dans la partie graphique, tout ce qu'on a, ce sont les coordonnées auxquelles placer l'unité.
Sinon, t'veux dire quoi par « tours » ?
tshirtman a écritSi on veux faire ça, faut encapsuler l'api de gtk avant de l'utiliser, comme ça, on peut juste implémenter ce dont on a besoin avec un autre toolkit après.
Ça paraîtrait assez propre en effet de faire comme ça.
