Cargando datos para un RPG

8

Estoy creando un pequeño juego de rol de texto como una forma de practicar Python y me encuentro con una pregunta sobre cómo cargar datos. El juego es un juego del salvaje oeste, aunque eso no es demasiado relevante, y necesito almacenar listas de armas y sus propiedades, así como listas de personajes, escenarios, etc. Tengo una buena idea de cómo representar estos datos como clases, pero no estoy tan claro sobre cómo almacenar y cargar los datos.

Mi pregunta principal gira en torno a la relación entre datos y clases. He leído algunas publicaciones aquí en SE y muchas de ellas están relacionadas con el almacenamiento, por lo que tengo buena información allí.

¿Cuándo debo cargar esos datos? Por ejemplo, el jugador elige entre varias armas cuando comienza el juego. ¿Debo cargar todas las armas e instanciar todos los objetos de armas en ese punto? ¿Debería la clase de armas tener la capacidad de mostrar armas de la base de datos sin crear instancias?

Gracias por cualquier ayuda.

architecture python rpg file-format timfreilly
fuente

Respuestas:

7

Como dices un juego de rol de texto "pequeño", mi consejo sería simplemente precargar todo. Si no estamos hablando de una enorme cantidad de contenido, entonces no debería hacer una gran diferencia en el tiempo de inicio, y mantiene las cosas, como aconseja Bjorn, simples.

Algo que se me ocurre al leer su pregunta es que es posible que desee considerar la diferencia entre un arma y un tipo de arma . Mi preferencia siempre es tener una distinción clara entre los dos, y tener ambos modelados en código para poder hacer preguntas sobre el tipo de arma sin tener que tener una instancia a mano. (Una forma de hacerlo es hacer que el tipo de arma sea la clase, con métodos de clase que le permitan interactuar con él, y que el arma sea una instancia de esa clase. En realidad, no prefiero este enfoque porque es imposible o increíblemente desordenado para que un arma cambie de tipo. Obviamente, eso no será relevante para todos los juegos).

caos
fuente
¿Cómo diferenciarías esto en código? De hecho, me he encontrado con este problema.
timfreilly
1
Según tengo entendido, los tipos de armas son objetos administrados a través del patrón "conjunto de definición negociado" del que hablo en esta pregunta SO: stackoverflow.com/questions/401720/… , y cada objeto de arma sabe de qué tipo es Un código de identificación. Entonces podrías hacer obj->setWeaponType(WEAPON_TYPE_SHOTGUN)o lo que sea, y el arma se configura de manera apropiada. Las métricas de rendimiento de las armas pueden usar los valores del tipo como línea de base, pero la instancia puede modificar el resultado final. Esa clase de cosas.
caos
Eso es algo en lo que pensar, gracias por el enlace. ¿Qué haría en una situación en la que quisiera mostrar una lista de los tipos de armas disponibles? ¿Ese tipo de solicitud pasa por la versión de corredor / tipo?
Timfreilly 05 de
1
@timfreilly: Depende del contexto. Si es algo así como una tienda, normalmente tendría el lugar abastecido con instancias reales de armas y mostraría sus descripciones al jugador. Si se trata de una descripción general del desarrollador o una interfaz de ayuda, entonces le pediría al corredor de demonios el conjunto completo de definiciones de tipos de armas y mostraría información sobre ellas.
caos
4

Cargue todo al inicio. No complique su programa dividiendo los datos entre la memoria y el disco a menos que sea necesario (por ejemplo, cuando hay demasiado para guardar en la memoria a la vez).

Lo importante es comprender la distinción entre los datos que representan instancias de un elemento y los datos que representan el tipo de elemento. Generalmente, varias instancias de la primera comparten una instancia común de la segunda.

Kylotan
fuente
Podría usar alguna información adicional allí. ¿Cómo codificar esta diferencia?
Timfreilly 05 de
1
@timfreilly: Tengo una jerarquía de clases de muestra para un sistema de elementos como Kylotan describe en gamedev.stackexchange.com/questions/4516/… ; Esto a menudo se llama el patrón de peso mosca.
Como dice Joe, el patrón Flyweight es una forma de presentar esto, compartiendo implícitamente esos datos de "tipo" en todas las instancias. Personalmente prefiero representarlos explícitamente, por ejemplo. con una clase MonsterInstance y una clase MonsterType. Cada instancia de MonsterInstance tiene una referencia a su instancia relevante de MonsterType.
Kylotan 05 de
(También haría lo que dice Kylotan, todavía lo llamaría un objeto de peso mosca).
0

No estoy muy familiarizado con Python. El consejo general que daría es que sea simple. Dijiste que ya tenías una idea de cómo representar los datos. Si tiene algunas clases para los datos que desea almacenar, puede almacenarlos en una lista. Esa lista se puede serializar en el disco onSave y deserialized onLoad. Para una primera implementación y si los datos no son tan grandes, cargaría todo al inicio del juego y lo guardaría en algunos momentos.

Bjorn
fuente
0

Podrías usar SQLite . Con SQLite, puede crear bases de datos en la memoria y en el disco duro, y no necesita un DBMS gigante como MySQL instalado.

grizwako
fuente