NOMIS
Una vez con un amigo dijimos: – “Vamos a hacer un videojuego por semana”. Y este fue uno de esos juegos. En realidad lo hicimos en un día, pero estuvímos toda la semana tirando ideas de diferentes cosas que se nos iban ocurriendo. Siempre tengo presente la frase de que “es muy fácil empezar cualquier proyecto, lo difícil es terminarlo”. Y creo que aplica en muchos sentidos a muchas cosas. Pero nos era muy difícil mantener una idea original sin pensar en querer agregarle muchísimas cosas. Lo que terminaba pasando muchas veces es que el juego se hacía enorme en ideas y ya no sabíamos ni por dónde arrancar.
Sabiendo todo lo anterior, tratamos de mantener el juego lo más simple posible. Lo más “complicado” fue generar sonido por código. Sí… Podríamos haber incluido sonidos básicos, pero quisimos por código por motivos que ya no recuerdo. Este es el código que usamos para eso:
Y para que vean que lo de mantenerlo simple era en serio, fijense cuántas clases usamos:
Creo que es una buena idea cuando se quiere tener experiencia cerrando proyectos (o sea, empezarlos y terminarlos de principio a fin), no pensar demasiado en una estructura de código. Sí. Ya sé. Esto rompe muchas reglas de código y demás. Pero creo que es importante pasar por la experiencia de hacer el proyecto de principio a fin, para luego entender “por qué” tenemos que aplicar determinadas estructuras de código. Cuando daba clases siempre dejaba que los alumnos se topen con determinados problemas, para recién ahí explicar cuál es la solución a dicho problema.
Si nuestro objetivo es subir un juego que muy probablemente no tenga grandes actualizaciones y por el sólo hecho de subirlo, tenemos otro motivo para no pensar demasiado en estructuras de código, ya que esto nos puede poner una barrera muy grande. Pero si nuestro objetivo es crear un producto escalable, que reciba actualizaciones frecuentes de niveles y demás features, de más está decir que tenemos que pensar en una base para que eso sea posible sin mayores inconvenientes.
