edición general
108 meneos
2415 clics
La parte más difícil de hacer de un videojuego es… TODAS [ENG]

La parte más difícil de hacer de un videojuego es… TODAS [ENG]

Hace unos meses, planteé a desarrolladores de todo el sector la siguiente pregunta: "¿Qué cosa de los videojuegos parece sencilla pero en realidad es extremadamente difícil de hacer para los desarrolladores?" Recibí casi 100 respuestas que representaban una amplia experiencia en el sector, desde desarrolladores en solitario hasta aquellos que habían abordado problemas en equipos de cientos de personas. […] Han recibido comentarios de jugadores enfadados: "¿Por qué no haces X?" La respuesta es, casi siempre: porque es muy, muy difícil.

| etiquetas: programador , viedojuego , diseño , mecánicas , 3d , historia , gameplay
  1. Una tontería como el típico avatar que el jugador puede personalizar puede convertirse en un inmenso quebradero de cabeza. Cosas como ponerse falda y pantalón a la vez, por ejemplo.

    Los ránkings son un problemón en juegos multijugador masivo. El típico listado de de los mejores del día/mes/año/toda la vida. Parecen fáciles pero se complican muchísimo, especialmente si no puedes cachear o diferir los cálculos.

    Otra tontería con la que he llorado. No poder sacar la lista de personas que me tienen de amigo. Detallitos de las BD no relacionales. :->
  2. Mucho más sencillo desde que hay motores y una infinidad de herramientas.
  3. #1 Es un poco obvio pero ¿has pensado en tener la lista de los que te tienen de amigo en tu propio registro? :-)
  4. #2 Bueno en realidad los motores gráficos han abierto mucho más las posibilidades dentro de los videojuegos por lo que, aunque han solucionado muchos problemas antiguos, han traído otros nuevos.
  5. #3Todo es obvio hasta que deja de serlo. No es tan directo cuando tienes cientos de miles de registros, quizás millones, y las relaciones de amistad están cualificadas por juego, tipo de amistad, fechas, etc ..
  6. #4 ¿Qué problemas nuevos?
  7. #6 así a bote pronto se me ocurren la dinámica de fluidos, la física de las tetas, los pelos, los reflejos de luz...
  8. #7 la física de las tetas se perfeccionó en Dead or Alive Volleyball
  9. Lloricas :shit:
  10. #7 Hay APIs para los pelos, los reflejos ahora que se va a hacer todo por fuerza bruta con RT tampoco deberían dar problemas, dinámica de fluidos todavía no he visto ejemplos y lo de las tetas siempre hay alguien dispuesto a meter horas en que luzcan gloriosas. No es lo mismo pero en NieR: Automata la mitad del presupuesto se les fue en el culo de 2B.
  11. #3 Estupendo, el registro de cada jugador va a ocupar lo que no está escrito.
  12. #6 el raytracing no es tan automático como debería ser :-/
  13. Decir que la parte más difícil de hacer un videojuego es todas, es equivalente a decir que la parte más fácil de hacer un videojuego es todas :shit:
  14. #1 Y meterlo en una relacional?
  15. La parte más sencilla: Hacer un remaster para la siguiente generación en lugar de sacar uno nuevo.
    Saquen ya las sextas partes de GTA y Elder Scroll o matamos a un rehén cada hora.
  16. La parte más difícil es tener un producto terminado, viable y vendible. El 99% de los videojuegos que se hacen no pasan de prototipo.

    La parte de "terminar" un juego se lleva el 90% del tiempo de desarrollo.

    Todo esto sin tener en cuenta el marketing, claro.
  17. #10 dinamica de fluidos ya habia en 2002 en el splinter cell. Aunque es verdad que poco se utiliza actualmente:

    youtu.be/uspPDqaLlnU
  18. #8 Itagaki, ese hombre que creó Ninja Gaiden pero al que siempre recordaremos por sus esfuerzos para mejorar las físicas tetiles. El Team Ninja restante sigue su legado, aunque la moral anglosajona siempre está acechante...
  19. El problema es que no son cosas especialmente difíciles. Sino cosas que les PARECEN difíciles

    La inmensa mayoría de desarrolladores de videojuegos no han pasado antes por los "sectores tradicionales". Lo que hace que puedan ser muy buenos en " lo suyo " pero fallen en cuestiones básicas al desarrollo de producto que no han aprendido y nunca aprenderán porque quizás, donde trabajan, nadie ha venido de fuera a traer esas estrategias y herramientas. Y eso si el juego es multijugador y online. Si corre sólo en una máquina para un jugador...

    Por mi experiencia, seis años trabajando en el sector de videjuego como desarrollador y dos más en otros puestos, el gran problema y lo más complicado es conseguir que los jugadores no hagan trampas.

    En un juego online la cantidad de gente que intenta meterse en tu sistema, hacer trampas o robar es abrumador. Yo he llegado a subir la primera versión/beta de una app de ios un jueves y el lunes ya la estaban usando para robar.

    La gente llega a ser muy paciente, resolutiva y original cuando se trata de encontrarle las cosquillas a un juego online.
  20. #15 calla calla, que últimamente llevo una vida equilibrada y como aparezca de nuevo por Skirym se irá todo a cascarla
  21. #18 un héroe de los videojuegos
  22. #17 creo que - si no me falla la cabeza - que el morrowind de bethesda tambien era de esa epoca.. y tambien manejaba decentemente lo de los fluidos
    www.youtube.com/watch?v=g0et8bWoEJk
  23. #1 permíteme no entender el problema. Por mucho que no sea relacional identificarás al amigo de alguna forma, con hacer una consulta sobre ello se podrá ver, digo yo.
  24. Yo trabajo de desarrollador backend y programo juegos por afición y sí que me he dado cuenta de que hacer juegos es mucho más difícil. Sobre todo si tu objetivo es programar "bien".

    La mayor fuente de problemas en programación surge de la interacción entre componentes. En un backend tienes uno o varios servicios de los que dependen y aunque se puede complicar todo está más o menos aislado y jerarquizado. En un juego todos los subsistemas dependen del resto y es extremadamente difícil separarlos. Por ejemplo hoy en día el subsistema de los efectos de sonido necesita conocer el mapa para calcular ecos y reverberación pero los jugadores pueden destruir partes del escenario usando el sistema de físicas. Al final en post de la eficiencia todo subsistema tiene que ser capaz de realizar llamadas al resto acoplando todo el código.

    Las aplicaciones gráficas o las webs también se pueden volver muy caóticas por la cantidad de interacciones entre componentes pero generalmente no mezclan video, sonido, IA, 3D como los juegos así que las pondría un poco por debajo de los videojuegos en cuanto a complejidad.
  25. A trabajar ostias! Que lo queréis todo bien facilito.
  26. #6 igual no son nuevos pero cosas que antes ni se planteaban en la práctica, los motores y nuevo hardware lo hacen algo más accesible.
  27. #13 No vengas con tu logica proposicional a estropear sus lloros :troll:
  28. #19 ¿Cual es el perfil medio del desarrollador de videojuegos?

    La gente que conozco del mundillo no ha pisado una ingenieria, solo han hecho cursos de unity, c# o cosas del estilo de uno o dos años, no se que capacidad de resolucion de problemas pueden tener, pero con ese perfil debe ser todo mas complicado (solo hablo de mi circulo personal).
  29. #11
    Los datos o consumen espacio o tiempo de procesamiento. Nada es gratis. Si quieres rapidez requieres espacio y si quires espacio tendras que gastar tiempo en cacular.
    Primero se establecen los requsitos funcionales y luego se elige una BBDD que los cubra.
  30. #29 Es lo habitual hoy en novatos. Pero no lo único.

    Claro que quien ha estado dos años usando un motor en un curso tiene ventaja ante un universitario que no lo ha usado.

    Antes de Unity era similar. ¿A quién contratas? Al que lleva haciendo juegos él sólo sin ayuda de nadie quizás con su propio motor.

    En eso, es el mejor. Pero hay mucho más que no ha aprendido de otras personas y empresas.
  31. #30 Hoy en día la cosa no es tan sencilla. Se usa mucho embeddings/encoders o algoritmos aleatorios para aproximar datos y resultados. Puedes optimizar tanto espacio como tiempo si aceptas un pequeño porcentaje de errores en los cálculos.

    Por ejemplo tienes estructuras como los bloom filters que te permite saber si un elemento pertenece a un conjunto ahorrando un montón de espacio pero aceptando que a veces puede fallar y devolverte menos elementos de los que realmente hay. Facebook en concreto ha ideado ribbon filters para almacenar la listas de amigos. Seguramente una implementación eficiente de rankings de amigos en un juego los utiliza.
  32. #24 Eso son "putadas" que un determinado motor te puede causar.

    Si tienes un mocroservicio para gestionar el audio sólo tienes que llamarlo para cada evento que genere audio. Si el motor no te lo permite es porque es una mierda.

    Es algo que puede ocurrir con los motores como UE y Unity, que intentan llegar a todos lados y hacen el desarrollo medianamente limpio algo complicado.

    Pero no es algo propio de la industria. Puedes crear un proyecto Android con libgdx y ya está, es programar en Android con las mismas posibilidades.

    Si utilizas un framework o motor estás atado y condenado a él. Es un mal necesario casi siempre pero no es por el mundo del videojuego ni por el sector o la naturaleza del mismo.
  33. #31 Gracias por tu respuesta, un saludo :hug:
  34. #23 Entiendo que lo que dice es que al no ser relacional, tendrá que buscar en todos los ficheros de datos de cada jugador si tú estás en ellos. Al final habría que enviar la búsqueda a todos los "nodos" en plan Map-Reduce, una locura.
  35. #14 El problema de las relacionales imagino que será el rendimiento..., pero que mejor que nos lo cuente él.
  36. Los motores de terceros está volviendo tonta la gente.
  37. #31¿Estas equiparando el que hace su propio motor con el que usa unity?
    ¿Estas diciendo que el que usa unity ha hecho un juego "solo"?
    ¿Cuanto tiempo crees que requiere alguien que se ha sacado la ingeniera informática a aprender a usar un motor de terceros?
  38. #6 ¿Un tsunami de juegos de mierda?
    ¿Que cuando ahora alguien te dice que sabe programar es muy probable que solo sepa unir cajitas màgicas?
  39. #35 depende del número de jugadores, y si hay muchísimos seguro que se puede permitir meter algo que guarde ese dato. En todo caso meterse en un paradigma para encorsetarse tanto me parece poco práctico, no sé.
  40. #14 Una relacional seria ideal, pero alguien ya había tomado la decisión de diseño de usar una no relacional mucho tiempo antes.

    #23 El problema es de rendimiento. Habría que recorrer todos los usuarios para sacar la lista y la cifra se acercaba al millón.

    Al final, lo pongo como ejemplo de que cosas que triviales se pueden complicar mucho en entornos de alta carga como el negocio del gaming.
  41. #24 en post de la eficiencia en pos de la eficiencia
  42. #42 Y no se podría hacer una migración a relacional si mejorase el rendimiento?

    Yo no soy programador de proyectos grandes, pero sí que me he dado cuenta que cuando he tomado alguna idea de diseño no tan buena como pensaba, si que me ha acabado perjudicando y no puedo cambiar el diseño porque implica reprogramarlo todo.
  43. #33 Pero lo habitual en videojuegos es usar un motor. Es raro que se cree un motor. Y muchos de los proyectos grandes usan UE y los medianos Unity. Supongo que es porque si tienes que crear tus propias bibliotecas hoy en día puede ser un infierno. ¿no?

    Lo mismo ocurre con frontends en páginas web, que se usa React, Vue.js o lo que sea. Porque crear el frontend desde 0 puede ser un infierno y llevarte a errores.
  44. #11 si guardas la lista de tus amigos igualmente puedes guardar la lista de los que te tienen de amigo si es relevante.
    Ni con millones de usuarios va a ocupar mucho
  45. #44 Si, claro. El problema es que todo eso formaba parte de un proyecto complejo. En un momento dado, alguien de negocio pide una funcionalidad en la que era necesario obtener esa lista y no tenía sentido darle la vuelta a todo solo por esa petición.
  46. #39 No, no lo he dicho
  47. Hacer cámaras/visión en 3era persona en las que el personaje no tape los objetivos, la cámara no choque con todo, q los obtáculos a la visión se vuelvan intangibles/tranparentes/translúcidos... debe ser imposible, pq los hideputas no lo hacen nunca y te vuelven loco con un punto de vista q se menea más q una puta batidora, sobretodo en los lugares estrechos, y haciendo que tu propio personaje te tape á lo que está apuntando... :shit:
    Dedicado al Fornite y muchos otros con todo el odio cariño... :-D
  48. #45 Sí, es un mal necesario la mayoría de veces en empresas medianas y pequeñas. Quizás se utiliza demasiado en proyectos en los que realmente no hacen falta (por ejemplo, plataformas 2d offline, ¿para qué?) porque el equipo sabe usar una herramienta y la usan para todo tipo de proyectos.

    La diferencia con un framework en desarrollo "convencional" es que el motor es mucho más "intrusivo". Como dice el compañero, capturar eventos de.sonido puede ser complicado porque quizás el motor lanza sonidos cuando decide romper algo automáticamente y a ti jamás se.te ha ocurrido.capturar ese evento. No sé cómo explicarlo,
    el motor "es el todo" y el código son generalmente scripts que se pueden meten dentro de objetos o soltar por ahí y haces que la lectura sea complicada y el mantenimiento sea aún peor.

    Un framework es un conjunto de ayudas. El motor es un ecosistema donde organizar sólo una parte es complicado.
  49. #11 Creo que #3 se refiere a algo como esto que explican aquí sobre el acceso a usuarios y grupos (con Firebase).

    firebase.google.com/docs/database/web/structure-data?hl=es#fanout
  50. #17 Eso ni es dinámica de fluidos ni es nada. Es una curiosidad imitando los detalles que tenía el MGS2.
  51. #46 Como máximo, el doble.
  52. #51 Puede ser, yo soy de más bajo nivel. Las BBDD son de muy alto nivel para mi.
  53. #53 Suponiendo que lo único que guardes de un usuario sea sus relaciones (entonces quizá sea mejor utilizar otro tipo de estructura de datos, por cierto).
    No sé, si es importante poder consultar esa relación en una base de datos no relacional la solución está clara, no es que sea un caso de uso extremo que no haya necesitado nadie :-)
    Y.. ¿en qué videojuego los datos de los usuarios son una parte significativa de los recursos utilizados? ¿es un tetris multijugador o algo así?
  54. #53 Eso puede ser un buen pico.
    Tu dile a google que doble capacidad.
  55. Como llevo años haciendo videojuegos y con una empresa con varios trabajadores os voy a decir el secreto y lo único difícil de hacer videojuegos.
    Hacerlo divertido!
    Ni gráficos, ni sonidos, ni programación (como he leído por ahí que si dependes de blablablbala) todo importa una mierda. Lo único que importa ea que le presentes al jugador un reto divertido. Punto.
  56. #57 Esa creo que es una gran verdad.
    Incluso en muchos casos la simpleza es mejor que la complejidad: menos gráficos recargados, menos artificio de sonidos, menos florituras de programación...

    Creo que lo mejor sería: "fácil de empezar a jugar, pero difícil dejarlo".

    * Fácil empezar :
    + Reglas sencillas, mejor si es tan intuitivo que se entiende en un vistazo.
    + Interfaz de usuario sencilla... táctil o pocos controles (ej: izquierda, derecha).
    + Versión gratuita o similares, para que no haya muchas barreras para probarlo.
    (también permite desencadenar un crecimiento exponencial del número de jugadores)
    + Disponible en la mayor cantidad de plataformas... hoy en día en móviles.
    + Mejor si tiene colores vistosos y temática simpática, que anime a probarlo.
    + Mejor si incluye emociones o sensaciones : alegría, risa, ternura, algún susto/miedo, comida...

    * Difícil dejarlo :
    + Aunque es sencillo comprender el objetivo, lograrlo cuesta mucho, o que no haya un "final".
    + Que sea adictivo (en parte como una droga).
    + Puede mantener cierta intriga, quizá con sorpresas...
    + Muchas veces el interés viene de una explosión combinatoria. Pese a que las piezas / elementos sean simples y pocos, las formas de combinarlos o de actuar son millones, haciendo que cada partida sea única y no aburra.

    Ejemplos:
    Pacman.
    + Tan simple como comer todo. Comer es algo que hace todo el mundo, todos los días.
    + Pocos controles: izquierda, derecha, arriba y abajo.
    + Colores primarios.
    + El recuerdo sensorial de comer cosas, unido a la emoción de miedo a los fantasmas.
    + Adictivo porque crees que podrás lograrlo o llegar más lejos y quieres intentarlo otra vez.

    Tetris.
    + Tan simple como piezas que caen. Pocas piezas, formas sencillas.
    + Izquierda, derecha y rotar (más bajar pieza)
    + Colores primarios.
    + Temática simpática: rusos bailando, musiquita, etc.
    + Adictivo porque quieres intentarlo otra vez o competir con otro.
    + Intriga porque no sabes que pieza saldrá (solo sabes la siguiente).

    Mario Bros
    + Tan simple como avanzar hacia la derecha, recorrer un camino superando obstáculos.
    + Controles: derecha, izquierda y saltar.
    + Un mundo de color
    + Temática simpática: héroe icónico medio chistoso / antihéroe, princesa, animales, ...
    + Engancha lo fácil que parece y lo difícil que es conseguirlo, unido a sorpresas.

    Bueno, esos ejemplos son de otra época.…   » ver todo el comentario
  57. #6 tener que hacer un marketing brutal de tu juego para no hundirse entre la marea de basura que sale a diario.
comentarios cerrados

menéame