¿Cómo comienzas el desarrollo de un juego? [cerrado]

Cuando comienzas un nuevo proyecto de juego, ¿qué haces primero? ¿Cómo comienzas? ¿Qué le da la mejor ventaja para completar el proyecto en lugar de agotarse antes de que llegue a alguna parte?

_{Mods por favor ayuda con las etiquetas ... No tengo idea de cómo clasificar esto ... :)}

Prototipo. Intenta implementar tu concepto de juego usando algún tipo de herramienta de iteración rápida. Pruebe python o simplemente alguna api de código abierto fácil de trabajar para que su "idea de juego" funcione. Trate de simplificar lo más posible, use bolas en lugar de personajes, obtenga la visión sobre algún tipo de representación visual. De esa manera, siempre puede verlo, discutirlo, debatirlo y dar su opinión. Ponga una línea de tiempo establecida para cada prototipo (tal vez 2 días? Quizás una semana como máximo?). De esa manera, solo puedes hacer todo lo que quieras hacer en el prototipo.

A veces, puede ser capaz de trazar su idea en un papelito si es lo suficientemente simple. Una vez que tenga su idea establecida, comience a planificar para ver qué tipo de sistemas y mecanismos necesita. Trate de estructurar las líneas de tiempo para las cosas y vea si es posible comprometerse con ellas. Si eres un grupo de personas que quieren hacer un juego juntos, debes hacerlo juntos. Hazlo con una cerveza, ya sea en persona o usando un programa de chat de voz. Una vez que sepa qué hacer, todos pueden comenzar con lo que están haciendo. Asegúrate de tener comunicación. Trate de tener una reunión de equipo con un intervalo frecuente que dependa de cuánto tiempo quieran dejar.

Si estás haciendo tu propio juego, recuerda que el tiempo es limitado y no puedes hacer todo bonito. Tal vez las esferas y los cubos sean suficientes para que tus gráficos funcionen si eres un programador. Darse cuenta de sus limitaciones y trabajar con ellos en lugar de en contra de ellos.

Espero que estos pocos consejos ayuden :)

Como maestra, veo muchos proyectos de pasatiempos estudiantiles que fracasan. Invariablemente, la razón más importante para el fracaso es el exceso de alcance: el proyecto comienza como esta gran visión de algo enorme que es demasiado grande para completar, cada vez más personas se ven involucradas hasta que se derrumba bajo el peso de su propio diseño, y todos se va frustrado y desmoralizado.

El mejor remedio para esto es restringir su alcance sin piedad. En lugar de decir "¿cómo mantengo mi energía lo suficiente como para terminar un proyecto largo?" deberías decir "¿cómo diseño un proyecto que sea lo suficientemente corto como para poder terminarlo antes de aburrirme?"

Los eventos de "atasco de juegos" (tipo de cosas de hacer un juego en un fin de semana) son una excelente manera de comenzar, y son excelentes para desarrollar buenos hábitos al hacer prototipos rápidos. En WORST, pasas un fin de semana haciendo un juego pésimo ... probablemente aprendiste algo en el proceso ... Y te ahorraste meses trabajando en una idea que terminó no siendo tan genial como pensabas originalmente. En el mejor de los casos, descubres que tienes algo realmente especial y puedes comenzar a agregar pequeñas características de una en una hasta que tengas un proyecto con todas las funciones.

En mis pequeños proyectos de pasatiempos, la otra cosa que he encontrado que ayuda es comenzar con una lista completa de todas las tareas de desarrollo conocidas que deben hacerse, ordenarse y reducirse para que cada tarea individual sea factible y comprobable en tal vez 30 a 60 minutos, como máximo. Es muy estimulante hacer una pequeña tarea, verla funcionando en el juego y tacharla de la lista ... lo que hace que sea mucho más probable que haga lo siguiente en la lista ya que la última fue tan fácil, y luego el siguiente ... algo así como comer papas fritas.

Otra pista: cada vez que implemente con éxito una nueva característica, haga una copia de seguridad (o use el control del código fuente, que es básicamente lo mismo, pero no todos usan el control de la fuente si solo trabajan en su propio proyecto personal). De esa manera, si arruinas totalmente el código a las 2 a.m. y no sabes cómo volver a funcionar, el proyecto no está muerto y no es necesario reiniciarlo desde cero; en su lugar, simplemente regresa al último hito completado y en funcionamiento, e intenta nuevamente.

Yo diría que lo realmente importante es tener siempre algo que mostrar.

Quiero decir, podrías pasar años y años en un sistema de entidad basado en datos, con renderizado diferido y FPS realmente alto, y todo eso. Pero es probable que te aburras de no tener nada que mostrar y te des por vencido. Mientras que, si primero intentas obtener algunos modelos en la pantalla, moverlos e ir desde allí, tendrás muchas más posibilidades.

Creo que el primero es el desarrollo de abajo hacia arriba; trabajando desde un marco hasta el contenido real, y el segundo es de arriba hacia abajo; trabajando desde obtener algo de contenido y construir desde allí.

Un pequeño punto, pero algo que realmente ayuda.

Como desarrollador solitario, creo que ayuda a implementar el sonido desde el principio. Me parece que me motiva a trabajar más duro en las otras funciones porque incluso en las primeras semanas (con gráficos limitados a polígonos de colores brillantes, detección de colisión escamosa, controles faltantes, etc.) el sonido aún da la sensación de estar "casi allí". ".

Una vez trabajé en un proyecto que parecía hacer todo bien. Habían creado un sitio web / tablón de anuncios para que todos los que trabajan en el proyecto puedan colaborar. Les habían presentado a todos plazos y objetivos específicos y el juego en sí era un buen concepto. A pesar de esto, a las personas solo les tomó alrededor de 2 meses comenzar a dejar el mapa. Después de 3 meses, el desarrollo se terminó y el juego nunca se completó.

Entonces, si estás trabajando en un equipo, creo que necesitas un incentivo. Necesita a alguien continuamente en contacto con todos, asegurándose de que estén haciendo el trabajo y recordándoles por qué quieren seguir haciéndolo.

Si trabajas solo; No estoy muy seguro Soy terrible con las obras de arte, etc., así que me concentro principalmente en el lado del motor de las cosas. Esto siempre es suficiente para mantenerme interesado :)

Los desarrolladores siempre te dirán que no te muevas a nuevas áreas hasta que hayas terminado la que estás trabajando ahora. Si estás tratando de construir un juego tú mismo, entonces no creo que sea demasiado atroz si decides romper esta regla. ¡Trabajar en algo nuevo es una buena manera de mantener altos tus niveles de emoción!

Hay muchas buenas respuestas, pero también agregaré las mías:

• Siempre tenga un proyecto en ejecución que pueda ver. No entre en modo tanque donde codifique durante 2 semanas sin algo que mostrar.
• Mantenga el ciclo de retroalimentación corto (esto se expande aún más en el punto anterior): codifique una pequeña característica nueva, muéstrela, obtenga retroalimentación.
• No siempre poner en práctica algo que no es necesario ahora, que es el corolario de: Nunca construir una primera cosa marco de un proyecto.

Me gustaría ampliar un poco el último punto, ya que lo he visto suceder varias veces: nunca construya un marco primero. Hay muchas razones, pero básicamente, no tendrá la visión necesaria para hacer las cosas bien, perderá mucho tiempo pensando en qué pasaría y perderá la moral cuando después de X días / semanas de trabajo, habrá nada que mostrar por ello.

El problema es que el marco a menudo es necesario para el producto final, entonces, ¿qué debe hacer un codificador? Comience a construir específicamente, con valores codificados. Cuando necesite cambiar un valor, hágalo modificable en opciones. Cuando necesite hacer dos cosas similares, abstraiga las piezas similares juntas, pero mantenga el resto específico. Si sigues haciendo esto, terminarás con un marco que surge debido a la necesidad, en lugar de perder el tiempo con lo que pasa al principio.

Después de construir tu Xth juego, puedes considerar comenzar con el framework, para entonces tendrás suficiente experiencia para llevarlo a cabo.

Tenía dos o tres cuadernos de ideas antes de comenzar a desarrollar mi primer juego. Pasé varios meses jugando juegos similares con fines de investigación, determinando qué características me gustaban o no. Generalmente trato de enfocarme en la mecánica primero y abordar el aspecto posterior (pero teniendo cuidado de no ignorar la usabilidad). Recomiendo tener un diseño aproximado pero completo antes de sumergirse en el desarrollo. No intente precisar todos los detalles demasiado pronto, ya que su diseño necesariamente evolucionará para acomodar problemas de jugabilidad, limitaciones tecnológicas, etc.

Asegúrate de que tu idea esté llena haciendo una lluvia de ideas y escribiendo algunos objetivos de diseño clave. Paso por un proceso que llamo encontrar el juego 'alma'. IE cuál es la razón principal por la que estoy haciendo este juego. A partir de aquí, desarrollaré más conceptos e ideas que respaldarán este objetivo principal. Todo este proceso puede llevar horas, días, semanas o más, dependiendo de cómo se te ocurra la idea.

Desde aquí, obtén algo visible y cinético. Creo que poder jugar con el juego y obtener comentarios es vital para mantener la motivación. Tiendo a implementar efectos visuales y de sonido, así como un manejo y procesamiento de entrada simple para que algo esté 'sucediendo' y se sienta como una realidad en lugar de un sueño.

No importa cómo vaya tu estrategia de desarrollo, no puedo enfatizar lo suficiente como para que no te involucres en tratar de diseñar y codificar un "motor" de juego. Cada característica que no tenga ningún efecto visible o táctil en el juego ofrecerá muy poca recompensa. Para ayudar a compensar esto con los sistemas básicos esenciales, coloque la información de desarrollo en la pantalla. IE FPS, variables AI y cualquier otro texto que ayudará a exponer que hay algo que no existía antes. No hay nada más agotador que pasar 10 horas codificando un sistema, compilando y teniendo exactamente la misma experiencia que antes.

Escribí un artículo hace varios años sobre cómo encontrar tu alma de juegos que puedes encontrar interesante aquí: http://deleter.phatcode.net/index.php?page=articles&a=8

editar: Y una cosa más que veo mencionada en otra publicación sobre la que quiero dar más detalles. Juegue no solo mientras diseña su juego, sino que en cualquier momento no se siente muy motivado para trabajar en su propio juego. Me parece que jugar juegos similares me ayuda a recordar por qué quiero hacer mi juego y me ayuda a dar ese impulso adicional que necesito para seguir adelante.

Además, puedes crear un "banco de inspiración" de imágenes, videos, música y clips de sonido que contengan elementos de lo que quieres poner en tu juego. Cada vez que necesite instrucciones, vuelva a estas fuentes para ayudar a guiar sus decisiones. Esto ayudará a mantenerlo motivado y encaminado.

Normalmente me concentro en la interfaz de usuario primero. Me ayuda a imaginar cómo jugará el juego. También tiendo a trabajar en pensamientos fáciles primero, así no me atasco en algo.

Comience con un concepto de juego, establezca la razón del juego, la jugabilidad, la apariencia del juego que desea hacer.

A partir de ahí, puede comenzar a hacer una lista de características y activos para que el programador y el artista puedan al menos comenzar a trabajar en algo, mientras que el diseñador piensa o modifica la mecánica del juego.

De esta manera, al menos tendrá algunos códigos y recursos en unos pocos días o semanas para aumentar la moral y poner en marcha su proyecto.

Para mí, ayuda a "planear" mentalmente la idea del juego antes de comenzar. Trataré de descubrir la mecánica principal, una estructura básica del juego interno, tal vez algunos pequeños detalles sobre cómo quiero que funcione. Luego aplico caucho a la carretera y empiezo a trabajar, doblando o rompiendo partes de mi mapa mental donde el código necesita una configuración diferente. Podría escribir algunas cosas (una historia de fondo, tal vez las características clave), pero en ese punto el diseño generalmente está cambiando demasiado para que un documento sea útil.

De lo contrario, me quedo un poco terminando siendo un proyecto fallido desde el principio: /