"c Excellent", ogame.fr

C'est vraiment un jeu temps réel ?

Cela n'en avait pas l'air à première vue, mais bon, c'est ptet qu'une histoire de "définition"

sisi c'est un jeu entierement en temps reel, chaque seconde je dois avoir quelque metal et deuterium en plus )

Et il faut un million de deuterium pour construire le moindre truc c'est ca ?
Bon j'essairais de regarder ca de plus près un de ces quatres quand même, par curiosité

lol, faut arreter de tout gober aussi
Les jeux qui se disent en temps réel utilent soit un calcul de différence entre les temps de connection ou soit des tour rapprocher (quelques minute ou quelque dizaine de minunte)
Et puis si je veut chippoter, le temps réel en info n'existe pas
@+

C'est du chipottage ça !

Bon, pour être plus "réaliste", on peut dire que le jeu sur site internet en "temps réel" n'est pas prêt d'exister...

Pour qu'un jeu soit en "temps réel", il faut un taux de rafraîchissement inférieur à 0.04 secondes. Sinon, c'est pas du "temps réel".

Alors, le jour ou un jeu tentera de rafraichir toutes les 0.04 secondes la page d'internet de plus de 10.000 joueurs avec un seul serveur (même avec 100 serveurs, ce serait pas possible), je plains le pauvre serveur : il va griller dans la seconde qui suit !

Il daudrait poser la question aux auteurs de JDR, ou la synhro doit être primordiale. la page est elle rechargée toutes les n milisecondes ou à la demande du joueur, par exemple quand il bouge ? (mais dans ce cas si un autre joueur bouge dans mon champ de vision, je ne le verrai qu'à mon prochain déplacement...)

c'est certes pas possible si on considère que rafraichir c'est reloader une page php toutes les 0.04 secondes, et donc invoquer un dialogue client/serveur.
mais ca doit être possible si côté serveur on a un composant écoutant et parlant sur un socket ip, et tournant en temps réel (donc un programme autonome tournant en dehors du serveur web), et de même dans le client (qui peut être une page générée par php, on met un "écouteur" dynamique qui permet ce temps-réel : par exemple un module flash ou ou une aplet qui écoute le serveur, il recoit un ordre, et apelle une méthode JS qui met à jour dynamiquement via css la page en cours sans aller la reloader entièrement.

bon bien sûr c'est compliqué mais pas impossible. La preuve nous en est donnée par dofus qui nous présente une véritable archi synchrone et pas basée sur un système requête/réponse (bon là c'est du tout flash côté client, mai son pourrait le faire avec JS/CSS).

La différence temps réel/pas temps réelle est claire : quelque chose (de notable, pas un gif animé) bouge sans que l'utilisateur d'agisse.
Cette définition exclue 99% des jpc au moins. Sur le www, ça impose l'utilisation du javascript ou autre code client. ("met à jour dynamiquement via css" ???). J'aurait tendance à penser que c'est LE point de différence entre un jpc et un jeu video.
J'ai fait un appel à information sur ce topic, personne ne m'avait cité "Dofus" (que je ne trouve pas dans l'annuaire)

Pour les jdr +queforum je pense que la plupart sinon tous sont fait pour 50 connectés qui font une action par 10s, bref pas de code particulier

@ askywhale

Donc pour toi les jeux en temps réel sont deux jeux qui utilise une technique de raffraichissement chaque 10 secondes par exemple ? (soit tour de 10 secondes)

Personnellement les tours de 0.04 secondes me semble plus être du temps réel vu qu'on a l'impression que c'est instantannée contrairement à des tours de quelques secondes... mais après tout je parle moi même de jeu en temps réel pour des jeux à tour de 10 secondes, seulement j'écris ainsi : "temps réel (tour de x secondes)".

------------------------

Oulà... faut voir... Imaginons Civilization (le 3 par exemple) le jeu vidéo qui permet de jouer par correspondance (envois de courriel), c'est donc un jeu vidéo par correspondance ? (jpc + jeu vidéo)

Donc on peut penser qu'un jeu vidéo peut être un JPC, et inversement... un jeu vidéo c'est peut être un jeu où on joue avec des images... ce qui regroupe pas mal de JPC... mais c'est peut être avec des vidéos ^^, et là un peu plus difficile sans télécharger de programme... hum... bon stop!

completement d'accord. moi je parle de synchrone/asynchrone mais ca veut dire la même chose. l'asychrone est basé sur le concept de base du web : action utilisateur/réaction serveur.
le web est par définition asynchrone, donc pour faire du vrai temps réel il faut vraiment se casser le cul avec les moyens du bord.

oui c'est ca que je voualis dire c'set bien JS qui est dynamique mais il travaille sur les propriétés css des objets statiques de la page pour les déplacer, ou changer leurs textes par exemple. le cas du JS c'est si tu es dans une page html statique, mais dans ce cas il faut quand meme un composant lourd (applet, activeX ou flash) qui maintient un dialogue permanent avec le serveur et qui lui invoque les méthodes de mise à jour visuelles JS local à la page (car a ma conaissanc e il n'y a pas moyen contrôler un socket ip en JS). En effet je n'ai encore jamais vu de jeu bâti sur cette architecture... en revanche si le client est entierement flash(comme dofus) ou applet ca simplifie la chose, on a plus la couche d'adaptation entre un écouteur dynamique et une page html statique. Le gros avantage d'un dialogue dynamique est que les messages échangés sont réduits au strict minimum, on ne recoit que des orders de cahngements de l'affichage en cours et plus l'intégralité de pages souvent lourdes et racalculées par le serveur.

côté serveur aussi tu auras besoin d'un écouteur tournant en permamence, indépendament du serveur web, qui ne fonctionne que sur déclenchement des utilisateurs. Et là le problème ne vient pas du développement mais plutot de l'hébergement de cet écouteur. D'un point de vue architectural, le liant entre l'écouteur serveur et le serveur web est la bdd.


sinon c'est :
www.dofus.com
un truc de pro...

Une simple remarque: il faut différencier l'aspect synchrone dans le déroulement du jeu (= temps réel) de l'aspect synchrone dans la technique de programmation (client-serveur en mode connecté, avec utilisation d'un port et d'un protocole de communication hors HTTP).

Un jeu d'échecs en ligne, par exemple (comme par hasard ), peut fonctionner en mode connecté mais être toutefois du tour par tour, pas du temps réel. En revanche, un jeu en mode non-connecté, par définition, ne peut pas être du temps réel, même avec des tours très rapides.

Mais même en mode connecté, je ne pense pas qu'il y ait de jeux en lignes offrant un vrai temps réel, excepté les jeux vidéos commerciaux jouables sur Internet (Warcraft, etc).

Je poursuis, l'exemple de lxir me fait en effet douter de ma définition du temps réel (qui indique que le jeu d'echec...en est). Lxir utilise la définition classique du temps réel (appliquée aux jeux video rts pas ex.). Je suivrait Zumba : on parle de synchrone dans le cas des echecs, asynchrone dans le cas des jpc classiques.

J'en revient au sujet : OGame est-il synchrone ?

Oui et Non : A chaque page qui est affichée, tes ressources sont recalculées.
En fait cela donne l'illusion d'un temps réel ... même si par définition cela ne peut pas l'être.

Mais attention, OGame va plus loin : A chaque action vers une planète d'un autre joueur, les ressources de cet autre joueur sont recalculées aussi.

Bref, pour ma part, je considère OGame comme du temps réel

C'est bien ce que je dis: pour se comprendre, il faut différencier le mode de fonctionnement du jeu de l'aspect purement technique.

Pour ma part, je dirais que techniquement Ogame n'est pas du temps réel, mais que dans le déroulement du jeu, il l'est (puisqu'à chaque action le joueur dispose de ressources recalculées). C'est en fait une simulation de temps réel; un "temps réel asynchrone".

A l'inverse, Sepao est techniquement synchrone (communication constante avec un serveur de jeu; l'action de l'adversaire apparait chez vous en "temps réel" - moins le temps de transmission), mais dans le jeu, on ne peut pas parler de temps réel alors que les joueurs jouent chacun leur tour !

Ogame c'est donc du jeu d'élevage en temps réel ?

Rôôhhhhhhh ! Trop fort !

Welldone > Yep, c'est même comme ca que je le décrivait : C'est un jeu d'élevage de planète.

Le pire, c'est que c'est vrai, pour moi OGame fait partie des jeux d'élevage, vu le peu d'impact de l'intéractivité entre les joueurs, vu le fait qu'on ne puisse pas perdre ... bref on fait que du levelling sans jamais taper sur les autres.

Tiens qq pourrais me traduire ce commentaire, je suis curieux

A+
Khiguard.

Déjà que l'allemand c'est pas facile, mais si en plus c'est du "langage SMS allemand" c'est mission impossible. ^^

salut, comme je suis le webmaster de ogame que connais bien ce jeu. et je peux vous dire que c'est un jeu de guerre. bien sûre on peut ce cacher sur ca planète et jamais faire la guerre (donc le jouer comme un jeu d'elevage). mais avec une telle tactique on ne peut pas devenir un joueur fort.
la majorite des joueurs se concentrent sur les guerres!

pour le grand nombre de votes: vous pouvez voir dans le jeu, ce ne sont pas du tout des "forced clics". on a un petite bannière de tourdejeu.net dans le jeu. et c'est tout. bien sûre les joueurs n'ont pas d'avantage dans le jeu s'ils votent pour lui! c'est un jeu serieux apres tout!!!
pour exercer un contrôle: ici

lol c'est rigolo le nombre de joueurs qui passent ici et postent sans créer de compte aussi

pis y a pas beaucoup de messages dans leur forum

enfin... pas bien grave je penses

Personnellement, je suis aller sur le site, et je n'aime pas une chose:

Pour savoir de quoi à l'air le jeu (est-ce que c'est un RPG, ou un truc genre reignofchaos ?) il faut s'inscrire, ya pas de screen shot (ou j'ai mal regardé)


Personnellement, ca ma fait réaliser que mon jeu avait le meme problème, chose que je vais régler pour la prochaine version

Désolé, c'était moi ^^

Pour qu'un jeu soit en temps réel, il faut 3 choses :
1- que toutes les valeurs du jeu (chaque planète, chaque perso, chaque boutique, chaque combat...) soit calculé par intervalle régulier
2- que ses valeurs soient systématiquement remis à jour sur la page Html (ou au "language", peu importe) sans qu'on touche à quoi que ce soit (pas de refresh par exemple)
3- que l'intervalle soit tellement faible qu'il n'est pas visible à l'écran (sinon, c'est de l'asinchrone)

En gros, ça demande beaucoup beaucoup de ressources...

D'ailleurs, les jeux-vidéo internet sont +- internet ! En fait, vous jouez avec la puissance de la machine, avec les infos/graphismes/sons/moteur_graphique qui sont installées sur votre bécane. L'internet, lui, ne fait que d'envoyer des infos comme quoi le squelette à été tué, que votre copain boit une potion de soins, etc...Seul les renseignements externes sont renvoyées...

It was Me !

Je pense que des que tout le monde sera sur du 500Kb/sec STABLE (comprendre, mininum possible), et bien avec un peu (énormément) de DHTML, quelques trucs Flash, etc etc, il sera possible de voir apparraitre des jeux réellement en temps réelle (oui, avec un délais de moins de 0.04 secondes)

Je sais, c'est un peu futuriste, mais ya pas si longtemps, on était sous 56K non ?

commentaire Ogame... :


prepucio, le 09-12-2004 :

----

prepucio, le 09-12-2004 :

----
(mes notes : Richesse=4/5, Jouabilité=4/5, Ambiance=5/5)

Edit YeDo : Ok, j'ai nettoyé. Passez par mail plutôt pour les abus. Merci.