¿Rellena todos los datos de su juego en grandes tablas de Excel? ¿Hay algún método mejor?


8

Realmente quiero saber cuántos diseñadores de juegos prefieren trabajar con una mesa enorme para todos los artículos, otra mesa para todas las habilidades e incluso otra mesa para todos los mobs en un MMORPG. Y estas tablas pueden crecer hasta varios cientos de MB con miles de registros, pero la mayoría de los registros solo usan unos pocos campos en una tabla.
Sé que algunos diseñadores de juegos funcionan de esta manera. ¿Hay algún método mejor?


1
¡Guauu! Dígale a su amigo diseñador de juegos que al menos considere algo como SQLite :)
bummzack

@bummzack: SQLite es una base de datos relacional. Excel es una hoja de cálculo. Un RDB puede ser (mal) reemplazado por un programa de hoja de cálculo, pero no puede reemplazar un programa de hoja de cálculo con solo un RDB.

(Tengo un sinfín de anécdotas profesionales sobre por qué Excel es genial / horrible para este tipo de cosas, que podría escribir en un día o dos si creo que puedo hacerlo sin ser demandado, pero espero que alguien tenga más pruebas basada en respuestas.)

1
Supongo que interpreté mal el contexto aquí. Pensé que esto se usaría como fuente de datos del juego y no como una "herramienta de diseño".
bummzack

¿Alguien ha pensado en usar archivos XML para este propósito?
James P.

Respuestas:


4

No quería responder aquí, pero cuando vi otra respuesta / comentarios cambié de opinión. SQL no es una muy buena solución para esto. SQL define tablas e inserta muchos datos en esas tablas. Este no es ese caso. Al crear / probar el diseño del juego, en su mayoría desea verificar si el gran sistema está equilibrado. Eso significa muchas tablas que se afectan entre sí. No hay nada bueno para SQL realmente, o lo es, pero no es fácil de manejar, porque tienes que hacer una programación que no es necesaria. Y el diseñador de juegos no tiene que saberlo.

Como programadores / desarrolladores de juegos, podemos despreciar Excel y su uso para cualquier cosa, pero es una herramienta bastante buena para este caso, especialmente cuando el diseñador de juegos puede usarlo bien y el documento está bien creado.

No puedo recomendar ninguna otra herramienta, pero puedo decir que conozco diseñadores de juegos profesionales que también usan Excel. Así que supongo que es una herramienta común.


Sí, Excel es una herramienta común. El punto de la pregunta es: "una sola mesa enorme para todos los artículos", los artículos incluyen equipos, consumos, etc. ¿Es necesario dividir el enorme en pequeños? ¿Incluso un archivo de configuración separado para cada elemento? Me temo que la gran mesa puede lastimar sus ojos: o)
Huang F. Lei

Lo siento, no se esto. Soy programador de motores. Solo quería decir "Hola, ¿por qué todos dicen SQL y hacen bromas de Excel, cuando es una herramienta común?". La pregunta es buena y estoy interesado en una respuesta sofisticada, mejor que la mía.
Notabene

Mi respuesta SQl original se debió a que me perdí la parte de la pregunta del 'diseñador del juego' y la eliminé porque sería engañosa.
El pato comunista

3

Estoy de acuerdo con la mayoría de los que responden que a veces las hojas de cálculo pueden ser herramientas de desarrollo decentes, especialmente para los diseñadores.

Si está interesado en llevar este enfoque más allá, el programa de hoja de cálculo Resolver One usa python para la creación de secuencias de comandos, lo que facilita la configuración de una hoja de cálculo para diseñadores que realiza modelados complejos y exporta a un formato de datos amigable para el juego. Me resulta mucho más fácil trabajar con VBScript de Excel.


1
¡diviértete esperando varios segundos para que se abra! Bah es lento (incluso en máquinas rápidas)
Spooks

2

Excel es una excelente solución. Me había estado preguntando cómo debería hacerse esto. Pero pensando en ello, Excel es una herramienta muy popular y bastante adecuada para esta tarea, no recomendaría esta práctica. Además, la base de datos real, como sugiere @notabene, trae una gran cantidad de sobrecarga adicional que realmente no es necesario. Veo un par de opciones, una de las cuales es similar a usar Excel:

  • Open Office Calc: gratis. También hay una descarga de conector MySql (código abierto, creo) para Calc.
  • datos serializados: XML o binario (cifrado)

... de cualquier manera, gratis y tienes el control completo.

Personalmente, me inclinaría por los datos binarios serializados y cifrados . Dos razones:

  • los datos del juego no pueden ser manipulados fácilmente
  • Puedo trabajar con tablas de datos en lugar de la serialización Xml de conjuntos de datos, es decir , tengo la opción.

¿Existe la necesidad de una biblioteca de datos dedicada y orientada al juego ? Tal vez ... a menos que alguien sepa de tal biblioteca que ya existe.

En cuanto a la pregunta del OP, mire cada archivo csv de la página como una tabla de datos única, similar a una tabla en una base de datos. Cada archivo de página debe contener datos relacionados:

  • Habilidades, o
  • Engranaje, o
  • NPC stats

Esto te ayuda a mantener un alto nivel de organización, lo cual será muy importante a medida que el contenido de datos crezca, el contenido del juego se expanda, etc.

Editar
Después realidad de intentar utilizar .ods (archivo Calc OpenOffice) y la conexión desde una aplicación, que es en realidad no es posible como mensajes iniciales en el sitio OO implícita. No pude encontrar nada que muestre específicamente el codez en la implementación.

Además, el uso de archivos de Excel puede estar bien mientras se desarrolla un juego para que los datos se puedan modificar sin sobrecarga de una base de datos. Sin embargo, y esto es importante, si planea hacerlo, debe tener instalado MS Office para poder hacer referencia a Microsoft Excel Interop COM. Esto puede ser beneficioso al principio, pero no me gustaría eliminar o cambiar un montón de código para tener una aplicación lista para Alpha, Beta o RC. Una biblioteca muy simplificada requeriría más esfuerzo del que podría ver útil.

Voy a usar archivos .CSV para el almacenamiento de datos en una etapa temprana. Hay algunos inconvenientes, pero en general creo que esta es una opción mucho mejor. Todo está contenido en mis bibliotecas. .Net tiene clases muy útiles para leer estos archivos de texto. Además, como archivos .CSV, los datos se manipulan fácilmente; y, para las etapas posteriores del desarrollo, todo lo que necesito hacer es tener mis archivos de datos serializados a XML, luego más tarde a binarios cifrados serializados.


No me molestan los votos negativos ... excepto cuando no sé por qué. ¿Hay algo incorrecto sobre las opciones que proporcioné o mi consejo para organizar una hoja de cálculo? ¿O a alguien simplemente no le gustaron mis opciones?
Resumen de

Le di -1 porque comparó una hoja de cálculo con un formato de datos de disco, y luego hizo declaraciones como "los datos del juego no pueden ser manipulados fácilmente". Un programa / interfaz y un formato de datos de disco no son realmente comparables, y hacer que los datos binarios de su juego hagan muy poco para disuadir a los modders. Además, su esquema de hoja de cálculo propuesto es horrible, ya que mantiene todos los datos en un archivo. Ciertamente, las habilidades y los NPC deben estar en archivos separados ; quizás todos los NPC deberían estar en páginas separadas en el mismo archivo , aunque si usa un RCS de bloqueo, eso también será horrible.

Estoy en desacuerdo. Tome Open Office Calc con el conector MySql. Seguro que puedes crear un archivo diferente para cada uno. Pero no esperaría mantener mis datos en este formato una vez que tenga un RC.
IAbstract

Si los diseñadores están utilizando Excel, que van a pasar los datos entre sí en formatos como .xls o .csv. Si no desea perder esos datos en un agujero negro de Outlook o cuando su computadora falla, debe enseñarles a mantenerlos en el RCS.

1

Siempre que la naturaleza de sus datos permita que se almacenen en una hoja de cálculo sin saltar demasiados aros, tendrá un formato muy bueno, especialmente para el trabajo de desarrollo. Al final, es posible que desee almacenarlo en otros formatos para su uso, pero la hoja de cálculo le brinda un editor muy potente que puede ser MUY agradable si decide cambiar la forma en que maneja algo.

Si está usando Excel, obtenga una copia de las utilidades ASAP: convierte la hoja de cálculo en un editor aún mejor.


Lo antes posible? ¿Puedes proporcionar un enlace?
Resumen de


-2

Bueno, para mí, creo que los programas de hoja de cálculo no pueden manejar esas cosas de manera correcta y efectiva. RDB fue diseñado, en realidad, para manejar grandes datos y tablas. Los RDB modernos fueron diseñados para manejar el tipo de cosas 'enormes' y lo están haciendo muy bien.

El punto es que, para obtener la mejor salida del RDB, necesita diseñar su base de datos de la manera correcta. Si su esquema de datos era deficiente o no cubría todos los datos de su proyecto, terminará con muy malos resultados, rendimiento y resultados.

La idea de RDB es dividir una tabla enorme en otras más pequeñas para que pueda mejorar el rendimiento y la legibilidad. Si tiene una tabla muy grande (atributos sabios o incluso registros sabios) o muchas reparticiones, y no usa la mayoría de ellas, eso significa que su diseño de la base de datos tiene algunos errores.

En su pregunta Huang F. Lei, si me pidieran que diseñara una base de datos MMORPG, no agregaría todas las habilidades en una tabla y todos los mobs en una tabla. Dividiré las habilidades de acuerdo a sus clases y uso en múltiples tablas. Cada tipo de habilidad tendrá su propia tabla o incluso tablas. Para las turbas, las dividiré según sus tipos o según su ubicación en diferentes mundos. Y así.

De esta forma, puedo reducir el tamaño de las tablas, facilitarme el seguimiento de los datos y mejorar el rendimiento de la base de datos.

En Excel, por otro lado, todos los datos se 'desmenuzarán' en un solo lugar. y encontrar una pieza de datos es casi intransitable, épicamente cuando tienes datos repetidos. Además, a medida que los datos crecen en tamaño, el tiempo de apertura del archivo aumentará.

Al final, Excel, en mi opinión, es una forma muy pobre de manejar grandes datos relacionados.


Tienes razón, pero esta no es la respuesta correcta. Si lees la pregunta detenidamente o lees otras respuestas o comentarios, sabrás que la pregunta es sobre el diseño del juego, no sobre el almacenamiento de datos.
Notabene

Sé que se trata del diseño y el rojo de las preguntas y respuestas. Lo que entiendo es que, Huang F. Lei, está tratando de elegir entre RDB y hoja de cálculo. Mi respuesta tratando de mostrar la diferencia entre los dos!
Ali Albahrani

Cita: Huang F. Lei: "Sí, Excel es una herramienta común. El punto de la pregunta es:" una sola mesa enorme para todos los artículos ", los artículos incluyen equipos, consumo, etc. ¿Es necesario dividir la enorme en ¿pequeños? ¿Incluso archivos de configuración separados para cada elemento? Me temo que la gran mesa puede lastimar sus ojos: o) "
Notabene

2
Gracias por su respuesta: o) La pregunta es sobre cómo el diseñador del juego proporciona datos para crear el juego, no sobre cómo el programador almacena / accede a los datos del jugador en el juego.
Huang F. Lei
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.