Discussion :

[r0d]

La donnée est là, si on l'utilise, tant mieux, sinon bah, ben tant pis

C'est bien ce que je dis: on surcharge le réseau.
C'est sûr que dans mon exemple avec une classe et deux propriétés, ce n'est pas un problème, mais dans la vraie vie, on aime bien avoir le plus de donnée possibles, et il devient donc rapidement nécessaire de faire un tri et ne garder vraiment que ce dont on a besoin.

D'autant plus que dès qu'on est dans les problématiques réseau, chaque donnée supplémentaire qui transite pose de nouveaux problèmes (définitions, protocoles, sécurité, synchronisation, etc.).

[koala01]

C'est bien ce que je dis: on surcharge le réseau.

Pas si tu ne la transmet que lorsque la valeur change!

L'idée, comme je l'ai précisé, n'est d'envoyer sur le réseau que ce qui est modifié, et non "tout à chaque fois".

Si une propriété est utilisée coté serveur mais inutilisée (ou modifiée uniquement lors du passage de niveau, par exemple) coté client, il ne faudra l'envoyer que... lorsqu'il y a réellement modification

C'est sûr que dans mon exemple avec une classe et deux propriétés, ce n'est pas un problème, mais dans la vraie vie, on aime bien avoir le plus de donnée possibles, et il devient donc rapidement nécessaire de faire un tri et ne garder vraiment que ce dont on a besoin.

Et l'on peut parfaitement faire ce tri quand il s'agit d'envoyer les données sur le réseau, non

D'autant plus que dès qu'on est dans les problématiques réseau, chaque donnée supplémentaire qui transite pose de nouveaux problèmes (définitions, protocoles, sécurité, synchronisation, etc.).

Ca, par contre, je suis tout à fait d'accord.

Et c'est bien pour cela que la première chose que j'ai dite à ce sujet, c'est qu'il fallait limiter au maximum les données transmises

[r0d]

Pas si tu ne la transmet que lorsque la valeur change!

C'est effectivement l'approche standard.
Mais dans la pratique ça pose plusieurs problèmes. Déjà ça ajoute une couche "décisionnelle" qui consiste à "faire le tri" de ce que l'on envoie et quand (en général on retrouve des modèles type mepg2: on envoie les modifs "on the fly", et à chaque intervalle I, on envoie une "photo", un ensemble plus important de données, qui permet de s'assurer qu'on est bien synchronisé). Ensuite, étant donné le rapport asymétrique entre client et serveur, cette couche sera différente des deux côtés. Tout cela réuni peut poser de sérieux problèmes de maintenance, en particulier du fait que toute modification dans la couche métier aura un impact sur cette couche "décisionnelle".

Nous cherchons une sorte de graal, une méthode qui permettrait de pouvoir serializer sauvagement nos classes métiers. Ça simplifierait tellement les choses, autant lors de la conception, que lors du développement, mais surtout de la maintenance, que ce serait vraiment magique. Et à priori, je ne pense pas que ce soit impossible, seulement il faut sortir du MVC.

[Iradrille]

La donnée est là, si on l'utilise, tant mieux, sinon bah, ben tant pis

C'est bien ce que je dis: on surcharge le réseau.

C'est plus le fait de fournir des données inutiles au client qui est gênant: c'est dans le client, donc disponible en allant fouiller ou il faut en mémoire.
Si le client n'a pas besoin de données, il ne faut juste pas les fournir, ça évite pas mal d'exploits

[Sytten]

Bon le sujet diverge un peu du but initial, comme koala () a répond à beaucoup de mes interrogations, je vais clore le sujet très bientôt

J'ai décidé d'utiliser pour mon prochain jeu un moteur existant (sûrement cocos2d-x même si je trouve qu'il n'est pas parfait vu que c'est un portage de celui fait pour objective-c qui est un langage quand même très différent du c++) afin de me concentrer seulement sur le jeu en lui-même, ce qui risque m'aider à obtenir une meilleur qualité de code . Aussi, cela permettra à notre équipe de se souder un peu plus. Je crois qu'avant de tout de suite passer à la création de mes propres outils, je dois voir ce qui existe et comment ces outils sont bâtis. Je dois voir ce dont j'ai besoin dans mes jeux et tester les limites des outils avant de pouvoir dire que je suis à prêt à en créer de nouveaux (et réinventer la roue comme le fait germino et sa team^^). Je réalise que j’essayais de passer par-dessus certaines étapes dans mon processus d'apprentissage . Il me reste beaucoup à apprendre avant de prétendre être capable de faire un jeu (ou un moteur) de façon 100% autonome .

P.S.: je laisse ouvert le sujet pour quelques jours si vous avez des commentaires (qui me sont extrèmement utiles en passant )