Introducción al desarrollo del juego: ¿XNA es una buena opción? [cerrado]

Lector de mucho tiempo; pregunta por primera vez:

Hace tiempo que quería formar parte de la industria de los juegos, pero mi currículum es 100% de trabajo de backend.

Soy un gran desarrollador de C ++ / C #, sin experiencia práctica en el desarrollo de juegos. Mi experiencia en el back-end me convierte en un buen candidato para el trabajo de back-end (ya que muchos juegos en estos días tienen aspectos basados ​​en el servicio), pero es un campo hipercompetitivo y estoy buscando formas de destacar.

Como nadie va a acercarse a mí y darme un trabajo en la industria del juego, decidí probar mi sombrero al escribir mis propios juegos.

Entiendo por qué C y C ++ son los lenguajes de facto en el desarrollo de juegos, pero realmente me gusta la filosofía detrás de XNA. Como dije anteriormente, soy experto tanto en C # como en C ++, pero si no recuerdo mal, XNA funciona solo con lenguajes compatibles con CLR (quizás solo solo C #).

¿Centrarme en el desarrollo de juegos usando XNA y C # en lugar de C ++ afectará mis posibilidades de conseguir un trabajo en la industria de los juegos? VB tiene una reputación injusta de no ser un lenguaje de programación real, y los programadores de VB están atrapados en ese estigma. ¿Es este el caso con el uso de C # en una comunidad que consiste principalmente en desarrolladores de C ++?

¿O los fundamentos del desarrollo de juegos que se pueden aprender de la escritura de juegos trascienden el lenguaje y las tecnologías?

No creo que perjudique sus posibilidades. C # se está volviendo más popular, especialmente con XNA y SlimDX. He usado C # y C ++, y debo decir que preferí XNA significativamente. Era más limpio trabajar con él, pero no tanto como para sentir que no estabas haciendo nada.

Para la parte de la carrera, querrás mencionar que estás acostumbrado a XNA, aunque no creo que perjudique tus posibilidades. De hecho, debido a la forma en que es más fácil de usar, las piezas de su cartera pueden ser mejores.

Y los conceptos siguen siendo los mismos, solo la sintaxis se vuelve diferente. A menos que vaya para un trabajo de gráficos de bajo nivel, el diseño de lo que tiene que hacer sería casi el mismo (no escribir código de carga del sombreador o cachés de malla, en lugar de cargarlo).

Según mi experiencia, los mismos conceptos utilizados en XNA se transfieren entre diferentes bibliotecas e idiomas. He podido saltar de un lado a otro entre diferentes tecnologías de juego, y comencé con XNA.

Trabajar con C # y XNA me ayudó a concentrarme en un objetivo de aprendizaje específico ("¿Qué hace que un juego funcione?") En lugar de mezclar objetivos ("¿Cómo aprendo X y hago un juego al mismo tiempo?"). Descubrí que cada vez que combinaba objetivos, terminaba con resultados bastante abismales. Sin embargo, comenzar en mi zona de confort y apoyarme en XNA ayudó a que todo funcionara.

Si puedes hacer un juego divertido, y en realidad eres un ingeniero talentoso, no tienes de qué preocuparte. Nadie te criticará por cómo hiciste tu juego.

Los juegos no se mantienen como muchos otros productos de software. Se genera menos código de descarte que en la industria de efectos especiales, pero aún podemos evitar muchos hacks por conveniencia.

Solo haz el trabajo. Al final del día, de eso se trata el desarrollo del juego.

Me han dicho que:

1. El contenido es significativamente más importante que las herramientas utilizadas con algunas excepciones.

2. Aunque la base de la mayoría de los juegos más grandes es C ++, es porque las herramientas están desarrolladas en C ++. Si no está codificando las herramientas, es posible que no esté programando en C ++ de todos modos.

Editar: Además, tener un proyecto de demostración completado en cualquier cosa (C #, etc.) es significativamente mejor que tener algo incompleto en un lenguaje más difícil (C ++, etc.).