Mi problema es que cada vez que comienzo a programar un clon de un juego (para practicar) o mi propio juego o algún otro problema, me detengo en algún lugar en el medio del desarrollo, porque perdí interés en él.
¿Cómo mantienes el interés en desarrollar un juego o en general?
Respuestas:
Como diseñador, tiendo a pensar en las personas como colecciones de estadísticas y variables. Cuando planteas tu pregunta, puedo imaginar fácilmente [Pong_Dev_Interest] disminuyendo y [Spa_Inv_Dev_Interest] aumentando. Cuando la diferencia entre los dos es mayor que [Dev_Project_Inertia] (algo relacionado con [Dev_Completion_Desire]), la actividad en [Pong_Dev] se detiene y [Spa_Inv_Dev] comienza.
En inglés: no puede completar el proyecto porque su deseo de ver un producto terminado se ve anulado por su falta de interés en el proyecto actual. Si realmente quieres terminar uno, la única solución es elegir uno (iría con tu clon de pong) y terminarlo . Dígase a sí mismo "Yo, sé que tal vez podría haber refinado ese clon un poco más, pero Dios mío, seguro que se siente bien patear un proyecto por la puerta". Entonces sigue trabajando.
Cuando estés aburrido, sigue trabajando. Cuando todo vaya bien, sigue trabajando. Cuando se caiga a la mierda, ¡sigue trabajando! ¡Perseverar! ¡Sé el pequeño desarrollador que podría! ¡Creo en ti!
Ejem. Tengo un poco sobreexuberante allí. Pero entiendes la deriva.
Estoy siguiendo mi propio consejo todos los días. Puse a trabajar a mi entorno y a mis actores, construí mis condiciones de ganar y perder y creé los objetos que usará el jugador. Básicamente estoy listo para comenzar a hacer un diseño de nivel y mi interés se desvaneció. Pero hago algo todos los días. Todos los dias Un día terminaré.
Y se sentirá tan bien.
fuente
Siempre me hago la misma pregunta y hay un par de cosas que puedes hacer para motivarte (muchas de ellas ya están publicadas aquí). Lo que funciona bien para mí es algo que escuché en una de las charlas independientes en el GDC de este año, creo que fue el tipo que hizo el juego de Mónaco :-)
Primero, encuentre un proyecto que esté bien en su línea de experiencia. Es decir, no empiezas a hacer un FPS si ni siquiera conoces los conceptos básicos de OpenGL / DirectX. (a menos que esté usando un motor de juego pero ese no es el punto aquí ;-))
Luego, haga una lista de las cosas que debe hacer y los hitos que desea lograr, para que siempre sepa a dónde ir. El TODOs es la parte importante. Defina sus tareas de modo que cada tarea pueda realizarse fácilmente en un día o en un par de horas . Entonces, cuando comienzas a codificar, diseñar, modelar, etc., ya ves la luz al final del túnel. Nada es más deprimente que diseñar y codificar su gran Game Engine durante un mes sin acercarse a la línea de meta. Divide las tareas grandes en tareas más pequeñas. Terminar una tarea rápidamente es realmente gratificante y te mantiene en marcha. Por ejemplo, esta fue mi lista de tareas para un pequeño juego de disparos espaciales al mismo tiempo:
Todas estas tareas fueron fáciles de hacer y una vez que funcionan en el juego, puedes iterar en esas áreas y pulirlas.
Y oye, terminé un pequeño juego. No es bonito, pero básicamente está hecho, lo que fue realmente gratificante al final :-)
fuente
Debe identificar el problema antes de poder resolverlo. ¿Por qué pierdes interés?
Para mí, generalmente sucede porque paso mucho tiempo en el marco, y después de semanas, ni siquiera pude obtener un solo elemento de juego.
Una forma que encuentro para mejorar mi motivación es hacer prototipos iterativos, o alguna forma de Desarrollo Dirigido por Pruebas. Por lo general, eso implica la automatización de casos de prueba, pero como los juegos son intensivos en gráficos, no puede automatizar pantallas y animaciones como pruebas, pero la lógica de su juego podría automatizarse.
Para las partes que no se pueden automatizar, básicamente planificaré un par de hitos para el juego. El hito 1 probablemente representaría un sprite en la pantalla y haría que WASD funcionara, por ejemplo. Gradualmente, agregaré más funciones y refactorizaré.
Es una forma de dividir y conquistar. Rompe en trozos pequeños, trabaja en el que te resulte cómodo y luego integre. Enjuague y repita. Eventualmente, puede ver una mejor manera de reorganizar las cosas, y puede refactorizar su código. Es complicado no tener una arquitectura por adelantado, pero por lo general, al comenzar a programar es difícil visualizar la arquitectura hasta que tenga algunos años de experiencia.
fuente
Trato de encontrar alguna parte más fácil de hacer. Por ejemplo, si no puedo entender cómo hacer algo o no quiero hacerlo, cambio de marcha y modelo o escribo un sombreador, etc.
Ver esta y esta otra publicación.
fuente
Si no sabes cómo estructurar correctamente un juego, debes comenzar a aprender cómo abstraer sus elementos en bloques independientes del juego. Esto puede ayudarte de muchas maneras (además de ser interesante), como: experiencia dividiendo las abstracciones de las implementaciones, una mejor explotación de la herencia y el diseño de la interfaz, o simplemente cómo poner el juego en múltiples archivos para que se vea profesional (o para proporcionar una flexibilidad de implementaciones mediante el uso de bibliotecas de enlaces dinámicos u otros usos de la interfaz). Tarde o temprano te darás cuenta de que todo se puede hacer y luego te encontrarás sin ese problema de motivación (solo lo haces).
Tuve el mismo problema cuando me quedé atrapado al principio, pero la mejor solución es seguir moviéndome, o puedes detenerte para siempre hasta que algo te restablezca de alguna manera (y puede llevar demasiado tiempo). No importa si solo codifica 2 líneas algunos días, pero todos los días tiene al menos para abrir el proyecto e intentar mejorar algo (es una tarea interminable, pero ese no es el problema).
Si en algún momento el programa no funciona, debes deshacer lo que hiciste al final (mantener una copia de seguridad usando un svn o al menos un .rar con el nombre de la fecha) en un punto en el que funcionó, e intentar hacerlo nuevamente, o trabaje en otros cambios que necesite hacer hasta que quiera volver a intentarlo.
Al principio, debe intentar corregir el error con la ayuda del depurador, pero no sé si su lenguaje incluso admite un depurador ... pero si por casualidad usa C ++ o algo así (lo que recomendaría si usted desea hacer juegos), debe hacer un mejor uso de su depurador, ya que le ayudará mucho a encontrar el error rápidamente en una sola ejecución.
Leer sobre la programación de juegos también es una buena cosa para seguir con el tema si no quieres trabajar en nada en particular. Hay algunos buenos libros y artículos sobre motores de juegos y diseño que puedes encontrar en línea.
No podrás hacer nada si no practicas. Tratar de encontrar un error puede ser muy frustrante al principio, pero luego aprende que en realidad es fácil si sabe cómo hacerlo. Esto es algo que aprende a evitar con el tiempo, al codificar de manera que sus cambios no afecten a todo el programa, disminuyendo la cantidad de lugares en los que buscar el error. Si cada vez que te resulta difícil te rindes, entonces cada vez que pienses en hacer un juego te rendirás antes de comenzar. Solo aprende a superar el mal momento superándolo: P Si no pasas por ese momento en el que pierdes la motivación, tu pereza ganará y perderás, así es como funciona, hasta que aprendas a recuperar la motivación. sin mucho esfuerzo
PD: Me preguntaba ... ¿qué estás usando para hacer el juego?
fuente
[destinado a dejarse como un comentario a la respuesta de anon, que se eliminó cuando lo publiqué. Mencionó que tenía toda esta funcionalidad funcionando, luego dividió el código de un solo archivo en varios archivos, solo para que todo se desmoronara]
Re: refactorización, pueden pasar cosas, incluso para profesionales. A veces, incluso con buenas herramientas como Git, una fusión puede fallar, por lo que en lugar de que la característica A y la característica B funcionen, ¡ninguna funciona! La única opción es volver a A e intentar nuevamente. Afortunadamente, el control de versiones guardará este código para usted; Si no usa el control de versión real, al menos hágalo manualmente comprimiendo su carpeta de desarrollo regularmente: ¡el espacio HD es barato! En conclusión, regrese a lo que funciona y refactorice en pasos más pequeños, asegurándose de que el juego aún funcione en cada paso. Es realmente deprimente limpiar el código solo para ver que todo se desmorona. Simplemente vuelva al código anterior.
fuente
Para mantenerte motivado, sigue diciéndote a ti mismo que estás haciendo un juego, no un motor de juego, bueno, a menos que sea lo tuyo. Y eso es genial, los motores de juego son geniales, pero con demasiada frecuencia se interponen en la fabricación de juegos.
Para ilustrar mi punto, puedo decirte cómo van las cosas a menudo: al principio creas algunos sprites, los mueves en la pantalla con tu proto-framework y ¡estás encantado! Puedes ver tu progreso y va bien; Puedes mostrar a tus amigos.
Luego, una vez que haya jugado un poco con su concepto, se dará cuenta de que necesita hacer que su marco (o motor de juego) sea más flexible. O que debería volver a factorizar alguna clase que no sigue los últimos patrones. Y a partir de ahí, te embarcas en una espiral de muerte: dejas de trabajar en un juego y comienzas a trabajar en un motor de juego. Y los motores de juego no son tan divertidos de hacer. Puedes pasar horas refactorizando y no tienes nada que mostrar en el juego. Y luego, pierdes interés.
Entonces, recuerda: crea juegos, no motores de juegos. Solo refactorizar cuando sea necesario. No seas demasiado flexible, solo lo mínimo. *
*: por supuesto, la refactorización y la flexibilidad son importantes. Pero no es tan importante como tener un juego terminado.
fuente
Intenta hacer una versión jugable en un día, no importa cuán simple sea. Luego iterar.
fuente
¡No intentes complicar demasiado tu juego!
Divida su tarea en subtareas pequeñas, específicas y medibles. Si alguna subtarea parece demasiado grande, subdividirla aún más.
Asegúrese de escribir "HECHO" en letras grandes en su lista de tareas (uso un archivo .txt) cuando termine su tarea. No elimines la tarea, porque entonces no parecerá que estás progresando.
Esto es lo que hago. Funcionó en el pasado.
fuente