Blabla général Making

Voilà. Les gens qui ont joué à des vieux jeux PCs savent apprécier.

Mais bon, les joueurs de vieux jeux PC sont plus rares que les joueurs  de vieux jeux console, et les joueurs de vieux jeux console sont visiblement facilement effarouchés par les vieux jeux PC, alors tant pis.

(Je me moque, mais comme pour ma part je suis sensible aux deux esthétiques, l'une et l'autre me conviennent.)

Et vous pensez quoi de la "fenêtre dans la fenêtre" ? C'est vraiment le meilleur moyen que j'ai trouvé d'utiliser tout l'espace sans pour autant surcharger d'infos. Ca ne fait pas trop bizarre ? Perso, je trouve ça mignon en fait, on a envie de faire des bisous à cette petite vignette. x)

Coco : oui, je pourrais, mais ça demanderais du boulot supplémentaire. Comme personne ne semble rejeter l'esthétique épurée, je m'en tiendrai à elle seulement, ce sera plus simple. ^^

Je trouve que sans ça, ce serait vite confus et lassant.

Zim a écrit:

Et vous pensez quoi de la "fenêtre dans la fenêtre" ? C'est vraiment le meilleur moyen que j'ai trouvé d'utiliser tout l'espace sans pour autant surcharger d'infos. Ca ne fait pas trop bizarre ? Perso, je trouve ça mignon en fait, on a envie de faire des bisous à cette petite vignette. x)

Je trouve que ça fait trop de traits blancs en peu de place sans raison apparente (il y en a sûrement une).

On verra bien, je peux mettre un blanc cassé.

15 heures à tripatouiller des pixels sans être sûr que le résultat plaira.
2 heures à assembler des ressources un peu bêtes (les chiffres 0 à 150 en pictures + 27 combinaisons de trois objets à trois états).
20 minutes de programmation garantie sans bug.

J'ai fini donc le HUD d'exploration, et je suis arrivé à la conclusion que vraiment, vraiment, je ne suis pas graphiste. x)

Comme quoi la programmation ne prend pas le plus de temps.

(J'attendais que tu me dises la raison ! )



(C'est d'ailleurs quelque chose avec laquelle je ne suis pas d'accord dans l'article de Derek Yu pour finir ses jeux : la partie où il dit qu'il vaut mieux travailler tout seul. Je pense que pour des non graphistes comme nous, s'improviser graphiste est fastidieux et le résultat est souvent décevant. - Je ne dis pas ça pour ton travail en particulier, allons. )

Citation :

(J'attendais que tu me dises la raison !  )

Si tu ne parles pas tant de la couleur que de la présence des traits, eh bien, c'est pour qu'il n'y ait pas trop de vide.
C'est que malheureusement la taille de la partie "interface" est trop grande par rapport aux infos que j'ai à afficher (mais a la juste taille pour les messages), et même aux infos que je peux afficher (pour l'exploration, je ne dois pas mettre trop de pictures, j'ai donc fait l'économie des PV et PM max par exemple.
Sans ça, pour citer KoZzY, "ce serait vite confus et lassant".

PS : un des jeux de Derek Yu est téléchargeable sur Guelnika : Spelunky.

Oui, il faut que j'y joue.

Je dirais que c'est donc une mauvaise raison de mettre un trait...


EDIT : Je teste pour les Alex d'or le jeu Last Chance qui dure 15 heures... C'est un RPG avec des combats aléatoires. Après y avoir joué une heure, je trouve que ces combats aléatoires sont trop longs : il faut au moins 2 tours avec 3 personnages pour arriver à vaincre un ennemi. Soit au moins 6 tours pour un combat avec trois ennemis... je comprends comment on atteint les 15 heures, du coup.

Diriez-vous qu'il y a une règle concernant le nombre de tours pour tuer un ennemi dans un combat aléatoire ? Je dirais 1 tour si l'équipe comprend 3 ou 4 personnages, et 2 tours sinon. (Bien sûr, cela dépend de l'avancée dans le jeu, de s'il s'agit d'un pic de difficulté ou pas...)

En deux tours pour une confrontation simple, puis un une fois qu'on a levelé assez pour le donjon (sinon c'est du "trash mob", qui meurt avant d'avoir fait quoi que ce soit, en tant qu'opposant il ne vaut rien). Quatre-cinq tours pour une confrontation plus compliquées (toujours en aléatoires) à réduire à deux-trois une fois qu'on a levelé. Et réduire le plus possible la durée d'affichage des textes, les animations d'attaque, les temps d'attente entre les tours (pour les ATBs et autres), l'introduction et la conclusion du combat. C'est ce que j'applique pour mon jeu.

Citation :

Je dirais que c'est donc une mauvaise raison de mettre un trait...

Ben... Développer un jeu, c'est faire plein de compromis, composer avec des limitations, etc. Faire le mieux possible avec ce qui est donné et qui ne peut pas être changé, ça ne me semble pas être une si mauvaise raison. (Mais je vois ce que tu veux dire... Mais c'est dans l'idéal, ta remarque. )

C'est un truc qui me fait fuir dans les RPG, Alex. Certains jeux pros ont cela (Romancing Saga 2 : le premier combat à 1 contre 1 dure genre 5 tours... inutile). Pas mal de jeux amateurs RM ont ce défaut aussi. Je me souviens du jeu de Nusenism dans un des concours d'il y a longtemps qui prenait plein de tours pour des monstres anodins.

En théorie, je dirai que l'on doit voir ça en terme de dégâts infligés sur le joueur. Donc un combat peu se finir vite du moment qu'on a retirer ce que l'on voulait. On peut avoir un combat plus long tous les X combats courts afin de dynamiser un peu. On peut aussi avoir un combat long du moment que les tours ne se répètent pas vraiment et ça c'est le plus important. Dans KB2 il y a certains combats longs, notamment dans la tour quand les fées rendent confus un des héros mais quand cela arrive ça change la donne du combat et le joueur doit entreprendre des actions bien différentes pour s'en sortir. Le problème n'est pas spécialement la longueur mais la répétitivité.

Aussi, quand c'est du random encounter on se fait stopper dans notre exploration n'importe quand, il faut donc que le combat soit rapide pour ne pas que cette coupure soit trop longue et que l'on perdre ce qu'on avait en tête juste avant.

Si je devais balancer un chiffre sans trop y penser, comme ça, je dirai que les combats doivent durer moins d'une minute et que l'exploration entre chaque combat au moins la même durée.

J'ai ajouté un système de jauge pour les points de vie et de magie actuels.
J'hésite à le garder (je l'enlèverai s'il n'est pas satisfaisant), mais a priori il répond à mes attentes, et peut-être d'autant plus à cause de son côté bricolage. x)

Tout d'abord, ce retour visuel valorise l'aspect gestion de ressources du jeu. Mais l'intérêt  principal est surtout de signaler au joueur lorsqu'il est dans un état d'urgence. Sachant cela, il n'était pas nécessaire que je détaille les jauges au pourcentage près. Je me suis contenté en fait de paliers de 20%.

C'était important, car je voulais faire tenir les deux jauges sur une image, pour limiter l'impact sur les performances en plein écran. Au pourcentage près, ç'aurait été 100x100 : 1000 images. A 5% (ce qui aurait encore été précisément détaillé), 400 images. A 20%, 20 images, ce qui est quand même largement plus faisable. Même si en fait c'était 49, car il fallait ajouter les images de jauge pleine, et de jauge vide (7x7, donc).

J'ai repris en plus de ça un concept des Marvel vs Capcom, qui ont une jauge en trois parties : vide, plein, et de transition. La partie de transition dans MvC représente une partie de l'énergie perdue, mais qui peut être récupérée lorsque le personnage est au repos (ce sont des combats en équipe, on peut switcher à tout moment le combattant qu'on contrôle, les deux autres étant en réserve). Appliqué à mon jeu, la partie de transition, c'est la partie de la jauge où le joueur se situe "en gros". La tranche de 20% où il est. Il me semble que de cette manière, le fait que la jauge ne soit pas détaillée au pourcentage près sera mieux accepté : ce n'est pas qu'elle est insuffisamment mise à jour, c'est qu'elle n'est que grossièrement précise... et pourtant suffisamment pour les besoins du jeu (l'essentiel, comme je disais, étant de représenter visuellement le vidage de ressources, et de signaler les situations d'urgence).


Bref, ça donne ça :

C'est très beau mais si tu te soucies vraiment des performances de ton jeu, la méthode la plus optimisée dans ton cas consiste en 4 images seulement, 6 avec tes jauges de transition et a une précision du niveau du pixel (même si tu peux habilement faire des paliers de 20% si tu le souhaites) : faire "Déplacer les images".
Il te suffit pour ça d'avoir ces images (le rose est bien évidemment transparent)

1.2.
3.4.
5.6.
1: Le contour de tes jauges, peut-être que tu utilises une image globale pour tout ton HUD dans ce cas-là c'est parfait tu n'as qu'à y faire deux fentes.
2: Le fond de tes deux images à garder fixe en dessous de 1.
3, 5 : tes deux jauges, à faire se déplacer à chaque changement de valeur selon les variables : y est constant mais x diminue avec la proportion de vie/magie
4, 6 : tes deux jauges complémentaires, à faire se déplacer de la même manière.

A la fin tes images devraient être positionnées avec cette priorité (de la plus haute à la plus basse) : 1. > 3./5. > 4./6. > 2., de telle sorte que la partie gauche de tes jauges qui dépasse (si la jauge n'est pas à 100%) soit masquée par 1.

Un poil plus compliqué : les calculs permettant de positionner tes jauges selon l'axe x. Je te sais doué donc je ne pense pas avoir à te les expliquer mais ce serait avec grand plaisir!


Tu ne peux pas faire plus optimisé, que ce soit en terme du nombre d'images (et donc de poids de ton jeu) ou des performance puisque les images ne seront chargées qu'une seule fois. En plus le nombre de lignes de code ne doit pas excéder plus d'une quinzaine donc c'est propre  

Bonne chance!

Hélas, ce n'est pas seulement charger les images qui impacte les performances, mais le fait qu'elles soient chargées, quand on veut ensuite en déplacer ou en charger d'autres. Du moins en plein écran. En fenêtré il n'y a aucun souci.
Ma méthode tient en une seule image à charger (49 à préparer, mais ça, peu importe, et puis ça pèse juste 58 ko, et encore c'est en bitmap).
Et le code tient en pas grand-chose non plus. ^^

Si je voulais le plus haut taux de précision (à 2% près, les jauges faisant 50 pixels), je séparerais simplement les deux jauges en deux images à afficher, et créerais autant d'images que de degrés de remplissage ? Ce serait un peu pénible, donc je pense qu'en supprimant la couleur "palier" (inutile si les jauges sont précises), et en me servant de deux autres images déjà chargées pour y mettre les fentes et fonds gris, je réduirais ta méthode à deux images à charger.

Je verrai bien une fois le système de combat programmé ce qui est préférable : une précision moindre en une image, ou une plus grande précision en deux. ^^

Et merci pour ton message !

De ce que j'ai pu voir avec le temps sur RM c'est que la taille ou le poids des pictures n'a aucun ou peu d'impact c'est simplement les charger qui créait une latence. Les deplacer ne fait rien, les garder ne fait rien. Tu as un PC très vieux ?

Sinon bah, moi je mets mes pictures en png et pas en bmp ça doit aider peut être.

Relm a raison c'est la commande afficher image qui fait ramer, et non le fait d'avoir des images affichées, c'est pour ça qu'il est préférable de les afficher en début de scène et d'ensuite les faire apparaitre où disparaitre en fonction des besoins.
Et le BMP fait moins ramer que le PNG, mais c'est beaucoup plus lourd.

Zim y'a pas l'air d'avoir énormément de calculs in game pour ton projet, ça m'étonne beaucoup que tu ai des soucis de performances.
Un code vraiment bien optimisé ne posera pas de soucis avec RM, où alors faut vraiment pousser jusqu'aux limites comme Joke l'avait fait avec son CBS pour Décadence.

Idéalement il vaut mieux charger des bmp que des png. Plus lourds dans les dossiers, mais plus rapides à afficher.
Vous avez parfaitement raison sur le fait que la commande Afficher Image est plus gourmande que Déplacer, et j'utilise déjà la commande déplacer image pour gérer mes décors, mais la commande Déplacer l'est tout de même, sur de grosses images (les miennes faut le maximum, 1600x1200) lorsqu'elles sont très nombreuses (19 actuellement en comptant celles du HUD).
Mais c'est en plein écran que RM gère n'importe comment l'affichage du jeu (preuve en est, il est paraît-il impossible nativement - c'est-à-dire sans un certain utilitaire de Cherry - de faire tourner un jeu RM 2K ou 2K3 de manière fluide sur Windows 8), ce qui ne porte pas à conséquence la plupart du temps, mais étant donné que je dois mettre à jour en temps réel 15 images à la fois sur 19, si j'en mets plus, ça commence à tirer la gueule, j'en ajoute donc au compte goutte (je ne pense pas avoir à dépasser 19, c'est même sûr). En plein écran, actuellement, si j'arrête d'appuyer sur les touches à un moment précis après avoir couru, il arrive une fois sur trente qu'il y a un lag d'un dixième de seconde dans l'affichage du labyrinthe. Après faut savoir que mon ordinateur chauffe, ralentit et s'éteint de plus en plus souvent, en jouant à des jeux 3D, mais même 2D (dernièrement Tiny Barbarian DX), il commence effectivement à se faire vieux, ou s'empoussière... Et tant mieux, ça me permet de gérer au mieux les performances.

Citation :

Zim y'a pas l'air d'avoir énormément de calculs in game pour ton projet, ça m'étonne beaucoup que tu ai des soucis de performances.

Je ne sais pas si tu te rend compte. x) Et surtout ça n'a rien voir, puisque le problème est de gérer constamment plein d'immenses images à la fois, peu importent les calculs.

Je confirme pour Windows 8 et le plein écran. Déjà le plein écran n'est pas plein écran (le jeu garde son ratio, certains aimerons d'autres comme moi non) mais surtout ça lag. Je ne connais pas cet utilitaire de Cherry, c'est quoi ?

Un souis que l'on va avoir à mon avis bientôt c'est que RM 2003 va devenir simplement incompatible avec les windows actuelsé Dejà avec le 8 ça commence à merder. Ce serait vraiment chiant.

Il faudra demander à Cherry, alors.

Elles sont chouettes ces jauges !

Sinon, une suggestion pour les traits :

Spoiler:

(Au fait, merci Zim et Relm pour votre réponse sur le nombre moyen de tours d'un combat.)

L'utilitaire, c'est "Another Full Screen Mode" en haut de page : http://www.rpg-maker.fr/programmes-type-patchs.html

C'est à lancer une fois le jeu lancé préalablement, mais il existe un autre exe qui lance le jeu puis AFM automatiquement (je ne retrouve pas le lien de celui-ci, mais je l'ai dans mes dossiers).
Sur mon ordi, l'affichage des images, n'étant plus géré par RM (rien à voir, donc, Falco, avec l'optimisation de mon code   l'optimisation consistant justement à tenir compte de ces limites), se fait merveilleusement immédiat, c'est pourquoi il est probable que je distribuerai mon jeu avec.
Malgré tout, contrairement à toi je n'aime pas que le ratio d'écran ne soit pas conservé, ça détruit le pixel-art, or ici sur les écrans larges, l'image est toute étirée.
C'est pourquoi, en attendant qu'un jour quelqu'un me programme un utilitaire qui change la résolution du moniteur, la remet une fois le jeu quitté, et lance automatiquement l'exe qui lance automatiquement le jeu puis AFM, j'essaie au moins d'optimiser le jeu en plein écran sur Windows 7, mais peut-être que je m'embête pour rien au fond (au moins ça me permet de me tenir à l'essentiel, ce qui n'est pas plus mal).

AlexRE :
- heureux que les jauges te plaisent. Avant d'arriver à un aspect aussi épuré, je suis passé par plein d'autres designs. C'est une jauge tellement facile à dessiner, mais penser à le faire m'a pris du temps x)
- lol tu n'as pas oublié le croisement de jeux avec Harusame
- oui pour les traits, c'est même en vérité l'étape qui a précédé celle de la petite vignette... mais ça marche moins bien pour le HUD de combat, ou tout autre où il y a un choix à faire : il me semble bien plus parlant de marquer les limites du choix dans une fenêtre fermée, distincte du reste. (Vous êtes deux à vous être exprimés contre cette idée, l'autre étant trotter, mais la plupart, ça n'a pas l'air de les choquer plus que ça.)
Je parle de l'écran à droite :

Spoiler:

Citation :

Un souis que l'on va avoir à mon avis bientôt c'est que RM 2003 va devenir simplement incompatible avec les windows actuelsé Dejà avec le 8 ça commence à merder. Ce serait vraiment chiant.

C'est pour ça qu'il commence à être urgent de finir nos jeux fait avec ce logiciel. L'objectif pour le mien, c'est fin juin 2015, dans un an, donc.

edit: Merde, putain de con de firefox de m... Je suis désolé Zim, j'ai édité ton post au lieu du mien, vraiment navré, c'est cette connerie d'explorateur qui a laggué au moment où j'ai cliqué sur Edit et je me suis pas rendu compte du truc :/

Perso je n'aime pas les deux jauges que tu as rajouté. Je trouve l'indication déjà assez claire avec les nombres, rajouter des jauges ça fait un peu "remplissage forcé" en plus de ne pas avoir grande utilité à mon sens puisque l'indication par les nombres est déjà ce qu'on peut faire de plus précis.

edit (sur le bon post, cette fois):
Si tu changes la couleur des noms "Vie" et "Magie" ça fera le même effet sans tomber dans la surenchère, je pense.

Ah non, t'inquiète, il n'y a eu aucun dégât !

J'avais essayé d'abord en changeant la couleur de Vie et Magie (et/ou les nombres associés), mais ça attirait trop l'oeil et faisait un peu festival de couleurs.
Et sans ces couleurs, les nombres ne suffisent pas tout à fait à eux seuls. Ce serait le cas si j'avais mis les pv et pm max, mais pour économiser une image (autrement il en faudrait une pour les pv max et une autre pour les pm max), je compense avec les jauges.
En ce sens, il me semble qu'elles ne sont pas redondantes. Mais je me pose la question de les garder ou non en effet (au pire, ça se vire en un switch, si par exemple je les propose en option). Mais rien que parce qu'elles mettent l'accent sur l'importance de gérer ses ressources de vie et magie, elles me semblent être au service du gameplay.

D'autant plus que des jauges sont plus "visuelles" que des nombres. (= Plus agréables, plus intelligibles.)

Zim a écrit:

L'utilitaire, c'est "Another Full Screen Mode" en haut de page : http://www.rpg-maker.fr/programmes-type-patchs.html

Je l'avais utilisé, mais ça clignotait très bizarrement sur mon PC.

Zim a écrit:

il me semble bien plus parlant de marquer les limites du choix dans une fenêtre fermée, distincte du reste. (Vous êtes deux à vous être exprimés contre cette idée, l'autre étant trotter, mais la plupart, ça n'a pas l'air de les choquer plus que ça.)
Je parle de l'écran à droite :

Spoiler:

Et pourquoi ne pas afficher la fenêtre fermée seulement quand le choix se présente ?

Ou coller la bordure à celle de la fenêtre principale ?

Ou laisser juste une ligne d'un pixel de large entre les deux bordures, aussi bien au dessus qu'à droite et en bas ?

(Ce ne sont évidemment que des suggestions, pour t'amener à réfléchir à d'autres solutions.)

Je sais qu'il y a un logiciel pour faire des gifs du in-game et plein pour faire des vidéos, mais est ce qu'il en existe simplement pour des screens plutôt que devoir tout coller à l'arrache des morceaux de map en galérant ? (En l’occurrence là j'utilise rpg maker xp. Oui c'pour le concours de Choco.)

J'ai trouvé ce script : http://www.rpg-maker.fr/scripts-292-el-panoramisator-xp-24.html

Tu as juste à créer un script au dessus du "Main", et ensuite tu copie colle le code présent dans http://www.rpg-maker.fr/dl/monos/script/elpanoxp.txt dans ce script.

Pour le lancer, tu met un Evénement en déclenchement automatique qui contient la commande "script" (dernière commande de la page 3) avec dedans :

Code:

$scene = Scene_Panoramisator.new

Et normalement ça devrait fonctionné

Génial, merci je vais tester ça tout de suite!

Double post pour le verdict : Ca marche effectivement très bien, sauf que ça ne prend pas les events !
J'ai bidouillé donc c'est OK, mais c'est vraiment juste la map qu'il prend. L'interface est simple et claire.