Guia de Produccion 1 0

ANEXO PRCTICO
Anexo Prctico para la Gua de Produccin Versin: 1.0

Fernando Sansberro
Contenido Seccin 1 Introduccin y Proceso de Produccin

Captulo 1 - Introduccin................................................................................................... 6 1.1 Sobre la Gua ............................................................................................................. 6 1.2 Pblico Objetivo ......................................................................................................... 6 1.3 Contenido de la Gua ................................................................................................. 7 1.4 Sobre el Desarrollo de Videojuegos ........................................................................... 7 1.5 Sobre la Industria de Videojuegos .............................................................................. 8 1.6 Sobre el Autor............................................................................................................. 9 Captulo 2 - Proceso de Produccin .............................................................................. 10 2.1 Ciclo del Desarrollo .................................................................................................. 10 2.2 Pre-produccin ......................................................................................................... 11 2.3 Documento de Concepto .......................................................................................... 12 2.4 Prototipo ................................................................................................................... 12 2.5 Anlisis de Riesgos .................................................................................................. 13 2.6 Cronograma ............................................................................................................. 13 2.7 Etapas de Produccin .............................................................................................. 13 2.7.1 Concept Document y Cronograma .................................................................... 14 2.7.2 Prototipo ............................................................................................................ 14 2.7.3 Alpha .................................................................................................................. 14 2.7.4 Beta ................................................................................................................... 14 2.7.5 Gold ................................................................................................................... 15 2.8 Entregables .............................................................................................................. 15 2.9 Herramientas de Produccin .................................................................................... 15
Seccin 2 Desarrollo de Actividades y Videojuegos

Captulo 3 - La Computadora XO .................................................................................... 16 3.1 OLPC y la Computadora XO .................................................................................... 16 3.2 Hardware .................................................................................................................. 16 3.2.1 La Computadora XO-1.0 .................................................................................... 16 3.2.2 Display ............................................................................................................... 17 _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 2 de 73 Centro Ceibal Uruguay
3.2.3 Audio .................................................................................................................. 21 3.2.4 Cmara .............................................................................................................. 21 3.2.5 Red .................................................................................................................... 22 3.2.6 Dispositivos de Entrada ..................................................................................... 22 3.2.6.1 Teclado ........................................................................................................ 22 3.2.6.2 Gamepad ..................................................................................................... 23 3.2.6.3 Touchpad ..................................................................................................... 23 3.2.6.4 Otras Entradas ............................................................................................. 24 3.3 Software ................................................................................................................... 24 3.3.1 Sistema Operativo ............................................................................................. 24 3.3.2 Interfaz Grfica .................................................................................................. 24 3.3.3 Las Actividades .................................................................................................. 26 3.3.4 El Diario ............................................................................................................. 26 3.3.5 El Navegador y las Aplicaciones Web................................................................ 26 Captulo 4 - Desarrollo de Actividades y Juegos .......................................................... 28 4.1 Actividades y Aplicaciones Web ............................................................................... 28 4.2 Lenguajes de Programacin .................................................................................... 29 4.2.1 Python y Pygame ............................................................................................... 29 4.2.2. C++ y SDL ........................................................................................................ 30 4.2.3 Ventajas y Desventajas de Python y C++ .......................................................... 31 4.2.4 Otros Lenguajes ................................................................................................ 32 4.2.4.1 Flash ............................................................................................................ 32 4.2.4.2 HTML5 ......................................................................................................... 33 4.2.4.3 Java ............................................................................................................. 33 4.3 Desarrollo en Python ................................................................................................ 34 4.4 Desarrollo en C++ .................................................................................................... 34 4.5 Sobre el uso de Emuladores .................................................................................... 35 4.6 Sobre el Desarrollo de Videojuegos ......................................................................... 35 4.6.1 Game Loop ........................................................................................................ 36 4.6.2 Mquina de Estados (FSM) ............................................................................... 37 4.7 Bibliotecas y Engines para Juegos........................................................................... 37 4.7.1 PGU Python Game Utilities............................................................................. 38 _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 3 de 73 Centro Ceibal Uruguay
4.7.2 Box2D y PyBox2D ............................................................................................. 38 4.7.3 Boost C++ .......................................................................................................... 38 4.8 Entornos de Desarrollos ........................................................................................... 38 Captulo 5 - Limitaciones de la Computadora XO y Optimizaciones........................... 39 5.1 Sobre el Display ....................................................................................................... 39 5.2 Sobre Audio y Video ................................................................................................. 40 5.3 Optimizacin de Memoria ......................................................................................... 40 5.4 Optimizacin de Espacio .......................................................................................... 41 5.5 Optimizaciones de Velocidad de Ejecucin .............................................................. 41 5.6 Uso de los Lenguajes ............................................................................................... 42 5.7 Redibujado de la Pantalla (Dirty Rectangles) ........................................................... 42 5.8 Overlays (Escalado por Hardware) .......................................................................... 43 5.9 Otras Optimizaciones ............................................................................................... 44
Seccin 3 Testing y Distribucin de Actividades

Captulo 6 - Normas de Usabilidad y Testing ................................................................ 45 6.1 Audiencia.................................................................................................................. 45 6.2 Fundamentos de Diseo .......................................................................................... 46 6.2.1 Interfaz Universal ............................................................................................... 46 6.2.2 Interfaz Intuitiva ................................................................................................. 46 6.2.3 Simpleza ............................................................................................................ 46 6.3 Gua de Estilo del Plan Ceibal .................................................................................. 47 6.4 Testing ...................................................................................................................... 48 6.5 Normas de Usabilidad y Testing ............................................................................... 48 6.5.1 Barra de Carga .................................................................................................. 48 6.5.2 Frames por Segundo (FPS) ............................................................................... 49 6.5.3 Tiempos de respuesta ....................................................................................... 49 6.5.4 Uso del Gamepad .............................................................................................. 49 6.5.5 Legibilidad de los Textos .................................................................................... 50 6.5.6 Ortografa y Gramtica ...................................................................................... 50 6.5.7 Contenido Apropiado ......................................................................................... 50 6.5.8 Libre de Errores ................................................................................................. 51 _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 4 de 73 Centro Ceibal Uruguay
6.5.9 Seguridad .......................................................................................................... 51 6.5.10 Adaptabilidad ................................................................................................... 51 6.5.11 Salvado ............................................................................................................ 52 6.5.12 Pausa .............................................................................................................. 52 6.5.13 Accesibilidad .................................................................................................... 53 6.5.14 Integracin con el Diario .................................................................................. 53 6.5.15 Compatibilidad con Rainbow ........................................................................... 53 6.5.16 Comportamiento y Funcionalidades de la Actividad ........................................ 53 6.5.17 Audio................................................................................................................ 54 6.5.18 Archivo de Distribucin .................................................................................... 54 6.5.19 Navegabilidad .................................................................................................. 55 6.5.20 Logos ............................................................................................................... 56 6.6 Plan de Testing ......................................................................................................... 57 Apndice A - Cmo se Construye una Actividad .......................................................... 60 A.1 Armado de la Actividad ............................................................................................ 60 A.2 Icono de la Actividad ................................................................................................ 61 A.3 Instalacin de Actividades ........................................................................................ 61 Apendice B - Desbloqueo de las XO y Flasheo............................................................. 62 B.1 Desbloqueo de la XO ............................................................................................... 62 B.2 Flasheo de la XO ..................................................................................................... 62 Apndice C - Distribucin de Actividades ..................................................................... 64 C.1 Distribucin .............................................................................................................. 64 C.1.1 Sitio Web ........................................................................................................... 64 C.1.2 Portal Ceibal...................................................................................................... 64 C.1.3 Repositorio de actividades de Sugar Labs ........................................................ 64 C.1.4 Actualizacin de XO .......................................................................................... 65 C.2 Dispositivo de almacenamiento ............................................................................... 65 C.3 Datos auxiliares ....................................................................................................... 65 Referencias ...................................................................................................................... 66 _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 5 de 73 Centro Ceibal Uruguay
Captulo 1 - Introduccin
1.1 Sobre la Gua El presente trabajo es indicado para desarrolladores de cualquier clase de contenidos para las computadoras XO, pero pone nfasis en el desarrollo de actividades educativas y videojuegos. La gua presenta las caractersticas particulares de las computadoras XO, muestra las alternativas de desarrollo existentes para las mismas, analizando pros y contras de cada una, y enumera un conjunto de tcnicas y prcticas requeridas para el desarrollo de un producto que corra adecuadamente en estas computadoras. Durante el desarrollo de esta gua se trat de no profundizar demasiado en cada tema para que ste trabajo tenga una funcin de gua introductoria en cada tema. De esta forma se hace posible la consulta rpida de cada tema y en cada uno se listan referencias bibliogrficas o sitios de Internet donde se pueden profundizar los conocimientos. El objetivo de esta gua es que sirva como punto de partida para el desarrollo de contenidos para la plataforma XO. En esta gua se utiliza mucho la palabra videojuegos. Se debe leer esta palabra como sinnimo de juegos propiamente dicho o actividades educativas con un uso intensivo de grficos y animaciones. Se ha elegido usar la palabra videojuegos para no usar siempre la frase videojuegos o aplicaciones educativas que hagan uso intensivo de grficos y animaciones. Por ejemplo, en el contexto de la discusin sobre performance siempre se utilizar la palabra videojuegos. Cabe aclarar que esta gua es para producir actividades educativas y videojuegos con los estndares de calidad comercial. Pero es posible que alguien quiera realizar una actividad muy simple que tenga fines educativos para uso en clase, que se quiera realizar rpidamente y/o que no requiera uso intensivo de grficos o animaciones, para lo cual en ese caso no es necesario seguir muchas de las normas aqu indicadas. 1.2 Pblico Objetivo El pblico objetivo de esta gua son por un lado los programadores que teniendo conocimientos de programacin, ven a la computadora XO como otra plataforma en la cual desarrollar y son los que van a trabajar durante el desarrollo, y por otro lado los gerentes, diseadores, etc. de empresas de informtica y/o audiovisuales que necesiten conocer sobre las caractersticas del desarrollo para la plataforma XO de forma tal de _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 6 de 73 Centro Ceibal Uruguay
poder tomar decisiones con ms informacin a su alcance. Por lo expuesto anteriormente, se ha tratado de utilizar un lenguaje ms informal, menos tcnico, tratando de evitar asumir conocimientos en la medida de lo posible. Cabe aclarar tambin que en algunos temas avanzados no es posible lograr esto, pero la idea de la gua es tratar todos los puntos como una introduccin, dando enlaces y referencias bibliogrficas en cada tema que sirvan como puntos de partida para que el lector pueda continuar la investigacin. De hecho, uno de los aspectos ms importantes de este trabajo son las referencias que se brindan en cada tema que funcionan como la punta de la madeja para continuar la investigacin en cada tema en particular.
1.3 Contenido de la Gua La gua se divide en tres secciones. La primera seccin brinda una introduccin al desarrollo de actividades y videojuegos para las computadoras XO. La segunda seccin habla sobre el hardware y software de la computadora y explica que lenguajes de programacin conviene utilizar en cada caso y da informacin de cmo optimizar los proyectos para que corran adecuadamente en las computadoras XO. La tercera seccin habla sobre las normas de usabilidad que hay que tener en cuenta al desarrollar actividades y explica cmo realizar el testing para asegurar la calidad del producto final. Por ltimo se presentan apndices de ndole tcnica sobre mantenimiento de la computadora XO, armado de una actividad, etc.
1.4 Sobre el Desarrollo de Videojuegos Desarrollar videojuegos es una de las tareas de programacin mas complejas que hay. Naturalmente que es muy sencillo programar un videojuego muy simple, pero lograr un videojuego de calidad aceptable es un trabajo muy arduo y se requieren conocimientos especficos que no se suelen ensear en la educacin formal. Es necesario tener en cuenta esto de modo de no subestimar el desarrollo de videojuegos, tanto en el tiempo que lleva como en los conocimientos requeridos y sobre todo, en los aspectos de produccin y trabajo con un equipo multidisciplinario. Uno de los puntos claves a la hora de evitar fracasos es el de tener una verdadera idea del tiempo y esfuerzo que lleva desarrollar un videojuego. Si nunca se hizo un videojuego, lo mejor es hacer un prototipo o una prueba cualquiera para lograr adquirir esa idea. Proponerse un juego simple y luego desarrollarlo es el mejor ejercicio para comenzar a adquirir una idea de realidad. Por supuesto que es posible que una empresa que nunca hizo videojuegos comience a desarrollar videojuegos (hablando de empresas tradicionales de informtica o _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 7 de 73 Centro Ceibal Uruguay
audiovisuales), pero es necesario tener en cuenta lo dicho anteriormente para poder cumplir con los plazos y poder alcanzar los requerimientos propuestos. ste es un punto crtico. El libro Fundamentals of Game Development [28] brinda una excelente introduccin a la produccin de videojuegos y a la industria, explicando el funcionamiento de la misma, los roles claves y las tareas involucradas en dicha actividad, etc.
1.5 Sobre la Industria de Videojuegos Las principales referencias para comenzar a investigar sobre el tema de videojuegos y sobre la industria son los siguientes: Gamasutra [74] es un sitio web hermano de la revista Game Developer, que contiene noticias y artculos sobre todos los aspectos del desarrollo profesional de videojuegos, tanto tcnicos como de negocios. IGDA (International Game Developers Association) [73] es la asociacin internacional de desarrolladores de videojuegos. De particular inters son los SIG (Special Interest Groups) que desarrollan investigacin sobre cada rea de los videojuegos. Estos grupos publican cada cierto tiempo papers que describen el estado del arte. Sobre la industria local (Uruguay) y regional, los principales grupos, organizaciones y empresas relacionadas al desarrollo de videojuegos o software educativo y audiovisual, son las siguientes: Proanima [70] es el Cluster de Empresas de Animacin y Videojuegos de Uruguay, y es el lugar indicado para tomar contacto con la industria local. El foro Uruguay Gamer [75] es la comunidad de desarrolladores de videojuegos de Uruguay. Ceibal Jam [76] es un movimiento de afiliacin abierta y voluntaria, con integrantes pertenecientes a un amplio espectro de edades, formaciones y actividades laborales, que comparten el compromiso con el futuro de la nacin y por ello aportan tiempo y conocimientos para desarrollar software libre didctico que funcione sobre la plataforma que utilizan las computadoras del Plan Ceibal. En particular, relacionado a los videojuegos, en varias oportunidades se ha tratado el tema, como por ejemplo en [78]. La lista de correo de Ceibal Jam es un buen lugar para conocer novedades, solucionar problemas tcnicos, hablar sobre el Plan Ceibal, etc. [81]. ADVA [71] es la Asociacin de Desarrolladores de Videojuegos Argentina, una comunidad de desarrollo de videojuegos de Argentina, la cual se encuentra bastante desarrollada. ABRAGAMES [72] es la Associao Brasileira das Desenvolvedoras de Jogos Eletrnicos. Las listas de desarrollo de la comunidad OLPC [79] y Sugar [80] renen a todo tipo _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 8 de 73 Centro Ceibal Uruguay
de gente vinculada a Plan Ceibal, Sugar y OLPC. Hay muchas ms listas que pueden resultar interesantes en [82] y [83].
1.6 Sobre el Autor Fernando Sansberro es Director de Batovi Games Studio (www.batovi.com), un estudio de desarrollo de videojuegos ubicado en Montevideo, Uruguay, que desarrolla juegos para diferentes plataformas como celulares, web y advergaming, juegos casuales para PC, Mac y Linux. Batovi Games ha desarrollado juegos para portales y publishers como AOL, Cartoon Network, Nickelodeon, Big Fish Games, GlobalFun, etc. Fernando ha trabajado tambin como docente enseando programacin de videojuegos web en Flash y programacin de videojuegos Java para celulares en Universidad ORT Uruguay. Muchos de los conceptos volcados en esta gua se recogen de las experiencias adquiridas durante el desarrollo de juegos que Batovi Games Studio ha realizado para la plataforma XO, entre los cuales se encuentran Super Vampire Ninja Zero, Vascolet: La Mquina del Tiempo, Xa contra los Cuatreros Galcticos, Garra Ftbol, etc.
_____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 9 de 73 Centro Ceibal Uruguay
Captulo 2 - Proceso de Produccin

En este captulo se presenta una introduccin al proceso de produccin y desarrollo de videojuegos. Se asume que el desarrollador conoce y utiliza buenas prcticas de ingeniera de software, control de calidad (QA), etc., lo cual impacta directamente en la calidad del producto final. Se brindan referencias bibliogrficas especializadas para profundizar en cada tema.
2.1 Ciclo del Desarrollo El proceso de desarrollo comienza la con definicin inicial del concepto del videojuego y termina con la publicacin de la versin final del mismo (denominada gold master). Este proceso es variable de proyecto a proyecto y esta es una de las razones por la cual la produccin de videojuegos puede ser difcil y desafiante el gerenciamiento (ejemplos tpicos de cosas que pueden variar el proceso de desarrollo entre un proyecto y otro es el uso de una propiedad intelectual, el uso de una tecnologa determinada, si el gameplay no est probado, etc). Mas all de los parmetros del proyecto, tales como el tamao del equipo, presupuesto, tiempo, complejidad del juego, etc. existe una base de proceso de produccin que es comn a todos los proyectos. El proceso puede dividirse en las siguientes etapas: preproduccin, produccin, testing y post-produccin. En cada una de estas etapas hay que lograr alcanzar ciertos objetivos para pasar a la siguiente etapa y la concrecin de cada etapa en forma adecuada impacta directamente sobre el resultado final. 1. Pre-produccin: Prototipo. Documento de Concepto. Requerimientos del Proyecto. Plan de Proyecto y Cronograma. Anlisis de Riesgos. 2. Produccin: Avances de progreso. Evaluacin de riesgos. Plan de Implementacin. Documento de Diseo. 3. Testing: Liberacin de assets. Plan de Testing.
4. Post-produccin: Postmortem. Publicacin. El esquema anterior muestra las etapas del ciclo de produccin del proyecto y muestra como cada etapa se construye sobre lo que ya hay realizado. Como se puede ver es sumamente importante la pre-produccin del proyecto porque en esta etapa se crean las bases para todo el desarrollo. Un proyecto en el cual no se especifique bien el concepto o alcance del proyecto es uno que posiblemente encuentre problemas no previstos que afecten su normal desarrollo. Estas etapas se suelen seguir en orden y es una simplificacin de la realidad. Para otros proyectos se puede adoptar otra forma. Si por ejemplo vamos a hacer un juego en el cual no est probada la idea (o la mecnica o el gameplay) es necesario crear lo antes posible una prueba de concepto (un prototipo: generalmente es un nivel jugable para probar que el juego es divertido). Para esto entonces dividimos el ciclo de produccin en varios subciclos, en el cual cada uno contiene las etapas de pre-produccin, produccin y testing [28]. En la industria de videojuegos la metodologa de desarrollo utilizada actualmente es Scrum [27] o alguna variacin de las metodologas giles.
2.2 Pre-produccin La pre-produccin es la primera etapa en el ciclo de produccin del proyecto y es crtico para definir las caractersticas del proyecto o cmo ser el juego, definir cunta gente se va a necesitar y cunto tiempo de desarrollo se requiere, el costo estimado del proyecto, etc. La etapa de pre-produccin puede llevar desde una semana a ms de un ao dependiendo de cuanto tiempo se disponga para terminar el proyecto. Se estima que la pre-produccin requiere del 10% al 25% del tiempo total del proyecto. De esta forma, si trabajamos en un proyecto de seis meses, la pre-produccin suele tomar desde una semana a un mes. El objetivo de la etapa de pre-produccin es el crear un plan de produccin, el cual es un mapa de ruta para lograr terminar el proyecto en tiempo y forma. El plan incluye la creacin del documento de concepto, determinar riesgos y amenazas que afectan el concepto, la creacin del documento tcnico, el costo, el equipo que va a participar y el cronograma.
2.3 Documento de Concepto Muchos proyectos comienzan con una idea vaga y el equipo debe trabajar para bajar a tierra el concepto y llevarlo a algo tangible y que pueda funcionar. Se plasman las ideas principales en un documento de concepto en el cual se explican las funcionalidades bsicas del juego o actividad de forma tal que todo el equipo pueda entender de que se trata el proyecto y cuales son los principales elementos de gameplay que se encuentran en el juego. Luego de que se tiene en concepto bsico inicial, el siguiente paso es agregar los elementos de gameplay bsicos. Se escriben las principales ideas sobre la mecnica del juego, los controles, el gnero, la historia, los personajes, etc. En este punto se deben identificar las caractersticas nicas que hacen que el juego se destaque de la competencia y tenga su lugar en el mercado. Las caractersticas que tiene un juego (denominadas features) generalmente se establecen en sesiones de brainstorming (lluvia de ideas) en las cuales cada caracterstica se clasifica como debe estar, quisiera que est y estara bueno que est. Luego se discuten las ideas y el resultado es que se logra una lista final del conjunto de features que se implementarn en el juego. Se debe evaluar cada idea si es implementable en forma sencilla o es muy complicada. Esto ayuda en la estimacin de tiempo y esfuerzo para luego implementarlas. Mientras se va definiendo el conjunto de features que tendr el juego, se investiga que tecnologa funciona mejor para el juego propuesto. Esto incluye estudiar las limitaciones en el hardware, explorar soluciones de middleware o bibliotecas a utilizar, o evaluar el uso de determinada tecnologa. Ademas, se debe tener en cuenta que herramientas van a ser necesarias para crear los assets (grficos, audio, etc) del juego y la mejor manera de establecer la forma de trabajo (production pipeline). A medida que estos elementos son ms definidos, el equipo debe crear un documento tcnico y un documento de diseo para comunicar las decisiones tomadas. Luego de escrito, los roles claves en el equipo deben revisar los documentos y aprobarlos. Los documentos suelen ser aprobados por el gerente del estudio y el publisher (quien comercializa el producto final y se encarga de ventas y marketing, a veces tambin es quien financia el desarrollo).
2.4 Prototipo Si el juego tiene una mecnica o gameplay que no se encuentra probado, lo mejor es realizar un prototipo que ayuda a definir la experiencia del juego. Un prototipo es una versin del juego que se construye rpidamente, que muestra generalmente un nivel del juego y con l se puede probar a ver si la idea original funciona o no.
El prototipo dependiendo del tipo de juego, puede ser realizado en papel, en Flash, etc. y a medida que las ideas avanzan y se hacen fuertes, el prototipo se hace cada vez ms jugable. Es importante construir un prototipo pulido, que refleje lo mejor posible la experiencia de gameplay final a lograr. Si la idea no funciona, se descarta el prototipo y se cancela el proyecto sin gastar mucho dinero. Si la idea funciona y se consigue un gameplay divertido y se prueba la idea, se continua el proyecto.
2.5 Anlisis de Riesgos A medida que se definen y se detallan los conceptos mencionados anteriormente, se realiza un anlisis de riesgos para determinar los riesgos ms grande que tiene el proyecto. En este momento existirn varios factores desconocidos, por lo cual ser difcil determinar riesgos especficos. Sin embargo, si algunos factores constantes son definidos con anterioridad, como por ejemplo el tamao del equipo de desarrollo y la tecnologa a utilizar, pueden ser utilizados para hacer un anlisis bsico de riesgos. Si no se toma el tiempo para realizar un anlisis de riesgo, es muy probable encontrarse despus con problemas en el proyecto que podran haberse minimizado si se hubieran identificado como riesgos al principio. Ayuda enormemente en el anlisis de riesgos y a evitar futuros problemas la experiencia que tiene el equipo de desarrollo. Especficamente en videojuegos, es imprescindible la experiencia previa, dado que los videojuegos son proyectos riesgosos por naturaleza.
2.6 Cronograma Luego que el conjunto de caractersticas (features) del proyecto est definido y ya se sabe que se pueden realizar, se definen las fechas de entrega para cada etapa (milestones) y se define que se va a realizar en cada una de ellas. Algunos proyectos se definen en un cronograma con etapas mensuales y otros proyectos en etapas prototipo, alpha, beta y gold master. Cualquier cronograma puede servir con tal de que las versiones entregables (deliverables) estn claramente definidas y conocidas por todos los involucrados en el proyecto. Se denomina deliverable a los elementos en el juego como assets de arte, cdigo, audio, etc. que demuestra el avance en el gameplay y el arte (look and feel) del juego.
2.7 Etapas de Produccin El ciclo correspondiente a la etapa de produccin suele incluir las etapas de concepto, prototipo, alpha, beta y la entrega final. Cuando se desarrolle un proyecto en el marco de _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 13 de 73 Centro Ceibal Uruguay
Plan Ceibal (por ejemplo durante la realizacin de ideas docentes a cargo de una empresa o desarrollos del Proyecto Rayuela [113]), stas sern las etapas que se utilizarn en los proyectos. Las mencionadas etapas corresponden a los entregables (deliverables) que se deben presentar para aprobacin por parte de Plan Ceibal /Rayuela.
2.7.1 Concept Document y Cronograma El documento de concepto indica cmo va a ser el juego (caractersticas, publico objetivo, bocetos que den una idea de cmo se vera el juego, cmo se vera el arte final, la historia preliminar, etc). Es muy variable como se presenta, incluso puede ser informal, pero lo importante es que viendo este documento, los involucrados se pueden hacer una idea de cmo sera realmente el juego.
2.7.2 Prototipo Esta es la primera versin jugable. Generalmente esta versin consiste de un nivel jugable, muchos grficos son temporales (placeholders) y faltan cosas que no hacen al gameplay como el men, ayudas, audio, etc. Lo ms importante para mostrar en esta versin es que ya hay una idea de cmo va a ser el ncleo del juego (la mecnica principal).
2.7.3 Alpha Es la primera versin del juego que tiene todas las partes funcionando aunque le falten bandas musicales o efectos de sonido, los niveles no estn balanceados (balancear es ajustar la dificultad gradualmente), muchos grficos no son los definitivos (todava existen placeholders), etc. La versin alpha se suele utilizar para hacer un focus group interno para ver que todo est bien, que se entienda el juego y ver que se puede mejorar. Este focus group puede introducir cambios a nivel de diseo, por lo cual es mejor realizarlo lo antes posible en el ciclo de desarrollo.
2.7.4 Beta Es una versin casi final del juego, solo faltan cosas auxiliares como puede ser el men principal, msicas, algunos grficos, etc. Esta versin es para focus group nuevamente (en este caso el focus group ya nos dara detalles sobre si la dificultad es la correcta o no, o cosas puntuales fciles de balancear), pero tambin se utiliza la versin beta para relizar testing en busca de errores (buscar bugs durante el beta testing).
2.7.5 Gold La versin gold o gold master es la versin final a la cual ya se le corrigieron todos los bugs reportados y todos los assets son finales. Es la versin que est pronta para distribucin (publicacin).
2.8 Entregables Cada proyecto debe entregar los siguientes archivos entregables (deliverables). - Archivos ejecutables. - Documentacin tcnica del proyecto. - Plan de Testing aprobado. - Material solicitado de Marketing. - Cdigo fuente y assets si corresponde (depende de la propiedad intelectual). - Hoja de requerimientos de hardware y software. - Manual del usuario.
2.9 Herramientas de Produccin Se recomienda durante el desarrollo el uso de algn sistema de versionado como Subversion [56] o Tortoise SVN [57] por ejemplo. De esta forma varios programadores y artistas pueden trabajar en diferentes archivos del proyecto, teniendo control sobre los cambios realizados. Una de las grandes ventajas de utilizar un sistema de versionado es que es posible trabajar en equipo y desde varios lugares de trabajo. Cuando se actualizan las versiones del proyecto, solamente se descargan los Durante la etapa de testing es necesario utilizar algn sistema de bugtracking (registro de errores). De esta forma, es posible asignar tareas de solucin de problemas, priorizarlos, marcados como solucionados, etc. Durante el proceso de testing cualquiera de los testers que vea un problema, lo reporta en el sistema y luego el gerente de proyecto prioriza los mismos y los asigna para su revisin y solucin. Hay muchos sistemas de bugtracking, uno de los utilizado comunmente es Mantis [58].
Captulo 3 - La Computadora XO
3.1 OLPC y la Computadora XO La computadora XO 1.0 es la laptop utilizada en el Plan Ceibal en Uruguay [1]. La computadora XO es diseada por OLPC (One Laptop Per Child) [2] y al ser diseada para nios, es una computadora con caractersticas particulares. Por este motivo, durante el desarrollo de una actividad o videojuego, no debe nunca asumirse que las cosas son de la misma manera o funcionan como en otros entornos. La nica forma de asegurarse que algo funciona correctamente es probando en la misma computadora XO. Por diferentes razones, la computadora XO tiene una capacidad de procesamiento y almacenamiento limitada en comparacin con las computadoras actuales en el mercado y al desarrollar software se debe tener en cuenta estas limitaciones. Durante el desarrollo de actividades es de suma importancia probar la misma en la XO porque va a correr bastante ms lento que en la computadora de escritorio utilizada para desarrollar. Hay muchos aspectos de performance a tener en cuenta durante el desarrollo que se describirn en esta gua. En general, el sitio Wiki de OLPC [3] contiene mucha informacin sobre el software, el hardware y sobre el programa OLPC en s mismo y es una excelente fuente de informacin para consultar. En [4] se pueden ver las principales razones filosficas detrs del diseo de la computadora XO (bajo consumo, software libre, la forma de la mquina, etc.)
3.2 Hardware Las especificaciones completas del hardware de la computadora XO-1.0 y de la computadora XO-1.5 se encuentran en [6] y [7] respectivamente. A continuacin se describe el hardware que es relevante para el desarrollo de actividades. En [88] se pueden ver las especificaciones de las computadoras actuales y tener una idea de lo que se podra venir en futuras versiones de las computadoras.
3.2.1 La Computadora XO-1.0 Las caractersticas ms relevantes de la computadora XO-1.0 son las siguientes: Procesador: AMD Geode LX700 CPU (433 Mhz.) con GPU (Graphics Processing Unit) integrada. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 16 de 73 Centro Ceibal Uruguay
Memoria: 256 Mb. DDR SDRAM. Almacenamiento: 1Gb. de memoria SLC NAND flash on board. Los datos son accedidos al dispositivo NAND a 30 Mb. por segundo. La computadora no cuenta con disco duro ni con partes mviles para disminuir el riesgo de roturas. Display: Pantalla de cristal lquido (TFT-LCD) de 7.5 pulgadas en diagonal (19.05 cm.) con modo dual: modo color (transmissive, full-color mode) y modo blanco y negro de muy bajo consumo (reflective, high-resolution mode) que puede usarse bajo la luz del sol. Resolucin: 1200 x 900 (200 dpi). Tamao: 15,2 cm. x 11,4 cm.; 6 x 4,5 pulgadas. Soporta una resolucin de color de aproximadamente 6 bits por color (262k de colores). Audio: Subsistema de audio AC'97. Ms adelante se describen en mayor profundidad algunos de estos elementos y las caractersticas que hay que tener en cuenta cuando se desarrolla una actividad para lograr una performance adecuada.
3.2.2 Display La pantalla de la computadora XO es una de las caractersticas propias de esta plataforma. La pantalla es de una resolucin muy grande porque est pensada para que sea fcil la lectura en ella, incluso a la luz del sol. En [5] se puede profundizar en el funcionamiento del display, porque no es sencillo el mismo. En esta seccin se hace un resumen de las caractersticas que ms nos interesan como desarrolladores y se explica porqu el tamao del display es el punto ms critico en lo que se refiere a la performance de los videojuegos. En el modo monocromo se soporta un display de 1200 x 900 pxels (200 dpi), donde cada pxel representa 64 posibles tonos de gris. En el modo color se soporta un display de 693 x 520 ternas de color, aunque la percepcin de resolucin es mas alta dependiendo del nivel de luz del ambiente [5]. Un test realizado en una habitacin luminosa indica que se percibe una resolucin de 1024 x 768 [6]. Cada componente de la terna da 64 niveles de brillo.
Fig. 1: Un pxel refleja la luz ambiente y tambin transmite luz de backlight.
Fig. 2: Vista de la pantalla al microscopio.
Fig. 3: Esquema diagonal de los pxels.
Fig. 4: Funcionamiento del Display en modo Blanco y Negro.
Fig. 5: Funcionamiento del Display en modo Color. Para pasar a modo monocromo se pulsa repetidamente la tecla para bajar el brillo hasta llegar al mnimo, o se expone el display al sol. Para pasar a modo color se incrementa el brillo hasta que se encienda la luz trasera (backlight).
Fig. 6: Teclas de control de brillo. La computadora XO no cuenta con una placa aceleradora de video. Esta falta, sumada a que la resolucin de pantalla es enorme (1200x900) es el aspecto mas crtico a tener en cuenta durante el desarrollo de videojuegos o cualquier actividad que haga uno intensivo de grficos. Peor an sera en el caso de querer hacer un juego 3D, en el cual todo el render es implementado por software (en los juegos de PC actuales o consolas de videojuegos, el render lo realiza la tarjeta grfica que soporta aceleracin por hardware y es mucho mas rpido). Lamentablemente no es posible por programacin setear otro modo de video con una resolucin ms baja como se hace en los PC, por ejemplo 320x240, 640x480, 800x600. Por este motivo no hay ms remedio que trabajar a 1200x900 (salvo la excepcin de utilizar overlays que se explica ms adelante).
Se pueden ver ms detalles sobre las caractersticas y profundizar en el funcionamiento del display en [5]. En esta referencia se brinda una detallada explicacin del funcionamiento del display en lo que se refiere a la luz de backlight y a la luz reflejada y cmo funcionan en conjunto de acuerdo a las condiciones de luminosidad del ambiente. Otro componente que vale la pena mencionar es DCON (Display Controller), el cual es el controlador de video secundario que permite que la XO funcione con bajo consumo de energa alternando entre los modos como se explic anteriormente. DCON se encuentra en el pipeline de video entre el controlador de video primario (integrado en el procesador) y el LCD. En [30] se puede profundizar en su especificacin.
3.2.3 Audio La computadora XO cuenta con audio estreo, con dos parlantes y micrfono interno y entrada para auriculares o parlantes externos y para micrfono. La frecuencia de los parlantes internos va aproximadamente desde 480 Hz. a 40 kHz. El sistema de audio est basado en el estndar Audio Codec '97 de Intel. Este codec soporta sampleos de entrada y salida de hasta 96 kHz. a 20 bits de resolucin y sampleos de 48 kHz a 20 bits de resolucin para grabacin y reproduccin multicanal, usando un conversores analgico/digital con un rango dinmico de 80 dB y conversores digital/analgico con un rango dinmico de ms de 90 dB. El codec AC'97 incluye un nmero de canales de entrada y salida que no son soportados en CL1 (la computadora XO 1.0). Estos canales son deshabilitados por el firmware para conservar energa. El codec entero se apaga cuando no hay audio de entrada o salida. Se puede profundizar leyendo la especificacin de AC'97 en [31]. Hay que tener en cuenta en el desarrollo, que los sonidos y msica con graves producen vibraciones en el parlante externo de la computadora que los hacen molestos. Hay que probar en la computadora el audio a utilizar.
3.2.4 Cmara La computadora tiene una cmara integrada (Omnivision OV7670) con una resolucin de 640x480 pxels y puede funcionar hasta 30 FPS (frames por segundo). Tanto la cmara como el piloto soportan la desactivacin del AGC (Automatic Gain Control) y balance automtico de color, permitiendo su utilizacin como un sensor fotomtrico para aplicaciones educativas. En [8] se pueden ver las especificaciones de la cmara.
3.2.5 Red La computadora XO hasta hace poco creaba una red denominada malla (mesh network) pero ahora la nueva imagen (F11) utiliza una red ad hoc. Se ha comprobado que la mesh (red malla) genera trfico innecesario que perjudica a los usuarios de la red Ceibal. Para optimizar el trfico de la red Ceibal, se deshabilit la red malla. La nueva imagen (F11) incorpora la funcionalidad de redes ad hoc, que permite conectarse con otros usuarios sin depender de una infraestructura de red inalmbrica. Los nios pueden trabajar, jugar y aprender en colaboracin, sin requerir de un punto de acceso inalmbrico. El chip controlador de red inalmbrica es un Marvell Libertas 88W8388+88W8015 [32]. La interfaz de red inalmbrica utilizada por la XO es una WiFi convencional 802.11 b/g (2.4 Ghz.). La computadora posee antenas dobles coaxiales ajustables y giratorias. La idea de la red malla (que ya no se encuentra en las XO) era la siguiente: En la red malla cada mquina funciona como un router inalmbrico full-time que le brinda conexin a las mquinas a su alcance. La idea detrs de esta red es que an en zonas remotas, las computadoras estn conectadas entre s y con la Internet. De esta forma, al contrario del funcionamiento tradicional de las redes inalmbricas en las cuales las mquinas se comunican con un punto de acceso en la red, las XO utilizaban la red malla, en la cual las computadoras pueden pasar los paquetes para otras computadoras, extendiendo el alcance de la red. Para lograr el funcionamiento de la red malla, la interfaz de red de la computadora est diseada para operar con poca energa como un nodo en la malla, incluso si la computadora se encuentra apagada.
3.2.6 Dispositivos de Entrada Los dispositivos de entrada de la computadora XO son el teclado, el touchpad y los cuatro botones de direccin a la derecha de la pantalla (gamepad) junto con los cuatro botones de accin (game keys) a la izquierda de la pantalla, un botn para rotar el display y el botn de apagado y encendido.
3.2.6.1 Teclado
El teclado de membrana consta de 72 teclas de goma, sellado contra el ingreso de agua y polvo.
Fig. 7: Imagen del Teclado. Hay que tener en cuenta en el diseo de videojuegos de no requerir un uso intensivo de determinadas teclas, dentro de lo posible (por ejemplo, en la accin de disparar, que no se tenga que apretar repetidamente la tecla de disparo, sino que se pulse una vez y se disparen varias balas). El motivo de esto es que no es un teclado apto para el uso intensivo en que se le da en videojuegos y hay que cuidarlo.
3.2.6.2 Gamepad La computadora puede girar el display y cerrarse para operarse en el modo denominado eBook. En este modo solamente quedan disponible los botones direccionales y los de acciones de juego que se encuentran a cada lado de la pantalla (de esta forma el teclado y el touchpad no se pueden acceder). De esta manera la computadora puede utilizare ms cmodamente para leer libros o jugar como si se tratara de una consola de videojuegos porttil. En la parte izquierda de la pantalla se encuentran las teclas direccionales y en la parte derecha de la pantalla las teclas de accin, las cuales se identifican con iconos distintivos (cuadrado, crculo, check y equis).
3.2.6.3 Touchpad La computadora XO tiene un touchpad usado para mover el puntero del mouse, junto con dos teclas para click derecho e izquierdo. El touchpad tiene una resolucin de 1000 dpi y un rea activa de 6.0 cm. por 4.4 cm.
Es posible colocar un mouse externo a travs de uno de los tres conectores USB.
3.2.6.4 Otras Entradas La computadora tiene tres entradas para dispositivos USB 2.0 un slot SD. El micrfono incluye un modo de sensor de entrada, en el cual los nios pueden enchufar sensores que pueden convertir la mquina, por ejemplo, en termmetros u osciloscopios.
3.3 Software A continuacin se describe el software instalado en las computadoras que es relevante para el desarrollo de actividades. Si nunca se ha manejado la computadora XO, se recomienda leer el manual bsico de uso de la XO [68]. En el sitio reduca Wiki [97] se listan muchas de las actividades disponibles para la computadora XO, algunas desarrolladas por OLPC y otras por docentes o programadores.
3.3.1 Sistema Operativo La computadora XO que distribuye Ceibal tiene instalado Fedora, una distribucin del sistema operativo Linux. La versin de la XO durante 2010 fue Fedora 9 Linux Kernel 2.6.25. En 2011 se libera la imagen F11: Fedora 11, Kernel 2.6.31. Es importante mencionar que si bien la filosofa detrs de Linux es software libre, la computadora XO del Plan Ceibal posee restricciones de seguridad para hacer ms sencilla la logstica de mantenimiento. Por esta razn Centro Ceibal (organismo encargado de la instalacin, distribucin y mantenimiento de las computadoras en Uruguay, ubicado en el parque del LATU [33]) instala las computadoras sin permisos de usuario administrador (denominado root). De esta forma, el usuario final no puede realizar cambios a nivel de software en el sistema operativo. Hay que tener en cuenta esta restriccin a la hora de desarrollar una actividad que requiera de la instalacin de libreras o elementos necesarios no incluidos en la distribucin y que requieran de permisos de administrador para ser instalados.
3.3.2 Interfaz Grfica La Interfaz Grfica de Usuario (GUI) utilizada en la computadora XO se denomina Sugar. Es una interfaz pensada para el uso de los nios y es diferente a otras interfaces _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 24 de 73 Centro Ceibal Uruguay
(Windows, Mac, etc.). El entorno Sugar est desarrollado en el lenguaje de programacin Python (ms adelante se describe este lenguaje de programacin).
Fig. 8: Imagen del Entorno Sugar. En el documento Human Interface Guidelines [9] de Sugar Labs se pueden ver las razones filosficas detrs del diseo de la interfaz grfica Sugar (por ejemplo la colaboracin, la metfora de objeto en lugar de archivo, la metfora del diario (journal) en lugar de sistema de archivos, etc.) El sitio Wiki de Sugar Labs [34] es una comunidad en la cual los desarrolladores comparten conocimientos y proyectos para soportar Sugar como plataforma. Al desarrollar actividades que corran bajo el entorno Sugar, es preferible que estas cumplan con los principios de diseo de usabilidad de Sugar. Los mismos pueden leerse en [9]. Este documento es sumamente importante para entender el funcionamiento de Sugar y porqu algunas cosas son de la manera que son. El documento describe en detalle las partes de la interfaz grfica que se relacionan directamente con el desarrollo de software y la forma en que las aplicaciones (que se denominan Actividades) interactan con el sistema operativo. En el caso de los videojuegos puede ser diferente. Los videojuegos como tienen su propia interfaz grfica acorde al tema del juego (por un tema de inmersividad), generalmente corren en modo fullscreen y no interactan demasiado con la interfaz grfica del sistema operativo, no tienen la obligacin de adherirse a los estndares del sistema operativo y/o entorno grfico. Las principales caractersticas de la interfaz Sugar son las Actividades, los objetos, el diario (journal) y la red malla (mesh). En la imagen F11 la red malla se desactiva, incorporando la funcionalidad de redes ad hoc.
3.3.3 Las Actividades En el entorno Sugar, las aplicaciones se denominan Actividades. Como en cualquier otro entorno, las actividades tienen una funcionalidad comn a todas (la barra de actividad, acciones como por ejemplo compartirla, etc). Las actividades son diferentes a las aplicaciones de otros entornos en cuanto a su foco (colaboracin y expresin) y su implementacin (journal y la iteracin) [9]. En el Apndice A se describe cmo se construye una actividad.
3.3.4 El Diario El Diario (Journal) es una caracterstica propia del entorno Sugar y es donde se van registrando todas las actividades que se realizan con la computadora. De esta forma, es como un cuaderno en el cual se puede ver el trabajo realizado y continuar con alguno que se encuentre pendiente. Se ha elegido la metfora del Diario como sustituto al sistema de archivos (el sistema de archivos por debajo es el de Linux, pero en Sugar se utiliza la metfora del Diario). Cuando se desarrolla una actividad educativa que es colaborativa, el diario toma un papel fundamental y el desarrollador debe pensar en profundidad cmo la actividad se integra con el diario. Se utiliza el diario tambin para poder acceder a los medios de almacenamiento externo (pendrives y tarjetas SD) y se utiliza el diario para eliminar archivos. Por este motivo es que se asocia el diario con el sistema de archivos.
3.3.5 El Navegador y las Aplicaciones Web El navegador de la computadora XO es la actividad Navegar (Browse), la cual utiliza el motor Gecko y el lenguaje de programacin Javascript [36], al igual que lo hace el navegador Firefox. La actividad Navegar es bastante ms simple que Firefox y la restriccin ms importante es que no soporta todos los complementos (plugins o add-ons) que soporta Firefox. Al igual que cuando se desarrolla una actividad nativa, cuando se desarrolla una actividad o aplicacin Web, debe probarse en diferentes navegadores, pero cuando sta es destinada al uso en las XO, no debe asumirse que algo funciona hasta no comprobarse en la misma computadora XO. Con la actividad Navegar se puede hacer lo siguiente: Navegar pginas web. Mostrar varios formatos de imagen, como PNG, SVG o JPEG. Se puede encontrar _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 26 de 73 Centro Ceibal Uruguay
ms informacin sobre formatos en [37]. Descargar actividades online (al acceder a archivos con extensin .xo la actividad se descarga automticamente y se instala, crendose el icono en el escritorio). El archivo .xo (denominado bundle) se descarga en el Diario. Correr algunos plug-ins como el Flash Player (hay que tener recaudo porque corre muy lento comparado contra otras computadoras). Ejecutar cdigo Javascript. La actividad Navegar escala las pginas aproximadamente un 40% para que se vean a un tamao legible (no usa la resolucin 1200x900). Por este motivo, es necesario probar el diseo de la pgina en la XO. Se recomienda disear para un tamao de 800x600. En [85] se encuentra la especificacin completa de las funcionalidades y componentes de la actividad Navegar (Browse).
Captulo 4 - Desarrollo de Actividades y Juegos

En este captulo se describen las caractersticas de las actividades y los posibles lenguajes a ser utilizados al crear actividades y juegos para la computadora XO. Se brindan pros y contras de cada uno y los elementos a tener en cuenta a la hora de elegir un lenguaje para desarrollar la actividad. Al comparar lenguajes para su uso, hay que tomar en cuenta las preferencias de cada uno, las realidades de la empresa y la industria, lo que se desea desarrollar, etc. Casi siempre estas discusiones de elegir entre uno u otro lenguaje son religiosas, pero la realidad es que es mejor poder usarlos a todos ya que uno puede ser mejor que otro en determinada situacin. La regla de oro es aceptar que no existe el lenguaje perfecto ni nunca va a existir. Mucha gente se pasa buscando el lenguaje perfecto y no se enfoca en lo mas importante que es hacer el desarrollo en s. Los lenguajes son solamente herramientas. Las variables para la eleccin de un lenguaje son la performance (Ej: C++ es ms eficiente que Python), la sencillez de uso (un lenguaje interpretado suele ser ms sencillo de utilizar que uno compilado), la disponibilidad de programadores en el mercado (suelen haber ms programadores de lenguajes de script que de C++), el costo (por ejemplo Flash tiene licencia mientras que C++ o Python no), etc. En [26] se encuentra el sitio de desarrollo del Plan Ceibal, en el cual se pueden acceder a diferentes documentos relacionados al desarrollo de actividades, incluyndose esta gua. En el sitio [96] hay compilados muchos enlaces a actividades, eventos y documentacin relacionada con el desarrollo para las computadoras XO y OLPC.
4.1 Actividades y Aplicaciones Web Como en toda computadora, es posible ejecutar programas de varias formas. Cada una tiene sus pros y sus contras y muchas veces hasta definen el lenguaje de programacin que debemos utilizar, por supuesto, segn que se vaya a realizar. El software a ser utilizado en la computadora XO puede clasificarse segn su lugar de almacenamiento: 1. Local: El software se instala en el equipo y luego es ejecutado localmente. Ejemplo de esto son las actividades que se instalan en la computadora y luego son ejecutadas localmente. 2. Web: El software es accedido a travs de la conexin de red inalmbrica accediendo a un sitio web. Ejemplo de esto son las aplicaciones web que se acceden utilizando el _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 28 de 73 Centro Ceibal Uruguay
navegador. Una actividad es bsicamente un archivo con extensin .xo (es un archivo con formato de compresin zip) que al accederlo (va el navegador, o pendrive, por ejemplo) la computadora lo instala y coloca el icono en la pantalla principal del entorno grfico para que quede disponible. En el Apndice A se describe la estructura de una actividad.
4.2 Lenguajes de Programacin Existen varios lenguajes de programacin que se pueden utilizar para desarrollar software para la computadora XO y cada uno tiene sus pros y sus contras que se analizarn ms adelante. Nunca una discusin de que lenguaje utilizar se debe centrar sobre cul lenguaje es mejor en s mismo, sino en cul lenguaje es mejor para realizar determinado proyecto. Para desarrollar software para la computadora XO se recomienda utilizar Python [13] y/o C++ [38]. El entorno Sugar se encuentra desarrollado en lenguaje Python as como la mayora de las actividades instaladas en la computadora XO, por lo cual lo hace el lenguaje natural para desarrollar actividades. Sin embargo, hay que tener en cuenta que como Python es un lenguaje interpretado, es ms lento que un lenguaje compilado como C++. C++ es el lenguaje recomendado para la programacin de videojuegos ya que es el lenguaje con el cual se obtiene la mayor performance posible y es el lenguaje estndar en la industria de videojuegos, adems de que existe mucha bibliografa al respecto. Es posible utilizar otros lenguajes segn el caso para realizar actividades ms sencillas o web (descartando por supuesto a los videojuegos en su concepcin tradicional): Flash, HTML5, Java, etc. pero no es aconsejable su uso debido a que hay que trabajar alrededor de bastantes problemas de performance, instalacin de plugins, etc. A continuacin se describen las principales ventajas y desventajas de cada uno.
4.2.1 Python y Pygame Python [13] es un lenguaje de programacin de alto nivel cuya filosofa se basa en tener una sintaxis limpia y el favorecer la legibilidad del cdigo. El uso de Python para desarrollar una actividad es recomendado debido a que el entorno Sugar est desarrollado en Python al igual que la mayora de las actividades instaladas en la XO. Hay que mencionar que el cdigo fuente de las actividades se encuentra disponible, por lo cual existe una gran base de cdigo que se puede reutilizar. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 29 de 73 Centro Ceibal Uruguay
Para realizar videojuegos, Python utiliza Pygame [14], que es una biblioteca para entre otras cosas, el manejo de grficos para videojuegos. Pygame es un wrapper de SDL para Python (ver la siguiente seccin que habla sobre SDL). Estas bibliotecas (Pygame y SDL) ya se encuentran instaladas en la computadora XO. En el sitio oficial del lenguaje de programacin Python [13] se puede descargar el software necesario, acceder a la documentacin del lenguaje, etc. En el sitio web de la biblioteca Pygame [14] se puede acceder a la documentacin de la biblioteca, a tutoriales sobre programacin de videojuegos, a cdigo fuente de videojuegos ya realizados, etc. Las empresas de la rama Audiovisual que tienen tendencia al uso de Flash deberan optar por Python que es un lenguaje de script al igual que ActionScript. Las empresas de la rama informtica que suelen tener programadores de mayor nivel podran usar cualquiera de los dos, Python o C++, dependiendo de sus objetivos. Es ms sencillo encontrar en el mercado programadores de script que programadores C++ y tambin el lenguaje de script tiene una barrera de entrada mucho mas baja que C++. El mejor juego de Pygame que el autor de esta gua ha encontrado que funcione bien en las computadoras XO (fullscreen) es Micro War 2.0 [77]. Su autor, Piere-Alain Dorange tambin escribi otro juego denominado PyFrogger, y ambos utilizan un engine para videojuegos que se denomina Fgame. Viendo el cdigo fuente de esos juegos se pueden aprender muchas cosas de Pygame. En algunos encuentros de Ceibal Jam se ha tratado el tema y se ha realizado un primer programa en Pygame [78]. En [14] hay una lista de juegos Pygame con cdigo fuente para probar y aprender, en [93] se brinda una introduccin a Pygame en la computadora XO y la librera OLPC Games [94] permite que un juego desarrollado en Pygame corra dentro de una actividad Sugar. La librera da acceso a varias caractersticas especiales del ambiente Sugar, como la red malla (recordar que no se utiliza ms en la imagen F11) y la cmara. En el sitio [95] se puede obtener informacin de los requisitos de OLPC para el desarrollo de actividades.
4.2.2. C++ y SDL C++ [38] es el lenguaje de programacin ms utilizado para el desarrollo de software de base y videojuegos por la eficiencia del cdigo generado por el compilador. C++ es un lenguaje de ms bajo nivel que Python, lo cual tiene ventajas en cuanto a la performance pero desventajas en cuanto a la productividad. Ms adelante se describen los pros y contras de los lenguajes. C++ es el lenguaje ms eficiente para desarrollar videojuegos para la computadora XO. Utilizando C++ se puede alcanzar una muy buena performance en las actividades. Para desarrollar videojuegos o actividades que hagan uso intensivo de grficos se utiliza la _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 30 de 73 Centro Ceibal Uruguay
bliblioteca grfica SDL (Simple DirectMedia Library) [15]. Esta biblioteca se encuentra instalada en la computadora XO, dado que es un requisito para el correcto funcionamiento de Pygame, el cual es un wrapper de SDL para Python. La biblioteca SDL es de uso comn en la industria de videojuegos, por lo cual existe mucho know how accesible en Internet. Una de las ventajas de esta librera es que es multiplataforma y ha sido portada a XO. Con C++ se utiliza directamente la librera SDL por lo cual es mas eficiente que usando Python con Pygame, sumado a que C++ no es un lenguaje interpretado, sino compilado. En el sitio oficial de SDL [15] se pueden acceder a tutoriales de programacin de videojuegos, a la documentacin de SDL, a cdigo fuente de juegos realizados, etc.
4.2.3 Ventajas y Desventajas de Python y C++ Siendo Python y C++ los lenguajes recomendados para desarrollar actividades y videojuegos para las computadoras XO, hay que tener en cuenta en la eleccin entre uno de estos dos lenguajes las siguientes ventajas y desventajas de cada uno. Python Ventajas: Es el lenguaje utilizado en el entorno grfico Sugar y en la mayora de sus actividades, por lo cual lo hace el lenguaje natural de la computadora XO. Facilita el intercambio con otros miembros de la comunidad de desarrolladores Sugar-OLPC ya que es el lenguaje ms difundido para los desarrollos en Sugar. Es ms sencillo el desarrollo ya que es un lenguaje de script. Esto permite desarrollar en un entorno con un intrprete interactivo, lo que facilita experimentar con caractersticas del lenguaje o probar funciones durante el desarrollo del programa. No requiere proceso de compilacin. Es multiparadigma, por lo que permite varios estilos de programacin: orientada a objetos, estructurada o funcional. Se pueden escribir nuevos mdulos fcilmente en C o C++. Hay ms programadores Python en el mercado que lo que hay, por ejemplo, programadores C++. El lenguaje tiene una barrera de entrada ms accesible. Desventajas: Es menos performante que C++ debido a que es un lenguaje interpretado. Para cierto tipo de videojuegos que requieran mucha performance puede no ser adecuado el uso de Python. Si no se codifica prolijamente se podra dificultar la lectura del cdigo o introducir errores indeseados. Puede llevar mucho tiempo encontrar determinado tipo de _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 31 de 73 Centro Ceibal Uruguay
errores, caractersticos de los lenguajes de script. En [18] se pueden ver las actividades Sugar realizadas con Python. C/C++ Ventajas: Es mucho mas performante que Python, debido a que es un lenguaje compilado. El compilador del lenguaje atrapa una gran cantidad de errores de sintaxis y operaciones sin sentido que evitan que se traduzcan a problemas de lgica que luego son ms difciles de encontrar. Es multiparadigma, permite programacin orientada a objetos y estructurada. Se puede utilizar para extender funcionalidades en un programa desarrollado en Python. En [19] se explica cmo utilizar rutinas C++ con Python. Desventajas: El proceso de compilacin es ms complejo y se requieren mayores conocimientos de programacin (manejo de punteros y programacin de ms bajo nivel). Suele costar bastante ms un programador C++ que uno Python. Tiene una barrera de entrada ms alta. Algunos errores en tiempo de ejecucin hacen caer el sistema, tomando un poco mas el tiempo de desarrollo. En [19] y [20] se pueden ver ejemplos de actividades desarrolladas en C++ totalmente o en parte.
4.2.4 Otros Lenguajes Existen otros lenguajes para desarrollar software para XO pero su uso no es recomendable si no se tienen en cuenta aspectos de rendimiento. A continuacin se describen los ms utilizados.
4.2.4.1 Flash Flash es una plataforma muy difundida, principalmente para el desarrollo de aplicaciones o juegos web. Se ha vuelto muy popular porque para hacer animaciones o aplicaciones bsicas no requiere de conocimientos de programacin. Generalmente las aplicaciones flash son accedidas desde una pgina web utilizando el navegador.
La imagen de Centro Ceibal trae instalado el player 10.x de Flash en el browser. La imagen original de OLPC traa instalado el player Gnash y el cambio se debe a un tema de compatibilidad, para que funcionen los sitios web con flash (aunque con severos problemas de performance). La performance del player de Flash en la XO es muy pobre. La inmensa mayora de las aplicaciones Flash no corren adecuadamente en la XO en cuanto a velocidad de respuesta. Flash por supuesto se descarta totalmente para videojuegos y aplicaciones con animaciones. Puede suceder que en el futuro las computadoras OLPC sean ms poderosas y permitan desarrollar actividades Flash, o que la actividad a desarrollar sea muy simple, en cuyo caso puede evaluarse el uso de Flash. Las principales ventajas del uso de Flash es el formato vectorial para realizar animaciones que hace que pese poco, la facilidad que tiene para permitir el manejo de grficos, audio y video, el editor que permite realizar animaciones cmodamente, la cantidad de diseadores y programadores disponibles en el mercado que ya conocen la plataforma, etc. Es posible empaquetar un programa Flash como una actividad, y se gana un poco en performance, pero de todas formas la performance es muy mala para videojuegos y actividades con animaciones.
4.2.4.2 HTML5 El estndar HTML5 est creciendo en adeptos y puede ser una opcin viable para determinado tipo de aplicaciones. La idea es poder ejecutar una aplicacin web desde cualquier navegador que soporte HTML5 sin requerir la instalacin de un plugin. Actualmente se est comenzando a hablar de HTML5 para videojuegos, aunque por el momento se encuentra muy lejos en su uso en la industria, con respecto a Flash por ejemplo. Ejemplos de juegos en HTML5 son el Pacman de Google [22] y el juego BioLab Disaster [23]. Hay libreras para videojuegos como Impact [24], aunque es paga. Un ejemplo de uso de HTML5 es el proyecto OLE Nepal, que desarroll el framework Karma [25] para crear software educativo utilizando HTML5, JavaScript y SVG.
4.2.4.3 Java No es posible utilizar Java en la computadora XO, tal cual viene instalada por no contar con el runtime de Java instalado. Sin embargo, es posible instalar Java manualmente, _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 33 de 73 Centro Ceibal Uruguay
utilizando el navegador Firefox. En [106] se describe la instalacin de Firefox y Java en la computadora XO. No se recomienda su uso para actividades como juegos por su baja performance.
4.3 Desarrollo en Python La versin de Python instalada en la computadora XO hasta principios de 2011 era Python 2.5.1. La versin de Python instalada en la versin F11 disponible desde 2011 es la 2.6. La versin de Python se puede obtener abriendo la terminal y ejecutando el siguiente comando: Python -V Python tambin puede utilizarse con PyGTK [16], que es una biblioteca para implementar una interfaz de usuario. A diferencia de Pygame, PyGTK no est orientada al desarrollo de videojuegos, sino que permite implementar los elementos comunes de una interfaz de usuario (ventanas, tablas, botones, listas, etc). En el sitio web de PyGTK [16] se puede acceder a tutoriales y a la documentacin de la librera. A la hora de desarrollar con Python se sugiere utilizar el estilo de cdigo de estilo definido en la gua PEP8 de Python [17] de forma tal de utilizar un estndar de codificacin conocido que permite la lectura por parte de otros desarrolladores, favoreciendo el intercambio. Para desarrollar videojuegos en Python se utiliza Pygame, que es una biblioteca diseada para dicha actividad. Pygame permite a un programa Python utilizar SDL (por lo cual se dice que Pygame es un wrapper de SDL para Python). Esto permite crear videojuegos o actividades multimedia de forma tal que es portable entre varias plataformas y sistemas operativos. Pygame ya viene instalado en las computadoras XO y funciona perfectamente. Los mejores libros que funcionan como puerta de entrada para la programacin de videojuegos en Python/Pygame son Beginning Game Development with Python and Pygame: From Novice to Professional de Will McGugan [39] y Game Programming With Python de Sean Riley [40]. El libro (free) Invent Your Own Computer Game with Python [87] es una excelente introduccin al lenguaje. En Ceibal Jam se han recomendado algunos libros introductorios sobre lenguaje Python [86], tambin hay un documento que explica la programacin inicial para XO y sugiere otros enlaces para investigar [89].
4.4 Desarrollo en C++ Para desarrollar videojuegos en C++ para la computadora XO, se utiliza la biblioteca SDL _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 34 de 73 Centro Ceibal Uruguay
(Simple Directmedia Library), la cual es una biblioteca que brinda acceso a las interfaces de bajo nivel para realizar tareas de forma eficiente en juegos 2D. SDL nos da acceso al display, al sistema de audio, a los dispositivos de entrada, etc. Al igual que Pygame, SDL viene instalado en la computadora XO y funciona perfectamente. Los mejores libros de introduccin a la programacin de videojuegos en SDL son Focus on SDL de Ernest Pazera [41] y Programming Linux Games [98].
4.5 Sobre el uso de Emuladores Durante el desarrollo del proyecto, los programadores prueban el juego en su computadora local con el entorno de desarrollo (IDE), lo cual es lgico porque se realizan muchas compilaciones al da, pero es recomendable cada cierto tiempo realizar una prueba en la computadora real. Si no se tuviera acceso a una computadora XO, es posible utilizar emuladores, pero de ninguna forma un emulador emula la realidad en forma confiable, por lo cual no se puede prescindir de realizar pruebas peridicas en la misma XO. Pero los emuladores ayudan en dar un entorno ms real que el del propio IDE. De todas formas, la nica manera de garantizar que un producto corre aceptablemente en la computadora XO es realizando las pruebas sobre la misma. Hay muchas cosas que se pueden dar como dadas en cuanto a compatibilidad que luego no son tal, por lo cual es recomendable hacer pruebas en la misma mquina. Muchas cosas pueden ser diferentes: como se siente el teclado, la luz de la pantalla que es un poco mas oscura que en las computadoras normales y los colores no son tan ntidos, el sonido de los parlantes, etc. El uso de emuladores puede mostrar problemas de funcionalidad de nuestro proyecto, pero no sirve para ver problemas de performance. Para esto ltimo se necesita hacer la prueba en la computadora XO misma. Algunos de los emuladores utilizados son QEMU [99], Sugar on a Stick [100] y Virtual Box [108]. En [107] se pueden descargar los archivos de imgenes de OLPC. En [67] hay un instructivo para la instalacin y uso de Jhbuild [66] para armar un entorno de desarrollo Sugar en su computadora.
4.6 Sobre el Desarrollo de Videojuegos El desarrollo de videojuegos es una tarea muy compleja. Se requieren habilidades especficas y se suele trabajar muchas horas. Se necesita de un equipo multidisciplinario formado por productor, diseador de juego, artistas, programadores, msico, etc. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 35 de 73 Centro Ceibal Uruguay
Mucha gente cuando comienza a desarrollar un juego y no tiene experiencia, no sabe como se hace para mover varias cosas y objetos en la pantalla y que stos tengan comportamientos autnomos. Generalmente se tiene la base de programacin que se da en la academia tradicionalmente, en la cual se utiliza mucho la programacin orientada a eventos. Este tipo de programacin sirve para crear una interfaz grfica en la cual se responde a eventos (por ejemplo, al pulsar un botn se invoca a una funcin), pero no para programar un videojuego. De hecho tampoco sirve para programar una interfaz grfica con animaciones. Lo que involucra bsicamente la programacin de un videojuego es: a. Estructura general de un juego, clases y objetos tpicos. b. El loop principal. c. Animacin de sprites y optimizaciones. d. Deteccin de colisiones. e. Respuesta a eventos. Los dos principales conceptos para programar un videojuego son: 1) El game loop (bucle principal) y 2) La mquina de estados de los objetos (FSM: Finite State Machine).
4.6.1 Game Loop El loop principal del juego (game loop) es una estructura que se repite continuamente y mantiene funcionando a todos los objetos del juego. Esto es contrapuesto a la programacin orientada a eventos en la cual el programa no hace nada hasta que el usuario hace alguna accin y esto ocasiona un evento. En un juego hay objetos que se estn moviendo o haciendo cosas, aunque el usuario no haga nada. Bsicamente el loop de un juego es algo as: while (!salir) { checkInput() // Leer la entrada del usuario (teclado, mouse, etc). update() // Lgica del juego. render() // Dibujado del cuadro actual. } update() { // Lgica del juego. Actualizacin de la nueva posicin de cada objetos del juego // de acuerdo a su comportamiento. Lo mismo con el cuadro de animacin de. // cada objeto. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 36 de 73 Centro Ceibal Uruguay
// Chequear colisiones entre objetos, destruir o crear objetos nuevos, etc.
render() { dibujarFondo() dibujarSprites() } El game loop (bucle principal del juego) es uno de los principales componentes a la hora de crear un juego, junto con el concepto de mquina de estado. Estos dos son los grandes secretos de la programacin de juegos que se deben aprender.
4.6.2 Mquina de Estados (FSM) Una mquina de estados (Finite State Machine) es simplemente una idea que permite definir en que estados puede estar un objeto. Por ejemplo, el personaje de un juego de plataformas puede estar parado, caminando, saltando, cayendo, etc. Cada uno de estos comportamientos es un estado y luego tendremos condiciones para pasar de un estado a otro. Por ejemplo, si el personaje est en el estado cayendo, la condicin para cambiar de estado puede ser si toca el piso. Si la cada es muy alta el personaje pasar al estado muriendo, mientras que si no es muy alta pasar al estado parado. Lo importante de todo esto es que la implementacin de una mquina de estado en la programacin, es una forma de organizar el mismo. De este modo, cuando se quiere cambiar cierto comportamiento, hay que ir a esa parte especfica del cdigo que maneja esa situacin, o dicho de otra manera, al estado. Una muy completa descripcin del funcionamiento de FSM y su uso en videojuegos se puede encontrar en [101]. El libro Programming Game Ai by Example de Matt Buckland presenta una excelente introduccin al tema. En particular, la programacin de estados es siempre el primer o segundo captulo de cualquier libro de inteligencia artificial (el primero suele ser el uso de vectores, lgebra y fsica bsica). Se puede acceder al sitio del libro desde [102].
4.7 Bibliotecas y Engines para Juegos Es posible utilizar algunas bibliotecas o engines para acelerar el desarrollo de actividades o videojuegos, o para prototipar ms rpido y probar una idea en el menor tiempo posible. Sin embargo, hay que tener en cuenta que el usar un motor (engine) ya desarrollado, no garantiza un menor tiempo de desarrollo y se recomienda entender cmo est construdo _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 37 de 73 Centro Ceibal Uruguay
el motor para poder usarlo correctamente. A continuacin se introducen algunos motores o bilbiotecas que pueden ser de utilidad.
4.7.1 PGU Python Game Utilities PGU [42] es un conjunto de mdulos (programas Python) tiles para escribir juegos con PyGame. Actualmente PGU contiene mdulos para crear una interfaz grfica con textbox, combobox, botones, etc. Tambin trae herramientas para crear niveles con mapas de tiles y un conjunto de libreras de propsito general para videojuegos.
4.7.2 Box2D y PyBox2D Box2D [43] es un motor de fsica para realizar videojuegos o simulaciones basadas en fsica. Box2D es para utilizar con C++. PyBox2D [44] es una conversin de Box2D para su uso con Python. Para ver una demostracin de la librera e imaginarse sus posibles usos, ver la versin para Flash Actionscript 3.0 es Box2DFlashAS3 [45].
4.7.3 Boost C++ Las libreras Boost de C++ son un conjunto de funcionalidades que se estn adoptando como de uso estndar en la industria, las cuales aumentan la productividad, debido a que aceleran el desarrollo, resultan en menso bugs, evitan reinventar la rueda y reducir costos de mantenimiento [46]. Las libreras Boost tienden a convertirse en un estndar y muchos programadores C++ estn familiarizados con ellas.
4.8 Entornos de Desarrollos Existen varios entornos de desarrollo (IDE) para los diferentes lenguajes y cada uno presenta diferentes funcionalidades. Hay que elegir cual usar de acuerdo a la plataforma en la cual se va a desarrollar y a lo que se necesite. Para desarrollar en Python o C++, algunos de los entornos de desarrollo ms usados en la industria son: Python: Eclipse + PyDev [47] y [48]. Python: IDLE (es ms simple) [49]. C++: Microsoft Visual C++ para Windows [50]. Eclipse CPP para Windows/Linux [51]. Xcode para Macintosh [52].
Captulo 5 - Limitaciones de la Computadora XO y Optimizaciones

La computadora XO est diseada para las necesidades de los nios en la educacin, no para las necesidades de los videojuegos frenticos u otras aplicaciones de oficina [9]. La computadora est diseada para que sea de bajo costo y consuma la menor energa posible, razones por las cuales hacen a la mquina con ciertas limitaciones si se la compara con otros sistemas. Por lo tanto, los desarrolladores deben hacer los mayores esfuerzos para escribir cdigo eficiente y optimizar tanto en espacio como en velocidad de proceso y uso de memoria. En este captulo se describen las limitaciones propias de la computadora XO que hay que tener en cuenta al desarrollar actividades y videojuegos y se describen tcnicas de optimizacin que hay que implementar para que el producto corra en forma adecuada en lo que respecta al rendimiento. Aparte de los consejos habituales sobre optimizacin del lenguaje, con los cuales cualquier programador debera estar familiarizado, se describen en esta seccin los consejos de optimizacin para ser tenidos en cuenta en el desarrollo de videojuegos. Al desarrollar un juego hay varios aspectos tcnicos que tener en cuenta, como la velocidad con que va a correr el juego, cunto espacio ocupar el archivo a distribuir, el tiempo necesario para la descarga, etc. Si bien las computadoras modernas ofrecen mucha capacidad de proceso, las computadoras XO son ms lentas en comparacin, lo cual nos introduce un mayor nivel de exigencia. Entre las principales limitaciones se encuentra la gran resolucin de la pantalla, la falta de tarjeta grfica aceleradora, un procesador ms lento, el espacio en memoria Flash de 1Gb para las actividades, etc. Durante el desarrollo, es necesario mostrar los frames por segundo (FPS) al cual corre el juego para asegurarse que el juego corra a una velocidad adecuada y poder identificar situaciones en el juego en las cuales el frame rate baja (por ejemplo cuando se crean objetos) y poder tomar accin para que esto no ocurra y el frame rate se mantenga constante durante todo el juego. 30 es un frame rate adecuado para videojuegos y 60 seria ideal aunque es difcil alcanzarlos en una XO, dependiendo del juego claro.
5.1 Sobre el Display Cuando se desarrolla un videojuego o una actividad que requiera un uso intensivo de grficos, nos encontraremos que el display es el cuello de botella en lo que se refiere a rendimiento.
Las principales causas son las siguientes: 1) la computadora XO es una computadora con capacidad de procesamiento limitada para lo que son los estndares actuales, 2) no cuenta con una placa aceleradora de video, por lo cual todo el render del juego se debe hacer por software, 3) Normalmente no es posible elegir un modo de video que no sea 1200x900 (SDL y Pygame nos retornan solamente ese modo en la XO), por lo cual ese ser el tamao de ventana a utilizar y es un rea muy grande considerando las caractersticas de la computadora. El hecho ms crtico en lo que respecta a performance es que en la computadora XO las libreras Pygame y SDL solamente soportan el modo 1200x900. No es posible elegir otra resolucin mas baja (salvo utilizando overlays y escalado por hardware, pero esto no se encuentra bien documentado). En general los videojuegos no corren a una resolucin tan grande, la mayora de los juegos descargables de PC corren a 800x600, los juegos flash en web a 640x480, etc. Hay que tener en cuenta entonces que usar esta resolucin tan grande introduce problemas de rendimiento y de espacio y hay que pensar en la optimizaciones que se describen ms adelante.
5.2 Sobre Audio y Video Para realizar un mejor aprovechamiento de la capacidad de almacenamiento y procesamiento de la XO es recomendable utilizar los formatos soportados por la XO para codificar los archivos de audio y video. El formato principal para la reproduccin de audio y video en Sugar es OGG (archivos con extensin .ogg). En [12] se puede obtener ms informacin sobre este formato. En [10] y [11] se puede obtener ms informacin sobre audio y video en la XO respectivamente. El formato OGG es bastante utilizado en videojuegos de PC y Mac y en general cualquier software de edicin de audio lo maneja. En el caso de video, el formato que funciona mejor es OGV. En [105] se puede ver una pgina web con un video que funciona perfecto en la computadora XO, incluso si el video se pone en fullscreen.
5.3 Optimizacin de Memoria La computadora XO no trabaja con espacio de intercambio (swap), como por ejemplo lo hace Windows, y solo unas pocas actividades pueden correr en forma concurrente. Hay que tener en cuenta las limitaciones de memoria cuando se desarrollan actividades, ya que stas limitaciones tendrn un mayor impacto en la performance del software en la XO que en otras computadoras. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 40 de 73 Centro Ceibal Uruguay
5.4 Optimizacin de Espacio Como las computadoras tienen un espacio de almacenamiento limitado (1Gb) y las actividades se suelen descargar desde Internet con una red inalmbrica y con conexiones a veces muy lentas, es conveniente que se piense en optimizar el tamao de la actividad (tamao del archivo .xo que se descarga y luego se instala en la computadora). Debido a la alta resolucin de 1200x900 de la pantalla, las imgenes (archivos JPG, PNG o GIF) deben ser de mayor tamao que lo normal y pueden llegar a ocupar mucho espacio. Se pueden utilizar diferentes mtodos para optimizar el tamao requerido por las imgenes, que al final suman en el tamao del archivo de la actividad. Es posible utilizar archivos JPG para los fondos, que comprime mas el tamao aunque se puede ver ruido en las imgenes. Hay que encontrar el balance justo. Es posible utilizar imgenes indexadas (paleta de 256 colores) en las imgenes PNG si es aceptable en cuanto a la cantidad de colores requerida. Una optimizacin muy importante es el uso de la utilidad PNG Tools [90] para bajar considerablemente el tamao de los archivos grficos PNG. Los desarrolladores de dispositivos mviles utilizan este programa para optimizar al mximo el tamao de los archivos PNG. Se pueden utilizar algoritmos de programacin para hacer transformaciones a los grficos (por ejemplo: mirror, flip, rotacin, cambio de la paleta de colores, etc.) de forma tal de no requerir las imgenes correspondientes. Se podra trabajar en una resolucin menor, por ejemplo a la mitad (600x450) y escalar en tiempo real. De esta forma los grficos se reducen a la mitad del tamao y se sigue utilizando toda la pantalla. Aqu por supuesto existir un trade-off entre velocidad y almacenamiento, y hay que tener en cuenta que en algunos casos puede ser una desventaja tener menos resolucin (se pierde definicin por ejemplo). Hay que ver tambin si se logra mantener un frame rate aceptable realizando el escalado por software.
5.5 Optimizaciones de Velocidad de Ejecucin Existen varias tcnicas de optimizacin de velocidad de ejecucin que son utilizadas generalmente por los desarrolladores de juegos para mviles o sistemas embebidos. Algunas de estas tcnicas son las siguientes: Es mejor utilizar un lenguaje compilado como C++ que uno interpretado como Python. Es bastante ms rpido utilizar color key (un color de la paleta que es tomado como color transparente, por ejemplo, suele utilizarse el magenta puro) que utilizar _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 41 de 73 Centro Ceibal Uruguay
un canal alpha. Las imgenes con alpha tambin ocupan mayor espacio. Es recomendable utilizar matemtica de punto fijo, de modo de no necesitar usar nmeros de punto flotante. Para llamadas a funciones costosas como seno y coseno, utilizar tablas de bsqueda. Se pierde precisin pero se gana en velocidad de ejecucin. Utilizar pool de objetos de forma tal de no pedir memoria cuando se crean objetos nuevos en el juego. No dibujar todo el cuadro en cada frame. Utilizar tcnicas de optimizacin de videojuegos como Dirty Rectangles. Evitar correr lgica de objetos que se encuentran fuera de la cmara, o comprobar colisiones de todos contra todos.
5.6 Uso de los Lenguajes Para desarrollar un videojuego para la computadora XO lo ms eficiente en cuanto a rendimiento (por ejemplo que mueva muchos sprites a la vez) es C++. De todas formas siempre hay que trabajar bastante en temas de optimizacin y en forma constante durante el desarrollo. Es aconsejable para este tipo de desarrollos el uso de C++ y SDL e incluso alguna rutina Assembler si se lleva al extremo el videojuego (por ejemplo para implementar scrolling o muchos sprites en pantalla). Python es mas apto para quien se inicia en programacin o para escribir la lgica de algunos objetos del juego o la interfaz de usuario, pero hay que usarlo para las partes del juego que no sean crticas en cuanto a performance. Si se disea alguna actividad teniendo en cuenta las limitaciones de la plataforma, es perfectamente posible hacerlo en Python a la resolucin de 1200x900. Lo mejor es realizar un prototipo lo mas temprano posible para asegurar que el motor del juego que se tiene hace posible el desarrollo deseado.
5.7 Redibujado de la Pantalla (Dirty Rectangles) Un aspecto clave de un videojuego a la hora de correr a un frame rate adecuado (por lo general 30-60 FPS) es la cantidad de grficos que hay que actualizar en la pantalla en cada frame. Esto se agrava por el hecho de que la computadora XO tiene una resolucin muy alta. Por ejemplo, supongamos que tenemos un juego en el cual hay un dibujo de fondo y sobre l se mueven muchos sprites. Si en cada cuadro dibujamos el fondo y todos los grficos, las cosas andarn lentas. Est bien comenzar hacindolo de esta forma y luego optimizar las rutinas de dibujo, pero en algn momento hay que hacerlo si el juego tiene los grficos suficientes como para que el frame rate no sea aceptable. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 42 de 73 Centro Ceibal Uruguay
En general el software se escribe primero y luego se optimiza, aunque siempre pueden haber excepciones. Una optimizacin para lograr tener muchos sprites en pantalla y que corra aceptablemente es usar la tcnica Dirty Rectangles, en la cual solamente se dibuja en pantalla los rectngulos que se han modificado. La tcnica de Dirty Rectangles implica definir un bounding box para cada imagen. Un bounding box es un rectngulo que engloba a la imagen, generalmente desde la esquina superior izquierda hasta la esquina inferior derecha. De esta forma, cuando se va a dibujar una imagen, se guarda lo que haba en el fondo. Luego cuando el objeto se mueve, se restaura lo que haba en el fondo y se dibuja la imagen en la nueva posicin. De esta forma se evita el dibujado del fondo y de todos los objetos en cada frame, lo cual es mucho ms eficiente. El nombre de la tcnica proviene justamente del hecho de que dibujamos solamente los rectngulos que marcamos como sucios, y estos son los que marcan la posicin anterior que tenia el objeto que vamos a dibujar en el frame actual. Pygame soporta el uso de dirty rectangles en grupos de sprites para actualizar solo las partes de la pantalla que cambiaron desde el cuadro anterior [53]. Hay una discusin muy interesante sobre esta tcnica en la lista de Pygame [54].
5.8 Overlays (Escalado por Hardware) Una buena solucin al problema de performance en juegos de accin con muchos objetos en pantalla, o con scrolling, es hacer el juego a una baja resolucin y luego utilizar overlays para llevar esa imagen a la pantalla completa (el chip de video de la computadora XO soporta escalado por hardware). Una ventaja tambin de trabajar en menor resolucin es que los grficos del juego ocuparn menos espacio en el archivo de la actividad. Hasta donde se investig, la computadora XO tiene deshabilitado el vsync, con lo cual si el juego se mueve a gran velocidad (scrolling), puede haber un notorio tearing. Para implementar overlays hay que referirse a la documentacin de SDL [15] y utilizar la clase SDL_Overlay. Implementando el escalado por hardware, es posible trabajar a resoluciones ms chicas de pantalla, lo cual abre la puerta para tener muchos grficos en la pantalla, implementar sistemas de partcula, implementar niveles grandes con scrolling, utilizar motores de fsica como Box2D [43], o incluso hacer un juego simple en 3D utilizando un motor de render por software como Mic3D [109].
5.9 Otras Optimizaciones Las optimizaciones ms crticas en videojuegos aparte del tamao de pantalla y la optimizacin al dibujar, son el uso de pool de objetos y el uso de matemtica de punto fijo. Existe un tutorial que muestra como hacer un pool de objetos y utilizar matemtica de punto fijo en un juego arcade (Asteroids) [55]. Si bien el cdigo es J2ME (Java 2 Micro Edition) est escrito muy claramente y es totalmente aplicable a otro lenguaje. La idea detrs del pool de objetos es que la operacin new para crear un objeto es muy lenta y no se puede hacer constantemente. De esta forma, en un array almacenamos objetos creados previamente (por ejemplo durante la carga o inicializacin del juego) y luego en lugar de crear y destruir objetos simplemente los tomamos del pool de objetos (del array) o los colocamos nuevamente en l. La idea detrs de utilizar matemtica de punto fijo (entera) es evitar el uso de nmeros en punto flotante, los cuales son ms lentos en las operaciones que los enteros. Tambin el evitar conversiones de tipos en las operaciones o llamadas a funciones, que siempre toman tiempo. De esta forma, usando punto fijo, podemos tener por ejemplo, tablas de seno y coseno que nos devuelven los valores sin tener que invocar a estas funciones que son lentas. Se pierde precisin pero se gana en eficiencia. El tutorial [55] explica bien ambas tcnicas de optimizacin, tan usadas en la programacin de videojuegos para celulares y aplicaciones mviles. Los sitios [91] y [92] contienen informacin muy til de optimizacin en Python. Cabe recordar que siempre es mejor escribir la programacin y luego pensar en la optimizacin, aunque siempre hay excepciones. Hay que balancear siempre el escribir cdigo claro contra el escribir cdigo ms optimizado aunque no tan legible.
Captulo 6 - Normas de Usabilidad y Testing

Este captulo trata sobre las normas de usabilidad a tener en cuenta durante el diseo, produccin y testing de actividades educativas o videojuegos y de cmo llevar a cabo el proceso de testing. Se brinda una lista de elementos a tener en cuenta para que el software se comporte en la forma esperada por los usuarios. Como la computadora XO es una computadora con limitaciones, es sumamente importante realizar las pruebas en la misma computadora XO. Durante el desarrollo es normal utilizar un PC normal de escritorio o un notebook de mayor poder, pero cuando se prueba en la computadora XO, no todo debera funcionar de la misma manera. El testing final de las actividades debe realizarse en la computadora XO y nunca debe asumirse que todo funciona igual. Con respecto a la usabilidad, cabe mencionar que los nios que utilizan las computadoras XO, generalmente es la primera computadora que manejan, por lo cual no se debe asumir que los nios esperan que algo funcione de determinada manera. No hay mejor sustituto que realizar un focus group con los nios para probar la usabilidad de la actividad.
6.1 Audiencia Una gran consideracin a tener en cuenta en el diseo de la actividad es que los usuarios finales sern nios y nias en edad escolar y liceal (entre 5 y 17 aos). Hay que tener en cuenta a la hora de disear la actividad, la audiencia para la cual est destinado el producto. Por ejemplo, los escolares de los primeros niveles pueden tener dificultad para leer, por lo cual no es bueno que el producto requiera obligatoriamente la lectura, a menos claro que sto realmente no se pueda evitar. Para la mayora de los nios, esta computadora es la primera computadora a la cual tienen acceso, por lo cual son inexperientes en el uso de las mismas, aunque aprenden muy rpido. Por este motivo hay que invertir tiempo en hacer la interfaz intuitiva, en la cual sea posible descubrir las cosas por s mismo, utilizando metforas que el nio entienda. Por otro lado, hay nios que reciben la computadora a la edad de 5 o 6 aos, y la tendrn durante todo el proceso escolar. Otros la recibirn a los 10-12 aos, por eso es importante que la actividad tenga en cuenta las diferencias de edades. Otra consideracin en cuando a la audiencia es la coordinacin y los reflejos necesarios, sobre todo para juegos de accin. Los escolares de los primeros niveles no tienen tanta coordinacin como los escolares de niveles superiores o liceales. El ejemplo tpico es requerir dos manos para jugar: con una se mueve el personaje utilizando las flechas y con la otra mando se utilizan varias teclas (saltar, disparar, etc). Los escolares de los primeros niveles pueden tener cierta dificultad en coordinar dos manos y varios botones simultneamente. De todas formas nunca hay que subestimar a la audiencia escolar y hay que probar realizando focus groups. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 45 de 73 Centro Ceibal Uruguay
No todos los usuarios son iguales y hay que considerar estos aspectos desde el diseo de la actividad. Se recomienda realizar focus groups dos o tres veces durante el desarrollo para detectar fallas de diseo (los focus groups suelen hacerse al alcanzar las etapas alpha y beta y los resultados suelen ser excelentes para mejorar la calidad y usabilidad de la actividad).
6.2 Fundamentos de Diseo Es muy recomendable leer la gua de la interfaz grfica de Sugar (Human Interface Guidelines de Sugar Labs) [9], ya que la misma explica la razn de porqu algunas cosas funcionan de determinada manera en Sugar y podran ser aplicadas a nuestro proyecto para mejorar la usabilidad. En esta seccin se resumen los principales aspectos de la misma que son ms relevantes.
6.2.1 Interfaz Universal La iniciativa OLPC funciona a nivel global, razn por la cual se deben tener en cuenta que la aplicacin puede ser usada por diferentes culturas y en otros lenguajes a los cuales las laptops puedan llegar. Las actividades no deberan utilizar metforas o ideas propias de la cultura local, occidental, etc, sino que deben usar un nivel de abstraccin que funcione para toda la humanidad en general, dentro de lo posible.
6.2.2 Interfaz Intuitiva La actividad y la interfaz grfica debe ser diseada de forma que sea simple e intuitiva para el usuario de todas las edades, nacionalidades y niveles de experiencia en el uso de computadoras.
6.2.3 Simpleza En general, evitar el uso de controles complicados, o que no apliquen en el contexto actual. Tratar de mantener en todo momento la interfaz de usuario lo ms clara y simple posible.
6.3 Gua de Estilo del Plan Ceibal En el caso en el que se est desarrollando un videojuego o actividad exclusivamente para el Plan Ceibal y se desee utilizar a los personajes Ceibal, es necesario cumplir con las normas sugeridas en la Gua de Estilo del Plan Ceibal. La Gua de Estilo es una gua para desarrolladores de proyectos educativos orientados al Plan Ceibal. En ella se brindan pautas a seguir, necesarias para mantener una consistencia y solidez en la comunicacin visual institucional y con el propsito de que la actividad cumpla con los criterios de la marca Ceibal. En sta gua se describen aspectos bsicos que son sugerencias (cuando la actividad se desarrolla exclusivamente para Plan Ceibal), como por ejemplo el uso de colores, que tipografa usar, cmo deben ser los iconos, etc.
Fig. 9: Personajes de la Gua de Estilo: Ape, Lupe y JP. La Gua de Estilo desarrolla una familia de personajes (Ape, Lupe y JP entre otros) que pueden ser utilizados en la actividad. En la gua se explica cmo son y se dan elementos para ayudar a crear las animaciones. Es importante remarcar que la idea es que estos personajes estn asociados al Plan Ceibal y estn presentes en la imagen corporativa de Ceibal. En el sitio de desarrollo del Plan Ceibal [26] se puede acceder a la Gua de Estilo. Cabe remarcar que el uso de la Gua de Estilo y de los personajes Ceibal es totalmente opcional, pero necesario si se quiere realizar un producto que refuerce la marca Ceibal y utilice sus personajes.
6.4 Testing Durante el desarrollo del proyecto se asume que se utilizan buenas prcticas de diseo de software, de programacin y de testing para asegurar la mayor calidad y verificar el correcto funcionamiento del programa. Se asume que los desarrolladores conocen estas prcticas que son ampliamente utilizadas en la ingeniera de software. Sin embargo, el desarrollo de un videojuego requiere un testing especial, debido a la inherente complejidad de los mismos. Los principales tipos de testing, son el gameplay testing y el beta testing. El primero determina que el juego es divertido, que el gameplay funciona, que la dificultad se presenta en forma gradual, etc., mientras que el segundo se encarga de la bsqueda de cualquier error o situacin no deseada (bug), y generalmente se realiza el testing en la versin beta y luego en la versin final. En el libro Fundamentals of Game Development [28] se puede profundizar sobre el testing de videojuegos. En [29] se describe bsicamente el funcionamiento del testing en videojuegos.
6.5 Normas de Usabilidad y Testing A continuacin se describen las principales normas de usabilidad y cosas a verificar para asegurar la calidad del proyecto y que el mismo tenga una excelente usabilidad y se encuentre bien probada. Cada una de estas normas se aplica en general a todo el producto y/o a cada pantalla, con lo cual debern estar incluidas en el Plan de Testing que se confecciona para testear el producto (como se detalla en la seccin 6.5).
6.5.1 Barra de Carga Si la actividad est realizando algn procesamiento como una carga de grficos por ejemplo, y sto demora un tiempo, colocar una barra de carga que se ir actualizando conforme se va realizando la carga. Esto disminuye la sensacin de espera por parte del usuario (jugador) y no perder el inters del mismo en el juego. No es deseable que el programa no indique cuando no se encuentra listo a responder a las ordenes del usuario (por ejemplo que no haya una indicacin de que la computadora est realizando una tarea, esto se puede tomar como una duda sobre si el programa sigue funcionando o no).
6.5.2 Frames por Segundo (FPS) En los casos que se trate de un juego o actividad con animaciones y movimiento, el juego debe correr como mnimo a 24 FPS (frames per second, frame rate). Aceptable son 30 FPS. Con menos de 24 FPS ya se comienza a notar el bajo frame rate. Idealmente un videojuego debe correr a 60 FPS, aunque en la XO esto no es posible porque el mximo que da la tarjeta de video oscila entre 48 y 52 FPS. Durante el desarrollo se deben mostrar los FPS en pantalla en todo momento y ver que el nmero no baje en determinadas situaciones (generalmente cuando aparecen nuevas animaciones o entran nuevos objetos en la escena). Si la actividad tiene pocas animaciones o poco movimiento este factor es irrelevante. Para lograr ms cuadros por segundo una aplicacin debe procesar menos cosas o dibujar menos. Por ejemplo, bajar la resolucin y no usar grficos con alpha son acciones tpicas. Se asume que la medicin de FPS es con el juego corriendo en modo exclusivo en la computadora. Es recomendable revisar la seccin sobre optimizaciones en esta gua y estudiar las referencias brindadas.
6.5.3 Tiempos de respuesta Cuando el usuario realiza un click con el mouse, la accin de la respuesta debe ser inmediata, de otra forma la experiencia del usuario sera muy mala. Lo mismo cuando el jugador pulsa una tecla. En un juego este es un aspecto crtico, por ejemplo, si se pulsa la tecla de disparo, la bala debe salir inmediatamente ya que el jugador coordina el tiempo para que as sea y si esto no ocurre as la experiencia es mala. Si el juego est funcionando a un bajo frame rate, el tiempo de respuesta baja mucho y el juego no es divertido. Para lograr un tiempo de respuesta aceptable la solucin es la optimizacin. El programa debe poder en cada frame (en el tiempo entre frame y frame) correr la lgica del juego y dibujar lo que sea necesario.
6.5.4 Uso del Gamepad Sobre todo si se trata de un juego, el mismo debe mapear las teclas de movimiento (las flechas de direccin) al joystick y las teclas de accin (por ejemplo saltar y disparar) a las teclas del gamepad. De esta forma la XO puede darse vuelta y se puede jugar como si fuera una consola de videojuegos porttil. Hay que tener en cuenta, siempre que sea posible, que la actividad no debe requerir el uso de mouse. Dicho de otra forma, los menes de la actividad y las pantallas deben ser navegables utilizando solamente las teclas del joystick y las teclas del gamepad. El caso tpico es el uso del joystick para seleccionar una opcin del men, la tecla (X) para aceptar y la tecla (O) para cancelar y volver hacia atrs como se hace en las consolas de videojuegos porttiles. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 49 de 73 Centro Ceibal Uruguay
6.5.5 Legibilidad de los Textos Los textos deben de ser legibles (hay que tener en cuenta que los nios escolares de los primeros aos estn comenzando a aprender a leer). Se recomienda utilizar una fuente clara. La fuente utilizada en Sugar y sugerida por el documento Human Interface Guidelines [9] es DejaVu LGC Sans. Hay que estudiar de acuerdo a cunto texto se muestra en pantalla, que los textos sean bien legibles y claros. Los textos se tienen que poder leer sin esfuerzo, sobre todo en videojuegos cuando se usan textos con estilos particulares. Verificar que todos los textos tengan el formato apropiado, que estn legibles y que se encuentren centrados o justificados segn correspondan (por ejemplo, verificar que ningn texto queda tocando un margen).
6.5.6 Ortografa y Gramtica La actividad no puede contener textos con errores ortogrficos o gramaticales. Se debe cuidar la redaccin para que los textos sean comprensible por el pblico infantil. Aunque los errores de texto siempre son indeseables, en el caso de actividades educativas la ortografa y gramtica cobra un rol mucho ms importante porque se encuentra enmarcado en un plan educativo y es fundamental dar el ejemplo. Se hace necesario que la revisin del texto la haga un profesional (docente), debido a que por ms que los textos sean revisados por el equipo de desarrollo, es muy factible que siempre se pase por alto algn detalle. El docente puede detectar errores conceptuales o de contexto que son ms difcil de detectar para los desarrolladores. Se sugiere revisar los textos reiteradas veces en busca de ambigedades o contradicciones en las ideas, que no existen frases repetidas o que no hayan errores de otro tipo que no sean ortogrficos o gramaticales. Revisar en particular errores que con el tiempo se adquieren de la costumbre de utilizar Internet (por ejemplo en espaol utilizar el signo de exclamacin al final y no al principio, el de pregunta lo mismo). Otro error muy comn al desarrollar es la falta de punto final en las oraciones.
6.5.7 Contenido Apropiado Verificar que el proyecto no tiene referencias a alcohol, drogas, etc. Verificar que el lenguaje sea el apropiado para el uso en ambiente educativo y con nios. Asegurarse que el proyecto tenga en cuenta consideraciones de gnero. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 50 de 73 Centro Ceibal Uruguay
Verificar que los textos del juego son apropiados y no contienen malas palabras. Una cosa que sucede durante el desarrollo es que los programadores colocan malas palabras en el cdigo para luego buscarlas, o como textos de placeholder. Pero luego, es posible olvidarse de cambiarlo y el programa sale con estos textos. Como norma general para que esto nunca suceda, prohibirle a los programadores el uso de texto no apropiado en forma temporal. Lo mismo puede suceder con los artistas cuando nombran archivos.
6.5.8 Libre de Errores La actividad debe estar libre de errores. Si bien esto no es posible asegurarlo cien por ciento, hay que realizar pruebas que son las tpicas durante el desarrollo de software. Entre otras, probar la actividad corriendo muchas horas, probarla concurrentemente con otras actividades abiertas, etc. Este tipo de errores es sencillo de detectarse. Hay con hacer la lista de features que tiene la actividad y probarlas una a una. Por ejemplo: Apagar el sonido desde el men de configuracin de la actividad y asegurarse que ningn sonido se escuche. Probar todas las teclas del teclado una a una para asegurarse que no haya quedado activada una tecla de debug. Verificar que no haya ningn texto utilizado en debug. etc.
6.5.9 Seguridad La actividad no debe violar la seguridad de la computadora en lo que respecta a los siguientes puntos: No daa de ninguna manera la computadora. No compromete la privacidad del usuario. No causa prdida de datos del usuario. No le hace cosas malas a otros usuarios. No se hace pasar por otro usuario.
6.5.10 Adaptabilidad La actividad debe comportarse apropiadamente, segn los cambios que ocurren en el sistema. Entre otros: La actividad se puede usar bien en los modos color (backlight) y blanco y negro (a _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 51 de 73 Centro Ceibal Uruguay
la luz del sol). La computadora puede estar en modo laptop (con el teclado y touchpad disponible) o en modo e-book (solamente estn disponibles las teclas del gamepad). La computadora puede momentneamente no estar con salida a Internet, puede estar con la red inalmbrica apagada, etc. Para actividades colaborativas: La fuerza de la seal de la red inalmbrica, y por lo tanto el ancho de banda, puede fluctuar. Otros participantes de la actividad pueden abandonar la misma y se debe tener en cuenta esto. La actividad debe manejarlo internamente, intentando reconectar a los usuarios que estaba participando o manejando el abandono de usuarios sin que esto provoque errores o que la actividad no se pueda seguir usando.
6.5.11 Salvado Si aplica, la actividad debe poder guardar los datos de modo de poder continuar desde el punto donde se dej. Es muy molesto para el usuario perder el progreso de su juego y no se lo puede obligar a realizar de nuevo lo que ya ha hecho antes. Tambin la actividad tiene que salvar cualquier configuracin que el usuario pueda modificar. Entre otras, hay que realizar las siguientes pruebas: La primera vez que se instala la actividad, asegurarse que las opciones por defecto son las correctas. La primera vez que se instala la actividad, asegurarse que el salvado no existe y se crea correctamente en la situacin inicial. Cambiar una configuracin en el juego, luego salir y volver a entrar. La nueva configuracin se debe haber guardado (por ejemplo el volumen). Pasar un nuevo nivel, luego salir y volver a entrar. El juego debera permitir comenzar en el ltimo nivel accedido y no obligar a empezar desde el inicio.
6.5.12 Pausa Si se trata de un juego de accin o una actividad en la cual interviene la variable de tiempo para realizar alguna accin, tiene que ser posible poner en pausa el juego. De esta forma, si el nio es interrumpido, pone el juego en pausa y puede atender. Se recomienda colocar un botn de pausa o que se llame a la misma pulsando la tecla Escape (la tecla [X] arriba a la izquierda)
6.5.13 Accesibilidad Se recomienda leer los lineamientos de la interfaz grfica respecto a la accesibilidad compilados en [35]. La actividad debera abordar (si aplica) los siguientes puntos en lo que respecta a la accesibilidad (hacer accesible o fcil de manejar el programa). Los siguientes puntos son tomados de [9]. Poder usar la actividad solamente con el teclado (sin el uso de mouse). Poder utilizar la actividad sin requerir la habilidad de distinguir entre colores (una gran parte de la gente tiene algn grado de ceguera al color). Para esto se recomienda desaturar (pasar a blanco y negro) una captura de pantalla y ver que las cosas se distingan bien en blanco y negro. No requerir que el usuario pulse ms de una tecla a la vez.
6.5.14 Integracin con el Diario La actividad (si aplica) debe integrarse al Diario, ya que es a travs del mismo que los nios acceden a los archivos. En Python hay varias herramientas para incorporar al proyecto las funcionalidades de Sugar (a esto se le denomina Sugarizar la actividad). Para el manejo de las entradas en el Diario, Sugar utiliza la biblioteca sugar.datastore [59]. Esta biblioteca de Python provee mtodos para crear nuevos objetos en el Diario, buscar entradas, eliminar archivos, etc.
6.5.15 Compatibilidad con Rainbow Rainbow es el sistema de seguridad que utiliza Sugar. Tiene como objetivo impedir que una actividad mal programada, o intencionalmente perjudicial, afecte la integridad del sistema. Para esto asla la ejecucin de una actividad del resto del sistema (como lo hacen los sistemas UNIX). Restringe, por ejemplo, el espacio de almacenamiento donde la actividad puede leer y escribir. Como todo sistema de seguridad tiene su costo, las actividades tienen que ser desarrolladas considerado las restricciones que el sistema de seguridad impone [60]. En la imagen utilizada hasta principios de 2001 Rainbow exista, pero en la imagen F11 Rainbow no existe ms y es probable que no est en el futuro.
6.5.16 Comportamiento y Funcionalidades de la Actividad La actividad debe comportarse adecuadamente y debe tener funcionalidades esperadas. La lista de issues a verificar es la siguiente (algunas pueden ser opcionales segn el _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 53 de 73 Centro Ceibal Uruguay
caso): Tcnicas: Permitir cambiar de actividad con las teclas Alt+Tab. La actividad se debe comportar adecuadamente al volver. La actividad debe ponerse en pausa cuando pierde el foco (de modo de no perder el juego o que los sonidos no sigan escuchndose, entre otras cosas). Permitir el cierre de la actividad con Alt+F4. Permitir salir del juego con la tecla Escape mediante confirmacin. Permitir apagar el audio y controlar el volumen de la msica y los sonidos. Correr en fullscreen si se trata de un videojuego inmersivo. Evitar que se puedan iniciar varias instancias de la actividad. Usabilidad: Poder seleccionar el nivel en el cual empezar si ya se han destrabado niveles. Que la actividad se encuentre pulida y con el nivel de calidad esperado. Que hayan pantallas con el progreso de carga cuando alguna actividad demora. Que hayan transiciones entre las diferentes pantallas o niveles. Indicar que hay que hacer con instrucciones claras.
6.5.17 Audio Los temas a verificar relacionados con el audio son los siguientes: Asegurarse que los audios del juego estn con la compresin adecuada, de forma tal de cuidar que los mismos no sean archivos de gran tamao. Hay que tener en cuenta que los parlantes externos de la computadora XO no justifican el usar archivos de audio de mucha calidad. Probar que los efectos de sonidos y msicas se escuchan bien en la computadora (los sonidos con graves producen ruidos molestos en el parlante). Asegurarse que la msica loopea bien. Hay que asegurarse de que todos los botones tienen sonido. El sonido de click es obligatorio y el de rollover es opcional.
6.5.18 Archivo de Distribucin Con respecto al archivo final de distribucin (el bundle), hay que revisar y realizar las siguientes pruebas. Asegurarse que el icono de la actividad se vea bien al instalarla. Controlar el tamao del archivo. Puede ser que algunos audios o imgenes estn sin comprimir y esto aumente sin necesidad el tamao del archivo (ver la seccin _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 54 de 73 Centro Ceibal Uruguay
de optimizacin en tamao). Asegurarse que la actividad se instala correctamente al ser accedida desde la actividad Navegar con Internet.
6.5.19 Navegabilidad Luego de creado el diagrama del flujo de pantallas de la actividad, se revisa en el plan de testing los siguientes puntos: Todos los botones funcionan correctamente (hacen lo que tienen que hacer). Todos los botones tienen estados de click y rollover. Revisar que todos los botones que no aplican al contexto estn deshabilitados y los que aplican se encuentran habilitados. Revisar que cada transicin de pantalla funciona correctamente. Controlar las animaciones de la pantalla. Revisar la navegabilidad con el mouse (mouseover y click). Revisar que la pantalla se pueda navegar con el teclado solamente. Revisar si la tecla Escape (X) hace lo que debe en la pantalla: Salir con confirmacin en el men principal. Llamar al men de pausa en el juego. Volver hacia atrs en pantallas como Crditos y Ayuda. Revisar si la msica es la adecuada en la pantalla. Se recomienda investigar las normas de usabilidad de Nokia [103], las cuales si bien estn orientas a dispositivos mviles, la mayora de las consideraciones que ah se mencionan aplican al desarrollo para XO. El documento a leer es Game design de la seccin Design and User Experience v2.0. En particular porque las mismas apuntan a un pblico que no es experto con el manejo de tecnologas (como es el caso con los celulares) y aplica para nios chicos con sus XO. Nokia siempre ha estado un paso adelante en la investigacin en usabilidad y hace aos que viene desarrollando estas guas, al punto que al da de hoy involucran dispositivos touchscreen y utiliza ejemplos de los ltimos juegos. En este documento se sugiere un flujo de pantallas que se resume en la siguiente imagen. El flujo de pantallas puede variar segn el tipo de actividad, pero bsicamente tendr estas pantallas.
Fig. 10: Flujo de Pantallas Sugeridas en el Documento de Usabilidad de Nokia [103].
6.5.20 Logos Asegurarse que se encuentren visibles los logotipos de Plan Ceibal y Rayuela junto con los logos de las empresas involucradas en el men principal, as como en la pantalla de crditos.
6.6 Plan de Testing Para conducir el testing, el desarrollador debe realizar un plan de testing el cual es diferente para cada proyecto, dado que cada uno tiene sus particularidades. El plan de testing es una planilla con una lista de cosas a verificar y pruebas a realizar. Al realizar el testing del software, se va anotando en la planilla el resultado (para cada punto se anota si lo pasa, si hay observaciones o si no lo pasa y cual es el problema detectado). Hay normas de usabilidad, comportamiento esperado por el usuario y parmetros de calidad que deben cumplir en comn todos los proyectos. A eso se le debe agregar el testing particular de cada proyecto. Es de vital importancia que la versin final del videojuego cumpla con el plan de testing. Cualquier cambio que se realice de ltimo momento requiere ejecutar nuevamente el plan de testing. No se debe asumir que un arreglo de ltimo momento no impacta en otra parte. Los videojuegos son software complejo con muchas entidades interactuando entre s y no se debe subestimar cualquier cambio por menor que ste sea. Un plan de testing obliga a prestar atencin a detalles que normalmente no se atenderan. Esto se debe a que es una lista de cosas a verificar y si bien es tedioso ir punto por punto probando el funcionamiento, es mejor que correr el videojuego y luego en el momento definir sobre la marcha que se prueba (de esta forma se escaparan muchos detalles). Cada proyecto a ser testeado necesita un plan de testing realizado a medida de la misma. Si bien hay cosas a testear y normas de usabilidad que son comunes a todos los proyectos, para cada uno hay que crear un plan de testing. El plan de testing que viene a continuacin son normas en general. En la primera hoja del plan de testing se pone una cartula con los datos del proyecto y del tester: Proyecto: Desarrollador: Publisher: Plataforma: Lenguaje: Breve descripcin: Pblico Objetivo: Fecha: Tester: La seccin 6.5 lista las principales reglas de usabilidad y comportamiento que el usuario espera de la actividad y que el software debe cumplir para aprobar la etapa del testing. Cada una de estas normas aparecern en la planilla del plan de testing para ser verificadas. Estas normas (ver seccin 6.5) deben ser cumplidas por los proyectos que sean desarrollados para Plan Ceibal. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 57 de 73 Centro Ceibal Uruguay
Un ejemplo de elementos a verificar en el plan de testing, a nivel de actividad, es el siguiente: Test La aplicacin se instala correctamente haciendo click sobre el paquete de la actividad utilizando un pendrive desde el Diario. La aplicacin se instala correctamente accediendo al archivo .xo desde el navegador usando Internet para descargarlo. La informacin guardada aparece en el Diario con la fecha, hora, cono y descripcin correctas. La informacin guardada en el diario es abierta correctamente por la aplicacin cuando se hace click sobre el icono. El icono de la aplicacin aparece correctamente en la lista de aplicaciones. La aplicacin se ejecuta correctamente luego de abrirla desde la lista de aplicaciones. La aplicacin termina correctamente. La aplicacin reacciona como se espera ante los comandos del marco de Sugar. La planilla se construye con el texto del test en una columna y luego otras columnas con los siguientes datos: Test --------------------------------------------------etc. Resultado (Si/No/NA) Si No Observaciones ------------------------Tester Julio Julio
Luego para cada pantalla de la actividad o videojuego se debe realizar una ficha con cosas en comn a verificar. Ejemplo de ficha para cada pantalla de la actividad: Pantalla: Men Principal: Test Resultado (Si/No/NA) - La pantalla carga en tiempo razonable. - El frame rate es aceptable. - El botn Jugar arranca el juego. - El botn Jugar reproduce sonido de click. - Animaciones funcionan bien. - Los textos estn sin errores. - Los textos no tocan ningn margen. etc... Observaciones Tester
Es necesario armar un diagrama con el flujo de pantallas para determinar si cada pantalla funciona correctamente. Para revisar el flujo del programa y controlar que todos los _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 58 de 73 Centro Ceibal Uruguay
botones de la actividad funcionan bien, que el pasaje entre pantallas es el correcto, y para revisar que funcionan correctamente todas las condiciones que tiene la actividad en lo que respecta a la navegabilidad de las pantallas. Para armar estas fichas para cada pantalla de la actividad, se deben revisar las normas de usabilidad que se explican a continuacin. Cada una de estas normas sera una o varias lnea de la planilla para verificar. Esta planilla se construye para cada pantalla de la actividad.
Apndice A - Cmo se Construye una Actividad

A.1 Armado de la Actividad La actividad se distribuye como un archivo con extensin .xo (que se denomina bundle). El archivo es un archivo comprimido (si descargamos un archivo .xo y le cambiamos la extensin a .zip, lo podemos abrir con cualquier programa descompresor como 7Zip por ejemplo). Se recomienda leer el tutorial sobre cmo crear una actividad [61] y el tutorial sobre desarrollo de actividades [62]. En ste ltimo se sugieren entornos de desarrollo y programas de edicin de grficos open source o libres, se brinda informacin de cmo crear actividades colaborativas, cmo trabajar con el Diario, utilizar Pygame, etc. Otro tutorial es [63], desarrollado por Ceibal Jam de Uruguay. En el sitio [85] se brindan varios recursos para el desarrollo en Sugar. Como se mencion anteriormente, en Sugar las aplicaciones son llamadas actividades y necesitan ser embebidas dentro de una ventana de actividad. Esta ventana provee algunas funcionalidades comunes a todas las actividades, a travs de la pestaa Actividad, donde se encuentran los botones para darle nombre, compartir o cerrar la actividad. Debe existir una estructura creada para poder empaquetarla y as instalarla fcilmente en la XO. Por ejemplo, la estructura bsica para una actividad llamada MiActividad es: MiActividad.activity/ MiActividad.activity/setup.py MiActividad.activity/activity MiActividad.activity/activity/activity.info MiActividad.activity/activity/<nombre del icono>.svg MiActividad.activity/<Programa Principal>.py MiActividad.activity/MANIFEST Todos los directorios deben tener los permisos 755 (drwxr-xr-x) y todos los archivos deben tener los permisos 644 (-rw-r--r--). Todo esto se empaqueta en un archivo .xo que tiene compresin zip (se puede utilizar 7Zip para armar el archivo .xo).
A.2 Icono de la Actividad El icono de la actividad debe ser un archivo formato SVG. Para que use los colores del usuario hay que agregar un par de entidades que sugar sustituye y usar esos nombres en vez de colores [64]. Si bien los iconos de las actividades de la computadora XO son en blanco y negro, es posible hacer iconos de colores.
A.3 Instalacin de Actividades Hay varias formas de instalar una actividad en la computadora XO para verificar que se ha armado correctamente. Entre otras: Acceder desde la actividad Navegar a la URL conteniendo el arhuivo .xo. La actividad se descarga y se instala automticamente. Ir al Diario y acceder al pendrive. Acceder al archivo .xo desde ese lugar. Utilizando la terminal, ir al directorio en el pendrive donde se encuentra el archivo.xo y ejecutar sugar-install-bundle nombre_del_archivo.xo. En [104] se explican diferentes formas de instalar actividades. Para realizar varias tareas auxiliares durante el desarrollo, como es el instalar actividades y otras como por ejemplo verificar que el archivo de salvado del juego sea el correcto, se necesitan conocimientos de manejo de la terminal de Linux. Por ejemplo, para instalar manualmente un archivo .xo desde un pendrive, primero hay que acceder al pendrive. Se escribe cd /media y luego ls para ver los directorios que hay. Uno de ellos es el pendrive. Se escribe cd /nombre_del_pendrive y luego ls para ver la lista de archivos en l. Luego se escribe sugar-install-bundle nombre_del_archivo.xo y la actividad se descomprime y se instala en la carpeta de actividades. En [110] se describen los principales comandos Linux para usar en la Terminal y poder as solucionar temas que aparecern durante el desarrollo. Cualquier desarrollador de ambiente Linux estar familiarizado con estos comandos.
Apendice B - Desbloqueo de las XO y Flasheo

B.1 Desbloqueo de la XO Las computadoras XO distribuidas por Plan Ceibal tienen un sistema anti robo, por el cual si una computadora no se conecta a la red escolar por un tiempo prolongado, se bloquea. Para poder desbloquear una computadora XO, hay que descargar la lista negra (blacklist) que son la lista de mquinas que han sido robadas o extraviadas. La lista negra est conformada por dos archivos: blacklist y blacklist.sig. Tienen un perodo de validez de 6 das, por lo que si el archivo se descarg hace ms de 6 das, no servir para desbloquear la mquina. Para desbloquear la computadora XO hay que realizar los siguientes pasos: Descargar el archivo blacklistCeibal.zip [65]. Descomprimir los archivos haciendo click derecho en el archivo descargado, y luego en la opcin "Extraer aqu". Copiar ambos archivos (blacklist y blacklist.sig) en un pendrive. Colocar el pendrive en uno de los puertos USB de la XO y encenderla. La mquina comenzar el proceso de inicio y se desbloquear automticamente. Puede tardar unos minutos. No quitar el pendrive hasta que la mquina haya iniciado normalmente. Sobre la blacklist: La XO tiene una forma de identificacin a travs de un nmero de serie. En base a ese nmero se cre un sistema de seguridad que permite bloquear las XO en caso de robo o extravo e ingresar en la lista negra los nmeros de serie de las mquinas denunciadas. Por tal motivo la lista negra slo podr desbloquear aquellas mquinas que no figuren como hurtadas o extraviadas. Si alguien pierde la computadora XO debe realizar la denuncia y posteriormente ingresar el reclamo a travs del 0800 2342. En ese caso el nmero de serie correspondiente a la XO se ingresar en la lista.
B.2 Flasheo de la XO El flasheo de la computadora consiste en eliminar todo el contenido de la memoria Flash y reestablecer la imagen original de la computadora. La imagen contiene todos los archivos y directorios que conforman el sistema operativo, adems de las actividades que vienen instaladas por defecto en la imagen. _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 62 de 73 Centro Ceibal Uruguay
Hay que descargar los archivos de la imagen, que son al da de escribir la gua (pueden cambiar): uy802c.img [65] y fs.zip [65]. tambin hay que tener el arhivo blacklistCeibal.zip [65] que hay que descomprimir (contiene los archivos backlist y blacklist.sig). Se copian todos estos archivos a un pendrive. En el mismo deben estar los siguientes archivos: uy802c.img fs.zip (no descromprimirlo, dejarlo as como est). blacklist blacklist.sig
Conectar el pendrive al puerto USB con la XO apagada y conectada al cargador. 1. Encender la XO y presionar al mismo tiempo los 4 botones de juegos que se encuentran sobre el botn de encendido. No se debe quitar el pendrive. 2. Aparecer el siguiente mensaje: "Release the game keys to continue". Soltar los botones. La pantalla quedar completamente cuadriculada y se iniciar el proceso de flasheo automticamente. 3. Al terminar este proceso la XO se reinicia sola. Luego comenzar a cargar los crculos alrededor de la X (esto puede tardar algunos minutos). No quitar el pendrive del puerto USB. 4. En la pantalla aparecer para que se ingrese el nombre del usuario. Esto indica que la XO qued lista para su uso. Aqu ya se puede retirar el pendrive. Nota: Si hubieran archivos creados por el usuario es necesario respaldar los mismos en un pendrive porque el flasheo de la computadora es similar a formatear la mquina, dejndola como viene instalada por defecto.
Apndice C - Distribucin de Actividades

Los contenidos desarrollados como actividades o aplicaciones web pueden dejarse disponibles a travs de cualquier sitio en Internet. Las actividades se deben empaquetar en archivos con extensin .xo, de esta manera al descargarse los archivos desde la XO, la actividad se instalar simplemente haciendo click en la entrada del Diario correspondiente. Si desde el browser se accede a una URL que contiene el archivo .xo, el mismo se descarga y se instala automticamente.
C.1 Distribucin En esta seccin se describen las formas de distribucin de un determinado contenido que actualmente estn disponibles. Los contenidos desarrollados para Ceibal se pueden distribuir de la siguiente manera: 1. 2. 3. 4. A travs de un Sitio web. A travs del Portal Ceibal o de Sugar Labs. Mediante una Actualizacin de XO. Utilizando un dispositivo de almacenamiento externo.
A continuacin se detallan cada una de las alternativas. C.1.1 Sitio Web Cualquier desarrollador puede poner online un sitio web y que las computadoras se conecten a su sitio para descargar el archivo .xo. Al hacer esto, el programa es descargado e instalado automticamente en la computadora.
C.1.2 Portal Ceibal Una alternativa particular para a la publicacin contenido en Internet es la utilizacin del Portal Ceibal (www.ceibal.edu.uy). Para poder acceder al mismo es necesaria la aprobacin del contenido por parte de los Contenidistas del sitio.
C.1.3 Repositorio de actividades de Sugar Labs Otra alternativa particular es la que utiliza la comunidad Sugar, mediante el repositorio de actividades [18]. Este repositorio permite clasificar las actividades por distintas categoras y versiones del entorno Sugar. Tiene una interfaz muy intuitiva por lo que es utilizado por nios de distintos pases para descargar sus actividades. Tiene la ventaja de que detecta _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 64 de 73 Centro Ceibal Uruguay
automticamente la versin de entorno Sugar que est utilizando el nio, para ofrecerle versiones de actividades compatibles con la del entorno.
C.1.4 Actualizacin de XO Ceibal cuenta con un mecanismo de distribucin de contenidos, a travs de los servidores en las escuelas, mediante actualizaciones al sistema operativo de cada XO. La utilizacin de este mecanismo requiere la aprobacin de Ceibal y tiene restricciones en cuanto al tamao que las actualizaciones pueden tener, de manera de proteger la red de posibles saturaciones (ver Datos auxiliares ms adelante).
C.2 Dispositivo de almacenamiento El archivo del proyecto .xo tambin se pueden instalar desde un dispositivo externo (pendrive o tarjeta de memoria SD). El contenido del dispositivo se puede copiar al Diario y desde all, haciendo click en la entrada correspondiente, instalar a la actividad en la mquina.
C.3 Datos auxiliares A continuacin se detalla informacin a tener en cuenta a la hora de desarrollar para la XO: Espacio de la computadora XO: Espacio mximo de almacenamiento: 1 GB. Espacio ocupado por el sistema operativo: 420 MB. Conexin en la escuela: La tasa de bajada en las escuelas varia fuertemente segn el tipo de conexin a internet con que la misma cuente, a modo de referencia se puede utilizar: Velocidad de bajada promedio: 25 Kb/s por mquina. Tamao de actualizaciones: Promedio: por debajo de 1 MB. Mximo: 20 MB.
Referencias
[1] Portal del Plan Ceibal en Uruguay. http://www.ceibal.edu.uy/ [2] Sitio Web de OLPC. http://www.laptop.org [3] The OLPC Wiki. http://wiki.laptop.org [4] XO: The Children's Machine. http://wiki.laptop.org/go/XO:_The_Children's_Machine [5] Caractersticas del Display. http://wiki.laptop.org/go/Display [6] Especificaciones de Hardware de la computadora XO-1. http://wiki.laptop.org/images/7/71/CL1A_Hdwe_Design_Spec.pdf [7] Especificaciones de Hardware de la computadora XO-1.5. http://wiki.laptop.org/images/f/f0/CL1B_Hdwe_Design_Spec.pdf [8] Caractersticas de la Cmara. http://www.ovt.com/products/sensor.php?id=74 [9] Human Interface Guidelines Sugar Labs. http://wiki.sugarlabs.org/go/Human_Interface_Guidelines [10] Sonido en la computadora XO. http://wiki.laptop.org/go/Sound [11] Video en la computadora XO. http://wiki.laptop.org/go/Video [12] Especificacin del formato OGG. http://www.vorbis.com/ [13] Lenguaje de Programacin Python. http://www.python.org/ [14] Biblioteca Pygame. http://pygame.org/ [15] Biblioteca Simple DirectMedia Library (SDL). http://www.libsdl.org/ _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 66 de 73 Centro Ceibal Uruguay
[16] Biblioteca PyGTK. http://www.pygtk.org/ [17] Gua de Estilo para el Cdigo Python. http://www.python.org/dev/peps/pep-0008/ [18] Actividades Sugar. http://activities.sugarlabs.org/es-ES/sugar/ [19] Extender Python con C++. http://wiki.laptop.org/go/Extending_Python_with_C%2B%2B [20] Actividad Gcompris. http://wiki.laptop.org/go/GCompris [21] Actividad Scratch. http://activities.sugarlabs.org/es-ES/sugar/addon/4249 [22] Google Pacman, juego HTML5. http://html5games.net/game/google-pacman/ [23] BioLab Disaster, juego HTML5. http://www.phoboslab.org/biolab/ [24] Impact HTML5 Game Engine. http://impactjs.org/ [25] Framework HTML5 Karma. http://karma.sugarlabs.org/ [26] Sitio de desarrollo de Ceibal. https://desarrollo.ceibal.edu.uy/ [27] Metodologa de desarrollo Scrum. http://es.wikipedia.org/wiki/Scrum [28] Fundamentals of Game Development, Heather Maxwell Chandler. http://www.jblearning.com/catalog/9780763778958/ [29] Testing de Videojuegos. http://en.wikipedia.org/wiki/Game_testing [30] DCON Display Controller. http://wiki.laptop.org/go/DCON
[31] Sistema de Audio AC'97 de Intel. http://en.wikipedia.org/wiki/AC'97 [32] Chip controlador de red inalmbrica. http://wiki.laptop.org/go/88W8388 [33] Laboratorio Tecnolgico del Uruguay. http://www.latu.org.uy [34] Sugar Labs. http://wiki.sugarlabs.org/ [35] Normas de Accesibilidad. http://wiki.laptop.org/go/Accessibility [36] Lenguaje Javascript. http://es.wikipedia.org/wiki/JavaScript [37] Formatos de Imgen. http://wiki.laptop.org/go/Image_file_formats [38] Lenguaje C++. http://es.wikipedia.org/wiki/C%2B%2B [39] Beginning Game Development with Python and Pygame: From Novice to Professional. http://www.amazon.com/Beginning-Game-Development-Python-Pygame/dp/1590598725 [40] Game Programming With Python. http://www.amazon.com/Game-Programming-Python-Development/dp/1584502584 [41] Focus on SDL. http://www.amazon.com/Focus-Premier-Press-Game-Development/dp/1592000304 [42] PGU Python Game Utilities. http://code.google.com/p/pgu/ [43] Box2D. http://www.box2d.org/ [44] PyBox2D. http://code.google.com/p/pybox2d/ [45] Box2DFlashAs3. http://box2dflash.sourceforge.net/
[46] Boost C++ libraries. http://www.boost.org/ [47] Eclipse IDE. http://www.eclipse.org/ [48] Pydev. http://pydev.org/ [49] IDLE. http://docs.python.org/library/idle.html [50] Microsoft Visual C++. http://msdn.microsoft.com/en-us/visualc/default.aspx [51] Eclipse CPP. http://www.eclipse.org/downloads/ [52] Xcode. http://developer.apple.com/technologies/tools/xcode.html [53] Dirty Rectangles en Pygame. http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.RenderUpdates [54] Discucin de Dirty Rectangles en la lista Pygame. http://archives.seul.org/pygame/users/Apr-2006/msg00216.html [55] Asteroid Zone J2ME Tcnicas de Optimizacin. http://jfdoue.free.fr/developers.html [56] Subversion. http://subversion.apache.org/ [57] Tortoise SVN. http://tortoisesvn.tigris.org/ [58] Mantis Bugtracking System http://www.mantisbt.org/ [59] sugar.datastore. http://wiki.laptop.org/go/Sugar.datastore.datastore [60] Sistema de Seguridad Rainbow. http://wiki.laptop.org/go/Rainbow [61] Creacin de una Actividad. http://wiki.laptop.org/go/Activity_tutorial _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 69 de 73 Centro Ceibal Uruguay
[62] Tutorial sobre Desarrollo de Actividades. http://en.flossmanuals.net/ActivitiesGuideSugar [63] Crear una Actividad Ceibal Jam. http://wiki.laptop.org/go/Ceibal_Jam/Aplicaciones [64] Making Sugar Icons. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Making_Icons [65] Imgenes de XO y archivo de lista negra de Plan Ceibal. https://desarrollo.ceibal.edu.uy/projects/infogeneral/wiki/Recursos [66] Jhbuild. http://wiki.sugarlabs.org/go/Development_Team/Jhbuild [67] Instalacin y uso de Jhbuild. http://ceibaljam.org/?q=node/334 [68] Manual Bsico de uso de XO. http://www.impo.com.uy/descargas/manual_xo_web%20.pdf [70] Proanima - Cluster de Empresas de Animacin y Videojuegos de Uruguay. http://www.proanima.org.uy/ [71] ADVA Asociacin de Desarrolladores de Videojuegos Argentina. http://www.adva.com.ar/ [72] ABRAGAMES - Associao Brasileira das Desenvolvedoras de Jogos Eletrnicos . http://www.abragames.org/ [73] International Game Developers Association. http://www.igda.org/ [74] Gamasutra The Art & Business of Making Games. http://www.gamasutra.com/ [75] Foro Uruguay Gamer. http://foro.uruguaygamer.com [76] Ceibal Jam. http://ceibaljam.org [77] Mad Dog Production. http://maddogproduction.blogspot.com/
[78] Experiencia de CeibalJam en el desarrollo de juegos para la XO: http://wiki.laptop.org/go/Ceibal_Jam/DesarrolloJuegos [79] Lista de Correo de la Comunidad de desarrolladores OLPC. http://lists.laptop.org/listinfo/devel [80] Lista de Correo de la comunidad de Desarrolladores Sugar. http://lists.sugarlabs.org/listinfo/sugar-devel [81] List de Correo de la comunidad de OLP-Uruguay (Ceibal Jam). http://lists.laptop.org/listinfo/olpc-uruguay [82] Otras listas de inters de comunidad OLPC. http://lists.laptop.org/ [83] Otras listas de inters de comunidad Sugar. http://lists.sugarlabs.org/ [84] Especificacin del Navegador Web de Sugar. http://wiki.laptop.org/go/Browse [85] Recursos para el desarrollo en Sugar. http://wiki.sugarlabs.org/go/Activity_Team/Resources [86] Libros de Python sugeridos en ceibal Jam. http://ceibaljam.org/drupal/?q=python [87] Invent Your Own Computer Game with Python. http://inventwithpython.com/ [88] Hardware de las computadoras XO. http://wiki.laptop.org/go/Hardware [89] Introduccin a la Programacin para XO Ceibal Jam. http://ceibaljam.org/?q=node/87 [90] PNG Tools. http://pmt.sourceforge.net/ [91] Python Speed. http://wiki.python.org/moin/PythonSpeed [92] Python Performance Tips. http://wiki.python.org/moin/PythonSpeed/PerformanceTips [93] Pygame en la XO. http://wiki.laptop.org/go/Pygame _____________________________________________________________________ Anexo Prctico para la Gua de Produccin v1.0 Pg. 71 de 73 Centro Ceibal Uruguay
[94] OLPC Games Wrapper http://wiki.laptop.org/go/Pygame_wrapper [95] Developers Manual OLPC. http://wiki.laptop.org/go/Developers [96] Muchos Articulos de uso de la XO y Otros. http://olpc-france.org/wiki/index.php?title=Explorations [97] Reduca Wiki. http://www.reducativa.com/wiki2/index.php?title=Proyecto_OLPC_-_Plan_Ceibal [98] Programming Linux Games. http://www.nostarch.com/plg.htm [99] Emulador QEMU. http://wiki.qemu.org/Main_Page [100] Sugar on a Stick. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick [101] AI Depot: FSM. http://ai-depot.com/FiniteStateMachines/FSM.html [102] Artificial Intelligence in Videogames http://en.wikipedia.org/wiki/Artificial_intelligence_%28video_games%29 [103] Design and User Experiece Library v 2.0. http://library.forum.nokia.com/index.jsp [104] Manual de Instalacin de Actividades de Plan Ceibal http://www.ceibal.edu.uy/UserFiles/P0001/Image/contenidos/pdfs/areatecnica/diferentesm anerasdeinstalaractividades.pdf [105] Formato de Video OGV. http://en.wikipedia.org/wiki/File:Video_xo.ogv [106] Instalacin de Firefox y Java en la XO. http://www.marcosorfila.com/site/java-applets-in-the-olpc-xo-laptop/?lang=es [107] Imgenes de OLPC. http://download.laptop.org/ [108] Virtual Box. http://wiki.laptop.org/go/VirtualBox
[109] Motor 3D por Software. http://code.google.com/p/mic3d/ [110] Comandos Linux para usar en la Terminal. http://wiki.laptop.org/go/Terminal_Activity [113] Proyecto Rayuela http://proyectorayuela.org.uy/

Guia de Produccion 1 0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guia de Produccion 1 0

Hochgeladen von

Copyright:

Verfügbare Formate

ANEXO PRCTICO

Anexo Prctico para la Gua de Produccin Versin: 1.0

Contenido Seccin 1 Introduccin y Proceso de Produccin

Seccin 2 Desarrollo de Actividades y Videojuegos

Seccin 3 Testing y Distribucin de Actividades

Captulo 2 - Proceso de Produccin

Fig. 1: Un pxel refleja la luz ambiente y tambin transmite luz de backlight.

Fig. 2: Vista de la pantalla al microscopio.

Fig. 3: Esquema diagonal de los pxels.

Fig. 4: Funcionamiento del Display en modo Blanco y Negro.

Captulo 4 - Desarrollo de Actividades y Juegos

// Chequear colisiones entre objetos, destruir o crear objetos nuevos, etc.

Captulo 5 - Limitaciones de la Computadora XO y Optimizaciones

Captulo 6 - Normas de Usabilidad y Testing

Fig. 10: Flujo de Pantallas Sugeridas en el Documento de Usabilidad de Nokia [103].

Apndice A - Cmo se Construye una Actividad

Apendice B - Desbloqueo de las XO y Flasheo

Apndice C - Distribucin de Actividades

Das könnte Ihnen auch gefallen