Deux détails qui peuvent vous arriver (en tout cas dans la version actuelle) et qui sont contournables dès maintenant :
L’export en web ou en exe prend des plombes
Perso, au bout de trente minutes, j’ai fait un kill proc sur java.exe (25% de proc et 850 Mo en mémoire).
La cause, ce sont les optimisations proposées avant l’export. Pour les gros projets, il vaut mieux tout décocher.
Et là, comme par miracle, c’est plié en 2-3 minutes.
L’aperçu en natif prend des plombes
Vous êtes tout fier d’avoir fignolé votre scène dans ses moindres détails.
Mais impossible d’avoir un aperçu dans GD en moins de 10 minutes de moulinage ? Changez de PC !
Même avec l’antivirus désactivé, et les réglages optimums de perf, GD nécessite un processeur double/quadruple coeur pour la compilation de scènes. Sinon, ça raammmmeeeeee. Testé sur un Celeron D à 4 Go de RAM, et j’ai le temps de passer à la grosse commission avant de pouvoir débugger ma scène.
Donc i3 sinon rien.
Autre solution si votre projet vous le permet : faites un aperçu en web. Ca lui prendra moins d’une minute.
Ou alors, optimise ton projet manuellement C’est plus compliqué et ça prend plus de temps mais ça en vaut la penne. Si certains événements se répète plusieurs fois dans différentes scène utilise des événement externe pour intégrer
Perso, mon projet actuelle comporte deux scène : Une scène moteur et une scène éditeur puis j’ai deux sous événement externe principaux : sauvegarde et chargement utiliser de très nombreuse fois dans mes deux scène.
Voila, tout ça pour dire que ma machine est un celeron et l’aperçu se fait en moins de une minute
C’est valable pour de petits projets.
Mais si tu veux de la variété, du contenu et de l’ergonomie, tu vas devoir multiplier scènes et évènements externes.
Sur mes deux projets sous GD j’en suis respectivement à 30 et 60 scènes pour 30 et 10 évènements externes.
Le premier est un clone d’asteroids, le second un point’n click dans un batiment unique.
Les deux sont relativement simples d’un point de vue fonctionnement. Mais si on veut un vrai feeling “pro”, il y a quantité d’écrans à proposer en plus (titre, intro, ending multiple, save, load, profiles, credits, cutscenes, inventaire, paramètres, scores, etc. ).
4ian m’a conseillé de m’appuyer sur des agencements pour éliminer les scènes qui changent peu de l’une à l’autre.
Mais je trouve que cela impose une gymnastique mentale source d’erreurs, notamment dans le cas où l’exploration est libre (et qu’il faut se souvenir que cette scène mène à celle-là qui mène à ces trois-ci, etc. ).
Je préfère le “un niveau = une scène”, où je peux gérer les évènements dont je n’ai besoin que pour cette scène. Comme sous RPG Maker en somme.
Je comprend parfaitement Avec deux scène c’est déjà assez dur deux raisonner avec deux événement externe qui s’entrecroise alors avec 20 C’est vrai que d’un point de vue très gros projet GD est moins efficace la ou RPG Maker, entre autre, se débrouille pas trop mal.
En fait, le modèle des scènes a évolué dans le sens où il vaut mieux maintenant privilégier la vision d’une scène comme étant un moteur de jeu ( ou un moteur de “menu” ) et moins “une scène = un niveau”.
Ca passe bien encore avec les jeux HTML5 car y a pas de compilation, mais pour les jeux natifs, on gagne beaucoup à garder une scène en moteur, et utiliser les évènements externes + agencements externes.
L’important n’est pas tant les évènements externes qui sont là pour une logique d’organisation, mais plutôt de factoriser dans une même scène le plus d’élements de jeu possible, l’idéal étant une unique scène “Moteur de jeu”, même si ce n’est pas toujours possible ou adapté à tous.
C’est plus compliqué et ça prend plus de temps mais ça en vaut la penne. Si certains événements se répète plusieurs fois dans différentes scène utilise des événement externe pour intégrer 
C’est vrai que d’un point de vue très gros projet GD est moins efficace la ou RPG Maker, entre autre, se débrouille pas trop mal.