¿Cómo es el desarrollo del juego diferente de otro desarrollo de software? [cerrado]

Para un desarrollador de software sólido de propósito general, ¿qué es específicamente diferente del desarrollo del juego, ya sea fundamentalmente o simplemente diferencias de grado?

He hecho juegos de juguete como Tic-tac-toe, Tetris y un solucionador de sudoku de fuerza bruta (con interfaz de usuario) y ahora me estoy embarcando en un proyecto de tamaño mediano (de tamaño mediano por ser un desarrollador único y no tener hecho muchos juegos) y una cosa que he encontrado con este proyecto en particular es que la separación de las preocupaciones es mucho más difícil ya que todo afecta el estado y cada objeto puede interactuar con todos los demás de una infinidad de formas.

Hasta ahora he logrado mantener el código razonablemente limpio para mi satisfacción, pero encuentro que mantener el código limpio en juegos no triviales es mucho más difícil de lo que es para mi trabajo diario.

El juego en el que estoy trabajando es por turnos y los gráficos serán bastante simples (basados ​​en la web, principalmente a través de la manipulación DOM), por lo que el tiempo real y el trabajo en 3D no son realmente aplicables para mí, pero aún así sería interesado en respuestas con respecto a aquellos si son interesantes. Aunque principalmente interesado en la lógica general del juego.

PD Siéntase libre de volver a etiquetar esto, no estoy realmente seguro de qué etiquetas son aplicables.

Hay una gran diferencia. En mi opinión, es la única diferencia que realmente importa.

Podemos repasar los detalles técnicos de por qué es diferente, seguro. Motores 3D, física de partículas, muchas cosas diferentes entran en juego.

Pero muchas formas diferentes de software tienen condiciones. El software de modelado tiene que hacer muchas de las mismas cosas. Cada pieza de software importante tiene alguna biblioteca especializada que tiene que usar.

Entonces, ¿qué hace que los JUEGOS sean diferentes?

Aquí está: El software está diseñado para satisfacer una necesidad comercial. ¿Quieres un sistema de inventario? Puede definir qué tipos de elementos debe manejar. Puede definir lo que desea para su programación de producción. Puedes hacer todo eso. O si desea un software bancario, puede definir qué quiere hacer con él.

Con los juegos, su necesidad comercial es "divertida". Intente escribir una especificación técnica para "diversión".

Eso, en mi humilde opinión como desarrollador, es lo que hace que los juegos sean diferentes al software normal. Simplemente no puede decir "¡Genial! ¡Este software ahora tiene funciones completas según las solicitudes del cliente!" porque todo lo que quieren hacer es divertirse.

Dicho esto, no necesitas gráficos en 3D y física extravagante para que algo sea divertido. ¿Por qué la gente todavía juega Tetris? Su física consiste en "mover el bloque hacia abajo", "no dejar que el bloque se salga de los límites" y "detener el bloque cuando golpea algo", y aunque a lo largo de los años ha habido numerosas versiones, algunas con gráficos más sofisticados que otras, pero el La conclusión es: ¡ es divertido!

Entonces, si quieres ser un gran desarrollador de juegos, no tires lo que has aprendido como desarrollador habitual de software. Todavía es algo muy útil. Y @Sion tiene razón al separar sus componentes, tal como lo haría en una pieza de software normal. Pero la característica más importante que puedes agregar a tu juego es divertida. Diversión, diversión, diversión, diversión, diversión. Por eso existe el desarrollo del juego, eso es lo que necesitas para que tu juego sea exitoso. Y confía en mí en esto, por divertido que sea jugar, ¡es al menos 10 veces más divertido de hacer!

Buena suerte con tu juego dev'ing !! :RE

Soy principalmente un desarrollador de juegos y no un desarrollador de software tradicional, pero creo que hay varias diferencias clave.

Obviamente, se trata de varias generalizaciones y no son exhaustivas:
equipos más grandes. Fondos más variados (artistas, programadores, productores, con cada uno hay aún más variación). Ciclos de desarrollo más largos. Mayores estándares de rendimiento. Mayor escala de proyectos. Mayor y más costoso riesgo de fracaso. Ambiente más estresante.

En cuanto a las interacciones de objetos y el diseño de su arquitectura, aún puede desacoplar adecuadamente los sistemas. Sus objetos y comportamiento de juego claramente dependerán entre sí y de estos sistemas. Sin embargo, esa es la naturaleza del juego (juego de palabras), combina todos estos sistemas en una sola unidad cohesiva, y eso no tiene nada de malo. Puede parecerlo porque la escala de todo es más grande de lo que estás acostumbrado.

¿Algunos sistemas fácilmente identificados y segregados?

• Detección de colisiones
• Respuesta de colisión
• Física
• Animación
• Gráficos (2D y 3D)
• Inteligencia artificial
• Entrada del usuario
• Entrada / salida de archivo
• Redes

No creo que la programación de juegos sea diferente de otros dominios de aplicación desde el punto de vista de que es más difícil elegir la separación correcta de preocupaciones. Cada vez que lleve sus habilidades a un tipo diferente de dominio de aplicación, encontrará que la transición no es tan fluida como esperaba porque siempre hay diferencias. Lo que funcionó en su aplicación de base de datos tiene muchos patrones / modismos que no funcionan tan bien en su aplicación integrada, que tiene muchos patrones / modismos que no funcionan tan bien en ese sistema en tiempo real que también tiene muchos patrones / modismos que no trabajes en la programación de juegos. Sin embargo, los programadores de juegos tienen los mismos problemas cuando dejan su dominio de programación de juegos. Todo es solo una cuestión de lo que estás acostumbrado.

Dicho esto, creo que la programación de juegos parece más difícil para muchas personas porque requiere que trabajes con partes de la computadora con las que la mayoría de los programadores nunca tienen que lidiar en su trabajo real (gráficos y sonidos de bajo nivel) y más matemáticas aplicadas que muchas las personas se sienten cómodas y no por la separación de preocupaciones. Si bien siempre hay dificultades para determinar la elección correcta para la separación de las preocupaciones, creo que la dificultad con la separación de las preocupaciones que está experimentando es simplemente pasar a un nuevo dominio de problemas. Una vez que cree algunas aplicaciones, será como cualquier otra cosa, aprenderá lo que le gusta y no usará lo que no.

y una cosa que he encontrado con este proyecto en particular es que la separación de las preocupaciones es mucho más difícil ya que todo afecta el estado, y cada objeto puede interactuar con todos los demás de una infinidad de formas.

Creo que tienes una respuesta allí, hay muchas interacciones. Hice algunos juegos con XNA (C #), ahora estoy haciendo un juego de tamaño medio como dices, un juego de simulación de estrategia, he estado trabajando en él durante casi 2 meses, y lo hago solo sin ayuda, así que debo mantener mi código simple. Creo que una gran diferencia es comprender y diseñar algunas clases para la funcionalidad, y otras para dibujar, esto ayuda y hace que su programa sea más limpio. Por supuesto, si estás haciendo un juego necesitas tener más recursos, como imágenes (2d o 3d) y música (o sonidos). Así que hay diferencias, creo que es más difícil, pero es muy divertido.

Creo que la programación de juegos es más divertida. Puedes probar constantemente tu juego, implementas diferentes físicas, lo que resulta en un comportamiento diferente.

Desde mi experiencia, la programación de juegos es en realidad mucho más divertida en comparación con el desarrollo de software. En el desarrollo de software, usted tiene que cumplir ciertas reglas comerciales, se vuelve poco aburrido. Estás creando un software, no es divertido. Usar software es genial, útil, útil, pero no divertido.

Los juegos son divertidos. Tal vez soy solo yo, pero encuentro el desarrollo de juegos mucho más intrigante y emocionante que el desarrollo de software tradicional, independientemente del uso de herramientas.

PD: Utilizo las últimas herramientas para el desarrollo de software, HTML5, Asp.Net, C #, etc. Todavía me parece más divertido codificar DirectX, UDK, XNA, Unity.