[Inform 7] Limite de mémoire, ampleur d’un projet

Création Inform 7
1

Salut à tous !

Me revoici avec un vrai problème : la limite de mémoire. Je me suis retrouvé face à ce message d’erreur lors de la compilation.

[spoiler]Translating the Source - Inform 6 ran out of memory
The application ran your source text through the Inform 7 compiler, as usual, and it found no problems translating the source as far as a sort of intermediate-level code - a program for Inform 6, which would ordinarily then be used to make the final working IF.
Unfortunately, the program must have been too demanding for Inform 6 to handle, because it reported that one of its memory settings had been broken. These are upper limits, usually on the number of things of a particular sort which can be created, or on the amount of memory available for a given purpose.
To get around this, look at the actual output produced by Inform 6 to see which memory setting was broken. For instance, suppose it said:
The memory setting MAX_PROP_TABLE_SIZE (which is 30000 at present) has been exceeded.
You then need to amend your Inform 7 source text to take account of this, by adding a sentence like the following:
Use MAX_PROP_TABLE_SIZE of 50000.
With sentences like this, you can make Inform 6 raise its limits until there’s no longer any problem: see Chapter 2 of the documentation.
Sorry for the inconvenience.[/spoiler]

Je suis certain qu’il ne s’agit pas d’une erreur de syntaxe, j’ai vérifié. Je suis certain aussi qu’il ne s’agit pas du nombre d’objets en mémoire. Non, il semble que ce soit à cause du nombre de types d’objets instanciés, ce qui est, en un sens, beaucoup plus inquiétant.

J’ai testé la commande suggérée par le message d’erreur, " Use MAX_PROP_TABLE_SIZE of (nombre)." En mettant quelque chose de très élevé, c’est sans effet.

Est-il possible de passer outre cette limite ? Et de façon plus générale, quelle taille peut faire un jeu Inform ?

Je suis quand même vachement inquiet pour le coup. Inform a l’air plutôt puissant comme l’engage, ce qui m’a orienté vers un projet qui, par nature, ne peut être que gourmand en types d’objets. Entre ce que peut ramasser le personnage, plus les décors, les monstres, etc. ça grimpe vite. J’espère vraiment avoir mal fait quelque chose ou avoir à disposition des commandes pour débloquer la situation, sans quoi il va me falloir repenser mon jeu en profondeur.

Merci d’avance pour vos réponses !

2

max prop machin n’est qu’un exemple donné par Inform, la vraie variable à changer figure dans le rapport d’erreur de compilation, dans un autre onglet.

3

Ha ok. La variable à augmenter, c’était MAX_NUM_STATIC_STRINGS.
Avec ça, ça passe. Merci Azathoth.

Est-ce que je peux continuer sur ma lancée en me contentant d’augmenter les limites à chaque fois que le compilateur bloque, ou viendra un moment où ça ne passera plus ?

Et vous autres, êtes-vous souvent confronté à ce cas de figure dès que vous vous lancez dans quelque chose de volumineux ? Ou dois-je remettre en cause ma façon de coder ?

Inform peut-il vraiment permettre de réaliser un Donjon Crowler avec tout ce que ça implique en variétés d’éléments ?

L’une des ambitions de mon projet, c’est de pouvoir être customisé à l’infini. Son système mis en place, il suffit d’ajouter des éléments pour que le jeu gagne en intérêt et en rejouabilité. Mais ça veut dire que ça peut devenir très, très lourd. Est-ce que cet objectif est viable ?

4

Kerkerkruip est un dungeon crawler procédural (roguelike), avec même des animations si je me souviens bien ! Bref t’inquiète, y’a la place :slight_smile:

Le format de sortie d’I7 n’a pas de limites en théorie ; par contre, viendra peut-être un moment où ça sera lent à jouer… Mais pour l’instant pas la peine de s’en faire :wink:

5

Merci Mule hollandaise ! Voilà une réponse rassurante. :slight_smile:

6

La limite pour un jeu Glulx est de 2 Go. Mais seulement pour le texte et le code, on ne prend pas en compte les éventuels sons et images. Selon des personnes sur le forum anglophone, ça ferait 20 % de tout Wikipédia, ou 30 000 000 de mots. Donc il n’y a pas de soucis à se faire. :slight_smile:

Les limites que tu as atteintes sont celles du compilateur, et il suffit juste de les augmenter arbitrairement (et tout le monde se plante sur le « MAX_PROP_TABLE_SIZE »…).

Mais comme Mule l’a dit, les jeux deviennent trop lents quand on atteint plusieurs centaines d’objets, à cause de fonctions mal optimisées dans les Standard Rules (mais il est possible de les optimiser soi-même).

Si tu crées des réservoirs de monstres (comme on n’en avait parlé), alors ça peut être une bonne idée de réduire leur taille, ou d’utiliser l’extension pour les créer dynamiquement. Mais tant que ça ne cause pas de ralentissements, ce n’est pas un problème.

Il ne faut pas oublier que les sauvegardes de jeu ne fonctionnent pas entre deux versions différentes, donc si tu ajoutes des choses et que tu distribues la version 2 de ton jeu, ceux qui avaient déjà joué à la version 1 seront obligés de tout recommencer (sauf si tu utilises ton propre système de sauvegarde, avec des fichiers externes, mais c’est difficile à mettre en place).

7

Merci Natrium pour les précisions.
Si ça commence à ralentir, je ferais en sorte d’optimiser ce qui doit l’être. Mais je ne pense pas que ce sera nécessaire avant un moment, pas avant le prototype en tout cas. Selon ce qui est en train de se dessiner, je vais avoir beaucoup d’objets (mais pas non plus des milliers) et ils seront en peu d’exemplaires.

Pour les sauvegardes, ce n’est pas un problème. En fait, sauvegarder pourrait même se révéler inutile. La vocation finale de mon jeu, c’est d’offrir des parties courtes (de quelques minutes à une demi heure) mais aussi différentes que possible. Et puisque je n’ai pas prévu que des éléments se débloquent d’une partie sur l’autre, les changements de versions ne devrait gêner personne.

8

Ou alors au lieu de 150 monstres dans 150 rooms, tu crées par exemple un seul monstre, mais que tu " téléportes ", régénéré, dans la prochaine room qu’explorera le joueur, dès qu’il a nettoyé celle où il se trouve. On peut toujours gruger…

9

Oui, en effet. Et si on veut pousser le vice plus loin, on peut faire un monstre générique, qu’une fonction construit selon les règles du jeu, et qu’on recycle sitôt que le joueur l’a tué. Comme ça, avec un seul objet, on fait 150 monstres différents dans 150 salles différentes. Seul désavantage de cette forme d’ultra optimisation : c’est que ça complique pas mal de choses, surtout si les monstres ont des implications plus variées que de simplement cogner sur le joueur.

J’ai opté pour une solution différente, plus simple, plus adaptée à mon projet. Si ça ralenti, alors je changerai mon fusil d’épaule, mais je devrais alors avoir acquis assez d’assurance dans Inform pour pondre des procédures efficace sans trop de soucis.

En tout cas merci, mon problème est réglé.

10

Il y a un degré de complexité inutile à ne pas atteindre si on ne veut pas se compliquer la vie encore plus qu’avec ce qu’on essayait de simplifier, oui :slight_smile:

Tu peux sans aucun, aucun problème créer une centaine, par exemple, de monstres différents - un troll, un voleur, un truc à tentacules, que sais-je - et comme je disais plus haut, les servir autant de fois que tu veux au joueur, room après room. Ça t’évite des changements de variables hyper lourd (caractéristiques et compétences du monstre, etc) tout en te permettant de varier les rencontres et de pouvoir les proposer à l’infini.

De même si le joueur ramasse 150 épées sur les cadavres de ses ennemis, pas forcément besoin d’avoir 150 " vraies " épées dans le code. Tu peux créer une vraie épée simple, une vraie épée à deux mains, une vraie épée rouillée, une vraie épée enchantée, etc … et ensuite, par exemple, à chaque fois que le joueur tue un Barbare, tu lui dis qu’il ramasse l’épée à deux mains du vaincu, et tu fais : increment the NombreEpées2MainsPortées. À chaque fois que le joueur tue un gobelin, tu lui dis qu’il ramasse l’épée rouillée du vaincu, et tu fais : increment the NombreEpéesRouilléesPortées.

En gros, Inform a beaucoup de mémoire, mais plus tu trouves de « trucs » pour la préserver, mieux c’est - tout en ne tombant pas dans des trucs inutilement complexes. Le joueur jugera ton jeu sur le " fun " et c’est parfaitement indépendant de tout ça…

11

Tout à fait d’accord.
Et le système que tu exposes est intéressant. Je le garde sous le coude au besoin.