Défi event : [Menu full event]

Danna-K a écrit:

Citation :

Et du code c'est quoi ?
Et Suite d'instruction et chaine d'instruction c'est identique.

Faux. Dans un event la " chaine d'instructions " est liée par une variable ou un switch (maillons de la chaine) que l'on peu actionner en positon ON ou OFF.

Alors que toutes les informations contenues dans une seule et même page, ne sont que " des suites d'instructions "

- Chaine d'instructions = Déroulement horizontal/nombre de pages dans un event
- Suite d'instructions = Déroulement verticale/suite d'instructions dans une seule et même page.

... bref rien avoir, tous comme les instructions données " a un logiciel " (dans le cas d'un logiciel WYSIWYG ou de l'event making) n'on rien avoir avec celles données au code (langage, ou Scripte) " a une machine " (le pc).

C'est un peu comme comparer le mouvement d'une main qui manipule un objet (habileté/WYSIWYG), et le chemin qu'il y a entre le cerveau et la main (intellect/code).

Euh non, vraiment pas.
De plus, l'environnement d'event making de RM n'est pas du tout WYSIWYG et n'est aucunement comparable.
Une chaine est une suite par définition, applique le à n'importe quel autre chose qui utilise ce concept et tu verras.
L'event making c'est du code parce qu'il s'agit d'un ensemble d'instructions, de données dynamiques, de foncteurs. C'est juste que sa syntaxe n'est pas factorisable. Mais il s'agit de code. Je veux bien admettre qu'on aie pas les même systèmes de références mais ce n'est pas pour ça qu'il faut dire des inepties...


EDIT:

Citation :

... bref rien avoir, tous comme les instructions données " a un logiciel " (dans le cas d'un logiciel WYSIWYG ou de l'event making) n'on rien avoir avec celles données au code (langage, ou Scripte) " a une machine " (le pc).

Sauf que c'est faux, tu ne communiques pas avec la machine quand tu script mais bien avec un logiciel, embarqué dans RM. Donc non.

EDIT2:
Et si on suit cette logique, aucun langage de programmation n'est le "chemin vers" puisque tout programme est abstrait et concretisé par un système d'exploitation ou du bytecode propre au matériel.

Citation :

Une chaine est une suite par définition

... non en Event making une suite n'a pas besoin de maillons (switch) pour être relié, sinon tu ne pourrait pas réaliser un simple coffre. Car a chaque fois que tu l'ouvrirait, tu prendrait le même objet a l'infini.

... en code peu être mais pas en event making, ne confond pas tout.

Citation :

l'environnement d'event making de RM n'est pas du tout WYSIWYG

... bien sur que si puisqu'il surfit d’appuyer sur le gros triangle vert pour tester son jeu (WYSIWYG = What you see is what you get = ce que vous voyez est ce que vous obtenez).

En plus y'a même une interface graphique ainsi qu'un truc qui s'appelle " Event Commande " tiens tiens comme c'est bizzard ... ^^

.... mais pourquoi ait-je l'impression subitement que vous prêchez pour votre chapelle

Danna-K a écrit:

Citation :

Une chaine est une suite par définition

... non en Event making une suite n'a pas besoin de maillons (switch) pour être relié, sinon tu ne pourrait pas réaliser un simple coffre. Car a chaque fois que tu l'ouvrirait, tu prendrait le même objet a l'infini.

... en code peu être mais pas en event making, ne confond pas tout.

Citation :

l'environnement d'event making de RM n'est pas du tout WYSIWYG

... bien sur que si puisqu'il surfit d’appuyer sur le gros triangle vert pour tester son jeu (WYSIWYG = What you see is what you get = ce que vous voyez est ce que vous obtenez).

En plus y'a même une interface graphique ainsi qu'un truc qui s'appelle " Event Commande " tiens tiens comme c'est bizzard ... ^^

.... mais pourquoi ait-je l'impression subitement que vous prêchez pour votre chapelle

Non mais n'importe quoi.
Le principe même de cette relation ne repose pas sur des maillage explicite.
Et non l'IDE d'event RM n'a rien de WYSIWYG.
Parce que tes séquences de code ne sont absolument pas le reflet de ce que tu verras Ingame.
Ca ne te réussis pas de parler de sujets que tu ne connais pas.

VAZY LA !! j'avais fais un putain de texte pour contredire Danna -K et il s'est pas enregistré !!!
Trop la loose.

M'enfin danna-k, as tu seulement déjà programmé ?
ne serais ce qu'un langage tout pourrie ?

Car tout ce qu'on retrouve en event making, on le retrouve dans n'importe quel langage.
Moi je ne vois aucune ( bien grand mot ) différence entre l'event et la prog'.

Donc avant de parler, renseigne toi sur le sujet au lieu d'affirmer des trucs qui ne sont pas à ton avantage

Moi je vois plus les commandes events comme des raccourcis. En gros, ce sont des fonctions pré-faites qui n'attendent qu'à être appeler et à être exécuter.
Pour simplifier ma pensée, l'event making, c'est de la programmation possédant une interface (boutons commandes) et des raccourcis (les commandes) mais dont l'accès est limité (on a pas la possibilité de faire ses propres fonctions) à causes des ces raccourcis. Exemple concret: RM2k0/3. (RMxp/vx, là on nous a donné cette liberté.)

Enfin, moi je le vois comme ça.

Les RPG maker (Tsukuru) sont des moteurs de jeu (logiciel de création de jeu), et pas une interface graphique pour Rubiste. Je vous rappel tous de même qu'il s'agit d'un défit a réaliser en event a la base (réalisation d'un menu).

Je vais faire le point sur le débat:

Il y a la réalité définie par les standards, celle que Grim a exposé, et, quoi qu'on en dise elle est tenue comme la rééle définition de l'event making ou du moins la plus proche. Mais il ne faut pas oublier la vision des principaux intéréssés: Ceux qui ne programment pas et ne programmeront peut être jamais. (Je parle de lignes de codes tapées)

Etant un event maker convaincu et ayant des résistances à la programmation, même si je m'y suis essayé de manière plus ou moins correcte, ma vision personnelle des choses tend plus vers le point de vue de Danna-K.

Pour moi l'event making n'a rien à voir avec de la programmation dans la manière d’interpréter et de placer les choses.

Quand je code, je dois faire appel à ma mémoire ou a un support d'aide mémoire, et celà pour chacune des lignes que je tappe. J'utilise donc des références déjà écrites par d'autres et fonctionnelles, et eventuellement, dans un moment de folie, je tente mon propre code en m'inspirant du principe. Je ne fait pas forcément appel à ce que je vais appeler "ma logique". j'applique juste betement un process que je sais bon. C'est le niveau le plus bas du codage, mais c'est le seul dont je suis capable à ce jour et celà certainement pour longtemps malgrè tout mes efforts.

Quand je fait de l'evenementing, j'utilise très peu ma mémoire. Je n'utilise pas non plus de notes, mais mon cheminement logique. Je me souviens donc pas de l'exact résultat, même si j'en ai une vision globale. C'est là pour moi la différence fondamentale entre coder et evenementer. Quand j'event, j'utilise bien plus des faits avérés du type: "Ceci fonctionne comme ca" à tel point que j'ai découvert il y a peu de temps qu'une fonction event que je considérait comme acquise.
Un event maker, c'est quelqu'un qui raisonne sous un système de pensée basé sur quelque chose qui parait logique quand on la voit fonctionner.

Toutes fois, un code pur est logique en soit, oui, mais on doit se souvenir de l'exactitude du code sous peine de planter celui ci (Ce qui explique pourquoi j'insiste fortement sur la création d'un listing de codes prets à l'emploi pour le scripting).

Il est difficile de comprendre pour un programmeur qu'un event maker soit si peu enclin à passer le pas de la programmation. Mais c'est parce qu'un bon programmeur pourra utiliser sa façon de travailler pour evenementer et sera logiquement un bon evenementeur.

Parcontre, vu le système de logique d'un evenementeur, même un excellent evenementeur ne sera pas obligatoirement bon programmeur, voir même (si on prend mon cas) un programmeur de bas étage quels que soit les efforts qu'il réalise pour cela.

Pourquoi? Parce que l'on ne fait pas appel aux mêmes façons de travailler. J'ai déjà essayé, plusieurs fois de faire comprendre ce concept à beaucoup de scripteurs, aucun à ce jour n'a saisi la différence.

Pour moi parler de ce genre de detail n'a aucun sens car la vision de part et d'autre n'est pas la même, ce qui est normal. Acceptons donc que chacun puisse avoir sa vision des choses et passons à l'essentiel: Apprendre et progresser, puis montrer son talent.

Citation :

et pas une interface graphique pour Rubiste

Ne me fait pas dire ce que je n'ai pas dit. A aucun moment j'ai dis que rpg maker était une interface graphique pour programmeur.

Apparemment tu ne m'as pas compris...

J'ai dis que les commandes étaient comme des raccourcis qui appellaient les fonctions dans le programme du logiciel. J'ai dis interface graphique, dans le sens où ça permet à l'utilisateur de repérer les divers commandes (donc les boutons).

Pour RMxp/VX, le log nous permet de passer outre l'eventmaking pour passer directement au scripts.

Citation :

et pas une interface graphique pour Rubiste

Je ne parlait pas de toi mais de Jin et de Grim pour qui ça semble être le cas.

Les commandes ca sert surtout a éviter d'avoir a écrire du code (se salir les mains)

Citation :

Pour RMxp/VX, le log nous permet de passer outre l'eventmaking pour passer directement au scripts.

... tous dépend si ton but c'est de modifier RM, ou de t'en servir pour créer des jeux.

... et sinon vous en êtes ou de votre menu en event, pour ma part je rame comme un malade ^^ Disons que j'avance lentement (j'attaque a peine la gestion des objets) mais surement. Faut dire le le concept même de mon menu (affichage de plusieurs blocs) , ne me facilite pas la tache en terme de réalisation.

Citation :

Je ne parlait pas de toi mais de Jin et de Grim pour qui ça semble être le cas.

Okay, bah précise à qui tu parles sinon on part dans un quiproquo x).

Pour ma part, l'inventaire est quasi-opérationnel (avec l'utilisation de certains objets mais je pense avoir fait le plus chiant concernant l'inventaire).

Nan mais lidenvice ce que tu dis est bidon xD

Tu dis limite qu'en event makign tu n'as pas besoin de réfléchir.
Mais en programmation c'est bien pareil.

Moi pour ma part, faire un page web qui communique avec la base de donné, je sais le faire sans même réfléchir. car je sais comment faire à force de travailler.

Moi l'event making je trouvais ca complexe au début, et à force d'en faire bah c'est devenu ( pas facile ) mais plus aisé.

Même si RM nous propose une programmation simplifié part une certaine interface, il n'en ai pas moins que de la programmation.
La logique programmatoire est la même, et si tu te loupe dans ton code event eh ben tu peux tout faire planter aussi !
La preuve j'ai abandonné mon CMS xD

Je sais pas si je suis clair (j'ai beaucoup de mal à m'exprimer aujourd'hui x) )

Danna-K, je ne comprend pas pourquoi tu spécules sans arrêt sur des choses que je "penserais" ?
La question n'est pas au ressentit, l'event making est une forme de programmation et il ne faut pas chercher plus loin.
Pourquoi, parce qu'il s'agit d'une grammaire formelle (donc régie par des règles) et qui fonctionne selon la logique assignation/effet.
Il s'agit d'une programmation en tout cas séquentielle tendant vers le procédurale, avec quelques aspects de programmation parallèle. En somme, de la programmation impérative a effet de bord.
Pour en revenir a ce que dit Lidenvice, la mémoire n'a rien a faire dans ce débat, car il faut comparer ce qui est comparable.
Si tu programmes dans un langage a effet minimaliste avec la référence sous les yeux, tu programmes et pourtant ta mémoire ne te fait pas défaut.

Je ne veux pas me mettre tout le monde a dos et passer pour désagréable, mais je trouve ça un peu déplorable, au nom d'un rang (et je suis d'accord que je te dois le respect Danna-K), de donner des avis si péremptoire en ne se reposant, au final, que sur du ressentit et pas sur de la théorie.

En bref, referons nous à Wikipedia:

Citation :

Un langage de programmation est un langage informatique (Turing-complet) 1, 2, permettant à un être humain d'écrire un Programme (informatique) (le code source) destiné à être exécuté par une machine, généralement un ordinateur. Le code source subit une transformation ou une évaluation dans une forme exploitable par la machine, ce qui permet d'obtenir un programme exécutable. Les langages permettent souvent de faire abstraction des mécanismes de bas niveau de la machine, de sorte que le code source puisse représenter une solution telle que comprise ou conçue par un être humain.

Dans ce cas, la machine peut être considérée comme Game.Exe (car il ne parle d'ordinateur qu'en terme de généralité), et l'event making est au final parsé par Game_Interpreter (ou Interpreter sous XP) et exécuté.

Citation :

D'un point de vue mathématique, un langage de programmation est un langage formel construit sur un alphabet (ensemble de symboles). Dans cet alphabet, on trouve plusieurs choses :

des lettres et des chiffres ;
des mots-clés (combinaisons de lettres et parfois de chiffres) ;
des caractères :
correspondant à des opérateurs : par exemple « = », « < », « & » ;
ou pas, comme « { », « _ », …

L'assemblage de ces symboles forme les « mots » du langage de programmation. Pour qu'un mot appartienne au langage, il doit vérifier certaines contraintes exprimées grâce à la théorie des langages dans une grammaire formelle : c'est la « syntaxe » du langage de programmation.
En associant une sémantique – généralement une opération – à chaque mot, on définit le comportement de la machine. La mise en relation de mots va donner un programme informatique.

On verra que cette analyse de la programmation s'applique parfaitement à RPG Maker.

On peut aussi conclure en parlant du rôle des commentaires qui facilite le raisonnement d'une application en Events, qui ont le même role que ceux de ce que vous appellez "un vrai langage de programmation".

On ne peux comparer taper des lignes de codes et utiliser des boutons pour obtenir un resultat.

Et si je créais un programme qui, en appuyant sur des bouton faisais apparaître directement le code dans le fichier ? et toi tu ne verrais qu'une image ? C'est exactement ce que je fait avec FlowCode pour mes microcontroleur, j'écris un algorithme, que je traduit en algorigramme pour le programme, qui vas alors générer le code C correspondant (pour microcontrôleurs).

Pourquoi cela n'existe pas pour un langage tel que le C (avec bouton) et qu'il existe pour l'event ? C'est parce que le nombre de fonction possible en C est incommensurable, alors que très limite (en quantité) pour l'event.

Tout simplement

Au pire, on peut créer un topic sur le sujet (à moins qu'il a déjà été créé) et en discuter ailleurs qu'ici, non?

Citation :

On ne peux comparer taper des lignes de codes et utiliser des boutons pour obtenir un resultat.

Détrompe toi mon jeune ami ( un peu plus vieux que moi tout de même )

Et vous pourrez demandé à n'importe quel programmeur, ils vous sortirons la même chose que nous ici.

tout le monde crois que la programmation c'est des lignes de 15 pieds de long, un gros charabia que personne comprend.
Ce qui est totalement faux.
Programmer c'est avant tout faire un programme ( si on en suit la logique du mot)
Quand on écrit une code php ou C peu importe, on créer un systeme, une page ou n'importe quoi d'autre.

Sur rm c'est pareil, tu balance des suite d'insctruction ( comme l'a dit danna k ) tout comme en programmation.

et je voulais dire un truc capitale qui aurait changé le cour de cette convers, mais j'ai oublié ...

Donc on en reste sur un texte pas fini !

Des events sont des events. Perso je vois pas, mais alors pas du tout l'intérêt de savoir à quel point c'est proche d'un langage de programmation. Ça ne va pas nous avancer en quoi que ce soit.

Faites attention à ne pas trop débattre quand même, y'a comme qui dirait quelque chose à rendre dimanche en huit.

Nan mais je suis d'accord avec toi, mais nous ça nous gonfle les gens comme danna-k qui affirme des choses don il est totalement ignorant.

Bah, c'est à rendre le dimanche du week-end prochain.

Citation :

Tu dis limite qu'en event makign tu n'as pas besoin de réfléchir.
Mais en programmation c'est bien pareil.

Par contre Jin, quand tu dis qu'il n'y a pas besoin de réfléchir pour la programmation, je suis mais pas du tout d'accord.

L'algo ne va pas se faire tout seul, faut bien réfléchir à comment procéder.

Parce que au pire, si pour un système de combat complexe (en ruby) comme un A-RPG par exemple, on a pas besoin de réfléchir, fais-en nous un =).

Moi ça me gonfle pas vraiment, c'est juste une bonne occasion de débattre

Danna-K me rappelle ce fameux dicton:
"La culture (ou les connaissances) c'est comme la confiture, moins t'en as plus tu l'étales."

Concentrez-vous plutôt sur vos CMS.

Vous savez quelle est la profondeur d'un panier de basket ?

C'est 3 il me semble

Merci, je dormirais mieux cette nuit. ^^

Citation :

Par contre Jin, quand tu dis qu'il n'y a pas besoin de réfléchir pour la programmation, je suis mais pas du tout d'accord.

C'est pas ce que j'ai voulus dire ^^
C'est l'inverse que j'ai voulu faire comprendre, mais c'pas grave ^^

Quand je pense qu'a l'origine c'est le mot "coder" qui a soulevé ce débat.
Et que:
http://fr.wikipedia.org/wiki/Codage
http://dictionnaire.phpmyvisites.net/definition-Coder-9213.htm
http://fr.wikipedia.org/wiki/Code

C'est devenu "qu'est ce qu'est un programme?"
Et que:
http://fr.wiktionary.org/wiki/programme
http://fr.wiktionary.org/wiki/programmer
http://fr.wikipedia.org/wiki/Programmation_informatique
http://dictionnaire.reverso.net/francais-definition/programmer
http://fr.wikipedia.org/wiki/Langage_de_programmation

D'un autre côté si je dis: je programme ma journée de boulot, je programme le micro-onde, je programme de l'event, un terme plus approprié serait judicieux.
Comme: Je planifie ma journée, je lance un des programmes du micro onde ou je fait de l'evenementing.

J'ai totalement compris les propos de Jin et de Grim, mais étrangement Jin me dit que mes propos son bidons et Grim a été relativement clair sans même comprendre l'etendue de la nuance.

J'ai bel et bien dit dans mon post que la vraie définition de programmer est celle de Grim et là je le met en gras et souligné. Et j'edite mon post en question pour mettre en gras et souligné la partie où je dis que Grim a raison.

Mais après, coder, programmer, dans le langage courant concerne quand même un type de programmation particulier. Pour le reste, d'autres mots ou synthaxes sont quand même plus pertinantes et représentatives.