Discussion :

[moa378]

Salut tt le monde.

Bon je vais poser une question qui va surement vous sembler stupide mais bon je me suis jamais penché sur la création de jeux vidéos et c t pour savoir.

Dans un jeu (par exemple un rpg) y'a pas mal d'infos a stocker (bon jusque là je dois pas trop avoir raconté de conneries) mais la question que je me pose est la suivante. Comment sont-elles stockées????

-une BDD (pq pas)
-des bons vieux fichiers externe (euh ça doit être lourd)
-codé en dur (vive le bordel )
-autre???? (là je vois pas)

bref le bdd me semble être la seule solution vraiment viable pour un gros projet mais vu que je connais rien en prog de jeux je voulais savoir si comme ça que c'était géré.

D'ailleurs si c t ça j'aimerais savoir commen c t foutu. tmps d'acces assez rapide? quelle bdd? (j'ai pas l'impression que quand j'installe un demineur celui çi me met une bdd oracle )

Scusez mon ignorance

[shenron666]

-une BDD (pq pas)

surement pas pour un jeu autre que massivement multijoueurs

-des bons vieux fichiers externe (euh ça doit être lourd)

pourquoi lourd ?
un bon gros fichier "script"
ou plusieurs fichiers
cela dépend du "moteur" du jeu
attention moteur moteur moteurs...
en gros dans le moteur du jeu tu peux avoir pleins de petits moteurs :
le moteur graphique qui va gérer l'affichage
le moteur sonore qui va gérer les sons
le moteur d'IA qui va gérer les réactions des ennemis
le moteur d'entrées qui va gérer le clavier et la souris
le moteur de script qui est une solution à la question que tu te pose
... (d'autres encore sont possibles, merci la POO)

en gros, le moteur de script est une sorte d'interpréteur, par exemple tu codes en basic des actions à assigner à des personnages/monstres dans un rpg, exemple :
si joueur clique sur moi alors je dis telle chose deviendra
if(click) say("telle chose")
si le joueur attaque je m'enfuis
if(chui_attaqué() == joueur) jmebarre(très_loin)

avec "chui_attaqué" qui appelle une fonction qui renvoie la source de l'attaque
et "jmebarre" qui est une fonction qui prend une destination

bon j'ai simplifié mais il existe des langages de script divers et plus ou moins évolués

-codé en dur (vive le bordel )

clair, ingérable et pas évolutif, en bref : non

-autre???? (là je vois pas)

je vois pas d'autre solution non plus

[moa378]

Ok mais je vois pas trop comment ça s'organise bon un exemple tout con prenons les dialogues d'un jeu:

dans une bdd d'un coté t'aurai la table des persos et de l'autre celle des dialogues avec une assoc entre les dialogues et les persos (ouais bon c la solution simple).

Avec des fichiers t'aura 1 fichier par perso? contenant tous les dialogues de ce perso sous forme de language script c ça?? et si y'a des conditions ça deviendra genre:

if(click and quete1Effectuee and quete2Effectuee) say("machin")
if(click and quete1Effectuee and quete2Effectuee) say("truc")


Je me demande si j'ai bien compris parce que cette solution me parrer bizarre pour plusieurs raisons:
- les fichiers deviendraient tres vite extrement lourd et se multiplieraient par un nombre extrement important (chaque fois que tu fais un perso en fait (j'imagine même pas pour bg ou morrowind)).
- ça reviens presque à coder en dur non???
- ça bouffe pas trop de ressources d'interpreter tt ça?

Bref y'a un truc que j'ai du mal saisir?

Sinon pourquoi on n'utilise pas une bdd?? je trouverai ça plus facile à gérer mais je dois surement me tromper.

ET au passage le :
if (suisAttaqué) jmebarre(tres_loin).
pq qu'il est pas dans le moteur d'IA.

Ou alors le moteur de scrit ne sert QU'A interpreter les scripts et fait ensuite appel aux autres moteurs.

Dsl si je suis un peu mou mais bon j'ai jamais touché à ça et c vague pour moi

[moa378]

En fait pour être + prceis je pensais que c'était une bdd + un moteur de scritp par exemple dans les champs de la table dialogue qu'il y avait le dialogue standard et un champ script sui permeté d'effectuer un cas special (par exemple enregistrer une nvelle quete ........) mais pr les dialogues par exemple il me semble que cela éviterait pas mal de redondance au niveau du code du script mais bon je dois surement me planter.

[shenron666]

Avec des fichiers t'aura 1 fichier par perso? contenant tous les dialogues de ce perso sous forme de language script c ça??

pourquoi faire pleins de fichiers ? c'est clair c'est lourd, alors rassemblons dans quelques fichiers seulement :
- tu peux très bien définir tes persos avec un ID unique par perso pour y faire référence, tu réunis tous les persos dans un seul fichier contenant les caractéristiques du perso (graphisme, nom, force, intelligence, ...)
- dans un second gros fichier (crypté/compressé si tu veux) tu as tous les textes avec un identifiant pour chacun d'eux

il s'agit d'une base de données si tu veux mais pas au sens BDD oracle, sql ou autre, c'est une base propre au jeu

- ça reviens presque à coder en dur non???

pas du tout, le programmeur ne s'occupe habituellement pas de ce genre de chose, c'est le designer, il faut pas qu'il ait à toucher au programme, qui plus est il connait rarement la programmation

- ça bouffe pas trop de ressources d'interpreter tt ça?

le moteur de script doit être simple, il a pas un tas de trucs à gérer

un exemple, la série quake, oui le jeu, tu as accès à une console qui te permet de modifier des paramètres du jeu, en fait la console est un interpréteur pour le moteur de script de quake, bon ca parait un peu basique mais tout est possible selon la puissante et la liberté que le programmeur aura accordée au moteur de script
évidemment, plus de liberté (ou plus de possibilités je dirais) demande plus de puissance (consommation CPU et ou mémoire) et consomme donc plus de ressources

[moa378]

ah ok je vois un peu mieux comment c fait.

Allez j'abuse et une autre question qui me vient à l'esprit. elle concerne l'affichage des objets (ds un jeu 3D). Je suppose que l'on n'affiche pas tous les objets d'une carte par exemple car ça doit bouffer des perfs mais comment que l'on sait lesquels afficher??? Bon on affiche ceux dans un rayon de x m autour de la camera je suppose. OK mais comment savoir desquelles il s'agit. On s'amuse à recalculer à chaque image la distance de tous les objets avec la camera?????? Ca me semble bien lourd donc ça doit pas être ça.

[shenron666]

Abuses, abuses, le forum est fait pour trouver réponse(s) aux questions qu'on se pose
bon si je dis des conneries j'espère qu'on viendra me corriger

la méthode est bonne, c'est lourd (quoique) mais c'est une solution parmis d'autres, si les objets sont bien ordonnés ca va vite (éventuellement avec des méthodes d'approximation)
tu peux te servir de la distance également pour voir quel niveau de détail utiliser pour afficher ton objet (un personnage de 5000 polygones avec des textures hyper détaillées n'a pas d'intérêt s'il est à 5 km de la caméra et qu'il fait 10 pixels de haut)

- il y a aussi le test du "cone de visibilité" ("viewing frustum" en anglais je crois), tu testes si l'objet est dans le champs de vision, un objet qui est totalement en dehors (soit trop sur le côté soit derrière) tu ne l'affiche pas

- ou encore la technique dite des portails ("portals" en anglais), le monde est découpé en zones, le programme repère d'abord les zones qui sont concernées par la position de la caméra et traite les objets qui sont dedans, surtout utilisé pour les intérieurs (quake est un bon exemple de moteur basé sur les portails)

il y a d'autres solutions qui, selon le type de moteur, sont plus ou moins exploitables

[moa378]

Je comprens pourqoui mon proc chauffe quand je joue a farcry .

Il me semble que plutot que de tout recalculer a chaque image un algo de ce type serait moins bouffeur de perfs non :

- bon la premiere fois on calcul la distance de tous les objets et on affiche ceux dans un rayon de x metres. et on stocke une reference vers les objets affiches.

- on n'affiche que les objets que dont on a stocké les refernces les fois suivantes.

- on recalcule la distance avec tout par exemple quand on avance de 10m.

Il me semble que ca permettrait de bien reduire la complexité de l'algo non??

Enfin remarque a la con:
soit un jeu decupe en zones carrées mais ou toutes les zones s'enchainent sans coupure (g pas dis sans chargement) un exemple de ce que je veux dire est farcry par exemple. Dans ce cas les eones doivent de chevaucher je suppose quand on est sur un chavauchement on doit calculer la distance des objets pour les 2 zones. Mais y'a aussi un endroit ou les 4 zones se chevauchent et là faut calculer pour les 4 zones (donc des endroits ou ça ramerai beaucoup + que d'autres dans certains jeux ??????????)

(Je sais tout pour aller chercher les conneries 8) )

[shenron666]

Pour ton algo c'est applicable, j'ai tendance à dire que tout est faisable en programmation (et c'est pour cela que j'adore la prog) juste que certaines choses se font mieux que d'autres, ce que tu proposes est de l'optimisation, alléger les calculs (parfois au détriment de la qualité ou autre)

à propos de ta remarque, tu peux aussi découper le jeu en zones plus petites et en considérer plus, par exemple, il y a la zone dans laquelle on se trouve, et les zones proches ce qui en fait déjà 9 au total) plus les zones éloignées (on passe à 25) et si le joueur a demandé plus de détail on augmente la distance de vue de 1 et on passe à 49 zones
et puis on peux afficher une zone sans forcément afficher les objets qu'elle contient (zone trop éloignée, objets trop petits donc pas intéressant)
le nombre de zones n'est pas un problème en soit (sans exagérer non plus), c'est ce qu'elles contiennent qui demande du temps de calcul

[moa378]

Ok je vois lr principe donc en theorie il serait possible de modéliser un monde de 50km de long avec tt plein de petites zones et de le parcourir de long en large sans aucun chargement. Ok mais dans ce cas pourquoi au niveau des jeux de ce type y'a des chergements (farcry, morrowind... ) remarque en y refelchissant bien y'a aussi des contre-exemples (outcast) . Donc en fait cette deifférence viendrait d'une différennce de conception a ce niveau là si j'ai bien compris.

[shenron666]

Différence de conception mais aussi tout dépend de ce que contient la zone (ou les zones)
les informations prennent de la place, il faut aussi considérer les graphismes, les sons, bref c'est peut-etre aussi un soucis de mémoire

et puis je pense qu'un moteur de jeu qui affiche beaucoup de choses est plus lourd à gérer, plus difficile à programmer, donc cela revient plus cher

[bafman]

(quake est un bon exemple de moteur basé sur les portails)

erreur : Quake n'utilise pas les portal mais les PVS (potentialy visibility set) ou en francais zone de potentiellement visible. En gros ca consiste en toute zone de la carte a stocker l'ensemble des zone potentiallement visibles. ainsi lorque le jeu tourne, plutot que de tester la visibilitée de tout les objet, on ne test la visibilitée que de ceux qui le sont potentiellement (mais pas forcement si on leur tourne le dos...
Par contre Doom 3 lui utilise les portal ET les PVS... La solution de portal dans quake avait été envisagée mais ne donnait pas de resultat suffisament interessant a l'epoque. Pour plus d'info sur le moteur de quake, lire les text de michael abrash qui a bossé avec carmack sur le moteur (il sont dispo sur le net...)

sinon pour les morteur de jeux, le but n'est pas d'en calculer le minimum, mais d'en afficher le minimum, car c'est bien la bande passante CPU/GPU qui limite le jeu la plus part du temps. l'ideal est même de pouvoir equilibrer les calcule entre le CPU et le GPU, chacun tournant ainsi ou maximum de ses possibilitée sans etre ralenti par l'autre (malheureusement c'est totalement theorique...).

Pour le probleme d'afficher un monde entier sans temps de chargement, la plus grosse partie du probleme consiste a mettre en memoire toute les info... impossible a l'heure actuelle de mettre des terrain ultra detaillé de plusieurs centaines de kilometres + texture + sons + scriptes + pleins d'autres truc en memoire, la solution generalement utilisée dans ces cas la est le streaming de donnée. la carte est decoupée en zone relativement grandes, on considere par exemple queetant située au centre de la zone tu ne puisse pas voir les extremitée de cette zone, on charge toutes les zones adjacentes, et quand tu te deplace dans une direction, on enleve de la memoire les zone que tu ne pourra plus voir avant un moment, et on charge celle vers lequelles tu te deplace. En fait ce ne sont pas des moteur sans temps de chargement, c'est juste que les chargement ne sont pas visibles pour l'utilisateur... Et le probleme de cette methode c'est qu'elle utilise une architecture nettement plus dure a mettre en oeuvre et qu'il faut bien regler les problemes de distance de vision et autre...

[shenron666]

erreur : Quake n'utilise pas les portal mais les PVS (potentialy visibility set) ou en francais zone de potentiellement visible. En gros ca consiste en toute zone de la carte a stocker l'ensemble des zone potentiallement visibles. ainsi lorque le jeu tourne, plutot que de tester la visibilitée de tout les objet, on ne test la visibilitée que de ceux qui le sont potentiellement (mais pas forcement si on leur tourne le dos...
Par contre Doom 3 lui utilise les portal ET les PVS... La solution de portal dans quake avait été envisagée mais ne donnait pas de resultat suffisament interessant a l'epoque. Pour plus d'info sur le moteur de quake, lire les text de michael abrash qui a bossé avec carmack sur le moteur (il sont dispo sur le net...)

autant pour moi, merci pour ces précisions

en fait les PVS gardent des infos du genre : "si je suis dans la zone 1 je peux voir les zones 2, 5 et 7" ?

[moa378]

Merci pour ces précisions je trouve tout cela extrement interessant.
J
e sens que je vais me mettre a la prog de jeu (enfin si je trouve le temps). Je ferai le meilleur jeu de tout les temps et deviendrai pls riche que bill gate et ...........

Bon ok je vais faire un tetris.

[shenron666]

lol, quitte à faire un jeu, même petit, trouve une idée qui te permettrait d'appliquer les principes auquels tu t'es interressé ici

quoique tétris il y a la liste des briques possibles avec leur configuration

sinon pourquoi pas un petit rpg ?

[moa378]

parce que ce serait un peu dure pour debuter.

Je pensais attaquer (un peu plus tard pour le moment g pas trop le tps) par une sorte de creatures (pour ceux qui connaissent ) en 3D. Ca permet de toucher a un peu tt et en aprticulier a l'IA mais bon pur debuter je pense que je vais faire comme tout le monde et commencer par faire qulques conneries deja faites 50 fois mais bon c pour la formation (pong, casse brique puis peut-être un morpion 3D (faut que je reflechisse si ça va pas merder le principe là...) et apres j'attaquerais peut-être si je suis pas deja a la retraite quoique au moins j'aurais le tps....

[bafman]

en fait les PVS gardent des infos du genre : "si je suis dans la zone 1 je peux voir les zones 2, 5 et 7" ?

voila en gros c'est ca... d'ou le probleme lorsque le niveau commence a etre gros, car ca signifie une explosion combinatoire des possibilitée de visibilitée... (et en plus ca fait un explosion de memoire necessitant l'utilisation de bitfield plutot que de booleen...)

moa378 => Tout a fait d'accord avec toi, il faut mieux commencer simple et terminer que de vouloir commencer tout de suite par refaire Doom 3