¿Debo desarrollar mi idea de juego en modo texto primero?

Question

Recientemente se me ocurrió una idea para un juego de simulación/estrategia. He estado esbozando muchas de mis ideas en papel sobre la mecánica del juego y también tengo algunas de las clases y objetos básicos funcionando. (Estoy escribiendo esto en C# usando XNA).

Sin embargo, una cosa que es dolorosamente obvia para mí es que no soy un artista gráfico y tratar de conseguir algo programado en gráficos ahora me está frustrando. Un pensamiento que me vino a la mente fue tratar de hacer que todo el juego funcionara primero en la consola de texto. Recuerdo pasar cientos de horas jugando a Zork y Hack cuando era niño y la mayoría de las ideas de mi elemento de juego no requieren animaciones de sprites en tiempo real para funcionar.

Así que mi pregunta a la comunidad aquí es si debo tratar de mantener mi entusiasmo por el concepto centrándome en hacer que simplemente funcione primero en modo de texto y luego reagruparlo para darle una interfaz bastante gráfica.

O

abordar la colina de interfaz gráfica, al mismo tiempo que estoy tratando de ahuyentar a mi idea?

Durante la redacción de esta pregunta creo que he respondido por mí mismo, pero me encantaría escuchar los comentarios de las personas.

Answer 1

Creo que tiene la idea correcta en función de su descripción del juego. Si separa sus inquietudes, puede implementar una gran parte de la lógica comercial primero. Piense en ello como una aplicación MVC. Puede dejar que su vista se implemente más tarde; solo proporcione una capa que interactúe con su lógica comercial, que su vista pueda usar.

De esta manera, no importa cuál sea su vista (basada en texto o gráficos). Puede pasar metadatos a la vista y la vista decidirá cómo renderizarlos.

Así que yo diría que su idea es buena. Comience con la lógica comercial y una vista basada en texto. De esta forma, puedes desarrollar tus conceptos e ideas y también decidir qué tipo de datos transmitir a la vista. Sin embargo, recuerde una cosa: tiene que ser extremadamente cuidadoso en este momento para no deje que las suposiciones sobre la vista se filtren en su capa empresarial. Por lo tanto, debe codificar la capa de su empresa y la interfaz asociada a la vista, como si tuviera sin idea cuál será la vista. Lo que quiero decir es que, dado que está comenzando con una interfaz basada en texto, no tome decisiones de codificación que lo vinculen a esa implementación en particular.

Una vez que haya completado todo, puede comenzar a aprender gráficos y comenzar lentamente su capa de gráficos.

Por supuesto, este enfoque (MVC) puede no funcionar en todas las situaciones, especialmente cuando su vista es de tiempo crítico. Para obtener más información, eche un vistazo a estas preguntas Stackoverflow:

• Is the MVC design pattern used in commercial computer games.
• Best practices when Designing iPhone Game with MVC
• Game framework architecture - view components or MVC

Sólo quiero que quede claro que no estoy abogando por un patrón MVC para su juego - Sólo quiero hacer hincapié en la separación de la preocupación por lo que es fácil para que usted pueda intercambie su vista sin hacer una refactorización significativa.

Answer 2

Si yo fuera usted, crearía primero una interfaz de línea de comandos basada en texto. Luego, si decides hacer una GUI real, puedes hacer que la GUI automatice el juego de línea de comando, para que no tengas que escribir la lógica del juego dos veces. Muchas herramientas usarán este enfoque. Alguien creará, por ejemplo, una herramienta de desfragmentación de línea de comando y luego alguien creará un "envoltorio" GUI para la herramienta. Sort of like what Nethack did.

Answer 3

Haz una IU. Mantenga los gráficos simples (Paint) y concéntrese en la usabilidad. Luego, libera tu juego como código abierto y otra persona creará buenos gráficos y una interfaz de usuario genial.

Answer 4

Mi consejo: actualmente casi ningún software se puede hacer con una sola mano.

Trate de esbozar sus ideas, publicar en algún lugar, encontrar más personas interesadas, armar un grupo y ensuciarse las manos.

Si su idea es realmente buena, encontrará más miembros del equipo que pueden llenar su falta de experiencia en las otras áreas necesarias.

Puede tratar de encontrar personas en la web, comenzando algo así como un proyecto de código abierto, o puede intentar encontrar un inversor, que pueda inyectar dinero en su negocio y podrá contratar personas especializadas.

Answer 5

Un juego es un proyecto complicado que se puede dividir en muchos compartimentos. Estos pueden ser módulos reales (por ejemplo, un renderizador de GUI o un administrador de comunicaciones), o pueden ser más teóricos o lógicos, como el "diseño del juego".

Si bien todas estas partes funcionan juntas, preferiblemente en armonía, para resaltar el juego real, cada una de ellas también se sostiene sola. Como tal, siempre es una buena dirección para dividir & conquistar. Si tiene confianza en su idea, implemente la forma más simple posible, que probablemente sea una aplicación de consola.

Sin embargo, debe tener en cuenta que aunque puede iniciar desarrollando cada módulo por separado, eventualmente deberá tener en cuenta cómo estas partes funcionarán juntas. Esto afectará intrínsecamente el diseño de sus módulos. Por ejemplo, puede descubrir que la lógica de su juego funciona muy bien, pero no tiene forma de permitir que el usuario realmente realice un cierto paso en términos de IU. La capacidad de juego es una de las características más importantes de un juego, y su interfaz de usuario incluso puede dictar alguna lógica del juego. Este concepto contradice la regla de oro de separar la IU de la lógica, pero como dije, los juegos son complicados, y para el producto final a menudo se encuentra flexibilizando algunas reglas. Los juegos son diferentes a otros proyectos; la escalabilidad no es un problema. La capacidad de mantenimiento es importante, pero se sacrificará si necesita ese jugo extra de CPU ... y así sucesivamente.