Estoy en preproducción de un juego de estrategia y estoy tratando de determinar si el juego central será divertido. Una buena técnica para determinar esto es reducir el juego a su mínimo producto viable (MVP) y ver si eso es divertido. Si el MVP no es divertido, entonces ninguna cantidad de contenido o características adicionales lo harán divertido.

Tengo dificultades para determinar el MVP para un juego de estrategia, ya que estoy demasiado lejos de las malezas para ver cuáles de las muchas características de diseño son mecánicas centrales y cuáles son innecesarias.

Simplemente como ejemplo, digamos que StarCraft2 es el juego de estrategia que quiero hacer. ¿Cuál sería el MVP para SC2 para demostrar que su juego principal es divertido?

Real-Time Strategy es un género que combina múltiples juegos en uno. Tiene un juego de administración (administración de recursos y órdenes de construcción), un juego de rompecabezas (construir una base con un diseño funcional pero fácil de defender), dos tipos diferentes de juegos de exploración (explorar el mapa y explorar qué unidades vencen a qué otras unidades), y un juego de tácticas (controlando tus unidades en la batalla). Obviamente, no puedes crear todos estos cinco juegos a la vez, así que primero debes concentrarte en uno de ellos.

En esta respuesta, me estoy centrando en dos de estos juegos que considero más esenciales para el género: Control de unidades y construcción de bases.

MVP de control de unidad

1. Cree un objeto de juego "tanque" controlado por el jugador (representado como un cubo sin textura) en un plano vacío que se mueve a una nueva posición cuando el jugador hace clic allí.
2. Agregue objetivos de IA inmóviles (representados por un cubo en un color diferente) que se eliminan cuando sus HP bajan de 0, y la capacidad del tanque de disparar al objetivo más cercano para reducir su HP.
3. Agregue la capacidad de los objetivos de disparar cuando el tanque del jugador esté dentro del alcance.

Ahora tiene un juego de estrategia / rompecabezas jugable: navegue su tanque de un objetivo a otro de manera que no pelee más de uno a la vez y los destruya a todos antes de que se destruya. Esto es básicamente cómo atacas una base con torretas defensivas en un juego de estrategia en tiempo real.

Los siguientes pasos a seguir en ningún orden en particular:

• Agregue una IA simple a los oponentes para que puedan moverse y no solo disparar
• Agregue múltiples unidades de jugador para controlar y la IU para seleccionar unidades
• Agregue edificios (consulte "MVP del edificio base" para más detalles)
• Agregue más tipos de unidades con diferentes rangos, fuerzas de arma y puntos de golpe
• Agregue terreno de bloqueo al mapa y encuentre rutas a la unidad AI para que puedan navegar a su alrededor.
• Reemplace las unidades con gráficos correctamente animados
• Agregue condiciones de ganar y perder

MVP de construcción base

1. Crea un plano vacío y permite que el jugador coloque un edificio en ese plano haciendo clic
2. Agregue diferentes tipos de edificios y una interfaz de usuario que le permite al jugador elegir qué edificio construir
3. Agregar tiempos de construcción y contadores de recursos
4. Agregue edificios que creen recursos a intervalos regulares (todavía no implementaría unidades de trabajo porque requieren demasiada programación de IA para funcionar) y un conjunto de reglas para cuándo puede construir qué edificio ("solo puede construir una fábrica cuando tiene al menos uno terminó cuarteles ").

Ahora ha implementado los primeros minutos de un juego de Starcraft: averiguar el orden de construcción ideal para obtener los edificios que desea lo más rápido posible.

De hecho, podrías quedarte aquí y pulirlo, y tienes un juego simple de administración de recursos. Pero si todavía está seguro de que desea crear un RTS, los siguientes pasos no estarían en ningún orden en particular:

• Agrega una IA que construya sus propios edificios
• Agregue características de terreno que eviten que se construyan edificios (o son un requisito para colocar ciertos edificios, como "las granjas solo se pueden construir en terrenos fértiles")
• Agregue unidades móviles (consulte "MVP de control de unidades" para más detalles) que pueden destruir edificios enemigos
• Agregue trabajos de construcción a edificios individuales que pueden iniciarse, tomar un cierto tiempo para completarse y el jugador puede abortarlos.
• Cree tipos de construcción que interactúen entre sí de alguna manera (en Starcraft, estos serían complementos Terran o pilones Protoss, por ejemplo)

Tengo muchas ganas de jugar tu juego.

¿Cuál sería el MVP para SC2 ...?

Si la respuesta fuera generalmente conocida, ¿no crees que habría mucha más competencia para SC2? SC2 es el producto de innumerables horas de decisiones de diseño; cada parche que se lanzó a SC1, el diseño inicial de SC1, las lecciones de WC y WC2 que se incluyeron en el diseño de SC1, y así sucesivamente.

El diseño del juego no es una ciencia exacta. El diseño del juego funciona con infinitas posibilidades. Claro, hay características bastante estándar en RTS, pero la pregunta aquí no es ¿Qué es un RTS para todos? porque todos no están construyendo tu juego, tú sí . Entonces es más bien, ¿Qué es un RTS para ti? (¿y por qué?)

Analizar el trabajo de otros es importante; pero comenzar tu propio trabajo es mucho más importante. La investigación es importante; pero no dejes que te empantane. Comienza a crear diversión.

MVP es una idea brillante, pero te estás perdiendo el espíritu: los MVP tienen que ver con la creación de prototipos de tus ideas, no con pensar demasiado en el trabajo tuyo y de los demás. Ensuciarse las manos es más importante que preocuparse por cuáles son los supuestos mecanismos mínimos para un RTS. Muchos juegos se pueden considerar RTS que caen en gran medida fuera de la definición habitual de ese género. Obtenga una demostración y haga que la gente comience a jugarla; y que decidirá si su producto es viable, así como género.

Estoy un poco lejos de la maleza para ver

Hasta que comience la creación de prototipos, ese será el caso, y muchas preguntas seguirán siendo difíciles de responder.

Algunos aspectos que diría son bastante fáciles de decidir qué necesita para un RTS en generel. Dependiendo de su concepto, necesita una "unidad", que se puede construir, ordenar o el juego simplemente comienza con ella.

Comenzando con Starcraft como su ejemplo, implemente quizás una unidad de trabajo, un edificio y una unidad de combate. Su edificio debería poder construir ambos. En general, ni siquiera agregaría un recurso para cosechar, pero dado que Starcraft depende en gran medida de él, en ese caso deberías hacerlo.

La parte difícil es qué características necesita implementar también. Tu unidad de combate debe ser capaz de "luchar". Entonces, ¿puede disparar? ¿Puede atacar en cc? ¿Qué son los enemigos? ¿Necesita más unidades diferentes (por ejemplo, aire?)

Sí, solo debes comenzar con una carrera, por lo que básicamente solo tienes partidos espejo, por así decirlo. Además, no necesita un mapa (si eso no obstaculiza ninguna característica muy importante), solo un cuadrado para avanzar. Cual es el objetivo? ¿Destrucción del enemigo o puntos de victoria, controlando puntos de captura?

Creo que el problema con RTS es que básicamente tienes tantas características importantes y elementos básicos que aún necesitas implementar para tener un MVP, aunque es realmente difícil decir cuáles son los elementos centrales de tus juegos.

En mi opinión, se trata de comparar tu juego base con otros RTS, y hay muchos de ellos, e incluso continuaron en una secuela, no son lo mismo.

• C&C Tiberium y Red Alert Series: comenzando con el edificio principal, construya edificios por menú sin una unidad de construcción, construya unidades en el menú cuando exista el edificio correspondiente, diferentes tipos de unidades individuales (a pie, vehículo terrestre o aéreo)
• Dawn of War 1 & 3, Company of Heroes: Edificio base con unidades de construcción, sin recolección de recursos activos (generación pasiva por puntos de control), la mayoría de las unidades se basan en grupos
• Battlefleet Gothic: sin edificios, sin recursos, diferentes tipos de unidades, no reemplazables, las habilidades son extremadamente importantes

Todas estas diferencias hacen que los RTS sean muy diferentes. Tratar de desarmar un juego a estos conceptos básicos es mucho más complicado que el ejemplo que Credit Extra dio con los juegos de carreras: Acelerar bloques, colisión, eso es todo.

Lo que hace que tu juego sea único

La razón clave para desarrollar un MVP es que puede probar su idea temprano y liberarla si es necesario. Es decir, se asegura de terminar siempre el desarrollo con un "algo", en lugar de nada.

Sin embargo, eso no significa simplemente hacer la versión más básica de un RTS que puedas. Significa hacer la versión más básica de tu RTS que pueda.

Descubrir exactamente qué características y activos son necesarios es un arte en sí mismo. Sin embargo, su objetivo debe ser minimizar la recreación de cosas que sabe que funcionan e incluir tantas cosas que no. Es decir, solo debe incluir cosas que son genéricas para otros juegos, si lo necesita para probar adecuadamente sus ideas específicas:

• ¿Necesitas IA sofisticada? (Para un MVP de un nivel, puede salirse con la suya con un orden de construcción fijo que la oposición siempre usa).

• ¿Necesitas más de una facción? (Tal vez tu juego se centre en la sinergia entre dos carreras y esa es la clave. Pero tal vez en realidad sea solo un "gusto tener")

• ¿Necesita tener unidades de construcción y recursos? (Tal vez todo lo que necesita es una escena de batalla prefabricada con un número determinado de unidades, tal vez todas sus ideas clave se centren realmente en el lado de las habilidades y tácticas)

• ¿Necesitas tener multijugador? (Si el objetivo del juego es hacer un MMORTS de 6000 jugadores; entonces sí, probablemente lo hagas)

Por supuesto, esto también incluye activos artísticos:

• ¿Realmente lo necesitas para correr en 3D? (quizás tenga características de terreno no plano)

• ¿Realmente necesitas modelos de personajes múltiples? (tal vez sí, tal vez cada unidad tiene una historia personal y eso es importante para usted)

• ¿Realmente necesitas iconos para el árbol tecnológico? (de nuevo, tal vez tengas ideas para innovar la interfaz de usuario para juegos RTS y ese es tu punto de venta).

Pero otra vez; solo desea incluir las cosas que necesita y dejar todo lo que no quiera para una fecha posterior.

El principio MVP no siempre funciona bien con un RTS, porque es la gestalt de todas sus opciones de diseño lo que lo hace divertido, pero hay algunos puntos clave a los que puede apuntar cuando comprende lo que hace que un RTS sea divertido.

Las reglas generales para hacer un RTS divertido son:

1- Haz que todas las tácticas sean viables como sea posible. Las tácticas de META deberían requerir que uses múltiples tipos de unidades juntas.

Esto requiere una lista vacía de clases de unidades para elegir con sus habilidades especiales finales para poder evaluar, pero no necesita cada tipo de unidad. Una clase de unidad es una unidad que cumple una función general en tu ejército y / o tiene una habilidad especial. Si tu plan es que cada facción tenga unidades similares con máscaras diferentes y solo estadísticas ligeramente modificadas, solo haz una facción. Si cada facción tendrá varios niveles de algunas de sus unidades que son solo versiones mejoradas una de otra, solo crea un nivel de esa unidad. Si cada facción tiene un conjunto único de unidades, es posible que necesites construirlas todas. Solo ten en cuenta que quieres probar tantas clases como puedas al principio, porque agregar nuevas clases más tarde puede alterar por completo el equilibrio del juego.

2- Haz que las tácticas de META cambien a medida que avanza el juego. Esto se puede hacer introduciendo nuevas unidades con el tiempo o cambiando las circunstancias de tus batallas.

Al igual que en el n. ° 1, esto puede requerir una lista de clases de unidades mayormente desarrollada, pero se trata más sobre cómo probar su MVP. Tu MVP debería poder restringir qué unidades están a tu disposición para que puedas asegurarte de que los primeros niveles sigan siendo divertidos sin todo el contenido del juego final para eliminarlo.

3- Equilibra el tiempo que lleva administrar tu base con la guerra. Un error común con los juegos RTS es una automatización de base demasiado pequeña, lo que significa que su producción se va al infierno si tiene que detenerse para controlar una batalla.

Esto requiere un sistema económico completamente enjuagado para probar. Una prueba de MVP con 5 tipos de edificios puede funcionar bien, pero un producto final con 30 edificios puede empantanar al jugador con tareas económicas y forzarlo a volver a visitar el tablero de dibujo sobre cómo maneja / automatiza su economía. La mejor opción aquí es hacer todos los edificios que planea tener para que pueda tener una idea de cómo se siente una base a gran escala. Aquí lo mejor que puede hacer es esperar en los gráficos sofisticados hasta que finalice su economía.

4- Haz que el medio ambiente afecte tus elecciones tácticas.

Aquí es donde las pruebas MVP le darán el mayor beneficio. Agregar factores ambientales como ventajas de terreno elevado, flanqueo, armas especiales, moral de la tropa, clima y varios niveles de paisajes abiertos tienen el mayor potencial para diferenciar tu juego y hacerlo más divertido, o arruinar completamente la experiencia porque hiciste tus misiones nocturnas son tan oscuras que los jugadores se frustran cada vez que tienen que jugar una. Puede hacer estas pruebas bastante pronto antes de tener una lista completa de unidades o economía; Entonces, este sería mi primer objetivo de prueba. Además, saber con qué entornos tendrán que lidiar sus unidades hablará mucho sobre cómo necesita diseñarlos y equilibrarlos. Eso'

No todos los géneros conducen a un "producto mínimamente viable". O al menos, no de la misma manera y no lograrán el mismo propósito.

Considere un juego de plataformas 2D basado en niveles. Un MVP para tal cosa se trata principalmente de encontrar buenas mecánicas de salto. No puedes cambiar la física de salto de tu personaje una vez que comienzas a diseñar niveles, por lo que debes precisarlo temprano. Así que eliges algo de física de salto, construyes un par de niveles de prueba y descubres qué tipo de física se siente bien. También intentas algunas mecánicas, como arrojar algunos enemigos y averiguar cómo quieres que funcione, y / o terrenos y habilidades especializadas (llevar objetos, etc.).

El final de ese proceso es lo que se consideraría el MVP.

Un RTS realmente no hace eso. O al menos, nunca se detiene realmente . Cada aspecto de un RTS alimenta otros aspectos del mismo. Si bien es cierto que hay algunas cosas que simplemente no cambias más allá de cierto punto en el desarrollo, el desarrollo general es mucho más fluido. Aquí hay un ejemplo.

Hacia el final del desarrollo de StarCraft I, Blizzard hizo lo que yo consideraría un cambio bastante estremecedor. En versiones anteriores, cada edificio zerg que disponía de unidades producía su propia larva, que solo se usaba para producir esas unidades. Básicamente, en esa construcción, la larva era una forma alternativa de colas de unidades. Esto se cambió a la mecánica que conocemos hoy para los Zerg: todas las unidades Zerg provienen de larvas producidas en una estructura central.

Ese cambio cambió fundamentalmente la naturaleza de los zerg como raza. Para otras razas, el cambio de tecnología (cambiar el edificio de producción de la unidad principal) es un proceso que requiere una inversión sustancial. Para los zerg, simplemente derribas un edificio y toda tu infraestructura de producción puede construirlos.

Pero esto alimentó la dinámica de los zerg en términos de diseño de la unidad. Mira, los Zerg de SC1 se construyeron básicamente alrededor de tres unidades fundamentales: Zerglings, Hidraliscos y Mutaliscos. Esta es su unidad básica, y todo lo demás es esencialmente una unidad de soporte para ellos. Así que los zerg realmente no cambian de tecnología como otras razas; agregan algunas X adicionales a su composición de ejército existente. Los grandes interruptores tecnológicos para los zerg se centraron principalmente en la unidad fundamental sobre la que se construye el núcleo de tu ejército.

Cada elemento de diseño alimenta al otro. Si cambia su modelo de producción, ahora tiene que cambiar el diseño de su unidad para compensar.

Un "producto mínimamente viable" para un RTS simplemente no funciona en general; todas las mecánicas de un RTS interactúan de muchas maneras para que un producto "mínimo" sea algo más que, esencialmente, un juego completo.

Así que te sugiero que hagas un RTS a pequeña escala como tu MVP. Un RTS completo . No necesita todos los gráficos allí, pero sí necesita todas las cosas que un RTS realmente posee. Eso podrá cumplir la función de un MVP: descubrir cómo hacer el juego que quieres hacer.

Aquí hay varias respuestas adaptadas a los RTS, pero quería señalar algo que es universal al concepto de un Producto Mínimamente Viable (MVP).

MVP es un concepto que existe desde hace mucho tiempo, pero se hizo muy popular a medida que el desarrollo Ágil apareció en escena. El concepto es bastante simple en su núcleo: es el producto más pequeño que es "lo suficientemente bueno". Eso es.

Lo que hace que MVP sea complicado es que es subjetivo y depende del contexto. Si está trabajando en los últimos hitos de un contrato militar, MVP es nada menos que "el producto pasa las pruebas de calidad". La calificación de su producto implicará probar cada uno de los requisitos establecidos para usted al comienzo del contrato (quizás hace años). Nada menos que eso califica como MVP.

Al principio de un proyecto, MVP es una barra mucho más baja (¡gracias a Dios!). Sin embargo, también es todavía subjetivo. Lo que creo es que el producto mínimo como desarrollador es muy diferente al del propietario del producto, y aún diferente de lo que pueda pensar el vicepresidente de mi empresa. Tienes que elegir la perspectiva del actor que estás utilizando al definir un MVP.

La voz más crítica, en mi opinión, es la de la persona que administra recursos finitos: su tiempo y su dinero. En una corporación, puede ser un líder de proyecto o alguien en finanzas. Podría ser un vicepresidente. Si eres una pequeña empresa independiente o alguien que escribe juegos en solitario, esa persona podrías ser tú . Pero no es el desarrollador normal del juego tu . Es usted quien cierra las herramientas de codificación y el software de arte y abre Excel para asegurarse de que puede pagar las facturas este mes. Es usted el que tiene que sopesar el equilibrio entre pasar otra noche codificando su pequeño proyecto de pasión versus salir con amigos.

Como estamos hablando de pequeños MVP (de eso es de lo que hablaba el video que vinculaste), podemos comenzar a usar el enfoque de Agile para el concepto. Lo diría de esta manera:

El MVP para cualquier iteración / sprint / fase es el producto mínimo que justifica el gasto de recursos en el tiempo dedicado a construir ese producto.

Esta definición es la razón por la cual la definición militar de MVP que usé anteriormente es válida: para ellos, lo único que puede justificar los millones gastados en un contrato militar es un producto exitoso que hace todo lo que se prometió. Pero para usted, podría estar justificando una semana o un mes de tiempo. La barra es más baja.

Entonces, para esto, quítate la gorra de desarrollador, ponte el traje y los pantalones a medida, y hablemos de lo que sucede después. Desarrollador que acaba de sacar un producto. ¿Que vas a hacer con eso?

Más adelante en el proceso, una opción será enviarlo: ganar dinero lanzando el juego. Y, de hecho, esa es una definición clave de MVP que nunca debe ignorarse. Si se puede enviar un producto , es un MVP candidato, porque ganar dinero justifica muchos recursos de desarrollo. Pero al principio, no lo vas a lanzar. Entonces el MVP tiene más matices:

En el desarrollo inicial, el MVP es el producto mínimo que le permite aprender algo que vale la pena el tiempo que llevó producirlo.

Nota: esto puede no ser lo que pretendías aprender. Si lo que aprendes es "este juego nunca lo logrará, así que deberíamos dejarlo ahora ... pero maldita sea, valió la pena intentarlo", entonces ganaste. Trabajaste un poco y sentiste que valía la pena. Por otro lado, si decides hacer el juego y piensas "maldita sea, ¿acabamos de perder cuántos meses de nuestras vidas?!?" entonces esa es una fuerte sugerencia de que no estabas haciendo un buen trabajo al limitarte a MVP. Si se limitara a MVP correctamente, las iteraciones pasadas ya se habrían considerado pagas por sí mismas, no se arrepiente.

Así que ahora podemos llegar a los ejemplos que otras personas escribieron aquí. Estas son respuestas que exploran cuál es la cantidad mínima que necesita para aprender algo. Pero todos pierden un detalle general: ¿cuál es su próximo movimiento?

El MVP depende de lo que planeas hacer con ese MVP una vez que se haya creado. Toma la gran respuesta de Philipp y el comentario de bxk21. La respuesta de Philipp abogó por dos "minijuegos", uno de control de unidades y otro de construcción de bases. bxk21 argumentó que esos no son tan importantes como el aspecto de gestión del tiempo. Entonces, ¿quién tiene razón?

Esa es una pregunta capciosa. Ambos tienen razón, en ciertos entornos. Presumiblemente, está a punto de entregar el MVP lanzado a algunos jugadores de prueba para obtener comentarios. ¿Qué tipo de jugadores de prueba planeas usar? ¿Son profesionales de RTS? Si sus expertos en juegos no son expertos en RTS, entonces la respuesta de Philipp probablemente sea acertada. Estás mirando las pequeñas piezas de hormigón del juego. Tendrán suficientes antecedentes para poder comentar sobre ese tipo de cosas.

Ahora digamos que de alguna manera obtienes playtesters como TLO, Day [9] o MVP. Estos son jugadores RTS de nivel profesional (o en el caso del Día [9], al menos una mención de honor, ya que no creo que juegue profesionalmente). Si estos son sus jugadores de prueba, entonces la opinión de bxk21 es probablemente la correcta. No les importarán los pequeños detalles sobre si construyes edificios o si los edificios se construyen solos. Les van a importar las cosas sutiles, como la gestión del tiempo y la capacidad de equilibrio. Ahora no tendrás este tipo de cosas en las primeras pruebas, pero deberías ser capaz de dejar que se vea su sabor . Debes concentrarte en hacer un juego que demuestre la sensación que quieres que el juego represente con un alto nivel de habilidad.

Así que averigua cuál quieres que sea tu próximo movimiento. ¿Qué quieres hacer con tu producto? Luego averigua cuál es tu MVP con respecto a ese objetivo.

La palabra clave en "Producto mínimo viable" es producto.

Un producto es algo por lo que cobra dinero con la expectativa de que alguien lo compre. Si lo que quieres es un MVP, tiene que ser lo suficientemente bueno para cualquier precio que tengas en mente. Es decir, puede tener un alcance limitado, pero debe estar completo suficientemente como para ser apto para la comercialización.

Supongo que probablemente no quieras un MVP, porque estás en el punto en que tienes alguna idea pero ni siquiera sabes si vale la pena convertirlo en un producto. Parece que lo que quieres construir es una demostración o algún otro prototipo. La forma típica de hacer esto es hacer una sola porción vertical del juego que incluya todas las mecánicas que quieres probar. En un SC2 tipo RTS, esa podría ser una sola misión (si estás haciendo un solo jugador) o un solo mapa multijugador.