Desarróllame

Creatividad – Guía básica del cazador de ideas

Desde que volví de Londres, se suponía que iba a volver a reactivar la sección Desarróllame, pero en dos meses sólo he escrito un artículo. Como explico en mi recién migrado blog (y de paso me doy un poco de publicidad xDDD), tampoco he estado parado. Aún así pido disculpas, y aprovecho para hablaros de un tema del que escribí hace casi un añó pero que aún no he subido aquí, y que creo que es muy interesante: cómo ejercitar nuestra creatividad.

Ahí va. Agarraos que vienen curvas :P.

Antes que nada, me gustaría dedicar el artículo al discurso inspirador de Pablo Medina, mi profesor de guión en la Universidad Europea de Madrid, al gran creativo e incombustible Valentín Fernández-Tubau, también profesor de guión durante el III Encierro en las Cumbres, y a la vida misma, mi maestra suprema, y que me ha mostrado cosas que en ocasiones no he visto claramente hasta que Pablo o Valentín no me lo pusieron delante de los ojos peor que, aún así, siempre estuvieron ahí. Así que no voy a dejar de nombrarles a lo largo de todo el artículo, porque me sabe mal que gran parte de lo que diga aquí no sea más que las conclusiones a las que he llegado en ocasiones gracias a ellos.

Lo primero que voy a hacer es contaros qué es el Encierro en las Cumbres. Pues, como su nombre indica, es una concentración de guionistas en las Hoces del Duratón, dirigida por Valentín Fernández-Tubau y organizada por su pareja, Anuska Gil. A lo largo de la semana que duró el evento, bajo la batuta de nuestro «profe», combinamos actividades en contacto con la naturaleza (caminatas, bicicleta, piraguismo,  etc.) con el aprendizaje de una serie de pautas creativas para ayudarnos a dar forma a nuestro guión. En mi caso, y tras muchas deliberaciones entre todas mis ideas, finalmente elegí el guión de un corto sencillo: «12 frases de amor«, que terminaré en cuanto esté un poco libre de mis obligaciones «videojueguiles». Pero ese será otro tema…

Así, nos juntamos más de una decena de creativos aprendiendo juntos, trabajando juntos y respirando juntos el aire del Duratón. Una experiencia maravillosa, con una gente fantástica, unos organizadores increíbles y un lugar mágico es todo lo que se necesita para que la creatividad eche horas extras.

Todo lo que voy a hablar de la creatividad a partir de ahora, va a ser una mezcla de lo que aprendí con Pablo Medina, con Valentín Fernández-Tubau y algo de mi propia cosecha.

Antes de que os creáis todo lo que os diga, aprovecho para preveniros de esos autores (en muchos casos no dudo que de gran prestigio), que predican sus métodos y estructuras como únicas e infalibes. Probablemente a ellos les funcionen, e incluso a vosotros en bastantes casos (o quizás en todos), pero no exisite ni uno sólo que le funcione siempre y a todo el mundo. Ayudaros de sus sugerencias y consejos, pero no os encorsetéis en ellos. En estructura de guión no he querido meterme en este artículo porque también tienen su miga, pero ya haré un artículo sobre ello.

Diseño de Niveles Básico

¡Muy buenas a todos! Ya he vuelto de Londres (estuve fuera desde octubre), y vuelvo a la carga con los tutoriales sobre diseño y programación de videojuegos. Para retomarlo, empiezo con algo suave, y creo que bastante interesante que escribí el jueves tras la charla de Daniel González en la Universidad Politécnica de Madrid con motivo de la II Edición del Game Spirit.

Si hay una materia que, en mi humilde opinión, se quedó algo flojita en el Máster en Diseño y Programación de Videojuegos de la Universidad Europea de Madrid que cursé el año pasado, desde luego ha sido Diseño de Niveles. Y no es precisamente un tema baladí, pues va a ser sobre los niveles donde se desarrollarán nuestros videojuegos. Para que veamos lo importante que puede llegar a ser un buen diseño de niveles, voy a poner un par de vídeos que hablan por sí mismos:

Cube (Trailer)

 

Uncharted 3 (Avión de carga)

 

Por eso no he querido perderme la conferencia que ha ofrecido hoy en la Universidad Politécnica de Madrid  Daniel González, autor del libro Diseño de Videojuegos de la editorial Ra-Ma, profesor en Gametopía, creador de la revista digital Vive la Live y autor de Advertainmen, un blog con información jugosa sobre desarrollo de videojuegos.

Así que con su libro en una mano, y el bloc donde he tomado apuntes esta tarde en la otra, me dispongo a dar una serie de pautas y recomendaciones sobre diseño de niveles.

Pero me va a ser imposible porque no me quedan manos para escribir, así que antes voy a dejarlos sobre el escritorio.

Ya está.

Bueno, humor absurdo aparte, lo primero que hay que saber es quién diseña los niveles. Obviando el tema de que estamos en el país en el que contratan a una persona para hacer lo que deberían hacer dos o tres (para que luego digan que no somos productivos), la tarea del diseño de niveles recae sobre dos profesionales muy distintos: el guionista y el mapeador. Aunque lo más probable es que en un estudio pequeño el game designer, el guionista y el mapeador sean la misma persona, es importante saber distinguir el rol que vamos a tener cada momento, aunque sólo sea para estructurar nuestras tareas.

¿Qué hace el guionista?

El guionista debe describir cómo debe ser el escenario que debe crear el mapeador, pero, como siempre, tiene algunos límites no muy bien definidos para no hacer lo que no le corresponde. A groso modo, sería:

  • Historia: Los escenarios deberían tener cierto nivel de profundidad, una historia de trasfondo que dé significado a todo lo que nos vamos a encontrar en él, y que nos haga sentir que ese lugar es algo más que un decorado. Un escenario con una buena historia puede dar lugar a quest secundarias que den más horas de diversión al jugador.
  • Ambientación: No es tanto el apartado visual como la sensación que pretende transmitirnos: si queremos darle al jugador una sensación de agobio o de tranquilidad, si queremos que parezca gélido o tropical, inhóspito o familiar… puede que queramos causarle miedo, o melancolía. Un buen artista sabrá interpretar correctamente estas sensaciones y plasmarlas en el escenario.
  • Dimensión: Cómo queremos que sea de grande nuestro nivel. Sencillo.
  • Jugabilidad: Un aspecto que muchas veces olvidamos, es que un buen diseño de niveles debe aportar en cada escenario una jugabilidad que lo diferencie de los demás. Puede que en unas misiones prime la infiltración, y en otras la acción, que tengamos un tiempo límite para el escenario, alguien a quien debamos proteger, o que el propio nivel sea nuestro enemigo (como sucede en los juegos de plataformas).
  • Personajes: Debemos definir a los enemigos y el resto de personajes que aparecerán en el nivel, y cómo interactuarán con él. Puede que alguien se esté escondiendo entre la maleza o en un intrincado laberinto, o que un enemigo esté usando sus poderes para arrojarte partes del escenario. O a lo mejor sólo es un pueblo tranquilo lleno de mercaderes. Quizás algún protagonista tiene una relación con ese sitio: ¿ocurrió algo en ese lugar? ¿quizás fue su hogar, ahora destruido?
  • Items especiales: Remarco lo de especiales, ya que no me refiero a los típicos ítems de munición, vida, etc. que serán trabajo del mapeador, sino a los que encierran algún vínculo con el nivel. Una espada poderosa puede estar custodiada en ese templo, o a lo mejor es uno de los fragmentos de gema que estás buscando. Puede que consideres que ya va siendo hora de darle al protagonista algo de artillería pesada. El guionista tiene que tener claro dónde van a encontrarse esos items, y ser capaz de darles cierto protagonismo.
  • Requisitos de entrada y de salida: Qué tenemos que hacer o tener para poder entrar en este nivel (quizás necesitamos ciertas habilidades, una llave, o haber completado otro nivel), así como qué es lo que tendremos que hacer para salir de él (llegar a un sitio, localizar algo o a alguien, acabar con un enemigo, etc.).
  • Diálogos y cinemáticas: Su función está supeditada a todo lo anterior: contar algo de la historia, ambientar la acción, guiar en la jugabilidad, o presentar personajes e items especiales. En cualquier caso, es trabajo del guionista desarrollarla y no pasarse con ellos (que es algo que nos encanta a todos los guionistas). Recuerda que el jugador quiere jugar, no ver una película.

¿Qué hace el mapeador?

Pues el mapeador hace, precisamente, todo lo demás. Que no es poco.

  • Mapa del nivel: En su libro, Daniel González recomienda la utilización de software como AutoRealm, aunque también se pueden utilizar otros como Tiled Map o editarlo directamente en nuestro motor favorito (Unity 3D, UDK, etc).
  • Obstáculos: Muchos de los obstáculos vendrán dados por la descripción que nos haya dado el guionista, pero su distribución dependerá del mapeador. Pueden ser puertas cerradas, pasadizos ocultos, caminos bloqueados, cámaras de vigilancia si tenemos que infiltrarnos sin que nos pillen, etc.
  • Enemigos y otros personajes: El guionista nos dice qué personajes va a haber, o con qué tipo de enemigos nos encontraremos, pero la distribución en el nivel depende completamente del mapeador.
  • Puntos de guardado: Previamente, el game designer tiene que haber definido cómo va a guardarse la partida. Si existen puntos de guardado o checkpoints, corresponde al mapeador decidir dónde estarán situados.
  • Items: Como ya comentamos, el mapeador también se encargará de distribuir los items estándar por el escenario (munición, items curativos, fuentes de maná, magias, etc). Es recomendable distribuirlos siempre después que los obstáculos y los enemigos, para mantener el equilibrio.

El trabajo del diseño de niveles es especialmente importante, ya que nos va a definir una serie de elementos clave que marcarán el trabajo del resto del equipo:

  • Balance: Lo controlaremos mediante la distribución de los ítems. No es lo mismo ir sobrado de pociones de vida, que tener que administrarlas con cuentagotas.
  • Ritmo: Lo marcaremos con la distribución de enemigos. Un mapa repleto de ellos será frenético respecto a otro que prefiera utilizar los obstáculos como elemento principal.
  • Duración: Con los obstáculos aumentaremos la duración del juego.
  • Curva de aprendizaje: Los puntos de guardado (si los tenemos), se irán distanciando a medida que avancemos en el juego.
  • Trama y ambientación: Los diálogos y las cinemáticas del nivel no sólo deben darnos información sobre la historia, sino que además deben introducirnos en la acción. Esto es importantísimo: la forma de dar cierta información no será la misma en mitad de un tiroteo que en la Sala de Instrucciones de nuestro Cuartel General.

Recordemos que el diseño de niveles forma parte de la acción, del guión, y de la jugabilidad, pero sobre todo de la DIVERSIÓN. Si nuestro nivel no es divertido, da igual lo bien marcados que estén los ritmos, lo perfecto que encaje en nuestra historia, o lo distintiva que sea su jugabilidad.

Un nivel siempre debe ser divertido.

Espero que estas pautas básicas os hayan servido tanto a vosotros como a mí.

 

Unity 3D – Cómo hacer un cuadro de selección como el de un RTS

¡Buenas tardes!

Hace más de dos semanas, antes de largarme al III Encierro en las Cumbres (una concentración de guionistas en las Hoces del Duratón dirigida por Valentín Fernández-Tubau) y las posteriores fiestas de mi pueblo, escribí un artículo que no me dio tiempo a colgar aquí.

Después también he tenido algo de lío y no he podido hacerlo hasta hoy. Espero que la espera haya merecido la pena:

Como ya he comentado un par de veces, el principal proyecto en el que me encuentro trabajando ahora mismo es Bellum, un juego de estrategia a tiempo real.

Uno de los retos a los que hemos tenido que enfrentarnos es la realización de un cuadro de selección de unidades. No es que sea demasiado difícil, pero no hemos encontrado absolutamente ningún tutorial de Unity 3D que indique cómo hacerlo en toda la red. Así que lo que voy a ofreceros probablemente sea una exclusiva de Internet (o quizás sea que soy un patán con Google, que también es posible).

Muchos de vosotros os preguntaréis para qué os sirve un cuadro de selección si los juegos de estrategia os importan un pimiento. Pues antes de que dejéis de leer os aviso de que, aunque vuestro juego no incluya este elemento, a lo largo del tutorial veremos cosas tan básicas e imprescindibles como tirar «rayos» desde la cámara para ver qué tenemos delante de nuestro puntero (la base de cualquier shooter) o cómo pasar coordenadas de mundo a coordenadas de pantalla.Así, en este tutorial vamos a aprender a:

– Enfrentarnos a un proyecto real, utilizando las distintas herramientas que nos ofrece Unity 3D.
– Construir un código ordenado que responda a nuestros requerimientos.
– Crear GameObjects desde el código a partir de Prefabs.
– Utilizar los valiosos «Raycast» para detectar elementos de nuestra escena presentes en un determinado vector.
– Pasar coordenadas de mundo a coordenadas de pantalla.
– ¡Ah, sí! Y a crear un cuadro de selección :P.

Aunque voy a reutilizar algo del código de Bellum, para no liaros he decidido crear un nuevo proyecto.

En un alarde de originalidad, lo he llamado «Tutorial_SelectionBox».

Game loop: el origen de todo

¡Volví de vacaciones!

Y lo hago con un tutorial que considero básico e imprescindible: cómo funciona un videojuego. A la hora de enfrentarnos a cualquier cosa, lo más complicado suele ser saber cómo empezar, cuál es el origen de todo lo que vamos a hacer después. Y creo que esta preocupación ocurre tanto a la hora de programar, como de enfrentarse a una hoja en blanco o al pedir nuestra primera subida de sueldo.

Con los videojuegos algunos motores nos darán esta base, y a partir de ahí podemos mirar un montón de tutoriales para seguir haciendo cosas, pero si no sabemos qué es lo que hace funcionar a nuestro juego, o en qué parte actúa el API que estemos utilizando, muchas veces iremos a ciegas. Y como todos ya nos conocemos el refrán «ojos que no ven, ostiazo que te pegas» vamos a intentar arrojar un poco de luz sobre todo esto.

Pues bien, un juego no es más que un bucle continuo llamado game loop:

  1. void run()
  2. {
  3.     bool playing = true;
  4.     while (playing)
  5.     {
  6.         ReadInput(); //Leemos las entradas del teclado
  7.         Update(); //Actualizamos el estado de los objetos
  8.         Render(); //Los dibujamos en pantalla
  9.     }
  10. }

Todo juego tiene una estructura similar, pero tenemos que tener en cuenta el API sobre el que estamos trabajando.

ReadInput()
Aquí comprobamos el estado de los distintos dispositivos de entrada (ratón y teclado sobre todo, pero podría ser un joystick o un joypad, una pantalla táctil en el caso de un smartphone, o incluso un micrófono). Es altamente recomendable separar la lógica del ReadInput de la del Update(), y utilizar flags que indiquen el estado del input para que el Update actúe en consecuencia.

También es ideal que almacenemos las teclas en variables, de este modo podremos cambiar fácilmente el mando del juego.

No recomendado:

  1. void run()
  2. {
  3.     bool playing = true;
  4.     while (playing)
  5.     {
  6.         ReadInput(); //Leemos las entradas del teclado
  7.         Update(); //Actualizamos el estado de los objetos
  8.         Render(); //Los dibujamos en pantalla
  9.     }
  10. }
  11. void ReadInput()
  12. {
  13.     //Cada API tiene su función para leer el Input.
  14.     if (isKeyPressed(Key.Space))
  15.     {
  16.         Jump();
  17.     }
  18. }

Recomendado:

  1. void run()
  2. {
  3.     bool playing = true;
  4.     //Input Keys
  5.     const Key KEY_JUMP = Key.Space;
  6.     //Input State
  7.     bool jump;
  8.     while (playing)
  9.     {
  10.         ReadInput(); //Leemos las entradas del teclado
  11.         Update(); //Actualizamos el estado de los objetos
  12.         Render(); //Los dibujamos en pantalla
  13.     }
  14. }
  15. void ReadInput()
  16. {
  17.     //Cada API tiene su función para leer el Input.
  18.     if (IsKeyPressed(KEY_JUMP))
  19.     {
  20.         jump = true;
  21.     }
  22. }
  23. void Update()
  24. {
  25.     if (jump)
  26.     {
  27.         Jump(); //Esta función terminaría con un jump=false;
  28.     }
  29. }

 

De este modo, separaremos de forma lógica ambas funciones y tendremos un código más ordenado, lo que nos ayudará enormemente cuando tengamos un Update complejo en el que tengamos que tener en cuenta un montón de variables.

Update()
Aquí desarrollaremos toda la lógica de juego, pero no os abruméis. Un juego no es más que unos cuantos objetos con una serie de estados, que realizan funciones. Así, en función de su estado, cambiaremos su posición en la pantalla, pero también deberemos de acordarnos de controlar la vida, la munición, los puntos o el resto de variables que estemos utilizando.

Dentro del Update deberíamos tener en cuenta también la física, pero por lo general nos la manejará automáticamente nuestro motor, por lo que no tendremos que preocuparnos. Si no lo hace, hoy en día existen motores físicos para absolutamente todas las plataformas que seguro podremos utilizar. Unity 3D, por ejemplo, tiene su propio manejador de físicas, por lo que sólo nos tendremos que preocupar de establecer en nuestro objeto una serie de propiedades físicas.

Los cálculos físicos suelen ser los últimos que se realizan en el Update

Render()
Cuando trabajamos con un motor gráfico, lo que hace básicamente es manejarnos automáticamente la función Render() (aunque luego pueda resolvernos más cosas, como la física), ya que es la que trabaja directamente sobre las librerías gráficas (DirectX u OpenGL), y muchas veces en nuestros juegos nos bastará con añadir nuestros elementos a un Graphic Layer (una capa que se encarga de dibujar todo lo que haya en ella), o heredar nuestros objetos de alguna clase que contenga toda la lógica de renderizado.

¿Dónde encaja todo esto en Unity 3D?

Efectivamente, en Unity 3D nosotros no vemos este bucle por ningún lado.

Antes que nada, hay que comprender que Unity 3D sigue una arquitectura basada en componentes, que es ligeramente distinta a la más familiar POO (Programación Orientada a Objetos). La diferencia entre un objeto y un componente es que los primeros necesitan ser instanciados, es decir, partimos de una clase que define un tipo de objeto que nos servirá de molde para crear objetos similares (por ejemplo, la claseEnemy nos podría servir para crear multitud de enemigos). Mientras tanto, los componentes se asemejan más a scripts, trozos de código que dan una funcionalidad determinada al objeto al que se anexan, y cuando uitilicemos la palabra clave «this«, no referenciaremos al componente, sino al objeto sobre el que está alojado.

De este modo, si en Unity creas un GameObject (que es cualquier cosa que actúe en el juego), tendrá toda la funcionalidad básica de un objeto del juego, pero si además le añades, por ejemplo, un componente RigidBody, el GameObject tendrá física, y si también le pones un componente Player, en el que defines la lógica del jugador, esteGameObject ahora responderá a las acciones del jugador.

Ambas arquitecturas pueden combinarse, y de hecho lo hacen. Tú, por ejemplo, puedes crear un componente cuya lógica utilice instancias de clases, y después agregarlo como componente a un GameObject.

Muy bonito todo este inciso, pero seguimos sin ver el game loop del que os he hablado al principio. La razón de esto es que Unity lo está manejando de forma transparente, sin que nosotros nos demos cuenta. Cada vez que Unity da una vuelta al bucle, llama a una serie de funciones contenidas en el MonoBehaviour. Por eso, cuando creamos un script en C# (el lenguaje recomendado), veremos que hereda de esta clase. Así, lo único que tenemos que hacer cuando creamos un script es definir estas funciones. Por defecto Unity nos creará Start() y Update().

Unity 3D nos ofrece la documentación de las funciones que utiliza en esta web: http://unity3d.com/support/documentation/Manual/Execution%20Order.html

Es imprescindible que tengáis en cuenta que cada vuelta al loop puede tomar un tiempo distinto en función de la carga del procesador, por lo que tendréis que utilizar este espacio de tiempo en vuestros cálculos. Para ello, Unity pone a vuestra disposición la variable Time.deltaTime, que no es más que los segundos que ha tardado el juego en completar el último frame.

La excepción es FixedUpdate(), que tiene un tiempo de llamada específicado en la variable global Application.targetFrameRate.

Aunque para trabajar con físicas FixedUpdate() es la función recomendada, debemos tener mucho cuidado al utilizarla, ya que procesos muy cargantes o frameratesdemasiado pequeños pueden hacer que nuestro juego haga cosas raras o nos vaya a saltos.

Ahora que comprendemos el game loop de un juego y sabemos cómo interactuar con él en Unity 3D, podemos empezar a hacer nuestros primeros scripts sin cortocircuitarnos en el intento ;).

Unity 3D – Familiarizándonos con el Editor

Siguiendo con los tutoriales de Unity 3D, iba a preparar una entrada para explicar la interfaz de este entorno de desarrollo. Sin embargo, echando un vistazo a lo bien explicadito que está todo en el manual de la web oficial de Unity, me voy a limitar a hacer una traducción libre de lo que viene ahí.

Familiarizándonos con la Interfaz
Primeros pasos

Vamos a empezar a utilizar Unity. Si aún no lo has abierto, puedes hacerlo desde «Inicio -> Programas -> Unity» en Windows o «Aplicaciones -> Unity» en Mac. Nos aparecerá el editor de Unity. Tómate tu tiempo para echarle un vistazo a la interfaz del Editor de Unity y familiarizarte con ella. El Main Editor Window está formado por varios cuadros llamados Views. Hay varios tipos de Views en Unity, cada uno con un propósito distinto.

Project View

Todos los proyectos de Unity tienen una carpeta «Assets«. El contenido de esta carpeta es mostrado en el Project View. Ahí es donde guardaremos todos los recursos que formarán nuestro juego, como escenas, scripts, modelos 3D, texturas, archivos audio y Prefabs (objetos prefabricados). Si haces click con el botón derecho del ratón en cualquier recurso del Project View, puedes elegir «Show in Explorer» («Reveal in Finder» en Mac) para abrirlo desde el sistema de archivos de tu ordenador.

Nota importante: Nunca muevas tus archivos desde el Sistema Operativo porque podría romper los metadatos asociados. Utiliza siempre el Project View para organizar tus recursos.

Para añadir recursos a tu proyecto, puedes arrastrarlos desde el sistema de archivos en el Project View, o utilizar la opción «Assets -> Import New Asset…«. Tu recurso estará disponible para que puedas utilizarlo en tu juego.

Las Scenes también se guardan en el Project View. Éstas son niveles individuales. Por ejemplo, puedes tener una pantalla de menú inicial, varios niveles de juego, etc. y cada uno de ellos será un Scene distinto. Para crear una Scene, pulsaCtrl+N (Command+N en Mac). Para guardar la escena actual, pulsa Ctrl+S(Command+S en Mac).

Algunos recursos del juego son creados desde Unity. Para ello, haz utiliza la lista desplegable de Create o haz click con el botón derecho del ratón y selecciona Create.

Esto nos permitirá crear xcripts, Prefabs, o carpetas para mantener tu proyecto organizado (algo esencial si queremos terminar un proyecto y no enloquecer en el intento). Puedes renombrar cualquier carpeta o recurso pulsando F2 en Windows, Enter en Mac o seleccionándolo y haciendo click sobre el nombre. Si pulsas Alt mientras expandes o contraes un directorio, todos los subdirectorios que contenga se expandirán o se contraerán.

Unity3D – Instalación

Después del primer tocho de Desarróllame, esta semana publicamos un artículo bastante más light en el que veremos cómo instalar la versión gratuita del entorno de desarrollo de Unity 3D, un motor gráfico 3D que nos facilitará bastante la programación de videojuegos en múltiples plataformas.

1. Lo primero que haremos va a ser bajarnos la última versión completamente gratis desde aquí: http://unity3d.com/unity/download/.

2. Una vez lo tengamos el instalador, lo ejecutamos y nos saldrá la típica ventana de instalación que ya estaremos hartos de ver. Así que hacemos lo de siempre:

«Next»

«I agree»

«Next»

«Install».

Mamá, quiero hacer un videojuego

Un día tienes un sueño, y al despertar sueltas la mítica frase: «Mamá, quiero hacer un videojuego».

Con este artículo estrenamos Desarróllame, una nueva sección de n3dsworld donde iremos publicando artículos sobre el desarrollo de videojuegos y entrevistas con profesionales del sector.

Si quieres hacer un videojuego, ya has dado el primer paso de un largo camino, que es precisamente querer hacerlo. Puede que parezca una perogrullada, pero no lo es. Eso sí, debes estar muy seguro de que realmente quieres hacerlo.

Si es tu primer juego, el recorrido probablemente será largo y duro, y no puedes dudar en ningún momento. Ármate de paciencia y de motivación, y sé sincero contigo mismo: no va a ser fácil, puede que tengas que dar muchos rodeos antes de alcanzar tu objetivo, y existen muchas posibilidades de que en algún momento decidas que el esfuerzo no merece la pena.

Si llegados a este punto sigues leyendo, puede ser por dos cosas: te pica la curiosidad o realmente estás dispuesto a sacrificar tiempo y paciencia para hacer tu juego.

Un recurso que puede ayudarte a enfocar tus esfuerzos y a sincerarte contigo mismo, y que debería hacerse incluso antes de plantear tu idea, es un análisis DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades), seguido de la estrategia a seguir basándose en este, y una conclusión. Este concepto que parece tan empresarial, no tiene por qué ocuparos más de una página (aunque podría extenderse todo lo que se quiera), y es una forma de ser realmente consciente de nuestras capacidades.

Este es el DAFO a partir del cual decidimos desarrollar Bellum (mi proyecto de fin de curso):

  • Fortalezas: Son los campos y recursos de los que dispondremos a la hora de hacer el juego.
  • Debilidades: Hay que ser sinceros para saber qué cosas nos va a costar más, o directamente no podremos hacer.
  • Oportunidades: Son los factores externos que nos ayudarán a cumplir nuestro objetivo.
  • Amenazas: Todos los factores externos que pueden perjudicar el desarrollo del proyecto.
  • Estrategia ofensiva: De qué modo podemos utilizar nuestras fortalezas para aprovechar las oportunidades.
  • Estrategia defensiva: Cómo vamos a utilizar nuestras fortalezas para combatir las amenazas.
  • Estrategia adaptativa: Cómo aprovecharemos las oportunidades para suplir nuestras debilidades.
  • Estrategia de supervivencia: Qué vamos a hacer para que las debilidades no supongan el fin del proyecto frente a una amenaza.