La simulation de fourmilière est vraiment marrante à coder car on voit les fourmis progresser au-fur-et-à-mesure qu'on code. Et si c'est bien codé, cela peut devenir rapidement un joyeux bazar avec plus de 20000 fourmis à la fois !
Vous avez la possibilité de refuser les sujets et de faire le votre ? Curieux
Je les trouve également bien foutus ces sujets : à la fois très simples et pourtant « complexifiables » à loisir si le cœur (et l'horloge) vous en dit. Tels quels, les énoncés ne requièrent aucun algorithme de recherche de chemin par exemple.
Il conviendra d'utiliser des automates (que vous avez dû voir en cours) pour modéliser les entités dynamiques si vous optez pour l'un des deux.
Ça me donne envie de coder les fourmis, tiens.
+1 sur les sujets, ils sont pédagogiques dans le sens où il vous font réellement résoudre un problème tout est laissant la porte ouverte à une représentation très visuelle. Cela enlève un peu la partie "gameplay" et je suppose que c'est ce qui vous déçoit. Mais cette partie est la moins intéressante à coder et apporte un lot de complexité (input utilisateur -> asynchronisme, multithreading) que vous risquez de ne pas pouvoir traiter en si peu de temps.
Qui c'est qui vient casser l'ambiance ? C'est jojo !
Sur les fourmis : c'est fun à coder, pédagogique ... mais aussi éculé. Quand j'étais dans mes études ça l'était déjà, et pourtant ça remonte. Quant à la notion de "jeu" : si on considère la partie ludique de la prog ok, sinon le résultat final sera aussi fun qu'une défragmentation d'un HDD sous Window 95 (ce qui était plutôt envoutant, je l'avoue volontier ).
Voilà voilà ...
jojo, t'as perdu ton âme d'enfant.
Bonjour bonjour,
Alors voilà, c'est décidé, nous allons faire les fourmis ( comme quoi vous savez être persuasifs ). Nous allons voir, en fonction du temps si l'on fait le déroulement normal de la chose, ou si nous rajoutons qques trucs drôles.
Alors j'aurais une question, nous allons devoir utiliser une "machine à états" ( ou un truc dans le genre ), et selon l'état "e" de la fourmi a l'instant "i" ( ex : deplacement aléatoire, retour à la fourmilière, etc) nous allons devoir changer (ou non) son état. Et je n'ai pas trop compris comment est définit un état, en gros, comment le programme sais l'état de la fourmi ?
Aussi, notre prof nous a dit que nous allions utiliser la library CONIO, pour nous servir du getXY comme pointeur ( je ne sais pas du tout si ce que je dis vous parle ). Si vous avez compris, pourriez vous m'expliquer en qques lignes sont fonctionnement ?
Merci à vous,
K
Et voilà tu as 2 états.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 enum class State { RandomMove, BackToHome, };
Si vous pouvez, j'utiliserais la SFML, je trouve plus simple la prise en main, et vous pourrez vous amuser bien plus avec le programme.
Merci,
Dans ton code, comment le progm sais que RandomMove = déplacement random ? On doit sûrement l'initialiser qque part non ?
Aussi, si tu devais me donner une définition de la SFML ? Que nous apporte-t-elle de plus que ce que nous faisons ?
K
conio est une bibliothèque C propriétaire (et primitive) de windows pour manipuler l'affichage en mode console.
la SFML est une bibliothèque C++ pour faire un affichage graphique (images, dessin, etc).
La concurrence à conio, ce sont les *curse (dont ncurse).
Aaaah d'aacord. Je ne sais pas si nous allons vraiment inclure des images, selon le temps qu'il nous restera. Nous projetions plutôt d'afficher un tableau de x*y, avec F pour fourmi et N pour nourriture. Mais il est vrai que ce doit être plus " joli " en utilisant le SFML .. Sauf qu'on y connait vraiment rien au SFML, donc on verra en fonction du temps
K
conio en 2017.. passons.
@Bousk : je pense que l'OP ne sais pas où placer les instructions qui implémentent le comportement défini par l'automate.
Une manière parmi d'autres d'implémenter un automate simple est :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84 class Actor { public: enum State { LookForMushrooms, EatMushroom, EnjoyGoodTrip, SufferBadTrip, Sleep }; void changeState(TState stateNext) { // exits current state switch (stateCurrent) { case LookForMushrooms: { /* ... */ break; } case EatMushroom : { /* ... */ break; } case EnjoyGoodTrip : { /* ... */ break; } case SufferBadTrip : { /* ... */ break; } case Sleep : { /* ... */ break; } } statePrevious = stateCurrent; stateCurrent = stateNext; stateDuration = 0.; // enters next state switch (stateCurrent) { case LookForMushrooms: { /* ... */ break; } case EatMushroom : { /* ... */ break; } case EnjoyGoodTrip : { /* ... */ break; } case SufferBadTrip : { /* ... */ break; } case Sleep : { /* ... */ break; } } } void update(double deltaTime) { stateDuration += deltaTime; // updates current state switch (stateCurrent) { case LookForMushrooms: { if (mushroomOnCurrentCell()) { removeMushroomFromCurrentCell(); changeState(EatMushroom); } else moveToRandomNeighboringCell(); break; } case EatMushroom : { changeState((rand() % 10 > 3) ? EnjoyGoodTrip : SufferBadTrip); break; } case EnjoyGoodTrip : { if (stateDuration > 10.) changeState(LookForMushrooms); break; } case SufferBadTrip : { drainStamina(deltaTime); if (stateDuration > 25.) changeState(Sleep); break; } case Sleep : { if (stateDuration > 30.) changeState(LookForMushrooms); break; } } } private: TState stateCurrent, statePrevious; double stateDuration; }; /* ... */ void Simulation::update(double deltaTime) { // advance all actors state for (auto actor : actors) actor->update(deltaTime); }
Alors non, décider de réaliser un projet d'une semaine en ligne de commande ou en mode graphique ne se décide pas le vendredi à midi. Sauf si l'application est conçue de manière modulaire (traitement vs. présentation) et je ne pense pas que ce sera le cas de la vôtre. C'est pas un mal vous pourrez vous focaliser sur la simulation.
C'est pourquoi j'avais proposé de se renseigner à l'avance sur les potentielles solutions techniques.
En ce cas il serait temps de s'orienter vers des sources plus précises, à commencer par ici-même vers le forum 2D/3D/Jeux
http://alexandre-laurent.developpez....boucle-de-jeu/
http://jeux.developpez.com/tutoriels/
https://en.wikipedia.org/wiki/Finite-state_machine
Page déjà citée plus haut, la suite serait : https://en.wikipedia.org/wiki/Automa...ed_programming .
Bonsoir !
Juste pour donner des nouvelles, parce que j'ai pas beaucoup de temps pour moi ^^ On a décidé de rester en mode texte, en utilisant la bibliothèque CONIO et le gotoxy() pour certains déplacements. Nous devons avoir fini le jeu demain à midi, mais il nous reste encore une étape à faire.
Pour le moment nous avons le programme qui tourne avec Une seule fourmi, et il fonctionne parfaitement. Excepté que lorsque nous voulons ajouter une autre fourmi, on a un beug.
En gros notre programme principal boucle à chaque fois que la suite d'actions suivante est terminée :
une fourmi bouge aléatoirement > elle trouve de la nourriture > elle la ramène a la fourmilière
Ce qui fait que la premiere fourmi bouge, fait ces actions et s'arrete, la suivante s'y met, etc ..
Donc voilà ^^ Je vais chercher comment faire, si vous avez des idées/conseils
K
Bonjour,
Peut être ce tutoriel pourra vous aider : http://alexandre-laurent.developpez....boucle-de-jeu/
En fait, dans la fonction update, vous allez parcourir votre liste de fourmis et exécuté l'action (le déplacement) qu'elle doit faire.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager