¿Cómo decides cuándo tu lista de funciones es lo suficientemente larga?

Sé un poco sobre esta pregunta, pero me parece que hay muchas opiniones diversas sobre el tema.

Sé desde la perspectiva de los jugadores que más opciones son casi siempre buenas. Pero por otro lado, si tiene más jugadores múltiples, significa mayor complejidad (metajuego) tanto para los desarrolladores como para los jugadores.

En el desarrollo, la complejidad y las limitaciones de tiempo siempre van de la mano. Otra sería la limitación de recursos y plataformas. Las posibles ramificaciones económicas de retrasarse para más adelante a veces también son una razón.

Entonces, según la experiencia de las personas aquí, aparte de lo anterior, ¿cuándo se deben cortar las características o ser para su posterior lanzamiento?

Yo diría que es un proceso de dos pasos para nosotros:

• Establece los objetivos del juego.
• Determine qué características nos ayudan a alcanzar estos objetivos.

La lista de características es lo suficientemente larga cuando esos dos puntos coinciden. Entonces:

1. Establezca nuestros objetivos : descubra todas las cosas que queremos que el juego haga para el jugador / revisor / quien sea, y luego exponga de manera medible. Por ejemplo, con nuestra última versión ( ver vid de prueba alfa aquí ), queremos hacer esto:

• Imágenes: queremos que cada crítica mencione que las imágenes son inusuales y sexys, especialmente para un título independiente. Esto es importante para nosotros porque los jugadores a menudo usan sus ojos como una medida rápida de calidad (aunque, por supuesto, ¡es solo una de muchas!), Y queremos que eso los atraiga.
• Exploración: también queremos recompensar a la gente por explorar el juego. Para decirlo de manera medible, queremos que se gaste algo alrededor de una quinta parte del tiempo de juego del jugador haciendo pequeñas cosas ordenadas fuera del juego central. Esto es importante para nosotros porque (IMO), gran parte del placer de un juego viene fuera de las áreas centrales esperadas (pensamos en cómo nos divierte hacer clic en piezas en Starcraft).
• Comunidad: queremos que todos le cuenten al menos a un amigo sobre el juego.

2. Determine las características que nos ayudan a alcanzar esos objetivos : estos casi se salen naturalmente de lo anterior. Entonces, las características que corresponden a los ejemplos anteriores podrían verse así:

• Imágenes: como estudio pequeño, si queremos imágenes sexys, no podemos enfrentarnos a EA o Sony por el realismo. Entonces, para acercarse al objetivo de los efectos visuales notables, una de las características del juego es una estética surrealista. (A partir de esto, podemos determinar qué herramientas necesitamos, y así sucesivamente).
• Exploración: Corolario de Tidbits a la acción del juego se cae de esto. En nuestro título más reciente , dejamos caer una referencia rápida a la cuestionable búsqueda de marineros de Ryo en Shenmue . Fue una tontería, ¡pero a la gente le gustó y habló de ello!
• Comunidad: nos preguntamos todas las formas de hacer que un juego valga la pena mencionar a un amigo. Hacerlo divertido es el # 1, por supuesto. Pero también podríamos recompensar a los jugadores con un elemento o nivel especial si tuitean al respecto. Pokémon hizo que valiera la pena tener amigos que retomen el juego: hay algunas criaturas que solo puedes obtener al interactuar con otras personas.

Cuando pasamos por este proceso, nos ayuda a determinar:

• Cuánto necesitamos implementar para un producto mínimo viable ( MVP ).
• Lo más importante, qué puede esperar y qué podemos dejar por completo.
• Cuando finalmente tengamos todas las características que necesitamos.

¡Vale la pena señalar que no nos atenemos servilmente a estas reglas! La mayoría de las veces, algunas cosas asombrosamente interesantes surgen como resultado de la creación de prototipos a mitad del proyecto y solo un vagabundeo general. Especialmente para juegos pequeños como el nuestro.

La complejidad no hace que tu juego sea divertido.

La combinación correcta y el equilibrio de los elementos de juego lo hacen. El jugador debe ser empujado a la medida de su nivel de habilidad y tener una sensación de dominio al conquistar desafíos.

Tu lista de funciones debería cambiar cada vez que sientas que el juego actual no es divertido. Estos cambios deben realizarse dentro de sus limitaciones de presupuesto / tiempo. Asegúrate de que cualquier cambio que hagas agregue valor a tu juego.

Además, prototipo temprano, no solo escriba una gran lista de características y asuma que todo será divertido cuando se combinen.

La perfección se logra, no cuando no hay nada más que agregar, sino cuando no hay nada más que quitar.

-- Antoine de Saint-Exupéry

Cuando el tiempo y el esfuerzo necesarios para incluirlos es mayor que el valor que agregan al juego .

Por ejemplo, si estabas creando un juego deportivo o algo en lo que es probable que los jugadores quieran mostrar sus habilidades, el multijugador es imprescindible. Guitar Hero no sería lo mismo sin él. Sin embargo, un juego exclusivamente individual, en el que llegas de principio a fin por tu cuenta, después de una historia o trama no necesita multijugador. El sistema de multijugador de mala calidad en Grand Theft Auto San Andreas es un testimonio de eso (a pesar de que esa compañía probablemente no encontró el multijugador demasiado difícil).

Además, las características que realmente no encajan con la historia del juego, simplemente están ahí porque pueden serlo. Si no es completamente esencial para la jugabilidad, probablemente sea una buena señal de que pueden ser empujados a una versión posterior si el tiempo es un problema.

La cuestión es que las características adicionales no son el elemento por excelencia de un juego. Una historia emocionante combinada con un juego agradable es.

Si bien hay un grado en el que la variedad de características es excelente (poder hacer toneladas de cosas al azar en un juego de GTA-ish, tener toneladas de variedad de armas y accesorios en un juego de rol o juego de Call of Duty-ish, etc.), Creo que una jugabilidad mínima centrada estrictamente en algunas características principales puede ser muy efectiva.

Mire Portal, tomó su mecánica principal y realmente construyó sus acertijos alrededor de eso sin necesidad de un montón de desorden adicional.

Creo que ser estricto acerca de mantener la lista de características lo más mínima posible y desarrollar algunas características principales permite un proyecto más factible y, a menudo, una experiencia más agradable (si Portal agrega elementos RPG y secuencias de conducción y slowmo y cualquier otra "característica genial" ", ¿habría sido tan bueno? ¿La mecánica central habría sido tan pulida?).

Ahora, como desarrollador independiente, estoy sesgado, pero creo que generalmente "menos es más" en las características, y aunque algo podría ser genial o popular en este momento, si no mejora notablemente la experiencia general, debe ser cortado

Descubrí por experiencia personal que es mejor evitar agregar nuevas funciones no planificadas lo antes posible.

Desde el punto de vista del diseño, una característica que se ha agregado durante un momento "no sería bueno tener el período de la característica x" agregará mucho tiempo de desarrollo, podría no integrarse bien con el código y podría no encaja completamente con el resto de su diseño.

En el peor de los casos, un proyecto que ha tenido muchos de estos momentos puede parecer una combinación de características desordenada y pirateada, que realmente debería haber pasado mucho más tiempo en la fase de diseño y, como resultado, parece menos profesional.

Como guía general, trato de seguir estas reglas:

• Si aparece una nueva característica al principio del proyecto, tómese el tiempo para volver a la fase de diseño y ver realmente cómo esta característica puede funcionar con su producto sin dejar de ser coherente con el resto del diseño.

• Si el proyecto se está acercando al lanzamiento, considere hacer una lista de características para agregar a una nueva versión.

• Si encuentra que surgen muchas características que realmente desea implementar, tal vez debería considerar volver al diseño y ver por qué estas nuevas características no se han considerado antes, posiblemente debido a la falta de esfuerzo invertido en La fase de diseño.

Obviamente, esto se ajusta mejor a algunos proyectos que a otros, pero realmente si tiene una función que aparece tarde en el proyecto, probablemente estará bien sin ella, al menos hasta que comience a trabajar en una nueva versión.

Mantenga listas cortas, sea ágil

No cree listas de características en absoluto, o si lo hace, compílelas muy cortas, solo valen unas pocas semanas de desarrollo.

Desarrolle en un estilo ágil: comience con las pocas características más importantes, pruebe, en función de lo que funciona y lo que no, y luego piense si vale la pena agregar algunas características más (podrá juzgarlas mucho mejor si ya tienes algo de experiencia con el juego básico).

Cómo juzgar la característica individual

Aparte de eso, estaría de acuerdo con el criterio bennybdbc, "Cuando el tiempo y el esfuerzo necesarios para incluirlos es mayor que el valor que agregan al juego".

Dicho esto, también debes considerar el mundo "externo":

• ¿se está quedando sin dinero o sin tiempo dado por un contrato?
• ¿te estás quedando sin espacio de publicación de medios (DVD completo)
• ¿te estás quedando sin espacio de rendimiento (las nuevas características harían que el juego se ejecute demasiado lento)?
• ¿Se publicará pronto un juego de la competencia?

Los problemas simples de la vida real como ese también deben considerarse, a menos que esté desarrollando el juego solo por diversión.

Cuando te quedas sin papel para escribirlo.

El límite definido será el tamaño de los medios; por ejemplo, no puedes incluir 10 GB de funciones en un DVD de 4,7 GB.

Tampoco quieres tener muchas funciones para complicar demasiado el juego. La mejor manera es preguntarse si esto será significativamente divertido para el jugador. ¿Va a comer demasiado en nuestro tiempo de desarrollo? ¿Es esto posible?