> 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