Skip to content
Snippets Groups Projects

Logo

MARS'GRICULTURE

Sommaire
  1. Projet T3
  2. Objectif pédagogique
  3. Type de jeu et mécanisme d'apprentissage
  4. Liste des principales fonctionnalités
  5. Licence
  6. Lien de téléchargement
  7. Capture d'écran
  8. Procédures d'installation et d'exécution
  9. Méta-Todo

Projet T3

Nom du groupe : LE groupe
Code du groupe : PEC22-T3-A
Participants :

  • FLU Charly
  • HOOGLAND Paolo
  • MARQUE Elise
  • NIEDERBERGER Léo

Lien des consigne : https://git.unistra.fr/T234/T3

(back to top)

Objectif pédagogique

Le joueur doit apprendre la dynamique entre l’offre et la demande, qui détermine les prix d’un produit : l’augmentation ou diminution de celles-ci cherche un équilibre, jusqu’à retrouver une concurrence pure et parfaite (CPP).

Cependant, cet équilibre n’est pas exempté des possibles pénuries et aléas qui peuvent découler de l’extérieur du marché : ces chocs bouleversent le marché, et créent des phénomènes auxquels les joueurs devront s’adapter.

Type de jeu et mécanisme d'apprentissage

Type de jeu

Mars'griculteur est un jeu de type tycoon: le joueur incarne un fermier martien, qui doit gérer sa ferme, vendre ses produits et gérer ses parcelles ; de plus, il doit être préparé à l’imprévu.

Mécanisme d'apprentissage

Pour apprendre les mécanismes du marché face aux changements de contexte, le joueur pourra voir l’évolution des prix de vente moyen sur le marché en fonction des saisons et des évènements.
Il devra donc comprendre et prévoir l'évolution de prix du marché afin de pouvoir fixer ses propres prix.

(back to top)

Liste des principales fonctionnalités

  • Avoir une vu des ses plantations, et pouvoir choisir quelle plante planter
  • Pouvoir voir son stand et mettre des produits à vendre, pouvoir modifier leurs prix en fonction du marché et des événements
  • Arrivée de nouveaux évenements, qui modifie la demande/les prix du marché, ou les récoltes
  • Passer au jour suivant
  • Voir l'inventaire des graines, avec un poids maximum pour l'inventaire
  • Voir l'inventaire des outils
  • Voir l'inventaire des plantes, avec un poids maximum pour l'inventaire

(back to top)

Licence

Les licences de type BSD (Berkeley Software Distribution License) ne nous ont pas intéressées, car elles n’imposent pas la citation de l’auteur lors de la redistribution.

Nous avons cherché si la licence devait être copyleft. “Le copyleft est un cadre permettant de faire d’un programme un logiciel libre et d’exiger que les versions modifiées ou étendues deviennent elles aussi des logiciels libres.” (source : gnu.org). Nous en avons convenu que la licence doit être copyleft.

La licence Apache 2.0 ne sera pas sélectionnée car c’est pour les gros programmes et nous avons décidé que notre programme n’est pas très volumineux.

La licence SAAS (Software as a Service) est une licence pour commercialiser un logiciel en tant qu’application accessible à distance comme un service, par internet. Ce qui n’est pas notre cas.

Nous ne prenons pas les licences GNU qui concernent les bibliothèques.

La licence GNU GPL(General Public License) est une licence en application du “copyleft”, elle nous dit que toute personne qui contribue à l'œuvre ne peut se l’’accaparer. Mais elle a la liberté de copier, de diffuser et de modifier. Les codes sources du programme sont accessibles à tous. (source : Cours) La licence GNU GPLv3 est la dernière version de la licence publique générale GNU. C’est une licence de logiciel libre et d’un copyleft (très fort). Elle n’est pas compatible avec la GPLv2. Elle est approuvée par l’OSI (Open Source Initiative). Elle est pérenne, elle est durable. Elle n’est absolument pas permissive. Et elle a une persistance des 4 libertés pour les additions de code. (source : Wikipédia)

Suite à l’étude du site du GNU (https://www.gnu.org/licenses/license-list.fr.html ), nous avons décidé de choisir la licence GNU GPLv3.

(Voir LICENCE.txt pour plus d'information)

(back to top)

Lien de téléchargement

(back to top)

Capture d'écran

UML

Diagramme de classe
Diagramme de classe

Au début du projet, nous avons décidé de faire un UML pour voir comment allait être agencé le code, et comment étaient relié les classes. Ce diagramme de classe nous a permis de nous répartir le code des classes.

MAP

Vision du début de game
Début de game
Les champs
Les champs
Le magasin
Le magasin
Le marché
Le marché
L'inventaire des graines
L'inventaire des graines
L'inventaire des plantes
L'inventaire des plantes
Les notifications
Les notifications
Les jours et l'argent du joueur
Les jours et l'argent du joueur
Le menu
Le menu

Différentes fenêtres

Le magasin
Le magasin
Le marché
Le marché
L'inventaire des graines
L'inventaire des graines
L'inventaire des plantes
L'inventaire des plantes
Les notifications
Les notifications
Demande au joueur s'il est sûr de quitter
Demande au joueur s'il est sûr de quitter

(back to top)

Procédures d'installation et d'exécution

Procédures d'installation

Sous Windows

Sous Linux

Procédures d'exécution

(back to top)

Méta-Todo

  • Mettre en place son GIT et préparer les milestones
  • Acquérir le sujet et définir un objectif pédagogique
  • Concevoir un poster qui décrit cet objectif pédagogique
  • Définir le type de jeu et les mécanismes d'apprentissage (Septembre)
  • Définir la liste des principales fonctionnalités
  • Développer ces fonctionnalités
  • Evaluation à mi-parcours (Octobre)
  • Tester et équilibrer
  • Choisir la Licence (Novembre)
  • Finaliser le git et produire la documentation
  • Présenter son jeu et le faire évaluer (Décembre)

(back to top)