Desarrollo de videojuego por empresa, desastroso.

Archivado
Buenas, en mi empresa hemos decidido sacar un videojuego con la temática de la que trata nuestra empresa y para ello contratamos a una empresa "X", da igual el nombre, para que nos realizará el videojuego.

El videojuego esta hecho, pero 6 meses fuera de plazo del previsto, así mismo, cada vez que solucionan algo la fastidian por otro lado y así llevamos, sin una versión final 6 meses después de tenerse que haber lanzado el videojuego.

El videojuego lo han hecho con Unity.

Mi pregunta es, como mi empresa tiene todos los derechos sobre el videojuego, es posible que si nos dan el proyecto de Unity, que pueda seguir realizándolo otra empresa diferente. ¿Como de complejo sería?

Vamos, no se si Unity es como a la hora de programar por ejemplo en PHP, que se va indicando que hace cada código que escribes con "#Aquí va el login del usuario" con lo que facilitar la estructura o Unity es más estructurado en si.

Lo digo porque claro, si ha de ir estructurado y esta gente no ha puesto ni una línea de información, la nueva empresa iría perdida y sería de nuevo un porrón de horas a pagar de trabajo ya realizado para descubrir que han hecho estos.

En fin, espero podáis ayudarme y a ver si podemos sacar el videojuego en condiciones, que menuda panda de patanes nos ha tocado y no son precisamente baratos, aunque vamos, sacar un videojuego no suele ser barato.

Gracias.
A mi me suena al proyecto de software estándar [+risas] [+risas] [+risas]

No tengo npi de Unity, pero si muchos años ya en consultoria informatica y la respuesta es: depende.

Si la estructura básica esta hecha una puta mierda, otra empresa que lo coja va a tardar lo mismo o incluso MENOS en empezar casi de cero (habrá assets que sean reutilizables) que en arreglar el desaguisado. Si no es una putisima mierda, lo que se suele hacer en estos casos es coger del cuello a la empresa que te la ha liado parda y obligarles, bajo amenaza de demanda por incumplimiento de contrato si hace falta, a facilitar el traspaso a la segunda empresa. Bien obligandoles a dejar BIEN documentado lo que han hecho o a explicarlo adecuadamente a los nuevos. De lo contrario no van a ayudar en nada y la nueva empresa va a flipar (y vosotros tambien).
mortisdj escribió:Mi pregunta es, como mi empresa tiene todos los derechos sobre el videojuego, es posible que si nos dan el proyecto de Unity, que pueda seguir realizándolo otra empresa diferente. ¿Como de complejo sería?

Por lo que cuentas, el proyecto es tan mierdoso que ni la propia desarrolladora se aclara con él. Probablemente, cueste menos tiempo que lo haga una buena empresa desde 0, que una muy buena empresa lo arregle con la base que teneis.

Vamos, no se si Unity es como a la hora de programar por ejemplo en PHP, que se va indicando que hace cada código que escribes con "#Aquí va el login del usuario" con lo que facilitar la estructura o Unity es más estructurado en si.

Pues según creo unity se basa en C++, así que puede haber comentarios... o puede haber un merdel enorme.
Por no haber, puede que ni haya clases. Es que a saber cómo han programado hasta el momento.

Para que te hagas una idea, yo programo software industrial. Y más de una (y más de 10 veces) me ha llegado software donde las "variables" son referencias directas a memoria... es decir, no tienen ni nombre.
Así que imagina qué infierno es arreglar algo cuya base es todo %m1000, %m1001, %mw3000... y así.
jorcoval escribió:
mortisdj escribió:Mi pregunta es, como mi empresa tiene todos los derechos sobre el videojuego, es posible que si nos dan el proyecto de Unity, que pueda seguir realizándolo otra empresa diferente. ¿Como de complejo sería?

Por lo que cuentas, el proyecto es tan mierdoso que ni la propia desarrolladora se aclara con él. Probablemente, cueste menos tiempo que lo haga una buena empresa desde 0, que una muy buena empresa lo arregle con la base que teneis.

Vamos, no se si Unity es como a la hora de programar por ejemplo en PHP, que se va indicando que hace cada código que escribes con "#Aquí va el login del usuario" con lo que facilitar la estructura o Unity es más estructurado en si.

Pues según creo unity se basa en C++, así que puede haber comentarios... o puede haber un merdel enorme.
Por no haber, puede que ni haya clases. Es que a saber cómo han programado hasta el momento.

Para que te hagas una idea, yo programo software industrial. Y más de una (y más de 10 veces) me ha llegado software donde las "variables" son referencias directas a memoria... es decir, no tienen ni nombre.
Así que imagina qué infierno es arreglar algo cuya base es todo %m1000, %m1001, %mw3000... y así.

Pues yo he oído que Unity va en C#
amchacon escribió:
jorcoval escribió:
mortisdj escribió:Mi pregunta es, como mi empresa tiene todos los derechos sobre el videojuego, es posible que si nos dan el proyecto de Unity, que pueda seguir realizándolo otra empresa diferente. ¿Como de complejo sería?

Por lo que cuentas, el proyecto es tan mierdoso que ni la propia desarrolladora se aclara con él. Probablemente, cueste menos tiempo que lo haga una buena empresa desde 0, que una muy buena empresa lo arregle con la base que teneis.

Vamos, no se si Unity es como a la hora de programar por ejemplo en PHP, que se va indicando que hace cada código que escribes con "#Aquí va el login del usuario" con lo que facilitar la estructura o Unity es más estructurado en si.

Pues según creo unity se basa en C++, así que puede haber comentarios... o puede haber un merdel enorme.
Por no haber, puede que ni haya clases. Es que a saber cómo han programado hasta el momento.

Para que te hagas una idea, yo programo software industrial. Y más de una (y más de 10 veces) me ha llegado software donde las "variables" son referencias directas a memoria... es decir, no tienen ni nombre.
Así que imagina qué infierno es arreglar algo cuya base es todo %m1000, %m1001, %mw3000... y así.

Pues yo he oído que Unity va en C#



Y la diferencia entre C++ y C# en cuanto a referenciar las líneas de código?
En cuanto a documentación ninguna.

De todas formas, un buen código no requiere comentarios. Es auto-explicativo.
amchacon escribió:En cuanto a documentación ninguna.

De todas formas, un buen código no requiere comentarios. Es auto-explicativo.


Está claro, pero visto lo visto y como han funcionado, creo que muy bien no estará. Además que son varias versiones (previo paso por caja de cada una), Windows, Mac, Linux, Android, IOS y no hay una que vaya en condiciones.
Ashdown está baneado por "faltas de respeto"
amchacon escribió:En cuanto a documentación ninguna.

De todas formas, un buen código no requiere comentarios. Es auto-explicativo.

Mis códigos son de una calidad decente y segun qué cosas mejor que estén documentadas en lenguaje humano. Qué menos que poner 'se resuelve el sistema por el método de Gauss-Jordan y si no es determinado aplicamos aproximaciones numéricas desde los ejes x y y z'.
Ashdown escribió:
amchacon escribió:En cuanto a documentación ninguna.

De todas formas, un buen código no requiere comentarios. Es auto-explicativo.

Mis códigos son de una calidad decente y segun qué cosas mejor que estén documentadas en lenguaje humano. Qué menos que poner 'se resuelve el sistema por el método de Gauss-Jordan y si no es determinado aplicamos aproximaciones numéricas desde los ejes x y y z'.

Bueno claro, siempre hay casos válidos para poner comentarios. Yo siempre los intento minimizar y uso los nombres de los métodos para orientar al lector sobre los pasos (importante que los métodos sean cortos).

Lo que no soporto es ver un código lleno de comentarios de este estilo:

// Añade 1 al contador de pacientes
pacientes = pacientes + 1;


Esto y no poner nada es lo mismo.
amchacon escribió:
jorcoval escribió:
mortisdj escribió:Mi pregunta es, como mi empresa tiene todos los derechos sobre el videojuego, es posible que si nos dan el proyecto de Unity, que pueda seguir realizándolo otra empresa diferente. ¿Como de complejo sería?

Por lo que cuentas, el proyecto es tan mierdoso que ni la propia desarrolladora se aclara con él. Probablemente, cueste menos tiempo que lo haga una buena empresa desde 0, que una muy buena empresa lo arregle con la base que teneis.

Vamos, no se si Unity es como a la hora de programar por ejemplo en PHP, que se va indicando que hace cada código que escribes con "#Aquí va el login del usuario" con lo que facilitar la estructura o Unity es más estructurado en si.

Pues según creo unity se basa en C++, así que puede haber comentarios... o puede haber un merdel enorme.
Por no haber, puede que ni haya clases. Es que a saber cómo han programado hasta el momento.

Para que te hagas una idea, yo programo software industrial. Y más de una (y más de 10 veces) me ha llegado software donde las "variables" son referencias directas a memoria... es decir, no tienen ni nombre.
Así que imagina qué infierno es arreglar algo cuya base es todo %m1000, %m1001, %mw3000... y así.

Pues yo he oído que Unity va en C#


Lo que 'va' es el scripting, unity como tal es un game engine con el que crear juegos, dentro del programita puedes programar con líneas de código ciertas acciones, por ejemplo, se programaría con líneas de código lo que quieres que pase cuando una bala impacte contra un jugador (por ejemplo), mientras que otros temas (como por ejemplo la creación de escenarios, o asignar texturas a algo, entre otros) se podría hacer mediante ratón.
Las líneas de código que se escriben pueden ser mínimo en c# o en javascript, desconozco si permite crear scripts con c++ , creo que no.

Otra cosa es el lenguaje en que se ha creado Unity, ahí creo que si que es c++, pero eso no afecta a la creación de juegos (a no ser que tengas que modificar el engine por X motivo, se que los estudios de desarrollo profesionales están acostumbrados a modificar el engine para poder realizar ciertas tareas, pero para eso hace falta el código fuente, unreal4 si que te lo ofrece, ni zorra de si Unity lo hace también).

Sobre si seria complejo o no pasar el proyecto a otra empresa...pues dependerá del desastre que hayan hecho, si han documentado bien, si han puesto comentarios en el código...vamos, no te lo puedo decir de primera mano, pero supongo que costará lo mismo que portar un gran proyecto de software de una empresa a otra..dependerá obviamente del estado en que lo hayan dejado.
Si no hay apuntes de cortesía en los scripts (que en unity también se pueden poner), salvad el arte y quemad el resto.
El código no tiene por qué estar comentado a menos que los desarrolladores lo hayan querido comentar. E incluso si está comentado, habría que ver cómo está comentado, que yo he visto cada cosa...

Si el proyecto se ha convertido en un infierno, yo coincido con el anterior compañero: salvad el arte y dádselo a otra compañía para que os desarrolle el juego desde cero. Va a ser más rápido, lo que equivale a que os va a costar menos la broma.
amchacon escribió:En cuanto a documentación ninguna.

De todas formas, un buen código no requiere comentarios. Es auto-explicativo.


La teoría es buena pero eso no es así. Quien no haya cogido su propio código de 6 meses atrás y haya pensado "por qué cojones hice esto?" es que no ha programado lo suficiente XD

Respecto al hilo, hay que verlo. A veces la base esta bien hecha pero luego se quedaron sin tiempo/dinero para pulir las cosas. En esos casos puede haber cosas que se salven de la quema. Aunque pinta mal según lo cuenta el OP.
Desarrollo videojuegos desde hace años(con Unity) y ya te digo,que por lo que comentas, la cosa pinta muy mal...

Este o no comentado, si tiene tantisimos bugs... igual es mejor empezar desde cero, aunque todo seria revisar el código.

DEBEN daros el código, y se lo entregáis al nuevo equipo...ojala puedan salvar algo, es una pena que estos casos ocurran....
redscare escribió:La teoría es buena pero eso no es así. Quien no haya cogido su propio código de 6 meses atrás y haya pensado "por qué cojones hice esto?" es que no ha programado lo suficiente XD

Tienen sus usos. Pero creo que un buen programador debería intentar expresarse por código siempre que pueda.

Ejemplo:

void App::start()
{
    while (window.isOpen())
    {
      // Clear the screen
     
      glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
      glClear(GL_COLOR_BUFFER_BIT);

      // Draw

      glBindVertexArray(vertex_array);
          glDrawArrays(GL_TRIANGLES, 0, NUM_TRIANGLES);
      glBindVertexArray(0);   // Unbind the vertex_array

      // Update the screen         
       window.display();
    }
}


Así es como lo haría yo:

void App::start()
{
    while (window.isOpen())
    {
        clearScreen();
        drawScreen();
        updateScreen();
    }
}

void App::clearScreen()
{
    glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);
}

void App::drawScreen()
{
    vertex_array.bind();
        glDrawArrays(GL_TRIANGLES, 0, NUM_TRIANGLES);
    vertex_array.unbind();
}

void App::updateScreen()
{
    window.display();
}


A mí me parece bastante claro, no sé.
amchacon escribió:
redscare escribió:La teoría es buena pero eso no es así. Quien no haya cogido su propio código de 6 meses atrás y haya pensado "por qué cojones hice esto?" es que no ha programado lo suficiente XD

Tienen sus usos. Pero creo que un buen programador debería intentar expresarse por código siempre que pueda.

Ejemplo:

void App::start()
{
    while (window.isOpen())
    {
      // Clear the screen
     
      glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
      glClear(GL_COLOR_BUFFER_BIT);

      // Draw

      glBindVertexArray(vertex_array);
          glDrawArrays(GL_TRIANGLES, 0, NUM_TRIANGLES);
      glBindVertexArray(0);   // Unbind the vertex_array

      // Update the screen         
       window.display();
    }
}


Así es como lo haría yo:

void App::start()
{
    while (window.isOpen())
    {
        clearScreen();
        drawScreen();
        updateScreen();
    }
}

void App::clearScreen()
{
    glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);
}

void App::drawScreen()
{
    vertex_array.bind();
        glDrawArrays(GL_TRIANGLES, 0, NUM_TRIANGLES);
    vertex_array.unbind();
}

void App::updateScreen()
{
    window.display();
}


A mí me parece bastante claro, no sé.


Mis dies
@amchacon Estoy de acuerdo contigo que los comentarios moñas de "aqui sumo dos numeros" no aportan nada. Pero tu ejemplo es demasiado sencillo. Cuando tienes un metodo que hace cosas complicadas es mejor documentarlo.

Por ejemplo, este es mio en mi proyecto actual (con algunos cambios para no poner en internet detalles de la BD). No lo pongo como ejemplo de perfección ni mucho menos, que conste.

    /**
     * Deletes a contract previously created by the XXX application.
     * Expects as input both the contractId and the assoiciated child records IDs in the
     * XXX table and appropiate YYY table. It first deletes the child records
     * and then tries to delete the contract. If the contract has more children, the service will fail
     * and rollback any deleted records. This is done to avoid deleting an active contract with other children.
     * @param request includes contractId and appropiate children IDs
     * @return empty response if OK, soap fault otherwise.
     * @throws FunctionalFault
     */
    public DeleteContractResponseDto deleteContract(DeleteContractRequestDto request) throws FunctionalFault {

Como ves explica el método en general, no linea por linea. Así cuando dentro de 8 meses alguien lo abra porque ha intentado borrar un contrato y le ha dado error, vera que es intencional y no joderá el método cambiándolo. O si algún manco no entiende porque le devuelve una respuesta vacía. O si algun manco no entiende por qué para borrar un contrato el método pide la lista de elementos hijos, etc. Siempre hay que asumir que dentro de un año alguien sin pleno conocimiento funcional de la aplicación va a tener que abrirlo para alguna corrección o cambio.
redscare escribió:@amchacon Estoy de acuerdo contigo que los comentarios moñas de "aqui sumo dos numeros" no aportan nada. Pero tu ejemplo es demasiado sencillo. Cuando tienes un metodo que hace cosas complicadas es mejor documentarlo.

Por ejemplo, este es mio en mi proyecto actual (con algunos cambios para no poner en internet detalles de la BD). No lo pongo como ejemplo de perfección ni mucho menos, que conste.

    /**
     * Deletes a contract previously created by the XXX application.
     * Expects as input both the contractId and the assoiciated child records IDs in the
     * XXX table and appropiate YYY table. It first deletes the child records
     * and then tries to delete the contract. If the contract has more children, the service will fail
     * and rollback any deleted records. This is done to avoid deleting an active contract with other children.
     * @param request includes contractId and appropiate children IDs
     * @return empty response if OK, soap fault otherwise.
     * @throws FunctionalFault
     */
    public DeleteContractResponseDto deleteContract(DeleteContractRequestDto request) throws FunctionalFault {

Como ves explica el método en general, no linea por linea. Así cuando dentro de 8 meses alguien lo abra porque ha intentado borrar un contrato y le ha dado error, vera que es intencional y no joderá el método cambiándolo. O si algún manco no entiende porque le devuelve una respuesta vacía. O si algun manco no entiende por qué para borrar un contrato el método pide la lista de elementos hijos, etc. Siempre hay que asumir que dentro de un año alguien sin pleno conocimiento funcional de la aplicación va a tener que abrirlo para alguna corrección o cambio.

Pues me parece un comentario bastante legítimo y útil, creo que llegamos a la conclusión que los comentarios que explican "porqué" sucede esto pueden ser bastantes importantes :)

Por cierto:
It first deletes the child records
     * and then tries to delete the contract.


Esta frase me parece que sobra. Ya estás explicando el "cómo" lo haces, y para eso está el código. Imagínate que añades un proceso adicional y no actualizas el comentario, puede dar lugar a confusión.

    /**
     * Deletes a contract previously created by the XXX application.
     * Expects as input both the contractId and the assoiciated child records IDs in the
     * XXX table and appropiate YYY table. If the contract has more children, the service will fail.
     * This is done to avoid deleting an active contract with other children.
     * @param request includes contractId and appropiate children IDs
     * @return empty response if OK, soap fault otherwise.
     * @throws FunctionalFault
     */
    public DeleteContractResponseDto deleteContract(DeleteContractRequestDto request) throws FunctionalFault {
Si decís que es un quebradero de cabeza, yo no lo dudaría. Cambiaría de compañía a la de ya.

El código es vuestro, que os lo den todo y ir con eso a otra compañía y que ya ellos os digan lo que pueden salvar. Podéis probar con varias, para así tener varias opiniones y poder valorar.
Rokzo escribió:El código es vuestro

Habría que ver lo que han firmado.

Han podido bajarles el coste a cambio de quedarse con el "derecho" a recursos de desarrollo desarrollados por su empresa y facilitar solo compilados.

En este mundo hay de todo.

Tanto lío que decís os han hecho, se puede saber el género y si es 2D o 3D? Ya me has despertado la curiosidad y quiero comentarlo con un conocido que tiene una empresa de desarrollo de videojuegos que me cuente su opinión y batallitas de cosas terribles que ha visto xD
19 respuestas
Archivado
Volver a Miscelánea