Discussions autour de la "description du monde"

[Lightning]

Point 1 : la zone affichable.

Par monde je limiterais d'abord à une zone interieure ou extérieure.

En fait tant que la taille de la zone reste "limitée" elle peut être géré de la même maniere que ce soit un intérieur ou un exterieur. Une zone interieure sera limité par ses murs, une zone exterieure par une limite arbitraire (zone non accessible, chargement, etc...) et un 'Skydome' qui simule un paysage lointain.

Pour bien comprendre la différence, je prendrais l'exemple d'un Stalker, Operation Flashpoint, Morrowind, DAOC (?) ou on peut marcher des heures sans chargement visible (il y a tj un chargement mais celui ci se fait au fur a mesure en fonction du placement du joueur) c'est une zone ouverte sans réelle limite. Ce type de jeux integre souvent les "zone interieure" comme une maison sans différence avec le reste du jeux.
Ce type de techno comprend un nombre important de difficulté technique tel que le streaming.

A l'opposé on trouve les FPS et des jeux comme neverwinter ou toute la zone est directement chargé en mémoire. Le gros désagrements est le nombre de chargement, le gros avantage est sa "simplicité" technique.

On peut aussi trouver des solutions intermédiaire type WoW.

Comme discuté lors de la derniere réunion, un systeme type neverwinter est le plus accessible pour nous. De plus comme on n'atteindra surement pas la complexité visuel d'un FPS moderne, on peut utiliser un 'Scene manager' (l'algo qui gére les objets a afficher ou non en fonction de la position de l'utilisateur) simple.

Point 1 : A partir de quoi va-t-on charger la zone de jeu ?
Deux solutions les plus courantes, un fichier texte ou un fichier XML du coté client, on charge le fichier on le lit on affiche les données de la zone.

Autre solution auquel j'ai pensé mais qui sort de l'ordinaire : les données seraient stockées en base de données du coté serveur. J'ai pensé a ca en me disant que ca serait un moyen de faire un monde complétement évolutif ou les actions d'un joueur sur un élement du décord se voient réellement chez les autres joueurs et un joueur qui rentre donc charge la zone.
J'ouvre la réflexion pour des gens plus averti sur la gestion des données et client/serveur. Bisou luther.

Ah il faudrait aussi différencier le terrain (Neverwinter m'a vraiment donné plein d'idée simplement a mettre en oeuvre pour gérer le truc avec des layers de bitmaps) des éléments de décors que l'on va placer sur ce terrain.

Point 3 : Les infos que l'on va mettre dans le fichier/autre décrivant le décors.

La question est encore plus ouverte mais je favoriserais le fait de rester très simple au début puis d'ajouter des éléments petit à petit.

Par exemple dans un premier temps tout simplement :
- la liste des objets 3D avec le .mesh comprenant le modele fil de fer ainsi que les infos de texturing et la position de celui ci
- la liste des lumieres

Voila j'attends des infos de tout le monde car c'est vraiment la GROSSE base de plein de chose sur le plan visuel. De plus pas besoin d'etre pro en programmation des idées tirées de divers éditeurs sont tj bonne à prendre.

PS: j'éditerais ce poste au fur et a mesure.

[Lightning]

Pour apporter des infos sur la réflexion monde ouvert ou fermé voila un ensemble de document sur la génération de terrain :
http://www.gamedev.net/reference/list.as...yid=45#188

En gros de loin il est facile d'avoir une qualité graphique potable, par contre de près il est difficile de pas avoir un rendu moche.

Autre chose, si vous voulez savoir a quoi ressemblera tant au niveau graphique qu'au niveau des bugs un mmorpg ouvert développé 'artisanalement', allez voir du coté de Dark and Light.

A part ca, je réflechis comment on va représenter le terrain nottament au niveau des textures.

Une technique bien impressionnante est présenté la : http://en.wikipedia.org/wiki/Texture_synthesis

sinon reste le classique texture + mapping ou la texture généré suivant la heigt map ... pas pris le temps de regarder dans l'editeur de neverwinter.

Si vous avez des idées à apporter (exemple d'autres jeux, articles sur le net ...) n'hesitez pas

[manooch]

bonjour

Je suis assez pour la solution des carte a limite physique avec de l'eau ou des montagne infranchissable.
Mais avec des zone de pont a la "WoW", on prend un transport en commun ou un systeme de vol ou de teleporteur, cela ne reste valable que si gameforge ne sert a develloper des jeux online et de surcroit en FPS, RPG
pour ce qui est des autres genres il est d'autre choix qui reste envisageable,
changement de niveau = chargement de la nouvelle map etc ..;

Pour le fun j'ai trouver ce genre la interressant
http://www2.rasterwerks.com/game/phosphor/beta1.asp
c'est juste pour commenter le cote affichage ce quand meme pas mal sur une courte distance dans une SKYBOX ou DOMEBOX on peut je pense avoir de joli rendu...
faut voir la velocite du moteur 3D aussi et un standart d'affichage en limite max pour commencer.
genre jamais plus de 12 000 000 polygone a afficher en simultanée ^^...
le chiffre n'est la que pour faire peur^^.
J ai pris un peu de retard mais j'ai reactualisé le PDF pour l'interface je continue cette semaine
edit:
pour Neverwinter je trouvai que c'etait assez limitatif dans l'exploration il y avait un cote frustrant dans cette perspective en deplacement qui cachait une parti du terrain. C'est un genre!!!
un peu comme ce deplacer avec le pad de la PS en analogique on n'ai jamais vraiment dans l'axe..
Cela dit ce n'est que le jeux pas l'editeur ? me trompe-je ^^
a++ tous...

[Paf]

Citation :Autre solution auquel j'ai pensé mais qui sort de l'ordinaire : les données seraient stockées en base de données du coté serveur. J'ai pensé a ca en me disant que ca serait un moyen de faire un monde complétement évolutif ou les actions d'un joueur sur un élement du décord se voient réellement chez les autres joueurs et un joueur qui rentre donc charge la zone.
J'ouvre la réflexion pour des gens plus averti sur la gestion des données et client/serveur. Bisou luther.

Envoyer TOUTES les informations concernant un niveau a CHAQUE joueur a CHAQUE arrivee dans le niveau (le niveau a peut etre change entre temps...) ne me semble pas vraiment une bonne idee.
Par contre, envoyer des delta localises me semble deja plus envisageable.

Citation :La question est encore plus ouverte mais je favoriserais le fait de rester très simple au début puis d'ajouter des éléments petit à petit.

Par exemple dans un premier temps tout simplement :
- la liste des objets 3D avec le .mesh comprenant le modele fil de fer ainsi que les infos de texturing et la position de celui ci
- la liste des lumieres

Perso, j'aurai plutot une liste de reference vers des objets logiques qui contiendront entre autre des objets 3d.
Un objet logique etant une lumiere (qui peut reagir sur certains triggers), des personnages ou des decors statiques (ne contenant donc qu'une reference vers un modele 3d et des coeffs et des bouding* pour le moteur physique)...
Bref je n'organise pas la scene autour du Ogre::SceneManager et des objets graphiques, mais j'organise la scene autour des objets logiques qui chargeront les meshs associes lors de leur chargement et les dechargeront lors de leur dechargement.
Pourquoi cela ? Car un objet logique aura surement a charger ses bouding* pour ode, se charger d'autres modules (scripts, sons, entrees utilisateur, logiques [installer des triggers], reseau...). Un objet logique peut aussi changer de modele en cours de route (transformation...).
Ca correspond donc au principe d'encapsuler ce qui varie

[Lightning]

Paf a écrit :Envoyer TOUTES les informations concernant un niveau a CHAQUE joueur a CHAQUE arrivee dans le niveau (le niveau a peut etre change entre temps...) ne me semble pas vraiment une bonne idee.
Par contre, envoyer des delta localises me semble deja plus envisageable.

Oui l'idée que j'emettais peut paraitre 'hors norme'. D'un autre coté si on se limite a des deltas localisés, on va vite se limiter au mobs et joueurs en gardant le décor et autre statique donc exit un monde tres vivant.
Le probleme technique vient du fait qu'un serveur ne peut se permettre d'envoyer un niveau a chaque joueur qui arrive mais pourrait on envisager un chargement distribué (style torrent)...... et oui ca entraine une grosse reflexion sur l'integrité des données (pour etre plus clair les possibilités qu'un joueur triche).

Mais qui sait y a ptet a creuser

Paf a écrit :Perso, j'aurai plutot une liste de reference vers des objets logiques qui contiendront entre autre des objets 3d.
Un objet logique etant une lumiere (qui peut reagir sur certains triggers), des personnages ou des decors statiques (ne contenant donc qu'une reference vers un modele 3d et des coeffs et des bouding* pour le moteur physique)...
Bref je n'organise pas la scene autour du Ogre::SceneManager et des objets graphiques, mais j'organise la scene autour des objets logiques qui chargeront les meshs associes lors de leur chargement et les dechargeront lors de leur dechargement.
Pourquoi cela ? Car un objet logique aura surement a charger ses bouding* pour ode, se charger d'autres modules (scripts, sons, entrees utilisateur, logiques [installer des triggers], reseau...). Un objet logique peut aussi changer de modele en cours de route (transformation...).
Ca correspond donc au principe d'encapsuler ce qui varie

Alors tout a fait pour l'idée d'un objet logique mais je descend pas à ce niveau la. Je pense qu'il préferrable de voir d'abord le cas le plus simple c'est a dire un objet 3D. On pourra très facilement généraliser la chose.

En plus en terme de code, j'imagine que ton objet logique se traduit par une interface avec les implementations (objet 3D, scripts, son..) spécifiques ? En fait je crois que le neud défini par Ogre correspond a cette objet logique. En gros à un noeud peut etre attaché n'importe quoi.

[Paf]

Citation :Oui l'idée que j'emettais peut paraitre 'hors norme'. D'un autre coté si on se limite a des deltas localisés, on va vite se limiter au mobs et joueurs en gardant le décor et autre statique donc exit un monde tres vivant.
Le probleme technique vient du fait qu'un serveur ne peut se permettre d'envoyer un niveau a chaque joueur qui arrive mais pourrait on envisager un chargement distribué (style torrent)...... et oui ca entraine une grosse reflexion sur l'integrité des données (pour etre plus clair les possibilités qu'un joueur triche).

Mais qui sait y a ptet a creuser Smile

Qui a dit que cela se limitait aux mobs et joueurs ?
On peut faire un delta de tout et n'importe quoi
On peut tres bien fournir un delta d'une heightmap, annoncer qu'il faut ajouter un nouveau modele (statique ou non)...

Dans tous les cas il faudra introduire une notion de version.

Citation :Alors tout a fait pour l'idée d'un objet logique mais je descend pas à ce niveau la. Je pense qu'il préferrable de voir d'abord le cas le plus simple c'est a dire un objet 3D. On pourra très facilement généraliser la chose.

Justement, je dirai que c'est le contraire
Un objet 3d n'est qu'un cas particulier. Pas tous les objets seront visibles, pas tous les objets auront un seul modele 3d les representant.

Citation :En plus en terme de code, j'imagine que ton objet logique se traduit par une interface avec les implementations (objet 3D, scripts, son..) spécifiques ? En fait je crois que le neud défini par Ogre correspond a cette objet logique. En gros à un noeud peut etre attaché n'importe quoi.

En fait j'ai plutot en tete une architecture d'objets a composants, le tout etant data driven.
Faire dependre les objets logiques d'un noeud d'ogre, n'est pas vraiment la solution ideale. Les noeuds d'ogre introduisent une certaine notion de spatialisation qui ne sera pas forcement applicable a tous les composants.
Par ailleurs tu veux pouvoir representer le monde sur le serveur, et un serveur devrait eviter de se reposer sur Ogre.
Et se baser sur les noeuds graphiques d'ogre peut aussi introduire des problemes plus tard. Par exemple, on peut raisonnablement penser qu'il n'y aura pas forcement une seule carte dans le monde, et pour faciliter certaines taches (path finding au hasard) on aimerait bien introduire une notion plus generale de coordonnee telle que (mapX, mapY, x, y, z).
Bref je ne vois pas l'interet de faire dependre des composant non graphiques d'un composant graphique, avec tous les problemes qui se poseront avec.

[Lightning]

J'edite mon poste pour qu'il soit plus explicite et represente mieux les axes de reflexion

1ere possibilité : La génération offline
On crée un terrain sous (au hasard) Terragen, on l'export sous un format 3D facilement lisible (est-ce possible sans acheter le logiciel ?), on charge le tout au lancement de la carte.

2eme possibilité : génération en direct à partir d'une carte des hauteurs.
Cela permet d'éditer directement le terrain sous notre éditeur.
Dans ce cas, c'est plus technique (subdivision du mesh, interpolation des valeurs, etc ,etc) mais aussi bon ca permet d'apprendre
Et pour cela hop un lien : http://www.vterrain.org/Elevation/Artificial/

[motarion]

Si on pouvait éditer la hauteur du terrain direct dans l'éditeur ça serait génial mais si pour avancer le projet faut passer d'abord par la première possibilité, j'y vois aucun inconvénient.

[Paf]

Il ne faut pas avoir peur de la 2eme possibilite. C'est TRES simple.
Meme en s'amusant avec les trucs genre vipm cela reste vraiment gerable.

[Lightning]

vipm ? tu peux preciser.

Sinon oui la premiere solution n'a rien d'impossible

D'ailleurs faut que je précise par écrit ce choix. Mais la je suis malade, dans les vapes et j'ai du taf