Projet jeu programmable

Idée de base

Un jeu dans lequel le joueur peut contrôler son environnement (son personnage, ses unités et possessions, les éléments du jeu en général) via la développement de script. L'idée de base est que le joueur puisse scripter toutes les actions qui sont réalisable "à la main".

Le concept est facilement transposable à plusieurs styles de jeux. Cependant, 2 directions sont particulièrement intéressantes: les RPG en monde ouvert et les RTS.

• Le cas d'un monde ouvert peut permettre une très grande créativité, que ce soit en solo ou en multijoueur (ex: Minecraft, Neverwinter Night). Cependant, cela représente une énorme quantité de travail pour rendre le jeu attractif: il faut offrir un énorme environnement en terme de possibilité, mais également empêcher les joueurs de "détruire" l'univers au détriment des autres joueurs.

• L'usage de la programmation dans un RTS est plus facile à implémenter, et également intéressant. Les parties étant limitées dans le temps, il n'y a pas à gérer de conséquences long-terme. Chaque joueur contrôlant de nombreux bâtiments et unités potentiellement indépendants, c'est très approprié au scripting. Le fait de coder les comportements des mobs apporte un gros plus par rapport aux actions réalisées à la main: les étapes peuvent automatiquement s’enchaîner sans la présence du joueur. Il est possible de coder des comportement en réponse à l'environnement (ex: apparition de l'ennemie, détection de ressource par une unité d'exploration). De même, le coté multijoueur devient une compétition entre l'adaptabilité des scripts, et il est possible d'élaborer plusieurs stratégies différentes. C'est le type de jeu que nous prendrons pour les premiers développements.

API de programmation

L'API serait composée de deux types de fonctions: les fonctions haut-niveau, et les fonctions bas-niveau. Chaque action réalisable par le joueur devrait avoir son équivalent dans l'API (principalement en tant que fonction haut-niveau).

Les fonctions haut-niveau permettent de réaliser très simplement les actions courantes (ex: se déplacer vers tel bâtiment, attaquer un ennemi), mais ne sont pas les plus efficientes. Les fonctions bas-niveau permettent un contrôle plus grand, mais sont plus compliquées à utiliser.

La triche et les comportements "non documentés"

TODO

Prototype - première version

On part donc sur un RTS. Chaque partie se joue entre deux joueurs.

Carte

La carte est composées de 2 bases (1 par joueur), chacune dans un coin opposé. Les premières versions seront simples (pas de décors), et les cartes ressembleront à celles d'un MOBA.

Les bâtiments

• QG. Impossible à construire, présent de base au début de la partie
• Usine: peut produire les unités d'attaque.

Les unités

• Soldat aérien (faible contre anti-aérien, fort contre terrestre)
• Soldat anti-aérien (faible contre terrestre, fort contre aérien)
• Soldat terrestre (faible contre aérien, fort contre terrestre)
• Récolteur de ressource

Chaque unité à 2 attributs:

• Position
• PV

Les ressources

Dans un premier temps, il n'y a qu'une seule ressource: le métal.

API

detect_ennemi() -> List[Ennemi]
attack(Ennemi)
move(Point)  	// Position précise
goto(target)  	// PathFinder
detect_buildings() -> List[Buildings]
detect_resources() -> List[Mine]
miner(target)

Idée en vrac

• Fonctions non documentées: elles seraient en partie utilisées par les PNJs. Il serait possible de "récupérer" les scripts des PNJs (et des éléments du décors en général), de pouvoir les lire et les copier

• Idée de background: L'univers n'est pas forcément futuriste: Le code pourrait être représenté par des "runes" magiques. L'utilisation de ces runes pourrait consommer de l'énergie (mana ?). De plus, cela ajoute l'idée de "matériel": il faudrait éventuellement plusieurs type de runes pour coder.
  -> Équilibre du jeu: mélange de skill pour bien coder, et de matériel à récupérer/crafter pour créer les runes.