Archivado en: Quejas
Una de las variaciones más importantes en los juegos actuales, cuando los comparamos con los antiguos, son los tutoriales. Es casi imposible encontrar, actualmente, algún juego que prescinda de esto.
Y hay tutoriales realmente molestos. Sobretodos aquellos que, siendo completamente obligatorios, te enseñan hasta a avanzar. Cuando jugué por primera vez al Halo y, con la excusa de “calibrar el traje” (¿que demonios es eso de calibrar el traje?), me obligaba a mirar a determinadas lucecitas, a moverme hacia adelante y atrás, a recargar mi armadura, dejarme tocar y volverla a recargar… de verdad, que estaba pensando “Dame de una vez la jodida ametralladora y vamos a comprobar si tu traje también está calibrado”.
Generalmente utilizan una excusa de lo más tonta. Para evitar poner las instrucciones o la configuración de las teclas, de forma genérica, en pantalla, la moda está en intentar modificar la trama para añadir las instrucciones. Los Final Fantasy, desde la época de la PS1, empiezan con el personaje entrenando o acompañado de “mayores”, que te van diciendo todo lo que debes hacer. Atrás quedó la época de los antiguos Final Fantasy u otros juegos de rol donde, generalmente, te metÃan en medio del barullo y apáñatelas como puedas.
A mi nadie me enseñó a jugar al Ikari Warriors. O al Gun Fright. Ni ningún tutorial te decÃa, en el Eye of Beholder o el Dungeon Master, que tenÃa que apretar los iconos de las manos de los personajes para atacar. Cuando empezaba, en el Doom 2, con un enemigo delante (y una sierra mecánica detrás), no habÃa ningún tutorial que explicara como moverse y que, para disparar al enemigo, debÃa apretar CTRL.
Yo entiendo los tutoriales como algo útil en muchos juegos. De estrategia, o incluso de rol, si son suficientemente complicados. Eso sÃ, con la opción de escoger el tutorial o ir directamente al grano. O, como hace el Star Ocean 3, una sala de tutorial donde puedes entrar o pasar de ella.
Pero si no necesité ningún tutorial para jugar al Zombie (aventura semi-conversacional rara y con un interface más horroroso que los enemigos) no voy a necesitar ir mirando las lucecitas y bailar la lambada para jugar al Halo.
Archivado en: Juegos
Hace un par de posts nombraba un juego, de la primera tanda de la PS2, llamado Ring of Red. Un juego de Mechtons, pero que desborda en originalidad.
Para empezar, los Mechtons no son futuristas. El juego transcurre en una alargada segunda guerra mundial, en los años 60. La bomba nuclear nunca estalló. Y Japón está dividida en dos bandos. La República de Japón, gobernada por los rusos y la Democracia de Japón, de la que formamos parte y que, para ser polÃticamente incorrectos, está apoyada por lo alemanes.
Matarlos a todos o ocupar la base. Una misión standar
Los robots en cuestión son, por lo tanto, máquinas clásicas, más steampunk que futuristas, más tanques con patas que clones de Evangelion. Además de requerir un pelotón completo para su funcionamiento (los proyectiles se cargan a la antigua usanza), cuentan con una autonomÃa de sólo 90 segundos.
El juego transcurre, como la mayorÃa de Tactics-RPG nipones, en un mapeado cuadriculado, donde moveremos nuestras unidades (que, a diferencia de los juegos de estricta estrategia, son personajes que van subiendo de nivel) con un objetivo concreto para poder superar la misión.
Pero lo bueno (y lo malo) del juego son los combates. Se reducen a un duelo de 90 segundos entre esas moles metálicas. Cuando finaliza ese tiempo se acaba la lucha, y hasta el siguiente turno a no ser que haya más combates.
Otras formas de acabar el combate puede ser la retirada o el acercamiento. En el primer caso, evitaremos el combate. En el segundo, propinaremos un ataque de cuerpo a cuerpo a nuestro adversario (en caso que nuestra máquina tenga capacidad para ello) o algún ataque especial, y acabará el combate.
Apuntando, el eterno dilema de esperar un poquito más (y arriesgarse a que el contrario dispare antes) o disparar ahora (y arriesgarse a fallar)
Quien ataca a quien tiene, aunque no lo parezca, gran importancia. La distancia inicial del ataque depende de la posición de los robots en el mapa (y, por lo tanto, del que ataca), y los mechs tienen una funcionalidad muy especÃfica. Un mech especializado en la lucha de lejos hará mucho menos daño, y tendrá mucha menos punterÃa, cuando está cerca de su adversario. Un mech especializado en distancia media perderá efectividad si se está muy cerca o muy lejos, y un mech de distancia corta, a pesar de no tener casi capacidad de ataque a larga distancia, es muy poderoso en la corta, y si llega a acercarse lo suficiente suele ser capaz de hacer ataques cuerpo a cuerpo demoledores.
Además de nuestras máquinas, tendremos tres tropas de soldados, una encima del mech (de la cual dependerán algunas caracterÃsticas como la rapidez de recarga) y otras dos de apoyo, que podremos mover delante del tanque (para atacar o utilizar habilidades especiales) o detrás (para evitar ser dañadas o utilizar habilidades de apoyo).
Francotiradores. Aunque utilicen pistola, son ideales para las largas distancias
El combate es, pues, en semi-tiempo real. Podemos pausar en cualquier momento para mover tropas o realizar los ataques, pero tendremos que ir controlando el tiempo (para apurar hasta el último segundo a la hora de atacar, ya que cuanto más tiempo estemos apuntando, más alto será nuestra punterÃa) y la distancia (para distanciarnos o acercarnos al contrario, dependiendo del tipo de mech que llevemos).
ImportantÃsimo elegir cuidadosamente las tropas de soporte que llevaremos en cada tanque (iremos consiguiendo nuevas en cada pueblo que “conquistemos”), ya que tienen habilidades muy limitadas. Las bengalas serán indispensables por la noche, para iluminar al contrario y evitar penalizaciones por oscuridad, o los cables o minas impedirán que el contrario se acerque demasiado. La artillerÃa pesada, con bazocas o granadas, nos ayudarán si nuestro mech tiene pobre potencia de fuego, la infanterÃa será vital en distancias cortas, y los francotiradores perfectos si pretendemos mantenernos en distancias largas.
La estrategia de este juego es magistral. A pesar de tener cierto componente de “tiempo real”, hay mucha más estrategia, no ya en tablero, sino dentro del combate, que en ningún otro juego parecido.
Como podeis comprobar, estos mechtons no son precisamente Mazinger Z, sino una mole de chatarra lenta y que necesita media docena de técnicos para hacerla funcionar
El único problema es que, si estamos acostumbrados a los juegos tácticos donde el combate se soluciona en una animación de 10 segundos, tener que destinar unos cinco minutos (sÃ, 90 de “tiempo real”, pero debemos añadir todas las animaciones, momentos en pausa eligiendo los ataques o moviendo las tropas, preparaciones antes de batalla, etc) hacen que cada misión pueda durar unas 3 o 4 horas (en vez de la media hora a la que estamos acostumbrados por otros juegos del estilo). Algo que requiere de un jugador muy paciente.
Un juego recomendadÃsimo a los fanáticos de los RPGs tácticos, siempre y cuando sepan tomarse las cosas con mucha calma. Pasarse 4 horas jugando para después darse cuenta que has gastado demasiado tiempo con rencillas estúpidas y no has conseguido acabar la misión en los turnos requeridos puede elevar la tensión por encima de lo saludable.
Archivado en: Divagaciones
Una de las ventajas que tienen actualmente los usuarios de las consolas (al menos, de algunas) es la compatibilidad con los juegos de las anteriores consolas.
Eso es algo que nunca habÃa ocurrido anteriormente (al menos no de una forma tan constante), y debemos dar gracias al formato CD-DVD.
Anteriormente, una nueva consola implicaba abandonar por completo el catálogo de la anterior. Lo cual, todo sea dicho, es algo muy doloroso para los que se han gastado bastante dinero en su momento. SÃ, uno sigue poseyendo la consola antigua, pero es bastante engorroso tener más de una consola conectada al televisor e ir cambiando.
Uno de los grandes éxitos de la PS2 fue garantizar la compatibilidad de los juegos de la PS1. Y parece bastante evidente que la PS3 va a garantizar la compatibilidad de los juegos de la PS2 y, se supone, también de PS1. Nada deberÃa impedirlo ya que la PS3 tendrá que ser capaz de reproducir DVD’s de pelÃculas y CD’s de música.
Que la PS3 fuera capaz de leer dichos formatos pero no reproduciera los juegos de las PlayStations anteriores serÃa una auténtico handicap en el terreno comercial.
Pero… ¿que ocurrirá con la PS4? SÃ, es cierto que probablemente queden un mÃnimo de 5 años, si no más, para la aparición de dicha consola. Pero el aparente estancamiento en los formatos audiovisuales, tanto el CD como el DVD (sobretodo este último), inducen a sospechar que la PS4 tendrá también un soporte óptico (que quizás no sea un DVD convencional, pero será capaz de leerlos, asà como muy probablemente los CDs).
Eso nos llevarÃa a un grado de compatibilidad increiblemente largo para una consola, permitiéndonos jugar a juegos realizados 15 años atrás. ¿Hasta cuando durará eso? ¿PS5? ¿PS8?
Nadie es capaz de prever lo que ocurrirá por ese entonces. Quizás para esas consolas ni siquiera se compraran los juegos de forma fÃsica, sino que los descargaremos directamente a nuestra máquina, siendo capaces de almacenar miles de juegos sin tener que llenar ninguna estanterÃa. Pero incluso en ese caso, la primera consola que utilizara un sistema parecido deberÃa ser compatible con la consola anterior, por lo que seguirÃa disponiendo de dispositivos de lectura.
Pero la tónica está aquÃ. La compatibilidad de sistemas antiguos. Parece impensable que compañÃas como Sony se atrevan, en algún momento, a hacer una consola que no sea completamente compatible con el sistema anterior. Quizás se han acabado para siempre eso de guardar los juegos antiguos en una caja junto a la consola antigua. Quien sabe. Pero, como la PS3 sea capaz de leer los discos de la PSP (algo bastante pausible), será la indicación que vamos por buen camino.
Archivado en: Juegos
Hay cierta tendencia a creer que un mayor realismo implica un mejor juego. Pero, claro, el término “mejor” es algo bastante relativo. Lo que sà que puedo dar por sentado es que un mayor realismo no implica necesariamente un juego más adictivo.
Situémonos. PS2. Robot Warlords. Con permiso del fabuloso (aunque injustamente incomprendido) Ring of Red, el juego de estrategia con Mechtons más realista nunca realizado.
Eso sÃ. Fui capaz, a duras penas, de acabar la primera misión antes de decidir que habÃa tirado el dinero. Y yo aún he sido insistente. Otras dos personas que conozco, que también compraron el juego, fueron incapaces de completar el primer combate. Y no precisamente por difÃcil, sino por excesivamente realista.
El juego, a diferencia de cualquier otro juego por el estilo (como podrÃa ser la saga Front Mission), es extremadamente realista. Si tu te mueves y estás en el area de visión de los otros Mechtons, evidentemente, vas a sufrir sus ataques, aunque no sea su turno. Si decides acercarte a otro robot para pegarle un puñetazo con un puño de 5 toneladas, no es que por el camino tengas que sufrir los disparos de tu futura vÃctima, sino también de todos los enemigos que haya cerca.
Eso significa que, en cada movimiento, ves treinta segundos de animaciones de un montón de moles metálicas disparando, sin saber exactamente quien dispara a quien, independientemente del turno de quien sea. Y, aún peor, cuando es tu turno sueles recibir más daño que el que realizas.
Sumémosle otra caracterÃstica realista. Que estamos hablando de unos armatostes descomunales y algo menos maniobrables que una motocicleta, por lo que si alguien te ataca por el flanco, uno puede necesitar dos turnos para girar lo suficiente como para poder atacarle (suponiendo que el enemigo tenga la gentileza de quedarse quieto). Y ya no hablemos si has avanzado demasiado. Girar 180 grados para realizar una “retirada estratégica” no es una opción. Una vez al descubierto lo mejor es ponerle todos los cojones metálicos al asunto y aguantar lo que se pueda.
Y no es que sea difÃcil, puesto que lo que vale para tÃ, vale para el enemigo. Con una buena posición de tus tropas puedes descerranjar una de esas máquinas sin ni siquiera tener que atacar activamente.
Además, como cuando estás quieto tienes mucha mejor punterÃa que cuando te mueves (aquÃ, a diferencia de la mayorÃa de juegos tácticos por turno, no hay movimiento y acción, sino acción en movimiento), todo queda en un no moverse de detrás de las esquinas de los edificios y de los autobuses destrozados, jugando al “venga, ahora me muevo un pasito p’alante, a ver si caes y te acercas”.
Todo muy realista. Más o menos como serÃa una lucha de lentos armatostes de cinco metros de alto combatiendo en la categorÃa de peso diplodocus. Y aburrido. Muy aburrido. Esa sensación de que no haciendo nada consigues más que haciendo algo. Ese no saber nunca quien está atacando a quien o si estás ganando o perdiendo. Esa sensación de impotencia de tener al enemigo en el cuadrado de al lado pero tener que escaparte, recibiendo tiros en tu trasero metálico, porque él te tiene de cara, pero tu de lado y no puedes girarte en un solo turno…
¡Demonios, que se dejen de tanto realismo y que editen el Front Mission 4 en Europa de una jodida vez!
PD: Sobre lo que comentaba de la manÃa de poner marcas en los screenshots, me he encontrado algo muy curioso. GameSpot y otra página tienen las mismas imágenes, pero cada una con sus propias marcas. Pero lo más curioso es que estas marcas no son coincidentes, pero los screenshots de una página no tienen la marca de la otra (ni siquiera restos). Asà pues, ambas páginas han sacado los pantallazos del mismo sitio… pero las marcan como propias.
Archivado en: Divagaciones
Programar para móviles tiene su encanto. Ya lo comenté, hace meses, antes de embarcarme en mi gran aventura por el mundo del j2me, y ahora que lo realizo, “por obligación”, debo reiterarlo. Es un encanto.
Pero un encanto con ciertas dosis de masoquismo, todo sea dicho. Programar para un sistema “poco potente”, implica tener en la mente, en mayúsculas, Arial 60, negrita, subrallado y lucecitas de neon, la siguiente palabra: LIMITACION.
Vamos a nombrar, de pasada, las limitaciones a las que se ve envuelto un programador de movil:
1.- Limitación de procesador. Lo que significa que, dependiendo de lo que hagas, el juego va a ir a patadas. Si uno no es cauto, y empieza a llenar la parte del código que se va a ejecutar constantemente (por ejemplo, en el repintado, o el trato de eventos) todo va a ir lento. Y la jugabilidad del juego va a bajar hasta el sótano.
2.- Limitación de código. Muchos móviles, o variantes del J2ME imponen un lÃmite del tamaño de los archivos de código. Que no significa que el código fuente sea más corto, sino que el código compilado, debe serlo. Y si el lÃmite es muy pequeño, como en las gamas bajas, uno puede alcanzar ese lÃmite muy fácilmente. Y aquà si que no hay atajos. Si no cabe, no cabe. La única solución es optar siempre por un desarrollo simple. Nada de grandes árboles de inteligencia artificial para los enemigos. Si puedes, no hacer lo mismo, pero “simularlo” con muchos menos código, hazlo.
3.- Limitación de datos. Como si no hubiera suficiente con la limitación de código, a un movil no se le pueden poner los datos que a uno le de la gana. Cinco midis chusqueros, unas cuantas imágenes a pantalla completa y el movil se va a declarar en vaga.
4.- Limitación de memoria. La cantidad de cosas que un movil puede poner en memoria es, para variar, limitada. Muy limitada dependiendo de los modelos. Lo que implica que, aunque tu tengas una gran variedad de gráficos disponibles (o datos, en general), no vas a poder tenerlos todos cargados a la vez. Pero, claro, el movil no va a ponerse a cargar los datos cada vez que el protagonista del juego, por ejemplo, salta. Todas las variaciones gráficas posibles en un nivel deben estar en la memoria a la vez. Y eso implica todas las animaciones posibles de todos los personajes que intervienen en ese nivel, amén de todos los gráficos adicionales. Eso significa saber reaprovechar animaciones y nombrar a los familiares del diseñador del nivel, que ha creÃdo que la variedad de enemigos hará el juego menos monótono.
5.- Limitaciones de soporte. El soporte del juego (es decir, el movil en concreto) puede tener otras limitaciones adicionales que están allá con el único objetivo de hacer la vida imposible a cualquiera que haga aplicaciones para ese movil. Puede ser la imposibilidad de hacer sonar más de un sonido a la vez, o el de apretar dos teclas simultaneamente (eso será la norma para casi qualquier móvil) o a veces cosas tan divertidas como la imposibilidad de tener más de X imágenes cargadas en memoria (independientemente del tamaño de las imágenes) o rutinas que no se pueden aplicar o no existen (por ejemplo, dibujar un cÃrculo de un radio determinado, o calcular un coseno).
Si programar juegos para PC lo comparamos con escribir una novela, programar juegos para un dispositivo concreto, especialmente para uno limitado, es como escribir una novela, pero sin utilizar nombres propios, las letra V, J y U, verbos en subjuntivo y parágrafos que pasen de los 200 caracteres.
Pero, eso sÃ, mola lo que no tiene nombre.
Archivado en: Oldies Computadoras
El juego definitivo para dos personas en el CPC.
Seguramente muchos veteranos de esa época discreparan conmigo. Dirán que nada como los partidillos del Kick Off, o la incansable búsqueda del Gauntlet. Pero no conseguirán hacerme cambiar de opinión. Cuando hablamos de diversión por diversión, sin añadidos, el Psycho Pig UXB era insuperable.
Una breve explicación de la trama: Eramos uno o dos cerdos. Literalmente hablando. Y realizábamos un torneo oficial (con árbitro incluido, que iba reponiendo el material) de lanzamiento de bombas. Cuando acabábamos con los demás cerdos, tirando bombas, pasábamos de fase.
Asà de simple. Pero el juego era tan increiblemente divertido (sobretodo en dos jugadores) a pesar de su sencillez, que era la opción escogida cuando lo que querÃamos era pasar un cuarto de hora de risas y frenesÃ.
No es que sea un gran juego. Este tipo de juegos pueden ser, o una auténtica bazofia, o el disco más rallado de tanto usarlo, con absoluta facilidad. Dependiendo en gran parte de la conexión de los jugadores. Y a mi, francamente, me encantó. Las musiquillas cómicas y las graciosas presentaciones de los cerdos adversarios a cada nivel resumÃan todo el juego incluso antes de haberlo jugado. Y los movimientos, asà como los “bonus” que aparecÃan en medio del campo de batalla, como “speed ups”, bombas estrella (que hacÃan explotar todas las bombas de la pantalla) o unos curiosos trajes de pingüino que nos proporcionaban cierta invulnerabilidad, hacÃan que jugar fuera algo hilarante.
Evidentemente, en el modo dos jugadores, se iba imponiendo una escala de violencia gratuita “Ay, no querÃa tirarte esa bomba, es que el CPC no me ha pillado bien la diagonal” “Uy, si te he dado. Vaya rebote más tonto que ha pegado esa bomba, ¿no?” que al final uno olvidaba el objetivo del juego y se liaba a bombardear a diestro y siniestro al otro jugador, primero disimuladamente, y después con todo el descaro del mundo, entre codazos.
Y poco más hay que comentar. Un bonus bastante tÃpico cada tres o cuatro niveles y unos contrincantes que, al final, de un color rosa fosforescente, resistian cinco o seis bombazos, se movÃan al lÃmite de la vista humana y lanzaban unas bombas que, de tanto rebotar en la pantalla, parecÃan de goma.
Un juego, quizás, del montón, y que seguramente no recibió demasiados elogios por parte de la prensa especializada de entonces pero que, en mi opinión, consiguió dislumbrar, como pocos, lo que es jugar “a dobles” en estado puro.
Archivado en: Informática variada
A mi, como programador, me encanta toquetear el código ajeno. Mucho más que generar código desde cero.
Hay que destacar que utilizar código ajeno, ya sea ampliándolo, o simplemente examinándolo, es algo vital para un programador. Pretender programar sin aprender antes a “leer” el código de los demás es como pretender ser un novelista sin haberse empachado de novelas.
A igual que en el caso de la lectura, estudiar el código ajeno sirve para aprender a programar de una forma mucho más efectiva que empezando de cero e ir recurriendo a la consulta constante del API, y es mucho menos tedioso que ir siguiendo un tutorial que, al fin y al cabo, es como ir a New York en visita guiada. Acabas viendo un poquito de todo, pero no puedes salirte del grupo a riesgo de perderte.
Yo tengo la mala costumbre de imprimir los códigos. Configuración de papel horizontal, Times New Roman a 8, tres columnas, numeración automática de página, y reduciendo los márgenes todo lo que permita la impresora. Un bolÃgrafo rojo, una taza llena de un café larguÃsimo con doble o triple carga, e ir picando fragmentos de código como quien va salteando entre canapés en un catering.
He aprendido mucho más MIDP mirando el código de un par de juegos, que siguiendo cinco tutoriales distintos. Ahora que estoy trabajando en el tema, y estoy encadenado durante ocho horas delante de código ajeno, estoy aprendiendo una barbaridad.
Y puedo afirmarlo objetivamente:
Un programador inexperto, cuando lee un código, suele pensar: “¿Que está haciendo aquÃ?” mientras se mira el código una y otra vez, esperando que las lineas de código cambien a algo que se entienda.
Un programador experto, cuando lee un código, suele decir, en voz alta, e indignado: “¿Pero que demonios está haciendo aquà este pedazo de cenutrio? ¡Haciendo esto, lo único que consigue es darme más trabajo A MI!”
Ultimamente, estoy experimentando más de lo segundo que de lo primero.
Archivado en: Noticias sobre esta página
Siento mucho esta falta de actualización (bueno, dos dÃas, tampoco es el fin del mundo).
Me paso más de 8 horas programando en el curro.
Cuando salgo, suelo ir a la facultad a hacer alguna práctica, ya que he tenido que posponerlas todas a partir de las 6.
Y, cuando llego a casa, me pongo a programar un poco más para ponerme al dÃa, que esto del trabajo ha llegado muy de golpe y tengo que ponerme a buen nivel.
Y, claro, lo que programo en el trabajo lo considero estricto secreto profesional (aunque, curiosamente, no me han comentado nunca que lo fuera).
Lo que programo en las prácticas de la facultad es demasiado aburrido para explicar aquÃ.
Y lo que programo en casa está muy relacionado con lo del curro, por lo que también lo considero, en su mayorÃa, secreto profesional.
Asà pues, ocupo unas 14 horas al dÃa con cosas de las que no puedo hablar (aunque sea programación de juegos). Y aunque sà tengo tiempo para ponerme a bloguear, no lo tengo para jugar o ponerme a rebuscar “oldies” por internet. Y sin juegos, no hay crÃticas. En un par de dÃas tendreis un suculento post, no temais.
A no ser que querais una clase sobre las Exception, las IOException o las UIException…
Archivado en: Divagaciones
Cuando compramos un café en un McDonalds o similar, podemos ver que en la taza pone algo parecido a: “Cuidado, la bebida de esta taza puede estar caliente”.
“Eso espero”, pienso yo mentalmente. Los cafés se sirven calientes. De hecho, si en el momento de servirme un café, este está frÃo, exigiré un café caliente. Vaya, es de sentido común que un café se hace mediante agua caliente, no con agua frÃa.
También es de sentido común que si uno coge una taza y está caliente, es muy probable que su contenido también lo esté. Vamos, de perogrullo.
Pues esta advertencia viene porque, en los USA, una mujer compró un café en un McAuto de esos. Conduciendo, se le cayó el café a las piernas, y se quemó. Denunció al McDonald por no avisarle que el café estaba caliente. Y, como ya sabemos como es la justicia americana, ganó.
Con los videojuegos parece que nadie quiere cometer el mismo error. Me encuentro este mensaje al inicio el Mario Party de GBA, versión americana.
Asà pues, voy a ver cuales son estos mensajes tan importantes para mi salud.
El más importante es el de la posibilidad de tener un ataque epiléptico mientras se juega (oh, bueno, la mayorÃa de manuales de instrucciones también lo comentan). Nos dan una serie de consejos a cumplir aunque nunca hayamos tenido ningún ataque de epilepsia:
1.- Colocarse lejos de la pantalla: Vale. Pero aviso que en el caso de la GameBoy me cuesta bastante jugar cuando me aparto a más de un metro. El palo de escoba no tiene la misma precisión que mis dedos.
2.- Usar el televisor más pequeño que tengamos: Ey, un momento. Me están vendiendo que si unos gráficos revolucionarios, un refresco de 60 Mhz y una resolución mejorada para televisores de última generacion… ¿y quieren que juegue en el televisor blanco y negro (que ni siquiera tiene euroconector) que tengo en el armario?
3.- Juegue en una habitación bien iluminada: Pero a la vez, juegos como el Silent Hill o el Project Zero recomiendan jugarlos a oscuras…
4.- Descanse unos 15 minutos por hora aunque crea que no lo necesite: No, eso sà que no. Cuando uno va por depende de que fase de depende que arcade, apretar el botón de pausa y esperar pacientemente 15 minutos NO es una opción.
Después viene una serie de consejos que, básicamente te dice que, si te duelen los brazos de tanto jugar, mejor que descanses un poco.
Yo estoy convencido que lo próximo será poner mensajes en las pelÃculas (sobretodo teniendo en cuenta que cada vez son más largas), al estilo: No pretenda ver esta pelÃcula entera. Cada hora, pausela y espere 15 minutos. O en la televisión: Mire este canal con la televisión más pequeña que tenga en casa.
Cuando seguimos viendo algunos consejos varios, la situación ya llega a puntos dignos de un show de los Monty Pyton:
- No deje caer la consola Game Boy ni ninguno de sus componentes, ni permita que sufran ningún golpe. Hacerlo podrÃa estropear la consola.
Y, mi favorito:
- Los nudos en los cables son un peligro potencial.
Se han olvidado el: No permita que su gato mordisquee el cable de alimentación…
Archivado en: Informática variada
Desde que estoy en esto del mundillo de los juegos para móvil, me he dado cuenta de un fenómeno en ascenso.
No me refiero a la piraterÃa de dichos juegos (esto ya hace años que lo conozco) sino a la modificación de gráficos de un juego java.
La mayorÃa sabreis que un archivo java para móvil tiene extensión jar. Este archivo no es más que una especie de rar, un archivo comprimido en el cual podemos entrar y ver su contenido.
Y, por regla general, la mayorÃa de dichos juegos java tienen sus archivos gráficos perfectamente visibles y modificables.
Hay gente que dedica su tiempo a coger estos archivos gráficos, con los sprites o fondos de los juegos, y modificarlos. Generalmente utilizando sprites sableados de otros juegos. Es decir, el Rings Fantasy se convierte en Zelda, el Ninja Run se convierte en Mario Kart, etc.
El record lo lleva el Kyushu’s Devil, juego de movil de lucha que han reconvertido, cambiando los gráficos, al Final Fight, Kings of Dragon, Megaman… debido a que dicho juego tiene todos los gráficos, sprites, fondos, pantallas de menú, etc, en archivos PNG fácilmente modificables.
No es que yo esté en contra de que la gente se haga sus propios gráficos, pero el problema es que todas estas creaciones, además de generar piraterÃa de estos juegos, hacen que el trabajo original se pierda. Cambian los tÃtulos de crédito, el nombre, y se nombran creadores del juego.
Al fin y al cabo, la piraterÃa es un mal relativamente menor para una compañÃa de juegos. La reputación de una compañÃa también es muy importante. Si un juego es bueno, aunque tenga un porcentaje de piraterÃa, la reputación de la compañÃa sube. Mucha gente optará por comprarse ese juego original, o algún otro juego que lleve el mismo sello. Si, además de piratear un juego, se hace eliminando los nombres de sus creadores originales, la compañÃa pierde por partida doble.
Pero lo peor del caso no es eso. Lo peor es que si uno se mueve por foros de desarrolladores amateurs de juegos, como GameDev.net, se dará cuenta que hay muchos programadores con ganas de hacer juegos que requieren de grafistas que les hagan los sprites para sus juegos.
Asà pues, todos estos grafistas amateurs que se dedican a modificar los juegos ajenos, quizás deberÃan empezar a colaborar en todos estos proyectos, para realizar un trabajo propio, aunque sea desconocido, antes de sablear el trabajo de los demás, aunque sus juegos sean más descargados.
