Hace 2 años | Por JanSmite a ign.com
Publicado hace 2 años por JanSmite a ign.com

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.

Comentarios

Doisneau

#13 No vengas con tu logica proposicional a estropear sus lloros

ccguy

#1 Es un poco obvio pero ¿has pensado en tener la lista de los que te tienen de amigo en tu propio registro?

LeDYoM

#3 Estupendo, el registro de cada jugador va a ocupar lo que no está escrito.

e

#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.

h

#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.

ccguy

#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

vayavaya

#46 Como máximo, el doble.

ccguy

#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í?

LeDYoM

#53 Eso puede ser un buen pico.
Tu dile a google que doble capacidad.

n

#11 Creo que #3 se refiere a algo como esto que explican aquí sobre el acceso a usuarios y grupos (con Firebase).

https://firebase.google.com/docs/database/web/structure-data?hl=es#fanout

LeDYoM

#51 Puede ser, yo soy de más bajo nivel. Las BBDD son de muy alto nivel para mi.

llorencs

#1 Y meterlo en una relacional?

D

#14 El problema de las relacionales imagino que será el rendimiento..., pero que mejor que nos lo cuente él.

cosmonauta

#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.

llorencs

#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.

cosmonauta

#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.

m

#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.

D

#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.

m

#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é.

D

#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.

llorencs

#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.

D

#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.

#24 en post de la eficiencia en pos de la eficiencia

D

Lloricas

Doisneau

#c-19" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3554967/order/19">#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).

D

#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.

Doisneau

#31 Gracias por tu respuesta, un saludo

NapalMe

#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?

D

#39 No, no lo he dicho

Acido

#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.
Pero más recientes:

Candy Crush
+ Tan simple como eliminar elementos agrupados.
+ Control táctil sencillo.
+ Colores primarios.
+ Temática simpática: caramelos, niños, ...
+ Une el recuerdo del sabor de los caramelos, cierta nostalgia, alegría, sorpresa...
Frases alegres y efectos de sonido.
+ También la interacción con amigos hace que enganche más.
+ Intriga porque no sabes los colores que caerán, elementos sorpresa, jugadas que no esperabas...
Además hay cientos de pantallas, vas descubriendo nuevos retos, más difíciles.

Otros ejemplos:
Among Us (intriga, risas, etc)
Pokemon Go (conexión emocional con una serie de dibujos muy popular, y criaturas tiernas)

Es cierto que muchos videojuegos exitosos actuales son complejos.
Pero pese a las florituras de gráficos que hoy sí permiten las máquinas actuales (aunque requiere mucho dinero y trabajo hacerlo y mantenerlo), sin embargo, la dinámica principal del juego es sencilla. Por ejemplo, tan simple como sobrevivir (matar y que no te maten) en dinámicas tipo Battle Royale o similares (PUBG, Fortnite...).
Y, sí, al final lo que hace que sean exitosos es que son divertidos. Todas las florituras, que muchas veces dan problemas como necesitar un gran presupuesto o requerir máquinas más potentes, si tienen sentido es porque aportan diversión / sorpresa / risa / ternura / personalidad... no aburrirse, ganas de jugar más.
En películas pasa algo similar: algunas tienen mucho presupuesto y muchos efectos especiales pero son aburridas o con mal guión que no interesa o no engancha... mientras otras pelis de bajo presupuesto pueden triunfar porque conectan con mucha gente: risas, o terror, o intriga, etc... historias interesantes, personajes emotivos, frases / situaciones memorables, etc.

Si un desarrollador individual o compañía pequeña no puede aspirar a juegos con mucha parafernalia, entonces para divertir creo que debería basarse en los puntos que dije. Y muchas veces nuevas compañías acaban siendo gigantes a pesar de competir con otras que eran grandísimas.
Pero supongo que es difícil dar con algo original y que sea divertido, y que al mismo tiempo triunfe, que se haga popular. Habrá muchos juegos que siendo sencillos, divertidos, gratuitos, coloridos/atractivos, con capacidad para enganchar, etc... no acaben cuajando, quizá por no tener suerte, o no tener buenos contactos que sepan promocionarlo, o porque ese tipo de juego no esté de moda, etc.
Importa que entretenga / que emocione... aunque puede ser muy difícil conseguirlo.
Difícil no por complicaciones técnicas, sino porque es difícil saber lo que se pondrá de moda.
Hay pocas fórmulas con muchas garantías de éxito: cosas como el fútbol, temáticas de personajes de dibujos que ya son muy populares, o videojuegos impulsados por éxitos previos como los de Nintendo. Estos suelen estar copados por grandes compañías y que requieren grandes inversiones o acuerdos por derechos de imagen, etc.

#18 un héroe de los videojuegos

D

#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...

neiviMuubs

#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...

Or3

#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.

Ivan_Alvarez

#10 dinamica de fluidos ya habia en 2002 en el splinter cell. Aunque es verdad que poco se utiliza actualmente:

Ehorus

#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

Or3

#17 Eso ni es dinámica de fluidos ni es nada. Es una curiosidad imitando los detalles que tenía el MGS2.

t

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.

cosmonauta

#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 ..

NapalMe

Los motores de terceros está volviendo tonta la gente.

D

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.

A

#15 calla calla, que últimamente llevo una vida equilibrada y como aparezca de nuevo por Skirym se irá todo a cascarla

astronauta_rimador

A trabajar ostias! Que lo queréis todo bien facilito.

D

Mucho más sencillo desde que hay motores y una infinidad de herramientas.

D

#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.

D

#4 ¿Qué problemas nuevos?

Cidwel

#6 el raytracing no es tan automático como debería ser

C

#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.

NapalMe

#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?

Boleteria

#6 tener que hacer un marketing brutal de tu juego para no hundirse entre la marea de basura que sale a diario.

NinjaBoig

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...
Dedicado al Fornite y muchos otros con todo el odio cariño...

D

Al final vais a acabar aceptando que programar es una mierda

Y no os faltará razón...