Chargement de données pour un RPG

8

Je crée un petit RPG de texte comme un moyen de pratiquer le python et je rencontre une question sur la façon de charger les données. Le jeu est un jeu du Far West, bien que ce ne soit pas trop pertinent, et je dois stocker des listes d'armes et de leurs propriétés, ainsi que des listes de personnages, de scénarios, etc. J'ai une bonne idée de la façon de représenter ces données en tant que classes, mais je ne suis pas aussi clair sur la façon de stocker et de charger les données.

Ma question principale tourne autour de la relation entre les données et les classes. J'ai lu quelques articles ici sur SE et beaucoup d'entre eux concernent le stockage, j'ai donc de bonnes informations là-bas.

Quand dois-je charger ces données? Par exemple, le joueur choisit parmi plusieurs armes au début du jeu. Dois-je charger toutes les armes et instancier tous les objets d'armes à ce stade? La classe d'armes devrait-elle avoir la possibilité d'afficher les armes de la base de données sans les instancier?

Merci pour toute aide.

— timfreilly
source

7

Puisque vous dites un "petit" RPG texte, mon conseil serait de tout précharger. Si nous ne parlons pas d'une énorme quantité de contenu, cela ne devrait pas faire une grande différence dans le temps de démarrage, et cela garde les choses, comme le conseille Bjorn, simples.

Une chose qui me vient à l'esprit, à la lecture de votre question, est que vous voudrez peut-être considérer la différence entre une arme et un type d'arme . Ma préférence est toujours d'avoir une distinction claire entre les deux, et d'avoir les deux modélisés en code afin que je puisse poser des questions sur le type d'arme sans nécessairement avoir une instance sous la main. (Une façon de le faire est de faire en sorte que le type d'arme soit la classe, avec des méthodes de classe qui vous permettent d'interagir avec elle, et que l'arme soit une instance de cette classe. En fait, je ne préfère pas cette approche car alors c'est soit impossible, soit incroyablement désordonné pour qu'une arme change de type. Évidemment, cela ne sera pas pertinent pour tous les jeux.)

— le chaos
source

Comment les différencieriez-vous dans le code? J'ai en effet rencontré ce problème.

— timfreilly

1

La façon dont je l'ai, c'est que les types d'armes sont des objets gérés via le modèle "ensemble de définitions négocié" dont je parle dans cette question SO: stackoverflow.com/questions/401720/… , et chaque objet arme sait de quel type il s'agit via un code d'identification. Vous pouvez donc faire obj->setWeaponType(WEAPON_TYPE_SHOTGUN)quoi que ce soit, et l'arme se configure de manière appropriée. Les mesures de performances des armes peuvent utiliser les valeurs du type comme ligne de base mais permettre au résultat final d'être modifié par l'instance. Ce genre de chose.

— chaos

C'est quelque chose à penser, merci pour le lien. Que feriez-vous dans une situation où vous vouliez afficher une liste des types d'armes disponibles? Ce type de demande passe-t-il par la version courtier / type?

— timfreilly

1

@timfreilly: Cela dépend du contexte. Si c'est quelque chose comme une boutique, j'aurais généralement le lieu rempli avec des instances réelles d'armes et afficher leurs descriptions au joueur. Si cela ressemble à une vue d'ensemble du développeur ou à une interface d'aide, je demanderais au démon du courtier l'ensemble complet des définitions de type d'arme et afficherais des informations à leur sujet.

— chaos

4

Chargez tout au début. Ne compliquez pas votre programme en divisant les données entre la mémoire et le disque, sauf si vous y êtes obligé (par exemple, quand il y a trop de contenu en mémoire à la fois).

L'important est de comprendre la distinction entre les données qui représentent des instances d'un élément et les données qui représentent le type d'un élément. Généralement, plusieurs instances de la première partagent une instance commune de la seconde.

— Kylotan
source

Je pourrais y utiliser des informations supplémentaires. Comment codez-vous cette différence?

— timfreilly

1

@timfreilly: J'ai un exemple de hiérarchie de classes pour un système d'objets comme Kylotan le décrit sur gamedev.stackexchange.com/questions/4516/… ; ceci est souvent appelé le modèle de poids mouche.

Comme le dit Joe, le modèle Flyweight est une façon de présenter cela, en partageant implicitement ce «type» de données entre les instances. Personnellement, je préfère les représenter explicitement, par exemple. avec une classe MonsterInstance et une classe MonsterType. Chaque instance de MonsterInstance a une référence à son instance MonsterType pertinente.

— Kylotan

(Je ferais aussi ce que dit Kylotan, j'appellerais quand même un objet poids mouche.)

0

Je ne connais pas très bien le python. Le conseil général que je donnerais est de rester simple. Vous avez dit que vous aviez déjà une idée de la façon de représenter les données. Si vous avez des classes pour les données que vous souhaitez stocker, vous pouvez les stocker dans une liste. Cette liste peut ensuite être sérialisée sur le disque onSave et désérialisée onLoad. Pour une première implémentation et si les données ne sont pas si grandes, je chargerais tout au début du jeu et l'enregistrerais à certains moments donnés.

— Bjorn
source

0

Vous pouvez utiliser SQLite . En utilisant SQLite, vous pouvez créer des bases de données en mémoire et sur le disque dur, et vous n'avez pas besoin d'installer un SGBD géant comme MySQL.

— grizwako
source