iPhone OS 4.0 y la nueva pol铆tica de Apple

Apple desat贸 la pol茅mica la semana pasada cuando anunci贸 una nueva versi贸n de los t茅rminos de servicio que deben respetar los desarrolladores si es que desean publicar sus juegos y aplicaciones para sus plataformas iPhone/iPad.

M谩s espec铆ficamente el punto de la discordia enuncia: 鈥淎pplications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.鈥. Esto significa que Flash CS5 no podr谩 realizar finalmente su debut, lo cual es malo muy malo para muchos desarrolladores que con productos ya creados en Flash ten铆an pensado – y muchos ya se encontraban en ello – realizar una conversi贸n para iPhone/iPad. Tambi茅n es muy malo para Adobe, naturalmente, ya que hace tiempo desea colocar su tecnolog铆a casi universal en la plataforma de Apple, si茅ndole la misma esquiva una y otra vez.

Finalmente, esto tambi茅n es muy malo para muchos otros desarrolladores que utilizando tecnolog铆as que realizan un proceso muy parecido a lo que har铆a Flash CS5 permiten a sus usuarios crear aplicaciones de un modo muy productivo en lenguajes como Lua, C#聽 y otros. Entre estas tecnolog铆as podemos citar a Unity3D, Corona, Titanium y MonoTouch.

En el caso de Unity3d, la empresa Unity Technologies ha intentando calmar un poco a su comunidad de desarrolladores pidiendo un poco de tiempo para anunciar si afecta o no a su herramienta pero mostr谩ndose optimistas en esta cuesti贸n. Sin embargo, la realidad es que la nueva pol铆tica s铆 parece que afectar谩 directamente聽 a Unity iPhone dado que el sistema de compilaci贸n AOT de Mono es muy parecido al que usa Flash CS5 para generar aplicaciones iPhone y es realmente una capa de software intermedia.

Apple siempre estuvo en contra de los int茅rpretes de terceras partes corriendo dentro de sus aparatos. De hecho, tampoco es la primera vez que realiza un cambio en los t茅rminos de servicio que afecta a empresas y desarrolladores: en Julio de 2008 anunci贸 que no permitir铆a compiladores JIT (Just in Time), muchos lenguajes interpretados hab铆an encontrado como posibilidad crear un compilador JIT que convirtiese el c贸digo intermedio a nativo al momento de ejecutarse (como por ejemplo Mono). En aquel entonces Unity tambi茅n se vi贸 afectado y colabor贸 con el proyecto Mono para crear el compilador AOT (Ahead Of Time), pudiendo de este modo esquivar la restricci贸n.

Ahora la cosa parece un poco m谩s complicada. 驴Y cu谩les son los motivos que sostiene Apple para realizar semejante cambio?聽 Veamos:

1. Apple no desea que el AppStore se inunde de aplicaciones de baja calidad, debido a que – seg煤n Steve Jobs – las capas intermedias generan aplicaciones por debajo del estandar de calidad deseado.

2. Si una aplicaci贸n depende de una capa intermedia, realizada por una tercera parte, y esta posee un bug entonces Apple no podr谩 corregir dicho bug porque no se encuentra dentro de su plataforma. Si esta capa intermedia se volviese muy muy popular, como lo es Flash, entonces miles de aplicaciones depender铆an de ella y un bug en la misma afectar铆a seriamente la experiencia que tendr铆an miles de usuarios.

Dem谩s est谩 decir que estas 鈥渞azones鈥 son bastante discutibles y muchos sostiene que lo que realmente quiere Apple es que los desarrolladores no tengan un trabajo f谩cil al momento de querer llevar sus aplicaciones a otras plataformas, como Android. De este modo, ser铆a una estrategia que buscar铆a mantener aferrado al desarrollador s贸lo a iPhone/IPad.

La realidad es que, m谩s all谩 de lo valederas que pueden ser las razones de Apple – d谩ndole el beneficio de la duda en cuanto a buenas intenciones – es muy poco feliz realizar este tipo de cambios luego de dos a帽os de inversi贸n de muchas empresas y desarrolladores independientes en la plataforma.

Por otro lado, realizarle un boicot a la empresa de Steve – como muchos est谩n solicitando -聽 tampoco parece que vaya a prosperar, dado que, para bien o para mal, Apple聽 le est谩 pagando las cuentas a muchos de ellos. Y quienes, a pesar de esta mala jugada, se encuentran buscando alternativas tecnol贸gicas que le permitan continuar publicando sus aplicaciones en esta plataforma.

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

[IRROMPIBLES] presenta su nuevo portal en Internet

La versi贸n 4.0 del portal en Internet [IRROMPIBLES] evoluciona en una red social para videojugadores, consumidores de tecnolog铆a, artistas y programadores de Am茅rica Latina, siendo su principal objetivo la industria de desarrollo de videojuegos de la regi贸n.

Buenos Aires, 29 de marzo de 2010 鈥 [IRROMPIBLES] presenta la versi贸n 4.0 de su portal en Internet que, adem谩s de lucir un dise帽o m谩s moderno y din谩mico, abraza el concepto de red social, para convertirse en el centro de reuni贸n de los aficionados a los videojuegos, la tecnolog铆a de consumo, el entretenimiento, el arte, la programaci贸n y el desarrollo de videojuegos en la regi贸n latinoamericana.

El portal facilita la creaci贸n de un perfil comunitario relacion谩ndolo con videos, fotograf铆as, grupos de inter茅s y blogs que publica el mismo usuario. Como siempre, la comunidad puede tambi茅n participar de una gran cantidad de foros que abarcan todos los temas.

[IRROMPIBLES] 4.0 promueve el desarrollo de videojuegos en la Argentina y en Am茅rica Latina mediante la publicaci贸n de art铆culos sobre el estado de la industria en la regi贸n, entrevistas a los estudios de desarrollo, artistas, programadores, creativos, educadores y dem谩s temas relativos a la creaci贸n de videojuegos y otras actividades t茅cnicas y culturales. Mantiene una bolsa de empleo e implementar谩 una secci贸n especial para curr铆culos profesionales.

Asimismo, el portal expone los nuevos productos que llegan al mercado, como: Hardware, audio, video, telefon铆a y otros t贸picos, en un espacio donde la comunidad participa activamente.

Se puede acceder al portal en www.irrompibles.com.ar.

[IRROMPIBLES] cuenta con una versi贸n amigable para iPhone accesible en la misma direcci贸n.

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Volviendo de a poco

No suelo hacer posts relacionados al sitio en s铆 mismo, creo que en un par de a帽os habr茅 hecho uno o dos nom谩s, pero en esta ocasi贸n quer铆a comentar – dado que hace un tiempo que no posteo – que el sitio comenzar谩 a tener mucha m谩s actividad que la actual en muy poquito tiempo (aunque no de inmediato).

De un modo casi recurrente en mi vida lo urgente siempre se le impone a lo importante y muy frecuentemente me descubro y redescubro prest谩ndole m谩s atenci贸n a lo que urge dej谩ndo de lado todo lo dem谩s. Con un poco de suerte este a帽o ser谩 distinto.

Me gusta mucho escribir, m谩s a煤n de videojuegos que es algo que realmente me apasiona. He “escrito” cientos de posts en mi cabeza mientras viajaba en colectivo pero much铆simas veces quedaron s贸lo all铆 y en pocas ocasiones, en el a帽o que pas贸, se transribieron a este gran papel virtual que tienen delante.

Si bien nunca promet铆 una frecuencia de posteo, y estoy en desacuerdo con quienes en sus blogs piden perd贸n por no postear m谩s seguido, quisiera realmente poder al menos tener el tiempo de escribir una nota de opini贸n sobre alg煤n tema relacionado al desarrollo de juegos una vez por semana; las ganas siempre estuvieron, espero que el tiempo este a帽o se haga presente. Crucemos los dedos. :)

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

EVA09: Llamado a presentaci贸n de propuestas

ADVA鈥 (Asociaci贸n鈥 de鈥 Desarrolladores鈥 de鈥 Videojuegos鈥 Argentina鈥)鈥 abre鈥 el鈥 llamado鈥 a鈥 presentaci贸n 鈥ヾe 鈥﹑ropuestas 鈥﹑ara 鈥ヾisertantes 鈥〆n 鈥﹍a 鈥7ma 鈥〆dici贸n 鈥ヾe 鈥〦VA鈥 (Exposici贸n 鈥ヾe 鈥¬ideojuegos 鈥〢rgentina) 鈥゛ realizarse 鈥〆n 鈥﹍a 鈥︰niversidad 鈥ヾe 鈥〣elgrano 鈥(Zabala 鈥1837 鈥┾ 鈥〤iudad鈥 de 鈥〣uenos 鈥〢ires) 鈥﹍os 鈥ヾ铆as 鈥4 鈥﹜ 鈥5 鈥ヾe 鈥〥iciembre 鈥ヾe 鈥2009.

Se鈥 recibir谩n 鈥﹑ropuestas 鈥﹑ara:

鈥 Charlas鈥 y 鈥㏄ostmortems
鈥 Workshops鈥 (talleres)
鈥 Debates 鈥﹐n鈥恠tage
鈥 Mesas鈥 redondas

La 鈥ゝecha 鈥﹍铆mite es鈥 el 鈥〥omingo 鈥11 鈥ヾe 鈥㎡ctubre 鈥ヾe 鈥2009.

Las 鈥﹕iguientes 鈥﹕on 鈥﹍as 鈥┟eas 鈥﹖茅cnicas 鈥﹕ugeridas 鈥﹑ara鈥 el鈥 contenido:

鈥 Arte鈥2D:鈥 Conceptos 鈥/ 鈥㏄ixel鈥〢rt 鈥/鈥 Colores
鈥 Arte鈥3D:鈥 Modelado 鈥/ 鈥〢nimaci贸n 鈥/ 鈥㏕exturas 鈥/ 鈥㏒haders
鈥 Business:鈥 Industria 鈥/ 鈥㎝anagement 鈥/ 鈥〦ntrepreneurship
鈥 Dise帽o鈥 de鈥 Videojuegos 鈥/ 鈥〨ui贸n
鈥 M煤sica鈥 & 鈥㏒onido
鈥 Programaci贸n 鈥(gr谩fica, 鈥﹊nteligencia 鈥゛rtificial, 鈥゛lgoritmos, 鈥〆tc)
鈥 Producci贸n鈥 y 鈥〢dministraci贸n鈥 de 鈥㏄royectos

Todas鈥 las 鈥﹑ropuestas 鈥﹕er谩n 鈥〆valuadas 鈥﹜ 鈥﹕eleccionadas 鈥﹑or 鈥﹗na 鈥ヽomisi贸n 鈥ヽonformada鈥 para 鈥﹖al 鈥ゝin. 鈥㎜a 鈥﹏otificaci贸n鈥 de 鈥゛ceptaci贸n 鈥┾﹕er谩 鈥〆nviada鈥 el 2 鈥ヾe 鈥㎞oviembre 鈥ヾe 鈥2009.

Mas informaci贸n en el post oficial: http://www.adva.com.ar/2009/09/11/eva09-llamado-a-presentacion-de-propuestas/

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Flashback: The Quest for Identity

La gloria de ayer de la cual nos ocuparemos en esta ocasi贸n no es m谩s ni menos que el Flashback: The Quest for Identity, desarrollado por Delphine Software.

Delphine Software, estudio de desarrollo de origen franc茅s, fue responsable adem谩s de otros cl谩sicos como Out Of This World (o Another World) y Fade to Black. Fundada en el a帽o 1988, se enfoc贸 durante los primeros 4 a帽os de su vida en plataformas Amiga y Atari ST, luego incursion贸 en algunas consolas (Sega CD, NES) y finalmente se volc贸 a PC y Playstation. En el a帽o 2003 fue comprada por Doki Denki Studio que un a帽o despu茅s se declar贸 en bancarrota (no pregunten porque una empresa compra a otra y a帽o despu茅s funde :P )

Una imagen del juego del primer nivel

(Leer nota completa)

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Los buenos juegos y los plazos de entrega

El lanzamiento de un juego es anunciado; muchas previews se generan a partir de ello; el juego innova en uno o m谩s aspectos o utiliza alguna licencia conocida no empleada hasta entoces en ning煤n producto del medio; jugadores entusiastas hacen eco, retransmiten e incluso amplifican todas las 鈥渘ovedades鈥 que el juego incluir谩. Sin embargo, el juego sale a la calle y decepciona estrepitosamente. 驴De qu茅 juego estamos hablando? 驴Cu谩ntos t铆tulos han sido publicados que repiten hasta el hartazgo esta f贸rmula? 驴Cientos? 驴Miles? Pero lo m谩s importante: 驴Por qu茅 raz贸n se defrauda de esta manera? 驴Acaso los desarrolladores no advirtieron todas las cr铆ticas, faltantes, errores y problemas que luego las reviews publicaron? La respuesta siempre es la misma: S铆, pero nos quedamos sin tiempo y/o dinero.

Un caso contrario a esta situaci贸n son los muchachos de Blizzard. Blizzard, recostado sobre un colch贸n colmado de billetes de alta denominaci贸n 鈥 relleno que mes a mes le otorga el WOW – pueden esperar y trabajar sobre sus productos todo el tiempo que sea necesario 驴el resultado? Juegos de muy alta calidad y el sello que muy pocas empresas puede adjudicarse: el nunca haber defraudado a sus fan谩ticos. Blizzard cancel贸 proyectos con a帽os de trabajo s贸lo porque llegaban a un resultado que consideraban suficientemente bueno.聽 De hecho, cancel贸 muchos m谩s proyectos de lo que imaginamos. Esta situaci贸n es desgraciadamente muchas veces inevitable si es que deseamos que todos nuestros productos tengo un cierto nivel de calidad y en definitiva, ser reconocidos por ello pero no todas las empresas pueden darse ses lujo.

La industria sabe y est谩 de acuerdo que el desarrollo de un juego consiste en generar un prototipo y refinarlo una y mil veces hasta llegar al producto final, un prototipo evolutivo.

驴Qui茅n puede predecir cu谩ntas iteraciones son necesarias para llegar a un producto refinado y 鈥 mucho m谩s importante a煤n 鈥 a un juego divertido? 驴Qui茅n puede anticiparse a todos los problemas que el desarrollo de un software complejo -聽 con un grupo desarrollo mucho m谩s multidisciplinario que en ning煤n otro tipo de software 鈥 que pueden acaecer? La metodolog铆a ayuda 鈥 sin ella estar铆amos perdidos 鈥 pero los plazos de desarrollo ajustados s贸lo permiten generar un producto que cumpla con las especificaciones previamente pactadas y que tienen que ver con caracter铆sticas funcionales solamente. El tanta veces mencionado fun factor es una ninfa que corre desnuda por el bosque y que absolutamente nadie puede acreditar tener o usar una metodolog铆a que asegure su conquista.

Otro ejemplo de empresa generadora de buenos juegos es Popcap Games quienes tampoco apuran los juegos que tienen en desarrollo. De hecho, Popcap posee desarrolladores trabajando en juegos sin saber si alguna vez ser谩n publicados, s贸lo algunos de ellos lo logran. Popcap bien sabe que un buen producto genera suficientes ganancias como para cubrir los costos de decenas de intentos fallidos (Su 煤ltimo t铆tulo, Plants vs. Zombies, se conviriti贸 en poco tiempo en el juego m谩s vendido de la compa帽铆a superando incluso a Peggle y Bejeweled).

Naturalmente que los estudios de desarrollo saben que apurar un juego 鈥 y recortar iteraciones de evoluci贸n 鈥 significa simple y llanamente un peor producto. Sin embargo, agotados los tiempos pactados y/o el dinero previsto muchas veces no queda otra salida que salir como se pueda. Incluso por esta raz贸n much铆simas veces los productos se retrasan. Los publishers entienden que emplear algo m谩s de dinero para obtener un mejor juego, retornar谩 con creces al momento en que este sea publicado. Pero, claro, todo tiene un l铆mite. E incluso muchas veces el tipo de contrato que negocia el desarrollador con el publisher impide cualquier tipo de retraso a costas de quien financia el proyecto. Inicialmente se pact贸 un tiempo, un dinero y un set de caracter铆sticas; si el proyecto se retrasa los costos ir谩n a cuenta del estudio desarrollador, quien usualmente no tiene espalda para aguantar un retraso significativo y que solo podr谩 hacerlo perdiendo parte de las ganancias esperadas.

De todas las relaciones contractuales entre publisher/desarrollador el escenario de work for hire (WFH) es el m谩s riesgoso para encarar el desarrollo de un juego,聽 debido a que se basa en una estimaci贸n muy precisa del tiempo total que el proyecto llevar谩 pero predecir la cantidad de iteraciones que conllevar谩 el proyecto hasta obtener el pulido y fun factor deseado 鈥 como ya hemos mencionado 鈥 es realmente dificil. A fin de cuentas se termina entregando 鈥渓o mejor que se pudo hacer con el tiempo que se tuvo鈥 o reduciendo ganancias llegando incluso a no obtenerlas pensando que si el juego es suficientemente bueno traer谩 nuevos negocios.

No es posible, para cualquier estudio de juegos, desarrollar un producto con fecha de release 鈥渨hen it鈥檚 done鈥. Pero basar un estudio 100% en WFH puede ser muy riesgoso y no tener productos con recurrente tambi茅n podr铆a afectar la situaci贸n financiera y econ贸mica del estudio a mediano plazo dado que requerimos una continuidad financiada de todo el personal que la empresa posea. Tal vez una buena estrategia pase por la diversificaci贸n, la negociaci贸n de buenos contratos y establecer una relaci贸n de confianza con los clientes basada en la concreci贸n de proyectos previos exitosos y de buena calidad, adem谩s de crear de productos con recurrente, posiblemente a partir de la negociaci贸n con alg煤n cliente de la participaci贸n en las ganancias de los productos desarrollados.

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

La casualizaci贸n de los juegos

El juego en cuesti贸n era un FPS, para machos, de esos que se juegan mascando tabaco y con una bailarina de Charlestone semidesnuda sentada sobre nosotros. Sin embargo, en alg煤n punto de su desarrollo alguien decide cuambiar el rumbo 驴Y si hacemos el juego m谩s casual? 驴Si lo hacemos atractivo al p煤blico femenino? 隆S铆, publiqu茅moslo en facebook!. Finalmente, tras much铆simo esfuerzo, danzan delante de nuestras narices chimpanc茅s vestidos con tut煤s rosas y arroj谩ndose bananas…de goma espuma, claro, no vaya a ser que alguno se saque un ojo.

Esta historia se viene repitiendo en los 煤ltimos a帽os en mucho de los estudios de desarrollo de juegos del planeta. Los publishers meten presi贸n para casualizar los juegos, masificar, ampliar la audiencia, las palabras claves son “wider audience”.

Pero 驴Cuando comenz贸 esto? Tal vez fue Nintendo con su Nintendo DS y Wii quien hizo de punta de lanza y demostr贸 que tanto mercado se estaban perdiendo otras empresas. Quiz谩 haya sucedido incluso antes y el 茅xito de los juegos casuales tambi茅n lo haya demostrado llevando incluso a Electronic Arts a crear un departamento espec铆ficamente para explotar este nicho llamado EA Casual Entertainment.

Pasamos tan r锟絧ido del Doom al Cooking Mama que no nos dimos cuenta

Redes sociales, como Facebook, llevan millones de usuarios a convertirse en gamers casuales, ya no es necesario ni siquiera ir a un sitio nuevo, simplemente clickear el link que nos sugiere uno de nuestros amigos para poder experimentar un nuevo clon de bejeweled (maravillas de la tecnolog铆a 卢卢).

Una demanda en crecimiento, nuevas necesidades por satisfacer y todas las empresas van por su porci贸n de la torta. Sin embargo 驴Hasta que punto se puede compremeter un dise帽o para alcanzar un mayor p煤blico? 驴Cu谩l es la verdadera raz贸n por la cual hacemos juegos? No es cierto que los estudios de juegos s贸lo quieran hacer dinero, tal vez sea as铆 en el caso de los publishers, pero en los estudios existen talentos creativos que no les parece lo mismo y aunque sean los empresarios quienes finalemente le den un giro al tim贸n, tampoco es cierto que para ellos sea lo mismo, al fin y al cabo existen muchos otros negocios con mejor relaci贸n riesgo/rentabilidad que hacer videojuegos.

En lo personal, no tengo nada contra los juegos casuales, podr铆a disfrutar mucho realizar un juego de perros y gatos que se disparen pelotitas…creo. El asunto es 驴Porque si una idea parec铆a buena debemos cambiarla en favor de atraer m谩s p煤blico? Entiendo que es necesario hacer ciertas conseciones m铆nimas siempre y cuando no se traicione la idea original. La cuesti贸n central no pasa por el juego casual o hardcore sino por dise帽ar en funci贸n de lo que quieren las masas exclusivamente, tratando de conformar a todo el mundo. Algo muy com煤n en tantas otras industrias como – por ejemplo – la literaria. El C贸digo Da Vinci de Dan Brown y los cientos de clones de relatos entrevesados con aspectos religiosos que salieron casi inmediatamente con el fin de hacerse con un pedazo del bot铆n.

La industria cinematogr谩fica fue, es y seguir谩 siendo la prostituta del pueblo en este sentido, como era de suponer. Siendo tal vez el ejemplo m谩s reciente, de los cuales hay miles, el caso de la pel铆cula de Max Payne en donde su director – John Moore – con el fin de “alcanzar una mayor audiencia” intent贸 hacer una pel铆cula menos violenta y sangrienta qued谩ndose a mitad de camino y sin poder satisfacer a nadie.

Afortunadamente, existen ejemplos de casos contrarios que nos demuestran que todav铆a existe quienes apuestan por sus mantener sus ideas fieles al concepto original. Y no s贸lo los buenos ejemplos provienen del lado independiente. Rockstar public贸 recientemente GTA: Chinatown Wars para Nintendo DS y no por ello hizo una juego menos violento y sangriento sino todo lo contrario. GTA: Chinatown Wars es quiz谩s el GTA menos pol铆ticamente correcto de todos y no por ello ha dejado de ser un 茅xito.

No soy un casual gamer. Detesto el 80% de los juegos de la Wii. No quiero esos elementos inunden los otros juegos, simplificando hasta el extremo lo que antes ten铆a una cierta profundidad. Ver como la industria se vende de esta manera me recuerda a Homero Simpson bailando vestido de oso Panda para que el se帽or Burns le arroje unos cuantos billetes. Sinceramente quisiera ver menos estudios corriendo atr谩s del nicho de moda y m谩s haciendos juegos distintos en donde se cuente una historia o se transmita una experiencia, tal cual el equipo de desarrollo imagin贸. Haciendo lo que nos gusta, con pasi贸n y esfuerzo, a煤n se puede ganar el sufieciente dinero para mantenerse a flote y al fin y al cabo hacer otro clon del Bejeweled no va a llenarte los bolsillos y el mundo tampoco lo necesita.

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

La mentira OnLive

Se anunci贸 en la GDC 09 un producto revolucionario. Otro m谩s. Como cada tanto aparecen. En este caso el “producto revolucionario” consiste en una consola que nos permitir铆a jugar los 煤ltimos juegos que salgan al mercado haciendo uso de una PC o Mac est谩ndar o con una micro-consola OnLive contando simplemente con una “buena” conexi贸n de banda ancha.

B谩sicamente – y para no andar con rodeos – la idea es que nos dan una peque帽a cajita (aunque tambi茅n se puede usar una computadora) que conectamos a un televisor y a internet. Por medio de un gamepad inal谩mbrico controlamos el juego. Luego, los juegos que queramos jugar ser谩n stremeados hacia el aparato a medida que interactuamos con 茅l. Las acciones realizadas por el jugador, por medio de su gamepad, ser铆an enviadas a un centro de datos, en donde se encontrar铆a la plataforma donde realmente se encuentra corriendo el juego y al mismo tiempo todos los frames producidos por el juego ser铆an enviados al jugador tomando el camino contrario, visualiz谩ndose en la pantalla o televisor como si estuvi茅semos corriendo el juego localmente. De este modo, la micro-consola funcionar铆a simplemente como un remotizador de entrada/salida.

No es necesario ser un sabio de las telecomunicaciones para saber que esta idea puesta en pr谩ctica es un disparate y un fracaso asegurado, al menos a nivel masivo.

Es cierto que el mercado se mueve hacia la distribuci贸n de contenido digital haciendo uso de internet, esto – por supuesto – no va a cambiar. La tendencia seguir谩 acentu谩ndose y soluciones h铆bridas entre lo que hoy son las consolas y lo que propone OnLive se convertir谩n en una realidad en muy pocos a帽os. Pero…decir que el mundo est谩 preparado para la distribuci贸n de contenido digital realtime hoy, es otro asunto. 驴Por qu茅? Veamos.

En primer lugar, el principal gran problema tiene que ver con el lag. S铆, es cierto que Steve Perlman nos jura que no existir谩 ni siquiera un poco pero esto es sencillamente imposible – al menos en un escenario normal con la arquitectura que posee la red de redes hoy d铆a (y que no cambiar谩 de un d铆a para otro). M谩s all谩 del ancho de banda que tengamos, aunque contratemos un servicio de banda ancha de 10 Mbs, o 20 Mbs o lo que sea, existe un tiempo que agrega el switch de paquetes en los routers, mientras m谩s lejos estemos del centro de datos m谩s hops se agregar谩n y m谩s lag sufriremos. Y en este sentido, tengamos en cuenta que el lag de entrada se hace perceptible y molesto en niveles realmente bajos (existen gamers que usan mice de m谩s de 1000 dpi porque menos les resulta poco). Adem谩s, las fluctuaciones de disponibilidad de ancho de banda en internet son constantes, incluso es com煤n percibirlo en comunicaciones por VoIP (voz sobre IP) que requieren apenas 64 Kb para funcionar de manera decente.

El 煤nico modo de disminuir el lag, de un modo realista, ser铆a colocar los centros de datos lo m谩s cerca posible del jugador, por ejemplo, junto al DSLAM en un central telef贸nica que nos brinda el servicio de banda ancha por medio de DSL, pero esto no es pr谩ctico debido a que el costo de los equipos que habr铆a que colocar en los centro de datos ser铆an muy altos y m谩s a煤n lo ser铆an si OnLive debiese colocar un minicentro de datos por DSLAM.

En segundo lugar, existe otro gran problema que est谩 relacionado al primero. Para lograr enviar un “pantalla” del juego a la mayor velocidad se requerir谩 que la compresi贸n sea lo m谩s alta posible, sin embargo comprimir video es una operaci贸n muy costosa a nivel de uso de CPU 驴Podr铆a realizarse este proceso en tiempo real? Y m谩s a煤n 驴Con una resoluci贸n decente y similar a los juegos actuales? Actualmente mis juegos en mi XBOX 360 corren a 1080p, 驴Ser铆a razonable contar con cifras similares haciendo uso de un ancho de banda de un servicio hogare帽o?

En tercer lugar, 驴Cu谩l ser铆a el costo de colocar un centro de datos? Sabemos que van a requerir colocar muchos y distribuidos geogr谩ficamente de un modo muy cercano a los jugadores, seguramente el servicio fracasar谩 antes de salir de US, pero incluyo all铆 no creo que sean muchos los jugadores que tengan una buena experiencia con 茅l. Deber谩n colocar granjas de equipos capaces de correr juegos como el Gears Of War o GTA IV y al mismo tiempo que tambi茅n tengan la potencia para comprimir cada uno de los frames que generen en tiempo real. 驴Ser铆a posible montar un servicio as铆 para todo un pa铆s y dejar conforme a los jugadores a un precio razonable? No lo creo.

Sin embargo, y como mencion茅 anteriormente, la tendencia sin duda viene por este lado. Usar cada vez m谩s la red, pero no pasar a una caja boba en tan poco tiempo. Comenzaremos a ver, en las futuras generaciones de consolas, que el papel de los servicios de descarga de juegos ser谩 cada vez m谩s importante; el juego en cajita eventualmente desaparecer谩 como lo hicieron los discos de vinilo; las comunidades y los contenidos generados por las mismas seguir谩n incrementando su importancia y cada vez ser谩n menos los juegos que puedan experimentarse sin estar conectados a la red.

Pero lo que propone OnLive – a mi parecer – es un poco mucho, a no ser que estos muchachos cuenten con tecnolog铆a extraterrestre como los motores de b煤squeda que usa Google 隆S铆, ya nos dimos cuenta!

La noticia en Irrompibles
GDC: Why OnLive Can’t Possibily Work

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Mono 2.2 utilizar谩 instrucciones SIMD para optimizaciones

El proyecto Mono, que es una implementaci贸n libre de la plataforma .NET de Micrsoft, est谩 lanzando su versi贸n 2.2 esta semana. En este caso, una de las mejoras m谩s importantes que posee la versi贸n es el soporte a instrucciones SIMD (Single Instruction / Multiple Data) que b谩sicamente son instrucciones implementadas por ciertas extensiones en los microprocesadores m谩s comunes (AMD con 3DNow! e Intel con SSE). Estas instrucciones permiten procesar conjuntos de datos asociados a s贸lo una instrucci贸n, lo cu谩l mejorar铆a la performance de las aplicaciones que hagan uso de ellas notablemente.

Por supuesto, uno de los los productos que m谩s se beneficiar铆an con esta nueva adici贸n ser铆a los juegos, incluso ahora los programadores de juegos .NET deber铆a considerar compilar sus juegos con Mono en lugar de utilizar la plaforma de Microsoft.

M谩s informaci贸n: http://www.betanews.com/article/Mono_22_may_overtake_NET_in_some_critical_categories/1232551276

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Personajes mudos

El d铆a de ayer termin茅 el Dead Space y sinceramente me pareci贸 un muy buen juego. Claro que me quedaron algunas peque帽as quejas de porque esto fue as铆 y no as谩, especialmente en temas que tienen que ver con la historia. Sin embargo, mi mayor queja y bronca me la genera una decisi贸n de dise帽o recuerrente en muchos videojuegos y esto es el hecho que el personaje jugador sea totalmente mudo.

Y en ese momento Isaac Clarke dijo: “…”

El mundo se cae a tus pies y tu personaje s贸lo mira, sin expresar emociones. Te encontr谩s con el amor de tu vida, que cre铆as muerto y ni siquiera se asoma un gesto de afecto ni expresi贸n. Todo el mundo de pregunta cosas y te habla normalmente, pero t煤 no contestas, s贸lo miras en silencia casi de manera enferma.

Hubiesen tenido la posibilidad de generar un personaje querible y entra帽able, darle una personalidad. 驴Ser铆a el mismo Duke Nukem si no hablara? Seguramente no.

Los game designers justifican esta decisi贸n argumentando que la idea es que el jugador se identifique de un modo m谩s profundo con el personaje. Si el mismo hablara y sus expresiones no coincidiesen con las que nosotros hubi茅semos realizado, tal vez esta simbiosis podr铆a perderse.

Personalmente no creo que esto sea as铆, no creo que el hecho de no hablar y parecer autista mejore la relaci贸n del jugador con su avatar sino todo lo contrario. Tal vez, en estos casos, s铆 ser铆a bueno evitar personalidades histri贸nicas pero por Dios, al menos deber铆a contestar la cosas que le pregunten.

Gordon Freeman es quiz谩s el personaje m谩s popular que fue creado con este concepto. 隆Que distinto podr铆a haber sido el Half-Life si Gordon fuera un tipo normal! Existen incluso bromas al respecto. Nuevamente, no creo que nadie se identifique m谩s con Gordon s贸lo por el hecho que 茅l no hable.

Ustedes que piensan 驴Les parece correcto que el personaje principal de un juego no hable en absoluto? 驴Se identifican m谩s con 茅l de este modo?

Compartir:
  • Twitter
  • Facebook
  • MySpace
  • BarraPunto
  • del.icio.us

Next Page »