Definiendo lascaracterísticas del juego Eduexperts, (2019). DERECHOS RESERVADOS ©.
“At the beginning of the game development process, the team will likely consist of a producer, lead designer, lead engineer, and lead artist. This core team is responsible for taking a concept and tur- ning it into a game design. This means determining the concept, platform, genre, gameplay mechanics, character designs, and any other key game elements. If you are working for a publisher-owned developer, the publisher will likely assign your team specific games to work on, including the platform, genre, and initial concept. With this basic informa- tion, the core team needs to define all the other elements of the game. If you are working for an independent developer, your core team will come up with the initial concept and further define it. Regardless of where the initial concept originates, there is still plenty of creative work for the team to do.”Brainstorming: A partir de este punto, un primer paso podría ser una sesión de Bra- instorming para generar ideas respecto al concepto del juego. “Brainstorming sessions are an opportunity to involve the team in generating a large number of ideas about the game. You can brains- torm about the initial game concept, the basic gameplay mecha- nics, the game's setting, or what the characters will look like in the game. Well-managed brainstorming sessions are also a great team-building exercise because it allows everyone to offer opi- nions about what makes a fun game.”
No siempre estas sesiones son tan productivas como quisiéramos, por lo cual, para lograr una sesión exitosa de Brainstorming, se re- comienda contemplar los siguientes puntos:● Definir claramente el propósito de la sesión.● Establecer una duración de la sesión.● Elegir cuidadosamente a los participantes de la sesión.● Indicarles de antemano el propósito de la sesión.● No criticar las ideas durante la sesión.● No discutir las ideas durante la sesión.● Cuando las ideas dejen de fluir, prepararse a generar más.● Definir claramente el propósito de la sesión.● Establecer una duración de la sesión.● Elegir cuidadosamente a los participantes de la sesión.● Indicarles de antemano el propósito de la sesión.● No criticar las ideas durante la sesión.● No discutir las ideas durante la sesión.● Cuando las ideas dejen de fluir, prepararse a generar más.“After the ideas are generated, the team should group the similarOnes together, then prioritize them. From this, generate a report ofthe results of the brainstorming session and add it to the meetingnotes. The higher priority ideas arc assigned to specific people for fo-llow-up and research. Be very clear about the action items generatedin each brainstorming session and include these in the meeting notes.If you do not follow up on any of the ideas generated, people will feelthat their participation was a waste of time. Some of the topics to bebrainstormed might include the genre, platform, and initial game con-cept.”La información generada por la sesión de “Brainstorming” debe serdepurada y confrontada con cualquier otra información que tenga-mos de antemano para poder determinar cuáles de las propuestas
son realmente viables y cuales deseamos integrar a nuestro proyecto.Por ejemplo. ¿Tenemos un límite de presupuesto a invertir o detiempo de desarrollo?, ¿tenemos algún requerimiento específico encuanto a mercado meta o plataforma?, ¿hay alguna limitante técnicaque debamos considerar? En teoría, estos factores ya deberían cono-cerse desde antes de la sesión de Brainstorming pero la intención esque las ideas producidas en esas sesiones no estén limitadas por laviabilidad de estas.La parte creativa no es una parte central de este módulo pero cabeseñalar que dependiendo de la estructura del equipo, el productorpuede o no tener injerencia en las decisiones creativas del proyecto oabocarse únicamente a la parte administrativa. Lo que sí es indispen-sable es que, cualquiera que sea el caso, se algo que el resto delequipo tenga claro.Historias de Usuario(User Stories) Las Historias de Usuario son un elemento común en las metodolo- gías ágiles y son una manera de representar los requisitos para nuestro producto expresados en lenguaje formal desde la perspec- tiva del usuario o consumidor. Regularmente se redactan como en el siguiente ejemplo: “Yo como usuario, deseo poder jugar con mis amigos que viven en otra ciudad”.
En ocasiones, también se engloban en esta categoría necesidades odeseos similares de otros roles involucrados en el proceso de crea-ción y/o distribución del juego. Por ejemplo: “Yo, como publisher,deseo poder distribuir mi juego en el mercado asiático”.Estas historias de usuario pueden elaborarse a partir de la informa-ción generada en el brainstorming pero muchas veces tambiénsurgen de los requerimientos del cliente o de la información arrojadapor el estudio de mercado. En el caso de un MVP, las historias deusuario pueden ser una herramienta muy útil no solo al principio sinoen cada iteración que reciba retroalimentación de parte de los usua-rios.El objetivo inicial es generar tantas historias como creamos conve-nientes y, a partir de estas historias, extrapolar una lista de todas las“features” o características que deberá contener nuestro juego.Listado de Características(Feature List) A partir de las Historias de Usuario y la demás información que ten- gamos podemos elaborar un listado de todas las características que deseamos incluir en nuestro juego. Claro que esta lista tam- bién requerirá una revisión para determinar cuáles de estas vamos a incluir en la versión final de nuestro juego, sobre todo si estamos hablando de un MVP, ya que este tiene que contener únicamente los esenciales.
Para poder tomar la decisión de qué se va y qué se queda, regular-mente tenemos que hacer un análisis de prioridades y de viabilidad decada una de estas características. Para este análisis es importantetomar en cuenta la opinión de los diferentes departamentos involu-crados para no subestimar ninguna información. Regularmente, estose puede revisar en una reunión con los líderes de cada área quienespodrán emitir comentarios y opiniones al respecto.La viabilidad de un componente puede evaluarse por su dificultad ocosto de implementación. Por ejemplo, si es algo que nadie en elequipo ha hecho con anterioridad o no hay nadie capacitado paraello, automáticamente la dificultad de la tarea será alta. Si el tiempode desarrollo de esa característica o componente es largo o implicaun gasto fuera de lo ordinario, también significa que es un elementode alta dificultad. Si todas estas circunstancias se conjuntan, quieredecir que la dificultad de implementación es muy alta. Puede habercomponentes que impliquen una dificultad alta para uno o más áreaspero no para las demás, por lo que a veces es recomendable hacer eldesglose de cada uno de estos elementos por departamentos. Regu-larmente es suficiente con establecer tres niveles de dificultad (bajo,medio, alto) pero quedará a criterio de cada equipo. Podemos asig-narle un valor numérico a cada uno de estos niveles, sobre todo sivamos a evaluar todas las áreas a la vez.Podemos ver un ejemplo en esta tabla, donde ‘1’ representa menordificultad y ‘3’ mayor dificultad, por lo tanto, un promedio más altoindica una tarea más difícil.
Componente Prod. Diseño Gráficos Progra. QA PromedioComponente 1 1 2 2 1 1 1.4Componente 2 2 1 1 3 1 1.6Componente 3 3 2 1 22 2Componente 4 1 3 3 3 2 2.4Componente 5 2 3 2 3 3 2.6En cuanto a la prioridad, debemos establecer qué tan relevante consi-deramos incluir dicha característica en nuestro juego para construir laexperiencia que buscamos y aquí es donde la participación del Direc-tor Creativo o el Líder de Diseño de Juego puede ser muy importante.Para este caso, también podemos establecer niveles, con parámetroscomo:● Mandatorio (Must have)● Importante (Like to have)● Deseable (Nice to have)Para este proceso también podemos involucrar a los líderes de otrasáreas y de paso conoceremos su opinión sobre el juego a desarrollar yasí saber si todo el equipo está en la misma sintonía. También puedeser una buena oportunidad para unificar criterios. Es posible que notodos consideran igual de importante alguna característica y seríamuy útil conocer el porqué.
Asignar estas etiquetas a cada uno de los posibles componentes yade por sí nos puede arrojar mucha luz sobre qué elementos debemosconservar y de cuales podemos prescindir. Regularmente, los menosprioritarios no se integran al producto y se dejan en espera como po-sibles componentes adicionales para una segunda versión o una se-cuela. También es importante confrontar estos valores con lo que nosarrojó el análisis de dificultad para prever y evitar complicaciones enel futuro.En la segunda de la siguiente tabla, los valores más bajos indicanmayor relevancia, por lo que los valores más bajos son más deseablesy los altos son menos deseables.Componente Relevancia DificultadComponente 1 2 1.4 Relevancia Media ?? Dificultad BajaComponente 2 1.2 1.6 Relevancia Alta SI Dificultad MediaComponente 3 2.2 2 Relevancia Baja NO Dificultad MediaComponente 4 3 2.4 Relevancia Baja NO Dificultad AltaComponente 5 1.2 2.6 Relevancia Alta SI Dificultad Alta (!)
En este caso, el Componente 3 tiene una relevancia baja pero su di-ficultad de implementación es alta, por lo que deberá ser descarta-do. Incluso, el componente 3, que no tiene tanta dificultad es reco-mendable descartarlo de antemano. Solo en casos como el delcomponente 1, cuya relevancia es media pero su dificultad de im-plementación es baja puede ser un elemento que se pueda incor-porar en caso de que tengamos tiempo y recursos para ello. Casoespecial es el del componente 5, cuya relevancia es alta pero tam-bién la dificultad que implica. Por lo tanto, deberá atenderse conurgencia para resolver cualquier inconveniente que se pueda pre-sentar y que no provoque retrasos. En caso de que todas o la mayo-ría de nuestras características principales sean problemáticas talvez se requiera un análisis más a fondo y posiblemente nuestro en-foque del proyecto no sea el más adecuado y requiere replantearse.Hay ciertas características o componentes que más que ser priori-tarios o no son ajustables, por ejemplo, en un juego de peleas, tenerpersonajes seleccionables es imprescindible pero la cantidad quetendremos disponible si es un elemento que podemos ajustar deacuerdo a nuestra capacidad de trabajo.Por otra parte, si nuestro enfoque es la producción de un MVP, lacantidad de elementos esenciales debe ser mínima y lo adecuadosería no incorporar en la primera versión ningún componente noesencial. Más bien, esperaríamos a probar el juego con nuestrosusuarios para obtener el ‘feedback’ que nos permita determinar silas demás características contempladas son algo que les puede seratractivo y deseable o, por el contrario, debemos cambiar la direc-ción del proyecto para ajustarnos a la información arrojada por laretroalimentación, que es lo que se le denomina ‘pivoteo’.
Backlog / Macro Design Document Una vez que hayamos logrado decidir cuáles serán las característi- cas que contendrá nuestro juego (al menos la primer versión), lo más adecuado será desglosarlas en las tareas específicas que se re- querirán para implementar cada una de ellas. Por ejemplo, si mi juego será 3D y tengo contemplado que el personaje principal del juego tenga varias acciones como salto, disparo y uso de otros ob- jetos, habrá que diseñar su apariencia, modelarlo, crear el ‘rig’, ani- marlo y agregarle texturas. Es importante desglosar todas esas tareas porque a partir de ahí deberemos definir el ‘pipeline’ y las fechas de entrega. Una herramienta para ello es un tipo de docu- mentación más orientada a la producción en la que desglosamos cada componente según su aparición y uso en el juego, por ejemplo en esta imagen del documento de “Uncharted 2” podemos ver que está señalizado en qué parte del juego aparece cada uno de los componentes. Esto es muy útil sobre todo si estamos utilizando una metodología ágil que porque así podemos determinar con mayor facilidad qué partes del juego requieren menos componen- tes y podemos comenzar por ahí nuestro desarrollo con el fin de tener lo antes posible un nivel completo implementado que poda- mos probar.
LEVELS UNCHARTED 2 Macro Design ALLY-NPC ENEMY MODELS MACRO MICRO FLOW PLAY LOOK DESCRIPTION TIME OF DAY / MOOD GAMEPLAY Free Climb / Dy no Wall JumpWarzone Nepalese city broken & High Noon - War-torn & Laz Army HOT Explore Traverse Basic Gunplay Traversal xx Freedom Fighters Minor Gunfights Gunplay xxwar-1-market burning smokeywar-2-streets Nepalese city broken & High Noon - War-torn & Chloe-2 Laz Army HOT Explore Traverse Basic Gunplay Traversal burning smokey Freedom Fighters Minor Gunfights Gunplaywar-3-inside war-4- Nepalese city broken & High Noon - War-torn & Chloe-2 Laz Army HOT Explore Traverse Basic Gunplay Traversal xx smokey Freedom Fighters Minor Gunfights Gunplay Get to higher (hotel)highrise burningcity Nepalese city broken & High Noon - War-torn & Chloe-2 Laz Army HOT Explore Traverse Skirt close to Laz Army xx burning smokey Freedom Fighters Minor Gunfightscity-2 New area unlocked of High Noon - War-torn & Chloe Elena-1 Laz Army HOT Traverse Major Basic Gunplay Traversal xx City Gunplay smokey Cameraman Freedom Fighters Fighttemple Temple complex built in mysterious Chloe Elenea-1 Laz Army HOT Explore Problem xx the middle of the city Cameraman Freedom Fighters Solve Escape x Dead Expeditionscity third pass City + Train Yard high tension Elena-1 Laz Army HOT Escape / Fight x Freedom Fighters Chase x xTrainTrain into valley Tansition from warzone city to valley Lower valley region,Valley loop Chinese rice fields, bamboo forests and distant mountainsValley lake straight Lake w/ vista to the horizonValley loop 2 Fall onto convoy trucks Melee / x Gunfight on truckValley convo intro Fall onto convoy trucks Melee / x Gunfight on truckValley convoy end Fall onto convoy trucks Melee / x Gunfight on truckTunnel loop Truck driver's been shot, jump x off before truck smashes into cliffsideCliff bridge Light / Dark Tunnels xCliif loop xCliff convoy intro xCliff convoy loop xClip end crash xTrain-Wreck Alone Laz Army Wintertrain-wreck Village in it's pure state. Parka-Drake Meet the villagers! Colorful & alive vs. Rescuer VillagerVillage Harsh, windy (barren-ish) Elena-winter environment SchafferHappy Village Rescuer xxIve-CaveIce-cave 1
YER MECHANICS GAMEPLAY THEME WEAPONS (FOCUS)Free Ropes Pendulum Monkey Bars Monkey Swing Balance Beams Carry Objects Heavy Carry Objects Light Traversal Gunplay v. 1 Forced Melee Puzzle Stealth Sin Moving Objects Push Objects Binoculars Tranq-gun Pistol-Semi-a Pistol-semi-b Pistol-full-a Pistol-revolver-a Pistol-revolver-b SMG-a SMG-b Assault-Rifle-a Assault-Rifle-b Shotgun 1 Shotgun 2 Sniper-Rifle Crossbow xxx x x x Basic Gunplay x x xxx x x Traversal Gunplay x x xxx x x x Basic Gunplay Traversal Gunplay x x xxx x x x x Basic Gunplay x x xx x xx Traversal Gunplay x xx xxxxxx xx x Basic Gunplay xx x Traversal Gunplay x xx x x xx x x Basic Gunplay x x Traversal Gunplay x xx x x x Fall onto convoy x x x x trucks Melee / x xx x x Gunfight on truck x x x Fall onto convoy x x trucks Melee / x x x Gunfight on truck x x Fall onto convoy x x x trucks Melee / x Gunfight on truck x x x Truck driver's been x shot, jump off before x x truck smashes into x xx cliffside x x Light / Dark Tunnels x x x xx x xx xx
Fechas y entregables Otro elemento crucial es definir las fechas de entrega de nuestro proyecto. Cada proyecto tendrá una fecha tentativa de entrega final, a la que se le denomina comúnmente como ‘deadline’ pero también habrá fechas para entregas intermedias, conocidas como ‘milestones’, en las que regularmente esperamos tener una versión de nuestro juego con cierto nivel específico de avance (releases), por ejemplo, tener listo un ‘Vertical Slice’ o alcanzar la fase ‘Beta’ de nuestro juego. Si trabajamos con metodologías ágiles, tendremos que contemplar la duración de los ‘Sprints’, las tareas que se espera realizar en cada uno de ellos y qué entregables se deberán tener al final de cada uno de ellos. Sin embargo, esto puede representar una paradoja.Como ya mencionamos, una vez que decidimos las característicasque tendrá nuestro juego, lo mejor es desglosar cada ‘feature’ y cadatarea hasta donde sea posible. Hacer una previsión confiable de lostiempos de producción es una de las tareas más difíciles, por ello, unaforma de tener una aproximación adecuada es justamente desglosan-do todo en partes pequeñas ya que así tendremos una visión másclara y cercana de lo que dicha tarea implica y el tiempo que puedetomarle a nuestro equipo de trabajo llevarla a cabo. Esto también seconoce como “Work Breakdown Structure” (WBS). Sin embargo, enlos modelos de trabajo ‘Ágiles’ y ‘Lean’, no podemos planear de ante-mano las tareas específicas que llevaremos a cabo más adelanteporque dependemos de la validación que obtengamos con los usua-rios y si no es de esta manera, entonces no estamos llevando a caboun desarrollo de este tipo.
Por otro lado, el ‘publisher’ y/o el inversionista van a querer saber deantemano y con exactitud cuánto tiempo de producción se requeriráy cuál será el costo del proyecto. Regularmente, si estamos utilizandola metodología de ‘Lean Startup’ significa que nosotros mismossomos los dueños del proyecto y tendremos que decidir cómo lovamos a llevar pero si no es así habrá que encontrar la manera de con-ciliar las partes que se contraponen.Una forma de hacerlo es mediante estimaciones generales para crearun ‘Roadmap’ sin mucho detalle para después realizar ajustes cons-tantes al proyecto. En ciertos casos lo que se hace es trabajar con unmodelo que combina elementos de metodologías ágiles y desarrolloen cascada. Por ejemplo, podemos definir con antelación la fecha enla que tendremos lista nuestra versión Alpha aunque algunas caracte-rísticas se vayan a definir más adelante por lo que, más bien, la tareadel productor será la de monitorear el progreso del proyecto de talmanera que, sobre la marcha, vaya haciendo el desglose de tareaspara cada ‘milestone’ o ‘sprint’ y vaya tomando decisiones sobrecuántas iteraciones habrá y los entregables de cada una de ellas, conel fin de no exceder los tiempos y presupuestos establecidos. Inevita-blemente, en la gran mayoría de los casos vamos a tener el tiempo yel dinero muy limitados, pero esto también tiene su lado positivo, yaque, de otro modo, corremos el riesgo de estar iterando eternamentey nunca lograr tener una versión terminada.En otras palabras, si tenemos una fecha de entrega definida y un pre-supuesto limitado, lo más importante será asegurarnos de que, sinimportar el tipo de juego que hagamos o la metodología de trabajoelegida, este se ajuste a estas limitantes.
La estimación de tiempos y la definición de fechas de entrega no esalgo que deba definir arbitrariamente el Productor sino que es algoque, hasta donde sea posible, debe acordar en conjunto con las demásáreas, en particular, con los líderes de cada departamento, quienes se-guramente tendrán estimaciones de tiempos de producción más acer-tados y tendrán el conocimiento necesario para desglosar adecuada-mente las tareas complejas. En ocasiones es más práctico definirplazos y entregas de manera general con los líderes de cada área y quecada uno de ellos se encargue de hacer el desglose del trabajo y deasignar tareas específicas a cada miembro del equipo.Hay aspectos que son muy difíciles de estimar, sobre todo si es nues-tro primer proyecto, tales como el tiempo que va a tomar a los progra-madores resolver ‘bugs’. Para este tipo de necesidades, la experienciaes insustituible y no sólo en relación al ‘expertise’ que ganan cadaquien al enfrentar ciertas situaciones sino que el haber realizado conanterioridad una tarea puede darnos información valiosa sobre su du-ración real y la próxima vez que se planee hacer ya tenemos una refe-rencia que nos da cierta confiabilidad. Por ejemplo, si en nuestro pro-yecto pasado se reportaron 130 incidencias y se requirieron 8 díaspara corregirlas y el proyecto actual tiene una complejidad de aproxi-madamente el doble, podríamos estimar que a groso modo tendremosel doble de incidencia y nos tomará el doble de tiempo hacer las co-rrecciones. Por supuesto, es poco probable que la extrapolación sea100% precisa pero con cada nuevo proyecto tendremos nueva infor-mación que nos ayudará a tener estimaciones cada vez más cercanas.
Art Tasks (Villain's Lair) Duration Create prototype 5 days 1 day Implement prototype feedback 20 days Create level geometry 3 days 3 days Add placeholder textures 2 days Fix first round of bugs 10 days 5 days Create destructible objects 2 days Add final textures 5 days 5 days Create player reference map 3 days Create special effects Duration Optimize level for budge constraints 2 days Polish map 2 days 5 days Fix final round of bugs 5 days 1 day Design Tasks (Villain's Lair) 5 days Design initial level layout 2 days 1 day Design initial mission scripting 5 days Script prototype 1 day 1 day Play test prototype scripting 3 days Implement prototype feedback 2 days Script first pass of mision scripting Script first pass of multiplayer scripting Duration 3 days Review scripting 2 days Script second pass 2 daysVerify all supporting files are tagged correctly 3 daysCreate localization tags for in-game dialogue 2 days 1 day Polish scripting Fix final round of bugs Duration 1 day Sound Tasks (Villain's Lair) 7 days Create sound design 2 days 1 day Implement sound design prototype 1 day Implement prototype feedback 5 days 1 dayComplete first pass of sound implementation Polish sound Duration 1 day Fix finl round of bugs 1 day 1 day QA Tasks (Villain's Lair) 1 day Play test prototype 1 day Test geometry and terrain navigation Check textures Test initial scripting Test second pass scripting Final test all level geometry and textures Final test for mission scripting Approvals (Villain's Lair) Approve initial layout Aprove initial art prototype Approve initial design prototype Approve sound design Approve final level, scripting and sound
Pipeline En “The Game Production Handbook” encontramos una explica- ción bastante concisa de lo que debe definirse en cuanto al flujo de trabajo desde que se comienza a trabajar en un proyecto. “In addition to evaluating which technologies will be used for the game, the lead engineer will work with the other leads to define the production pipeline. The production pipeline refers to the series of steps that are needed to get code and assets working in a playable version of the game. It must smoothly incorporate the tools, assets, and production needs of the game. It is very rare that an asset can he created that is instantly useable in the game; the asset might need to be converted to a specific tile format or compi- led into the code. The game is not instantly playable with the new updates and assets; the engineers have to compile the code and build a new executable first. Key things to consider when defining, the pipeline are the following: ● What tools and software are needed? Software tools are needed to convert the file formats, and source control software must be used to check assets in and out of the build. Decisions must also be made on which compilers and ending languages are used. ● Can the pipeline support two-way functionality? The pipeline should support functionality for assets to he converted for game use, and the ability to convert game assets back into their original source assets. This allows asset changes to be made more readily. ● What is the critical path? Are there any bottlenecks? Make sure that a single person does not have a disproportionate amount of work in the pipeline, becoming a bottleneck for getting assets con- verted. Also, limit the number of steps in the pipeline; assets should he viewable and playable in a build as quickly as possible.
● When does the system need to be fully functional? In order tocreate a playable build of the game with the correct assets, the pi-peline must be functioning. Partial functionality is useable for afew months, as long it is does not prevent people from creatingassets and seeing them in the game.● How are assets managed and tracked in the system? Decidewhich source control software to use, so that team members cancheck out assets before working on them. Everything should bekept under version control to prevent multiple versions of a filefrom causing confusion in the pipeline.● Which areas of the system can be automated? Automate as muchof the pipeline as possible in order to reduce time and humanerror.\"
Concept phase On paper Game concept3D content creation pipeline Level conceptGraphics Concept arteditingMaya Low poly modeling import as references UV layout Level design High poly Sculpting Maya modeling Texturing Rigging Level designGraphicsediting Lighting LightmapsMaya static obects Animation animated objectsImplementationSound Unity 3Dediting Sounds Asset import Effects Scripting Shader Release
Documentación Otro de los temas importantes, sobre todo en la preproducción, pero regularmente sigue siendo una necesidad a lo largo de todo el proyecto es la generación de documentación. Aunque la más cono- cida es toda la generada por los diseñadores de juego, regularmen- te cada una de las áreas de trabajo requiere generar su propia do- cumentación para sus propios fines. Por ejemplo: ● Documentación del Departamento de Arte (gráficos): Guía de estilo, Listado de Assets, Documentación sobre herramientas. ● Documentación de Ingeniería (programación): Estándares de código, Diseño técnico, documentación de tecnologías utilizadas en el proyecto. ● Plan de Pruebas. ● Plan de Mercadotecnia ● Etc.