Juegos terminados VS Programar bien

[Lustrike]

Hola a todos.

Venía en busca de la siguiente opinión. Soy consciente de que la industria valora mucho la gente que presenta proyectos/demos/juegos terminados, pero me gustaría una explicación más detallada sobre este tema.

Por lo que la cuestión es:

Si yo os presento un juego terminado, pero éste no está bien programado, o por el contrario, si un juego no está terminado, pero sí está siendo bien programado... ¿Cuándo se valora más que un juego esté terminado y cuándo que esté bien programado? O en caso de que no importe que esté bien programado... ¿Cuál sería el límite en el que algo terminado que está mal programado no es aceptado?

Me gustaría leer opiniones si es posible. Y si se crea debate de este asunto, también sería agradable de ver.

Gracias de antemano.

[jmtu]

Desde alguien que no está en la industria, no termina los proyectos que empieza (se alaaaaargaan) y programa con código spaghetti no veo por qué esos dos terminos (juegos terminados/programar bien) han de estar enfrentados.

  Personalmente valoraría que el proyecto presentado estuviese bien acotado en sus ambiciones, que fuese jugable, aunque no llegase a estar terminado, y que tuviese un código no demasiado feo aunque con los trucos necesarios para tamaño/velocidad del mismo, cosa que suele estar en contra de un código limpio, estructurado y legible (buen código). Y acompañado por la documentación que muestre por qué se han tomado las decisiones de diseño y programación que se han tomado.

   Pero no soy, ni he formado, parte de la industria y no creo que vaya a trabajar con nadie en proyectos propios en un futuro futurible.

Nos vemos.

[Fanakito]

¿Que entiendes por bien programado? Porque entiendo por como planteas la pregunta que consideras que programar "bien" puede ser un handicap a la hora de terminar el juego. De hecho, de cara a terminar un proyecto de portfolio, usualmente si no está bien programado es más dificil terminarlo, porque mantener codigo malo suele ser menos agradable.

Otra cosa sería si me hablaras de GameJams, donde a veces si se pueden tomar ciertos atajos para ir rápido, pero en un proyecto de un par de meses, yo creo que el tiempo que puedes perder por hacer las cosas "bien" lo ganas a lo largo del proyecto.

Pero una cosa es programar bien y otra la sobreingenieria. Si el código es legible y, cuando toma atajos, dejas una nota para que quede claro que sabes que esto esta mal, pero lo arreglarás más adelante, para mí es suficiente. Pero hay muchas cosas que se consideran "programar bien" que no te hacen ir más lento. Para más info no está de más leerse The Art of Readable Code p.ej.

[Lustrike]

Pondré un ejemplo:

Yo estoy haciendo un proyecto en el que implemento movimiento; y durante ese proyecto implemento el movimiento de una forma que para mí está correcta, pero que es posible que para una empresa no sea la forma más eficiente o correcta de hacerlo.

Entonces la cosa es que a pesar de que yo haya implementado el movimiento y terminado mi proyecto, mi duda era que si no implementar una parte de un juego de la mejor forma posible para una empresa, puede ser algo que me quite puntos a pesar de tener un juego terminado, o viceversa.

[Sefhi]

Creo que no hay solo una manera de hacer las cosas, no es o bien o mal hecho, hay formas mas eficientes de resolver un problema que otras, obviamente si vas a optar por un puesto junior no creo que se fijen tanto en esas cosas (aunque lo haran probablemente, hablo desde la inexperiencia de no haber trabajado nunca en empresas xD).

Con el tiempo tu mismo iras encontrando formas mejores de hacer las cosas sea por ti mismo o por medio de otras personas, y respecto a juego terminado vs programar bien, algunas empresas si es cierto que piden juegos lanzados ya al mercado (play store etc), pero tambien puedes tener varias demos enseñando algunas cosas en vez de juegos enteros (sistemas de particulas, un movimiento de personaje como tu dices, una camara, cualquier cosa que te guste y creas que esta bien implementada).

[valnar]

Desde mi experiencia, todas las empresas en las que he formado parte del proceso de selección, no revisan el código que has utilizado para hacer los juegos de tu portfolio. Si intentas acceder a un puesto de programador (generalmente) van a pedirte que hagas una prueba/test (un juego sencillo, implementar una feature, etc..), y de esa manera valoran tu capacidad de "codear" en un tiempo determinado. Dependiendo del puesto al que quieras acceder (junior, senior, lead) te pedirán más legibilidad, orden, mejor forma de resolver problemas, etc...

[Lustrike]

Gracias a los 4, ya tengo algo más clara la escena.

De todas formas, sigo abierto a leer más opiniones. Nunca está de más.

Muchas gracias y un saludo.

[Fanakito]

Entonces la cosa es que a pesar de que yo haya implementado el movimiento y terminado mi proyecto, mi duda era que si no implementar una parte de un juego de la mejor forma posible para una empresa, puede ser algo que me quite puntos a pesar de tener un juego terminado, o viceversa.

Que no habrás usado la mejor forma posible es algo que ya entra dentro de los parametros que se esperan (especialmente para un Junior). Pero cuenta que sepas moverte por una base de codigo de complejidad razonable (porque lo que te encontrarás dentro es aún mayor). También que sepas resolver los problemas (y por eso lo de terminar los juegos, porque te habrás tenido que enfrentar a dificultades cuando el codigo ha crecido y lo importante es ver como lo has resuelto.

De hecho, los proyectos sirven para tener un tema que hablar en la entrevista. Cuando busqué trabajo por primera vez estuve hablando sobre mi proyecto del Master y que había hecho, que problemas habíamos encontrado, que había hecho yo, etc.

[Lustrike]

Muchas gracias, esto último definitivamente me ha despejado las dudas :).

[Vicente]

Una gran verdad de la programación es que todo puede estar mejor programado. Da igual lo que pienses hoy, dentro de 6 meses pensarás que podrías haberlo hecho mejor.

Así que en mi opinión, mejor terminar las cosas.

Un saludo!
Vicente

[notoi]

Yo personalmente, cada vez qe hago un nuevo proyecto soy más ordenado. Pero a veces algo que no tenia pensado incluir, lo meto como puedo(lio mental y mucho tiempo) o borro mucho código antiguo y lo programo desde 0(que al final resulta que es más rápido y ordenado). De todas formas hace tiempo vi una página bastante interesante y que tengo pendiente de mirarmelo mejor que habla sobre patrones de programación de cara a hacer un mejor código y está escrito por un tio que trabajó en Electronics Arts(No se si curra aun, ni lo he buscado). La web en cuestion :

www.gameprogrammingpatterns.com

[XÑA]

Código ordenado= 1/(tiempo que tienes para desarrollarlo + ganas de hacer la aplicación * 2)

[Sante]

Yo lo valoraría en este orden:

1) Juego terminado, y bien programado.
2) Juego terminado, y mal programado.
3) Juego no terminado, pero lo que hay está bien hecho.
4) Juego no terminado, y mal hecho.

Aunque como dice Valnar, las empresas generalmente no van a mirar el código de tu proyecto, sino que van a evaluar tu nivel de programación mediante tests y/o preguntas en la entrevista.

[robertsan82]

Muchas gracias por compartir vuestras experiencias