Discussion :

[khayyam90]

Bien le bonjour,

J'aimerais vous faire réagir / commenter / démonter une idée d'architecture logicielle pour un jeu.
Nous sommes à peu près tous d'accord sur le fait qu'il faut clairement séparer les différents modules d'un jeu.
Alors pourquoi ne pas carrément développer différents modules reliés entre eux par un bus logiciel par exemple basé sur des sockets ?

On se retrouverait alors avec un paquet de modules faisant de l'écoute / envoi et avec la possibilité de séparer les processus (!), les machines et même les langages des différents modules. Ces modules seraient par exemple un moteur graphique, un moteur physique, un moteur d'IA .... avec la possibilité de rajouter très simplement des nouveaux modules ou de les modifier.

Ceci entrainerait une lourdeur au niveau de la communication entre les modules, c'est sûr, c'est le goulolt d'étranglement. Il faudrait déjà plusieurs traitements parallèles pour faire tourner les différents modules. Mais ceci amènerait indubilablement une simplicité au niveau du développement des modules, de la séparation des tâches, de l'évolutivité du jeu (Faites évoluer votre jeu en changeant son moteur physique) voire même des performances si l'on dispose de plusieurs machines.

Qu'en pensez-vous ?

oui oui, CORBA, il y a de ça ...

[Matthieu Brucher]

Effectivement, c'est lourd En plus il faut permettre certaines communications entre certains modules et pas d'autres.
En même temps, je n'ai pas d'idée fixe là-dessus, c'est à creuser, mais aucune architecture que j'ai pour l'instant pu explorer ne fonctionne là-dessus. Qui sait ? Bientôt je me lance dans un tel projet, on verra bien, je risque de changer d'avis

[Ti-R]

Je trouve cela lourd aussi.

Autant créer une espèce d'interface générique qui se lie à des dll ou les différents moteurs sont développés.

Si le moteur physique est nul.... on le jette, on prend un autre, on adapte le nouveau moteur à l'interface, on remplace la dll dans le projet, et zouuu.... c’est repartit.


Donc au final peut importe quel moteur on utilise. L'interface de l'API est la même, un peu comme OpenGL, peut importe l'implémentation derrière, et qu'on change d'une version 1.1 à 1.2, seulement de nouvelles fonctionnalités seront disponibles et pas de problèmes avec les anciennes ni de mise à jour du code.

C'est un peu la même idée, sans les sockets...
L’avantage des sockets étant de décentraliser certaines tâches.

L’avantage de l’interface est qu’il sera plus simple de communiquer et plus rapide aussi.

Ce n’est que mon point de vu.

Pourquoi pas faire des

OpenSound
OpenIA
OpenPhys
Etc…

Qui pourront compléter OpenAL et OpenGL.
Comme le group Khronos qui reprend les specs OpenGL
http://www.khronos.org/developers/specs/

[khayyam90]

et aussi différentes que ces deux architectures puissent paraitre (un simple agencement de modules par appels de dlls / une architecture basée sur une répartition réseau), je pense qu'elles peuvent être regroupées.

Ainsi, chaque module serait basé sur une interface de communication implémentant l'architecture choisie. J'aime beaucoup l'abstraction que ça rajoute.

L'une des contraintes serait qu'il faut programmer un jeu purement local comme si c'était une application réseau où tous les composants sont physiquement séparés, même si c'est ensuite pour implémenter des interfaces classiques entre modules sur une même machine.

De plus, il serait facilement possible de réaliser un tel bus de communication une fois pour toute (utopie?), basé sur des objets systèmes anciens et qui n'évoluent pas ou très peu avec en tout et pour tout, une simple recompilation pour prendre en compte des nouveautés systèmes.

Ca donnerait un socle très abstrait pour développer aussi bien des jeux classiques, massivement réseau ou distribués.

Pourquoi pas faire des

OpenSound
OpenIA
OpenPhys
Etc…

c'est en effet l'idée sous-jacente, qui risque de devenir réalité si ces composants sont incorporés au niveau matériel dans les composants. Certains constructeurs de cartes sons ont déjà franchi le pas me semble-t-il.

[bafman]

le problème d'une telle modelisation est qu'elle implique un nivellement par le bas des possibilitées...
su on reprend l'exemple du moteur physique :
j'ai une interface moteur physique qui permet de faire ce que je veut et j'ai un moteur physique derriere qui réalise l'interface.
finalement, les perfs n'etant pas suffisante, je decide de changer de moteur physique. Problème, ce nouveau moteur physique a plus de fonctionnalités dans certains domaines (fluide et autres) mais par contre n'implemente pas certaines autres fonctionnalités presentes dans le moteur physique précédent... je fait comment ?

[Ti-R]

Bonne question

Un mix des 2, ou tu redéveloppes certaines parties...

Je ne pense pas que le but soit de changer de moteur physique ou autre tous les ans. Mais de pouvoir compiler son projet vieux de 5 ans avec la même interface même si il y a 2 changements de moteur entre temps.

Enfin je le vois comme cela !

[bafman]

mais on se retrouve quand même avec un nivellement par le bas.

en gros, niveau fonctionnalités, on ne pourra avoir que l'intersection des fonctionnalités proposés par les differentes librairies

[Ti-R]

Oui c'est certains, sauf si un ensemble de fonctionnalité est défini au départ et devrait être supporté, et donc complété les fonctionnalités manquantes dès qu'un changement de moteur est mis en place. Et pourquoi pas prévoir une interface plus large que la moyenne, et donc proposer une « norme » de ce qui semble utile et nécessaire pour développer un jeu ou autre logiciel.

[khayyam90]

l'idée première n'est pas d'avoir les meilleurs performances possibles, c'est surtout d'avoir un socle commun pour faire communiquer tous les modules, un socle facilement utilisable et réutilisable. Bien sûr, univers de la 3D oblige, les performances doivent être au rendez-vous, quitte à attendre encore un peu.

Le composant que j'essaie de décrire devrait simplement gérer toute la communication (socket ou autre, ça ne doit pas avoir d'importance) entre les différents modules pour les rendre davantage indépendants et pourquoi pas, les désynchroniser et les paralléliser.

La notion de "norme" est tout à fait pertinente, on peut intégrer n'importe quel composant du moment qu'il gère les traitements de base qu'on attend de lui. Si ensuite s'il gère davantage de choses, alors tant mieux, c'est la même histoire que les cartes graphiques qui ont leurs propres extensions 3D.

Et actuellement, où l'on voit de plus en plus de projets amateurs (open source ) qui tentent de créer des composants généraux, celui là me parait manquer cruellement. Peut-être est-ce simplement dû à un manque de maturité des différents composants présents dans un jeu ou bien car il y a d'autres priorités notamment sur l'amélioration de ces composants.

[bafman]

pour revenir sur le sujet des moteurs 3D, après quelques recherches, je suis tombé sur ca :
http://ox.slug.louisville.edu/~o0loz....php/Main_Page
dont le but est de décrire une abstraction pour moteurs physique.

sinon, le problème d'un "bus" logiciel entreles differentes parties du jeu n'est pas nouvelle non plus, c'est justement ce qu'on appel le designe par composants, ou chaque composant requiere certains services et en fournit d'autres via des ports. Le plus gros problème etant de definir des ports permettant d'inclure un maximum de composants logiciel differents...

[Graffito]

Bonjour,

La communication entre modules par messages via des sockets a effectivement pour conséquence une interface demandant une sérialisation et une baisse de performance. comme indiqué :

Ceci entrainerait une lourdeur au niveau de la communication entre les modules

C'est toutefois une solution que nous utilisons pour des réalisations de frontaux de communication.

L'idée d'architecture multi-modules indépendants est bonne, mais pour des jeux, je préconiserai une solution à base d'objets COM+ ou de son équivalent en c#/.net.

[N_I_C_S]

Salut,

ton idée de "décentralisation" des tâches me semble effectivement pertinente en regard de l'évolution de l'informatique moderne qui, depuis les 60's, est dominée par les idées systémiques (collaboration de divers processus indépendants).

Je me permet d'intervenir car le discour est proche de mon idée de l'informatique à venir. Les performances grandissantes des liaisons réseau (internet : bientôt 100 Mo) permettent d'imaginer de nouveaux paradigmes. Pour ma part, j'imagine facilement un éclatement de l'OS : peut-être prochainement y aura-t'il une factorisation à grande échelle de tâches communes comme la saisie, la gestion de fichiers, etc...

Dans ce contexte, on peut pousser la reflexion sur le multimédia un peu plus loin : pourquoi pas un matériel simplement emetteur d'ordre/récepteur d'infos (une stricte VUE du MVC) ? Par exemple, un joueur disposerait (pour un prix modique) d'un ecran+clavier+modem, enverrait chaque ordre à un système distant (pour très cher) et recevrait l'image correspondante en temps réel.

Pour moi, ce genre de solution est imminente, nonobstant la technologie !!

[shenron666]

Les performances grandissantes des liaisons réseau (internet : bientôt 100 Mo) permettent d'imaginer de nouveaux paradigmes.

je pense que tu voulais dire 100Mb, une bonne connection chez un particulier ayant déjà du mal à atteindre les 24Mb théoriques (3Mo)

Pour ma part, j'imagine facilement un éclatement de l'OS : peut-être prochainement y aura-t'il une factorisation à grande échelle de tâches communes comme la saisie, la gestion de fichiers, etc...

"l'idée" a déjà été soumise par microsoft avec les logiciels déportés
le logiciel n'est pas installé sur l'ordinateur, il s'auto-télécharge lorsque l'utilisateur en a besoin et se désinstalle lorsqu'on le quitte

Dans ce contexte, on peut pousser la reflexion sur le multimédia un peu plus loin : pourquoi pas un matériel simplement emetteur d'ordre/récepteur d'infos (une stricte VUE du MVC) ? Par exemple, un joueur disposerait (pour un prix modique) d'un ecran+clavier+modem, enverrait chaque ordre à un système distant (pour très cher) et recevrait l'image correspondante en temps réel.

Pour moi, ce genre de solution est imminente, nonobstant la technologie !!

c'est le genre de système qui existe déjà en entreprise depuis des années
lorsque j'ai fait un stage il y a plus de 10 ans dans une grande entreprise de verrerie, il y avait des terminaux reliés à un serveur
le serveur effectuait les calculs et renvoyait les informations sur le terminal
certes ce n'était pas des images mais juste du texte mais le pricnipe est le même
vu la taille du site, le serveur pouvait être au pire à 3 bon kms du terminal et les connections n'étaient pas aussi rapides qu'aujourd'hui

maintenant dans le contexte actuel, je ne suis pas partisant de ce genre de solution à grande échelle mais elle a ses avantages dans des domaines particuliers

La communication entre modules par messages via des sockets a effectivement pour conséquence une interface demandant une sérialisation et une baisse de performance.

pas forcément, cela peut aussi permettre une amélioration des performance si le système est bien concu et même permetre au système de fonctionner non seulement en multitaches mais aussi sur un système style cluster en faisant transiter les requêtes via un réseau entre plusieurs machines se partageant les taches

il suffit d'imaginer un jeu en réseau où le serveur fait tout et les clients se tournent ne serai-ce qu'un peu les pouces alors que ce type de système permettrai au serveur de demander aux clients quelle proportion de temps libre ils ont et leur attribuer des taches

je pense qu'il y a matière à creuser, surtout avec l'augmentation (multiplication) du nombre de cores dans les futurs processeurs

[fearyourself]

Dans ce contexte, on peut pousser la reflexion sur le multimédia un peu plus loin : pourquoi pas un matériel simplement emetteur d'ordre/récepteur d'infos (une stricte VUE du MVC) ? Par exemple, un joueur disposerait (pour un prix modique) d'un ecran+clavier+modem, enverrait chaque ordre à un système distant (pour très cher) et recevrait l'image correspondante en temps réel.

Cela fait un baille que ca existe. Dans la faculté d'informatique dans lequel je me trouve, il y a une soixantaine (et je suis gentil) de terminaux branchés à un serveur. Il ne gére quasiment rien du système, le serveur faisant la plus grande partie du travail.

Jc

[millie]

Cela fait un baille que ca existe. Dans la faculté d'informatique dans lequel je me trouve, il y a une soixantaine (et je suis gentil) de terminaux branchés à un serveur. Il ne gére quasiment rien du système, le serveur faisant la plus grande partie du travail.

Jc

Oui, c'est des terminaux X. En plus, il y a toujours moyen de se connecter sur d'autre serveur via SSH et de soulager un peu le serveur principal (qui gère quand même toujours la visualisation des applications).

Ca peut permettre de limiter un peu les vols Parce que personne voudrait de ça chez lui