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

18

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.

Davy8
fuente

Respuestas:

23

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

corsiKa
fuente
2
Si intercambia "diversión" por "útil", creo que se encuentra con el mismo problema al diseñar un producto (en lugar de escribir software para un cliente). Sin embargo, supongo que hay una diferencia de grado. Las personas a veces se equivocan acerca de lo que sería útil, generalmente no tienen idea de lo que les hace algo "divertido". (+1 aunque)
Davy8
1
Hubo un infame fallo de la corte suprema con respecto a la industria del cine para adultos y lo que clasificó "hardcore" en los años 60. La justicia dijo que "nunca podría tener éxito en [definirlo] pero lo sé cuando lo veo". Creo que lo mismo se puede decir por diversión. Quiero decir, puedo anotar cosas que me gustan de los juegos, pero a menudo me encuentro jugando y preguntándome "¿Qué hace que esto sea divertido?" (¡Obviamente quiero saber para poder recrearlo en uno de mis juegos!) ¡La gente no sabe qué hace que algo sea divertido, pero definitivamente saben cuándo lo encontraron!
corsiKa
Realmente me gustó esta publicación. Tienes mucha razon. Realmente me gusta el desarrollo de juegos, pero realmente no lo tengo en mí para ver lo "divertido" que es para la gente "común". Lo que ha tenido el efecto de que solo hago juegos que me gustan a mí y a otros locos como yo :)
Phil
1
@ Phil y eso está bien. Si sabes lo que es divertido para ti, debes recordar que solo hay un par de cientos de arquetipos de personajes en este mundo. Mire alrededor de su lugar de trabajo y combine las personalidades de sus compañeros de trabajo con las que asistió a la escuela secundaria o universidad. Encontrarás que la mayoría de ellos se pueden combinar. Entonces, si algo es divertido para ti, probablemente será divertido para más personas de lo que crees. ¡El truco es que conozcan el juego para que puedan disfrutarlo!
corsiKa
Esta es la mejor respuesta que he visto hasta ahora. Hay toneladas de artículos para ideas de nicho de negocios de software, etc., pero no muchos sobre el desarrollo de juegos. Hmmmm
Johnny
21

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
Sion Sheevok
fuente
+1 para una buena respuesta a la pregunta, aunque para mi juego en particular no tengo que lidiar con la mayoría de esos (basados ​​en turnos y mosaicos, por lo que no hay colisiones reales, no hay física, los gráficos consisten en sprites y lanzan más JQuery en él, 2 jugadores, así que todavía no hay IA, la entrada del usuario se maneja de una manera principalmente RESTANTE que también cubre el aspecto de la red) No estoy muy seguro de lo que quieres decir con File IO, aparte de decir guardar / cargar un juego qué Qué tipos de IO se necesitan en los juegos típicos?
Davy8
44
Estoy de acuerdo con la mayor parte de esta publicación y recibo un +1 de mi parte, pero cuestionaría la línea de "riesgo de falla más grande y más costosa". Si trabaja para un banco, una gran empresa de fabricación o un sitio web de mucho tráfico, su falla se puede medir en cientos de miles por minuto de tiempo de inactividad como resultado de la falla. En una hora, podría perder (en ventas perdidas, clientes perdidos, etc.) más de lo que algunas tiendas de desarrollo de juegos equivalen a meses de nómina completa. No digo que no pueda ser grande, solo digo que no estoy convencido de que sea más grande que el software tradicional.
corsiKa
@ Glowcoder Sé lo que estás diciendo, pero creo que también entiendo el punto que Sion está tratando de hacer, que con los juegos generalmente todo el proyecto es un éxito o es un fracaso, y generalmente es un factor de lo que mencionaste en tu respuesta : ¿es divertido? Puede corregir los errores, pero no puede corregir la falta de diversión.
Davy8
3
No estoy del todo convencido de que los "equipos más grandes" sean ciertos incluso como una generalización. Claro, los juegos AAA tienen grandes equipos, pero también lo hacen los productos de software que no son juegos de complejidad equivalente. Grandes cantidades de juegos son producidos por individuos o equipos de dos o tres personas.
Peter Taylor
@ Davy8 oh, si solo el éxito comercial de un juego fuera proporcional a lo divertido que es. :)
tenpn
2

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.

Remojar
fuente
0

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.

Zukki
fuente
0

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.

harsimranb
fuente