Internal Beeper


Anuncios
febrero 26, 2006, 9:11 pm
Filed under: Curiosidades de la Red

Buscando por YouTubes he encontrado un par de reliquias curiosas sobre el mundo de la publicidad y los videojuegos.

La primera es el primer anuncio de la GameBoy. Increible como en 30 segundos se pueden recopilar todos los años 80.

Y, como regalo, la publicidad del Legend of Zelda: Link to the Past. Cuanto daño hizo el Thriller de Michael Jackson…



Problemas de la DS
febrero 16, 2006, 1:02 am
Filed under: Divagaciones

Mirando las listas mensuales de los juegos más vendidos en España, via ADESE (Asociación de Distribuidores y Editores de Software de Entretenimiento), veo que aquí en España, la DS tiene unas ventas más que modernas.

Lo que sigue son los títulos de las consolas portátiles que han aparecido en la lista de los más vendidos, indicando la posición en dicha lista y el mes.

Juegos PSP

1 F1 GRAND PRIX (Septiembre 2005)
2 MEDIEVIL: RESURRECTION (Septiembre 2005)
3 RIDGE RACER (Septiembre 2005)
4 GRAND THEFT AUTO: LIBERTY CITY STORIES (PSP) (Enero 2006)
5 GRAND THEFT AUTO: LIBERTY CITY STORIES (PSP) (Diciembre 2006)
5 VIRTUA TENNIS: WORLD TOUR (Septiembre 2005)
6 PRO EVOLUTION SOCCER 5 (PSP) (Enero 2006)
7 WORLD TOUR SOCCER (Septiembre 2005)
9 F1 GRAND PRIX (PSP) (Octubre 2005)
9 METAL GEAR ACID (Septiembre 2005)
10 ULTOLD LEGENDS: LA HERMANDAD DE LA ESPADA (Septiembre 2005)

Juegos DS
4 SUPERMARIO 64 DS (DS) (Abril 2005)
5 SUPER MARIO 64 DS (DS) (Marzo 2005)
5 SUPER MARIO 64 DS (DS) (Mayo 2005)
8 NINTENDOGS: LABRADOR (DS) (Octubre 2005)
9 SUPER MARIO 64 DS (DS) (Junio 2005)
10 NINTENDOGS: DACHSHUND (DS) (Octubre 2005)
10 NINTENDOGS: LABRADOR (DS) (Diciembre 2005)

Juegos GBA

1 POKEMON ESMERALDA (GBA) (Noviembre 2005)
2 POKEMON ESMERALDA (GBA) (Diciembre 2005)
3 POKEMON ESMERALDA (GBA) (Octubre 2005)
4 YOSHI’S UNIVERSAL GRAVITATION (GBA) (Mayo 2005)
5 MADAGASCAR (GBA) (Junio 2005)
5 MADAGASCAR (GBA) (Julio 2005)
9 LOS INCREIBLES (GBA) (Febrero 2005)
7 W.I.T.C.H. (GBA) (Diciembre 2005)
9 POKEMON ROJO FUEGO (GBA) (Abril 2005)
8 KINGDOM HEARTS: CHAIN OF MEMORIES (GBA) (Mayo 2005)
10 POKEMON ESMERALDA (GBA) (Enero 2006)
10 YOSHI’S UNIVERSAL GRAVITATION (GBA) (Junio 2005)

La diferencia es abismal, y aún más si tenemos en cuenta que la PSP apareció en septiembre y la DS en marzo. Mientras que en los tres primeros meses de la DS, sólo se consiguió meter uno de los títulos (Mario 64) en el top ten, en septiembre, 7 de los 10 juegos más vendidos fueron de PSP. Desde mayo, no hay ningún juego de DS, ni siquiera el Nintendogs, que pase del 8º juego más vendido.

Hasta la GBA (con precios por juego muy parecidos a los de la DS) está dando de collejas a su hermana mayor. En estas navidades, el Pokemon ha sido lider indiscutible de ventas, y los juegos de GBA parecen venderse más que los de DS, incluso en este último mes.

Lo más destacable es que en estos 11 meses de DS, sólo dos juegos, el Mario 64 y el Nintendogs, han llegado al top ten. ¿Como se entiende?

Por una parte, por distribución. Nintendogs se agotó en navidades y el Mario 64 también fue dificilísimo de encontrar en los primeros meses de la DS. Probablemente con un stock mayor, se hubieran podido conseguir mejores resultados. Por otra parte, también se tiene que tener en cuenta que el catálogo de la DS es mayor que el de la PSP, lo que hace que las ventas se repartan más y, aún consiguiendo un buen número de ventas en conjunto, ningún juego vende en exceso.

Esto es extrañísimo. Si miramos las ventas en Japón o en USA, los resultados son mucho más favorables para los juegos de DS. Supongo que en parte porque allá han llegado algunos “killer apps” como los juegos Brain, o el Animal Crossing. Aún así, también es probable que el target español sea radicalmente distinto al de otras zonas…

Actualización: También es muy pausible que ADESE no contabilice los juegos de los packs. Generalmente se hace así porque el juego de un pack no implica intencionalidad de comprarse ese juego (es decir, uno puede comprarse el pack XBox + Halo porque le sale rentable, pero porque quiera la XBox, no el Halo). Pero es posible que las particularidades del target de la DS haga que muchos compradores, al comprar un pack no busquen una DS, sino un juego concreto.



Los problemas de la PSP
febrero 11, 2006, 1:36 am
Filed under: Divagaciones

Aunque la PSP parece remontar ligeramente, es evidente que la cosa no va como a Sony le hubiera gustado.

El gran problema al que se enfrenta la PSP es, precisamente, su potencia. La gran capacidad gráfica hace que realizar un juego para PSP requiera un coste de producción altísimo. Hablamos de equipos de 20 o 30 personas para realizar un juego (fácilmente comprobable mirando los títulos de crédito de cualquier juego de PSP). El coste es, pues, casi el equivalente al de un juego de consola de sobremesa. El mercado en cambio, mucho más pequeño.

Eso hace que un juego en exclusiva para PSP no sea rentable, incluso aun teniendo excelentes ventas. Juegos como el GTA Liberty City se han mostrado deficitarios económicamente a pesar de ser los más vendidos.

Así pues, la única forma de conseguir rentabilidad, manteniendo la carrera de los gráficos, es realizar una conversión, o un remake. Pero, claro está, la PSP no puede mantenerse únicamente mediante copias reducidas de versiones de PS2 y juegos de PSX embellecidos.

Locoroco y EXIT, por ejemplo, es la tendencia que deben seguir los juegos de PSP. Juegos que siguen destacando gráficamente por encima de la DS, pero con un mecanismo original y, sobretodo, un coste de producción mucho menor. Y contenidos extras. La gente adora los contenidos extras descargables.

Pero donde Sony la está cagando completamente es con las actualizaciones de firmware. Los isos funcionan sólo en la 1.5 y, aunque el homebrew funciona en su mayoría hasta la 2.5, es muy engorroso. Se tiene que trampear la consola mediante lectura de png o cargando un save del GTA, pierde la funcionalidad de sleep, se tiene que resetear la consola antes y después de ejecutar un homebrew…

Eso hace que mucha gente se decante por mantenerse en la versión 1.5. Como mucho, en la 2.0, al ser la única que ofrece la posibilidad de bajar a 1.5.

Que Sony obligue a actualizar el firmware con los nuevos juegos no hace que la gente se la actualice. Al contrario, lo que hace es que la gente no compre nuevos juegos porque, o pierde el homebrew, o pierde el dinero del juego.

Sony está perdiendo la posibilidad de convertir la PSP en una consola multiusos (que precisamente era la intención inicial). Una consola con 1.5 permite mucha más funcionalidad gracias al homebrew (por ejemplo, navegación y gestión archivos mediante shells, lector de txt y pdf, ejecutar código LUA, etc, etc…) que las versiones oficiales no ofrecen.

Sony cree que va a conseguir mejores ventas de juegos forzando a la gente a actualizarse, con la creencia que, al perder la posibilidad de ejecutar homebrew e isos, la gente se resignaría a comprar las novedades. Pero precisamente tiene el efecto contrario. La gente no compra juegos para poder seguir ejecutando homebrew e isos…

Al final, resulta que el principal enemigo de la PSP no son los crackeadores de firmware (que por cierto, han desaparecido misteriosamente de la “scene”, posiblemente por presiones de Sony), ni siquiera la DS, que compite en otro mercado (también portatil, pero otro mercado) sino que su principal enemigo es ella misma…



Mobile Game Development (II)
febrero 8, 2006, 1:01 am
Filed under: Divagaciones

Venga, empezamos la parte interesante: Programación. Este post va a ser un poco duro para los no programadores, quedais avisados.

Programar para móviles, en Java, es bastante fácil. Si sabes Java (es decir J2SE), sabes J2ME. Es decir MIDP.

Básicamente es lo mismo. La API (comandos disponibles para el programador) es más limitada, lo que obliga a hacerse uno mismo muchas cosas que en Java convencional ya te vienen hechas, y por otra parte se dispone de algunos comandos, sobretodo en MIDP2, que bien utilizados (y suponiendo que el móvil para el que programas sea completamente compatible con esas funciones) pueden mejorar la capacidad gráfica enormemente.

Para aprender más sobre MIDP, no hay nada mejor que pasarse por developer.com, MicroDevNet, tutoriales varios o la siempre infalible página de Sun. También por emule se puede encontrar bastante información sobre J2ME.

Pero hay algo que no se acostumbra a enseñar en los tutoriales. Para programar en J2ME, sobretodo cuando tratamos con móviles reales, debemos abandonar la programación orientada a objetos de JAVA. Al menos, en su faceta más pura.

A todos los que hemos aprendido Java nos han enseñado que lo mejor es tener un sistema de clases organizado. Muy organizado. Múltiples clases, herencias, hacer decenas de clases para agrupar cualquier tipo de dato relacionado…

Para programar con móvil uno debe desprenderse de esto. Hacer objetos, es decir, instancias de clases, le cuesta una barbaridad a un móvil. Destruirlos aún más. Aún suponiendo que el móvil libere completamente la memoria, y sin fragmentarla, que es más la excepción que la regla.

Imaginemos el Zelda pasado a móvil. Sistema de habitaciones donde hay un número limitado de enemigos. Cualquier manual de Java nos explicaría que lo que tenemos que hacer es una clase genérica de “enemigo”. Y tener clases heredadas para los enemigos con características distintas. Y, evidentemente, cada vez que se entra en una habitación, generar un objeto por cada enemigo (o tenerlos todos previamente generados), e irlos destruyendo los objetos “enemigos” cuando los vas matando.

Pero si queremos que realmente el juego se pueda ejecutar en un móvil, se tiene que programar más a lo bruto. Por ejemplo, la mejor solución sería:

-Tener una tabla de características de cada tipo de enemigo, en una array bidimensional. Será una array relativaente pequeña, de 10×10 bytes.

-Tener una array de booleanos de los enemigos con su estado (vivo o muerto) o, mejor aún, de bytes (en MIDP, un booleano ocupa lo mismo que un byte) con la vida restante de ese enemigo (si queremos guardar información adicional, como la habitación donde están o incluso la posición en concreto, el tamaño empezará a ser preocupante, por lo que es mejor cargar sólo los de esa fase).

-Tener una array de índices de que tipo de enemigo es cada uno.

Así, ya no tenemos distintos objetos que crearemos y destruiremos constantemente, consumiendo la memoria del móvil. Tendremos unas pocas arrays de información que solo tendremos que cargar al inicio del juego y destruir cuando salimos de él.

Bienvenidos al maravilloso mundo de la programación para móviles…