Discussion :

[ternel]

tu devrais aller jeter un œil un moment dans la section des tutos de 2D-3D-jeux, (dans Applications, mais mon proxi au taf me bloque cette page là)

Tu y apprendras beaucoup de chose sur un jeu.

Pour l'instant, écrit déjà un code, sans interface graphique, capable de représenter une situation du jeu:
Joueur, carte, position du joueur, inventaire du joueur.
Tu rajouteras ensuite des données telles que sorts du joueur, PNJ, table de monstres, proba de rencontre.

Et ensuite seulement, tu pourras afficher la situation.

Tout cela fait, tu pourras envisager de déplacer un joueur.

[devdeb91]

Bonjour

alors pour ce qui est joueur c'est déjà commencé depuis quelques jours et niveau inventaire la m’embête car j'ai opté pour deux solutions soit le contenu de l'inventaire dans une base de données sous mysql que le programme appellerai lors de l'ouverture de l'inventaire ou 2ème possibilité dans un fichier en lecture écriture dans lequel on stockerait le tout.

Que me conseillerais-tu ?

[r0d]

Par la je veux dire : prévois comment le moteur de jeu et le moteur graphique vont interagir (+moteur son éventuellement), prévois comment vont être gérées les ressources (textures / sons / scripts / etc..),

Bah, tu fais un bête MVC et ça roule tout seul. Niveau graphique et audio, la SFML fait presque tout le boulot. Il faut faire un peu attention aux ressources (images, sons, typiquement) mais ce n'est pas si difficile si on y réfléchit avant de se lancer.

Si j'ai un conseil important à donner, c'est de connaitre un minimum la bibliothèque que l'on utilise avant de se lancer dans l'implémentation, car certains détails de design (avant même l'implémentation) dépendent des dépendances.

Le problème du réseau est à prendre en compte le plus tôt possible: si tu veux que ton jeu soit jouable en multijoueur en réseau, alors il faut que tout soit prêt dès le début (architecture p2p ou 3 tiers à définir dès le début).

[r0d]

que me conseillerais tu ?

Gère tout en mémoire: à l'intérieur de ton programme, et de simple fichiers (plats ou xml si vraiment tu veux un truc très évolutif) pour la serialisation (sauvegardes). Les bases de données ne doivent être utilisées que lorsque le besoin s'en fait sentir.

[Iradrille]

mais mon proxi au taf me bloque cette page là)

proxy: anonymouse ou autres
vpn: securitykiss ou autres
Tor: ici
La sécurité sur Internet n'a jamais eu autant d'importance qu'aujourd'hui, svn et/ou Tor sont plus que "recommandés" à l'heure actuelle.

[devdeb91]

Gère tout en mémoire: à l'intérieur de ton programme, et de simple fichiers (plats ou xml si vraiment tu veux un truc très évolutif) pour la serialisation (sauvegardes). Les bases de données ne doivent être utilisées que lorsque le besoin s'en fait sentir.

donc si je comprend bien base de données en dernier recours, c'est bien se que je penser merci pour cette reponse

[r0d]

donc si je comprend bien base de données en dernier recours

Oui, et encore.
L'utilisation d'une base de donnée comporte de nombreux désavantages:
- Tant que les données n'atteignent pas une masse critique (plusieurs centaines de Go) c'est (beaucoup) plus lent.
- Si les données sont gérées en local, il faut que la base de donnée (le client et le serveur) soit installée sur la machine.
- Problèmes de portabilité parfois insolubles.
- Augmentation de la complexité (interfacer un programme natif avec une bdd n'est jamais trivial).

Et même, si un jour le besoin s'en fait sentir (trop de données à gérer), souvent il est préférable d'implémenter son propre gestionnaire de données.

[Iradrille]

Oui, et encore.
L'utilisation d'une base de donnée comporte de nombreux désavantages:
- Tant que les données n'atteignent pas une masse critique (plusieurs centaines de Go) c'est (beaucoup) plus lent.
- Si les données sont gérées en local, il faut que la base de donnée (le client et le serveur) soit installée sur la machine.
- Problèmes de portabilité parfois insolubles.
- Augmentation de la complexité (interfacer un programme natif avec une bdd n'est jamais trivial).

Et même, si un jour le besoin s'en fait sentir (trop de données à gérer), souvent il est préférable d'implémenter son propre gestionnaire de données.

Entièrement d'accord, utiliser une DB, c'est vraiment qu'en cas de besoin (centaines / milliers de joueurs, plus un MMORPG qu'un RPG :p)
Çà ajoute une complexité qui n'est pas forcément utile pour un premier jeu.
C'est vraiment une complexité inutile pour une découverte.

[devdeb91]

Oui, et encore.
L'utilisation d'une base de donnée comporte de nombreux désavantages:
- Tant que les données n'atteignent pas une masse critique (plusieurs centaines de Go) c'est (beaucoup) plus lent.
- Si les données sont gérées en local, il faut que la base de donnée (le client et le serveur) soit installée sur la machine.
- Problèmes de portabilité parfois insolubles.
- Augmentation de la complexité (interfacer un programme natif avec une bdd n'est jamais trivial).

Et même, si un jour le besoin s'en fait sentir (trop de données à gérer), souvent il est préférable d'implémenter son propre gestionnaire de données.

ok donc les base données c'est rayer deja un point sur lequel je pourrai commencer a voir merci

[r0d]

niveau inventaire la m'embete car j'ai opter pour deux solution soit le contenue de l'inventaire dans une base de données sous mysql que le programme appelerai lors de l'ouverture de l'inventaire ou 2eme possibilité dans un fichier en lecture écriture dans lequel on stockerai le tout.

Je disais précédemment qu'il vaut mieux tout gérer en RAM et n'utiliser des fichiers que pour les sauvegardes. Mais en fait, une autre approche est possible: gérer les données dans des fichiers. L'énorme avantage c'est que si le jeu plante, lorsque tu relance le jeu tu pourras le retrouver dans l'état qu'il était lorsqu'il a planté. L'inconvénient, c'est que tu perds en performance et ça rajoute une couche de complexité. En effet, la gestion des fichiers est toujours un peu plus complexe que la RAM qui, il est toujours bon de le rappeler, est largement gérée par les objets de la bibliothèque standard du c++.

Mais quoi qu'il en soit, et c'est très important: ne te préoccupes surtout pas de problèmes de performances aussi tôt.

[devdeb91]

Ça ça risque pas les problèmes de performance seront en dernier recours car ce projet n'est pas pour forcement utilisé il est juste la pour m'apporter un + au niveau connaissance et pour concrétiser mes connaissances déjà présentes.

[Iradrille]

Je disais précédemment qu'il vaut mieux tout gérer en RAM et n'utiliser des fichiers que pour les sauvegardes. Mais en fait, une autre approche est possible: gérer les données dans des fichiers. L'énorme avantage c'est que si le jeu plante, lorsque tu relance le jeu tu pourras le retrouver dans l'état qu'il était lorsqu'il a planté. L'inconvénient, c'est que tu perds en performance et ça rajoute une couche de complexité. En effet, la gestion des fichiers est toujours un peu plus complexe que la RAM qui, il est toujours bon de le rappeler, est largement gérée par les objets de la bibliothèque standard du c++.

Mais quoi qu'il en soit, et c'est très important: ne te préoccupes surtout pas de problèmes de performances aussi tôt.

fichier gérer par la stl (ou equivalent) -> ça plante, c'est pas forcément sauvagardé (buffer), mais les lecture / écriture sont plus rapide.

Et entièrement d'accotrd sur le fait de ne pas s'occuper de comment sont fait les lectures / ecritures (c'est de l'optimisation ça, c'est pas quelque chose dont tu dois te préoccuper ... (tu ne prévois surement pas des dizaines de milliers de joueurs) donc osef ça ta structure tiendra le coup

[r0d]

fichier gérer par la stl (ou equivalent) -> ça plante, c'est pas forcément sauvagardé (buffer), mais les lecture / écriture sont plus rapide.

Oui mais bon, si justement on cherche à sauvegarder l'état du programme, on prendra garde à flusher son buffer à chaque opération d'entrée/sortie. De toutes façons, je suis partisan du flush systématique sur les i/o (utilisation de endl).

[devdeb91]

re bonjour

j'ai commencer le developpement du code source mais je bloque a un endroit j'arrive a déplacer le personnage mais quand il s'agit du changement d'endroit(exemple : rentrer dans une maison ou changer de lieu) bah sa bloque a certain endroit j'arrive a changer de map entre deux map mais aprés j'arrive pas plus donc ma question est auriez vous une idée de comment effectuer cela pour que je puisse changer de d'endroit comme je le veux ?

[Médinoc]

Personnellement, je ferais un certain nombre de valeurs de tiles (genre, une dixaine) de type "événement n°X" sur la map, et quand on marche dessus, on consulte les infos d'événements liées à la map, pour établir la correspondance "marcher sur telle case veut dire aller à tel endroit", etc.

Selon le degré de hard-codage voulu, la table d'événements de chaque map peut être directement un tableau de pointeurs de fonction, un bytecode, un script dans un langage de script...

[devdeb91]

J'avoue comprendre a moitié mais le problème est que j'arrive pas à mettre en œuvre moi j'avais pensé à une structure exemple room avec comme paramètre le nom de la map et les sorties existantes mais voila entre penser et le faire il y a une différence . Auriez-vous une idée ou peut-être des exemples à me donner ?

[Bousk]

Bonjour,

ce que tu demandes est beaucoup trop spécifique et totalement dépendant de ton architecture entre autre.
Il est pour ainsi dire impossible de t'aiguiller sur ces choix.

[Médinoc]

Si on fait abstraction des événements, on peut définir la carte simplement en terme de sorties. Mais je pense que ça va te compliquer la vie dès que tu voudras ajouter une histoire à ton jeu.

Dans ce cas, il faut savoir qu'une map a plusieurs sorties. Ces sorties peuvent être les bords, et peuvent aussi être des cases (entrées de batiments, etc.).

Si on simplifie à l'extrême, on peut définir que les bords mènent toujours aux maps adjacentes à moins d'être bloqués (façon Zelda) et on peut simplifier encore plus en limitant à une "case de sortie" par map (ce qui veut dire un seul bâtiment par map, attention!)

Auquel cas, les informations de la "case de sortie" sont simples:

• Position de la case
• ID de la map de destination
• Position d'arrivée sur la map de destination.

[devdeb91]

ok bah je vais plancher sur ça et reviendrai si jamais je ne me sors pas de cette impasse. merci a vous pour ces réponses

edit : voila à peu près ce que mon code donne pouvez-vous me dire comment palier à ce problème ( les ':' sont les endroit ou on change de map j'en ai mis deux pour que vous puissiez comprendre le problème)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
char Map[2][10][20] = {"###################",
                       "#@                #",
                       "#                 #",
                       "#                 #",
                       "#                 #",
                       "#    :            #",
                       "#                 :",
                       "#        +        #",
                       "#                 #",
                       "###################",
                       "###################",
                       "#                 #",
                       "#                 #",
                       "#                 #",
                       "#       +         #",
                       "#                 #",
                       ":                 #",
                       "#                 #",
                       "#                 #",
                       "###################"
 
                   };
 
bool Exit = false;
int inmap = 0;
int gamespeed = 200;
int main()
{
    int y, y2, x, x2;
    while(Exit == false)
    {
        system("cls");
        for(y = 0; y < 10; y++)
        {
            cout << Map[inmap][y] << endl ;
        }
 
        for(y = 0; y < 10; y++)
        {
            for(x = 0; x < 20; x++)
            {
                switch(Map[inmap][y][x])
                {
                case '@':
                {
                    if(GetAsyncKeyState(VK_UP) != 0)
                    {
                        y2 = y - 1;
                        switch(Map[inmap][y2][x])
                        {
                        case ' ':
                            Map[inmap][y][x] = ' ';
                            y--;
                            Map[inmap][y2][x] = '@';
                            break;
                        }
                    }
 
                    if(GetAsyncKeyState(VK_DOWN) != 0)
                    {
                        y2 = y + 1;
                        switch(Map[inmap][y2][x])
                        {
                        case ' ':
                            Map[inmap][y][x] = ' ';
                            y++;
                            Map[inmap][y2][x] = '@';
                            break;
                        }
                    }
 
                    if(GetAsyncKeyState(VK_LEFT) != 0)
                    {
                        x2 = x - 1;
                        switch(Map[inmap][y][x2])
                        {
                        case ' ':
                            Map[inmap][y][x] = ' ';
                            x--;
                            Map[inmap][y][x2] = '@';
                            break;
                        case ':':
                            Map[inmap][y][x] = ' ';
                            x = 17;
                            inmap--;
                            Map[inmap][y][x] = '@';
                            break;
                        }
                    }
 
                    if(GetAsyncKeyState(VK_RIGHT) != 0)
                    {
                        x2 = x + 1;
                        switch(Map[inmap][y][x2])
                        {
                        case ' ':
                            Map[inmap][y][x] = ' ';
                            x++;
                            Map[inmap][y][x2] = '@';
                            break;
                        case ':':
                            Map[inmap][y][x] = ' ';
                            x = 1;
                            inmap++;
                            Map[inmap][y][x] = '@';
                            break;
                        }
                    }
                }
                break;
                }
            }
        }
        Sleep(gamespeed);
    }
    return 0;
}

[Médinoc]

Déjà, es-tu sûr de ne pas pouvoir te passer de cases "sorties" sur les bords? C'est mieux si on passe à la map d'à-côté simplement en la quittant, je trouve.