Daniel's base
www.remar.se/daniel



News


Games

Game guides

Resources

Ludosity games


DDR Simfiles

Doom II levels

UT99 levels

Pics


Forum

YouTube channel

Twitter page

Links

About

FAQ

Donate


 Iji 1.6 - Guide officiel

Introduction - Secteur 1 - Secteur 2 - Secteur 3 - Secteur 4 - Secteur 5 - Secteur 6
Secteur 7 - Secteur 8 - Secteur 9 - Secteur X - Secteur Y - Secteur Z - Secrets divers
À débloquer - Armes - Objets - Ennemis - Boss - Trivia - Fichier texte


Divers

Des tonnes de trucs en plus liés à la création du jeu, liés au codage notamment.


Chronométrage
Voilà comment les Tasen et les Komato mesurent le temps, en se basant sur le modèle Origine/Terre. Je l'avais pensé suffisamment vague pour ne pas avoir à être trop précis dans l'histoire.
  Tour d'étoile = année ; le temps que met Origine pour réaliser un orbite complet autour de son étoile
  Tour long = mois, on ne sait pas combien il en faut pour faire un Tour d'étoile
  Tour = jour ; le temps que met Origine pour réaliser une rotation autour de son axe
  Cycle = heure, on ne sait pas combien il en faut pour faire un Tour
  Cycle court = minute, on ne sait pas combien il en faut pour faire un Cycle
  Cycle pouls = seconde ; la fréquence de pouls qu'avaient les Komato quand ils ont inventé cette mesure...

Ternaire
C'est tout simplement la base trois, de droite à gauche. L'image suivante devrait clarifier la façon dont fonctionne le système ternaire dans le jeu :



Totaux
Le nombre minimum de tués dans le jeu après l'avoir fini est de 0, le maximum est d'environ 600. Le nombre maximum de cracks réussis est d'environ 740, mais aucun de ces deux totaux n'est vraiment possible en raison des pertes que s'infligent les Tasen et les Komato. Le nombre minimum / maximum de dégâts reçus et de cracks ratés sont tous deux de 0 / 999.

Nodules bleu foncé
Si vous regardez attentivement l'interface de crack, vous remarquerez que le nombre au-dessus de chaque colonne indique combien il y aura de nodules bleu foncé pour cette colonne (en ternaire). Comme leur nombre est fixe pour chaque colonne, le jeu ne peut pas générer de labyrinthe inextricable.

Mises à jour ninja
Lors de la création du jeu, je changeais l'image que l'on voit dans la page "Liens" (Links) à chaque fois que j'achevais un Secteur. Comme je dessinais les Secteurs sur papier et que je les accrochais sur mon mur, j'ai ajouté le même détail à l'image de la page "Liens".

Secteur Z
Le Secteur Z contenait à la base des sprites, des niveaux et des comportements d'ennemis copiés sur Super Mario Bros, Zelda 2 et Metroid. Au moment où je créais le Secteur X, le Secteur Z était complètement repensé.

Asha
La manière de parler d'Asha en combat (en particulier son cri : "Tu es à moi !") est inspiré de Lunar, de Mischief Makers. Son nom est dérivé du nom de famille de la doubleuse d'Iji.

Null driver
Le Null driver est appelé ainsi parce qu'il ne "tire" pas, ça n'a rien à voir avec un pilote d'ordinateur (driver). Dans la version 1.2 du jeu, on le trouvait dans le Secteur 2, après avoir terminé le Secteur Z, en crackant une boîte spécifique dont le minuteur des secondes était un multiple de 10. Je suis sérieux.

La famille Kataiser
Cela n'a pas été ajouté au jeu en raison de dialogues "coupés au montage", mais le père d'Iji avait deux femmes, et c'est de sa seconde qu'est née Mia. À un certain moment des relectures, Sonia Plait était censée être la mère d'Iji avant que l'idée ne soit écartée. Iji devait également trouver les cadavres de Mia et de son père dans le Secteur 2.

Mais comment ça marche à la fin ?
Quand Krotera, Asha ou Iosa utilisent une Superarme, leur Nanogun clignote, vous donnant un aperçu de ses entrailles.

Vivre avec son temps
La plus grosse partie d'Iji a été développée avec un ordinateur 850Mhz doté d'une carte graphique de 16MB et de 256MB RAM.

Cinglés
Les trois cinglés Komato aux surnoms ridicules décrivent les rouages du Nanogun d'une manière complexe qui n'a aucun sens pour le joueur, qui, lui, résout une énigme pour aboutir au même résultat.

Récompenser à l'envers
En discutant avec reallyjoel, j'ai décidé de récompenser le joueur avec les meilleurs éléments à débloquer pour les tâches les plus faciles et laisser les éléments les plus fantaisistes pour des choses comme le mode Ultimortal. Je me suis dit qu'il valait mieux donner au plus de gens possible les récompenses les plus intéressantes et gratifiantes au lieu de les mettre hors d'atteinte, puisque la plupart des gens qui finiront le jeu le feront probablement une seule fois en mode Normal.

Technique : Animations et modèles
J'ai conçu 14 modèles 3D pour Iji. Ils ont été montés avec des squelettes géométriques direct, animés image par image et l'ombrage plat a été réalisé via projection parallèle. Les images produites ont été éditées afin de corriger les pixels égarés et ajouter les lignes de vitesse. Comme je n'utilisais pas de géométrique inverse, faire en sorte que tout le monde pose ses pieds ou ses mains par terre s'est révélé particulièrement pénible. La seconde tenue d'Iji a été dessinée à la main par-dessus ses 45 animations de base, et en raison de la vieille version de Blender que j'utilisais (caméra bugguée, outils d'animation et pas de bouton pour revenir en arrière) la masse de travail nécessaire a manqué faire stopper le projet à plusieurs reprises.



Technique : les fils de Proxima
Semblable aux étincelles électriques des ennemis vaincus, ce sont simplement quelques lignes de code d'un draw event. Trois points hypothétiques (des paires de X et de Y) sont en chaîne. Un point veut être à une certaine distance directement sous le point précédent de la chaîne, mais n'y arrive pas immédiatement à chaque image - il divise la distance vers la position souhaitée de 1.5. Les lignes sont alors dessinées entre les points.

Technique : Hero 3D
J'ai conçu Hero 3D en cinq jours. C'était ma première idée qui correspondait aux critères d'un jeu qui pouvait être dessiné en plus d'Iji, qui ne nécessitait pas de dérouler l'écran et n'utilisait pas de mémoire vidéo. Le jeu dessine et calcule tout avec des mathématiques de base, y compris les murs et les collisions. Il utilise des objets de Game Maker pour tout ce qui se déplace. Ils partagent tous un masque de collision de 32*32 (emprunté au "bloc par défaut" d'Iji) et ont pour instruction de se déplacer dans l'écran en fonction de l'endroit où "vole" le joueur.

Technique : optimisation des graphiques
Le style graphique d'Iji est fait pour ressembler à des jeux comme Another World. Le peu de couleurs utilisées pour les sprites et pour les arrière-plans signifie qu'ils nécessitent très peu de place. En réalité, la plus grande partie du poids du jeu est due aux effets sonores, au carrelage et aux localisations d'instance des Secteurs. De nombreux effets et la totalité du combat contre le dernier boss utilisent des lignes, des cercles et des polygones plutôt que des sprites - ce que j'ignorais, c'est que certains système d'exploitation allaient avoir à redire sur la façon de faire de Game Maker et ralentiraient terriblement.

Technique : optimisation des tuiles
La plupart des Secteurs n'ont qu'une seule couche de tuile. Bien que les "extérieurs" des Secteurs utilisent une tuile d'arrière-plan à répétition, les intérieurs étaient à la base remplis de tuiles 32*32, du bleu uni la plupart du temps. J'ai fait un unique arrière-plan bleu 128*128, duquel j'ai extrait une tuile 128*128 et j'ai commencé à remplacer 4*4 pans de 32*32 tuiles bleues. Cela signifie en gros que pour chaque pan de tuiles 4*4 remplacé, je réduisais le nombre de tuiles de 15. J'ai alors extrait une tuile 128*96 de ce même arrière-plan, puis j'ai répété le processus sur une échelle réduite de 64*32, que j'ai également répété pour d'autres structures comme les portes et les murs. Cela a permis aux Secteurs de se charger 25% plus vite et a économisé environ 2.5 MB du poids des fichiers.



Techniques : optimisation des blocs
Comme pour l'optimisation des tuiles, j'ai remplacé de larges pans des blocs invisibles de collision qui recouvrent les Secteurs par des blocs de 128*32 et de 32*128. Cela aboutit à la vérification d'une moyenne de 1/3 à 1/4 de leur nombre de collision d'origine et a tronqué le jeu de 0.5 MB. Un autre détail : les munitions ou les nanochamps en suspension dans les airs. Quand elle tombent par terre, elles éteignent leur propre vérification de collision.



Technique : le boss de fin
Tor est dessiné avec des formes polygonales 2D définies via les listes de vertex, mises en rotation grâce à sinus et cosinus en utilisant une table de correspondance à la précision diminuée d'un tier de degré. Les animations ont été conçues dans le cadre d'un projet Game Maker particulier que j'avais écrit pour construire et animer les boss image par image, cf la représentation ci-dessous. Tor est constitué de 10 os et de 270 sommets distribués en 35 formes et 21 cercles. Les listes de vertex ont été entrées manuellement, dérivées d'un modèle 3D que j'avais construit d'abord.




Technique : optimisation de la désactivation des instances

Quand on "désactive" quelque chose sur Game Maker, il continue en gros à exister sous une forme invisible et figée de ce qu'il était avant d'être désactivé. Il ne peut pas faire fonctionner de code ou vérifier les collisions. La plupart des instances dans Iji sont constamment activées et désactivées un peu en dehors de l'écran, mais cela doit être fait avec doigté - activer la totalité du Secteur est hors de question. Voici comment j'ai résolu cela dans Iji, en l'exécutant toutes les 8 images :

#1 Désactiver un pavé autour de l'écran. Cela assure que tout se désactive derrière Iji quand elle passe d'un endroit à l'autre.

#2 Activer un pavé plus petit autour de l'écran. Cela assure que les éléments s'activent dans la direction où va Iji, du moment que ce pavé reste bien à l'intérieur du pavé précédent il n'y aura pas de "traces" d'instances activées résiduelles.

#3 Désactiver tout enfant du parent obj_deactivateme. Ce sont les éléments comme les ennemis et les objets à ramasser affectés par la gravité.

#4 Activer un pavé encore plus petit que le #2 autour de la vue. C'est crucial : comme les blocs de collision sont activés plus loin hors de l'écran, tous les ennemis sont désactivés. Au final tous les ennemis à l'intérieur de ce pavé sont activés. Cela assure qu'aucun ennemi ne se trouve en dehors du bloc de collision parce qu'il aurait été activé/désactivé à la même distance.

#5 Activer tout enfant du parent obj_activateme. Il y a quelques éléments qui pourraient autrement ne pas fonctionner, comme les téléporteurs.

Il y a quelques cas particuliers, comme quand Iji entre pour la première fois dans un Secteur ou quand elle se téléporte, mais ces deux cas n'affectent qu'une image du jeu, et l'écran devient alors complètement noir ou blanc à ce moment pour cacher le ralentissement sur les ordinateurs lents.


Technique : IA ennemie

L'IA pour la plupart des ennemis suit ces priorités :
Attaquer la race rivale > attaquer Iji > récupérer toute santé à portée en cas de blessure > s'éloigner des blits > marcher sans rien faire.

Prenons un Annihilateur Komato en exemple. Iji et tous les ennemis tirent des projectiles invisibles horizontaux, qu'on appelle des objets vérificateurs de vision. Quand l'objet vérificateur de vision d'Iji ou d'un Tasen touche l'Annihilateur, alors qu'il a le regard tourné dans la même direction que le vérificateur de vision, il "s'énerve" et obtient la permission de traquer sa proie et d'ouvrir le feu. La "proie" en question est l'ID de l'ennemi qui a tiré le vérificateur de vision - chaque ennemi a son ID lié au projectile vérificateur de vision lui-même.

Une fois que l'Annihilateur a identifié sa cible, il a dix secondes pour la traquer avant de redevenir docile. Tant que la cible continuera à toucher l'Annihilateur avec son vérificateur de vision, cela remettra à zéro le compteur. Si la cible est à une longue distance, l'Annihilateur utilisera le Shocksplinter ou le Plasma cannon, mais si l'ennemi est à portée de l'Hyper Pulse (192 pixels) ou du Splintergun (512 pixels) il pourrait les utiliser. Le Plasma cannon n'est pas utilisé si le joueur est à plus d'une moitié d'écran.

Si Iji a cracké l'Annihilateur et qu'il utilise le Shocksplinter ou le Plasma cannon, l'arme explosera avant de faire feu. Cela enclenche chez l'Annihilateur une variable qui s'appelle "oups", lui indiquant d'éviter de réutiliser ces armes.

Les ennemis ont une conception très réduite du combat en équipe. Si un Tasen repère Iji ou un Komato, il enverra un vérificateur de vision alentour qui alertera tout Tasen touché de la cible du Tasen émetteur. Ces vérificateurs de vision mettront un ennemi "en colère" quel que soit le côté duquel il est tourné, un Tasen ou Komato peut ainsi "appeler" ses alliés proches. De la même façon, les tirs d'Iji ou l'explosion d'un ennemi envoient également ces vérificateurs de vision, créant l'illusion que l'ennemi est régi aussi bien par la vision que par l'ouïe.

Pour ce qui est de savoir comment un ennemi choisit l'action à réaliser, il opère par états, alarmes et ordres. Une "alarme" s'enclenche selon une valeur aléatoire à chaque fois que le décompte débute, et elle indique par là même quel ordre l'ennemi doit exécuter. Les ordres sont des choses comme rester immobile, marcher, tirer ou charger un projectile. Le mode de difficulté, l'état de l'ennemi (s'il est "en colère"), son équipement, sa portée au corps à corps ou encore son crackage affecteront les ordres qu'il suivra et la durée qu'il faudra attendre avant qu'un autre ordre soit donné. Pareillement si un ennemi est en colère mais que l'ordre "marcher" lui a été délivré à plusieurs reprises d'affilée (3 à 5 fois selon le type d'ennemi), faire feu avec son arme sera automatiquement son prochain ordre s'il a une cible appropriée à portée. On appelle cela le "désoeuvrement", ça ne s'applique pas aux Scouts.

Si un ennemi n'est pas en colère, il réagira aux vérificateurs de vision envoyés par les Nanochamps rouge, qui les autorise à chercher de la santé après un combat. En construisant un niveau, j'ai parfois placé des Nanochamps rouges là où l'ennemi pouvait les voir mais pas les atteindre. Les ennemis avançaient et reculaient alors de manière répétée, tout en rédigeant un logbook poétique sur les inaccessibles trésors de la vie.


Sommaire du travail sur Iji

Si vous êtes curieux, voilà le logbook exhaustif du projet (95KB). Cliquez droit pour télécharger.

Si l'on en croit mon logbook, Iji est née quelque part en Juillet 2004. Les premiers sprites créés pour le jeu ont été Iji elle-même et un Soldat Tasen. J'avais l'intention de concevoir un simple jeu de plate-forme, mais cela a abouti à des semaines d'écriture sur ce qui est aujourd'hui la base des contrôles du jeu et de la détection de collision. C'était censé au départ être un jeu de survie où on était principalement traqué par un gros monstre coriace, mais ça a vite évolué.

À mesure que j'ajoutais des idées, des personnages et du contenu, les ambitions du projet ont grandi, et j'ai réalisé qu'il allait me falloir des années pour le finir. J'ai pris des mois entiers de pause car la motivation se faisait rare. J'ai sorti deux petites démo techniques en Avril et Octobre 2005, mais elles étaient plus ou moins nulles.

Chaque Secteur prenait des semaines à finir, sans compter l'ajout de nouveau contenu pour chacun d'entre eux. L'exception fut le Secteur 5, fini en 3 jours. Lors de l'été 2006 je me suis mis une échéance de "avant 2008". À ce moment le jeu était fini à un peu plus de la moitié, et je commençais à le tester davantage. De la même façon, je commençais également à travailler plus vite.

Le Secteur X fut une vaste entreprise, en raison du nombre de cas particuliers et de boss secondaires. Mon ordinateur a crashé deux fois, ruinant des heures de travail sur les tuiles. Je m'étais préparé à passer beaucoup de temps sur le dernier boss cela dit. Quand j'en fus à dessiner les cutscenes, je m'étais épuisé à dessiner le mode Ultimortal et j'avais perdu le peu de doigté que j'avais eu un jour. Au bout du compte, les 74 dessins des cutscenes ont pris trois mois, leur implémentation dans le jeu cinq jours. On était alors en Décembre 2007 et il devenait évident que je ne parviendrais pas à respecter mon échéance "avant 2008".

Le doublage et son traitement furent un très bon moment. Les acteurs ne mirent pas longtemps à se mettre dans le bon état d'esprit, et j'avais souvent beaucoup d'extraits parmi lesquels choisir. Après les voix je me suis affairé à terminer les derniers détails pour le jeu. J'ai également fait endurer beaucoup de tests en profondeur à la bêta, que je dirigeais en personne. Je sortais généralement de chaque test avec plusieurs pages remplies de choses à changer avant la prochaine. Je recommande cette procédure de test : ne l'expliquaient pas, ne cherchez pas d'excuses, asseyez-vous simplement en silence et regardez-les jouer. Le mieux c'est encore d'avoir une personne qui joue et un ami à elle à côté qui regarde, pour qu'ils discutent plus naturellement de ce qu'ils voient.

Dans le même temps, mes musiciens ont travaillé très dur pour achever la bande son. J'ai été plus qu'impressionné par le rendu final. À deux semaines de la sortie, je corrigeais des bugs que je n'avais jamais vus auparavant et qui faisaient planter le jeu. Je savais donc que j'allais devoir mettre à jour le jeu plus tard, surtout si je comptais ajouter toutes les choses que je n'avais pas eu le temps d'inclure. Aux alentours de la sortie, je me suis pratiquement effondré et j'ai eu des soucis pour dormir pendant des semaines, en raison de l'angoisse sur la façon dont le jeu allait être reçu. Une angoisse qui a empiré quand cette réception s'avéra plutôt négative. Mais je me suis tapi dans les forums qui parlaient du jeu, parmi les plus caustiques et négatifs, pour trouver des moyens de l'améliorer, jusqu'à ce qu'il évolue en ce qu'il est aujourd'hui.

En charge totale de travail, Iji a fini à environ 3500 heures, 75000 lignes de code, 4247 sprites, 80 images de cutscene, 2111 tuiles d'arrière-plan, 21 musiques et 190 effets sonores et voix. Rien de tout cela, à l'exception de la bande-son, n'est de haute volée, mais il semblerait que les gens acceptent finalement le jeu pour ce qu'il est. J'ai préféré terminer un jeu de grande envergure au mieux de mes capacités d'alors, plutôt que d'attendre que mes compétences se soient améliorées, car autrement je n'aurais rien fait du tout, et je ne me serais pas amélioré non plus.