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


19

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!


1
Esta es una lectura algo relacionada e interesante que he encontrado útil: makegames.tumblr.com/post/1136623767/finishing-a-game
zfedoran

Respuestas:


22

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.


44
Esto casi mató a uno de mis juegos de FB. Está repleto de características, pero todo se siente medio tonto en general.
Tesserex

Si recuerdo correctamente, este fenómeno se llama "arrastre de características". Una trampa peligrosa, de hecho.
S. Tarık Çetin

14

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


Eso es genial ... Voy a tener que echarle un vistazo a ese artículo. Solo por el extracto que publicó, parece que podría estar buscando prototipos incorrectamente, pero también parece que puede ser un error común.
angryCodeMonkey

El error que ha citado me ha estado molestando durante bastante tiempo.
jokoon

4

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 consejo que recibo aquí es excelente, y puedo ver que he estado tomando el enfoque equivocado en gran parte de esto. Sin embargo, la razón por la que he reescrito el motor es porque creo que lo estoy haciendo demasiado complicado. Mi última versión del motor de batalla es una clase con (por el momento) una única función pública y varios soportes. La función principal 'pelear' no solo es calcular el ataque básico contra la defensa, sino también determinar el primer golpe, revisar las tiradas para determinar si tu habilidad táctica te da un segundo golpe, etc., etc., etc. Creo que lo hice demasiado maldito ¡difícil!
angryCodeMonkey

No separando su lógica de sus datos. ¡Ese es un gran punto, que casi siempre causará problemas en el camino o durante la actualización!
Spooks

2

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.


1

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.


El problema que tengo ahora es sentirme bien con el código que estoy escribiendo. Quieres un backend contable para tu negocio, no hay problema ... ¡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?
angryCodeMonkey

¿Por qué reescribir el motor? podrías implementar código específico del juego en un lenguaje de script como lua. Cambie las variables o cómo se calculan las matemáticas y nunca necesita volver a compilar solo para verificar las cosas. gamedev.net/reference/articles/article1932.asp
David Young

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.