Bonsoir !
Concernant les fichiers yml, le seul fichier qui est vraiment un fichier de configuration stricto sensus c'est le fameux project_identity.yml. Tous les autres yml que tu peux voir ne sont que des conversions des fichiers rxdata, permettant ainsi de les versionner via Git.
Concernant le nom du fichier, je laisserai Yuri trancher, personnellement je préfère project_identity, je le trouve plus parlant que parameters qui fait assez générique.
Concernant le dernier point, ce n'est pas nécessaire : il suffit de setup une seule fois la variable 31 sur le numéro correspondant au mode que tu souhaites utiliser directement dans ton event d'introduction (qui est aussi utilisé pour setup pas mal de variables). Ce message n'engage que moi et possiblement que Yuri aura son mot à dire sur le sujet. :b

Pour les fichiers de configuration, c'est au cas où un jour d'autres configurations pourraient être potentiellement possibles (ou qu'un script en rajoute).

Pour la variable, c'est vrai mais c'est mieux de choisir ce paramètre dès le départ. Tout du moins de mon point de vue uniquement. 

Edit : Je propose aussi comme idée de créer un script qui permet de générer l'image des crédits en remplaçant l'année et le nom du jeu dans la ligne de crédits.

C'est des idées qui méritent d'être approfondies.
Pour le moment project_identity contient surement beaucoup trop de chose un peu "unrelated" par rapport à l'identité du projet. (A la base c'était juste le titre, la résolution et quelques paramètres).
Le dossier config me parait être une bonne idée, on pourrait faire plusieurs fichiers et comme mentionné, des scripts pourraient exploiter ce dossier à leur fin

On devrait implémenter un config handler dans PSDK pour gérer la configuration, leur compilation etc...
Ainsi, un script qui a besoin de configuration pourrait simplement définir la configuration dont il a besoin et spécifier le chemin dans lequel la configuration sera stocké dans PSDK_CONFIG

Pour les crédits, j'aimerai bien qu'on fasse qqch, mais pour l'instant rien de spécial n'est prévu dans les détails, on pourrait en faire une configuration qui permettra de générer l'image ou carrément la scène tout en étant sûr que les crédits de PSDK sont bien pris en compte

Bonjour,

Pour le moment project_identity contient surement beaucoup trop de chose un peu "unrelated" par rapport à l'identité du projet. (A la base c'était juste le titre, la résolution et quelques paramètres).

C'est pourquoi je pense que c'est plus adapté que ce soit genre "settings" ou "parameters" pour indiquer que ce sont des réglages plutôt que l'identité du projet (bien que ça peut aller avec aussi). Mais ce n'est qu'un avis purement personnel.

On devrait implémenter un config handler dans PSDK pour gérer la configuration, leur compilation etc...
Ainsi, un script qui a besoin de configuration pourrait simplement définir la configuration dont il a besoin et spécifier le chemin dans lequel la configuration sera stocké dans PSDK_CONFIG

Oui, c'est une idée que j'approuve. Cela peut être bien utile.

Pour les crédits, j'aimerai bien qu'on fasse qqch, mais pour l'instant rien de spécial n'est prévu dans les détails, on pourrait en faire une configuration qui permettra de générer l'image ou carrément la scène tout en étant sûr que les crédits de PSDK sont bien pris en compte

Ah, en effet, je n'avais pas pensé à une scène. Cela peut être soit une scène avec le choix de la carte (ID) soit sous forme d'image. Mais j'aime assez l'idée de l'image générée.

En tout cas, c'est génial que tu aies pris le temps de lire tout ça.

La configuration du project_identity, qui effectivement sera plutôt assimilé à un Project Settings, sera bien plus simple dans le prochain éditeur :D Il s'agira vraiment d'une page de configuration, pour éviter au créateur d'aller taper dans une page un peu lourde aujourd'hui.

Bonsoir à toutes et à tous,

Je reviens vers vous pour une autre idée (mais pas prioritaire en soi) :

- Créer un ordinateur comme pour les Pokémon sauf que ce serait pour les objets (Dans la première génération, on pouvait stocker les objets dans le PC) et ainsi on pourrait organiser les objets dans les boîtes et les organiser comme on le souhaite. La fonction « Déplacer » ne sera limitée qu'aux boîtes mais une option « Retirer l'objet » permettra de récupérer l'objet (ou les objets selon la quantité existante) dans son inventaire.

Bien à vous

C'est effectivement une feature qui n'est pas du tout prioritaire. Tu peux créer une issue sur le Git et tenter de l'implémenter.

Bonsoir,

Je reviens vers vous (encore !!) pour suggérer certaines choses.

@Aerun : Pour en revenir à ce dont tu parlais, pour le moment, le temps d'étudier et à comprendre certaines choses du code, je ne pense pas pouvoir l'implémenter. Mais je ferai sûrement des tests quand j'aurais déjà l'idée de comment organiser ça.

Pour la version .25, je pense qu'il serait intéressant de créer une classe : StartScreen (Ecran de démarrage) avec les méthodes du genre :

• main
• init_splash
• init_menu
• add_button(name, callback, icon) (pour ajouter de nouveaux boutons)

Enfin ce ne sont que des idées. A voir ce que vous en pensez. 

Bien à vous