Vale la pena agregar características 'futuristas' a nuestro juego, ¿o deberíamos centrarnos en otro lado?

Soy programador principal en un estudio de juegos indie de tamaño mediano. Este es nuestro primer juego como equipo. Estamos trabajando en un juego futurista de FPS, con un plan de negocios para compartir ganancias.

De todos modos, tenemos algunos programadores muy buenos, que tienen la capacidad de crear características nunca antes vistas (fluidos realistas reales, destrucción de mallas de procedimiento, cajas de cielo de procedimientos, etc.) Y me pregunto si hay algún punto para implementar estas cosas. Toman mucho tiempo, pero se ven brillantes. Nuestro objetivo es un ciclo de desarrollo de 12 meses. Entonces deberíamos hacer esto, o simplemente hacer un juego estándar.

No intentes hacerlo porque sabes que puedes hacerlo.

La jugabilidad debe ser lo primero, todas las cosas (incluso los gráficos) son secundarios. Si el juego es divertido y agradable pero tiene gráficos pobres (o no de la próxima generación), seguirá siendo divertido y agradable y la gente lo jugará, y también tu metacrítico será bueno. De lo contrario, si el juego tiene gráficos y características impresionantes (fluidos realistas, destrucción de mallas de procedimiento, etc.) pero no es entretenido o difícil de jugar (malos controles, etc.), la gente no lo jugará. Sin jugadores = sin dinero y también mal metacrítico.

Así que primero planifique el juego que desea hacer y piense en sus características de juego, sus situaciones jugables. No intentes presionar para que esa característica X encaje en el juego solo porque se ve genial. Si realmente no tiene sentido, o si no va a representar una parte importante del juego, simplemente déjalo.

Además, evite tratar de construir un juego en torno a una de esas características increíbles si no tiene sentido o si cree que no va a ser divertido. Por ejemplo: podrías pensar "Tengo destrucción de malla de procedimiento, así que obliguemos al jugador a destruir todo antes de que pueda continuar avanzando en el juego (para que pueda ver cómo se destruyen las mallas de procedimiento)".

En resumen: primero piense en su juego y en sus necesidades. Desde esa base, planifique su fase de desarrollo, y luego verá si hay suficiente espacio para una o más de estas increíbles funciones (y si tiene sentido agregarlas a su tipo específico de juego).

Teniendo en cuenta que un ciclo de 12 meses no significa que dejes de codificar en la semana 52 y lo empujes por la puerta, estoy del lado de las respuestas ya dadas, que el juego debe ser lo primero y solo agregar características interesantes si ayudan al juego jugar.

Idealmente, tendrá tiempo para realizar una prueba beta con candidatos de lanzamiento, por lo que la mayoría de los trabajos, excepto las correcciones de errores de emergencia y el ajuste, se detienen en la semana 50.

Las funciones completas deben estar implementadas mucho antes de la versión beta, por lo que quizás no haya nada antes de la semana 46 para que pueda hacer pruebas internas para que todo sea sólido antes de pulir en versión beta. Así que en realidad solo son 46 semanas de trabajo antes de comenzar a preparar el juego.

El pensamiento clave es decidir si hacer que su ingeniero en activo trabaje en un sistema vale la pena el intercambio de ese ingeniero que aún no está trabajando en su próximo título. "¿Qué más podría estar haciendo?" Es el costo oculto de cualquier decisión.

Por cierto, los volúmenes de fluidos simulados, la destrucción de procedimientos, los cuadros dinámicos del cielo, etc., se han hecho en juegos comerciales y la razón por la que no escuchas tanto sobre ellos es que el juego en sí siempre fue más importante.

¡Mucha suerte, cualquier cosa que hagas será emocionante!

Si sus programadores son tan buenos, use esas habilidades para entregar a tiempo y por debajo del presupuesto. Y entre ahora y el comienzo de su próximo gran proyecto, piense en cómo aprovechar mejor las habilidades que tiene su equipo, con el mayor presupuesto que viene con un buen historial.

Pero si debe hacer las cosas de esta manera, elija UNA cosa genial. No todos, ni siquiera dos: nunca introduzca demasiados factores de riesgo a la vez. Y el que elijas DEBE ser de alguna manera central en la jugabilidad, porque todo lo demás es simplemente esponjoso. Cuando eres Blizzard, puedes permitirte sentarte agregando características geniales, aunque sus decisiones siempre son de carácter empresarial.

Pero tratar de implementar todas o incluso algunas de las cosas que sus codificadores pueden hacer, porque parece genial y piensas que puedes hacerlo, te llevará a una gran caída.

Una vez más, la clave es NO agregar nada que no contribuya con certeza a la dinámica central del juego, sea lo que sea (suena como si eso aún no se hubiera definido).

"Tenemos algunos programadores muy buenos, que tienen la capacidad de crear funciones nunca antes vistas"

Nada personal, pero debo decir que lo dudo. Valve (para elegir solo uno) tiene algunos de los mejores programadores de la industria, si no del mundo. Havoc también tiene algunas personas bastante inteligentes: hay docenas de otros ejemplos. Todos tienen más codificadores que tú, más tiempo y presupuestos más altos.

Ahora, tal vez de alguna manera has logrado reunir a un grupo de genios absolutos. Pero sería muy cuidadoso con la brecha entre lo que los programadores piensan que pueden hacer y lo que realmente podemos hacer en un tiempo limitado y con un estándar liberable. Como han dicho otras personas, puedes (si tienes mucha confianza) elegir uno. Personalmente, me gustaría pasar por el proceso de llevar un juego al mercado al menos una vez antes de intentar disparar a la luna.