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
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.
Saquen ya las sextas partes de GTA y Elder Scroll o matamos a un rehén cada hora.
La parte de "terminar" un juego se lleva el 90% del tiempo de desarrollo.
Todo esto sin tener en cuenta el marketing, claro.
youtu.be/uspPDqaLlnU
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.
www.youtube.com/watch?v=g0et8bWoEJk
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.
www.meneame.net/story/tan-dificil-hacer-bien-puertas-videojuegos-eng
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).
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.
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.
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.
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.
¿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?
¿Que cuando ahora alguien te dice que sabe programar es muy probable que solo sepa unir cajitas màgicas?
#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.
en post de la eficienciaen pos de la eficienciaYo 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.
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.
Ni con millones de usuarios va a ocupar mucho
Dedicado al Fornite y muchos otros con todo el
odiocariño...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.
firebase.google.com/docs/database/web/structure-data?hl=es#fanout
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í?
Tu dile a google que doble capacidad.
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.
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