Discussion :

[dreck]

Salut à tous

J'espère que je suis assez clair dans le titre du post

Oui bon voila en fait j'envisage la création d'un jeu en java en utilisant la base de données mysql d'un hebergeur "normal". Mais bien évidemment, ça ne sera pas extrêmement rapide vu que l'hebergeur ne pourrait pas subir 80 requêtes par seconde et par personne.

Donc je me disais que le jeu pourrait être "par coups", la base de données ne serait consultée que toutes les 0.25 secondes par exemple, ou toutes les 0.5 secondes mais je ne sais pas si c'est une bonne idée, si l'hebergeur suivra... Et comme je n'ai pas l'argent pour un serveur dédié, j'aimerais avoir votre avis sur mon idée....

Merci

(PS : J'espère que c'est le bon forum, j'hésitais avec le forum "Général Java"...)

[chat hotplug]

Bonjour,

Un jeu en applet Java hein ?
Le Java s'execute côté client donc si vous vous arrangez pour quil n'y est pas tellement besoin de base de données vous pourriez faire en sorte que la base soit requetée seulement au lancement du jeu.

Pourquoi utiliser un base, quelle type de données ? C'est un jeu multijoueur alors ?

[Maximil ian]

Salut,

Tu es bien dans le bon forum

Pour te répondre, il nous faudrait des détails plus précis : volumétrie de la base de données, nombre estimé d'utilisateurs simultanés, évolution prévue...

Retarder toutes les requêtes de 0.5 secondes n'arrangerait pas grand-chose puisque s'il y a des pics d'accès ça ne ferait que déplacer ces pics.
Ce que tu peux faire c'est utiliser du code SQL le plus optimisé et le plus propre possible et tirer parti au mieux des index. Mais sur un serveur mutualisé (donc moyennement performant et dépendant de tes "co-hébergés") il ne faut pas s'attendre à des miracles.

Par ailleurs, il y a d'autres paramètres à considérer que la base de données :

- Robustesse du serveur web
- Bande passante
...

[dreck]

Salut, merci de vos réponses

Oui un jeu en applet, qui serait effectivement multijoueur (d'où la necessité d'utiliser la base de données).

Pour ce qui est du type des données, si j'ai bien compris la question, elles seraient majoritairement numériques.

Pour ce qui est des 'pics' tous les 0.25 ou 0.5 secondes, ça ne serait pas pareil chez chaque joueur, puisque cela partirait du lancement du jeu, et qu'il ne serait pas toujours le même (enfin vous avez compris, j'espère )

Le nombre de joueurs attendus... eh bien plusieurs dizaines en même temps, aux heures de 'pointe', je pense (vu la vitesse de ce type de jeu à se remplir de joueurs)

Mais les informations à transmettre toutes les 0.25 secondes ne seraient pas tant que ça, puisqu'il ne s'agirait que de la position des autres joueurs sur la portion de carte ou se trouve le joueur plus une ou deux infos sur chaque autre joueur... les autres informations pouvant être transmises de façon plus espacées...

Mais sur un serveur mutualisé (donc moyennement performant et dépendant de tes "co-hébergés") il ne faut pas s'attendre à des miracles.

Le seul problème c'est qu'à part cette solution je n'en vois pas d'autre qui soit dans mes moyens....

Voila j'espère avoir répondu à vos questions et que vous comprenez mieux ce dont il est question...

Merci

[pcaboche]

Le nombre de joueurs attendus... eh bien plusieurs dizaines en même temps, aux heures de 'pointe', je pense (...)

Mais les informations à transmettre toutes les 0.25 secondes ne seraient pas tant que ça, puisqu'il ne s'agirait que de la position des autres joueurs sur la portion de carte ou se trouve le joueur plus une ou deux infos

Dans ce cas, tu ne va pas faire des INSERT et des SELECT dans ta base de données toutes les 0.25s: ça serait affreusement lent !

Tu ferais un serveur en Java qui gérerait certaines infos des joueurs connectés (positions sur la carte) sous forme d'objets. C'est seulement pour faire des sauvegardes que tu utiliserais la base de données (ou à la limite sérialiser tes objets dans des fichiers, comme ça t'as juste à les désérialiser par la suite !).

En fait, au minimum, tu as besoin:
- sur tes clients: des infos sur le joueur (équipements, caractéristiques...) obtenues à la connection sur le serveur
- sur ton serveur: de la position des joueurs sur la carte

Quand deux joueurs se croisent sur la carte, tu fais communiquer leurs clients entre eux (en fournissant à chacun l'IP et le port de l'autre) et c'est tes clients qui gèrent les interactions entre les joueurs (parce que si tu centralises tout, ton serveur risque vite de ramer s'il y a du monde). A intervalles réguliers, les clients communiquent au serveur les changements importants.

Quand deux joueurs s'éloignent l'un de l'autre, le client peut décider de libérer la connection (en vue d'en accepter d'autres).

Bon, après, je ne suis pas super fort en programmation réseau et algorithmique distribué (c'était un peu ma bête noire)

[Maximil ian]

Dans ce cas, tu ne va pas faire des INSERT et des SELECT dans ta base de données toutes les 0.25s: ça serait affreusement lent !

+1

J'ai du mal à voir dans laquelle de ces deux catégories se situe ton projet :

- Les jeux à interface Web (souvent en PHP) comme ceux proposés ici et où le joueur n'effectue que quelques dizaines de clics par minute. Il a en général un certain nombre de points d'action à dépenser et les interactions (autres que chats et forums) sont souvent limitées.

- Les jeux multijoueurs avec des graphismes (3D ou pas) où le joueur évolue dans un espace en temps réel.
Dans un jeu de ce type, ce qui est stocké en base de données c'est des informations générales sur le joueur ou son personnage, pas des données qui évoluent en continu.
Je ne m'y connais pas assez pour l'expliquer en détail, mais cela implique un code réseau qui peut être très complexe. Et inutile de dire qu'un hébergement web ne peut pas servir à gérer de façon centrale les agissements en simultané de tous les joueurs...

[pcaboche]

J'avais fait l'hypothèse qu'il se trouvait dans le cas 2 (les jeux multijoueurs où le joueur évolue dans un espace en temps réel) parce qu'il nous parle d'un jeu en Java. Si c'est le cas 1, c'est beaucoup plus simple.

Je ne m'y connais pas assez pour l'expliquer en détail, mais cela implique un code réseau qui peut être très complexe. Et inutile de dire qu'un hébergement web ne peut pas servir à gérer de façon centrale les agissements en simultané de tous les joueurs...

+1

C'est pour cela que je parle de décentraliser la gestion des intéractions entre joueurs du côté des clients, et oui, c'est assez complexe à gérer...

[dreck]

Salut

Il s'agit effectivement du cas 2, mais la solution que j'avais proposée n'aurait pas été si complexe, je pense. Mais effectivement après réflexion et après vos posts, il est clair qu'elle ne correspond pas à ce type de jeu.
Les meilleurs solutions, d'après ce que j'en sais, sont effectivement assez complexes, comme vous l'avez dit. Il faudra donc une longue étude approfondie (très longue) de la chose...

Merci à vous de m'avoir éclairé sur le fait que ma solution n'était pas adaptée !