Bases de datos en videojuegos

Archivado
Hola a todos, un amigo y yo estamos desarrollando un juegode digamos.. "accion" en 2D, le estamos haciendo en Sdl.Net y la cuestion que me surgio hace tiempo ya, y que tengo que empezar a implementar ya por estas alturas, es como cargar los recursos en el juego, ya que no quiero que los sprites queden al alcance de cualquier persona que abra la carpeta sprites etc.. por lo que habia pensado implementar una base de datos donde ademas de guardar los datos del juego (records, logros...) tambien guarde sprites, fondos sonidos.. y al iniciar el nivel y demas simplemente se hace una consulta y lo cargamos todo a sus correspondientes objetos, la idea la tengo mas o menos clara, la duda me surge, en si esto no es aconsejable por alguna razon que desconozco, y de paso si alguien me dice si esto no es posible de hacer con SQL Server 2008, ya que en principio iba a realizarlo con MySQL pero por problemas de presupuesto (hay que pagar por usar bbdd offline) no puedo hacer, y access es un suicidio para cargar imagenes. basicamente lo que pido por tanto es eso, si alguien sabe de algun impedimento, y consejo sobre SQL server ya que nunca lo he usado, y al tener version express es el que ahora mas me llama la atencion.
Un saludo y gracias :D
Ni os molestéis, las BBDD relacionales no fueron diseñadas nunca para almacenar datos binarios en cantidades tan enormes, además del gran overhead que produce tener corriendo un servidor de base de datos en el mismo equipo en el que se juega. Olvidad la idea porque es enormemente descabellada.

Para temas de datos de records, logros, etc si que es aconsejable una BBDD pero ligera, como SQLite, que es una base de datos incrustada en el propio proceso del juego y que no produce una penalización de rendimiento excesiva ni mientras se ejecuta el juego ni cuando ha dejado de ejecutarse.

Para los assets, os recomiendo que u os implementéis vuestro propio sistema de ficheros virtual cifrado para almacenar todos los assets en un solo fichero o useis un zip con contraseña. En ambos escenarios la librería Zlib es vuestra amiga.

Saludos.
Voto por lo mismo. Es lo que ha hacían en quake, aunque estos usaban directamente un zip con la extensión cambiada.
Muchas gracias, la verdad es que andaba un poco perdido en lo que son estos temas de las bases de datos ya que yo es lo que mas veo en clase y pensaba que podria hacerse estilo a access pero con rendimiento en cosillas como oracle o MySQL asi que nada pasare del tema y me programare con arrays algo del estilo jejej
Muchas gracias
las base de datos vienen bien cuando desarrolláis un juego tipo MOORG en navegador por que puedes tener un Servidor WEB en un equipo y en otro el servidor de la base de datos
es ideal para juegos tipo travian, ogame etc..etc..
también si quieres mas velocidad puedes optar con base de datos no relacionales (NOSQL) ejemplo "mongoDB"

puedes usar archivos de texto o algún procedimiento para guardar datos de juego como "save game"

o hacer archivos de datos para guardar montajes de mapas que solo contengan arrays en si que carguen por pantalla
hay muchas formas de guardar o de cargar mapas


pd: hay base de datos gratuitas lo que pasa que montar una base de datos en un juego tira mucha maquina si no tiene mas remedio puedes intentar con una "nosql" como mongoDB sin llevarla al limite y si quieres potencia barata pero esto come maquina progreSQL
Creo que no se refería a eso. En el caso que comentas (es decir, para guardar datos del juego) la utilización de BD en juegos está bastante extendida, pero en el caso al que se refería el (almacenar recursos como imágenes, modelos o sonidos) no.

Por ejemplo, UFO:Afthermath utiliza una BD relacional para gestionar todos los datos del juego.
sqlite es tu amiga
6 respuestas
Archivado
Volver a Desarrollo