Discussions générales de making

Petite question : vous pensez que les failles dû aux diagonales et au système de course sont ingérable ? Je trouve que ça donne un aspect carrément différent à RM mais si y'a pas moyen de les garder, autant arrêter de bosser dessus pour l'instant.

Je pense que c'est ingérable. Ou alors c'est une telle prise de tête que ça vaut pas vraiment le coup (genre des interrupteur pour chaque event au sol en fonction de si on court/marche en diagonale, des tests de coordonnées pour déclencher quand même des event même si ça bug avec la course etoo... bref c'est jouable mais à la première erreur c'est foutu. Et le pire c'est que ce genre de truc ça passe très facilement inaperçu lors des debugs (sauf si c'est un vrai debug ultra sérieux où tu cherche à courir/marcher en diagonale partout pour tout faire planter mais après c'est du boulot de pro qu'on demande).

Je pense pas perso, il 'suffit' d'utiliser les coordonnées pour déclencher un event. Ça peut paraître long/chiant, mais je pense pas tant que ça, surtout que ça représente pas grand chose sur la création d'un jeu.

RÉSUMAY !!1

Kaila a écrit:

Les combats et les menus, non, il faut une certaine expérience pour faire des trucs potables.
Mais ça vaut autant pour XP et VX que pour 2k3.

Xiaoxiao a écrit:

Une fois que sous 2k3, il y a plus des possibilités pour les commandes d'un event, je pense qu'il est moins complexe de réaliser un système quel qu'il soit que sous VX ou XP (en utilisant uniquement les évènements)

Alors, comme l'a dit Ephy, je pensais à la difficulté de faire ce genre de système en général, pas seulement par rapport au nombre de commandes d'event disponibles. C'est très difficile de mettre un CMS ou un CBS au point.

Et puis même ! Pour créer un menu perso ou un système de combat perso, t'as juste besoin de:
- afficher / déplacer / supprimer une image
- utiliser des variables et des interrupteurs
- savoir gérer l'appui touche
- savoir faire des boucles et des conditions
- déplacer / animer des évènements
- lancer le menu de sauvegarde / l'écran-titre / le retour à la map, pour les menus
À partir de là, je ne vois absolument pas la différence entre XP, VX et 2k3 étant donné qu'ils proposent tous ces commandes...

Btw, sur 2k3, les commandes qu'il y a en plus par rapport à XP/VX, c'est:
- mémoriser la position / retour à la position (useless car elle ne fait que rentrer les coordonnées du héros dans 3 variables)
- inverser la position de 2 évènements (useless aussi car faisable avec des variables temporaires)
- modifier le chipset de la map (useless pour les CMS / CBS)
- modifier un carreau (encore useless ici)
- changer les commandes de combat (useless parce que ce n'est valable que pour le système de base)
Alors bon... je vois pas en quoi le fait qu'il y ait quelques commandes en plus soit un avantage étant donné que ce ne sont pas celles-ci qu'on va utiliser.

Hum, expliqué comme ça effectivement la différence pour la création de systèmes complexes frôle le néant.

Néan()moins, chacun dispose d'une méthode différente quant à l'élaboration de ce type de système. Il est donc possible que certaines commandes que tu accuses d'être inutiles ne le seront pas pour certaines personnes.

Mais je m'égare, je reconnais mes torts.

Bah, franchement, changer le chipset ou un carreau, c'est pas franchement utile... Quant au reste, c'est tout faisable avec 2 ou 3 variables temporaires.

Je reviens cette fois avec une méchante question qui me travaille.
Je suis dans cette situation là:

Le machin en bois sous lequel est le perso, c'est l'entrée de la ville (entrée qui se trouve au premier plan. A savoir, y'a 3 plan. le 1er qui est devant le perso, le second sur lequel se trouve le perso et le 3ème qui se trouve derrière). Bref pour sortir de la ville faut être dirigé vers le 1er plan (donc vers le bas pour RM) et appuyer sur espace pour sortir.

La question est, comment indiquer au joueur qu'il peut sortir de la ville par cette manœuvre (parce que c'est pas beaucoup facile à trouver par soi même) et ce sans expliquer ça façon tuto (sans expliquer comme je viens de le faire en somme) de manière à ce que ça puisse s'intégrer facilement dans le jeu.

J'attend des idées géniales!!1

Une petite aura lumineuse sur le sol pour les points de téléportations ?

Pour sortir de la ville on doit regarder vers le bas et faire espace en somme ?

Je sais pas, moi je trouve ça plus logeek de devoir regarder vers le haut et appuyer sur espace maybon...

Donc je te conseille un truc tout bête : quand le héros arrive sous la porte, tu affiche au dessus d'elle un truc animé bien sympathique, du genre une flèche vers le bas qui monte et descend et une touche espace qui se presse et se dé-presse.

Ou sinon tu fais un vrai jeu Old-School et t'explique pas tes commandes compliquées, histoire qu'on comprenne rien et que ton jeu passe chez le joueur du grenier.

Slup> J'y ai pensé mais ça fail un peu vu qu'on voit pas le sol


Bibi> oui je sais faudrait être vers le haut. Sauf que la map suivante se trouve devant l'actuelle.
Schéma:

______________ ____________ map actuelle
______________ ________________________________ map suivante

l'espace sur les lignes, c'est l'entrée. Si je fais comme ça mes téléportations c'est pour garder un minimum de repères spatial (et pour rentabiliser la touche bas aussi).

Sinon je fais comme Zelda 2. Un PNJ qui se dirige vers l'entrée, regarde vers le bas et disparaît

Ah oui, c'est très très étrange.
Effectivement, une petite flèche vers le bas animée, ça explique très bien et simplement.

Étrange en quoi? J'utilise juste deux sorties en plus par rapport aux jeux de plateforme (oui parce que là il s'agit pas d'un pur jeu de plateforme).

C'est pas ça qui est étrange, mais au niveau de la perspective, je me serais attendu à me tourner vers le haut. En toute logique, sans spécialement être IG, du moins.

Faut savoir que IG quand on passe au niveau des piliers de la porte ils sont devant le héros et pas derrière. Idem avec les portes dans les intérieurs.

D'accord, ça doit être plus pratique pour comprendre !
Malgré tout, je critique pas négativement, hein. J'ai simplement remarqué que ça me paraissait un peu étrange.

Citation :

Faut savoir que IG quand on passe au niveau des piliers de la porte ils sont devant le héros et pas derrière.

Bah alors il n'y a pas de problème, c'est assez compréhensible... Si tu vois ton perso passer derrière, tu comprends bien qu'il faut appuyer sur bas pour passer dessous.

Merci pour vos réponses. J'vais faire un mix de tout ça et ça devrais aller.


Sinon question. A votre avis, vaut mieux surcharger le jeu en mettant trouzemilles ressources pour les PM (cf screen du dessus, le machin entre le coeur et les stats) c'est à dire avec 54 pictures (une pour chaque étant de la barre de MP sachant quelle est à une unité au début et augmente au fur et à mesure de un en un) ou alors d'utiliser que deux images (unité vide et unité pleine) et d'utiliser donc 9 pictures dans RM sachant que y'en a déjà 33 affichées à l'écran en temps normal?

La seconde possibilité ne paraît-elle pas plus judicieuse ?
Après je ne sais pas laquelle des deux est plus facilement programmable.

Seconde solution. Afficher beaucoup d'images ne vas pas faire ramer le PC, et ça fera autant de Ko évités sur le poids final du jeu.

(alors que sur XP, un petit script et hop, une seule image importée dans le jeu, et aucune image d'event utilisée)

Quand on sait que sur Game Develop, un event, trois images et un seul objet par image suffisent pour programmer les MP, les HP et les caractéristiques en même temps... La deuxième solution est probablement plus judicieuse. Pas parce que ça fera moins lagger le jeu ou que ça rendra le jeu moins lourd (des images aussi minuscules avec une qualité pareille, onsanfou un peu) mais juste parce que c'est beaucoup plus "normal" (et skillé) d'utiliser la deuxième solution. Ça montre que tu gères en prog. Et c'est beaucoup plus important qu'on ne le pense.

Au pire de toute façon si je vois que c'est trop lourd pour RM je passe ça en valeur chiffrée. C'est moins classe mais au moins ça casse pas les burnes avec trouzemilles conditions.
Parce que là mine de rien, je vais me coltiner des tonnes de conditions (pire que ce que y'a déjà sachant que TOUT le jeu se passe sur les maps (c'est à dire, jeu+menu+combats) donc tout ce bazar qui tourne en même temps en parallèle avec de l'automatique etoo

(mais une chose est sûre, au moins tout ça ça claque (merci aux graphismes quoi). Et j'ai enfin réussit à faire un gameplay satisfaisant ET original. Plus d'infos bienToT).

Maintenant, need trouver un scénario

Pour pas que ça rame, soit tu mets en bmp et tu peux afficher direct, soit c'est en png et faut utiliser la fonction déplacer une image uniquement (en affichant les images juste au début du niveau, opacité 100).

Ah bon? Si on met en bmp ça rame pas? Je savais pas du tout ça... c'est bon à savoir.
Je sens que je vais convertir toutes mes images en bmp d'ailleurs.

Sinon j'ai trouvé comment résoudre mon problème. J'ai modifié un peu beaucoup mon système de magie pour faire un truc bien plus efficace et intéressant.

Rheu, c'est encore moi qui comprends rien à ce tuto. (sérieusement je sais pas si c'est moi ou le tuto ) :

C'est pour créer et éxecuter un programme Ruby:

Citation :

Attention ! Il faut que le fichier sous enregistrer dans le bon chemin (ce qui est encadrer en rouge) ! Pour changer la destination, tapez "cd " - suivi des dossiers "fils" - ou "cd ../" - suivi des dossiers "parents"-
Exemple :

C'est l'histoire des "cd" que je comprends pas. Il parle pas du "cx" mais il le mets dans l'exemple...


(tavu Ephy, dans la bonne section).

La commande cd c'est pour aller dans un dossier. Quant à cx, c'est un nom de dossier.

Ah les jeunes qui n'ont pas commencé sous MS-DOS