¿Cuáles son los mayores escollos a tener en cuenta al desarrollar un nuevo juego?

De hecho, recién comencé a rastrear (gracias a David Young por la corrección de la nomenclatura) un par de nuevos juegos basados ​​en la web para Facebook hace unas semanas y acabo de estar inundado de bloqueos mentales y el tiempo de la nueva codificación. Estoy trabajando en algo similar al RPG de estilo basado en turnos (Guerras de vampiros). Tengo las habilidades para codificar un juego, pero estoy tratando de hacer que los patrones de diseño sean correctos y hacer que el producto coincida con lo que veo en mi mente.

Normalmente, cuando construyo un sitio web, me gusta "pensar en el código" y me resulta más rápido cambiar el código / HTML para modificarlo. Esto es probablemente porque estoy MUY cómodo en lo que hago y sé qué esperar. como lo he hecho una y otra vez. En este punto con el desarrollo del juego, me encuentro empezando de nuevo en papel (como solía hacerlo con los sitios web) y me pregunto si esto es solo mi falta de enfoque e intuición con la lógica del juego o si esta es una forma adecuada de desarrollar mis pensamientos. avance de la codificación.

Agradecería algunos consejos sobre cómo atacar correctamente este problema y mantenerme en la tarea. ¡Estoy aprendiendo rápidamente cuán diferente es un motor de juego de un sitio web comercial estándar! Cada vez que pongo algo en su lugar, me siento malhumorado e incompleto y se está volviendo muy frustrante.

Extendido

Como ejemplo, el motor de batalla que me ha estado causando tantos problemas recientemente toma una habilidad de ataque simple y luego realiza una tirada aleatoria entre -50% y + 50% y luego multiplica la habilidad de ataque original contra ese porcentaje. Lo mismo se hace con la defensa y luego los combino para determinar si se hace algún daño contra la salud del enemigo. Supongo que debería darme cuenta de que estoy loco cuando comencé a preguntarme si esa es la forma correcta de hacerlo, o si incluso existe una forma 'correcta'. Una falla importante que encontré con esto es que dos personajes del mismo nivel pueden tener varias 'tiradas' donde el ataque es -50% y la defensa es + 50%, así que termino con algunas secuencias de batalla EXTREMADAMENTE largas donde nadie hace nada. FALLAR

Tal vez mi publicación debería haber estado pidiendo enlaces sugeridos que describan la lógica simple del juego.

Fin de extensión

¡Gracias a todos de antemano!

agregando demasiadas características. Concéntrese en el núcleo del juego, compílelo, luego, si todo funciona bien, agregue funciones. La gente se concentra demasiado en agregar cosas interesantes y nunca hace nada.

Este es un gran artículo sobre cómo prototipar un juego. Según su pregunta, parece que se está perdiendo la idea de lo que se supone que es un prototipo.

Creación de prototipos: estás (probablemente) haciéndolo mal

Propaganda:

Error # 4: construir un sistema, no un juego
Cuando estás haciendo un prototipo, si alguna vez te encuentras trabajando en algo que no te mueve directamente hacia adelante, detente allí. Como programadores, tenemos la tendencia a tratar de generalizar nuestro código, hacerlo elegante y poder manejar cada situación. Encontramos que una picazón es terriblemente dura, no se rasca, pero necesitamos aprender cómo. Me llevó muchos años darme cuenta de que no se trata del código, sino del juego que envías al final.

No escriba un elegante sistema de componentes del juego, omita el editor por completo y conecte el estado del código, evite la locura basada en datos, el auto-análisis, XML, y simplemente codifique la maldita cosa.

Editar:

Estoy agregando esto solo para aclarar la diferencia entre Prototype y Tracer Code.

Recuerde siempre: ¡un prototipo está diseñado para ser desechado! El código de seguimiento no lo es.

La trampa del prototipo

... El enfoque del código de seguimiento aborda un problema diferente. Debe saber cómo se mantiene unida la aplicación en su conjunto. Desea mostrar a sus usuarios cómo funcionarán las interacciones en la práctica, y desea dar a sus desarrolladores un esqueleto arquitectónico en el que colgar el código. En este caso, puede construir un marcador que consista en una implementación trivial del algoritmo de empaquetado de contenedores (tal vez algo así como el orden de llegada) y una interfaz de usuario simple pero funcional. Una vez que tiene todos los componentes de la aplicación conectados juntos, tiene un marco para mostrar a sus usuarios y desarrolladores. Con el tiempo, agrega a este marco con una nueva funcionalidad, completando rutinas tropezadas. Pero el marco permanece intacto, y usted sabe que el sistema continuará comportándose de la misma manera cuando se completó su primer código de seguimiento.

La distinción es lo suficientemente importante como para justificar la repetición. La creación de prototipos genera código desechable. El código de seguimiento es sencillo pero completo y forma parte del esqueleto del sistema final. Piense en la creación de prototipos como la recolección de reconocimiento e inteligencia que tiene lugar antes de que se dispare una sola bala trazadora.

Más información sobre el diseño del código Tracer, de The Pragmatic Programmer

Balas trazadoras y prototipos

Errores: no separar su lógica de sus datos. No probar que sus datos produzcan los resultados deseados.

De tu comentario en la publicación de Joe:

¡Quieres que codifique un motor de batalla para encuentros con monstruos, BOOM! He reescrito mi motor al menos tres veces esta semana y nunca me siento bien al respecto. Quiero decir, las matemáticas funcionan, pero cuando lo pruebo, me siento inestable. ¿Tiene sentido?

Parece que estás combinando el motor con los datos aquí. Tu motor de encuentro de monstruos debe ser impulsado por datos. Si los datos que afectan el equilibrio / diversión de su juego son incorrectos, no debería ser necesario reescribir completamente su motor, solo modifique las variables de equilibrio hasta que se sienta bien.

Sin embargo, debido a que las variables de equilibrio son a veces interdependientes, cambiar una variable a un mejor escenario puede tener un efecto vasto (negativo) en otros escenarios.

Para probar que sus datos recién ajustados no acumulan muchos otros casos, es útil mantener algunos casos de prueba y asegurarse de que no se rompan después de ajustar. Aquí hay un ejemplo artificialmente inventado de cómo probarías esto.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

P.ej. Si llamas a esto con PlayerStats.Level == 5 y MonsterStats.Level == 3, esperarías que el jugador siempre derrote a este monstruo eventualmente.

El problema aquí, hasta donde puedo ver, es que estás tratando la programación y el diseño del juego como la misma tarea, cuando en realidad son tareas separadas. Como sugiere, este no es un problema de programación o algoritmo (puede codificar el sistema de batalla de la forma que desee), se trata de lo que es divertido e interesante para el jugador.

La respuesta es buscar recursos en el diseño y el equilibrio del juego. En realidad, hay universidades que dedican un programa completo de estudio de cuatro años a los temas que está planteando, por lo que simplemente darle una respuesta rápida y sucia es imposible (de la misma manera que probablemente estaría perplejo si alguien dijera " Sí, tengo esta idea para un juego, pero no sé cómo programarlo, ¿qué debo tener en cuenta? "). Hay libros, cursos y escritos en línea sobre diseño de juegos; búscalos.

La mayor dificultad al escribir juegos es preocuparse por si estás usando o no los patrones de diseño correctos en lugar de solo escribir el código con el que te sientes bien.

Recomendaría los artículos de Steve Pavlina sobre gestión del tiempo y automotivación: http://stevepavlina.narod.ru/

Él es programador también. Sus experimentos de estilo de vida han generado cierto interés en los medios de comunicación.