¿Cómo va el proceso de desarrollo del juego?

Si trabaja solo o en un equipo de 2-3 personas, no necesita dedicar demasiado tiempo a la planificación porque, francamente, no se lo puede permitir. Crear un juego no es simple y quieres dedicar la mayor parte del esfuerzo al desarrollo real y reducir cualquier otra sobrecarga.
Sin embargo, si no tiene un plan, está jodido desde el principio, por lo que debe encontrar una manera de planificar sin perder tiempo.

Lo que funciona para mi:

1. Mi propio GDD: cuando tengo una idea, la describo rápidamente en un documento de texto simple. Esto lo considero mi GDD. La diferencia entre un GDD real es que mantengo las cosas al mínimo, trato de no pasar de una página y enfocarme en las características principales. A veces, mientras escribo esto, me doy cuenta de que la idea no es tan buena y simplemente la pongo en una carpeta de trabajo pendiente para poder revisarla algún tiempo después en busca de inspiración (nunca la elimine).
2. Trello Board : cuando el documento está listo, extraigo las principales tareas necesarias para implementarlo. Estas tareas son algo como “crear una cuadrícula de 10 × 12” o “implementar soporte para la entrada del mouse”, “permitir que el personaje se entierre bajo tierra”, se entiende la idea. Todas estas tareas van en una lista de “Tareas”. No tiene que usar Trello, solo un simple bloc de notas llamado ToDo será suficiente. Con esto me mantengo enfocado realmente en las cosas principales que deben implementarse. Si me salteo esta parte, terminaré después de 2-3 horas trabajando en cosas totalmente ajenas.
3. Implementación : Si paso el GDD y sigo pensando que es una buena idea, a veces creo un prototipo rápido. Tengo una carpeta con elementos de muestra que descargué con el tiempo o creé yo mismo. Si realizo un prototipo, no dedico tiempo a crear otra cosa que no sean los requisitos básicos y cuando necesito un activo solo trato de usar lo que ya tengo. Si el prototipo no es divertido, vuelvo al GDD para reiterar o archivar el proyecto para más adelante. Si me gusta el prototipo, sigo adelante e implemento el resto de las tareas planificadas. Aquí uso el Tablero de Trello creado anteriormente y tomo las tareas de la lista de Tareas y las muevo a Hacer. Intento implementarlos lo más rápido posible mientras los selecciono de la mecánica más importante a la menos importante.
4. Refactorización : en este punto tengo implementada la mecánica planificada, me gustan, así que sigo adelante y me creo una nueva tarea para la refactorización. Aquí trato de desacoplar las dependencias, modificar las API incorrectas, etc. Con experiencia, las cosas que tiene que hacer aquí se reducen considerablemente. Me gusta tener esto por separado de la implementación real para poder controlar y, a veces, reducir el tiempo dedicado a tales actividades.
5. Revisión: lo que estaba bien y lo que no. ¿Qué puedo mejorar en el futuro y qué evitar? También creo futuros “mini-proyectos” dependiendo de cómo quiera desarrollar el proyecto en el futuro. Tal vez solo usé activos de marcador de posición, por lo que un próximo proyecto podría ser crear los activos. O tal vez un algoritmo no funciona tan bien, por lo que podría tener un proyecto para cambiarlo.

Repite este proceso.

El prototipo es opcional; Realmente depende de la tarea en cuestión. Si su implementación demoraría 3 días y el prototipo 2 días, entonces omítala. Pero si la implementación llevara 2 meses y el prototipo 2 días, sería un tonto si se salta esa parte. Y para algunas tareas realmente no tiene sentido hacer prototipos antes.

Esto funciona bastante bien para mí, me mantiene enfocado y encaminado mientras tengo una buena visión general del proyecto.

DESCARGO DE RESPONSABILIDAD: Esto es solo un proceso. No te ayudará a escribir un buen código, crear buenos elementos de juego, crear juegos divertidos, terminar proyectos, etc. Simplemente te ayuda a organizar el proyecto sin tener que dedicar demasiado tiempo a los detalles. Si en algún momento siente que necesita un diagrama UML, continúe y hágalo. Si necesita plazos, aplíquelos. Si aparece la necesidad de hacer algo más que no se menciona aquí, simplemente hazlo.

Muchos de los procesos respondidos aquí son sólidos. Si bien muchos cubren el nivel bajo (paso a paso), me gustaría dar respuesta a una aplicación más de alto nivel.

• El primer paso para crear un juego sería preguntarte por qué. ¿Por qué quieres crear este juego? O incluso más básico, ¿POR QUÉ quieres ser un desarrollador de juegos?

Encontrarás que responder esta pregunta (comenzar) te proporcionará una piedra de toque y una visión que siempre puedes mirar hacia atrás (especialmente cuando las cosas comienzan a ser difíciles / frustrantes). Será un recordatorio continuo de por qué está haciendo lo que está haciendo y puede revitalizar su resolución de atravesar cualquier barrera que esté obstaculizando su resolución o impulso.
CONSEJO: Tu POR QUÉ no debería girar en torno a ganar dinero, ya que es un RESULTADO (acuñado por Simon Sinek, autor de Start With Why).

• La segunda pregunta que debes hacerte es para quién estás haciendo el juego.

Si bien su ‘idea’ puede ser sólida, aún necesita comprender a su audiencia, así como el tipo de género o mercado de jugadores al que se dirige, si el juego es para usted y solo para autoedificarse o comprender el proceso, entonces busque ¡y desafíate a ti mismo hacia ese proceso de exploración! Sin embargo, si está buscando desarrollar / lanzar su título en el mercado, debe explorar la investigación adecuada hacia esa comunidad, género, tendencia del mercado y portales de distribución.

• En tercer lugar, debe preguntarse cuánto tiempo desea dedicar a la creación de este título, así como si se trata de una empresa ‘solitaria’ o si desea buscar ayuda (equipo).

Si no te das una fecha de FINALIZACIÓN proyectada, podrías estar sorteando durante meses o incluso años. Regalarse una fecha de finalización le permitirá volver al diseño / alcance de su proyecto y comprender objetivamente qué características, mecánica y carga de trabajo realmente puede permitirse dentro de ese período de tiempo dado.
Puede requerir ‘matar a algunos de sus seres queridos’, pero al menos su oportunidad para lograr un alcance / escala más realista hacia la finalización.
Espero que esto ayude. Si tiene alguna otra pregunta, ¡no dude en preguntar!

Hacer un juego no se trata solo de lanzar código y crear hermosos renderizados. No se trata solo de tener una historia interesante, hermosas escenas cortadas o los efectos de partículas correctos cuando disparas un misil. Es todas estas cosas combinadas … y mucho más.

No necesita tener una consola de juegos profesional o un dispositivo relacionado para explorar y entrar en el mundo de los juegos ahora. Los teléfonos inteligentes han revolucionado todas las esferas de la vida y lo mismo ocurre con el mundo de los juegos. Ahora, se trata más de aplicaciones de juegos que de CD de juegos. Sin duda, para una mejor experiencia de usuario, las consolas de juegos y los pads de juegos son una plataforma mucho mejor y conveniente para jugar juegos, pero como la tendencia está cambiando con la influencia de la tecnología de teléfonos inteligentes en la sociedad, el gusto por una plataforma de juegos y su accesibilidad también cambiado Otra consideración importante que está más relacionada con los desarrolladores es el hecho mismo de que el proceso de diseño y la plataforma en la que se desarrollará el juego deben estar de acuerdo con los últimos estándares establecidos. En pocas palabras, el diagrama de flujo fundamental que determina el proceso de desarrollo del juego debe ser esbozado a fondo en colaboración por los diferentes equipos que trabajan juntos para garantizar que el juego no pierda la mejor modificación posible mientras se desarrolla. Estamos hablando de GDD – Documento de diseño del juego ……
Leer más sobre: ​​El elemento mágico detrás de los juegos exitosos: GDD

Broma clásica de ingeniería de software burlándose de la administración: “El gerente le dice al programador: ‘comienza a codificar, y yo averiguaré los requisitos'”. El problema con muchos programadores nuevos es que compran la historia, por ejemplo, codificar primero.

Sí, eso es una pérdida de tiempo colosal.

No puedo hablar de “desarrollo de juegos”, ya que no lo hago para vivir. Pero teniendo en cuenta que el propósito de un juego es proporcionar entretenimiento interesante, supongo que la primera tarea es tener una idea de lo que podría ser divertido (“Vamos a volar lagartos gigantes”) y luego diseñar un plan del tipo de cosas que el usuario puede hacer (historias de usuarios, por ejemplo, “el usuario usa una bomba de neumáticos para volar lagarto gigante”) que conforman el núcleo de la juego, dibuje bocetos de dibujos animados de las diversas pantallas de juegos y luego pregunte a tantas personas como sea posible, “¿sería divertido?”

Dado que “diversión” es bastante difícil de precisar (personalmente, no estoy interesado en volar lagartos gigantes, prefiero volar los calamares gigantes), supongo que después de algunos comentarios positivos, alguien construye prototipos de las partes ( Aquí es donde la codificación comienza a suceder) y luego los ajusta de acuerdo con la experiencia real. Ignorando la mecánica del código (por ejemplo, “¿cómo adquiere el juego señales del usuario? ¿Cómo se mueve y muestra los objetos?”) Sospecho que esto requiere mucha experiencia para decidir qué hacer.

Si tiene suerte, escuchará de un programador de juegos real, pero “codificar primero” casi siempre está mal.

No soy un programador de juegos, pero, como cualquier programa complejo, primero debes tomar algunas decisiones básicas antes de comenzar a planificar la estructura del programa. Cosas como qué dispositivos de entrada desea admitir (teclado, mouse, joystick); qué sistemas de renderizado desea implementar (OpenGL, DirectX, software); un jugador o multijugador y, si es esto último, cómo desea manejar la red y los servidores necesarios. Debe decidir sobre los gráficos: 2D o 3D; Perspectiva en primera persona (como Doom and Quake) o “perspectiva externa” (es decir, representar al jugador desde la distancia) o incluso ambos como Duke Nukem 3D. ¿Será multihilo o no; necesitará capacidades de IA; qué depuración necesitará para ayudar con las pruebas; la lista continua…

Lo que estoy tratando de decir es que tienes que tener todos tus requisitos y opciones correctamente fijados. La programación de juegos generalmente requiere un código muy eficiente y optimizado para los altos rendimientos requeridos por el sonido y los gráficos. Agregar nuevos requisitos importantes después del hecho puede costarle mucho. Tendrá que “enchufarlo” y sufrir un rendimiento o tendrá que rediseñar el código que podría ser muy costoso a tiempo.

Una vez que tenga este “panorama general”, puede comenzar a planificar cómo puede estructurar su código en módulos, etc. Recuerdo haber visto el código fuente de Quake 2 hace unos años y utilizaron un enfoque “enchufable” para cosas como el motor de renderizado donde se implementaron DirectX, OpenGL y los motores de software como DLL y el módulo principal simplemente cargó el requerido y lo usó genéricamente; como polimorfismo en OOP; solo ellos usaron vainilla C.

Es casi como la arquitectura: ¡termina tus planes antes de comenzar a construir! Estoy seguro de que los programadores de juegos pueden darle más detalles: este es solo un enfoque general que describí.

No creo que haya un proceso paso a paso de desarrollo independiente, porque francamente nadie lo ha descubierto. No es un problema resuelto, y la tecnología cambia cada año, así que no creo que lo sea.

Lo que funcionó para mí es que prototipo lo suficiente de mi juego en Excel / VBA para tener una idea de lo que estoy tratando de hacer. Luego vuelva a codificarlo en C # / Unity y haga las tablas de la base de datos al mismo tiempo. Pero resulta que tengo mucha experiencia de excelencia (es mi herramienta de diseño de juegos), y en nuestra línea de producción específica con nuestro juego específico, esto tiene sentido.

Así que creo que, en general, es posible que desee considerar la creación de prototipos, dependiendo de los juegos que le interese hacer. No tienes que usar Excel, simplemente funciona para mí. Pero generalmente es una buena idea estar bastante avanzado en el diseño antes de comenzar a escribir el código de producción.

Si quieres ver cómo estamos desarrollando nuestro juego de aventura de apuntar y hacer clic, transmitimos todos los días en Twitch, haciendo arte, música, animaciones y programación.

Aquí está nuestro canal y nuestro horario:

gibbousgame – Twitch

STREAMS DE ARTE / ANIMACIÓN: MARTES, JUEVES Y VIERNES a partir de las 2 PM CET (3 PM GMT + 2)

STREAMS DE DESARROLLO: LUNES, MARTES, MIÉRCOLES, JUEVES a partir de las 4 PM CET (5 PM GMT + 2)

Para cualquier persona interesada en el diseño de un juego, recomiendo este libro: The Art of Game Design: Un libro de lentes: Jesse Schell: 9780123694966: Amazon.com: Libros

Como ex desarrollador de software pero no desarrollador de juegos y no jugador, este libro me ayudó enormemente a comprender los desafíos no técnicos del desarrollo de juegos.

Hay pocas cosas que requieren una orientación adecuada y podemos aprenderlo como otras cosas a través de Internet. El proceso de desarrollo del juego es una cookie pensada y para eso debes ir a un instituto de capacitación adecuado. Busque pasantes de TI y búsquelo usted mismo.