Discussions générales de making

Oui mais je me méfie. Puis enterbrain est champions des coups :
Coucou voici de super truc qu'on ajoute sur nos logiciels, mais on supprime ça par contre qui est super important !

J’espère que les panos visibles sont de la partie quand même.

À la différence qu'ici, le logiciel c'est RPG Maker VX Ace et non RPG Maker 2011 (ou 2012 ou autre).
Je ne vois pas pourquoi ils supprimeraient des fonctionnalités importantes de VX, qui a plus l'air d'une version bêta maintenant.
Je vois VX Ace comme une version améliorée de VX plutôt qu'un RPG Maker à part entière comme XP.
En espérant maintenant que ce tu dis ne se produise pas...

Je ne voyais pas non plus pourquoi ils auraient supprimé les fonctions d'XP tel que l'infinité de chipsets ou les background en combat lors de la sortie de VX
Quoiqu'il en soit, je dlerais cette version lorsqu'on aura une traduction stable, mais juste pour le plaisir d'avoir l'icone VX.Ace dans mon dossier making

Non mais t'as pas compris ma démarche en fait .

Pour moi VX, XP et 2k3 sont trois RM à part entière par exemple. Or, VX Ace ressemble plus à une maj de VX, une version finale de ce dernier si tu veux. Ils nous auraient nommé VX Ace autrement, j'aurais certainement été plus anxieux.

Après je me trompe peut-être.

Oué enfin suis-je le seul à pas me fier au nom des logiciels pour cause de maketing ? A vrais osef du nom. A ce petit jeu VX garde le même modèle que XP en supprimant des tas options.
Les options d’évènements sont basé sur XP avec des ajouts considérable à XP ou je veux dire des retours des options considérables vitale pour faire du RPG, et l’annihilation des trucs important.

J'ai aussi appris à me méfier. Après non je ne considère pas Vx comme une "béta" tout comme je ne considère pas Rm2000 comme une bêta de 2003. Ils ont loupé le coche avec les tilsets mais je en suis pas sur qu'ils ont loupé le coche chez les japonais avec VX.

Après ce n'est que mon avis . Il est vrai que je n'utilise pas du tout XP pour faire la comparaison, même si je connais les principales différences et que je trouve VX plus ergonomique.
Mais je n'ai jamais dit que je n'étais pas d'accord avec toi. On va dire que j'essaie de me convaincre qu'ils feront tout comme il faut pour cette fois .

Ce que j'ai vraiment envie de savoir, c'est comment les développeurs ont eus l'idée de limiter le nombres de tilesets ainsi que la taille par rapport à la version précédente. À quoi ça sert ? Pourquoi ?

Ils ont peut-être voulu viser un public plus large et plus jeune en simplifiant et rendant leur bébé plus "accessible".
Après je dis peut-être de la zutre.

Je plussoie, sachant que VX est très ergonomique en terme de mapping (gestion des relief et des ombres automatique etc...)
Mais ils ont du se rendre compte que ça avait un peu foiré

Xiaoxiao a écrit:

Ils ont peut-être voulu viser un public plus large et plus jeune en simplifiant et rendant leur bébé plus "accessible".
Après je dis peut-être de la zutre.

Mais en quoi ne pas limiter la hauteur d'un tileset va perturber un maker lambda ?

Bah moins de tiles à gérer et à comprendre (uniquement pour les RTPs), sinon je ne vois pas vraiment la raison. Peut-être par flemme qui sait (moins de RTPs à fabriquer après leur exploit sur XP) .

Les commandes d'évents ? Osef, y'a l'appel de script. C'est plus puissant que toutes les commandes d'évents réunies.
C'est pas si compliqué à comprendre, faut juste s'y mettre.

Au contraire, les RTPs de VX sont archi-compliqués, rien qu'à voir le nombre de sols différents
Prend ceux de 2000/2003 par exemple, il y a un tile d'herbe, un d'herbe hautes, un de terre, un de sable, un de neige et basta.
Alors que là y'a tout un système de liaisons, de tiles réservés à la worldmap, d'autres aux villages... Suffit de voir les screens des débutants

J'ai commencé sur VX aussi, c'est peut-être pour ça.

Zanghter > Ce n'est pas parce que tu es scripteur, que tout le monde devrait suivre ton exemple. Il faut de tout pour faire un monde, même des events makers sur VX.

Pense à ceux qui ont de l'urticaire dès qu'ils voient une ligne de code !

Présent o/
Mais je m'améliore...

Sinon, je trouve aussi que le mapping sur Vx n'est pas plus simple, surtout avec les RTP ; mais on peut aussi utiliser autre chose, je ne vois pas où est le problème...

Zangther a écrit:

Les commandes d'évents ? Osef, y'a l'appel de script. C'est plus puissant que toutes les commandes d'évents réunies.
C'est pas si compliqué à comprendre, faut juste s'y mettre.

Où peut-on apprendre le Ruby (ou RGSS) de manière claire ? J'aimerais bien m'y mettre, le Ruby doit pas être plus compliqué que le PHP...

Citation :

Je plussoie, sachant que VX est très ergonomique en terme de mapping (gestion des relief et des ombres automatique etc...)

J'appelle pas ça ergonomique. Le truc des ombres est un catastrophe, et je ne vois pas le truc des relief xd. Si c'est les auto-liant à la pagaille, je trouve ça emmerdant. Cela limite pas mal de chose même surtout quand il faut adapter des ressources divers ou du rips.

Citation :

Les commandes d'évents ? Osef, y'a l'appel de script. C'est plus puissant que toutes les commandes d'évents réunies.
C'est pas si compliqué à comprendre, faut juste s'y mettre.

Personnellement j'utilise RM (et MMF), c'est pour ça simplicité de faire un jeu grâce à ces events qui ne nous oblige pas à apprendre un langage de programmation ! L'erreur de Rm Xp n'est pas d'avoir introduit le Ruby qui est une bonen chose, mais d'avoir retirer les commendes évent de RM2003 en pagaille qui donne le force de faire des "systèmes" que nous voulons sans une once d'un langage programmation pour la plupart du monde.

Citation :

Où peut-on apprendre le Ruby (ou RGSS) de manière claire ?

Il n'y a rien de prévus pou les débutants de chez débutants qui veulent apprendre ça simplement. Souvent c'est va voir le site officiel qui te balance un cours magistrale sur la langage adéquate. xd

Xiaoxiao a écrit:

Ce n'est pas parce que tu es scripteur, que tout le monde devrait suivre ton exemple.

L'appel de script est la prolongation légitime des commandes d'évents. Ne pas vouloir l'utiliser parce que c'est des scripts c'est complètement débile.

Monos > Cf ci dessus. Juste comprendre le mécanisme des fonctions et pleins de portes s'ouvrent à toi. Ne pas vouloir apprendre et se plaindre de la limitation des évents, c'est être hypocrite.
A la rigueur, il faut comprendre un peu la programmation procédurale mais c'est un peu ce que tu utilises déjà avec les évents.
Les boucles sont bien mieux que dans les évents.
On peut aller plus loin, mais c'est pas forcément nécessaire. Suffit juste de vouloir apprendre et c'est simple.


Fresh > Faut d'abord comprendre l'OO et ensuite ce sera limpide. La syntaxe, c'est du gâteau.

De même que de ne pas vouloir utiliser de commandes d'event parce que c'est réalisable en script

Zangther a écrit:

Ne pas vouloir l'utiliser parce que c'est des scripts c'est complètement débile.

Ce qui a le don de m'horripiler ce sont les gens qui n'acceptent pas qu'on ne soit pas du même avis qu'eux et qui s'expriment de façon aussi piquante. Je ne m'étalerai pas plus sur le sujet, c'est du Zangther.

Enfin bref pour revenir à ce que je disais, tant que ce qu'a prévu le maker est faisable avec des commandes d'events, je ne vois pas pourquoi il faudrait ABSOLUMENT qu'il passe par l'appel de scripts. Mais ce dernier est utile pour combler certaines lacunes de l'eventing pure, je suis donc d'accord qu'il est impossible de tout réaliser avec les autres commandes même s'il n'est pas vraiment nécessaire de se mettre aux scripts pour ça. Je crois d'ailleurs que Monos avait écrit un tutoriel qui proposait certaines lignes de code très utiles pour l'appel de scripts, qui sont amplement suffisantes pour s'attaquer à la réalisation de systèmes plus ou moins complexes en events.

Mais à la façon de t'exprimer dans ce post

Zangther a écrit:

Les commandes d'évents ? Osef, y'a l'appel de script. C'est plus puissant que toutes les commandes d'évents réunies.
C'est pas si compliqué à comprendre, faut juste s'y mettre.

j'ai eu l'impression que tu imposais ton point de vue sans vouloir comprendre le fond de la pensée de Monos.

Citation :

Ne pas vouloir apprendre et se plaindre de la limitation des évents, c'est être hypocrite.

Sauf qu'il y a pas mal de gens qui n'arrive pas à scripter véritablement ou à apprendre ç scripter.coder avec un langage de programmation. Je dis ça car j'en fais partie et ce n'est pas faute d'avoir essayé. (J'arrive juste à faire de la simple bidouille dans certain script. Et c'est cool pour pas mal de chose)


Je vais prendre un raccourci mais dans mon cas je suis heureux d'avoir un évènement qui me change les panoramas que de devoir re fouiller le net ou mon cahier de note pour trouver la commande en ruby et installer un script à chaque fois que je fais des tests...
Je n'ai plus non plus de patience. Me balader sur différent site pour avoir un script qui permet d’appeler la programmation d'une page d’évènement pour le foutre dans une autre, ça me fais chier alors qu'elle existait en sur RM2003 cette commande. Passer / être tributaire d'un tiers pour faire les scripts que je veux, et les débugés, me saoul.

Ce n'est pas de l'anti-script car je suis le 1er à reconnaître les biens fait quand nous savons les réalisers, mais plus j'avance dans le temps (comme tout le monde) plus je préfère utiliser les fonctions native de RM et ne pas faire le jeu, un catalogue de script comme nous pouvons le voir dans 99% des jeux et dont j'ai fais aussi au début. Pour ça que j'attend VX.ace qui serait très certainement le RM que je voudrais.

-Sur VX, il y avait deux trucs qui me chagrinait, la gestion des tilsets qui me freiné. (Je pouvais passer avec les panos mais c'est très long surtout si tu veux faire du simple rip)
-A moitié corrigé car je pense que nous somme très loin de retrouver toute les fonctions de 2003/XP

-Un systèm de combat jolie avec Background en espérant que c'est réglable avec les zones, et des id de terrain comme sur RM2003 et non à la map comme XP !

-Le système de combat au tour par tour strict avec la compétence vitesses des compétences et objet en fait le meilleurs système de combat de RM (Hors 2003 qui est un autre style de combat avec l'atb) à mes yeux des RM 2000 et Xp. Cela représente ma vision des combat. (Juste dommage de pas voir les persos de coté mais bon). Alors oui souvent en me dit re fait ça aussi en événement, mais idem personnellement je n'ai plus le courage et l'envie de faire de la grosse programmation en évènement. Souvent c'est le châteaux de sable aussi xd.

Moralité, je suis un partisan de la nativité des options qui permette de faire un "RPG" normalement. Après libre à chacun de transformer RM avec des évent et Script pour changer les fonctions d'un RPG en autre chose ou ajouter des trucs inutiles comme des minis cartes xd.

C'est faux. L'appel de script n'est en aucun point de la réele programmation ruby et je ne parle que de l'appel de script.

Cette fonction porte très mal son nom. Il ne s'agit pas uniquement "d'appeler" un script. Il s'agit d'executer des morceaux de code en ruby.
Je suis désolé mais juste aux prix de fouiner un peu, demande de l'aide etc, tu peux faire des passes de choses.
La programmation en elle même n'est en rien différente des évents de base, c'est du procédural. Sans les étiquettes, parce que c'est de la merde.

Après, c'est sur, n'importe qui ne peut pas coder un système de combat complet. Ce qui est certain par contre c'est que toutes les personnes qui prétendent maîtriser les évents PEUVENT aller fouiner dans les scripts et voir comment on fait telle ou telle chose en script pour pouvoir appliquer ça dans un appel de script.
Si tu as vraiment envie d'apprendre, je peux t'aider à comprendre et à utiliser ces outils.

Tout n'est pas possible avec la commande appel de script, mais elle permet d'étendre ses action très très loin devant les évents.

Cela alors serait bien d'avoir des listes de commande qui peut aider les gens.
Mais il reste encore une différence qui est majeur. Les commandes scripts il faut les connaitre. ET surtout connaitre ça syntaxe. C'est plus ça que j'ai du mal personnellement. (J'ai déja du mal avec le syntaxe française).

Mais déjà référencer du code utile serait pas mal.

En parlant de syntaxe cela me fait dire un truc. Info qui vient de Rpg Créative et de leurs pages facebook.

Je savais qu'il était possible de customiser facilement les formules de combat. Je n'avais pas fait gaffe comment.

Sur les armes il y une ligne à expression pour entrer des formules et personnaliser des formules de combat propre au armes (et compétence je pense)

Bon points.
Mauvais points, c'est qu'il faut connaitre les termes utilisés dans les scripts ruby. (Enfin mauvais points suivant certaine personne, ce qui va m’obliger à me faire un ABCd'aire xd)

Abécédaire *

Par contre, je vois qu'il y a un petit bouton sous le champ où on entre la formule. C'est probablement un bouton qui renvoie sur un générateur d'expression. Ça m'étonnerait qu'on ait à rentrer du Ruby directement dans l'interface même de la base de données, ce serait pas assez user-friendly. Enfin, c'est ma déduction à moi, hein, je me trompe peut être.
Après, si Bibux était là il nous traduirait tout ça, mais bon...

Sinon, en ce qui concerne les appels de script... Ben... Je dirais que c'est pas compliqué du moment qu'on sait quoi écrire. La seule chose qui manque aux non-scripteurs, c'est la syntaxe, parce que la logique, tous les makers l'ont déjà grâce à la programmation évènementielle.
Ce que je dis ne vaut pas grand chose étant donné que je suis moi même scripteur, mais je rejoins Zang' quand il dit qu'il "suffit" de s'y mettre. Et comprenez bien qu'on ne parle que des appels de scripts, pas de la vraie programmation Ruby !
Il faudrait un récapitulatif des commandes utiles, mais comme ici on est tous des flemmards (et moi le premier), ben c'est dommage.

J'ai pas d'appel de script sur ma version de RM2k3 ='(

Je vais devoir continuer avec mes events