¿Cómo te preparas para el arrastre de características?

¿Cómo puedo prepararme para el arrastre de funciones durante la preproducción?

El arrastre de características es cuando estás en la fase de producción y decides "¡Sería genial si esta fuera una característica!" Eso agrega n horas al tiempo de desarrollo que no se contabilizaron y, a menos que sea Blizzard, no tiene tiempo para hacerlo. No puede prever que sea una característica interesante durante la preproducción, porque la característica solo se descubre durante la producción.

¿Qué puedo hacer durante la preproducción para tener en cuenta o prevenir o preparar el arrastre de funciones?

¿Debo permitir el arrastre de características y cortar las características menos deseadas? ¿O esto creará problemas ya que la arquitectura no está diseñada para las nuevas características? ¿Debo decir que no hay características a menos que se ajusten a la arquitectura existente?

Sé que esta es una pregunta amplia, pero espero que no se cierre como tal. Este es un problema importante en el desarrollo de juegos, y debe ser considerado.

Si bien, por supuesto, no hay reglas estrictas cuando se trata de la preproducción, hay una variedad de heurísticas para ayudar. Algunas características son naturales y necesarias: ningún plan sobrevive al primer contacto con la realidad, y es posible que no sepa qué sería "genial" hasta que lo vea.

Primero, prepara tu desarrollo. Dibuje su esquema en un mapa de características y luego busque formas de agrupar sus características en iteraciones comprobables , cada una con una fecha límite . Una vez que comience una iteración, resista agregarle nuevas características. Cualquier necesidad técnica imprevista , por supuesto, debe entrar en la iteración actual, pero las nuevas ideas para las características deben ir a una lista para su consideración futura. Luego puede considerar si agregarlo o no a una iteración una vez que se complete la actual.

Esto se desprende del método MoSCoW , mediante el cual clasifica características de la siguiente manera:

• Debe tener : características que son vitales para que la iteración actual sea estable , es decir, comprobable . Si la iteración no funciona sin ella, es imprescindible.
• Que tienen Deberían - características que tendrán que hacer en algún momento, pero si la iteración va con el tiempo pueden ser empujados a la siguiente iteración . Las cosas requeridas por un editor, por ejemplo, podrían ir aquí.
• Podría tener : características que cree que pueden ser importantes para la iteración actual, pero podrían eliminarse del proyecto. Estas son las características polacas más importantes .
• No tendrá : elementos que potencialmente alimentan el trabajo atrasado , características identificadas en esta iteración para ser consideradas para iteraciones posteriores.

Lo ideal es que el desarrollo sea un refinamiento progresivo, no todo o nada. Trabajando dentro de una fecha límite final, las características menos importantes deben ser llevadas al final, por lo que cualquier cosa que no consigas será algo que está bien cortar. Asegúrese de calcular cuánto tiempo llevará cada característica desarrollar y refinar esas estimaciones a medida que avanza. Nunca comprima el horario para dejar espacio para más funciones. Resista empujar fechas límite (iteración o final) hacia el futuro: mueva o corte características, si es posible. Si está llegando a su fecha límite y el juego sigue siendo un desastre imposible de vender, entonces sabe que es hora de reevaluar seriamente sus decisiones y considerar canibalizar el proyecto antes de que se convierta en un pozo de tiempo / dinero.

• Planifique utilizar una fracción de su tiempo de preproducción disponible para el conjunto de características base.
• Featureset base debe ser de bajo riesgo, características de alta recompensa, por lo que no tiene fluencia en los
• El conjunto de características base es mínimo y no es negociable; deben estar presentes; de lo contrario, no hay una base sólida desde la cual trabajar y usted estará plagado de dudas sobre el síndrome de "debería reemplazar este"
• Asegúrate de que las primeras iteraciones de tu juego sean lo suficientemente atractivas como para permitirte el deslizamiento de funciones. Un juego fundamentalmente poco impresionante no va a llegar lejos, y mucho menos con escalofríos.
• Sepa de antemano qué margen de fluencia puede permitirse, para que pueda usar ese margen sabiamente.
• Use tecnología preconstruida y altamente generalizada como Unity, y úsela canónicamente para mejorar la flexibilidad de modo que el arrastre de características no afecte demasiado la arquitectura existente
• No cree subsistemas complejos: aquí es adecuado un enfoque de programación eXtreme
• Haga que otros (diseñadores y codificadores) cuyos cerebros pueda tocar periódicamente para ayudarlo a priorizar qué características permitirá arrastrar, haga que alguien con experiencia revise su código como punto de referencia principal para estas preguntas.
• Aún tendrá que limitar el arrastre de características, por lo que debe priorizar constantemente y saber dónde dibujar la línea.

En última instancia, no es algo que sugiera a los principiantes, porque debes ser capaz de tomar la decisión correcta en cada etapa y eso no es fácil incluso para los más experimentados. Si no está seguro de cuáles son las decisiones correctas, entonces tenga una política estricta de "no arrastrarse más allá de este punto".

También puede ver cómo el primer punto y el de usar una tecnología que conoce bien significa que necesita una experiencia sustancial tanto en prototipos rápidos (atascos de juegos) como en el conjunto de herramientas elegido.