Le Deal du moment : -20%
(Adhérents Fnac) Enceinte Bluetooth Marshall ...
Voir le deal
199.99 €

Aller en bas
Anonymous
Invité
Invité

Orienté Objet et structure des données dans les JV Empty Orienté Objet et structure des données dans les JV

Dim 30 Déc 2018 - 19:49
Orienté Objet et structure des données dans les JV

Oye, je repop dans les sections débats après un ptit de bout finalement \o/ (Qu'on ne vienne plus me dire que je fais plus de pavé après ça é_è)
Mais pour le coup avec un débat un peu technique x). Je précise d'emblée que je suis un peu à ma limite aussi niveau technique mais que je m'intéresse à la question, ne serait-ce que parce que je veux faire du game design et que forcément les données à implémenter sont relatives aux objets du jeu (donc que c'est un peu important à comprendre au moins dans les grandes pour discuter avec les programmeur) ainsi que pour faire peut-être des mini-jeux pas trop complexe. MAIS en aucun cas, je ne suis un expert en progra xD. Donc mes excuses en avance si je sort de grosses conneries x).

Comme dit dans le titre donc, je me suis fait trigge par un article sur gamedev "The faster you unlearn OOP the better for you and your software" qui argumentait contre l'utilisation de l'orienté-objet pour divers raison à savoir principalement:

  • L'OO n'encourage pas, de par sa nature d'une certaine manière, à bosser suffisamment sur la structure des données et donne toujours la possibilité d'ajouter des trucs ce qui aboutit généralement à un bordel sans nom.
  • L'encapsulation, c'est beau en théorie mais en pratique, c'est la merde What a Face. Il faut toujours rajouter des trucs pour faire des ponts.
  • L'OO nécessite une organisation des données inflexible (de part par la structuration en classe) et c'est pas pratique de pas pourvoir manipuler les données de plusieurs manières.
  • Le tout produit de mauvaise performance =x.

Bref, la structure des données en OO, s'pas top et et il faudrait l'oublier ces mauvaises manies au plus vite pour aller voir ailleurs o/

De l'autre côté, j'ai lu un peu les commentaires plus un article "OOP is dead long live OOP" qui était link en bas et de ce que j'ai compris, dans l'opposition, on a:

  • La structure des données est importante en effet. Mais si, ça merde autant, c'est justement parce que vous la bossez pas assez et que vous respectez pas les règles basiques de l'OO (souvent en faisant une sur-utilisation de l'héritage) puis comme des moutons, vous switchez sur l'ECS par facilité  Orienté Objet et structure des données dans les JV 844836
  • Et que les problèmes suivants résultent de ce problème initiale o/.


Bref, v'là un peu ce que j'ai compris des points principaux du débat x). Perso, j'ai l'impression de me reconnaître un peu dans les arguments contre dans le côté bordel et inflexibilité de l'organisation des données. Pour l'inflexibilité, notamment lorsque j'ai voulu réfléchir sur une internationalisation des textes sous RM et qu'on m'a répondu merdouille vu que les textes sont dispatchés un peu partout :v. M'enfin si j'ai bien et que c'est un peu le même problème :3.
Mais dans un autre point de vue, c'est pt parce que c'est mal foutu tout court et qu'il y a moyen de régler ça facilement de manière générale o/. Pour le coup, cette phrase m'a fait tiqué : "There's common beginners questions like "which class should I put this data in?", which is often answered in vague terms like "you just need to gain experience and you'll know by feel"...  "
Et là, j'ai l'impression de bien me reconnaître XD. Notamment quand j'avais voulu test un peu la progra objet x). Et la plupart des tutos ne me donnait pas vraiment la réponse... :v
Bon aujourd'hui, je cherche plus vraiment et je m'intéresse surtout au niveau game design (sauf pt un peu pour tenter des jeux simples. Et à tout hasard, si vous avez des exemples sur le cas d'un platformer, je suis preneur. À tout hasard bien sur ) mais ça m'intéresserais quand même de savoir un peu votre avis là dessus =p (pour la raison précédente et aussi pour savoir un peu mieux comment penser le game design en relation avec la progra comme précisé au tout début). Du coup, y a un peu de grains à moudre et si vous voulez rentrer un peu dans du technique pour vous faire plaise, hésitez pas (m'enfin pas trop quand même qu'on puisse suivre hein xD).

Bon maintenant, tout cela est dit, Come and Fight! \o/
Orienté Objet et structure des données dans les JV Warhammer_fantasy___orc_big__un_by_getsugadante-d9rlhk5
é_è

Même si je doute qu'il y ait beaucoup de monde intéressé par ce type de débat malheureusement :'(. Mais osef, je lance quand même o/
Symphotang
Symphotang
Membre

Nombre de messages : 282
Age : 24
Localisation : Dans son lit
Distinction : Poisson 2018 [Amal']
Duo comique du fofo' de 2017 à aujourd'hui feat Élolo :v (mais on aime qd même <3) [:3]
Date d'inscription : 12/05/2013

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Dim 30 Déc 2018 - 21:25
Je n'ai qu'une seule réaction :
Prout '-'
Anonymous
Invité
Invité

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Dim 30 Déc 2018 - 21:50
Pouet alors o/
Zangther
Zangther
Membre

Nombre de messages : 913
Distinction : aucune
Date d'inscription : 06/02/2013

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Lun 31 Déc 2018 - 10:38
Pour faire simple. Déjà tu vas pas choisir ton paradigme quand tu vas faire un jeu vidéo. Tu vas choisir tes outils.
Ensuite, l'orienté objet est décrié principalement parce qu'il est complexe pour pas grand chose. Pour pouvoir lancer un programme, on est obligé de savoir ce que c'est un objet comment le manipuler etc etc alors qu'avec un paradigme plus simple comme le fonctionnel ou le procédural, on a juste un main et possibilité d'appeler des fonctions directement.

Mais bon, tous les langages objets ne sont pas aussi compliqués au premier abord. Par exemple si tu compares du java et du ruby ...

Code:
class myfirstjavaprog

        public static void main(String args[])
        {
          System.out.println("Hello World!");
        }
}

VS

Code:
puts "Hello World!"


C'est surtout un travail à faire du coté du programmeur pour savoir avec quoi il est le plus à l'aise.
Anonymous
Invité
Invité

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Lun 31 Déc 2018 - 15:45
Oui, c'est sur x).

Mais justement, c'est bien le choix de l'outil qui me préoccupe =p. Parce que si c'est pour me retrouver coincés avec une bdd "inflexible" et à devoir inventé des trucs dégueulasse pour régler ça, ça va me souler xD (et puis ça serait contre les principes de l'OO). Après, je vois bien qu'il y a des solutions à prendre en considération en "amont" :

"There are multiple ways to look at the same data - IMHO it's common for an underlying data model to be tabular as in the relational style, with multiple different OO 'views' of that data, exposing it to different modules, with different restrictions, for different purposes, with zero copies/overhead. So, this section is false in my experience. " (du premier article)

Mais ça change pas ma question principale xD. Quand est-ce que tu va partir dans un module ici par exemple? Dans le cas des textes par exemple (et avec RM), est-ce que ça veut dire qu'il faudrait pouvoir avoir la structure de base de RM d'un côté et d'un autre côté, une autre "vue" centré uniquement sur les textes du jeu avec des modules dédiés? Ou bien, il faut plutôt créer une série de classe pour les gérer?
De même, dans le second article:

"Composite reuse principle. Composition is the right default™️. Inheritance should be reserved for use when it's absolutely required. "

J'ai pas de problème à comprendre cette phrase x). Sauf cette partie "when it's absolutely required"... Ça veut tout dire et rien dire xD. C'est quoi ces cas de "nécessité absolu"? x)
Bref, je veux bien écouter les conseils des anciens qui disent que "suffit" de respecter les principes de l'OO mais à certains endroits, ça sent un peu l'enfumage é_è. Mais pour autant l'info, c'est pas de la mystique donc je doute que ça se résume à ça xD.

Mais bref, au lieu d'essayer de trop continuer niveau théorique sans exemple, hier t'a dit que RM, c'était propre et bien fait. Qu'est-ce qui te fait dire ça en fait? Pourquoi c'est bien, au moins pourquoi ce n'est pas la pire des méthodes, de séparer la gestion des sprites des autres objets par exemple? Créer une classe-mère qui gère à la fois les propriétés des objets du jeu possédant un sprite et l'affichage, déplacement, animation de ces sprites, c'était très clairement une mauvaise idée? Bon là, plus je réfléchis, plus je me dit que ça pue vraiment xD. Et que niveau responsabilité, ça le charge trop x). Mais c'était juste pour l'exemple o/.

Bref, selon toi pourquoi la structure de RM est cool? è_é
C'est ça qui m'intéresse en vrai xD.

Ah et bonne année, on pourra reprendre après les fêtes quand même si ça te dit toujours x)
Zangther
Zangther
Membre

Nombre de messages : 913
Distinction : aucune
Date d'inscription : 06/02/2013

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Sam 5 Jan 2019 - 16:37
Bah, déjà faut pas faire la confusion entre la base de données et le langage. Ce sont (presque) toujours des entités séparées.

RM c'est bien fait parce que c'est bien séparé en plusieurs entités dont chacune à se responsabilité. Des choses sont à améliorer mais ça pourrait être pire.
Si je prends de RPG maker XP à VXace. T'as différents "types" d'objets selon l'utilisation. Grosso modo les Scenes, Window, Game, Sprite, Spritset.

Les Sprites sont tous les éléments graphiques affichés à l'écran, ex : Sprite_Character (joueur, event), Sprite_Picture (les images dans les events) ou Sprite_Battler (les battler en combat).
Les SpriteSet, sont comme leur nom l'indiquent des ensemble de Sprite. L'exemple le plus evident, c'est la map via Spriteset_Map.
Les Window sont toutes les fenetres affichées en jeu. WIndow_Menu, Window_Gold, mais aussi des Window plus génériques comme Window_Selectable.
Les objets Game sont tous les éléments variables du jeu. La liste est bien longue mais ce sont eux qui vont comporter tout ce qui fait le jeu. Game_Event, Game_Player, Game_Map, Game_Battle, Game_Party. En les manipulant tu fais avancer ton jeu.
Enfin les Scene vont représenter les "étapes" du jeu. Est ce qu'on est à l'écran titre ? Ou alors en combat ? Dans un menu ? Sur la map ? Les scenes organisent tout en manipulant les autres objets. Exemples : Scene_Title, Scene_Battle, Scene_Menu, Scene_Map.

Tout est bien séparé et généralement tout le monde a son rôle bien attitré. Genre la fenêtre ne va pas pouvoir modifier les HP d'un héros (Game_Actor). Un sprite ne pourra pas faire de transition vers une autre Scene etc.


C'est ça qui est cool.
Anonymous
Invité
Invité

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Sam 5 Jan 2019 - 19:36
Zangther a écrit:Bah, déjà faut pas faire la confusion entre la base de données et le langage. Ce sont (presque) toujours des entités séparées.

Yup! Mais après le choix du langage implique certains structure de données et inversement, le choix d'une structure de données implique certains langage (ou en tout cas, je crois que c'est un peu ça la raison derrière ces fameux débats). Parce que le langage ne donne pas la possibilité d'utiliser tel ou tel structure de données (et inversement), ou même sans parler de possibilité, parce qu'il va falloir implémenter des trucs dégueulasses ou galères pour faire ce dont on a envie. Et à terme, ça impactera aussi les possibilités du gameplay du coup! (que ce soit parce que techniquement, c'est pas possible ou simplement parce le workflow est trop lent et qu'il y a plus le temps)

Sans parler des performances mais ça, ça sera un débat pour un autre jour xD.

Zangther a écrit:Les Sprites sont tous les éléments graphiques affichés à l'écran, ex : Sprite_Character (joueur, event), Sprite_Picture (les images dans les events) ou Sprite_Battler (les battler en combat).
Les SpriteSet, sont comme leur nom l'indiquent des ensemble de Sprite. L'exemple le plus evident, c'est la map via Spriteset_Map.
Les Window sont toutes les fenetres affichées en jeu. WIndow_Menu, Window_Gold, mais aussi des Window plus génériques comme Window_Selectable.

Sinon, dac' dac' :3. Mais du coup, ça me permet de rebondir là o/. Parce si on devait faire une distinction entre les sprites et les window (qui sont tous deux des éléments graphiques), y en a qu'on va pas trop manipuler parce que ça rend pas bien (baisser la luminosité d'une map pour donner l'impression que c'est la nuit, c'est juste immonde) alors que l'autre, on peut le manipuler tranquille sans que ça soit choquant (taille, couleur, etc) voir le générer directement o/.
Mais dans le cas d'un jeux avec une UI custom (à tout hasard, un jeu comme ceux d'Asha' o/), ça sera pas plus simple de simplement créer des classes filles de "Sprite" dont certaines aurait quelques caractéristiques des windows? Parce qu'avoir la possibilité baisser la luminosité quand t'a des menu custom, voilà quoi... :v
Il suffirait juste d'avoir quelques fonctions utile comme _Selectable (et un second sprite d'une couleur différente pour afficher la sélection) et d'autres fonctions du même genre sur ces sprites :3 (bon, je connais pas suffisamment bien le nombre de fonctions minimales à avoir dans un jeu classique mais, pareil, c'est juste pour l'exemple et dans l'idée d'une autre structure x) )

Sinon, pour les "Scene" (ou autre nom), j'ai l'impression que là par contre, c'est l'indispensable xD. Pourvoir gérer des grosses transition de ce type (et en même temps les updates), il en faut forcément dans n'importe quel jeu x). Pareil, pour les game object si ce n'est que ça a l'air quand même d'un gros  fourre-tout et qui dépend du type de jeux x) (même si il doit quand même avoir des structures classiques en fonction des genres de jeu... Bien que j'arrive pas à mettre la main dessus xD. Ce qui est un peu normal mais bon x)).

Zangther a écrit:Tout est bien séparé et généralement tout le monde a son rôle bien attitré. Genre la fenêtre ne va pas pouvoir modifier les HP d'un héros (Game_Actor). Un sprite ne pourra pas faire de transition vers une autre Scene etc.

Dac' dac' :3. C'est tout con mais illustré avec un exemple, ça devient tellement limpide xD (à se demander pourquoi on y a pas penser avant x) )

PS: Désolé pour l'utilisation du terme "fonction" xD. À chaque fois, je sais pas quel le bon terme entre "méthode", "fonction" et les autres là x)
Zangther
Zangther
Membre

Nombre de messages : 913
Distinction : aucune
Date d'inscription : 06/02/2013

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Dim 6 Jan 2019 - 21:34
le choix d'une structure de données implique certains langage
Non.

ça sera pas plus simple de simplement créer des classes filles de "Sprite" dont certaines aurait quelques caractéristiques des windows?
En fait, les sprites ce sont juste des éléments graphiques qui comportent le bitmap, avec des methodes pour le modifier, selon les besoins. Les Window dans RPG maker, c'est une entité similaire mais qui est surtout constitué autour du principe d'afficher quelque chose dedans. Du texte, des icons, etc. En gros toute la partie interface.

game object si ce n'est que ça a l'air quand même d'un gros  fourre-tout
A vrai dire, non. C'est pas réellement du fourre tout, c'est toute la partie qui va concerner le contenu du jeu. Les events, les héros, la map etc.

PS: Désolé pour l'utilisation du terme "fonction" xD. À chaque fois, je sais pas quel le bon terme entre "méthode", "fonction" et les autres là x)
Une fonction, c'est presque la fonction au terme mathématique. Tu lui passe un/des paramètres et elle te renvoie un résultat. Potentiellement elle fait des effets de bord mais c'est une autre histoire.
Une methode c'est une fonction qui est attachée à un objet.
Anonymous
Invité
Invité

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Jeu 10 Jan 2019 - 12:58
Zangther a écrit:Non.

Ça, c'est dit xD.

On ne discute donc jamais des éléments du jeu puis donc des données et de leur probable structure pour enfin choisir le langage le plus adapté?

Zangther a écrit:En fait, les sprites ce sont juste des éléments graphiques qui comportent le bitmap, avec des methodes pour le modifier, selon les besoins. Les Window dans RPG maker, c'est une entité similaire mais qui est surtout constitué autour du principe d'afficher quelque chose dedans. Du texte, des icons, etc. En gros toute la partie interface.

Dac' dac' :3. Pour le coup, un bitmap, c'est juste la conversion en un tableau de bit en fait? Où est retenu indirectement la position (par la position dans le tableau) et la couleur par un code correspondant? (À chaque que je vois ce terme, je me demande si j'ai bien compris xD)

Zangther a écrit:A vrai dire, non. C'est pas réellement du fourre tout, c'est toute la partie qui va concerner le contenu du jeu. Les events, les héros, la map etc.

"Contenu du jeu", justement x). Rien que le terme, c'est le fourre-tout du jeu comme si ce qui relève du jeu devrait être absolument séparés du reste plus générique (ou plus info classique, je sais pas comment le dire x) ). Après pt que ça a une utilité de séparer bien distinctement ce qui relève du jeu (pour gérer d'éventuels problème par exemple)  mais sinon, mettre tout ça ensemble, j'ai un peu de mal x).

Les game_character, game_player, game_event, game_switch, game_variable et toute leur filles ok. La game_Map ou encore la game_Battler, ça a rien à voir déjà. Les game_Temp, game_System, game_Timer, c'est aussi un autre type. game_screen et game_picture, c'est aussi un autre truc un peu transversale et qui concerne pas vraiment le jeu en lui-même. Et t'a aussi game_BaseItem, c'est aussi un truc transversale (concernant un peu plus le contenu du jeu cette fois-ci). Et game_interpreter aussi si ce n'est que c'est pas directement le contenu du jeu :v

T'a l'impression que les programmeur ont vu les game designer arriver de loin et se sont mis en mode "Hé, ho, vous allez vous calmer tout de suite, vos machins, on va les mettre dans game_object, comme ça on pourra faire quelque chose de plus propre et solide à côté pis on essayera d'implémenter tout vos fantasmes juste après" xD

Bref, je vois pas la logique derrière la séparation game_object, du contenu du jeu d'un côté et du reste de l'autre x). Elle me semble artificielle et sans fondements si ce n'est peut-être une sorte de commodité (voir une séparation réellement efficace et qui évite des soucis) quand un dév doit gérer ce qui relève très générique d'un côté et de trucs plus ou moins divers et variés qui lui sont demandés par l'autre corps de métier :3

Après, je dit pas que pas que c'est mal fait (et en plus, je serais bien incapable de le dire vu mon niveau). Mais réunir tout ça dans la même catégorie, c'est bordélique :v. La map, c'est un élément du jeu sur lequel se déroule les events qui sont un autre éléments. Quand au combat, c'est une autre scene avec ses éléments (même si dans leurs manière de faire, c'est mélangé). Et les autres, c'est un peu des interfaces entre les classes ou des trucs génériques

Bon, toi, avec l'expérience que t'a sur RM, tu pourra pt me donner un autre point de vue =/. Mais bon, là, je suis pas convaincu x)

PS: Bon game_temp, vu que ça gère les event commun, je l'ai pt mal placé et ça a quand même un peu plus de sens ici mais bon x)

Zangther a écrit:Une methode c'est une fonction qui est attachée à un objet.

Danke o/
Contenu sponsorisé

Orienté Objet et structure des données dans les JV Empty Re: Orienté Objet et structure des données dans les JV

Revenir en haut
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum