¿Puedo usar la función creep para mi ventaja? [cerrado]

¿Puedo usar la función creep para mi ventaja?

Cada vez que hago un prototipo de un juego, se agregan características inadvertidamente. Esto sucede ya sea por coincidencia, o resulta fácil de agregar según el contenido existente.

Si conozco el género del juego, ¿puedo comenzar a hacer la mecánica básica y agregar características a medida que se hacen evidentes?

Por ejemplo, si quiero hacer un juego de plataformas en 2d en el transcurso de 6 meses, ¿puedo comenzar a correr, saltar, disparar, etc. y agregar las mecánicas principales a medida que las encuentro inadvertidamente? ¿O es esto demasiado arriesgado de una inversión de tiempo sin un plan predeterminado?

Mi lógica detrás de esto es que el diseño será más rentable. Las opciones de diseño se construirán más fácilmente en torno a lo que es fácil de hacer (en el tiempo).

En resumen, ¿hay algo malo en construir un juego antes de diseñarlo?

Esa es una pregunta interesante. Principalmente porque responderla plantea el dilema de tonos de gris versus negro vs blanco.

¿Hay algo malo en construir un juego antes de diseñarlo?

Si piensa que esa pregunta es un tipo sí o no, la respuesta solo puede ser: sí, la hay. Si la respuesta puede ser más matizada, entonces cambia. Motivo: nunca se debe construir un juego antes de algunos de diseño. Pero seguro que puede guardar partes del diseño para más adelante.

Significa que no creo que deba ver el problema en cuestión como hacer o no. Más bien, es algo en lo que debes pensar en términos de grados. La característica rastrera puede ser la segunda raíz de todo mal en lo que respecta al desarrollo del juego (la primera, como Donald Knuth nos tiene, es que "la optimización prematura es la raíz de todo mal" ). Sin embargo, en mi experiencia, no pensar en ninguna de las características principales, es decir, no tener al menos un diseño básico de dónde quiere ir con su mecánica básica, tampoco es una buena idea.

La primera razón principal es que es útil en términos de recursos (incluido el tiempo como recurso) tener alguna planificación para guiarlo a través, porque llegar a callejones sin salida todo el tiempo debido a un excesivo intento y error puede ser solo un desperdicio de recursos como tener que incluir características imprevistas.

La segunda razón principal, en cuanto al diseño del juego, es la coherencia. El buen diseño del juego tiene coherencia conceptual, o consistencia si lo desea. Significa que el juego en general, el historial, la implementación, incluso los gráficos, deben ajustarse entre sí de la mejor manera posible. Es muy poco probable que un diseño de juego logre algo así si las características principales se descubren sobre la marcha. Si no es por otra cosa, porque en el camino tiene mucha aleatoriedad: las cosas que pisarás pueden tener impactos muy diferentes dependiendo de cuándo las encontraste en el proceso de desarrollo .

No me refiero a decir que no debes hacer lo que dijiste en absoluto. Solo digo que tienes que encontrar algo de equilibrio.

Por ejemplo, si quiero hacer un juego de plataformas en 2d en el transcurso de 6 meses, ¿puedo comenzar a correr, saltar, disparar, etc. y agregar las mecánicas principales a medida que las encuentro inadvertidamente? ¿O es esto demasiado arriesgado de una inversión de tiempo sin un plan predeterminado?

Comenzaría por introducir una ligera modificación en tu oración. Al correr, saltar, disparar, etc., ya está implementando la mecánica central. Lo que agregaría sobre la marcha en su ejemplo son las características específicas del juego.

No es porque sepa que el juego será una plataforma 2D, que correr, saltar o disparar no puede variar según el diseño del juego. ¿Puede tu jugador correr en las paredes? ¿Puede tu jugador flotar en el aire al saltar? Incluso, ¿puede tu jugador disparar mientras corre? ¿Tu jugador dispara solo en una dirección lineal o mediante una parábola? Estas decisiones pueden depender mucho de las características del juego.

Pero veo su punto: estas mecánicas a menudo tienen algunas partes que varían muy poco. Entonces, si haces un diseño de juego y decides las características básicas para estar seguro de cómo funcionará correr, saltar, disparar, etc., eso es un comienzo. Entonces puedes optar por estas mecánicas y seguir construyendo sobre ellas.

Por supuesto, aún puedes encontrar una nueva característica que requiera que modifiques estas mecánicas, sin importar cuán básicas sean. Pero la clave aquí es la probabilidad. La probabilidad de que esto suceda con demasiada frecuencia será menor si al menos reflexionó sobre las consecuencias de correr, disparar, saltar, etc. para las ideas básicas que tenía para el juego.

Por último, si quieres seguir esa ruta, te sugiero lo siguiente. Piense en ello como un proceso iterativo. Haces un pensamiento de diseño inicial de nivel amplio. Implementas lo que parece básico y más "universal" dentro de tu juego, para que tenga éxito. Luego haces un poco más de pensamiento de diseño, reevalúas lo que implementaste y buscas más implementación.

Al realizar proyectos complejos como juegos, a menudo no puede hacer todas las funciones que desea, porque se está quedando sin tiempo / dinero o porque no resultaron tan buenas como esperaba. Esto se conoce como arrastre de características. Pero hay otro lado de esto; También encontrará características que no creía que necesitara, pero a medida que el proyecto toma forma, su necesidad se hace evidente.

Esta es la razón por la cual las personas construyen prototipos , para que puedan aprender qué funciona y qué no, para poder cortar funciones que no funcionan , pero también para que puedan encontrar nuevas funciones que serían increíbles . Si no está haciendo ninguna de esas cosas que no está aprendiendo , lo está haciendo mal.

Este es básicamente el sentimiento expresado en una charla llamada Prototipos avanzados , por Chris Hecker y Chaim Gingold, que incluye muchos ejemplos de su trabajo en Spore, donde a menudo se sorprendieron por lo que funcionó y lo que no, llegando al rediseño completo sistemas basados ​​en retroalimentación de prototipo.

Otro ejemplo es el proceso de diseño de Left 4 Dead ; Al principio, el juego solo tenía zombis básicos, pero después de probar con jugadores experimentados, los diseñadores descubrieron que los jugadores se mantenían unidos de manera efectiva y que el juego era demasiado fácil, por lo que agregaron zombis especiales para separar al equipo y mantener el juego emocionante.

Por supuesto, esto no significa que debas construir tu juego sin ningún diseño previo . Debes asegurarte de que el núcleo de tu juego sea divertido antes de continuar, porque esa es la parte más difícil de hacer un juego.

Yo diría que sí, adelante. Pero planifique algunas características / clases comunes con anticipación para tener cierta cohesión entre cada nuevo componente.

Unity es conocido por su enfoque de componentes para el desarrollo de juegos, y permitiría esta forma de desarrollo fácilmente. Si no está utilizando Unity, podría replicar un enfoque de semicomponentes. No estoy familiarizado con otros motores de juegos.

Todos los objetos del juego Unity tienen un componente de transformación. Esto indica la posición, rotación y escala del objeto. Por lo tanto, cree una clase genérica de 'transformación' para contener estos valores, más una referencia al objeto del juego real tal vez.

Tome un componente 'Saltar', por ejemplo. Haga que toda la lógica funcione con la clase de transformación de un objeto de juego para manipular la posición. (O su motor ya tendrá una clase incorporada similar). Puede adjuntar esta clase 'Jump' a cualquier objeto, y la clase animará la posición de transformación cuando se active una acción (Jump.PerformJump () o lo que sea). La clase Jump no tiene que saber nada sobre su propietario (o, al menos, información mínima).

Ahora puede divertirse creando una tonelada de componentes, luego adjuntándolos a los objetos del juego, combinándolos en un objeto, etc. Por ejemplo: Ejecutar, Saltar, Agacharse, Mosaico en movimiento, FireWeapon (especifique el sprite 'bala' y el comportamiento para hacer un componente genérico), etc.

Haga que cada componente sea lo más genérico posible para permitir múltiples usos / variaciones. Para FireWeapon, puede especificar el sprite de bala, la velocidad, el daño, etc. Puede intentar normalizar esos atributos, de modo que la velocidad y el daño se especifiquen entre 0 y 1. Luego, escale los valores máximos del juego. De esta manera solo te preocupas por las diferencias relativas entre las armas. Además, esto se adapta a configuraciones globales como la dificultad donde una dificultad mayor tiene un daño máximo mayor, etc.

Antes de que te des cuenta, tienes un arsenal de componentes para conectar y ahora puedes desarrollar rápidamente para cualquier tipo de juego.

Breve: la mayoría de las veces no puede tener un solo paso de diseño seguido de un solo paso de codificación. Tendrás que alternarlos. Como regla general, trate de respetar lo que ya está diseñado (no lo que ya está codificado).

Acerca de no tener un diseño inicial (solo un boceto o una imagen mental): si no tiene un diseño, no tiene un diseño. Debes hacer algo para venir con uno. Pero mientras comiences a construir uno, trata de respetarlo, no vengas con uno nuevo cada vez.

Experimentar y obtener características aleatorias puede o no ser dañino. Incluso puede ser beneficioso o inevitable. Por ejemplo: sabe que desea apoyar el salto (muchos juegos de rol 3D / 2D no permiten saltar). ¿Como lo sabes? ¿Porque imaginaste un mapa del juego que requiere saltar para ordenar un obstáculo? Por lo tanto, la implementación del salto es lo suficientemente buena siempre que le permita al jugador clasificar ese obstáculo o tiene que cumplir con ciertas características como la altitud máxima alcanzable, puede ser impulsada por elementos u objetos del juego en el mapa, la física debe incluir la aceleración o el rebote ( cuando Mario salta a un enemigo, gana impulso para elevarse nuevamente y eso es muy importante para el juego).

Si ya puede responder esas preguntas, sus documentos de diseño (imaginarios o reales) están muy completos. Si no puede responderlas, entonces su diseño está incompleto. En este caso, deberá volver a trabajar en el diseño o experimentar para llenar los vacíos. Las oportunidades pueden ser muy abiertas o muy restrictivas. Si algunos de tus niveles de juego tendrán obstáculos, y solo necesitas saltar para ellos, entonces hay mucha libertad para decidir la altitud o velocidad máxima alcanzable, tal vez decidas fingir que hay un motor de física para comenzar todo solo para mejora las imágenes de la animación de salto, pero no la necesitas para nada más. (En muchos juegos de juegos de rol en 2D no puedes saltar cuando quieras, pero siempre que haya un solo agujero en un mapa, al intentar entrar automáticamente se dispara un salto al piso al lado del agujero)

Entiendo que está bien ir al código sin un diseño completo siempre que respete lo que ya está decidido. También puede ser inevitable en algunas situaciones, ya que los universos de juego pueden construirse a partir de una variedad de procesos de pensamiento diferentes. Por ejemplo, un juego de cartas: sé que quiero que las cartas tengan Ataque y Defensa, una cierta cantidad de cartas en la mesa en un momento dado y que el jugador durante su turno puede elegir con qué carta atacar qué otra carta. Para algunos puede parecer un diseño ya completo, pero luego viene el equilibrio del juego, solo posible a través de muchas simulaciones. Después de muchas simulaciones, decido que una tarjeta con el Ataque 10 está dominada, simplemente puedo eliminarla del juego, pero me gusta demasiado, así que haré algo diferente, Crearé una nueva regla que dice que si un jugador ataca con una carta así, no puede atacar con otra carta durante ese turno. Ahora tengo una nueva regla que enriquece la mecánica del juego, pero aplicarla a una sola carta se ve rara (como un truco sucio), me doy cuenta de que se ve rara y luego decido crear un nuevo conjunto de cartas que tengan números altos pero nueva regla limitante se aplica a ellos. Ahora tengo una mecánica de juego más compleja, construida sobre la original más simple, en mi opinión, aproveché para hacer un mejor juego.

Ahora, una cosa sobre ese último ejemplo, en el ejemplo propuesto del juego de cartas, las nuevas cartas pueden dar como resultado nuevos activos (aumento de costos, aumento de tiempo). Pero creo que es un buen ejemplo de dejar que las oportunidades que solo ves cuando codificas influyan en tus decisiones de diseño de una buena manera.

No creo que la mayoría de los juegos que jugamos estén completamente diseñados antes de la codificación, estoy seguro de que tuvieron que tomar decisiones difíciles para cumplir con los plazos y así.

Cuando alguien más está pagando por todo: explique, negocie.