¿Cuáles son las tareas típicas del día a día de un programador de juegos de nivel básico? [cerrado]


64

Lo que me gustaría saber es: ¿Cuáles son las tareas diarias de un programador graduado en el lugar de trabajo de la industria de los juegos? ¿Se trata principalmente de codificación, análisis, diseño o qué?

Gracias.

PD: Estoy en mi segundo año de universidad en este momento y estoy trabajando para especializarme en programación de juegos, específicamente juegos, herramientas o programación de UI.

Respuestas:


103

Según mi experiencia (en los Estados Unidos, contratado fuera de la universidad en un proyecto que acababa de salir de la creación de prototipos y era un equipo de aproximadamente 50 personas, luego fue cancelado, luego pasamos a hacer dos juegos más durante los cuatro años que pasé). estaba allí con una base total de desarrolladores de aproximadamente 200),

  • Probablemente pasará alrededor del 50-70% de su tiempo programando. En este momento, incluyo las 'cosas divertidas' como hacer una función realmente inteligente, así como las veces que estás mirando un volcado de memoria durante 8 horas seguidas tratando de descubrir qué se estrelló. Tal vez el 25-50% de eso es una programación real de sentarse a su teclado y entrar en la zona.
  • Otro 15-25% en reuniones y tareas administrativas, como clasificación de errores, reuniones sobre clasificación de errores, programación, documentación de alto nivel para otros programadores y productores, correo electrónico, actualizaciones de todo el proyecto / estado de la empresa, etc. Esto depende de cuánta autonomía tenga: si no tiene autonomía, entonces pasará más tiempo programando, porque pasará menos tiempo estableciendo su propio horario. Si tomas más control de tu horario, podrías comenzar a trabajar en cosas más interesantes, pero luego debes dedicar tiempo a hacer estas cosas.
  • Otro 15-25% ayuda a diseñadores / artistas, asiste a reuniones creativas sobre el juego, se mantiene al día con los documentos de diseño del juego, etc.

A medida que avanza en la calificación salarial, el tiempo que dedica a la programación probablemente disminuirá . Tendrá que tomar más decisiones administrativas, se le pedirá que ayude a las personas con menos experiencia en el equipo y pasará más tiempo haciendo documentación y revisión de código / arquitectura. En el lado positivo, la calidad de la programación probablemente aumentará; podrá trabajar en funciones más interesantes (y errores más frustrantes).

Si el tiempo que dedicas a ayudar a los diseñadores y artistas aumenta, disminuye o no cambia realmente, depende del área en la que quieras trabajar. Si quieres trabajar en la interfaz de usuario, las herramientas y el juego, espera que ese tiempo aumente hasta más del 50% a medida que ganes más experiencia. Te sentarás con diseñadores senior para planificar y demostrar nuevas herramientas y ver cómo usan las existentes. Desafortunadamente, esta vez también sale de su programación.


No es exactamente como lo recuerdo, pero ayuda cuando tu compañero de entrenamiento realmente te enseña cosas ;-)
coderanger

@coderanger: No creo que ninguno de nosotros haya recibido mucha ayuda de nuestro compañero de entrenamiento. ;)

26

Además de los puntos de discusión de alto nivel que Joe mencionó, hay algunas otras cosas que debe tener en cuenta.

  • Por lo general, utilizará algún tipo de herramienta de seguimiento de errores o de tareas que su cliente potencial utilizará para asignarle tareas. A veces son lo mismo (es decir, FogBugz). A veces, su lista de errores será a través de un editor y su lista de tareas se encuentra en un wiki interno. No solo te sientas y comienzas a hacer lo que sea , tus tareas serán dirigidas.
  • A veces se le pedirá que calcule sus tareas. Esto está implícito cuando se usan sistemas como FogBugz. Parte de sus responsabilidades será / debería / puede ser desglosar una característica de nivel superior en partes que pueda usar para estimar adecuadamente cuánto tiempo tomaría para ver cuán encaminado está para terminar los hitos, etc.
  • Muchos estudios se han movido a metodologías de estilo más ágil / scrumm. La actualización de los gráficos de quemado (es decir, decir que pasó X horas en la tarea Y y espera terminar en tiempo Z) es bastante común. Las reuniones de pie diarias son probablemente un poco más comunes. De cualquier manera, estarás proporcionando algo de visibilidad en lo que estás trabajando.
  • Utilizará el control de versión / fuente. Cuanto más grande sea el estudio, es más probable que usen Perforce. Debe tener en cuenta los conceptos básicos (revisar archivos, confirmar archivos, poder resolver sus conflictos de fusión locales). También es posible que se le pida que comprenda ramificaciones y fusiones de ramas. Algunos estudios funcionan donde todos los desarrolladores obtienen su sucursal local y usted puede registrarse tanto como desee y fusionarse cuando su sucursal. Otros estudios (el nuestro) solo tienen una política de "no romper", por lo que debe asegurarse de actualizar, hacer una prueba rápida para asegurarse de que no rompió nada y luego registrarse. Algunos estudios no tienen esa política y las personas rompen mierda todo el tiempo y es súper molesto y tienes que aprender a solucionarlo.
  • Las revisiones de código son bastante comunes. A veces son códigos de todo el departamento. Nuestro equipo utiliza un enfoque de código amigo donde es más individualizado para las revisiones en los registros. De cualquier manera, debe esperar que se le pida que proporcione un análisis crítico del código de otras personas.

11

Acabo de terminar una pasantía de 4 meses trabajando en un juego muy grande. El proyecto estaba en una etapa muy tardía cuando llegué allí, por lo que la mayoría de lo que hice fue corregir errores. De todos modos, eso probablemente hubiera sido una parte decente de mi tiempo ... usar mi experiencia con la codificación para corregir errores en lugar de mi inexperiencia con el desarrollo de juegos para diseñar o desarrollar características.

Mucho de lo que hice también estaba relacionado con TI. El desarrollo de herramientas internas fue una gran cosa: algunas para ayudar directamente con el desarrollo del juego, otras para automatizar cosas que se hicieron manualmente antes. Y, por supuesto, correcciones de errores para otras herramientas, incluido el instalador de Microsoft Games para Windows Live.

Las pruebas de juego fueron otra parte decentemente grande, y también fui responsable de hacer algunas de las compilaciones que se enviaron a los jugadores de prueba. Los errores en el mundo del juego son bastante difíciles de localizar y requieren mucho trabajo para descubrir la causa.

No me especialicé en juegos o gráficos, por lo que presumiblemente cualquier trabajo que hicieras estaría más relacionado con tu experiencia que esto. Pero espero que te dé una idea.


4

Mi proyecto de año final está en el elemento de lienzo HTML5. Actualmente estoy trabajando en una pasantía durante los últimos dos meses donde tengo que portar un juego flash existente al lienzo HMTL5.

Por lo que puedo contarte sobre mi vida aquí, bueno, es difícil. El equipo de requisitos tiene demandas muy específicas. Se supone que el clic del mouse debe hacer qué, cómo se deben aplicar los efectos en el juego. No importa cuán difícil sea para el programador, incluso para la solicitud más tonta, debe abordarse, y después de que se implementen todos los requisitos. El inicio de informe de errores. Dios es tan molesto. Realmente comienza a ponerte nervioso. Un desplazamiento de 1 px por un clic puede hacer que tu vida sea un infierno, ¡confía en mí! Puede significar una nueva estructuración de todo su espacio de posicionamiento e interacción para que pueda adaptarse a sus caprichos y fantasías.

¡Pero también es divertido! :) La gran alegría de escribir esa función realmente inteligente, interactuando con la comunidad de cómo podría recrear una función que flash hace automáticamente. Todo ello. En momentos como ese no te arrepientes de tener ese trabajo. Lo hace sentir como el mejor trabajo del mundo, y para mis sobrinos, el mejor del mundo.

Entonces, un día normal en mi trabajo vendría a trabajar implementando una función. Investigar y buscar esa función que hace posible una función. Obtener el infierno probado con ese código. Arreglando ese código. Discutir con la comunidad sobre cómo se podría optimizar ese código. Luego, escribir lo que siento es el mejor programa en la tierra: P

Al final del día, en su mayoría estoy satisfecho con lo que he logrado, a veces todavía estoy tenso acerca de dónde podría haberlo hecho mejor y qué podría haber hecho diferente y perfeccionar eso. Acabo de estar en la fase de principiante y, por lo tanto, es posible que no pueda aconsejarle sobre cómo será en el futuro, pero a partir de ahora ... creo que tengo que hacer el mejor trabajo :)

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.