Si, aleatoriedad determinista, si se me permiten los palabros.
Intentando hacer un simulacro de juego por turnos, tipo Colonization o un RPG cualquiera en el que los combates tienen de matemático y de aleatorio, sale un problema.
La parte matemática es una fórmula que diga a partir de cuánta fuerza de ataque se traspasa un escudo y cuánto daño hacer al que se defiende. La parte aleatoria siempre es un dado, de todas las caras que se quiera, pero un dado.
Si se tiene un servidor centralizado donde se ejecuten todas las reglas, no hay problema. Uno dice al servidor a quién ataca y el servidor responderá con todo el cálculo ya hecho. El problema planteado es que la computación sea de par a par.
Todos los clientes son iguales y todos reciben las instrucciones de un jugador para ejecutar sus turnos. Si se calculase en la aplicación cliente el palo que se le va a pegar al otro y se le enviasen los resultados tampoco habría problema, pero tenemos otro añadido que es el presentar la información al usuario. Ocurre que, si se le envía el resultado de los combates, habría que programar un comportamiento aparte para que el otro cliente muestre esos resultados al usuario... ¿Por qué no enviar sólo las acciones del usuario y que se pinten como si el que mueve es el dueño del dispositivo cliente cuando eso ya lo tendríamos programado para la edición del siguiente turno?
Pues qué carajo, eso. Acumularíamos comandos o acciones de usuario y al finalizar su turno se envían al resto de clientes para que se ejecuten como si hubiese un robot pulsando teclas. Al final son datos y los algoritmos de los que dependan ya residen en la otra máquina porque, si no, no estarían jugando.
Pero, claro, el usuario provoca que la aplicación tire un dado para los sorteos de sus ataques y el adversario tiene que ver el mismo resultado porque si no, perderíamos la sincronía entre clientes.
Mi solución pasa por hacer una tabla de números aleatorios e ir usando. Al principio de cada turno se podría sortear una tabla de números dispersos y que se vayan consumiendo en cada operación cuantas tiradas de dados se necesiten. Al final del turno, además de la información de las acciones a realizar, añadimos la lista de números para que quien reciba el turno completo, tenga las mismas tiradas de dados que nosotros.
Esto es un futurible, por ahora, con un Conecta 4 hay trabajo de sobra. Todo se andará.
Mostrando entradas con la etiqueta juegos. Mostrar todas las entradas
Mostrando entradas con la etiqueta juegos. Mostrar todas las entradas
Deathspank
mayor: what do you know about orphans?
deathspank: well... they have no parents.
mayor: I see you are well informed...
deathspank: well... they have no parents.
mayor: I see you are well informed...
¡Ocupado!
Llevo unos días, demasiados, pero entre el curro y demás, no hay tiempo para todo.
Llevo unos días, decía, programanding otra vez para el androide. Jugar por correo electrónico es algo que no está muy explotado en el market. Problema gordo es que tengo cien mil ideas por minuto y sólo dos manos.
Tengo organizadas unas cosas chulas y lo que más me fastidia es no tener tiempo físico de llevarlas al mercado, cagonlaputa.
Estoy con un juego sencillo con el que poder probar todo el sistema, y hablo de todo el sistema porque en código la que estoy montando trae telar. Además toda la gestión de "eventos" en Android es un poco rara y entre sincronía, hebras, servicios, ventanas, bases de datos... Un jueguín de mierda toma entidad de proyectazo.
Esperemos que el primero duela pero el segundo vaya algo más fluido una vez montada toda la estructura.
Quería tener dos antes de sacar al Market algo para que la gente no se desespere a instalar una mierdecilla de juego que luego no les guste por aquello de que en la variedad está el gusto, quiero tener dos pequeños y luego meterme en unas cosas más complejas que tengo en la cabeza.
No quería publicar mucho, por ahora juegos por turnos, jugar por correo y cosas pequeñas.
Está muy bien la idea de la que no soy el padre porque jugar por correo se hace desde que se inventó el ajedrez o las damas. Aquí tenemos la posibilidad de que sea asíncrono como cualquier juego por correo (en inglis PBM, ahora se dice también PBeM por aquello del correo electrónico) y llevar el juego en el bolsillo para responder al contrincante cuando te salga. Está bien la idea, insisto, a ver cómo se lo toma el mercado.
Es importante para mí lo de tener dos juegos funcionando, carajo, a nivel personal o propio no es que sea un reto, que lo es, es que así probaré que todo el sistema funciona. Y ya a nivel de mercado, el problema es el que a la gente le parezca mal uno de los juegos y tenga un cierto apego al otro. La putada más gorda es tener que hacer otro más complejo (¡mucho mas!) que tengo perfilado en la cabeza pero que sólo en base de datos me va a llevar tanto o más tiempo que en la implementación completa de este.
Me daré una o dos semanas más para terminar este, ¡que aun no se mueve!.
Ver veremos. Que haya salú... Y ganas que, aunque no falten hoy, no vienen a diario tampoco.
--
O quam cito transit gloria mundi.
--
O quam cito transit gloria mundi.
Loable Causa
http://www.ukresistance.co.uk/2005/11/blue-sky-in-games-campaign-launched.html
Mmh... quizá pierdan algo de emoción según el juego. Hay gustos para todo y de todo donde elejir.
Mmh... quizá pierdan algo de emoción según el juego. Hay gustos para todo y de todo donde elejir.
La lógica de un evento que se convirtió en acción
Vamos a suponer que tenemos un cliente de damas. El cliente es tonto para pintar, siempre pintará el estado del juego y esta lógica nunca se actualizará. En pantalla se pintará el tablero y una superposición de las opciones del jugador después de que éste haya seleccionado una pieza.
Cuando el usuario selecciona una ficha en el tablero se genera un evento que se procesará mediante una entidad representada por un script que puede cambiar en tiempo de ejecución. Normalmente este script formará parte de la configuración del juego, bien sea de la aplicación o de la partida en curso (se podría jugar a las damas inglesas con la misma interfaz pero distinta configuración). Si la ficha está bloqueada no se cambiaría la interfaz. Si no estuviera bloqueada, el script podría activar distintas opciones a mostrar en pantalla y pedir un repintado.
Esta parte está un poco borrosa y sin definir. La entidad que ha resuelto el evento no pasa de ser un EventHandler normal y corriente de los de toda la vida, en ella no intervinen lógica de negocio, sólo presentación. La parte en la que cito “ficha bloqueada” sería lógica de negocio. Ahí entraría una acción que sería, por ejemplo, MoverFicha. La interfaz de las acciones permitirían al código que las llama unas entradas de “seguridad” o, más bien, de comprobación de la posibilidad de ejecución. Varios métodos ayudarían a esto. Un getOptions o algo así, podría, no sólo decir si es posible realizar esta acción sino realizar algún refresco en la vista añadiendo las opciones a un menú que se pueda pintar. En este caso de las damas, en una capa por encima del tablero que estaba pintado, podrían aparecer en sombreado dos fichas en los posibles lugares a los que se puede mover la actual. Si la ficha fuese una dama en las damas inglesas esas casillas serían hasta ocho en un movimiento simple en el que no coma… La configuración lo variaría todo.
Esta acción se convertiría en comando cuando se ejecute. Por ahora estamos en la posibilidad de que se ejecute. El usuario la podría cancelar, la tenemos en cola para un posible fin de turno, es la acción actual y el botón volver la puede deshacer. El usuario confirma, la acción se ejecuta y repintamos el modelo en pantalla con el nuevo tablero… Se ha hecho cambiar el proxy del modelo en el cliente. Incluso, con ser este un juego de damas y sólo podemos mover una ficha cada turno, se podría comunicar al servidor el fin de turno o desencadenar una acción que permita al usuario aceptar para finalizar su turno. Entonces se enviarán los datos al servidor para que se actualicen el resto de clientes.
Ese paso, el de actualizar el resto de clientes, se puede independizar de la arquitectura, del método usado, etc. Habría que ver si hacemos PULL o PUSH desde el terminal. Un límite de tiempo y refresco a petición del cliente sería lo más óptimo a mi entender.
En próximos capítulos, el milagro del remote scripting ^^
Cuando el usuario selecciona una ficha en el tablero se genera un evento que se procesará mediante una entidad representada por un script que puede cambiar en tiempo de ejecución. Normalmente este script formará parte de la configuración del juego, bien sea de la aplicación o de la partida en curso (se podría jugar a las damas inglesas con la misma interfaz pero distinta configuración). Si la ficha está bloqueada no se cambiaría la interfaz. Si no estuviera bloqueada, el script podría activar distintas opciones a mostrar en pantalla y pedir un repintado.
Esta parte está un poco borrosa y sin definir. La entidad que ha resuelto el evento no pasa de ser un EventHandler normal y corriente de los de toda la vida, en ella no intervinen lógica de negocio, sólo presentación. La parte en la que cito “ficha bloqueada” sería lógica de negocio. Ahí entraría una acción que sería, por ejemplo, MoverFicha. La interfaz de las acciones permitirían al código que las llama unas entradas de “seguridad” o, más bien, de comprobación de la posibilidad de ejecución. Varios métodos ayudarían a esto. Un getOptions o algo así, podría, no sólo decir si es posible realizar esta acción sino realizar algún refresco en la vista añadiendo las opciones a un menú que se pueda pintar. En este caso de las damas, en una capa por encima del tablero que estaba pintado, podrían aparecer en sombreado dos fichas en los posibles lugares a los que se puede mover la actual. Si la ficha fuese una dama en las damas inglesas esas casillas serían hasta ocho en un movimiento simple en el que no coma… La configuración lo variaría todo.
Esta acción se convertiría en comando cuando se ejecute. Por ahora estamos en la posibilidad de que se ejecute. El usuario la podría cancelar, la tenemos en cola para un posible fin de turno, es la acción actual y el botón volver la puede deshacer. El usuario confirma, la acción se ejecuta y repintamos el modelo en pantalla con el nuevo tablero… Se ha hecho cambiar el proxy del modelo en el cliente. Incluso, con ser este un juego de damas y sólo podemos mover una ficha cada turno, se podría comunicar al servidor el fin de turno o desencadenar una acción que permita al usuario aceptar para finalizar su turno. Entonces se enviarán los datos al servidor para que se actualicen el resto de clientes.
Ese paso, el de actualizar el resto de clientes, se puede independizar de la arquitectura, del método usado, etc. Habría que ver si hacemos PULL o PUSH desde el terminal. Un límite de tiempo y refresco a petición del cliente sería lo más óptimo a mi entender.
En próximos capítulos, el milagro del remote scripting ^^
Servidor filosofando de clientes
No es que quiera pegar estos pensamientos a una tecnología en particular, pero no está de más centrar la finalidad del proyecto para acotarlo de algún modo. La idea no es hacer el DooM entero y ejecutarlo a ver qué pasa. Hacer un cliente capaz de ejecutar pequeñas lógicas de negocio para descartar eventos de usuario y un servidor que sincronice partidas es ya un trabajo suficientemente grande para una persona. Añadir capas a esta estructura o ampliar esta lógica de negocio sería lo mismo que construir una aplicación sobre un buen framework en el que cada acción de usuario se pueda implementar independientemente. Añadir datos al modelo incluso nuevas reglas de negocio…
Sobre nuevas reglas de negocio, vamos a centrarnos ya en Android. Android es lo que quiero que implemente el primer cliente de la aplicación. Sin quitar que luego haya cliente web o lo que venga. Al tener una aplicación desplegada en un aparato con android, se puede actualizar esta arbitrariamente cuando el desarrollador quiera dentro del Market. Una pega bastante gorda de esto es que el cliente tiene que tener la voluntad de actualizarla porque debe activar él mismo la descarga e instalación de la nueva versión.
Quisiera poder esquivar este tema. Las acciones de usuario deberían tener consecuencias distintas según el modo de juego, incluso si se me apura, poder cambiar dinámicamente. Habría que tener un cliente lo suficientemente inteligente como para decir que no se puede mover una ficha del juego de damas en vertical u horizontal. Se me ocurre flexibilizarlo aun más y poder, desde el servidor, introducir nuevas modalidades de juego de damas distintas a las que yo conozco. Los ingleses juegan con las damas (cuando son damas y se le da vuelta a la ficha que por el otro lado les ponen una cruz negra) con un tipo de movimiento particular, pueden mover en cualquier dirección (incluso vertical u horizontal) pero de uno en uno.
Esto de flexibilizar las reglas de juego no es un problema en sí, se podría anunciar una actualización y decir al cliente que si no se actualiza no podrá jugar a las damas a la inglesa… Pero preferiría que si se actualiza el cliente sea por corregir bugs o añadir algún tipo de funcionalidad que, de veras, no se pueda desde el servidor. Además este nuevo requisito se une al depender en dos aplicaciones (cliente y servidor) de un cambio que se podría dar en una.
Me lleva a pensar esto en distribuir la computación y hacer que el cliente pida “permiso” al servidor para mover de a3 a a4 en un juego de damas. Esto usaría red. Un defecto de los informáticos es que pensamos en el usuario y en sus aparatos. Al programar para una consola portatil se pausa de vez en vez la cpu o los sistemas de sonido mientras no se vayan a usar para ahorrar batería. Parece mentira, pero como usuario te acabas dando cuenta de qué juegos o aplicaciones se comen la batería y cuales no. Así que vamos a descartar eso de tirar la énergia y usar la red sólo cuando se necesite.
Esto del ahorro nos descarta de un juego en tiempo real aunque también es posible algún tipo de juego que ya he pensado en el que los eventos de usuario sean bastante espaciados. Al final, lo que me interesa es hacer un juego por turnos que sea “atemporal” no que exista por siempre si no que se pueda jugar en cualquier momento, incluso flexibilizar los turnos para limitarlos a un tiempo o no tipo civilization.
Como soy medio masoca pa todo esto, lo que más me pone es preparar estas milongas que hay por debajo.
Vamos a hacer un proxy del servidor. El proxy deberá contener la lógica de negocio que decida qué acciones son permitidas al usuario y cuales no. Es absurdo preguntar al servidor cuando el usuario pincha sobre una casilla en blanco. En un cliente Ajax ni siquiera se generaría un evento javascript para esa celda del mapa. Pues un cliente algo listo, debería detener la ejecución antes de pedir por red al servidor que le describa qué mostrar o qué hacer. Parte o toda la lógica de negocio podría almacenarse en scripts o en clases que se puedan servir al cliente (ya me estoy limitando a una tecnología), al menos aquella lógica que diga qué eventos del usuario superan el ámbito del cliente y tienen que pasar como un comando al servidor: Al final de un turno, por ejemplo, el cliente no debería haber contactado con el servidor para nada y entonces enviar un lote de acciones que gestionar de las que ha hecho el usuario. En un juego como el poker llegarían todas las cartas que ha tirado el usuario al final de su turno pero no de una en una sino en un solo comando.
El proxy del cliente actuará como si ya se han movido sus fichas y podrá ver el tablero actualizado con sus movimientos incluso deshacerlos antes de terminar su turno salvo que las reglas no permitan deshacer… “Carta en la mesa” o como se diga en cada sitio.
Evento: será un gesto del usuario ante la interfaz que se le presenta o cualquier tarea repetitiva o programada que desencadene una acción contra la aplicación, cosas del tipo un click de usuario, arrastrar, o un timer que haga el tick de una animación.
Accion: un evento pasará a ser una acción cuando la lógica de negocio tenga que responder a él bien sea cambiando la vista, el modelo o comunicando cualquier cosa a un posible servidor de la aplicación.
Proxy: Un proxy es una representación de un objeto que no esxiste realmente como tal o que es un modelo sobre el modelo. Explico esto diciendo que si se centraliza un servidor con toda la lógica de negocio, por ejemplo, es bastante absurdo para un cliente que no sea tonto (osea que haya que programar cierta lógica en el cliente) el tener que consultar qué hacer con un click del usuario o con un tick de las animaciones. Ver proxy pattern en wikipedia o donde sea.
Comando: Una acción pasa a ser un comando cuando modifica un proxy o el modelo.
Continuará...
Sobre nuevas reglas de negocio, vamos a centrarnos ya en Android. Android es lo que quiero que implemente el primer cliente de la aplicación. Sin quitar que luego haya cliente web o lo que venga. Al tener una aplicación desplegada en un aparato con android, se puede actualizar esta arbitrariamente cuando el desarrollador quiera dentro del Market. Una pega bastante gorda de esto es que el cliente tiene que tener la voluntad de actualizarla porque debe activar él mismo la descarga e instalación de la nueva versión.
Quisiera poder esquivar este tema. Las acciones de usuario deberían tener consecuencias distintas según el modo de juego, incluso si se me apura, poder cambiar dinámicamente. Habría que tener un cliente lo suficientemente inteligente como para decir que no se puede mover una ficha del juego de damas en vertical u horizontal. Se me ocurre flexibilizarlo aun más y poder, desde el servidor, introducir nuevas modalidades de juego de damas distintas a las que yo conozco. Los ingleses juegan con las damas (cuando son damas y se le da vuelta a la ficha que por el otro lado les ponen una cruz negra) con un tipo de movimiento particular, pueden mover en cualquier dirección (incluso vertical u horizontal) pero de uno en uno.
Esto de flexibilizar las reglas de juego no es un problema en sí, se podría anunciar una actualización y decir al cliente que si no se actualiza no podrá jugar a las damas a la inglesa… Pero preferiría que si se actualiza el cliente sea por corregir bugs o añadir algún tipo de funcionalidad que, de veras, no se pueda desde el servidor. Además este nuevo requisito se une al depender en dos aplicaciones (cliente y servidor) de un cambio que se podría dar en una.
Me lleva a pensar esto en distribuir la computación y hacer que el cliente pida “permiso” al servidor para mover de a3 a a4 en un juego de damas. Esto usaría red. Un defecto de los informáticos es que pensamos en el usuario y en sus aparatos. Al programar para una consola portatil se pausa de vez en vez la cpu o los sistemas de sonido mientras no se vayan a usar para ahorrar batería. Parece mentira, pero como usuario te acabas dando cuenta de qué juegos o aplicaciones se comen la batería y cuales no. Así que vamos a descartar eso de tirar la énergia y usar la red sólo cuando se necesite.
Esto del ahorro nos descarta de un juego en tiempo real aunque también es posible algún tipo de juego que ya he pensado en el que los eventos de usuario sean bastante espaciados. Al final, lo que me interesa es hacer un juego por turnos que sea “atemporal” no que exista por siempre si no que se pueda jugar en cualquier momento, incluso flexibilizar los turnos para limitarlos a un tiempo o no tipo civilization.
Como soy medio masoca pa todo esto, lo que más me pone es preparar estas milongas que hay por debajo.
Vamos a hacer un proxy del servidor. El proxy deberá contener la lógica de negocio que decida qué acciones son permitidas al usuario y cuales no. Es absurdo preguntar al servidor cuando el usuario pincha sobre una casilla en blanco. En un cliente Ajax ni siquiera se generaría un evento javascript para esa celda del mapa. Pues un cliente algo listo, debería detener la ejecución antes de pedir por red al servidor que le describa qué mostrar o qué hacer. Parte o toda la lógica de negocio podría almacenarse en scripts o en clases que se puedan servir al cliente (ya me estoy limitando a una tecnología), al menos aquella lógica que diga qué eventos del usuario superan el ámbito del cliente y tienen que pasar como un comando al servidor: Al final de un turno, por ejemplo, el cliente no debería haber contactado con el servidor para nada y entonces enviar un lote de acciones que gestionar de las que ha hecho el usuario. En un juego como el poker llegarían todas las cartas que ha tirado el usuario al final de su turno pero no de una en una sino en un solo comando.
El proxy del cliente actuará como si ya se han movido sus fichas y podrá ver el tablero actualizado con sus movimientos incluso deshacerlos antes de terminar su turno salvo que las reglas no permitan deshacer… “Carta en la mesa” o como se diga en cada sitio.
Evento: será un gesto del usuario ante la interfaz que se le presenta o cualquier tarea repetitiva o programada que desencadene una acción contra la aplicación, cosas del tipo un click de usuario, arrastrar, o un timer que haga el tick de una animación.
Accion: un evento pasará a ser una acción cuando la lógica de negocio tenga que responder a él bien sea cambiando la vista, el modelo o comunicando cualquier cosa a un posible servidor de la aplicación.
Proxy: Un proxy es una representación de un objeto que no esxiste realmente como tal o que es un modelo sobre el modelo. Explico esto diciendo que si se centraliza un servidor con toda la lógica de negocio, por ejemplo, es bastante absurdo para un cliente que no sea tonto (osea que haya que programar cierta lógica en el cliente) el tener que consultar qué hacer con un click del usuario o con un tick de las animaciones. Ver proxy pattern en wikipedia o donde sea.
Comando: Una acción pasa a ser un comando cuando modifica un proxy o el modelo.
Continuará...
Retro Game Challenge
Como sabrás, querido lector, no me gusta hacer eso que llaman “reviews” de juegos ni películas porque no dejan de ser una opinión y en esto de los gustos de uno al de al lado corre el mundo. Las reviews suelen estar hechas por alguien que sólo juega y no sabe lo que hay debajo así que cuando hacen puntuaciones técnicas me da la risa.
Es que mi gusto en cuanto a juegos despinta bastante de los del resto de la humanidad como para todo lo demás. Cuando digo que tal o cual mujer me parece guapa siempre hay alguien que dice que es un “trincho” o un congrio… Replico aquello de que me gustan las caras con personalidad, siempre fue así y yo no soy de esos que cambian de un día para otro de discurso. Antes tengo que convencerme a mi mismo y eso me puede llevar muchos años. Quizá tú, lector, lo sepas.
Las reviews que leí por ahí nunca me convencieron. Hace cierto tiempo descubrí esto de los feeds, RSS, etc y me fue muy facil llegar a noticias sobre juegos de blogs aún vírgenes… Por virgen quiero decir que eran de aficionados que se dedicaban a jugar y a poner en público su experiencia. En pocos meses y, a pesar de escribir como completos zoquetes, vi como remontaban en visitas y aparecía ese post de “He recibido hoy…” con el que empiezan siempre los comentarios positivos para una marca, un juego o una simple página de internez… Se pierde la ingenuidad inicial en la que se podía leer tanto el gusto como su disgusto.
Lo mismo pasa con la gente. La gente sólo habla de verdad cuando son las tripas las que tiran de ellos o cuando en cierto modo, tira el cerebro… Es difícil de comprender pero, si tuvieras la vida que yo tengo o he tenido, sabrías a qué me refiero. Dicen que puedes vivir la vida con alguien y no llegar a conocerlo… Bienaventurado de aquel que nunca llegue a descubrir la verdad porque de él será el reino de los cielos... Quizá nunca llegas a conocer a nadie hasta que lo oyes hablar de las dos maneras, cuando su chocho es el que habla y cuando habla con la cabeza. Las mujeres son como los gatos para eso, cuando están fuera de casa miran para otro lado al verte y no reconocen ni a sus hermanos ni a sus padres, así que imagínate cómo van a reconocer a quien las quiere bien.
Pues es mi opinión. Voy a hablar de un juego para Nintendo DS que se llama Retro Game Challenge. Aun no se ha publicado en Europa, estoy jugando la versión yankee. Aun así quizá merezca la pena jugar esta ya que la traducción la hará gente que no jugó a aquellos juegos o que, vistos ahora le parecerán muy cutres o una mierda… La gente es tonta. Es la misma gente que no quiere ver películas en blanco y negro porque, dicen, están hechas “en el año cero”…
Relleno el texto, querido lector, de puntos suspensivos para que dejes pasar ciertos segundos para efecto dramático o de guiño cómplice en aquellos momentos en los que cabe pensar mal.
Así que si hago lista de los mejores juegos para DS, sin haberlos visto todos, y mezclando mi juicio y gusto en el algoritmo de ordenación, llegaremos que entre los tres o cuatro primeros estarían (no necesariamente por este orden) Mario Kart DS, New Super Mario, Quizá el Zelda ese como se llame y el Tetris.
Lo del Tetris es completamente subjetivo. Uno tiende a recordar las cosas buenas. El Tetris me entretuvo en el tren muchos días pero es el mismo juego. Lo recuerdo más bien por la parte multijugador y los buenos raticos que me hizo pasar, quizá no el juego sino la compañía. Dicen que agua pasada no mueve molinos, pero uno no está hecho de palo y aunque sea una tontería, me cuesta tan poco recordar y tanto olvidar que me dedico muchísimo más a lo primero… Es como el que quiere adelgazar y come compulsivamente. Es como aquel que una vez quiso escapar y no pudo más que caer en picado, fundidas sus alas por el sol. Puta tecnología que nunca me trajo más que disgustos.
El Mario Kart es un juegazo. Es indudable, tantas veces copiado y nunca con parangón. Es divertido y detallado, con una gran física y con todo lo que puedes pedir a un arcade pero dentro de un juego de coches. Además el modo multijugador es genial… Incluso en solo divierte muchísimo.
Del New Mario, ¡¿qué decir?!… Cada nivel es nuevo, casi en cada mundo hay un gameplay que aprender, cada nivel es característico de su mundo y cada enemigo está tan trabajado como si fuera el monstruo de final de fase. Siempre cosas nuevas siempre hacia delante. Los Mario hoy dia no son lo que eran, eran una máquina de matar jugadores. Ahora son el jugar por jugar. El puro espectáculo. El ver el mundo y oler las rosas. Dicen: Si eres el juegón que pensamos te vamos a ocultar un par de mundos y seis niveles más. Si sólo quieres jugar tienes niveles para aburrirte.
El hardware de la consola, tanto en el New Mario como en el Mario Kart está aprovechado al límite. En ambos se utilizan los modos 2d y 3d a la vez. En el new Mario se pueden ver sprites 3d quizá a veces escalados al tamaño de la pantalla y otros chiquitajos en 2d pero hechos con polígonos para sobrepasar ese "límite" de 128 sprites que lleva la consola.
Bueno… Pues ya me voy hartanding de hablar bien de los juegos. Sus cosas malas tendrán… ^g^ No las voy a citar a pesar de que Nintendo ni siquiera me felicita el cumpleaños por email…
Bien, hablemos del nuevo. Ayer estrené el Retro Game Challenge. El argumento es de esos del mono tirando barriles en los límites del universo. Por lo demás es genial. Es un juego sobre juegos: Dentro hay un mundo en el que se van publicando juegos y un endino mago te reta a que pases cuatro niveles o ganes 200.000 puntos. Sin perder una vida.
Los juegos que se publican van con el estilo de la época en la que dicen que lo publican. Así que son retro hoy día pero son incluso muy avanzados para las épocas en las que dicen que se publicaron. Las mecánicas se complican más que las que recuerdo de entonces… Quizá esté bien que hubiera power-ups en juegos como el Xenon y toda la panda aquella, pero no había tantos elementos en pantalla ni eso de romper en cadena cuando el número de tiles era tan limitado… Aun así es genial que hagan esto porque a un juego de esos que llaman casual y que tiene cuatro niveles (recordemos que es un juego dentro de otro) le añaden muchísimas posibilidades de superación. En la época un juego así costaría 8000pts. Y no te cansaría nunca… Siempre tendrías un orden que aprender para sacar 10.000 puntos más o una letra oculta que te cuenten un día en clase.
Quitando los cuatro impedimentos físicos que sólo cuatro fricancios conoceremos y que impedirían programar juegos como estos en la época. Nunca pierden de vista los mismos efectos sonoros y visuales. Incluso lo de venderte la segunda parte de un juego con el mismo motor pero algo mejorado y enchungueciending los niveles… Aquellos “giros” argumentales en los que llegas, rescatas a la princesa… Que siempre es una princesa… Y te la vuelven a raptar…
Las músicas, los menús, los enemigos, las animaciones, el motu del jugador por avanzar una pantalla más o por querer tener aquel arma... Aquel truco…
Se me olvidaba… Los trucos… Los trucos forman parte del juego. En el juego te dan trampas para poder acabar los otros que van dentro. Antes de que aparezca un juego hay un preview en las revistas que se publican. Después hacen un reportaje más extenso cuando el juego está en el mercado. Y por fin, como se lleva haciendo desde que tengo uso de razón, a toro pasao te empiezan a soltar trucos y guías de estrategia para sacar el máximo de partido… Como simulan juegos de consola, en la revista no hay POKEs, pero era lo que faltaba, jajaja.
Tanto para jugadores casual como para jugones de los de toda la vida, este es el juego del mes. No poque yo lo diga sino porque, carajo, no canta, no baila, peo vayan a verla. Luego ya me dirán. Los casuales van a tener varios juegos dentro de juegos para batirse y los otros van a tener montones de retos que superar y truquejos que aprender.
Quizá tenga alguna pega como que para salvar la partida hay que aguantarle la turra al otro criajo ochenteno que se sienta en la alfombra a verte jugar (estás en su casa, así que hay que aguantarlo).
Para el niño, para la niña, para grandes que vivieron aquello, para pequeños que no saben lo que se perdieron o que lo viven hoy día con esos reportajes de revista. Para todos, Retro Game Challenge.
Es que mi gusto en cuanto a juegos despinta bastante de los del resto de la humanidad como para todo lo demás. Cuando digo que tal o cual mujer me parece guapa siempre hay alguien que dice que es un “trincho” o un congrio… Replico aquello de que me gustan las caras con personalidad, siempre fue así y yo no soy de esos que cambian de un día para otro de discurso. Antes tengo que convencerme a mi mismo y eso me puede llevar muchos años. Quizá tú, lector, lo sepas.
Las reviews que leí por ahí nunca me convencieron. Hace cierto tiempo descubrí esto de los feeds, RSS, etc y me fue muy facil llegar a noticias sobre juegos de blogs aún vírgenes… Por virgen quiero decir que eran de aficionados que se dedicaban a jugar y a poner en público su experiencia. En pocos meses y, a pesar de escribir como completos zoquetes, vi como remontaban en visitas y aparecía ese post de “He recibido hoy…” con el que empiezan siempre los comentarios positivos para una marca, un juego o una simple página de internez… Se pierde la ingenuidad inicial en la que se podía leer tanto el gusto como su disgusto.
Lo mismo pasa con la gente. La gente sólo habla de verdad cuando son las tripas las que tiran de ellos o cuando en cierto modo, tira el cerebro… Es difícil de comprender pero, si tuvieras la vida que yo tengo o he tenido, sabrías a qué me refiero. Dicen que puedes vivir la vida con alguien y no llegar a conocerlo… Bienaventurado de aquel que nunca llegue a descubrir la verdad porque de él será el reino de los cielos... Quizá nunca llegas a conocer a nadie hasta que lo oyes hablar de las dos maneras, cuando su chocho es el que habla y cuando habla con la cabeza. Las mujeres son como los gatos para eso, cuando están fuera de casa miran para otro lado al verte y no reconocen ni a sus hermanos ni a sus padres, así que imagínate cómo van a reconocer a quien las quiere bien.
Pues es mi opinión. Voy a hablar de un juego para Nintendo DS que se llama Retro Game Challenge. Aun no se ha publicado en Europa, estoy jugando la versión yankee. Aun así quizá merezca la pena jugar esta ya que la traducción la hará gente que no jugó a aquellos juegos o que, vistos ahora le parecerán muy cutres o una mierda… La gente es tonta. Es la misma gente que no quiere ver películas en blanco y negro porque, dicen, están hechas “en el año cero”…
Relleno el texto, querido lector, de puntos suspensivos para que dejes pasar ciertos segundos para efecto dramático o de guiño cómplice en aquellos momentos en los que cabe pensar mal.
Así que si hago lista de los mejores juegos para DS, sin haberlos visto todos, y mezclando mi juicio y gusto en el algoritmo de ordenación, llegaremos que entre los tres o cuatro primeros estarían (no necesariamente por este orden) Mario Kart DS, New Super Mario, Quizá el Zelda ese como se llame y el Tetris.
Lo del Tetris es completamente subjetivo. Uno tiende a recordar las cosas buenas. El Tetris me entretuvo en el tren muchos días pero es el mismo juego. Lo recuerdo más bien por la parte multijugador y los buenos raticos que me hizo pasar, quizá no el juego sino la compañía. Dicen que agua pasada no mueve molinos, pero uno no está hecho de palo y aunque sea una tontería, me cuesta tan poco recordar y tanto olvidar que me dedico muchísimo más a lo primero… Es como el que quiere adelgazar y come compulsivamente. Es como aquel que una vez quiso escapar y no pudo más que caer en picado, fundidas sus alas por el sol. Puta tecnología que nunca me trajo más que disgustos.
El Mario Kart es un juegazo. Es indudable, tantas veces copiado y nunca con parangón. Es divertido y detallado, con una gran física y con todo lo que puedes pedir a un arcade pero dentro de un juego de coches. Además el modo multijugador es genial… Incluso en solo divierte muchísimo.
Del New Mario, ¡¿qué decir?!… Cada nivel es nuevo, casi en cada mundo hay un gameplay que aprender, cada nivel es característico de su mundo y cada enemigo está tan trabajado como si fuera el monstruo de final de fase. Siempre cosas nuevas siempre hacia delante. Los Mario hoy dia no son lo que eran, eran una máquina de matar jugadores. Ahora son el jugar por jugar. El puro espectáculo. El ver el mundo y oler las rosas. Dicen: Si eres el juegón que pensamos te vamos a ocultar un par de mundos y seis niveles más. Si sólo quieres jugar tienes niveles para aburrirte.
El hardware de la consola, tanto en el New Mario como en el Mario Kart está aprovechado al límite. En ambos se utilizan los modos 2d y 3d a la vez. En el new Mario se pueden ver sprites 3d quizá a veces escalados al tamaño de la pantalla y otros chiquitajos en 2d pero hechos con polígonos para sobrepasar ese "límite" de 128 sprites que lleva la consola.
Bueno… Pues ya me voy hartanding de hablar bien de los juegos. Sus cosas malas tendrán… ^g^ No las voy a citar a pesar de que Nintendo ni siquiera me felicita el cumpleaños por email…
Bien, hablemos del nuevo. Ayer estrené el Retro Game Challenge. El argumento es de esos del mono tirando barriles en los límites del universo. Por lo demás es genial. Es un juego sobre juegos: Dentro hay un mundo en el que se van publicando juegos y un endino mago te reta a que pases cuatro niveles o ganes 200.000 puntos. Sin perder una vida.
Los juegos que se publican van con el estilo de la época en la que dicen que lo publican. Así que son retro hoy día pero son incluso muy avanzados para las épocas en las que dicen que se publicaron. Las mecánicas se complican más que las que recuerdo de entonces… Quizá esté bien que hubiera power-ups en juegos como el Xenon y toda la panda aquella, pero no había tantos elementos en pantalla ni eso de romper en cadena cuando el número de tiles era tan limitado… Aun así es genial que hagan esto porque a un juego de esos que llaman casual y que tiene cuatro niveles (recordemos que es un juego dentro de otro) le añaden muchísimas posibilidades de superación. En la época un juego así costaría 8000pts. Y no te cansaría nunca… Siempre tendrías un orden que aprender para sacar 10.000 puntos más o una letra oculta que te cuenten un día en clase.
Quitando los cuatro impedimentos físicos que sólo cuatro fricancios conoceremos y que impedirían programar juegos como estos en la época. Nunca pierden de vista los mismos efectos sonoros y visuales. Incluso lo de venderte la segunda parte de un juego con el mismo motor pero algo mejorado y enchungueciending los niveles… Aquellos “giros” argumentales en los que llegas, rescatas a la princesa… Que siempre es una princesa… Y te la vuelven a raptar…
Las músicas, los menús, los enemigos, las animaciones, el motu del jugador por avanzar una pantalla más o por querer tener aquel arma... Aquel truco…
Se me olvidaba… Los trucos… Los trucos forman parte del juego. En el juego te dan trampas para poder acabar los otros que van dentro. Antes de que aparezca un juego hay un preview en las revistas que se publican. Después hacen un reportaje más extenso cuando el juego está en el mercado. Y por fin, como se lleva haciendo desde que tengo uso de razón, a toro pasao te empiezan a soltar trucos y guías de estrategia para sacar el máximo de partido… Como simulan juegos de consola, en la revista no hay POKEs, pero era lo que faltaba, jajaja.
Tanto para jugadores casual como para jugones de los de toda la vida, este es el juego del mes. No poque yo lo diga sino porque, carajo, no canta, no baila, peo vayan a verla. Luego ya me dirán. Los casuales van a tener varios juegos dentro de juegos para batirse y los otros van a tener montones de retos que superar y truquejos que aprender.
Quizá tenga alguna pega como que para salvar la partida hay que aguantarle la turra al otro criajo ochenteno que se sienta en la alfombra a verte jugar (estás en su casa, así que hay que aguantarlo).
Para el niño, para la niña, para grandes que vivieron aquello, para pequeños que no saben lo que se perdieron o que lo viven hoy día con esos reportajes de revista. Para todos, Retro Game Challenge.
The Force Unleashed
La imagen es un Concept Art, no se corresponde con ninguna de las versiones del juego.
Y es que, querido lector, no puedo pasar sin hablar de El Poder de la Fuerza. No puedo dejarlo pasar porque he visto cómo lo vituperan porque, dicen, es más de lo mismo, que los gráficos no llegan más allá y que, en fin, no es más que otro juego de Lucas para explotar el filón interminable de los jedis, etc.
Pues nole. Hale. Aquí uno de los que dicen que quien tiene una Wii tiene un tesoro. Muchos de los juegos que se venden son casual games. Al final los juegos de consola son, la mayor parte, de esos casuales y esto es extensible al resto de consolas que conozco... Me dirán ahora que un juego de chapas no es casual... ¡vamos hombre!
Bueno, pues partiendo de ese hecho y de que todos los juegos de consola que conozco, no se por qué, parecen no haber sido acabados, hasta el punto de que, sin venir a qué, se cortan las partidas para meterte alguna animación que parece no comenzar niacabar sino estar cortada y empujada con baqueta entre disparo y disparo... Esto ocurre en The Force Unleashed también.
Otra cosa que ocurre en la mayor parte de los juegos es que el doblaje es una mierda muy poco cuidada. Las escenas deben de tener que grabarse independientemente unas de otras, incluso las locuciones deben de ser aisladas de forma que ni el director del doblaje ni los actores deben de saber muy bien qué motiva la frase que van a grabar en cada momento. Así en este juego de vez en cuando hay una salida de tono, un gritillo o lo que sea que no cuadra con lo anterior. Además siempre se sincopan o entrecortan las ediciones de forma que queda mecánico como esa voz al final de los anuncios de medicamentos que está acelerada y notas, descaradamente, los cortes donde debería haber inspirado para poder seguir hablando. Esto ocurre en The Force Unleashed también.
Bien, después de poner a caldo el mercado vamos a hablar del verdadero poder de la fuerza.
Me dicen por la internez que es que los gráficos de la Wii... No saben de lo que hablan... No lo saben... O es que nunca han jugado a esto con la Wii o, símplemente, no les gusta jugar. La cosa es bien sencilla, si te gusta jugar a cosas nuevas de formas nuevas, te compras una Wii. Si, por el contrario, te gusta jugar a lo de siempre pero con más polígonos, te compras otra cualquiera.
El tema de los gráficos lo resumo en cuatro palabras: "¿Qué cojones importa?"
Aun con estas, tengo que defender los gráficos de la versión Wii porque, dentro de toooodos los juegos que he visto en la consola, este, es de los más logrados, tanto en personajes como en niveles. La supuesta "apertura" de los niveles, que no es tal en ningún juego, pero la aparencia es buena en este, las texturas son detalladas y la profundidad de las escenas es suficiente. Han aprovechado el hardware al máximo viendo el render de la pantalla con varios niveles de detalle según te aproximas a los objetos. Los efectos visuales son comparables al resto de versiones aunque, claro está, nunca llega al nivel de detalle de las inmediatas (muy por abajo) competidoras de la Wii.
¿Qué es el poder de la fuerza? ¿Qué hace que el juego sea bueno? ¿Qué engancha? ¿Qué me hizo jugarlo cada noche y acabarlo en una semana? Pues los controles.
Uno de los poderes es el empujón de fuerza que ya habíamos visto en el Jedi Knight, ¿Cuál es la diferencia? Pues que aquí "empujas" con tu mano y tu personaje empuja. La sincronía de los movimientos de la espada con el Wiimote es mejor que en cualquier otro de los que he visto. Los gestos y combos están muy bien buscados y la variedad hace que tengas que jugar una segunda vez para poder pasar por todos.
La dificultad no es extrema de forma que se hace más llevadero y divertido, además, a pesar del doblaje y de lo mecánico de las cinemáticas que comenté antes, la historia es un buen cuento para una película de la Guerra de las Galaxias.
Así que, en resumen, si puedes jugar una versión de The Force Unleashed, juega la de Wii porque puede que sea la única que no te decepcione.
Y me llaman mala persona...
Nunca lo había hecho y pocas veces lo volveré a hacer. Ayer me compré la revista esa oficial de Nintendo, Nintendo Nación o algo así se llama.
La revista es como cualquier otra de videojuegos, llena de chachi y guachi, con referencias a la liga de fubol que es la única comparación a la que alcanzamos los mortales en cuanto a emociones y diversión... Lamentablemente yo no alcanzo ni a esa.
En un anuncio a doble página me encontré esa imagen que he pegado ahí. Imagina, dice, imagina ser... ¡lo que quieras ser!. Y como decía Ford, siempre y cuando sea negro.
Así que imagina ser Diseñadora de moda, ser Cocinera, ser... Mamá, Veterinaria...
Es a todo lo que puedes aspirar... Es de suponer que en unos pocos meses aparecerán otras variantes como ingeniero aeroespacial, presidente y, como no, cirujano vascular... Aunque, visto el mercado, me temo que no.
No soy yo el que lo dice, es el puto mundo, esto viene dado y, la libertad que escoge la gente es tirarse a cualquiera, al primero que sea... Es a lo más que llegamos lo demás parece ser que viene dado por el entorno.
Es la libertad aquella que tenía en La Esclava Libre la negrita aquella que gritaba:"Ya somos libres, podemos beber cuanto queramos sin que nadie nos diga nada". Así he visto y veré sin remedio perderse la libertad de muchas personas por las que temí en este mundo mío tan limitado dividido en lo malo y lo bueno y que, al final, se perdieron sin remedio...
Esa gente a quien tanto quise, que tanto estimé y que ahora son libres de beber cuanto quieran sin que nadie les diga nada. Es a lo que llegaron, mientras mentían en sus intenciones, por supuesto.
Suscribirse a:
Entradas (Atom)