They do clump a lot

I've been an attentive reader of KirbyKid's writings on level design for a couple of years, now, so I sent him a copy of Apple Assault v1.1, asking for advices on a few points where my "regular consultants" and I tend to disagree. I was happy and honoured to find his in-depth reply in my mailbox this morning. I'll sure have things to think about and experiments to run in the next weeks.

A force que la plupart de mes "consultants réguliers" (comprenez, CJ, Cyril et Gédéon) me contredisent sur certains choix de design pendant les préparatifs d'AppleAssault, et vu les commentaires peu instructifs récoltés sur dev-fr, j'ai fini par profiter que j'avais un binaire prêt-à-l'emploi pour demander l'avis d'un quasi-pro du level design, j'ai nommé Krazy Kirby Kid. Après quelques échanges de commentaires et d'e-mails, j'ai reçu ce matin sa réponse détaillée dans ma boîte aux lettre, que j'ai ouverte avec une excitation assez proche d'une réponse-du-Père-Noël. Il faut dire que je suis le blog de KirbyKid depuis près de 2 ans et que ses essais sur les "blind-boxes", les "core mechanics" et autre DKART. Un des aspects qui me turlupinait, c'est cette tendance qu'ont les applemen à "s'agglutiner" pour former des chenilles

I had issues with the "wiggler/lemmings" aspect of applemen behaviour, and my initial idea was to make "fall of cliff" somehow probabilistic. KirbyKid pointed out that

I like working with simple predictable enemies. They [Applemen] do clump up a lot though. The issue I have with this is that they can clutter the game (...) [and it] makes it easier for an appleman to sneak behind a stunned appleman and hit you.

La bonne nouvelle, c'est que l'avis extérieur de KirbyKid me motive à faire des expérimentations alors que j'ai plutôt tendance à justifier ma position vis-à-vis de mes "voisins de VTJ". Ou alors il a juste réussi à trouver les arguments vraiment convaincants. Bref, voyons ce qu'on peut faire pour éviter les "grappes" d'applemen, en particulier compte tenu du fait qu'un tel attroupement rend plus difficile l'identification des applemen encore "en course".

Let's experiment another strategy, then ... something more bio-inspired, such as generators that "sense" how many applemen exists in their surrounding and self-inhibit the generation of applemen if a certain density is reached.

state1->state2 on done
state2->state1 on found0
state2->state1 on done [c#applemen# 0 >] (x#throw_appleman# d#applemen#)

Petite idée "bio-inspirée" pour éviter ça: rendre le générateur d'applemen plus sensible à son environnement ... par exemple l'empêcher de générer un nouvel appleman s'il en a vu un récemment. J'ai déjà des zones-de-détections (cf la boîte bleue sur le schéma) que l'appleman utilise pour "voir" Bilou et l'attaquer, c'est le même principe. Sauf qu'ici, celà provoquera le retour anticipé de l'état "sonder l'environnement" (state2) vers l'état "attendre" (state1) alors que la génération d'un nouvel appleman se fait normalement à la fin de l'animation de state2 (à condition qu'il y ait encore des applemen à générer, bien-sûr).

It is actually surprisingly easy to tweak: an additional state (state2) is added to the FSM ruling the generator, which has an "active test area" (depicted in blue) and it will remain in this state only for a few frame, while state1 covers the majority of the inter-applemen delay. We can leave state2 either because an appleman has entered the "sensitive area" of the generator (in which case nothing happens) or because the delay for state2 has expired, and only then we throw a new appleman and decrement the number of applemen still to be generated.

Pour peaufiner, je peux faire en sorte que l'appleman soit à son tour "sensible" à l'annulation d'une génération et du coup "quitte le nid". Ca marche assez bien sur le niveau 1, en tout cas.

An additional tweak allowed the applemen to "sense back" such detection and, when this happens when they're on a cliff, make them jump off. In this way, applemen no longer "stick in their trunk hideout forever" on map #1: after a short time, they will leave the safety of the hollow trees and explore the surroundings. That should make them clump much less, although it's not yet a full-proof solution.

edit: I only gave these new game rules a few tries, but it looks like it doesn't make difficulty increasing with levels. At least, it doesn't make me feel that the game is getting harder, just that the levels are longer and longer to play, and I've been tempted to stop playing when I reached the map #1 with >60 applemen to attract out of there trees. I may need to find something else so that running applemen cannot ambush behind stunned applemen. The fact that the priority of two applemen solely depend on the OAM registers they use doesn't help 0_o


Au final, l'approche n'est pas vraiment concluante. Le niveau 1 est rasoir (sauter pour attirer 60 applemen ou les voir approcher au compte-goutte ... bof. Le niveau 2 déséquilibré (certains "trous" n'auront généré que 2 applemen, et un bug fait que certains restent "cachés" dans leur arbre. Les niveaux 3 et 4 ont leurs générateurs trop loin des applemen et ne sont donc de toutes façons pas affectés. Bref un "compteur global du nombre d'applemen présent à l'écran" aurait été tout aussi (sinon plus) efficace. Je devrais avoir moyen d'arranger les niveaux 1 et 2 avec un "nombre de saut autorisés" défini pour chaque générateur, par contre.