Etapas dedesarrollo Eduexperts, (2019). DERECHOS RESERVADOS ©.

Podemos definir las etapas de desarrollo de juego usando los términoshabituales de Preproducción, Producción, y Postproducción. Veamosen qué consisten: PreproducciónEsta etapa corresponde más o menos al 10% o 20% del total deltiempo de desarrollo y su duración puede ir desde una semana hastaun año, dependiendo de la magnitud del proyecto. Este es el momentoen el que se realiza la mayor parte de la planeación; se definen las ca-racterísticas de nuestro proyecto, incluido el presupuesto, las fechasde entrega y el equipo de trabajo que se requerirá para su producción.En términos generales, al finalizar esta etapa se deberá tener resueltolo siguiente: - Concepto de juego. - Jugabilidad Central. - Características de Jugabilidad. - Desglose de componentes del juego. - Desglose de los alcances del proyecto.En este periodo, el departamento de Diseño comenzará a elaborar ladocumentación y también construirá prototipos que permitan validarel concepto de juego. Si las demás áreas ya están involucradas, Progra-mación puede apoyar con el prototipado o dedicarse a investigar sobrelos requerimientos técnicos del proyecto y hacer pruebas con las he-rramientas que utilizarán. El departamento de Arte trabajará de llenoen la parte de conceptualización visual.

Durante esta etapa hay una revisión constante de la información gene-rada y se realizan numerosos ajustes en la planeación, proponiendo, in-corporando y descartando componentes de juego hasta tener un plande acción que se ajuste a los tiempos y presupuestos. ProducciónEsta es la etapa en la que se aborda de lleno el desarrollo del juego. Eneste periodo es cuando se realiza la contratación del personal que hagafalta. El área de Programación se dedica de lleno a construir el progra-ma de juego. El departamento de diseño estará al tanto de la imple-mentación y generará la documentación adicional que se requiera. Elárea de Gráficos elaborará los assets finales del juego y Audio tambiénentrará en algún punto de esta etapa de producción. También, Controlde Calidad será fundamental y dictará buena parte del ritmo de trabajodel resto del equipo. Por su duración y complejidad, regularmente estaetapa se divide a su vez en otras más específicas. Vertical SlideEste es un entregable que no siempre se considera aunque en algunosestudios es una práctica habitual. Consiste en la producción de unasección del juego que contenga los componentes principales de ete.Por ejemplo, crear un solo nivel del juego que tenga una duración deunos cuantos minutos. El objetivo de esto es que sirva como guía del“look and feel” que se busca lograr para el resto del juego. Es sobretodo útil en proyectos a gran escala porque, al ser una especie de ver-sión del juego a pequeña escala, también ayuda a corroborar las esti-maciones de tiempo y a planear las fechas de entrega. Adicionalmente,puede ser usado en “pitches” para lograr una validación interna o ex-terna o incluso como un recurso para la mercadotecnia del juego.

Durante esta etapa hay una revisión constante de la información gene-rada y se realizan numerosos ajustes en la planeación, proponiendo, in-corporando y descartando componentes de juego hasta tener un plande acción que se ajuste a los tiempos y presupuestos. Pre-AlphaEsta es la etapa en la que todavía no comienzan formalmente las prue-bas al juego por parte de control de calidad pero Control de Calidaddefine su plan de pruebas de acuerdo a las características del juego. Eneste periodo se crean la la mayor parte de los ‘assets’ del juego, comomodelos 3D y su respectiva animación. Se hacen los mapas de niveles,se diseñan misiones y se realiza la parte más intensa de la programa-ción del juego. En este momento el juego todavía está sujeto a ajustesy regularmente se decide recortar contenido ya sea por cuestiones detiempo o porque se determina que no funciona adecuadamente para elconcepto de juego. AlphaA esta altura del desarrollo, la programación de los principales compo-nentes del juego ha concluido y es jugable en su mayoría. Todavíafaltan algunos ‘assets’ finales pero los controles y la funcionalidad cen-tral están completos y, por lo tanto, Control de Calidad comienza laspruebas intensivas al juego. Los cambios que puede sufrir el juego enesta etapa regularmente son mínimos y no se recomienda agregar con-tenido adicional sino limitarse a completar y pulir lo que ya se teníacontemplado con antelación, a menos que haya conflicto con lasfechas de entrega puede ser necesario eliminar o reducir algún compo-nente del juego.

BetaPara esta etapa, la programación de todos los componentes funciona-les del juego se considera completa y todos los ‘assets’ finales se hanintegrado. La producción de la mayor parte del equipo cesa y la aten-ción se centra en las pruebas y en corregir los ‘bugs’ arrojados porestas, así como estabilizar y optimizar el código. GoldUna vez que el juego ha pasado las pruebas finales se considera un pro-ducto terminado, aunque en ocasiones, falta que una entidad externasometa el juego a sus propias pruebas para dar su aprobación, comopuede ser el ‘publisher’ o la tienda en línea en la que lo publicaremos.

PosproducciónPor último, tenemos esta etapa en la que se realizan algunas tareascomo la creación de parches o el desarrollo de contenido descargable,pero también hay un par de tareas que son relevantes para finalizar elproyecto y poder pasar al siguiente. “Post-Mortem”Este se puede llevar a cabo de manera presencial y/o documental. Con-siste en una revisión de todo el desarrollo, con el fin de identificar losproblemas que surgieron en el proceso, así como los aciertos y erroresen el manejo de los mismos. También se revisa si se cumplieron los ob-jetivos planteados o si los alcances y fechas reales de entrega cumplie-ron con las estimaciones iniciales. Básicamente, el objetivo es obtenerun aprendizaje que pueda servir para futuros proyectos. “Closing Kit”Una vez que el trabajo en el juego concluye se recomienda recopilar yorganizar todo el material generado para archivarlo. Esto incluye la do-cumentación de diseño, el código, los assets finales y los archivos deaudio. Esto es muy importante en caso de que se requiera crear conte-nido adicional descargable o ante la posibilidad de desarrollar una se-cuela, una reedición o incluso una remasterización del juego.

Time Frame First PlayableEngineeringArt 12 - 18 months before code releaseDesignSound Basic functionality for a few key features is in to demonstrate very basic gameplay.LocalizationProduction Two or three key art assets are created andQA viewable in the build. The assets demonstrate the look and feel of the final version of the game. Basic features are defined; key gameplay mechanics have basic documentation and a playable prototype if possible. The sound of the game is determined, including voiceover music, and sound effects. Samples are available to communicate the sound vision of the game. Work with publisher to determine which languages are needed. Select lozalization vendor and send the vendor design documents and first playable. Define localization pipelina. Basic game requirements and game play are completed. Can test game against the first playable milestone deliverables defined in the game requirements phase.

Time Frame AlphaEngineeringArt 8 - 10 months before code releaseDesign Key gameplay functionality is in for all game features.Sound Features work as designed, but may be adjusted andLocalization changed based on feedback. Game runs on target hardware platform.Production Assets are 40-50% final, with placeholder assets forQA the rest of the game. All design documentation is completed. Feature implementation is in progress. 40-50% of design production tasks are completed. Major areas of game are playable as designed. 40-50% of sound effects are working. Voiceover design is in progress. Placeholder VO files are recorded. Music is in process of being composed. Work with vendor to determine asset deliver schedule. Send glossaries, cheat codes, and walkthroughs to vendor. Test localization pipeline to ensure translations are displayed correctly. Full production has begun. The game requirements and game plan are fully completed and approved. If working with licenses, all licenses are secured and an approval process is in place. Game is now playable (a full game), although there are some rough edges and holes in some of the functionality. Play testing can begin. Can test against the alpha deliverables expected fot this milestone.

Time Frame Code FreezeEngineeringArt 3-4 months before code releaseDesignSound Code complete for all features. Only bug fixingLocalization from this point forward. No newProduction features are added unless approved by seniorQA management. Assets are 80-90% final, with placeholder assets for the rest of the game. Game is 80-90% playable. Play testing feedback is being incorporated. Final voiceover is recorded and in game. Final music is in the game. Sound effects are 80-90% implemented. Final text and VO assets are sent for translation. Translations are completed and returned to developer for integration. Localizations have started. Manual is in process of being written. Marketing assets are being generated. Test plan is 100% complete. Full game functionality can be tested and bugged. Play testing continues. Can test against the code freese milestone deliverable first.

Time Frame BetaEngineeringArt 2-3 months before code releaseDesignSound Code complete. Only bug fixing from this pointLocalization forward.Production All art assets are final and working in game. Only majorQA bug fixes from this point forward. All design assets are final and working in the game. Only major bug fixes from this point forward. Minor gameplay tweaks can be done, based on play test feedback. All final sound assets are in and working in the game. Final language assets are integrated into the game. Linguistic testing is completed. Send builds to appropiate age rating goals to secure final rating. Localization is complete. Only bug fixes from this point forward. Manual is complete. External vendors are finished with work. All aprovals for licenses are secured. Devlopment team can start rolling off project. All aspects of game can be fully tested and bugged. Some play testing continues in order for design to put the final polish on the game.

Time Frame Code ReleaseEngineeringArt 2-3 First code release candidate available to QA 3Design weeks before final code release deadline.SoundLocalization Full code freeze. During this phase, only crash bugs canProduction be fixed. Critical bugs can be fixed with approval.QA Full art freese. No art fixes unless it is to fix a crash bug. Full design freeze. No design fixes unless it is to fix a crash bug. Full sound freeze. Full localization freeze. All production tasks are completed. If submitting game to console manufacturer, the submission forms are filled in and ready to go. Test code release candidates for any crash bugs that will prevent the game from shipping.

Time Frame Third-Party Submission - CONSOLE ONLYEngineeringArt Submit code release candidate at least 8-12 weeksDesign before desired ship date.SoundLocalization Code final. If submission is rejected, only specific bugsProduction as requested by the third party will be fixed forQA re-submission. Art final. If submission is rejected, only specific bugs as requested by the third party will be fixed for re-submission. Design final. If submission is rejected, only specific bugs requested by the third party will be fixed for re-submission. Sound final. If submission is rejected, only specific bugs requested by the third party will be fixed for re-submission. Localization final. If submission is rejected, only specific bugs requested by the third party will be fixed for re-submission. Production final. Only managing submission process. Testing continues on submission candidate(s) until game receives final approval.

“Pipeline”Este es un término que de manera literal se traduciría como “tubería”, yhace referencia al flujo de trabajo. Es decir, el problema de producir unjuego no solo tiene que ver con dividir el trabajo en área y definiretapas de desarrollo. Mucho de el trabajo que se hace está dentro deun flujo de dependencias. Dicho de otro modo, en muchas ocasiones,para que un miembro del equipo pueda realizar su trabajo, requerirádel entregable de alguien más. No se pueden hacer pruebas de códigosi no hay código y no se puede crear el código si no hay un diseño queimplementar. Es por ello que el trabajo del productor incluye la planea-ción de este flujo de trabajo para que sea lo más eficiente posible. Laintención es que cada miembro del equipo tenga en todo momentouna tarea en la cual trabajar pero sin saturar a nadie de trabajo. De ahíque también es importante definir en qué momento entra o sale unmiembro del equipo al proyecto. Podría darse el caso de un conjuntode tareas que una sola persona pudiera completar en el tiempo con-templado para el desarrollo, pero si la mayoría de estas se requierencompletar en etapas tempranas del proyecto tal vez la mejor opciónserá repartirlas entre dos o más personas para que puedan ser comple-tada con mayor anticipación.