Haciendo experimentos con XUL:
http://www.servicios-dpi.com/fun/zelula2/index.php
(nota: requiere soporte de XUL, por ejemplo con Mozilla Firefox)
Me molaria mas hacer el mapa con html, en lugar de con xul, porque dadas la filosofia de xul el hacer objetos que se penetren unos a otros hay que utilizar una gigantesca cantidad de capas acumulativas (<stack>) lo cual puede producir pesadillas mas adelante.
Esta muy claro que usando html basico, el poner cientos de graficos gif ordenados en capas segun z-index seria algo para lo que un render de html esta preparado. Esto de acumular cientos de stack's me imagino que no.
En cualquier caso funciona.
Algo que he descubierto haciendo este experimento, es que el estado de los graficos animados es compartido. Si hay dos graficos de explosion, y uno de ellos termina la animacion. Cada vez que muestres ese mismo grafico solo mostrara el ultimo frame de la animacion. Esto reduce muchisimo la posible utilidad de los graficos animados, haciendo que o bien te inventas un hack para que no reconozca como iguales dos graficos de explosion, o bien no utilizas graficos de estos que se animan hasta el ultimo frame y luego se paran.
Haciendo experimentos con este tema he creado estas paginas:
http://www.servicios-dpi.com/fun/zelula/test.htm
Nota: tambien requiere Firefox, o soporte de XUL.
nota: los graficos no son mios, los he pillado de internet y modificado para mis intereses, solo son placeholders para vestir estos test tecnologicos
no conozco el XUL pero eso que muestras es muy parecido al mapa que estoy haciendo para la version final de goldpiece, y en mi caso con css + ajax se ve perfecto, y es muy facil de hacer :P
Que XULo :P
Cita de: "Alexpi"no conozco el XUL pero eso que muestras es muy parecido al mapa que estoy haciendo para la version final de goldpiece, y en mi caso con css + ajax se ve perfecto, y es muy facil de hacer :P
Cualquier cosa que hagas me molara mucho. Yo el mapa que tiene ahora mismo Goldpiece no me gusta. Lo unico bueno que tiene es que es al que la gente esta costumbrada, aunque eso es mucho.
El que tiene OGame que es un simple listado tiene su cosa. Mas que nada porque los graficos de los planetas son bonitos, y la gente pone nombres curiosos a los planetas y a ellos mismos. Tiene su poquitin de utilidad como "Agenda de direcciones" para vecinos :D
El que tu hagas, pues va a estar muy bien y sera muy interesante. Haber, ya tengo ganicas, y desde luego te deseo suerte :D
Se nota que controlas mucho del tema :)
Cita de: "josepzin"Se nota que controlas mucho del tema :)
No me hagas la pelota que me lo creo :D
Se nota que controláis mucho del tema :lol:
Cita de: "RobiHm"Se nota que controláis mucho del tema :lol:
¿Lo dices por los dibujos?
En realidad tengo tengo un esclavo que me los hace, The Gimp.
No son mios.
Wenas Tei,
Me parece muy interesante tu proyecto pues yo me inicié en la experimentación del desarrollo de un juego del estilo de los de Sierra (caesar, zeus, faraón) con gráficos isonométricos en html por medio de javascript. Aún no empleo ajax puesto que todavía no estoy en la fase de comunicación con el servidor, pero el caso es que, de momento, funciona muy aceptablemente, piensa que llego a manejar mapeados de unos 1000 tiles y se desplazan sin problema mediante un minimapa y eventos de ratón.
De hecho me pregunto si alguien estuviera interesado en compartir más experiencias de este tipo, recursos y, quien sabe, tal vez iniciar un proyecto conjunto.
Entre mis dudas están, por ejemplo, si existe alguna forma de crear el mapeado de los tiles directamente mediante css (yo lo hago mediante código javascript, bucles y demás), o si será viable almacenar la información de los cambios efectuados por el jugador en su mapeado a una base de datos mediante ajax: lo pregunto por lo del volumen de información, puesto que la idea final es elaborar un juego online multijugador, en el cual cada usuario tendría su propio mapeado.
Un saludo.
Cita de: "waveland"Entre mis dudas están, por ejemplo, si existe alguna forma de crear el mapeado de los tiles directamente mediante css (yo lo hago mediante código javascript, bucles y demás), o si será viable almacenar la información de los cambios efectuados por el jugador en su mapeado a una base de datos mediante ajax: lo pregunto por lo del volumen de información, puesto que la idea final es elaborar un juego online multijugador, en el cual cada usuario tendría su propio mapeado.
Las respuestas son Si, y Si.
Con CSS puedes modificar el fondo de una tile, sea esta tile un div, o una celda de una tabla. No se hasta que punto al navegador le gusta mas una cosa o la otra.
En algunos de mis experimentos he terminado usando siempre img. Porque tenemos el objeto image en javascript, el cual te aporta unas cuantas funciones interesantes.
Tampoco hace falta usar tiles para toda el area. Se puede poner un backgroun "general", por ejemplo arena, o agua. Y solo poner cosas donde hay una excepcion.
Lo del ajax te funcionara. Las peticiones las tienes que hacer asincronas, y son relativamente rapidas. He visto por ahi experimentos y parecer que es suficiente para una interactivida sencilla de mover un muñeco por el mapa, y decirle que combata con cosas.
Pero habria que experimentar con distintas bases de datos, y distintos servidores web. En principio tenemos Apache con MySQL, pero ninguno de los dos estan especialmente optimizados para velocidad. Asi que supongo que valdria la pena experimentar con SQLlite, y algun server sencillo. O experimentar con tablas en memoria de MySQL. O quizas no usar una base de datos para cosas muy dinamicas, sino un programa que este siempre en memoria, y contra el que se hacen consultas sencillas. Este programa deberia estar programado en un lenguaje que no haga facil crear leaks de memoria, y eliminando a PHP porque me fio que un php pueda correr indefinidamente sin dar problemas.
Enfin. Si quieres discutir cualquier punto, tecnologia o problema. Aqui estoy. Me gano el pan haciendo ajax. Tengo aplicaciones medianas, de 15.000 lineas escritas con ajax en cada esquina. He hecho algunas cosas interesantes, y me apasiona el tema. Me encantara cualquier cosa que quieras comentar. (nota: pero no soy administrador de sistemas, asi que solo puedo comentar cosas de programacion)
Gracias por tu respuesta Tei,
Ten por seguro que te haré más preguntas porque yo estoy, como quien dice, empezando en el mundillo del ajax y javascript avanzado :? , eso si, con mucha pasion :D
Un saludo!!
Tei, intenta echarle un ojo al cliente web del Dreamlords, es impresionante lo que han hecho (está en Java).
Un saludo,
Vicente
Cita de: "Tei"Pero habria que experimentar con distintas bases de datos, y distintos servidores web. En principio tenemos Apache con MySQL, pero ninguno de los dos estan especialmente optimizados para velocidad. Asi que supongo que valdria la pena experimentar con SQLlite, y algun server sencillo. O experimentar con tablas en memoria de MySQL. O quizas no usar una base de datos para cosas muy dinamicas, sino un programa que este siempre en memoria, y contra el que se hacen consultas sencillas. Este programa deberia estar programado en un lenguaje que no haga facil crear leaks de memoria, y eliminando a PHP porque me fio que un php pueda correr indefinidamente sin dar problemas.
¿Y que me dices de SQL Server con IIS y ASP, mejor o peor? por cierto, ¿a qué te refieres con leaks de memoria?
Cita de: "waveland"
¿Y que me dices de SQL Server con IIS y ASP, mejor o peor? por cierto, ¿a qué te refieres con leaks de memoria?
No se como de veloces seran esos. Mi experiencia es con Apache, MySQL y muy poca con ASP y SQL Server.
Un leak de memoria es cuando el programa coge memoria al sistema operativo, pero se olvida de devolverla. Se nota porque un programa con leaks de memoria crece y crece y cada vez parece que necesita mas memoria.
En teoria los lenguajes de scripting estan a salvo de esto, porque administran la memoria automaticamente, y los lenguajes con recolector de basura pueden tener leaks cuando se producen referencias circulares que impiden que los datos se liberen como deberian cuando han sido borrados.
Bueno, la verdad es que, aunque tengo mas experiencia de trabajo con ASP y SQLServer, me decanto mas bien por PHP y mySQL: me dan mas 'buena espina', con el añadido de que resulta mucho más barato (a donde irá a parar!!) :wink:
Ahora bien, tengo una duda que no se muy bien como abordar: ¿como procesas las rutinas programadas en un juego de este tipo?, es decir, cuando el jugador da una orden de 'construir', por ejemplo, supongo que lo tienes que almacenar en la base de datos para que se procese, en el momento específico, mediante un triger o similar en el caso de que el jugador abandone la página, ¿cierto?.
¿Y si lo que se tiene que procesar son eventos del juego programados, que no respondan a la intervención del usuario?
En resumen, como procesas los eventos del juego en un escenario offline, cuando el jugador no está con la página abierta?
No se si me he explicado bien, espero que si por que esto me tiene en ascuas!! :?
Puedes por ejemplo tener un programa "corriendo" en el servidor , revisando la finalizacion de construcciones , la llegada de ataques y demas , o bien , puedes aprovechar las conexiones de los jugadores al entrar , para hacer todo eso "pendiente".
En este hilo se hablo de algo relacionado con este tema , lo rescato por si ayuda a alguien
http://www.stratos-ad.com/forums3/viewtopic.php?t=5732&highlight=
Una forma seria programar una cola de acciones programadas, el servidor en cada frame no consume toda la cola, solo los eventos "caducados", y en orden cronologico. Realizado asi, te da igual si entre ejecucion y ejecución ha pasado un segundo, o dos meses.
El problema es que si han pasado muchas horas desde que se conecto un jugador, pues a lo mejor en lugar de consumir 30 eventos, tiene que consumir 3000. Y es mucho mas lento. La velocidad de ejecucion seria irregular, dependiendo de si eres el primero de la mañana, por ejemplo, o eres el segundo (si eres el segundo te va instantaneo).
Asi que parece que es interesante tener una aplicacion corriendo todo el tiempo, que invoque estos frames del servidor. Ademas esta tarea podria realizar labores de mantenimiento. Suponte que tienes una tabla de precios de productos. Podrias actualizar esta tabla cada 3 horas. O podrias regenerrar los ficheros del mapa como ficheros estaticos. De este modo cuando alguien los descargue, se descargara ficheros estaticos, lo que siempre es interesante. Enfin, que tener un servidor o tarea corriendo te puede servir para que todo funcione mucho mejor.
No he escrito nada de este estilo. Asi que tampoco me hagas mucho caso.
nota: Si te da por invocar una pagina del servidor desde cron. Estilo wget http://localhost/game/serverframe.php?do=rulea. Ten cuidado y ponlo con limitacion de intentos. "wget -t 1 http://localhost/game/serverframe.php?do=rulea". Sino wget cuando vea que hay un problema,lo hara mas grave pidiendo la pagina una y otra vez hasta que el servidor no tenga CPU suficiente..
Capiflash, interesante el hilo que posteaste.
Añado duda: que creéis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo así como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresión de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabéis donde puede estar el límite mas o menos?
creo que el límite depende de cómo lo implemente cada uno.
Si las solicitudes están en la base de datos, el cron job puede recoger varias de esas solicitudes cada X tiempo, según el orden en que se grabaron y ejecutarlas.
Si lo programas cada 24horas seguramente tendrá muchas más que hacer que si el job corre cada 1h por ejemplo.
Es decir, no creo que se sature el servidor, las bases de datos están hechas para eso, entre otras cosas para almacenar grandes cantidades.
Cita de: "waveland"Capiflash, interesante el hilo que posteaste.
Añado duda: que creéis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo así como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresión de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabéis donde puede estar el límite mas o menos?
cron es un programador de tareas, puedes programarle que ejecute lo que sea con la periodicidad que quieras. Por ejemplo cada viernes, o cada 15 minutos.
osea, es una opcion para hacer lo mismo:
- o usas un demonio
- o ejecutas una tarea con una periodicidad X.
El demonio puede ser mas delicado: No te interesa que haya leaks. Seria un desastre que hubiera un bucle infinito. Y tienes que disponer de un modo que si el demonio se muere, se relance. Y deberia ejecutarse al reiniciar el servidor, que se puede resetear solo por razones hardware.
con cron podrias ejecutar una aplicacion php de linea de comandos, o podrias invocar una pagina publica. lo de wget es invocando una pagina publica.
para un juego web hacer labores auxiliares en php tiene la ventaja de que reutilizas toda las librerias de la aplicacion. Sino se haria en Perl o algo asi.
Windows tambien tiene un servicio de ejecucion programada. Y si tienes contratado un hosting barato podria usarse para que tu ordenador invocara una pagina del juego web cada 30 minutos, corriendo asi los frames del servidor. Y evitando asi la necesidad de un servidor dedicado.
Aunque si se quiere hacer algo serio yo apostaria por PHP5 y MySQL4. Y a lo mejor un hosting barato no te da mas que PHP4 y MySQL3.
En general, hacer un daemon no es mucho más complicado, sólo que tienes que hacerlo "mejor" porque va a estar siempre corriendo, y deberías pues tener cierto control sobre si muere (que mande un mensaje o señal cuando muera), logs que genera, etc. Digamos que en comparación con un script auxiliar en cron, el daemon necesita más "envoltorio" alrededor de la misma funcionalidad para controlar ese tipo de cosas.
Hay situaciones en las que un daemon es 100% imprescindible. En el caso de un juego web, no creo que sea tan imprescindible. Pero aquí también juega en tu contra el tema servidor. O tienes servidor propio (o virtualizado), u olvídate de daemon porque te tendrás que conformar con un script ejecutándose en cron.
Y como ya han dicho, si tu aplicación está en PHP, una gran ventaja que tiene hacer el script auxiliar correspondiente en PHP es que puedes reaprovechar toda la funcionalidad de las capas de servicios y de dominio que tengas en tu aplicación/juego. Y eso es una gran baza porque además de ahorrarte tiempo, te aseguras que la arquitectura de tu software se respeta. Sino, pues eliges el lenguaje que mejor te venga, no tiene porqué ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solución compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)
Cita de: "Kr0n"Sino, pues eliges el lenguaje que mejor te venga, no tiene porqué ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solución compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)
Yo no tengo mucha idea de juegos web, pero para que el cuello de botella esté en la BD la tienes que estar dando muchísima caña...
Un saludo!
Vicente
Si, la verdad es que tenía más en mente una aplicación web con mucha carga (estilo flickr, meneame, etc.) donde la escalabilidad tiene que andar muy afinada.
Al final todo depende de la carga que le metas al juego o aplicación, claro.