Jeu en temps "réel"

[SorenS]

Dernièrement je réfléchi de plus en plus à un type de jeu. Cependant je me pose une grosse question.

Imaginez un jeu où durant un certain temps vous entrainez votre gars, etc... et à un moment, vous devez le gérer non-stop dans une sorte "d'arène" durant 30 à 45 minutes. Vous devez être derrière l'écran à ce moment là non-stop.

Pensez vous que cela est jouable ? Beaucoup préfère faire clic-clic quelques temps puis repartir... Qu'en pensez vous ?

PS : le titre du post n'est peut-être pas adapté. Si vous voyez un titre plus adéquat dites le moi

[NicoMSEvent]

Pour moi, le jeu par navigateur est un jeu qui peut se dérouler 5 min par ci, 5 min par la, et n'oblige pas le joueur a rester derriere son écran.
Apres ça, c'est ton jeu, et tu fais ce que tu veux ^^
Le temps réel est faisable et pas trop couteux en ressources avec APE dont on a parlé dans un autre post (trop la flemme pour faire un lien, vous m'excuserez :p )

[Ter Rowan]

quand je joue a wow, c'est 2h,4h voire 6h

alors 45minutes, c'est pas grand chose

cependant j'analyse ton sujet par deux points

1) une partie des "clients" habituels des jeux web sont des joueurs "occasionnels" qui n'ont pas le temps (ou le souhait) nécessaire de rester connecter et impliqué non stop. Cette partie du "marché" sera perdue d'office.

2) est ce qu'un jeu par navigateur peut avoir la richesse de gameplay (et autres) suffisant pour conserver l'intérêt de rester non stop 45 minutes (si je dois attendre toutes les 5 minutes de raffraichir la page => non, si je dois faire toutes les 10secondes la même chose => non, etc..., si au bout de deux jours je n'ai plus rien de nouveau a faire => non)

je en sais pas si on peut développer des jeux à mécanisme "d'immersion intense" sans une partie client lourde

[Quirinus]

Il est clair que du temps réel c'est effectivement très mauvais pour les ressources : rafraichissement couteux, sans oublier qu'il faut une palette d'action assez importante pour éviter la monotonie.

Je ne pense pas détenir la vérité absolu mais tu peux orienter ton jeu vers du semi-temps réel. C'est ce que je pense utiliser pour mon jeu : chaque action que tu entreprend laisse un temps de latence avant la prochaine action. Par exemple, tu frappes et tu devras attendre 30 secondes (ou +) pour une nouvelle action.
Rien de vraiment novateur si ce n'est que tu allèges considérablement les appels au site pour réactualiser l'action ; en effet, pourquoi réactualiser tous les 10 centièmes alors qu'un refresh toutes les 5 sec est suffisant pour suivre l'action?

Et pour "occuper le joueur" pendant ces moments d'attente, rien de tel qu'un petit chat directement intégré pour qu'il puisse discuter/commenter le combat en cours ( et hop petite dimension sociale ^^)

[JauneLaCouleur]

Pourquoi ce limiter à 45minute ? C'est une question de gameplay. Utiliser un navigateur pour faire un client léger c'est tout a fait possible, mais de suite ça limite le nombre de joueur. Tu ne pourras pas avoir 1,000 joueurs connecté en même temps, quoi que, il faudrait faire des tests de monté en charge... HTTP(S) n'est pas très léger comme protocole d'échange, mais il est simple et répandu. Par contre, si tu souhaite faire du " temps réel " oublie le cron qui actualise ta DB toute les X secondes.

Par exemple, le game play de combat de FF VII, c'est du semi tour par tour, et cela demande peut d'échange réseau. Même WoW, c'est très jouable avec 200 ms de ping. Par contre, les FPS eux, il faut avoir le minimum de latence pour que se soit un minimum jouable. Je pense qu'il faut adapté le gameplay aux technologies que tu utilise.

Je suis, moi même entrain de réfléchir à comment crée ce genre d'application, bien que mon objectif ne soit pas de faire un jeu, mais plutôt une démo-technique.

Pour le moment, mes choix technologiques sont les suivants: un serveur de jeu ( en Java ou C++, j'hésite encore, mais en PHP c'est très faisable aussi) caché derrière un serveur HTTP (genre lighttpd, ou xngin), via FastCGI. Pourquoi pas directement un serveur de jeu qui gèrent HTTP ? C'est une question de sécurité et de fiabilité, les serveurs HTTP existant sont beaucoup plus stable et sécurisé que je n'arriverais jamais à la faire...

[Allwise]

Et les sockets dans tout ça ? Grâce à Flash on peut s'affranchir du protocole HTTP et coder son serveur dans le langage qu'on veut et faire le client de son jeu web avec JS / CSS / HTML / Flash.

[JauneLaCouleur]

Oui, le seul hic, c'est que flash c'est un plug-in propriétaire, et que la majeur partie de plateforme portable ne le supporte pas ou très mal. Il y a aussi la possibilité d'utiliser les XPCOMs sous Mozilla, mais encore une fois, ce n'est pas portable... A l'image de Flash un applet Java permettrait aussi de faire du "socket".

Tout dépend des exigence de chacun.