Convertirse en un programador no solo es aprenderse la sintaxis y los conceptos de un lenguaje de programación: se trata de averiguar cómo usar ese conocimiento para hacer programas. Hiciste un montón de programas en este curso, en los desafíos y proyectos, pero ahora debes tener ideas para nuevos programas (ideas que te emocionen mucho) y tratar de convertir esas ideas en programas reales.
Probablemente no sepas todo lo que necesites para tu programa cuando lo empieces, y eso está totalmente bien. Te motivarás para aprender esas cosas nuevas porque realmente quieres hacer que tu programa sea real. Los programadores están constantemente aprendiendo nuevas cosas para nuevos proyectos, y eso es parte por lo cual nos encanta.
Vayamos a través del proceso de planear un proyecto de programación:

1. ¿Qué quieres hacer?

Cuando empecé a programar, me encontré constantemente pensando en nuevos programas por hacer y escribiéndolos en una lista. Era adicto al poder de la creación, y había tanto que mi cerebro quería hacer. Si tu eres así, entonces probablemente ya tienes una idea de lo que quieres hacer, y tal vez ya tienes tu propia lista.
Si todavía no tienes una idea, entonces aquí hay algunas preguntas para ayudarte en una lluvia de ideas:
  • ¿Cuál es tu juego favorito, electrónico, de mesa, de deportes? ¿Podrías hacer una versión simplificada, digital de eso? ¿Podrías cambiarlo un poco, como darle otro tema o personajes principales?
  • ¿Cuáles son tus campos académicos favoritos? Si te encanta el arte, ¿podrías hacer un programa para hacer arte? Si te encanta la historia, ¿que tal una línea de tiempo interactiva? Si te encanta la ciencia, ¿qué tal una simulación científica? 
  • ¿Cuál es tu película o programa favorito de televisión? Podrías hacer una versión digital de una escena o un personaje de ahí? ¿Tal vez hacer un juego basado en eso?
  • ¿Cuál es un dispositivo de la vida real que te encanta? ¿Podrías hacer una simulación de eso?
Una vez que hayas escogido una idea, deberías escribir una descripción de ella. Por ejemplo, si decidiera hacer un clon de "Breakout", porque ese es mi juego electrónico retro favorito, podría escribir:
Breakout: un juego en donde controlas una paleta en la parte inferior de la pantalla y la usas para golpear una pelota hacia arriba y en ángulos para romper bloques. El objetivo es romper todos los bloques y no dejar que la bola caiga al suelo demasiadas veces.
Vas a detallar esa descripción después, pero por ahora eso te da una idea suficientemente buena para continuar en el proceso de planeación.

2. ¿Qué tecnología usarás?

En este paso, necesitas considerar con qué tecnologías (lenguajes/bibliotecas/ambientes) estás familiarizado o cuáles puedes aprender fácilmente, y cuáles de ellas son las más adecuadas para el trabajo. Para muchos de ustedes, esa lista puede ser de un solo elemento, "1. JS+ProcessingJS", y eso hace que tu decisión sea fácil.
Nuestro ambiente JS+ProcessingJS funciona muy bien para hacer animaciones, juegos, visualizaciones y simulaciones. Solo revisa los programas de la comunidad para ver el amplio rango de programas que la gente hace aquí.
Nuestro ambiente no funciona para otras cosas como juegos multi-jugador, aplicaciones móviles o aplicaciones de procesamiento de datos. Si sabes otros lenguajes/ambientes (como JS+HTML, Python, SCRATCH, Swift, etc.) y estás pensando en construir algo que no tiene mucho sentido hacer con ProcessingJS, entonces considera cuál de esas tecnologías sería mas adecuada para tu programa. Si quieres construir esas cosas pero no sabes otras tecnologías, tal vez quieras replantearte una nueva idea para tu programa. Tu puedes aprender una nueva tecnología para un nuevo proyecto, pero en especial si estás empezando a programar, es una buena idea primero volverte muy bueno en tu primer lenguaje.
Si yo decidiera hacer un juego como Breakout, escogería JS+ProcessingJS, dado que ya sé esa tecnología y también funciona muy bien para juegos en 2D como ese.

3. ¿Qué características incluirá?

Aquí es donde realmente nos metemos a planear de verdad, y en donde (creo) se pone divertido. Tu objetivo en este paso es averiguar qué es lo que estás haciendo en realidad: cómo se verá, qué características incluirá, qué características no incluirá.
Lo primero que puedes hacer son "maquetas": bocetos que se parezcan a lo que estás haciendo, pero sin los detalles como colores o tamaños exactos. Puedes hacer maquetas en papel o con con programas en línea:
Para darte una idea de cómo se ven las maquetas, a continuación incluyo maquetas de mi clon de Breakout. Hice bocetos para cada escena de manera separada y dibujé flechas entre ellas para mostrar cómo una escena conduce a otra. Esas flechas me ayudarán a entender la lógica que necesito en mi programa para cambiar entre estados del programa.
Maquetas esbozadas de un clon de Breakout
Ahora puedes usar esas maquetas para ayudarte a hacer una lista de características, en donde pienses acerca de cada una de las características de tu programa, y convertirla en una lista.
Para mi clon de Breakout, esta podría ser mi lista de características, separadas por escena:
Escena del juego
  • Paleta controlada por el usuario
  • Bloques de varios colores
  • Movimiento angulado de la pelota
  • Detección de choques
  • Desplegar vida
  • Desplegar puntuación
  • Efectos de sonido
Escena principal
  • Botón de jugar
  • Botón de ayuda
Escena de ayuda
  • Texto
  • Botón para regresar
Escena de ganar
  • Encabezado
  • Animación de fuegos artificiales
Escena de perder
  • Texto
  • Botón para reiniciar

4. ¿Pero qué características debe incluir?

Si todos tuviéramos un tiempo infinito para hacer todos los programas en nuestras cabezas, entonces incluirían todas las características en nuestra lista. Pero no lo tenemos, así que en este paso tienes que decidir cuáles características son las más importantes, y cuáles características harás solo si tenemos tiempo. Esto también te ayudará a averiguar en qué orden implementar las características, de las más a las menos importantes.
Para ayudarte a averiguar la importancia de cada característica, hazte estas preguntas:
  • Si compartiera esto con un amigo, ¿cuáles características me gustaría estar seguro que funcionaran?
  • ¿Cuáles características me emocionan más construir?
  • ¿Cuáles características son las más únicas de mi programa?
  • ¿De cuáles características aprenderé más al implementarlas?
  • ¿Hay algunas características que parecen demasiado complicadas para mi nivel actual de habilidades?
Después, revisa tu lista del paso anterior y ordena la lista o agrégale un rango de importancia a cada característica.
Para mi lista de características del clon de Breakout, puse "P1", "P2" y "P3" junto a las características, que significan prioridad alta (P1), prioridad media (P2) y prioridad baja (P3). Decidí priorizar los mecanismos únicos del juego por encima de las características generales del juego como las escenas, porque eso se me hace más emocionante de este proyecto:
(P1) Escena del juego
  • (P1) Paleta controlada por el usuario
  • (P1) Bloques de varios colores
  • (P1) Movimiento angulado de la pelota
  • (P1) Detección de choques
  • (P2) Desplegar vida
  • (P2) Desplegar puntuación
  • (P3) Efectos de sonido
(P2) Escena principal
  • (P2) Botón de jugar
  • (P3) Botón de ayuda
(P3) Escena de ayuda
  • (P3) Texto
  • (P3) Botón para regresar
(P2) Escena de ganar
  • (P2) Encabezado
  • (P3) Animación de fuegos artificiales
(P2) Escena de perder
  • (P2) Texto
  • (P3) Botón para reiniciar
Como un consejo general para aquellos de ustedes haciendo juegos, aquí están las características que recomiendo no priorizar: menús, niveles múltiples, gráficos 3D. Enfócate en lo que es único y divertido acerca de tu juego, después agrega esas cosas adicionales.
También puedes convertir tu lista priorizada en versiones del proyecto, de modo que puedas ver fácilmente lo que necesitas implementar en cada versión, y siempre puedes detenerte después de una versión particular y estar contento con lo que has hecho.
Aquí está como se verían las versiones para mi clon de Breakout:
V1
  • Paleta controlada por el usuario
  • Bloques de varios colores
  • Movimiento angulado de la pelota
  • Detección de choques
V2
  • Desplegar vida
  • Desplegar puntuación
  • Escena de jugar con botón de jugar
  • Escena de ganar con encabezado
V3
  • Efectos de sonido
  • Botón de ayuda
  • Fuegos artificiales
  • Escena de perder con botón para reiniciar

5. ¿Cómo lo vas a implementar?

Ya tienes una idea de qué características vas a construir primero en tu programa. Pero si empiezas ahora, estarás viendo un programa completamente en blanco sin nada de código escrito, y eso puede ser intimidante. ¿Cuáles variables debes escribir primero? ¿Cuáles funciones?
Una manera en la que puedes averiguar eso es pensar acerca de la "arquitectura de alto nivel" de tu programa (separarlo en categorías como "objetos", "lógica", "interacción del usuario", "datos del usuario" y "escenas") y después pensar acerca de cómo puedes implementarlas, como tipos de objeto orientados a objetos, funciones o variables.
Por ejemplo, aquí está una arquitectura para mi clon de Breakout:
Objetos
  • Brick (.isHit())
  • Paddle (.move())
  • Ball (.move())
Escenas
  • Inicio
  • Juego
  • Fin
Lógica
  • Choque pelota-bloque (function, usar bounding box)
  • Ángulo de la paleta con la pelota (function, invertir ángulo)
Interacción del usuario
  • Movimiento de la paleta con el teclado (keyPressed)
  • Botones para cambiar escenas (mouseClicked)
Datos del usuario
  • Muertes de la pelota (array)
  • Golpes de la pelota (array)
Una vez que ya hayas pensado acerca de la arquitectura de alto nivel, debe ser más claro qué puedes empezar a codificar primero.
Puedes decidir escribir todo tu programa en pseudocódigo primero, del cual hablamos más adelante en esta lección. Básicamente, significaría escribir todo el programa en español dentro de un comentario, y después poco a poco convertir eso en código.

6. ¿Cuál es tu cronograma?

¿Cuánto tiempo tienes para hacer este programa? ¿Cuántas semanas y cuánto tiempo cada día? ¿Qué características vas a escribir cada semana? Tu objetivo en este paso es averiguar un cronograma para tu proyecto, el cual es particularmente importante si tienes una fecha límite, pero también es útil para que puedas empezar a entender cuánto tiempo te toma escribir un programa.
Aquí está un cronograma para mi clon de Breakout, suponiendo 2-4 horas de trabajo cada semana:
  • Semana 1: diseño y pseudocódigo
  • Semana 2: visualizaciones preliminares
  • Semana 3: mecánica del movimiento/choque de la pelota
  • Semana 4: mecánica de la puntuación
  • Semana 5: escenas (inicio/ganar/perder)
  • Semana 6: pulir, pruebas manuales (revisión de calidad), preparación para demostración
Averiguar los cronogramas para proyectos de programación es difícil. Algunas cosas que parecen fáciles toman mucho más tiempo del esperado (como algún error extraño con el cual te pasas horas depurando), algunas cosas que parecen difíciles toman menos tiempo del esperado. Como una regla general, supón que te vas a tardar más de lo que piensas, y ajusta a medida que vayas avanzando.

¡¿Estás listo!?

Con suerte esto te da una idea del proceso de planear un proyecto de programación, y te inspira a empezar un proyecto ahora. Dependiendo en qué quieras construir, también puedes decidir tomar otros cursos antes, como JS avanzado: juegos y visualizaciones o JS avanzado: simulaciones naturales, para darte más ideas para construir juegos y simulaciones.
Lo importantes es asegurarte de que empieces a hacer tus propios proyectos en algún punto, porque ahí es donde vas a aprender más, y también donde vas a tener la mayor alegría de programar, porque estás haciendo tus sueños realidad.
Cargando