Buenas.
Para las practicas de la uni estoy haciendo un "miniclon" de un rpg (el zelda, que es del que mas graficos he encontrado) en java. La verdad es q aunque a velocidad lenta, todo avanza.
Como veo que la cosa avanza me han surgido dudas tecnicas que hasta ahora no me habia planteado. Demomento con el interfaze serialization me ha funcionado bien para guardar/cargar datos. Pero ha llegado un momento que me pregunto si con eso es suficiente. Tengo varias clases con String[] y boolean[], y una clase que quizas grabandola a mano ocupase un par de kbs, con serialization ocupan 5, 6 o incluso 8 veces mas.
Ahora bien, la solucion no la tengo del todo clara.....es mejor olvidar serializacion y crear un cargador?? o seguir con serialization, pero buscar compresion?? o incluso olvidarnos de serialization, implementar un cargador y buscar compresion???
Aparte, la mayoria de los String se repiten (sobretodo en los mapas, de cara a los path a los tiles).....es "normal" guardar cada string en cada mapa, o crear una clase de recurso de string para guardar solo el indice del string????
GRACIAS!!!
No recuerdo como se puede personalizar la serialización en Java, pero si se puede personalizar, yo tiraría de serialización de momento y cuando necesites más rendimiento o lo que sea, te puedes implementar tu unos serializadores propios y listo.
Al menos en .NET lo haría así, supongo que en Java debe poder hacerse algo parecido...
Un saludo!
Vicente
Es complicado responder de manera detallada sin tener un planteamiento detallado del problema en cuestión.
¿Serializar con las herramientas proporcionadas por la librería estándar del lenguaje o manualmente? Depende.
¿Guardar una única copia de los mismos datos o permitir redundancias? Depende.
En el caso de la serialización, por ejemplo, existen dos opciones claramente divergentes (almacenar en texto o en formato binario) y varios niveles de sofisticación para cada una de ellas (qué condiciones debe cumplir una clase para ser serializable). ¿Qué necesitas exactamente? Una vez respondida esta pregunta, ¿cuál es el método que merece la pena utilizar (en términos de "retorno de la inversión") para satisfacer las necesidades establecidas?
Yo no entiendo de estas cosas, y solo tengo una idea vaga de lo que es serializar, pero esta es mi opinion:
Para savegames, serializar sera el metodo mas robusto y logico. Como referencia, Quake1 y todos los siguientes Quakes, utilizaban serialización para savegames. Asi que si programadores de C hacen en una cosa concreta con serializacion, es porque tenian buenos motivos.
Para cargar recursos graficos, si son miles, pues no, una carga que con binarios ocurria en medio segundo, se prolonga a 11 segundos. Le estas robando al juego mucha gracia, añadiendo esas pantallas de carga.
Si son menos de 100 recursos, incluso aunque esten serializados, aunque añadan a una carga de medio segundo, otro medio segundo, pues al usuario no le importa.
Es una cuestion de cuanto y que quieres serializar, y creo que esos cuanto y esos que no quedan claros en tu mensaje.
Por supuesto, no creo que sea una buena idea serializar objetos. Serializa datos lo que quiera, pero no "codigo" (?). Puede que encuentres que la serializacion no es portable entre tu maquina de produccion, y la del jugador. Aqui seguramente se aplican los consejos sobre serializar objetos java a una base de datos.
Cita de: "Tei"Por supuesto, no creo que sea una buena idea serializar objetos. Serializa datos lo que quiera, pero no "codigo" (?). Puede que encuentres que la serializacion no es portable entre tu maquina de produccion, y la del jugador. Aqui seguramente se aplican los consejos sobre serializar objetos java a una base de datos.
Serializar objetos en Java y .NET es lo que toca ya que todo tipo de dato en estas plataformas es un objeto. Serializar el objeto basicamente es generar una estructura con los valores de los miembros publicos del objeto, nunca se serializa codigo, por otro lado tambien se pueden definir que quieres serializar del objeto especificando y definiendo el contenido de los miembros que quieras. Sobre portabilidad, a parte de la serializacion binaria (que hoy dia incluyendo ya a los Mac y otras plataformas similares dentro la arquitectura x86, no deberia haber problemas supongo) se puede y se suele serializar a XML, por lo que la serializacion generada seria totalmente portable.
Salu2...
Buenas.
Siento no haber dado mas datos, si veis que ahora me dejo algo sed libres de preguntar :D
Para los savestates ya tengo claro que usare serialization...aunque serializar a xml no lo conocia. La cuestion esta en los mapas. Demomento como no tengo toda la clase completa, voy guardando cada uno de sus componentes internas de forma independiente, pero cuando este minimamente completa utilizare serialization del mapa entero.
La pregunta de buscar un metodo de serializacion diferente o compresion es para reducir el uso de hd repercutiendo lo menos posible en el tiempo de carga y tiempo de procesador.
Sobre recursos graficos.....en java no permite serializar imagenes, asi que lo que hago es guardar el path a la imagen. Esto es una de las razones por lo q pregunte de crear una clase de recursos de texto...aun no lo tengo todo planteado, y puede que si un tile termina collevando ciertas caracteristicas puedo centralizar en esa clase esas caracteristicas.
Como veis ni yo mismo tengo claras mis dudas :S:S
GRACIAS
Cita de: "shephiroth"Para los savestates ya tengo claro que usare serialization...aunque serializar a xml no lo conocia.
Se ve que para mi la serializacion es reciente (desde que he saltado a .NET) por que siempre di por hecho que la serializacion se hacia a XML y a que a binario era menos comun, curioso :lol:
Cita de: "shephiroth"Sobre recursos graficos.....en java no permite serializar imagenes, asi que lo que hago es guardar el path a la imagen. Esto es una de las razones por lo q pregunte de crear una clase de recursos de texto...aun no lo tengo todo planteado, y puede que si un tile termina collevando ciertas caracteristicas puedo centralizar en esa clase esas caracteristicas.
Yo lo que hice fue crearme una 'estructura maestra' para definir la informacion de un nivel, esta contiene un par de miembros con informacion general (nombre y ubicacion inicial del nivel por ejemplo) y dos coleciones, una del tipo de mi clase Tile, dicha clase tiene un miembro publico que guarda el path de la textura, y otra colecion del tipo string que contiene la ruta de las texturas asociadas a los tiles del nivel. De esta manera, cuando quiero exportar un nivel a archivo lo que hago es serializar la 'estructura maestra' a XML en un solo paso. Para la carga seria practicamente lo mismo, deserializar el archivo XML y volcarlo en la 'estructura maestra' y despues recorrer las colecciones regenerando primero los objetos textura y despues los tiles mediante la informacion contenida en las estructuras de las colecciones, un par de foreach al caso. Supongo que sera similar a lo que tendras implementado.
Salu2...
P.D.: Una pregunta relacionada, pudiendo serializar a XML merece todavia la pena serializar a binario? De ser asi, por que motivos respecto hacerlo a XML?
Ya que has tocado el tema, aprobecho.
El primer dilema con el q me encontre en java (aunque quizas se deba a inexperiencia) es q al dibujar una imagen no puedes definir las coordenadas internas de la imagen quieres dibujar, sino que tienes q restringir la zona de la pantalla donde quieres dejar que dibuje y luego dibujar la imagen de forma que encaje lo q quieres dibujar el sitio deseado. Aunque en muchos sitios explicaban el tema del mapeado por tiles basandose en una misma ninguno trabajaba en java, por lo q dicho problema no existe. Por esta razon cada uno de los tiles es representado por una imagen.
Hasta ahora el mapa contenia un vector con path de cada imagen, un vector paralelo al anterior que identifica la dureza del tile, algunos valores enteros (tamaño de mapa, nº de capas...), un array bidimensional por cada capa y un array de acciones (aqui faltan cosas...lo se :D).
Lo que estoy viendo es q si centralizo la carga de tiles en una clase, tanto los vectores utilizados (el del path y el paralelo) como otras posibles futuras peculariedades de los tiles me las ahorraria, solo necesitaria el array de tiles.
Llegados a este punto se me plantean dudas de si (tiempo invertido)/(tiempo de carga)/(ahorro hd)/(gasto en memoria).............de si seria mejor que me quedase callado xDD
* I love "Duplicados" *
No se si he entendido bien el ultimo post :P
Cita de: "shephiroth"Llegados a este punto se me plantean dudas de si (tiempo invertido)/(tiempo de carga)/(ahorro hd)/(gasto en memoria).............de si seria mejor que me quedase callado xDD
Te refieres a tener toda la informacion del tile en un mismo objeto/clase en vez de diferentes arrays para cada cosa (grafico, dureza, accion, etc...)? Pues hombre, supongo que sera mas comodo que tenerlo todo separado (mas organizado seguro) pero sobre velocidad de carga y lectura, creo que seria mas rapido crear un solo objeto por tile con toda la informacion que 4 objetos por tiles para cada dato. Ojo, que no soy un guru en cuanto a rendimiento y demas lindezas en cuanto a ingenieria de software y esas cosas, que quizas me equivoque sea mas optimo lo primero, yo siempre suelo tirar mas por el camino de simplicar y acomodar la programacion que al rendimiento, aunque siempre buscando un minimo equilibrio (a ciegas, claro :P)
Salu2...
P.D.: Si esto no tiene que ver con lo que preguntabas aclara un poco la cuestion, que a estas horas no esta uno muy despierto que digamos xD
Cita de: "shephiroth"Buenas.
Siento no haber dado mas datos, si veis que ahora me dejo algo sed libres de preguntar :D
Para los savestates ya tengo claro que usare serialization...aunque serializar a xml no lo conocia. La cuestion esta en los mapas. Demomento como no tengo toda la clase completa, voy guardando cada uno de sus componentes internas de forma independiente, pero cuando este minimamente completa utilizare serialization del mapa entero.
La pregunta de buscar un metodo de serializacion diferente o compresion es para reducir el uso de hd repercutiendo lo menos posible en el tiempo de carga y tiempo de procesador.
Sobre recursos graficos.....en java no permite serializar imagenes, asi que lo que hago es guardar el path a la imagen. Esto es una de las razones por lo q pregunte de crear una clase de recursos de texto...aun no lo tengo todo planteado, y puede que si un tile termina collevando ciertas caracteristicas puedo centralizar en esa clase esas caracteristicas.
Como veis ni yo mismo tengo claras mis dudas :S:S
GRACIAS
Puedes personalizar la serialización implementando readObject y writeObject de la interfaz ISerializable, con lo que podrías guardar las imágenes si quisieras en vez del path (las escribes y las lees como quieras).
Un saludo!
Vicente
*duplicado*