Un proceso corto e introductorio al desarrollo de videojuegos

Transcripción

Un proceso corto e introductorio al desarrollo de videojuegos
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
1
Un proceso corto e introductorio al desarrollo
de videojuegos
Pablo Figueroa, Nicolás Mendoza
Abstract—En este artículo se presenta un proceso corto para el
desarrollo de videojuegos casuales con una duración estimada de
2 semanas. El objetivo del proceso es construir un prototipo
pulido de un videojuego casual con al menos 1 nivel. Se
introducen terminus utilizados comunmente dentro del
desarrollo de videojuegos, se dan ejemplos del proceso, se dan
algunos datos del context colombiano en cuanto al desarrollo de
videojuegos y finalmente se habla del proyecto DAVID.
Términos clave—Videojuegos, videojuegos casuales, proceso de
desarrollo, DAVID.
I.
H
INTRODUCCIÓN
ace ya varias décadas, la humanidad se ha encargado de
crear, establecer y soportar una industria: la de los
videojuegos. Ya desde 1947, había personas que se las
ingeniaron para crear interacción con una pantalla, como lo es
el aparato de Thomas Tolivan Goldsmith Jr. En ese entonces
no se pensaba en los gráficos alcanzados por las consolas
modernas, apenas se proyectaba un haz de luz con la ayuda de
la tecnología usada en ese entonces para ver imágenes de radar
en la segunda guerra mundial. No se pensaba en pipelines de
creación de assets como se piensa hoy en día, en vez de eso se
pensaba en como hacer un circuito que permita cambiar de
forma interactiva lo que se proyecta en la pantalla.
Desde ese entonces estamos pensando en formas de
divertirnos interactivamente a través de aparatos electrónicos,
hasta tal punto que hoy en día la industria de videojuegos es
más grande que otras industrias de entretenimiento como el
cine. Muchas cosas han cambiado desde la epoca en la que
Thomas Tolivan Goldsmith Jr construyó y patentó su
máquina, sin embargo algo que no ha cambiado, es que la
creación de videojuegos representa un desafío interesante y
puede resultar y su desarrollo puede ser una actividad muy
divertida de realizar.
Hoy en día ya no es un desafío técnico nada más, los
equipos de desarrollo de los videojuegos modernos requieren
de una gran variedad de disciplinas que permiten interactuar
con un amplio rango de personas en donde la sola
organización del trabajo se convierte en una tarea
indispensable y desafiante. Además de aprender sobre
diversos temas, el desarrollo de videojuegos permite que las
personas involucradas apliquen teorías y conocimientos que
nunca pensaron utilizar fuera de la academia, esto incluye
campos del conocimiento que pueden ir desde la antropología
hasta la inteligencia artificial.
El objetivo de este artículo es presentar una introducción al
desarrollo de videojuegos en donde se ilustran algunos
conceptos básicos y se presenta un proceso de desarrollo
enfocado en la producción de juegos casuales, con una
duración esperada de no más de dos semanas. El proceso
pretende tener como producto un juego casual corto que pueda
ser usado como base para un proceso iterativo más largo en
donde se refine y añada más contenido a la base producida. Se
plantean una serie de entregables como el “pitch” y el “one
pager” por medio de los cuales se pueda plasmar la idea
central del videojuego a crear y se pueda llevar la trazabilidad
de lo creado y se pueda tener una idea del rumbo deseado para
el videojuego.
II. ALGUNOS CONCEPTOS
Como en cualquier otra disciplina, dentro de la industria de
videojuegos se usan conceptos muy útiles dentro del proceso
de desarrollo ya que permiten nombrar e identificar nociones
que ayudan a definir rumbos dentro del proceso, en su mayoría
son términos provenientes del inglés y en ocasiones difícil de
traducirlos por lo tanto los dejaremos en su lengua original. A
continuación se explorarán algunos conceptos claves a la hora
de hablar de desarrollo de videojuegos.
Assets: Son todos aquellos artefactos que componen el
videojuego. Estos artefactos son, en su mayoría, creaciones
artísticas en distintas áreas como los son la animación, la
ilustración, el modelado, la música, la actuación en voces,
entre otras. Estos artefactos se encuentran en su forma final ,
es decir su forma lista para ser usada en el videojuego, por
ejemplo una animación 2D por lo general estará exportada en
un sprite sheet o sprite atlas en un formato reconocible por el
motor de juegos a utilizar. En algunas plataformas de
desarrollo, el código es tratado como un asset del videojuego
gracias a la modularidad de algunas de estas plataformas.
Mecánicas: Las mecánicas pueden ser referidas como el
conjunto de reglas construidas dentro del juego que se
encargan de darle vida a los retos y objetivos encontrados
dentro del mismo. Pueden ser tan complejas como se quiera
pero en los videojuegos casuales por lo general son sencillas
para el usuario.
Game engines: Es un software especializado para la
creación y desarrollo de videojuegos. Ofrecen funcionalidades
de alto nivel como la detección de colisiones, motores de
física, visualización de escenas, modelos de iluminación, etc.
Por lo general trabajan con interfaces de programación de bajo
nivel como OpenGL, DirectX, Canvas (en el caso de HTML5)
entre otras. La ventaja que ofrecen es brindarle al
desarrollador un conjunto de herramientas y funcionalidades
que usualmente se necesitan en el desarrollo de videojuegos de
forma tal que no sea necesaria una implementación de
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
funcionalidades complejas que no son triviales en su
implementación.
Prototipos físicos: Es un prototipo rápido del videojuego a
desarrollar hecho a partir de materiales físicos, idealmente
baratos y fáciles de manipular. La idea detrás de los prototipos
físicos es validar una idea de juego de forma rápida para
determinar tempranamente si un videojuego va a ser divertido
o no. Se realizan pruebas con posibles usuarios del videojuego
para ver las reacciones de los mismos ante el juego y recibir
críticas para mejorar el concepto antes de comenzar con la
implementación digital.
Gameplay: Es una palabra difícil de traducir al español,
más aún su definición en inglés puede no ser tan clara en
ocasiones. En general el gameplay es el conjunto de
mecanicas, temáticas, experiencias y artefactos ensamblados
dentro de un videojuego que le permiten al jugador interactuar
con el juego de cierta manera. El gameplay no suele definirse
por la calidad gráfica, sonora o musical del juego. Ciertamente
estas cualidades añaden mucho a la experiencia general del
usuario pero en general se puede generar un mismo gameplay
con distintos estilos gráficos.
Brainstorming: El concepto de brainstorming se aplica a
muchas industrias, sin embargo el objetivo principal a lo largo
de cualquier industria es el mismo: producir muchas ideas, y
documentarlas para que luego sea evaluada su viabilidad. En
videojuegos será una sesión grupal en donde los miembros que
participen en la sesión pensarán en ideas de mecánicas,
historia, arte, público objetivo y demas para armar un
videojuego.
HUD: El HUD (Heads-up display) es una colección de
información mostrada al jugador que le indica el estado del
juego al jugador. La información mostrada depende
fuertemente del juego y de lo que se considere necesario saber
en determinado momento. Ejemplos de información mostrada
en el HUD incluyen la cantidad de vidas restantes, tiempo
restante, mapa, etc. Dentro de este artículo vamos a considerar
los menús y demás navegaciones externas al juego como parte
del HUD ya que muchas veces pueden confundirse.
2
Fig 1. Proceso corto de desarrollo
En la figura anterior, se muestra el proceso mencionado
desde el nivel más alto, es decir, se muestra cada una de las
etapas. Como se puede ver, es un proceso sencillo y lineal
dividido en 4 etapas, no hay ciclos entre cada etapa ya que
muy difícilmente se lograría completar el proceso en 2
semanas si se agregan ciclos dentro del proceso. A
continuación se explicará cada etapa del proceso.
Desarrollo creativo: El objetivo de esta etapa, es
conceptualizar la idea general del juego y plasmarla en
documentos iniciales y un prototipo. Se divide el equipo en 2
grupos: equipo de game design y equipo de negocio.
Fig
2.
Etapa
de
desarrollo
creativo
vista
en
su
totalidad
Se analizará la etapa por partes, en donde se explicarán las
actividades y los entregables mostrados allí.
III. PROCESO DE DESARROLLO
El proceso de desarrollo presentado en este artículo permite
desarrollar juegos casuales durante un periodo corto, de
alrededor de 2 semanas. Se pretende que al final del proceso
se tenga al menos un prototipo de un videojuego que ilustre
los conceptos principales del videojuego, incluyendo assets
artísticos y sonoros. Podría decirse que se espera al menos el
primer nivel del videojuego.
Fig 3. Primera parte de la etapa de desarrollo creativo
La primera parte del proceso comienza con la
conceptualización de la idea. El objetivo de la actividad es
aterrizar la idea que se tenga del videojuego que se quiera
crear para discutirla con el equipo inicial y plasmarla en 2
documentos cortos. Es importante poder plasmar la idea en
estos documentos porque en la elaboración de estos, el equipo
se pone de acuerdo en muchos aspectos que inicialmente
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
pueden estar pensados de una forma muy diferente para cada
miembro del grupo. Adicionalmente uno se puede dar cuenta
si hacen falta personas en el equipo establecido inicialmente.
Los documents a producir son el “Pitch document” y el “One
pager”.
El “Pitch document” es un documento corto que ilustra de
una manera muy gráfica la idea general y las características
importantes del juego. El objetivo del documento es
presentarlo a posibles inversionistas, por lo tanto se deben
plasmar los puntos clave del juego, factores diferenciadores y
razones por las cuales sería un proyecto rentable. Este tipo de
documento se puede crear a manera de presentación.
El one pager es un documento que reúne la información
plasmada en una descripción corta del videojuego (párrafo que
ilustra el juego en términos generales) y el “Pitch document”,
complementando de tal forma que se pueda tener un plan
inicial de desarrollo. En este documento debe estar el género
del juego, descripción del gameplay, características
principales, el ambiente, la historia a un alto nivel, usuario
objetivo, plataformas objetivo, calendario de desarrollo
estimado, análisis de mercado, equipo de trabajo requerido y
análisis de riesgo (dificultades posibles). Como su nombre lo
indica, lo ideal es que esta información esté plasmada en una
página, por lo tanto se debe ser lo más breve posible.
Una vez se conceptualice el proyecto, se obtiene una visión
más clara del proyecto, se puede ver con más claridad los roles
necesarios y la necesidad de buscar más gente, es por eso que
se procede a conformar el equipo. Esto significa asignar roles
dentro del equipo, por ejemplo, si hay varios programadores
una buena práctica puede ser dividir responsabilidades entre
ellos como la programación del HUD del juego o la
implementación de una mecánica específica.
3
Fig 5. Prototipado y pruebas.
En la actividad de “Vender la idea”, se pretende mostrar la
idea a un tercero, idealmente un inversionista dispuesto a
invertir en el proyecto pero si no es el caso lo ideal es que una
persona critique el proyecto para recibir retroalimentación
desde un punto de vista externo. Después se evalúa si la
propuesta presentada es válida o no. En caso de haber cambios
profundos, se devuelve a la conceptualización del proyecto.
Cuando se apruebe la idea, se procede a realizar un
prototipo digital muy rápidamente. La idea de este prototipo es
validar la idea clave del videojuego de la forma más rápida
posible para poder probarla con posibles usuarios. La idea es
captar la mayor cantidad de información posible para tenerla
en cuenta a la hora de entrar en la etapa de desarrollo.
Fig 4. Actividades de negocio.
Una vez se haya clarificado un poco la experiencia que se
quiere transmitir con el videojuego, es bueno preguntarse cual
va a ser el modelo de negocio del videojuego, su posible
audiencia y los números que se puedan necesitar o lograr. Esta
es una buena actividad a realizar desde una etapa temprana ya
que muchas veces el gameplay va a ser afectado por el modelo
de negocio que se escoja. Con una buena propuesta de
negocio, se puede conseguir financiación para llevar a cabo el
proyecto a una escala más grande.
Fig 6. Creación del documento de diseño.
Finalmente se finaliza la etapa con la creación del “Game
Design Document” inicial. En este documento se almacena
toda la información generada y recopilada hasta el momento y
se sientan las bases para describir el gameplay principal.
Adicionalmente se listan los assets que van a ser necesarios
para el desarrollo del videojuego.
El “Game Design Document” o “GDD” es un documento
que contiene todos los aspectos que describen el juego de
forma detallada. Es un documento que se debe actualizar de
forma continua durante todo el ciclo de desarrollo. Esta
versión inicial contiene un índice que organice todos los
aspectos del juego. En su primera versión, el documento debe
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
4
describir el gameplay, los personajes, la historia, los aspectos
técnicos y demás información que el equipo considere
necesaria para comenzar con la producción del videojuego.
Producción: Durante la etapa de producción se lleva a cabo
todo el desarrollo del videojuego. El equipo se divide en 4
grupos: artistas, programadores, músicos y equipo de game
design. Durante esta etapa, es muy importante que todo el
equipo de trabajo se sincronice para ponerse de acuerdo con el
trabajo. La forma para lograr esto, es una buena lista de assets.
Fig 7. Etapa de producción vista en su totalidad.
Comenzaremos con la parte más baja del diagrama con el
equipo de game design.
Fig 8. Primeras actividades del proceso.
Ya teniendo un GDD con su estructura base, se profundiza
en los detalles de diseño del juego y se documenta dicha
información en el mismo GDD. El diseño se hace a tres
niveles: diseño de nivel, diseño de gameplay y diseño de
HUD. En este diseño se describe básicamente todo lo que se
va a desarrollar a un nivel de detalle suficiente para que todo
el equipo de desarrollo entienda lo que se debe hacer, es decir
que entienda el producto final.
Una vez el diseño se encuentre completo, el equipo produce
una “Media list” y se consigna en el GDD. La media list es
una lista que contiene todos los assets necesarios para la
producción del juego incluyendo las descripciones que el
equipo considere necesarias, por ejemplo si es un juego 2D se
puede especificar la cantidad de frame para cada sprite sheet
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
5
que reproduzca una animación, o se puede decir cuales
animaciones deben encajar con otras.
Teniendo una media list, se procede a crear una jerarquía de
directorios en donde se van a consignar los assets del juego
para que sean visibles a todo el equipo. La idea de este
directorio es compartir lo que los otros miembros del equipo
crean mediante herramientas como Dropbox, repositorios
SVN, repositorios Git, o lo que el equipo desee utilizar. Lo
importante es que la estructura esté de acuerdo con lo
acordado en la media list de forma tal que el equipo sepa
dónde se encuentran los assets.
Fig 10. Actividades del equipo de músicos (parte 2)
Fig 9. Actividades del equipo de músicos (parte 1)
Tomando la media list como base, el equipo de producción
musical se encarga de producir los assets sonoros necesarios.
Estos pueden ser voces, foley (sonidos de ambiente y efectos
de sonido) o música. Lo que salga de esta producción debe
integrarse en la estructura de carpetas que se haya hecho para
que el resto del equipo las pueda ver. Posteriormente se hace
una verificación de los assets sonoros producidos, chequeando
que se tenga lo necesario para el juego y la calidad de los
archivos de audio sea la requerida por el equipo. Cada vez que
se producen y verifican los audios, se debe actualizar la media
list para notificar cambio o información útil para el equipo en
cuanto a la producción Sonora, por ejemplo, marcar como
listos ciertos elementos en la lista.
Los archivos finales se comparten en la jerarquía de
directorios creada. En este proceso algún miembro del equipo
puede detectar errores en los archivos, en dado caso habría que
corregirlos en las actividades de producción. Finalmente, el
equipo genera un reléase del videojuego para ver los assets
producidos en vivo.
Lo ideal es tener una configuración en donde el motor de
videojuegos utilizado le permita generar ejecutables del juego
a los artistas y músicos, de forma tal que no dependan del
equipo de programadores para ver en el juego lo que han
producido. Para esto es clave que el equipo de programación
proporcione scripts o simplemente le enseñe al resto del grupo
qué se debe hacer para generar un release.
Fig 11. Actividades del grupo de artistas
De la misma forma que se hizo con el grupo de producción
musical, las personas encargadas de la producción de assets
gráficos dividen la producción de sus assets en varias
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
categorías. Estas son: creación de personajes, creación de
escenarios, creación de elementos complementarios, creación
de animaciones y creación de arte para HUD. Posterior a la
creación de dichos elementos, se realiza la verificación,
integración y generación del ejecutable de una manera similar
a las actividades hechas por el grupo de músicos.
6
embargo sí es importante realizar pruebas sobre las mecánicas
más importantes, teniendo varios casos de prueba.
Fig 12. Actividades del grupo de programadores (parte 1)
El grupo de programadores divide sus actividades
principales en la programación del gameplay y en la
implementación del HUD. El grupo basa la implementación de
acuerdo con lo descrito en el GDD y se encarga de utilizar las
rutas para ubicar los assets de acuerdo a la jerarquía de
directorios establecida. De esta forma los músicos y artistas
solo ponen los assets producidos con un nombre determindado
en una carpeta determinada y el juego toma los assets
correctos automáticamente.
Fig 14. Etapa de testing vista en su totalidad.
El grupo de tester se encarga de probar el juego para
encontrar bugs (si los hay).
Fig 15. Actividades del grupo de testers.
Fig 13. Actividades del grupo de programadores (parte 2)
Despúes de haber implementado el gameplay y el HUD se
procede a verificar que su funcionamiento sea correcto, esto se
puede hacer con el método que el grupo prefiera.
En ocasiones hay que hacer ajustes específicos en el código
o en la herramienta para la correcta integración de los assets
con el juego. Para esto se realizan dos actividades en donde se
llevan a cabo estos ajustes: una para assets gráficos y otra para
assets sonoros. Estas actividades comienzan una vez se haya
completado toda la producción de assets.
Finalmente la etapa de producción termina con la
generación de un release oficial por parte del equipo de game
design.
Testing: En la etapa de “Testing” se prueba el videojuego
en diferentes facetas para probar toda su funcionalidad y
asegurarse de tener un producto de buena calidad. Dada la
naturaleza corta del proceso de desarrollo, probablemente no
se alcancen a probar todos los escenarios posibles, sin
El grupo de testers debe jugar el juego bajo diferentes
escenarios significativos para probar casos suficientes en el
juego. Si se encuentran bugs, se documenta como se produce
el error para reproducirlo de nuevo y se actualiza esta
información en la lista de bugs del videojuego. El esquipo
decide como llevar esta lista pero una buena opción es utilizar
un bug tracker como Bugzilla para llevar registro de esta
información.
Finalmente se idntifica el equipo encargado de resolver el
problema (grupo de artistas, grupo de músicos o grupo de
programadores) y se trata de resolverlo.
Despliegue y mantenimiento: En esta etapa ya se tiene el
producto desarrollado pero no se ha publicado el videojuego
en ningún lado. La idea de esta etapa es publicar el juego y
hacer un seguimiento de como lo están usando los jugadores.
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
7
rápido, se utilizaron sprites genéricos inicialmente y luego se
añadió el arte propia de Simón el bobito.
El testing se realizó de forma muy rápida por los mismo
miembros del equipo de desarrollo ya que no se contaba con
más gente disponible. Se detectaron unos cuantos bugs que
fueron corregidos y finalmente se añadieron detalles como una
pantalla de “loading”.
Los documentos de desarrollo y el producto realizado se
encuentran en el portal Juega Libre del cual se hablará en una
sección posterior.
V. CONTEXTO COLOMBIANO
Fig 16. Etapa de despliegue y mantenimiento.
Lo primero que se hace es añadir código para el
seguimiento de analytics dentro del videojuego. Es importante
añadir analytics por que le permite ver al equipo como sus
jugadores están usando lo que crearon. Esto se hace con el
objetivo de mejorar el juego en futuras iteraciones o ver en
que se falló a la hora de diseñar el juego.
Después se publica el juego en el medio deseado por el
equipo. Este medio puede ser la App Store de Apple, la tienda
Google Play, publicarlo en un sitio web, o simplemente
dárselo a conocer a familiares y amigos para que lo usen, den
sus opiniones y alimenten las estadísticas recopiladas por
medio de analytics.
Finalmente se analiza la información de la forma preferida
por el equipo. Esto dependerá fuertemente del tipo de
analytics usadas y el framework usado para recopilarlas. Un
ejemplo de esto es el “Funnel Analysis” o análisis de embudo,
en donde se plantea una ruta de acciones esperadas por el
usuario y se observa cuantas personas cumplieron o no
cumplieron cada paso.
IV. EJEMPLO
Un ejemplo del proceso descrito anteriormente lo
encontramos en el videojuego: “Simón el bobito: Reto
pastelero”. Este juego se desarrolló aproximadamente en 15
días. La premisa del juego se basa en que el pastelero del
pueblo le encarga a Simón el bobito la tarea de llevar pasteles
a sus clientes, sin embargo Simón es un niño con una
imaginación muy grande y piensa que debe atravesar un
campo de zombies para llegar a los clientes.
El desarrollo del juego comenzó con una sesión de
brainstorming en donde surgió una idea de lo que se quería
hacer. Posteriormente las ideas se aterrizaron más cuando se
realizó el pitch document, dado que se debía transmitir una
idea clara del videojuego en el documento.
Se desarrolló un prototipo físico del juego de forma muy
rápida (en 2 horas aproximadamente) y se probó la mecánica
con varias personas. Las pruebas se realizaron de una manera
muy informal ya que el objetivo era analizar los
comportamientos de las personas y ver qué tan fácil resultaba
la mecánica.
Posteriormente se comenzó el desarrollo del prototipo
digital usando un repositorio SVN con una estructura de
carpetas definida previamente. El desarrollo del prototipo fue
Durante los últimos años la industria colombiana en el
sector de la animación y videojuegos ha venido creciendo.
Año tras año se ve un incremento en el número de personas
interesadas en la creación de estos contenidos digitales. Esto
se puede ver reflejado en el número de juegos colombianos
que han sido publicados en los últimos años, algunos de los
cuales han ganado premios internacionales.
Un estudio contratado en conjunto por la Universidad de los
Andes y Proexport, realizado por el Centro Nacional de
Consultoria, muestra un poco del estado de la industria
actualmente.
VI. PROYECTO DAVID
El proyecto DAVID (Desarrollo en Animación y
Videojuegos) es un conjunto de acciones encaminadas al
apoyo del sector industrial de la animación y videojuegos en
Colombia. Es un proyecto financiado por Colciencias entre los
años 2012 y 2015, a cargo de un consorcio de 4 empresas y 4
grupos de investigación de la Universidad de los Andes.
Como producto de este proyecto, se creó el portal Juega
Libre. El cual pretende brindar tutoriales, herramientas y
procesos enfocados en el desarrollo de videojuegos con el
objetivo de crear una comunidad de desarrolladores dispuestos
a colaborar entre sí. Dentro del portal se encuentran foros
especializados por herramienta, procesos de desarrollo
documentados, catálogo de herramientas útiles en el desarrollo
de videojuegos, catálogo de videojuegos hechos usando las
metodologías propuestas en el portal, contenidos relacionados
con la industria de videojuegos y servicios para
desarrolladores.
En el catálogo de herramientas, el contenido se encuentra
categorizado según el tipo de herramienta. Cada herramienta
cuenta con su descripción, links para descargarla y tutoriales.
El objetivo del catálogo es mostrar un abanico de
posibilidades para los desarrolladores, mostrando un conjunto
de herramientas listas para ser usada en los proyectos que
deseen llevar a cabo. Cada herramienta cuenta con un foro
para el intercambio de preguntas, respuestas y opiniones.
Las personas que lo deseen, pueden subir sus juegos al
portal para que sean publicados en el mismo. La idea es que se
puedan subir los documentos de desarrollo producidos durante
el proceso de desarrollo que se llevó a cabo. Los juegos
publicados pueden ser jugados desde el portal y la descripción
del juego junto con los documentos de desarrollo pueden ser
encontrados en la página de cada juego.
> FOR CONFERENCE-RELATED PAPERS, REPLACE THIS LINE WITH YOUR SESSION NUMBER, E.G., AB-02 (DOUBLE-CLICK HERE) <
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
G. Eason, B. Noble, and I. N. Sneddon, “On certain integrals of
Lipschitz-Hankel type involving products of Bessel functions,” Phil.
Trans. Roy. Soc. London, vol. A247, pp. 529-551, Apr. 1955.
J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol.
2. Oxford: Clarendon, 1892, pp. 68-73.
I. S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange
anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New
York: Academic, 1963, pp. 271-350.
B. Smith, “An approach to graphs of linear forms,” unpublished.
E. H. Miller, “A note on reflector arrays,” IEEE Trans. Antennas
Propagat., to be published.
J. Wang, “Fundamentals of erbium-doped fiber amplifiers arrays,” IEEE
J. Quantum Electron., submitted for publication.
C. J. Kaufman, Rocky Mountain Research Laboratories, Boulder, CO,
private communication, 2004.
Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy
studies on magneto-optical media and plastic substrate interface,” IEEE
Transl. J. Magn. Jpn., vol. 2, pp. 740-741, August 1987 [Dig. 9th
Annual Conf. Magn. Jpn., p. 301, 1982].
M. Young, The Technical Writer’s Handbook. Mill Valley, CA:
University Science, 1989.
8

Documentos relacionados