RM 2003 : script
RM 2003 : script
Bonjour ,
tout d'abord je tien à saluer tout le monde : cella fait depuis pas mal de temps que je n'ai pas traîner ici (pour ceux qui se le demanderaient , mon projet "Vhize Code Z-ro" avance toujours).
En fait voilà, je me demandais s'il y'avait un moyen d'avoir un "onglet script à la base de donnée"(ou quoi que ce soit permettant d'utiliser des scripts) dans RM 2003 et si oui comment , merci d'avance.
tout d'abord je tien à saluer tout le monde : cella fait depuis pas mal de temps que je n'ai pas traîner ici (pour ceux qui se le demanderaient , mon projet "Vhize Code Z-ro" avance toujours).
En fait voilà, je me demandais s'il y'avait un moyen d'avoir un "onglet script à la base de donnée"(ou quoi que ce soit permettant d'utiliser des scripts) dans RM 2003 et si oui comment , merci d'avance.
Signature à déterminer.
Hey dark ! =) Ça fait plaisir de te lire ! Je suis content que Vhize avance toujours, j'avais vraiment aimé la première partie !
Comme dit Chaos, les scripts ont été introduits à partir de RPG Maker XP et se sont développés davantage dans les versions suivantes (RPG Maker VX et VX Ace). Pour pouvoir faire des choses custom sur RPG Maker 2003, il faut passer par l'event. Le résultat peut être aussi efficace qu'un script s'il est bien "programmé".
Autrement, l'autre solution serait de passer à une nouvelle version de RPG Maker. Il y a le choix ! Mais, tout dépend de ce que tu souhaites créer.
Comme dit Chaos, les scripts ont été introduits à partir de RPG Maker XP et se sont développés davantage dans les versions suivantes (RPG Maker VX et VX Ace). Pour pouvoir faire des choses custom sur RPG Maker 2003, il faut passer par l'event. Le résultat peut être aussi efficace qu'un script s'il est bien "programmé".
Autrement, l'autre solution serait de passer à une nouvelle version de RPG Maker. Il y a le choix ! Mais, tout dépend de ce que tu souhaites créer.
Oui on avance tous bien.
Pas de scripts sur RM2003 mais quelques patch sont dispo pour booster, c'est pas autorisé par Enterbrain mais comme RM2003 non plus bah on s'en fou on est pas à ça prés si on fait un ptit jeu gratos perso.
Le mieux ce serait quand même de passer sur un RM plus récent et si c'est le feeling rétro que tu aimes, tu peux quand même importer des ressources plus rétro dedans et avoir le même feeling ou presque. (Darx y arrive très bien avec ses jeux qui simulent un feeling 8bits gameboyesque !)
Pas de scripts sur RM2003 mais quelques patch sont dispo pour booster, c'est pas autorisé par Enterbrain mais comme RM2003 non plus bah on s'en fou on est pas à ça prés si on fait un ptit jeu gratos perso.
Le mieux ce serait quand même de passer sur un RM plus récent et si c'est le feeling rétro que tu aimes, tu peux quand même importer des ressources plus rétro dedans et avoir le même feeling ou presque. (Darx y arrive très bien avec ses jeux qui simulent un feeling 8bits gameboyesque !)
heureux de voir que cela avance de votre côté alors ,
sinon les scripts c'est surtout pour pouvoir exploiter le logiciel au maximum , mais c'est vrai qu'avec des évènements biens
fichus on peut faire de même. Quand à vouloir faire un jeu "gameboyesque"(je ne sais pas pourquoi j'aime bien ce terme) , je vais d'abord finir mon premier projet avant de m'y lancer , j'ai encore pas mal de travail pour finir le chapitre 1 (prévu normalement dans 1-3 mois) , et il reste encore les 2 autres . Sinon bonne journée à tous.
sinon les scripts c'est surtout pour pouvoir exploiter le logiciel au maximum , mais c'est vrai qu'avec des évènements biens
fichus on peut faire de même. Quand à vouloir faire un jeu "gameboyesque"(je ne sais pas pourquoi j'aime bien ce terme) , je vais d'abord finir mon premier projet avant de m'y lancer , j'ai encore pas mal de travail pour finir le chapitre 1 (prévu normalement dans 1-3 mois) , et il reste encore les 2 autres . Sinon bonne journée à tous.
Signature à déterminer.
Roh Kayzou... Disons que je me démerde ! J'aurai pu faire la même chose avec RM2003, mais il aurait fallu que je programme certaines choses en event (moi et l'event avancé, ça fait 2). Pour ça que j'ai choisi VX au final.KaYsEr a écrit :(Darx y arrive très bien avec ses jeux qui simulent un feeling 8bits gameboyesque !)
Le plus important à retenir, c'est qu'il faut utiliser la version avec laquelle tu te sens le plus à l'aise.
Et il y a autre chose d'intéressant :
Oui ! Et puis crois-moi, les scripts ne permettent pas nécessairement d'exploiter le logiciel au maximum. Bon nombre de gens s'en servent, mais peu au final parviennent à montrer la maîtrise de l'outil. Le mieux, c'est de faire selon ses besoins et ses idées (sans vouloir se lancer dans quelque chose de trop compliqué pour ses propres capacités).dark03 a écrit :sinon les scripts c'est surtout pour pouvoir exploiter le logiciel au maximum , mais c'est vrai qu'avec des évènements biens
fichus on peut faire de même.
N'hésite pas à ouvrir un nouveau topic ou à remonter le précédent pour pouvoir donner des news de ton projet. Et puis, pour donner de tes news à toi aussi bien sûr, ça fait toujours plaisir (comme maintenant). =) Bonne journée à toi aussi et bon courage pour ce qui se prépare (j'attendrai sagement les nouvelles de ton projet) !
(Bonaniv Nuki?)
Wé ça risque d'être compliqué et bouffer du temps, c'est surtout pour les codeurs qui ont la motivation, celui qui est concentré sur son jeu ça risque surtout de lui faire perdre le focus. Si tu démarres un projet de zéro d'ailleurs bah faut quand même considérer ce qu'il y a de plus récent pour la situation la plus pérenne. (ptain comme ça s'écrit ça... Pet-Reine ? Paix-Renne...)
Wé ça risque d'être compliqué et bouffer du temps, c'est surtout pour les codeurs qui ont la motivation, celui qui est concentré sur son jeu ça risque surtout de lui faire perdre le focus. Si tu démarres un projet de zéro d'ailleurs bah faut quand même considérer ce qu'il y a de plus récent pour la situation la plus pérenne. (ptain comme ça s'écrit ça... Pet-Reine ? Paix-Renne...)
Mon avis est fortement contesté mais je vais tâcher d'être claire en tâchant de rester un minimum objectif.
Premièrement, il est vrai qu'on peut faire énormément avec le C++, que c'est un langage qui bénéficie d'une grosse communauté et qu'il existe des supers macros librairies.
Mais. Quand on apprend la programmation, je pense qu'il est nécessaire de faire face à des situations simples, que l'on complexifie au fur et a mesure. Le C++ comme beaucoup de langages orientés Objets de seconde génération force la manipulation de concepts très complexes. La notion même d'objet, la notion de types dérivés des objets et les factorisations liés à la spécification raffinées de ces objets. (Parce que le fait de faire du générique avec l'objet est un mythe, au plus on avance, au plus on spécialise ses objets pour les transformer en objet métiers, donc plus complexe à maintenir).
Historiquement, le C++ arrive après la mise en lumière de mécanismes de modularité performant grâce aux objets de SmallTalk ou de Eiffel et les développeurs se disent qu'ils vont associer ces mécanismes à un langage matûre et qui offre pleins d'opportunités de compilation : le C.
Le soucis, c'est qu'a force de vouloir répondre "à tout", le C++ est devenu une usine à gaz verbeuse. On a vu la naissance de l'extremProgramming et de la métaprogrammation sur domaine compilé et la naissance des templates, qui complexifie tout raisonnement de code. A ça tu ajoutes une syntaxe très complexe à parser, donc à étendre (il a fallu beaucoup de mal à C++ pour intégrer les Lambdas Expressions, appelé, injustement, en C++ des foncteurs) et qui sort des messages d'erreurs... généralement illisibles.
Le système de type (et j'adore les systèmes de types) est louffoques, notamment dans certains cas de fermetures et cette envie d'occulter les pointeurs au profit des références (comme java, ruby, python) a été mal abordé, ce qui a donc donné naissance à une bouillie au niveau des pointeurs/références. On peut aussi montrer l'héritage multiple du doigt, et rire... et un modèle objet qui n'en n'est pas un et qui a souvent été mal copié (l'exemple le plus flagrant étant l'objet de PHP... lol).
Bref, pleins de choses que je trouves très/trop compliquées pour en faire un véritable langage convaincant, et j'inviterais toute personne désireuse de faire du "bas niveau" de rester sur C qui à le mérite d'être honnête vis à vis de son paradigme, qui demandera moins d'investissement dans l'apprentissage. Ou alors, le tout récent D, encensé par Carmack ! Qui est un peu dur à apprendre mais qui refait "bien" le C++.
Pour les Appleux, on pourrait aussi citer Objective-C, qui s'inspire de SmallTalk mais je ne connais pas bien ce langage.
Par contre, si tu es désireux de te dépayser, tu peux aussi t'essayer à la programmation fonctionnelle. Pour plusieurs motifs, le premier étant que la programmation fonctionnelle insiste sur la rigueure et que tout ce que l'on fait à généralement une explication rationnelle. On peut ajouter que si on prend la programmation fonctionnelle comme un "état" et non comme "une collection de langage", il se greffe de plus en plus dans les langages qui se modernisent (Ruby => Bloc, Proc, Lambda, Python => Lambda, Methode callable, JS => Functions as prototype, Java => Lambda expression, Foncteurs, C# =>Linq, Lambda, Delegate et même C++ et ses foncteurs/lambdas) et que si la programmation fonctionnelle est un peu la source des langages modernes, c'est aussi son futur, comme le prouve l'évolution des langages actuellement.
Je conseil généralement OCaML qui a un système de type extrêmement rigoureux mais qui est moins "abrupt" que Haskell.
Si tu as des questions ou des objections, je me ferais un plaisir d'y répondre (ou de m'excuser).
Premièrement, il est vrai qu'on peut faire énormément avec le C++, que c'est un langage qui bénéficie d'une grosse communauté et qu'il existe des supers macros librairies.
Mais. Quand on apprend la programmation, je pense qu'il est nécessaire de faire face à des situations simples, que l'on complexifie au fur et a mesure. Le C++ comme beaucoup de langages orientés Objets de seconde génération force la manipulation de concepts très complexes. La notion même d'objet, la notion de types dérivés des objets et les factorisations liés à la spécification raffinées de ces objets. (Parce que le fait de faire du générique avec l'objet est un mythe, au plus on avance, au plus on spécialise ses objets pour les transformer en objet métiers, donc plus complexe à maintenir).
Historiquement, le C++ arrive après la mise en lumière de mécanismes de modularité performant grâce aux objets de SmallTalk ou de Eiffel et les développeurs se disent qu'ils vont associer ces mécanismes à un langage matûre et qui offre pleins d'opportunités de compilation : le C.
Le soucis, c'est qu'a force de vouloir répondre "à tout", le C++ est devenu une usine à gaz verbeuse. On a vu la naissance de l'extremProgramming et de la métaprogrammation sur domaine compilé et la naissance des templates, qui complexifie tout raisonnement de code. A ça tu ajoutes une syntaxe très complexe à parser, donc à étendre (il a fallu beaucoup de mal à C++ pour intégrer les Lambdas Expressions, appelé, injustement, en C++ des foncteurs) et qui sort des messages d'erreurs... généralement illisibles.
Le système de type (et j'adore les systèmes de types) est louffoques, notamment dans certains cas de fermetures et cette envie d'occulter les pointeurs au profit des références (comme java, ruby, python) a été mal abordé, ce qui a donc donné naissance à une bouillie au niveau des pointeurs/références. On peut aussi montrer l'héritage multiple du doigt, et rire... et un modèle objet qui n'en n'est pas un et qui a souvent été mal copié (l'exemple le plus flagrant étant l'objet de PHP... lol).
Bref, pleins de choses que je trouves très/trop compliquées pour en faire un véritable langage convaincant, et j'inviterais toute personne désireuse de faire du "bas niveau" de rester sur C qui à le mérite d'être honnête vis à vis de son paradigme, qui demandera moins d'investissement dans l'apprentissage. Ou alors, le tout récent D, encensé par Carmack ! Qui est un peu dur à apprendre mais qui refait "bien" le C++.
Pour les Appleux, on pourrait aussi citer Objective-C, qui s'inspire de SmallTalk mais je ne connais pas bien ce langage.
Par contre, si tu es désireux de te dépayser, tu peux aussi t'essayer à la programmation fonctionnelle. Pour plusieurs motifs, le premier étant que la programmation fonctionnelle insiste sur la rigueure et que tout ce que l'on fait à généralement une explication rationnelle. On peut ajouter que si on prend la programmation fonctionnelle comme un "état" et non comme "une collection de langage", il se greffe de plus en plus dans les langages qui se modernisent (Ruby => Bloc, Proc, Lambda, Python => Lambda, Methode callable, JS => Functions as prototype, Java => Lambda expression, Foncteurs, C# =>Linq, Lambda, Delegate et même C++ et ses foncteurs/lambdas) et que si la programmation fonctionnelle est un peu la source des langages modernes, c'est aussi son futur, comme le prouve l'évolution des langages actuellement.
Je conseil généralement OCaML qui a un système de type extrêmement rigoureux mais qui est moins "abrupt" que Haskell.
Si tu as des questions ou des objections, je me ferais un plaisir d'y répondre (ou de m'excuser).
Non, j'ai pas vraiment d'objections, ça reste plus "correct" dans l'explication que ton "Le C++ c'est de la merde." qui a fait fuir Watchinofoye il y a quelques années héhé
J'admet que certains concepts en C++ c'est un peu le bordel, surtout en apprenant à base de tutoriaux genre OpenClassroom ( anciennement Site Du Zéro ). J'essaye de chipoter pour faire un moteur 2D un minimum utilisable et je t'avoue que parfois je me prends la tête sur des choses "bêtes" car y'a tellement de trucs à penser genre les paramètres que tu vas passer, bien gérer les classes et objets et faire de l'héritage pour optimiser le bordel, puis te rendre compte que finalement comme t'as procédé, ça fout tout en l'air de l'autre coté, et finalement tu passes 3h sur une fonction qui fonctionnait mais qu'au final t'as du réécrire car t'as changé un p'tit truc ailleurs...
Bref un gros merdier par moment, mais dans l'ensemble ça me dérange pas trop.
Le problème dans ta réponse c'est qu'il y a beaucoup de choses que tu abordes que je ne connais pas/comprends pas, comme par exemple la partie sur la programmation fonctionnelle. ( Après, c'est p'tet aussi que à part comment programmer un peu au pif en C++, je connais pas grand chose niveau langage )
J'admet que certains concepts en C++ c'est un peu le bordel, surtout en apprenant à base de tutoriaux genre OpenClassroom ( anciennement Site Du Zéro ). J'essaye de chipoter pour faire un moteur 2D un minimum utilisable et je t'avoue que parfois je me prends la tête sur des choses "bêtes" car y'a tellement de trucs à penser genre les paramètres que tu vas passer, bien gérer les classes et objets et faire de l'héritage pour optimiser le bordel, puis te rendre compte que finalement comme t'as procédé, ça fout tout en l'air de l'autre coté, et finalement tu passes 3h sur une fonction qui fonctionnait mais qu'au final t'as du réécrire car t'as changé un p'tit truc ailleurs...
Bref un gros merdier par moment, mais dans l'ensemble ça me dérange pas trop.
Le problème dans ta réponse c'est qu'il y a beaucoup de choses que tu abordes que je ne connais pas/comprends pas, comme par exemple la partie sur la programmation fonctionnelle. ( Après, c'est p'tet aussi que à part comment programmer un peu au pif en C++, je connais pas grand chose niveau langage )