Entradas de la categoría ‘Desarrollo’

De toda la vida de Dios se ha dicho, en el mundo de la informática, que cuando un error de software está lo suficientemente documentado, se transforma automáticamente en una característica. Esto ha pasado siempre en el plano del desarrollo computacional y seguirá sucediendo, porque los programadores son seres humanos que, por un lado, cometerán errores, y por otro, nunca estarán dispuestos a admitirlos como tales.

En el desarrollo de videojuegos a veces un error ha sido aprovechado por el programador para implementar una característica antes de lanzar un título al mercado y, otras veces, el juego ha salido a la venta con un fallo no detectado que, posteriormente, se ha convertido en una peculiaridad propia muchas veces aprovechada en versiones posteriores.

Vamos a repasar rápidamente los ejemplos más señalados y reconocidos de este tipo de bugs que fueron, más que bugs, glitches aprovechados por diseñadores y usuarios. Existen muchos, pero sólo nos vamos a centrar en los tres más importantes y globales (según nuestro humilde entender).

El primer caso fue el pionero en esto de aprovechar errores y, además, inventó por casualidad un nuevo concepto para el mundo videojueguil. Nos referimos a ‘Space Invaders‘, el juego matamarcianos de toda la vida desarrollado en 1978 por Toshihiro Nishikado para la compañía Taito. Cualquiera que haya jugado a este arcade que, sospecho, serán muchos de los lectores, podrá recordar que una pantalla repletita de invasores espaciales (que se desplazaban a izquierda y derecha y hacia abajo) amanezaba de muerte a nuestro cañón defensor y, por ende, a la humanidad.

La velocidad de descenso en el ataque de aquellos marcianitos era progresiva según íbamos deshaciéndonos de ellos, esto es, al principio iban muy lento y, cuando quedaban menos, la velocidad aumentaba; convirtiéndose en endiablada cuando únicamente quedaba un marciano. Esta velocidad in crescendo no era una característica programada, sino un error de programación, o en realidad, más que un error, una escasez de hardware.

Toshihiro Nishikado diseñó prácticamente el arcade completo, software y hardware. Las limitaciones de la época en cuanto a memoria RAM y procesador hacían que los marcianos descendieran muy lentamente cuando se contaban por decenas, pues el sistema estaba saturado. Según matábamos bichos, la memoria y el micro se liberaban y eran capaces de mover a los marcianitos de manera más veloz.

Es curioso, pero esta limitación de hardware originó y estableció un concepto básico del mundo del videojuego: la curva de dificultad ascendente. Hasta el momento, todos los juegos existentes contaban con el mismo grado de dificultad de manera lineal y plana a lo largo de los niveles. Con ‘Space Invaders’ se inventó algo que ha afectado a la industria del videojuego en su totalidad y de manera universal, algo que ahora nos resulta tan evidente como que un videojuego sea muy fácil al principio y, según vamos avanzando, se vaya haciendo cada vez más difícil.

Seguimos. Al igual que hoy en día parece inconcebible encontrar un juego cuya dificultad no sea progresiva, es igualmente impensable hallar un título de lucha en el que no se puedan realizar combos. Pues bien, los combos nacieron como un error de programación en ‘Street Fighter II‘ (Capcom, 1991), el segundo de la saga de videojuegos del género de lucha que, probablemente, sentó las bases principales para lo que hoy representan los títulos de repartir hostias a diestro y siniestro (sin pasar por alto, claro está, ‘Yie Ar Kung-Fu‘ [Konami, 1985], quizás el primero primerísimo en marcar un hito en el género y en sus controles).

Dicen las malas lenguas que Noritaka Funamizu, el productor de ‘Street Fighter II’, se percató del error disfrutando de la fase de bonus del juego en la que se nos invita a destrozar un coche a mamporrazos. Aquel bug permitía enlazar dos golpes de manera rapidísima y consecutiva (combinaciones) como parte de una única secuencia de movimientos, algo que, en principio, no debería estar permitido: la premisa era golpe-reposo-golpe.

Funamizu comprobó que aquello podía ser una característica muy ventajosa en el combate, pero no de manera tan consistente para que fuera abusiva con el oponente, pues era imposible encadenar combos infinitos. Por ello, no comentó absolutamente nada a los programadores y, cuando el juego llegó a la calle, los usuarios enseguida comenzaron a conocer y a utilizar los diferentes combos.

Tal fue el éxito de esta innovadora mecánica que los combos fueron añadidos, ya como una característica oficial, en versiones posteriores del título, incluyendo además el típico contador que indicaba cuántos golpes seguidos encadenabas y otorgaba puntos extra por ello. Hoy en día, es prácticamente absurdo encontrar un videojuego competitivo de peleas que no tenga combos incorporados.

Cambiamos de tercio y nos acercamos a los juegos del tipo FPS para descubrir diversos bugs en algunos de ellos que han llevado a generar características parecidas en todos en un movimiento muy particular: el salto.

La verdad es que programar los movimientos de un personaje dentro de un juego no es una tarea sencilla. Hay que tener en cuenta el entorno, la inteligencia artificial de los enemigos, la detección de colisiones, los diversos mapas y ciento cincuenta mil millones de variables más. Con el paso del tiempo, los videojuegos cada vez se desarrollan y se depuran mejor, pero hace años era muy común encontrar numerosos errores en los títulos de ocio digital.

Tanto ‘Doom‘/’Quake‘ (id Software, 1993/id Software, 1996) como ‘Half-Life‘ (Valve, 1998) como ‘Counter Strike‘ (Valve, 1999) , entre otros FPS, han contenido errores de programación que han facilitado los diversos saltos dentro del desarrollo del juego. Es lo que en el argot se denomina trickjumps, técnicas que se utilizan para mejorar la movilidad del jugador al saltar y que, casi siempre, no han sido previstos por el creador del juego.

En el motor de ‘Doom’/’Quake’ apareció un error que permitía incrementar la velocidad del jugador por medio de saltos encadenados. El modo de ejecutar este truco, explotando así el error en nuestro favor, era por medio de una combinación específica de movimientos de ratón y entradas de teclado. Es lo que se dio en llamar el strafe-jumping, y que continuó posteriormente como una característica en casi todos los juegos de la compañía (y en otros ajenos).

Por su parte, el conocido como rocket-jumping es una técnica que consiste en disparar un lanzacohetes, u otra arma explosiva similar, contra el suelo mientras se salta al mismo tiempo. El salto, el impulso del disparo y la física programada en el juego para que salgamos despedidos ante una explosión resulta en un cóctel que genera un bug que nos hace saltar como canguros mutantes endemoniados. El rocket-jumping surgió por un error en ‘Half-Life’ (aunque también en otros juegos) y hoy es prácticamente imprescindible en algunos títulos de disparos en primera persona.

También, el crouch-jumping, surgido de un bug en ‘Counter Strike’, permitía a los jugadores realizar saltos inverosímiles por medio de un truco que consistía, básicamente, en saltar y pulsar al tiempo el botón de agacharse, muy rápidamente. Es una característica que Valve, en cuyos motores se origina este error, nunca concibió, pero que hoy en día aún sigue presente en sus juegos.

Existen muchísimos más, pero la mayoría son errores que se han explotado únicamente en los propios juegos o en versiones posteriores de las distintas sagas. Los que aquí hemos desgranado son tres ejemplos sobresalientes de tres glitches que, partiendo de videojuegos particulares, han escalado en fama y han llegado a convertirse en características típicas del desarrollo general de juegos digitales. Todo un honor para ellos.

Y no es una cosa moderna, es un algo ya viejuno pero, ahora, muy mejorado. ‘SmileBASIC‘ es una aplicación exclusiva para Nintendo 3DS que permite programar software en lenguaje BASIC dentro de esta consola nintendera y de sus primas más directas (3DS XL, 2DS, New 3DS y New 3DS XL). Desciende directamente del antiguo ‘Petit Computer‘ para DSi, pero ‘SmileBASIC’ promete ser más potente, versátil y sencillo de manejar.

‘SmileBASIC’ es obra y fruto de la compañía japonesa SmileBoom, una empresa dedicada al desarrollo de software en, sobre todo, el campo de las consolas de videojuegos. Sus programadores tienen en su haber un montonazo de aplicaciones y juegos de todo tipo y, en este momento, creen necesario ofrecernos la herramienta perfecta para que seamos nosotros mismos los que nos lancemos al desarrollo de títulos lúdicos para la consolita de Nintendo.

Y todo esto es una primicia que podremos ver en vivo y en directo en el Tokyo Game Show 2014 (que comienza mañana), pero de la que no podremos disfrutar aquí hasta primavera del año que viene. Como siempre, debemos ser precavidos y dudar un poquito de lo que nos prometen, que es, ni más ni menos, que la más sencilla plataforma de programación para desarrollo de juegos 3D, única en el mundo. Bueno, pues ya lo veremos.

El lenguaje SmileBASIC está fundamentado en el propio lenguaje BASIC, por lo que va a ser muy sencillo de aprender. Eso sí, habremos de acostumbrarnos a sus peculiaridades en cuanto a la sintaxis, así como también a su particular objetivo final, la Nintendo 3DS, y sus características propias: micrófono, sensor giroscópico, acelerómetro, pantalla 3D, etcétera. Por ello, para hacernos la vida más sencilla, ‘SmileBASIC’ viene con diversos materiales incorporados con el fin de reducir el tiempo y el trabajo necesario a la hora de programar. Trae, por ejemplo, más de 2.000 elementos de galería integrados para utilizarlos en los diseños de sprites de un personaje o como fondos. También elementos para mapas y, sobre todo, una herramienta de diseño integrada a la que han llamado SmileTool, algo que ayudará a crear nuestro propio arte en forma de píxel desde cero y, asimismo, a editar cualquiera de los incorporados en función de nuestras necesidades.

En el campo del sonido, encontraremos más de 100 audios profesionales para dar efectos espectaculares a nuestros juegos o sonorizarlos de fondo, pero también la posibilidad de componer nuestra propia canción haciendo uso del sencillo lenguaje Music Macro Language, o MML.

Manuales de instrucciones, tutoriales de ayuda, juegos de ejemplo, comunidades en línea, compartición de material, copiaypega de código, publicaciones en la nube y un larguísimo etcétera, harán de esta herramienta una opción más que probable para que los iniciados comiencen a programar videojuegos y, también, para que los más expertos se adentren en el mundo de la 3DS y comprueben todas sus capacidades.

Por desgranar muy someramente las características más técnicas, podemos comprobar que ‘SmileBASIC’ va a permitir programas de hasta 1.000.000 de líneas de código, con edición de 4 programas al mismo tiempo, soporte de todos los sensores y métodos de entrada de la 3DS (botones, pads, pantalla táctil…), 6 páginas de memoria gráfica, diversas resoluciones, profundidad 3D en el eje Z desde -256 hasta 1.024, todo tipo de sonidos o formatos de la máquina y diversos juegos de caracteres UNICODE, entre otras muchas cosas.

Con respecto al lenguaje de programación, por comentar lo más significativo, vemos que disponemos de uso de variables y palabras reservadas, conversión implícita de tipos de datos, matrices de hasta cuatro dimensiones, múltiples sentencias separadas por dos puntos (:), subrutinas sin límite, manejo de archivos de texto y binarios, operadores aritméticos, operadores relacionales, lógicos, de orden y a nivel de bit.

En fin, una herramienta muy elaborada y con bastante buena pinta para todo aquel que se anime a zambullirse en el mundo del desarrollo de videojuegos (o aplicaciones) para Nintendo 3DS. Eso sí, y como decíamos antes, en otoño de este año vera la luz en Japón, y nosotros deberemos esperar hasta la primavera del año 2015 para disfrutar de él. Por cierto, sólo disponible desde Nintendo eShop para 3DS.

Le estaremos esperando con ansias.

Tras el gran éxito de sus estrenos anteriores, Algoritmos de ordenamiento y Algoritmos de redondeo, teknoPLOF! vuelve al ataque con su tercera entrega Algoritmos de búsqueda básicos para torpes (<- este último metavínculo es recursivo en sí mismo; miedito).

Los programadores informáticos son muy cuadriculados y todo lo tienen que hacer siguiendo unas pautas prefijadas perfectamente determinadas y secuenciadas. Paso 1, paso 2 y paso 3; y fin del asunto. Como suelen utilizar enormes cantidades de datos (yo que sé, como inmensas listas de personas con sus teléfonos, por ejemplo), se les hace necesario poder buscar un elemento en concreto dentro de un grupo de ellos. Y eso, a veces, no es tan sencillo.

Hoy en día existen métodos de búsqueda propios y muy optimizados en los lenguajes de programación más modernos y, también, en los propios gestores de datos. Sin embargo, no viene mal conocer los algoritmos de búsqueda más básicos del mundo mundial por si se nos presenta esa ocasión eventual en la que tenemos cosas que ordenar y no disponemos de herramientas a nuestra disposición.

Y, además, lo vamos a hacer de una manera tan insultantemente sencilla que resulta hasta ofensiva. Pero bueno, allá vamos.

Búsqueda secuencial (lineal)

Es tan fácil como recorrer, secuencialmente, toda la lista de elementos en la que queremos buscar uno en concreto (llamado clave) desde el principio hasta el final. Si lo encontramos, ¡estupendo!, si no lo encontramos es que no está. Tan sencillo como eso.

La búsqueda secuencial se utiliza para listas o matrices de datos que están desordenadas, que no siguen un orden en concreto, como un listado de alumnos de un colegio, por ejemplo, que no está ordenado alfabéticamente.

Dado que, como decimos, el conjunto no tiene un orden prefijado, es probable que el elemento que estamos buscando se encuentre en primera posición, que esté el último o que ande por el medio de la lista (¡o que no esté!). Por ello, este tipo de búsqueda puede ser mu rpdilla o hacerse eteeeeeeeeerna, en función del número de elementos en el grupo. Funciona correctamente en listas cortitas y es muy sencillo de implementar.

Búsqueda binaria (dicotómica)

El algoritmo de búsqueda binaria es mucho más eficaz que el de búsqueda secuencial, pero eso sí, necesita que la lista de datos esté ordenada; por ejemplo, un índice de pueblos organizados numéricamente, de menor a mayor, por su código postal.

Los pasos que se deben seguir son muy sencillos. Se empieza a buscar el dato que necesitamos encontrar por el elemento de en medio de la lista, el del centro. Si no es el que buscamos, comprobamos qué relación tiene con él, es decir, si es mayor o menor. Si es menor, por ejemplo, acotamos la búsqueda a la primera mitad de la lista. Y repetimos: cogemos el elemento central y lo comparamos con el que estamos buscado; si no es, volvemos a acotar la búsqueda en función de si el que buscamos es mayor o menor que el nuevo central.

Un ejemplo facilón para que quede claro. Dada la siguiente lista de valores numéricos ordenados:

2 23 35 38 47 56 57 76 83 85 90 92 95 98 99

Quiero saber si el número 56 se encuentra en la lista. Leo el valor central de la lista: 76. ¿Es el que busco? No. ¿Es mayor o menor que el que busco? Mayor. Por lo tanto me quedo con una lista más pequeña, la que va de 2 a 57. Leo, otra vez, en valor central: 38. ¿Es el que busco? No. ¿Es mayor o menor que el que busco? Menor. Entonces, mi nueva lista para comparar es de 47 a 57. Vuelvo a leer el valor central: 56. ¿Es el que busco? Sí. Finiquitado en tres comparaciones.

En el caso de que, en algún momento, alguna de las listas tenga un número par de elementos, no pasa nada, los programadores son tan listos que ellos se encargan de realizar labores de redondeo a la hora de averiguar la parte media de una relación.

Búsqueda por interpolación

Este último tipo de búsqueda es un poco más puñetero. En principio es muy parecido al anterior, pues es un algoritmo recursivo (se repite continuamente hasta que da con el valor buscado) y también acota las listas en secciones más pequeñas. La diferencia con la búsqueda binaria es que, en lugar de cortar las listas todo el rato por la mitad, éstas se delimitan siempre por medio de los valores resultantes de una interpolación matemática. Más clarito: si durante la búsqueda encontramos un valor que está muy cerca del número clave que buscamos, parece más razonable continuar buscando en esa área, en lugar de cortar y buscar el número central otra vez.

En matemáticas, se denomina interpolación a la obtención de nuevos valores partiendo del conocimiento de un conjunto de otros valores. Fijémonos de nuevo en la lista anterior. Tras la primera comparación apuntando al centro, la nueva lista que nos quedaba iba de 2 a 57. El número que andaba buscando era el 56, que está terriblemente cerquita del final de mi lista; tan cerquita, tan cerquita que casi se tocan. La lógica me dice que voy a andar mejor empezando a buscar por el final que tirando al centro y comparando de nuevo.

Los programadores utilizan esas interpolaciones matemáticas, codificadas en código fuente de un lenguaje de programación, para determinar por dónde andan los valores más cercanos y afinar la búsqueda.

Y hemos llegado al final. Existen otros algoritmos de búsqueda, pero estos son los más simples y los más utilizados. Y no vamos a escribir ni una sola línea de código porque nos hemos prometido hacerlo fácil de entender. Los informáticos que deseen codificar estas explicaciones, no creo yo que tengan ningún problema en hacerlo rápidamente; es extremadamente sencillo.

Se acabó.

Podemos conectar casi cualquier cosa a una red informática: bombillas, termostatos, cafeteras e incluso tejones. Sí, tejones.

Los tejones, esos pequeños mamíferos de cabeza blanquinegra, pasan mucho tiempo bajo tierra, en sus profundas madrigueras, lo que hace difícil para los biólogos y para los zoólogos rastrear su paradero y monitorizar sus actividades. El sistema GPS, por ejemplo, no funciona bien debajo del suelo o en áreas cerradas.

Sin embargo, hace unos cinco años, los investigadores Andrew Markham y Niki Trigoni de la Universidad de Oxford, resolvieron este problema mediante la invención de un sistema de seguimiento inalámbrico que puede trabajar debajo de la tierra.

Este sistema es inteligente, pero no lo hicieron ellos solos. Al igual que muchos otros científicos, miraron de frente hacia el código abierto (open source) para evitar tener que construir desde la nada los componentes fundamentales. Uno de los bloques que utilizaron para diseñar su dispositivo fue un sistema operativo de código abierto llamado Contiki.

Contiki no es tan conocido como Windows, Linux o Mac OS, pero, desde hace más de una década, ha sido el sistema de referencia para hackers, académicos y empresas de dispositivos conectados a la red, como sensores, secuenciadores o sistemas de automatización basados en web. A los desarrolladores les encanta porque es ligero, muy maduro y, por supuesto, gratuito. Además, proporciona una base para programadores y emprendedores deseosos de traernos todos los aparatos conectados a la Red de redes, como el «Internet de las cosas» promete y sin tener que desarrollar un sistema operativo subyacente para esos gadgets en cuestión.

Quizás lo mejor que Contiki tiene a su favor es que es una distribución pequeña; realmente muy pequeña. Mientras que Linux, por ejemplo, requiere de un megabyte de RAM, Contiki necesita sólo unos pocos kilobytes para correr. Su inventor, Adam Dunkels, ha sabido lograr un sistema operativo completo que incluye una interfaz gráfica de usuario, software de red y un navegador web corriendo en menos de 30 kas de memoria. Eso hace que sea mucho más fácil de ejecutar en chips pequeños y de baja potencia (precisamente el tipo de necesidades que se requiere para los diminutos dispositivos conectados), pero también ha sido portado a diversos sistemas antiguos, como Apple II o Commodore 64.

Contiki pronto se va a enfrentar a competencias de la talla de Microsoft, que recientemente anunció su nuevo Windows orientado al Internet de las cosas. Y aunque el nuevo sistema operativo de Microsoft sea gratuito para los dispositivos de menos de 9 pulgadas (que así parece que será), no va a ser de código abierto, por lo que Contiki le lleva una ventaja ya de 11 años.

El proyecto de Contiki OS se inició en 2003, pero sus raíces se extienden a los días de Dunkels como estudiante de informática en la Universidad de Mälardalen, en Suecia. En el año 2000, Dunkels trabajaba en un proyecto para utilizar sensores inalámbricos con el objeto de rastrear los signos vitales de los jugadores de Hockey y mostrarlos en pantalla para que la multitud pudiera verlos. «Les convencimos a los deportistas para llevar todo el rato esa cosa en su nariz con el fin de que nosotros pudiéramos medir su respiración», recuerda Dunkels.

Para hacer que todos aquellos sensores funcionaran correctamente, Dunkels tuvo que escribir el software que les permitiera interactuar con una red informática. Denominó a aquel código resultante LwIP (que viene de pila Lightweight TCP/IP) y, aunque LwIP se sigue utilizando en muchos microcontroladores y otros productos actuales, Dunkels decidió que no era lo bastante ligero. En 2003, creó microIP y, posteriormente, Contiki. El sistema operativo fue un éxito inmediato entre los investigadores y aficionados, y en los últimos años ha atraído a muchos usuarios comerciales con propuestas interesantes, como los instrumentos de detección de radiación Rad DX o los sistemas de monitorización del entorno Zolertia.

Para ayudar a apoyar el creciente uso comercial de Contiki, Dunkels dejó su trabajo como profesor en el Instituto Sueco de Ciencias de la Computación y fundó Thingsquare, una empresa enfocada a proveer un back-end basado en la nube para dispositivos Contiki. La idea es hacer más fácil para los desarrolladores conectar sus dispositivos de hardware con los teléfonos inteligentes e Internet. Thingsquare administra los servidores y proporciona todo el software necesario para gestionar un dispositivo a través de la Red.

Contiki está diseñado, pues, para sistemas embebidos con escasa memoria. Cuenta con un núcleo orientado a eventos sobre el cual los programas pueden ser cargados y descargados de forma dinámica en tiempo de ejecución. Tiene un subsistema GUI opcional, con soporte de gráficos para terminales locales y para terminales virtuales en red mediante VNC o sobre Telnet. Incluye una pila ligera TCP/IP y una pila Rime, que está diseñada especialmente para comunicaciones inalámbricas de baja potencia, y cuenta con un amplio rango de primitivas de comunicación. También soporta IPv6, junto con protocolos como RPL4 y 6LoWPAN.

Es muy probable que Contiki sea el futuro de los sistemas operativos para el Internet de las cosas. Le echaremos un vistazo y lo seguiremos bien de cerca.

Utilizando el conjunto de herramientas cliente-servidor que proporciona Visual Studio Team Foundation Server 2013, podemos aplicar prácticas lo suficientemente demostradas para gestionar el ciclo de vida de una aplicación.

En el siguiente vídeo podemos visualizar una sesión de prueba que muestra cómo planificar proyectos; desarrollar, construir y probar una aplicación; cómo realizar el seguimiento de trabajo y el informe de progreso mediante el control de versiones; y el sistema y las herramientas de planificación ágil proporcionadas por el propio software.

A través del famoso blog The Register se están retransmitiendo un montón de sesiones online grabadas en la QA’s Tech Week, en abril de este 2014. Pásate y echa un vistazo, porque son todas muy interesantes (no hace falta registrarse para ver los vídeos).