Novedades
Ciudadano Estelar | Tu comunidad de Star Citizen en Español

¡Bienvenido! ¿A que esperas para formar parte de la comunidad hispana de Star Citizen con más años de historia? Únete hoy mismo, ¡Es gratis!

El Server Meshing y la copia única del 'verso

Lee bien lo que he puesto sobre comparar. Cry Engine pierde cuantitativa, y cualitativamente.

¿Tú no has visto de lo que es capaz Cryengine V hoy día, no? En calidad desde luego no pierde. Que Unreal sea más usado es por otras cuestiones que vienen de tiempo.

Predicador said:
Si Cry Engine necesita más tiempo, trabajo y dinero para hacer lo mismo, o menos, es peor para mi.

La clave es que nada es blanco o negro, a día de hoy no necesitas ni más tiempo, ni trabajo, ni dinero para desarrollar en Cryengine, eso no depende del motor, depende primero de tu proyecto y depende de tu personal, del que tengas o puedas conseguir, y que precisamente lo más difícil es encontrar a gente cualificada, no un motor de calidad. Y eso quiere decir que aunque sepan de Unreal pueden no saber de muchas otras cosas, pueden ser unos patatas con Cpp por ejemplo que es el lenguaje que usa tanto Cryengine como Unreal, saber manejar el motor gráfico no es lo único importante y además entra también en juego el talento y las ganas que le echen.

Pero hablando de talento yo me quedaría con que CIG cuenta con los ingenieros orignales del motor que usan, Cryengine. Y ese es un gran punto a su favor, una ventaja que no habrían tenido con ningún otro motor. Eso sí acelera las cosas, no hay mayores expertos.

En Cryengine V se solventaron muchos problemas igual que Epic solventó los problemas de UDK con el paso a Unreal 4.
Lo mismo ha hecho Amazon con Lumberyard al paso con O3DE y también CIG con "Star Engine". Los motores son cosa de un desarrollo continuo... y con tiempo hasta Godot se está convirtiendo en un motor pepino AAA.

Y claro, te preguntas en qué se basa una empresa para elegir motor... pues será mejor o peor según tus necesidades, si varios motores son adecuados para sus necesidades entonces tienes que empezar a valorar otras cosas, como el soporte, el contrato que te puedan ofrecer o la formación de tus trabajadores. Por ejemplo Ninja Theory se decantó por Unreal para Senua porque les ofrecieron un contrato de soporte muy suculento con el que Epic promocionaría el motor. Algo parecido a lo que pasó con los Gears of War tiempo atrás.

Pero al final depende del proyecto que tengas entre manos, si vas a tener que modificar todo el motor como fue el caso de CIG al final te da igual qué motor coger si vas a tener que cambiarlo todo, ¿se entiende, no?

Preguntabas atrás el porqué se usa más Unreal que Cryengine. Y es muy fácil.
- Se usa más Unreal que Cryengine porque desde 2005 a 2015 aprox era el único motor público AAA, por lo tanto hasta que Unity no le pasó la mano por la cara o hasta que Cryengine se hizo también público Unreal no tuvo competencia y todo ese tiempo los desarrolladores sólo sabían manejarse en ese motor (aunque Cryengine fuese más potente).
- Luego apareció Unity, y Unity es el motor más utilizado de aquí a Lima porque usa tecnología muy friendly, como C# que es un lenguaje fácil de aprender y manejar, ahí lo bueno no es que entonces Unity sea fácil de usar, sino que hay mucha gente que sabe usarlo por sólo saber ese lenguaje. Aun así apenas se usa para juegos AAA, pero créete a la prensa y a la gente que no tiene ni idea, creete a los que piensan que Unity sólo sirve para juegos Indie y que en realidad tiene la misma capacidad que Unreal o Cryengine  :)

Nota curiosa, Nintendo está usando una rama de Unreal para algunos de sus juegos hasta donde yo sé y los de Genshin Impact han hecho en 4 años con Unity lo que a Nintendo le llevó 5 con BOTW aun subcontratando como a 6 empresas. ¿Es mejor Unity? ni sí ni no, ni blanco ni negro, pero Nintento no es muy buena con las nuevas tecnologías, nunca lo ha sido y siempre se ha tenido que apoyar en otras empresas, mientras que los chinos de Genshin tienen vasta experiencia con Unity.
Nintendo habría estado en las mismas usaran el motor que usaran, pero los de Mihoyo serían tontos si cambiasen a día de hoy de motor ¿se va pillando la lógica?

Pero en fin, año 2012, UDK 3 era cáncer (estaba muy anticuado, era tosco) al lado de Cryengine, ni siquiera en 2014 con Unreal 4 aun estaban al nivel, vuelvo a sacar Ryse: Son of Rome, mírate si quieres su making of, es flipante su tecnología en 2013, y por ejemplo Cryengine usaba PBR desde varios años atrás.

Por su lado mientras tanto CIG por sus necesidades ha desarrollado herramientas que no tiene Unreal, así como Unreal 5 tiene herramientas que no tiene el "Star Engine". Como dije, esto es un proceso continuo, los motores ni son mejores ni peores de por sí, eso depende de tus necesidades y capacidades y cada motor ha evolucionado por su camino paralelo.

Y tampoco puedes pensar en como es hoy día Unreal u otro motor, porque cuando empiezas a desarrollar un juego ya no lo actualizas si no es que son modificaciones propias. ¿por qué?, igual es algo técnico pero nada te garantiza que los cambios que traiga ese motor te rompa el juego, sin embargo sí puedes fiarte de tus propias modificaciones. Ya sin mencionar que las nuevas actualizaciones les da igual porque nadie sabe manejar lo nuevo que traiga el motor por precisamente ser nuevo.

Así que olvídate de como es Unreal hoy día, y qué hubiera pasado si lo hubieran elegido, piensa en como era en 2014-2015, más allá de esa fecha nunca lo habrían actualizado con los updates oficiales, lo habrían modificando igual que Cryengine.

Bueno...  espero que te sirva de algo, no son temas técnicos, son fechas, y cómo y porque el mercado se ha movido por donde se ha movido  + algo de historia. Pero quédate con esto, que nada es blanco ni negro, no hay "el mejor motor" y aun así con la contratación del personal de Cryengine por parte de CIG sí creo que han tenido una gran suerte y fue muy acertada la elección de Cryengine, no por el motor, sino por el personal.
 
Hunk_Stalker said:
¿Tú no has visto de lo que es capaz Cryengine V hoy día, no? En calidad desde luego no pierde. Que Unreal sea más usado es por otras cuestiones que vienen de tiempo.

El Star Engine no se corresponde con el 5.

Esas otras cuestiones no seran buenas razones?

Hunk_Stalker said:
lo más difícil es encontrar a gente cualificada, no un motor de calidad. Y eso quiere decir que aunque sepan de Unreal pueden no saber de muchas otras cosas, pueden ser unos patatas con Cpp por ejemplo que es el lenguaje que usa tanto Cryengine como Unreal, saber manejar el motor gráfico no es lo único importante y además entra también en juego el talento y las ganas que le echen.

Eso yo lo comenté antes. Es un punto importante para precisamente no optar por Cryengine, si hay pocos desarrolladores de alto nivel, que lo usen, hay menos personal cualificado disponible.

Hunk_Stalker said:
Pero hablando de talento yo me
- Se usa más Unreal que Cryengine porque desde 2005 a 2015 aprox era el único motor público AAA, por lo tanto hasta que Unity no le pasó la mano por la cara o hasta que Cryengine se hizo también público Unreal no tuvo competencia y todo ese tiempo los desarrolladores sólo sabían manejarse en ese motor (aunque Cryengine fuese más potente).
- Luego apareció Unity, y Unity es el motor más utilizado de aquí a Lima porque usa tecnología muy friendly, como C# que es un lenguaje fácil de aprender y manejar, ahí lo bueno no es que entonces Unity sea fácil de usar, sino que hay mucha gente que sabe usarlo por sólo saber ese lenguaje. Aun así apenas se usa para juegos AAA, pero créete a la prensa y a la gente que no tiene ni idea, creete a los que piensan que Unity sólo sirve para juegos Indie y que en realidad tiene la misma capacidad que Unreal o Cryengine  :)

Pero si la mayoría de los equipos dominan Unreal ya, no les sirve de nada a ellos cambiar a Unity y sobre todo, como todos están igual, no van a encontrar nuevos trabajadores especializados suficientes cuando hagan falta. Lo cual tiene toda la lógica del mundo esa inercia. Otra cosa es que alguien que domine Unity forme equipos nuevos para nuevos proyectos de nuevos indies apoyados por una gran empresa. Tu dales tiempo. El dinero es muy cobarde y si algo funciona no se va a cambiar, hasta que haya manera más fácil de hacer más dinero.

Hunk_Stalker said:
Nota curiosa, Nintendo está usando una rama de Unreal para algunos de sus juegos hasta donde yo sé y los de Genshin Impact han hecho en 4 años con Unity lo que a Nintendo le llevó 5 con BOTW aun subcontratando como a 6 empresas. ¿Es mejor Unity? ni sí ni no, ni blanco ni negro, pero Nintento no es muy buena con las nuevas tecnologías, nunca lo ha sido y siempre se ha tenido que apoyar en otras empresas, mientras que los chinos de Genshin tienen vasta experiencia con Unity.
Nintendo habría estado en las mismas usaran el motor que usaran, pero los de Mihoyo serían tontos si cambiasen a día de hoy de motor ¿se va pillando la lógica?

Son chinos, el crunch es su día a día normal, y Nintendo lo que es Nintendo su política es contraria al crunch. No viven a la misma velocidad. Nintendo es una compañía japonesa de provincias, muy conservadora, y a veces es algo bueno. Otra cosa son las compañías que no son realmente Nintendo aunque Nintendo participe. Además, Genshin se ahorró mucho trabajo, porque es una copia de zbotw. El mérito de Nintendo es arriesgarse e innovar, y a veces le sale mal, pero ahí siguen, toda mi maldita vida. Curiosamente siendo tan conservadores.

De china están presentándose juegazos, pero no es tanto por tecnología, sino por como funciona laboralmente. Se van a comer el mundo en esta década.


Hunk_Stalker said:
Pero en fin, año 2012, UDK 3 era cáncer (estaba muy anticuado, era tosco) al lado de Cryengine, ni siquiera en 2014 con Unreal 4 aun estaban al nivel, vuelvo a sacar Ryse: Son of Rome, mírate si quieres su making of, es flipante su tecnología en 2013, y por ejemplo Cryengine usaba PBR desde varios años atrás.

En 2014 Crytec estaba en un estado ruinoso, era público. Curva descendente. Habría señales en los años anteriores, Rise of Rome no tuvo mucho éxito, maravillosos gráficos, pobre jugabilidad (nos suena?). Solo por esa incertidumbre yo no hubiera invertido un ochavo en ellos.

Hunk_Stalker said:
Por su lado mientras tanto CIG por sus necesidades ha desarrollado herramientas que no tiene Unreal, así como Unreal 5 tiene herramientas que no tiene el "Star Engine". Como dije, esto es un proceso continuo, los motores ni son mejores ni peores de por sí, eso depende de tus necesidades y capacidades y cada motor ha evolucionado por su camino paralelo.

La pregunta, cuanto funcionan de verdad las herramientas que en CIG han desarrollado o siguen estando trabajando en ellas? (la de incendios en la nave la veo en sus videos desde como hace 4 años, la de creación rápida de planetas parece seguir siendo humo). Y no quiero hacer demérito de los desarrolladores de CIG, sino de la elección de los objetivos. Tu puedes poner la mano en el fuego que otro equipo de buenos profesionales con otro motor no lo hubiera hecho mejor y más rápido, con Unreal? No creo que tantas grandes y pequeñas empresas estén haciendo el idiota prefiriendo el unreal (o el unity) al cry engine. Es más para tu alivio te diré, más que el motor, para mi el problema principal de este desarrollo, es CR. Si un inversor externo le dejara en segundo plano, da igual el motor, el juego recibiría un buen empujón.

Hunk_Stalker said:
Y tampoco puedes pensar en como es hoy día Unreal u otro motor, porque cuando empiezas a desarrollar un juego ya no lo actualizas si no es que son modificaciones propias. ¿por qué?, igual es algo técnico pero nada te garantiza que los cambios que traiga ese motor te rompa el juego, sin embargo sí puedes fiarte de tus propias modificaciones. Ya sin mencionar que las nuevas actualizaciones les da igual porque nadie sabe manejar lo nuevo que traiga el motor por precisamente ser nuevo.

Así que olvídate de como es Unreal hoy día, y qué hubiera pasado si lo hubieran elegido, piensa en como era en 2014-2015, más allá de esa fecha nunca lo habrían actualizado con los updates oficiales, lo habrían modificando igual que Cryengine.

Claro, eso está claro. El tema es, cuann bien funcionaría el resultado en cada caso, tiempo y horas trabajo= dinero que supondría.

Hunk_Stalker said:
Bueno...  espero que te sirva de algo, no son temas técnicos, son fechas, y cómo y porque el mercado se ha movido por donde se ha movido  + algo de historia. Pero quédate con esto, que nada es blanco ni negro, no hay "el mejor motor" y aun así con la contratación del personal de Cryengine por parte de CIG sí creo que han tenido una gran suerte y fue muy acertada la elección de Cryengine, no por el motor, sino por el personal.

Es que si CR no tiene esa suerte, este proyecto hubiera muerto o hubiera cambiado de motor, eso está claro. Lo cual sigo pensando, que puede que hubiera sido lo mejor. Sin juicio, con mayores facilidades de conseguir trabajadores, etc. Te hablo de 2014, cuando CIG solo tenía "humo".

Pero gracias por tu tiempo siempre, en cualquier caso
 
Predicador said:
Eso yo lo comenté antes. Es un punto importante para precisamente no optar por Cryengine, si hay pocos desarrolladores de alto nivel, que lo usen, hay menos personal cualificado disponible.

De hecho suele pasar lo contrario con Unreal, la inmensa mayoria de devs que se dedica a tocar el motor no son especializados porque lo usan por pura fama que tiene de tiempo atrás o porque se dejan atraer por el márketing y vídeos bonitos, pero no tienen CV, pocos lo dominan. Lo mismo pasa con Unity, es el más usado con muchísima diferencia, pero la inmensa mayoría son todo programadores amateur o ni eso, simplemente gente que se dedica a hacer juegos sacados de tutoriales. Por eso no es tan frecuente ver juegos AAA y se asocia a Unity con juegos amateur o Indie.

O sea, por un lado está la calidad de los motores que es similar en todos los casos.-
Por otro la cantidad de desarrolladores, y que sean muchos no quiere decir que sean mejores, y ahí el ejemplo de Unity, que gana por goleada en cantidad de desarrolladores pero ni de lejos tiene la mayor cantidad de expertos, y Epic quiso tirar por ese camino para hacer competencia, atrayendo a usuarios a toda costa, y ahora explico esto...

En el caso de Unreal la situación es algo más desgraciada porque Epic promociona lo que son los blueprints, que es un sistema para hacer videojuegos sin necesidad de programar pero que en realidad es basura XD Algo parecido a Scratch, por lo que muchos de los que usan Unreal ni siquiera saben programar, así que andan por el nivel de los de Unity o peor. Insisto en que esa basura la promociona Epic así que la gran mayoría de desarrolladores de Unreal ni siquiera saben programar. Una lástima, porque considero Cpp un lenguaje de puta madre, a mi me encanta es mi preferido.

¿Que Cryengine tiene a menos cantidad de desarrolladores y menos expertos? seguro, pero CIG tiene a los mayores expertos en Cryengine y más que nadie.

El Star Engine no se corresponde con el 5.

Yo es que no te estoy diciendo que Star Engine corresponda a Cryengine V (no es 5), corresponde al 3.7. Te estoy diciendo que Cryengine V está al nivel de Unreal 5. Y lo digo porque afirmas que Cryengine pierde en calidad frente a Unreal, eso es falso, ambos motores disponen de todo tipo de las tecnologías más modernas. Siendo que Unreal dispone de algunas herramientas que no tiene el otro y un mejor motor de iluminación en su versión 5 y Cryengine en su línea con un mejor renderizador más rápido y mejores resultados (por eso los graficazos y esa vegetación tan realista que es de lo que más cuesta) y motor de físicas más potente (por eso se usa en simuladores militares).

Unreal, CryEngine o Unity, todos soportan software de terceros punteros como Houdini para FX, Substance para creación de shaders procedimentales o SpeedTree para vegetación. Fíjate que ninguno incluye estas cosas de serie, sino que son compatibles con idénticas tecnologías externas, por lo tanto casi idénticos resultados.
 
Hunk_Stalker said:
Predicador said:
Eso yo lo comenté antes. Es un punto importante para precisamente no optar por Cryengine, si hay pocos desarrolladores de alto nivel, que lo usen, hay menos personal cualificado disponible.

De hecho suele pasar lo contrario con Unreal, la inmensa mayoria de devs que se dedica a tocar el motor no son especializados porque lo usan por pura fama que tiene de tiempo atrás o porque se dejan atraer por el márketing y vídeos bonitos, pero no tienen CV, pocos lo dominan. Lo mismo pasa con Unity, es el más usado con muchísima diferencia, pero la inmensa mayoría son todo programadores amateur o ni eso, simplemente gente que se dedica a hacer juegos sacados de tutoriales. Por eso no es tan frecuente ver juegos AAA y se asocia a Unity con juegos amateur o Indie.

O sea, por un lado está la calidad de los motores que es similar en todos los casos.-
Por otro la cantidad de desarrolladores, y que sean muchos no quiere decir que sean mejores, y ahí el ejemplo de Unity, que gana por goleada en cantidad de desarrolladores pero ni de lejos tiene la mayor cantidad de expertos, y Epic quiso tirar por ese camino para hacer competencia, atrayendo a usuarios a toda costa, y ahora explico esto...

En el caso de Unreal la situación es algo más desgraciada porque Epic promociona lo que son los blueprints, que es un sistema para hacer videojuegos sin necesidad de programar pero que en realidad es basura XD Algo parecido a Scratch, por lo que muchos de los que usan Unreal ni siquiera saben programar, así que andan por el nivel de los de Unity o peor. Insisto en que esa basura la promociona Epic así que la gran mayoría de desarrolladores de Unreal ni siquiera saben programar. Una lástima, porque considero Cpp un lenguaje de puta madre, a mi me encanta es mi preferido.

¿Que Cryengine tiene a menos cantidad de desarrolladores y menos expertos? seguro, pero CIG tiene a los mayores expertos en Cryengine y más que nadie.

No creo que sepas cuantos de los que entraron continúan trabajando en CIG, yo tampoco por supuesto. Son ya 7 años, tu sabrá la volatilidad laboral que hay en ese mundillo en nuestros vecinos del norte. Súmale mantener el juego post lanzamiento 10 años. No parece una buena idea depender hasta ese punto de unos pocos trabajadores insustituibles. Eso no ocurriría con Unreal o Unity.

No sabran programar, pero sacan juegos adelante. Quizás porque como en CIG, programadores son el quesito pequeño de la plantilla? mira el gráfico que postee sobre datos tomados de linkedin que hizo alguien, que postee en este foro. Seguro que hay gente suficiente, ni más ni menos, muy capaz, y que sabe jugar muy bien con tanto proyecto en marcha con este motor.

Hunk_Stalker said:
El Star Engine no se corresponde con el 5.

Yo es que no te estoy diciendo que Star Engine corresponda a Cryengine V (no es 5), corresponde al 3.7. Te estoy diciendo que Cryengine V está al nivel de Unreal 5. Y lo digo porque afirmas que Cryengine pierde en calidad frente a Unreal, eso es falso, ambos motores disponen de todo tipo de las tecnologías más modernas. Siendo que Unreal dispone de algunas herramientas que no tiene el otro y un mejor motor de iluminación en su versión 5 y Cryengine en su línea con un mejor renderizador más rápido y mejores resultados (por eso los graficazos y esa vegetación tan realista que es de lo que más cuesta) y motor de físicas más potente (por eso se usa en simuladores militares).

Estábamos comparando las listas de juegos que usan ambos motores, la lista de juegos, y te dije que había que comparar cuantitativamente, pero también cualitativamente, y ahí Cry Engine perdía (en ambos casos, pero tuve que repetirlo para corregirte al comparar Unity con Unreal, que solo lo hiciste cuantitativamente). La lista de juegos.

Es irrelevante la calidad de Cry Engine V por partida doble, primero porque  no es la versión base de Star Engine, y segundo porque no hay una mesnada de desarrolladores hambrientos por usarlo que podamos comprobar a corto plazo de si se verá mejor en Cry o en Unreal. Y de todas maneras, es que esa no era la discusión, sino la utilidad, la lista de juegos.
 
Hunk_Stalker said:
Bueno yo ya te he respondido a todo aunque no te valga de nada XD

Te agradezco la respuesta, en cualquier caso  :)

Lo de los blueprints ha sido muy interesante. Te das cuenta que es útil para crear cantera? Mucha gente comienza crear jueguitos, la mayoría lo terminan dejando y se estancan, unos pocos deciden profundizar y entran en la industria. Aún así esos pocos de una "promoción", serán más que todos los devs de cry engine juntos. Circulo vicioso (pocos juegos y pocos devs, aprendizaje dificil, acceso dificil, se retroalimenta para mal, lo sostiene una compañía en perpetua "crisis") vs círculo virtuoso (muchos juegos, facilidades para comenzar a usarlo, gratuidad, se retroalimenta para bien, lo mantiene una compañía en su verano).

Edito: Por volver al tema principal:


71j6hmii22t71.jpg


Así en conjunto y sobre todo el último post, deja claro que del global shard mejor olvidarse. Esto va a ser muy bueno para jugar el PU, y desatascar el desarrollo, excelente noticia.
 
1- Twitter: Hilo de un ex-dev de Amazon, con respuestas a puñados https://twitter.com/cubesos/status/1453756798025011206?t=lgFmUjfrdaHVi6FK7_oRQA&s=19

"Jorge Rodriguez 🇨🇺
@cubesos
Story time about the history of New World’s networking architecture.

Some time before I joined Amazon in 2016, Amazon Games “bought” CryEngine. They then built two competing internal engines on top of it, one that would become Lumberyard, and one that the games teams used. https://twitter.com/landongn/statu"


Selección:

"The reason for the two forks is that Lumberyard was replacing basically all of CryEngine (which was terrible) with new code, but the games teams needed to get to work building games, so Crucible, New World, and Breakaway used some existing code that Double Helix had."

"GameCore’s networking was a trash fire. I swam around in it once to try to fix a bug, and I don’t remember any specifics but I do remember thinking that just about everything they did was the most complex way they could have done it."

"Not only was it server authoritative but it could support shafted servers, where each server would be responsible for a given geographic area but could still tell its clients about entities in other servers/areas. They did this because they had a very large world."

"Anyway they were canceled, but they had built some pretty cool tech, and so some people on Nova went off in search of another team to adopt their code. Crucible was having a lot of problems with GameCore and it’s client authoritative model, so they adopted Nova’s code."

"Crucible spent about a year and a half rebuilding the entire game under NovaNet. Artists worked on another branch the whole time and designers had basically nothing to do for a year."

"New World was faced with the decision of whether to move to NovaNet. I wasn’t on New World so I don’t know the details but I don’t really blame them that they decided not to share Crucible’s pain."


"New World had already rebuilt their game from scratch once (it was originally less an MMO and more Rust-like) and by all rights Crucible should have been canceled rather than rebuilt. I mean, before it was actually canceled lol"

"When faced with a choice between spending millions delaying the game for another year or two vs accepting client authoritative bugs, it’s easy to say “ok let’s just be very careful!”"

"The root cause (my personal view) is that when AGS was new leadership, who had little experience in games, had no experience of the risks of choosing bad tech to build games off of and didn’t get their technology or listen to warnings of seniors and principals."

"So anyway the answer to “how does a multi billion dollar company making games in 2021 write client authoritative code” is “Game development: it’s very complicated.” Please be kind to and patient with the New World team, they’ve been trying to fix this problem for like 8 years." (hay tweets sobre este tema).




Prensa:

2- Amazon Can Make Just About Anything—Except a Good Video Game

https://www.bloomberg.com/news/features/2021-01-29/amazon-game-studios-struggles-to-find-a-hit

"Frazzini was more fixated on another project anyway. Amazon’s designers and programmers needed a game engine, a collection of tools used to build games. For most studios, there are really only two options. Epic’s Unreal Engine is Coke, and Unity Software Inc. is Pepsi. Amazon, in effect, decided to make an RC Cola. In 2014, it licensed technology from the German company Crytek for a homemade engine called Lumberyard. Frazzini then assigned a team of engineers to build the engine and released it to the public in 2016 for free. The tools are intertwined with Amazon Web Services, setting up Lumberyard as a way to draw a new class of software developers to the business. Frazzini, who reports to Web Services Chief Andy Jassy, also mandated that all Amazon games be built with Lumberyard, rather than pay for Unreal or Unity.

Lumberyard became a bogeyman around the office. Some features required esoteric commands to function, and the system was painfully slow. Developers played Halo or watched Amazon Prime Video while waiting for Lumberyard to process art or compile code, several former employees say. A common refrain around the office, according to a former employee: “Lumberyard is killing this company."

From the outside, though, Amazon’s game operation was scaring competitors. It had some of the world’s brightest minds, a deep budget and the most sophisticated internet infrastructure on earth. It was building a proprietary engine, and at TwitchCon in 2016, Amazon said it was working on three new games: Breakaway, Crucible and New World. (Nova, the League of Legends copycat, was still under lock and key.) Over the coming years, all but one would be canceled."


 
Adamanter, que no se te atragante esto, es oficial, Q&A del Server Meshing.

"If I make a base on a moon, will my base be reflected on the other shards that I am not on?

The Planet Tech team plans to implement base building with server shards in mind. Claiming land for your base will claim this land on all shards, and we plan to replicate your base to all shards.

However, only one shard will have an ‘active’ version of the base, with other shards spawning a ‘limited access/read only’ version of that same base. For example, a base will give full access and the ability to expand in the shard the owner currently plays on, while on all other shards, this base may spawn with locked doors in an immutable state. The full design is not 100% established yet and may change though."


QED.
 
Predicador said:
Adamanter, que no se te atragante esto, es oficial, Q&A del Server Meshing.

"If I make a base on a moon, will my base be reflected on the other shards that I am not on?

The Planet Tech team plans to implement base building with server shards in mind. Claiming land for your base will claim this land on all shards, and we plan to replicate your base to all shards.

However, only one shard will have an ‘active’ version of the base, with other shards spawning a ‘limited access/read only’ version of that same base. For example, a base will give full access and the ability to expand in the shard the owner currently plays on, while on all other shards, this base may spawn with locked doors in an immutable state. The full design is not 100% established yet and may change though."


QED.

¿Quieren decir que podré bombardear una base "inactiva" en mi "fragmento del servidor" y las bombas no le harán nada? Entiendo la parte de que la base esté cerrada y apagada, como si no hubiera nadie en casa, pero mis torpedos son unos maleducados y no llaman al timbre... o en todo caso llaman y se van corriendo xD
 
He leido que preveen que sea necesario implementar mecánicas para evitar que haya demasiados jugadores en un único sitio, como que los puntos de salto se vuelvan intransitables si hay demasiada gente en el lugar de destino, y me he empezado a reir solo
 
Vendaval said:
He leido que preveen que sea necesario implementar mecánicas para evitar que haya demasiados jugadores en un único sitio, como que los puntos de salto se vuelvan intransitables si hay demasiada gente en el lugar de destino, y me he empezado a reir solo

O que las naves capitales tengan su propio servidor, lo cual me parece muy práctico, desde muy ignorancia. Yo les aplaudo por este nuevo realismo.

Si realmente lo fundamental es que la simulación de fondo, el Quantum, sea común a todos los Shards. Y eso lo han explicado en este Q&A. Así que por mi perfecto.

Por lo demás están tomando caminos ya conocidos en lugar de buscar eternamente supuestas genialidades, que no alcanzan nunca. Como las granjas de lechugas de palito, que van a funcionar parecido a otros juegos, como los Fleet Carrier de ED. Yo hubiera preferido áreas delimitadas comunes, porque a pesar de ser más artificial rompe menos la immersión, pero por lo menos por fin eligen por una de las opciones sensatas, que comentaba posts más arriba.

Este juego si me creo que lo vayan a poder publicar.
 
Chekatron said:
Predicador said:
Adamanter, que no se te atragante esto, es oficial, Q&A del Server Meshing.

"If I make a base on a moon, will my base be reflected on the other shards that I am not on?

The Planet Tech team plans to implement base building with server shards in mind. Claiming land for your base will claim this land on all shards, and we plan to replicate your base to all shards.

However, only one shard will have an ‘active’ version of the base, with other shards spawning a ‘limited access/read only’ version of that same base. For example, a base will give full access and the ability to expand in the shard the owner currently plays on, while on all other shards, this base may spawn with locked doors in an immutable state. The full design is not 100% established yet and may change though."


QED.

¿Quieren decir que podré bombardear una base "inactiva" en mi "fragmento del servidor" y las bombas no le harán nada? Entiendo la parte de que la base esté cerrada y apagada, como si no hubiera nadie en casa, pero mis torpedos son unos maleducados y no llaman al timbre... o en todo caso llaman y se van corriendo xD

Va a ser como o muy similar a los FC de ED. Si lo dicen ellos bien claro: "‘limited access/read only’". para referirse a las copias de la granja donde no está el jugador. Quizás te parezca que las has destruido al bombardearlas, eso ilusión quizás si te la dejen vivir, a diferencia de ED, pero va a ser completamente irrelevante, igualmente. Porque como no te emparejen con la original, nanay. Que es cuando si vamos a tener espero la diferencia con un FC de ED. Quizás los servicios del nodo también estén limitados, en las réplicas, ya se verá.
 
Pues se me hace raro de imaginar lo que quieren hacer, creo que no alcanzo a entender cómo funciona, porque se me escapan los conocimientos técnicos necesarios para ello.

Si ponemos el ejemplo de la base, el "fragmento relevante" debería ser "la base y su territorio más cercano" y a medida que te alejas, deberían crearse otros fragmentos menos relevantes para lo que ocurra en la estructura. Si muchos jugadores se amontonan en esa base, deberían saturar ese fragmento y a partir del máximo soportable comenzarían los problemas de lag y tirones o incluso peor, caídas de servidor; pero lo que plantean es que llegados a ese punto, los últimos en llegar o los "jugadores menos relevantes" se pongan en una copia a parte en la que pueden corretear y hacer el oso pero sin relevancia. ¿Esto es así o lo he entendido mal?

Yo prefiero que se caiga el servidor, la verdad, he estado en la apertura de Auroria en Archeage, he visto  miles de jugadores lanzando skills "invisibles" y provocando lag tanto a nivel de servidor como de jugador (mi gráfica tuvo que ir a terapia después de aquello xD) y aún así creo que es preferible eso a mandarnos a la dimensión espejo del Dr Strange.

Por otro lado supongo que un torpedo o una bomba será lo bastante relevante como para entrar en el fragmento principal por la puerta VIP, pero lo de las dimensiones paralelas no termino de verlo.

Lo que se podría hacer, y seguro que acabará pasando por lo que han comentado, es reducir la necesidad de tanto jugador para que esos eventos sean meras anécdotas como lo de Auroria, y por ejemplo reducir los requisitos de tripulación de las naves, no me extrañaría ver Javelins manejadas solo por 6 jugadores, aunque esto plantearía otro problema: ¿Polaris y Perseus controladas por un único jugador? Total solo quieres usar los torpedos y  cañones, ¿para qué más? ¿Cuántas podrá manejar el servidor en pleno vuelo? ¿Se podrá luchar a lo largo de varios fragmentos e ir cambiando de uno a otro mientras te desplazas por el espacio? Esto último creo que era la idea original y cuanto más lo pienso más me suena a ciencia ficción.

 
Chekatron said:
Pues se me hace raro de imaginar lo que quieren hacer, creo que no alcanzo a entender cómo funciona, porque se me escapan los conocimientos técnicos necesarios para ello.

Si ponemos el ejemplo de la base, el "fragmento relevante" debería ser "la base y su territorio más cercano" y a medida que te alejas, deberían crearse otros fragmentos menos relevantes para lo que ocurra en la estructura. Si muchos jugadores se amontonan en esa base, deberían saturar ese fragmento y a partir del máximo soportable comenzarían los problemas de lag y tirones o incluso peor, caídas de servidor; pero lo que plantean es que llegados a ese punto, los últimos en llegar o los "jugadores menos relevantes" se pongan en una copia a parte en la que pueden corretear y hacer el oso pero sin relevancia. ¿Esto es así o lo he entendido mal?

Yo prefiero que se caiga el servidor, la verdad, he estado en la apertura de Auroria en Archeage, he visto  miles de jugadores lanzando skills "invisibles" y provocando lag tanto a nivel de servidor como de jugador (mi gráfica tuvo que ir a terapia después de aquello xD) y aún así creo que es preferible eso a mandarnos a la dimensión espejo del Dr Strange.

Por otro lado supongo que un torpedo o una bomba será lo bastante relevante como para entrar en el fragmento principal por la puerta VIP, pero lo de las dimensiones paralelas no termino de verlo.

Lo que se podría hacer, y seguro que acabará pasando por lo que han comentado, es reducir la necesidad de tanto jugador para que esos eventos sean meras anécdotas como lo de Auroria, y por ejemplo reducir los requisitos de tripulación de las naves, no me extrañaría ver Javelins manejadas solo por 6 jugadores, aunque esto plantearía otro problema: ¿Polaris y Perseus controladas por un único jugador? Total solo quieres usar los torpedos y  cañones, ¿para qué más? ¿Cuántas podrá manejar el servidor en pleno vuelo? ¿Se podrá luchar a lo largo de varios fragmentos e ir cambiando de uno a otro mientras te desplazas por el espacio? Esto último creo que era la idea original y cuanto más lo pienso más me suena a ciencia ficción.

La parte técnica que la explique Hunk Stalker o algún voluntario  ;D

Pero ya en el Q&A te comentan que las naves grandes tengan su propio servidor. Y eso cuando funcione en Dinamic Server Meshing, imagínate antes.

"Con el "Dynamic server meshing" o mallado dinámico del servidor, es posible que las naves grandes, como la Javelin, tengan su propio servidor asignado para ejecutar la simulación autorizada para esa nave y todo lo que hay en ella. Sin embargo, intentamos evitar tener reglas inflexibles sobre cómo se asignan las entidades a los recursos de procesamiento, por lo que no siempre será así. Se trata de una cuestión de eficiencia, tanto en términos de velocidad de procesamiento como de costes de servidor. Si tuviéramos una regla rígida de que cada Javelin y todo lo que hay en ella tiene su propio servidor, entonces no sería muy rentable cuando un Javelin sólo tiene un puñado de jugadores dentro de ella. La misma regla tampoco sería eficiente en términos de velocidad de procesamiento del servidor si hubiera cientos de jugadores apiñados en la misma Javelin, ya que la regla nos impediría distribuir la carga de procesamiento entre varios servidores."

Si consiguen hacer que la IA funcione, meterán la NPC crew que se comentaba desde los inicios. Y por un simple principio básico de economía de esfuerzo, casi todas las naves capitales de jugadores, irán con uno o pocos jugadores. Quitándo algunos grupos recalcitrantes, por puro roleo militar, que se terminarán cansando de hacerlo de manera habitual=para farmear.

Ya he dicho que a mi me suena a tiempo de rebajas, y es algo bueno. No pueden hipotecar el futuro del juego lastrado por el peso muerto de ideas felices sobre las que giraba el diseño original. Espero que esto les desatasque, aunque sigue estando el resultado lejano.
 
Lo que entiendo de ese párrafo es que habrá ocasiones en las que una javelin será un servidor entero, o fragmento, pero solo cuando haya un número de jugadores relevante para crear un fragmento que abarque exactamente esa nave, si solo hay 3 jugadores, el fragmento abarcará la Javelin+espacio próximo (que si solo hay 2 jugadores más en Hornets podría abarcar una luna entera, por decir algo, no?), y del mismo modo, si hay mucha gente en esa nave es posible que la bodega sea un fragmento y el puente otro diferente.

Si es como lo he entendido, el reto tecnológico sería, desde mi punto de vista, poder  gestionar todos esos fragmentos y jugadores para que todas las posibles acciones relevantes respecto al resto de elementos se puedan emparejar entre ellas en el mismo fragmento, de lo contrario podemos encontrar casos de jugadores a los que les disparas y no les haces nada porque están en otro fragmento, entonces, pongamos la Javelin como fragmento, llega una Retaliator y le lanza un torpedo... bueno no, una Ares, porque un torpedo tal vez se considere como un elemento físico capaz de viajar entre fragmentos, pero una ráfaga láser no creo; lo que quiera que haga este láser puede ser relevante para ese fragmento, pero está fuera de él, por lo que habría que incluir esta nave enemiga en el mismo fragmento de la Javelin, es decir, hacerlo más grande. No me quiero imaginas una batalla de varias naves capitales.

Supongo que en el espacio se pueden crear fragmentos dentro de fragmentos, es decir, un fragmento 1, nuestra Javelin, un fragmento 2, la Idris enemiga y un fragmento 3, el espacio entre ellas, ¿y cuando sean tantas naves que haya que fragmentar el espacio? Supongo que la misma Ares podrá volar por toda la batalla cambiando de fragmento ¿Y una Polaris que dispara un torpedo a 60km de distancia?... bueno vamos a dejarles trabajar, tienen mucho curro por delante xD

EDITO: tal vez los problemas planteados con este  sistema solo se den en absurdas situaciones en las que 60 jugadores amontonados disparen a otros 60 jugadores amontonados mientras otros 60 jugadores también amontonados les disparen al mismo tiempo, es decir, ahí la gente iría a romper el sistema directamente xD

En este caso uno de los pelotones no le haría daño al resto.
 
Chekatron said:
No me quiero imaginas una batalla de varias naves capitales.

Esto resumiendo es mi conclusión de tu parrafada XD

Es lo que tiene archivar por la letra P las ideas felices. Ahora tienen que trabajar con conceptos realistas y hay muchas dificultades para que el juego final se acerque al de la visión, porque la visión se basaba en poder alcanzar esas ideas felices.

A mi genial que vayan relatando la variabilidad de opciones que tienen que enfrentar. Simplemente por como se presentan este tipo de textos, frente a los de ideas felices o de control de daños, aunque realmente no entiendas el contenido, respetas su valor.
 
Chekatron said:
Lo que entiendo de ese párrafo es que habrá ocasiones en las que una javelin será un servidor entero, o fragmento, pero solo cuando haya un número de jugadores relevante para crear un fragmento que abarque exactamente esa nave, si solo hay 3 jugadores, el fragmento abarcará la Javelin+espacio próximo (que si solo hay 2 jugadores más en Hornets podría abarcar una luna entera, por decir algo, no?), y del mismo modo, si hay mucha gente en esa nave es posible que la bodega sea un fragmento y el puente otro diferente.
Es exactamente eso. Eso es lo que hace el server meshing dinámico. Y como dicen en la QA, el problema de la acumulación de genete está del lado del cliente no de los servidores. Eso lo han dicho siempre, desde el 2015 que es cuendo hicieron el cambio de diseño y empezaron a hablar de el Server Meshing.

Si hay poca gente, la burbuja que controla ese servidor o nodo servidor, como lo llaman ahora, puede ser tan grande como un sistema entero; donde se vaya acumulando gente esa zona se va repartiendo entre múltiples nodos según se vayan necesitando. Que sea el espacio, un planeta, o una ciudad es lo de menos, lo que determina la necesidad de nodos adicionales es el tráfico de jugadores.

El fragmento contiene TODOS los nodos y los mantiene actualizados, el problema que tu mencionas no se va a dar, porque los nodos no hablan entre sí, hablan con el fragmento en el que están, que es el encargodo de manter TODOS los nodos actualizados en todo momento.

Salu2 :)
 
Adamanter said:
Chekatron said:
Lo que entiendo de ese párrafo es que habrá ocasiones en las que una javelin será un servidor entero, o fragmento, pero solo cuando haya un número de jugadores relevante para crear un fragmento que abarque exactamente esa nave, si solo hay 3 jugadores, el fragmento abarcará la Javelin+espacio próximo (que si solo hay 2 jugadores más en Hornets podría abarcar una luna entera, por decir algo, no?), y del mismo modo, si hay mucha gente en esa nave es posible que la bodega sea un fragmento y el puente otro diferente.
Es exactamente eso. Eso es lo que hace el server meshing dinámico. Y como dicen en la QA, el problema de la acumulación de genete está del lado del cliente no de los servidores. Eso lo han dicho siempre, desde el 2015 que es cuendo hicieron el cambio de diseño y empezaron a hablar de el Server Meshing.

Si hay poca gente, la burbuja que controla ese servidor o nodo servidor, como lo llaman ahora, puede ser tan grande como un sistema entero; donde se vaya acumulando gente esa zona se va repartiendo entre múltiples nodos según se vayan necesitando. Que sea el espacio, un planeta, o una ciudad es lo de menos, lo que determina la necesidad de nodos adicionales es el tráfico de jugadores.

El fragmento contiene TODOS los nodos y los mantiene actualizados, el problema que tu mencionas no se va a dar, porque los nodos no hablan entre sí, hablan con el fragmento en el que están, que es el encargodo de manter TODOS los nodos actualizados en todo momento.

Salu2 :)

Salvo que a partir de ahora ya oficialmente, no hay un futuro universal shard server lo que sea, seamless y se van a dar shards paralelos (aunque en el Q&A han metido un texto vacío y sin compromisos reales, en la conversación en Twitter reciente sobre este problema quedó claro que incluso aunque en un futuro se pudiera conseguir, supondría importantes limitaciones para un juego del alcance de SC, hablando en plata, ni aunque lo consiguieran, sería útil). Ahora su máxima ambición práctica es llegar a shards regionales. Si están utilizando de ejemplo una sola Javelin, por amor de dios Ada. Esa javelin según el emparejamiento va a ser la Morning Destroyer del jugador pepito pi 1998 o una de 40 réplicas genéricas en modo lectura. Y si es un fragmento de shard, a todo ese shard le va podrían llegar a afectar los problemas de emparejamiento (hablan de evidentes incluso para mi XD parámetros para emparejarte, de los más obvios a los internos del juego) con Pepito Pi. Y volvemos al modo lectura de las réplicas de la Javelin. Y solo reproduzco lo que pone su propio Q&A
 
Is the true end goal one single shard for all players?
This is our ambition, however giving a definite answer is not possible at this point.

We will start with many small shards per region and slowly reduce the number of shards. The first major goal will be to reduce this to only needing one single shard per region. To get there, our plan is to gradually increase player count per shard and constantly improve the backend and client tech to support more and more players.

It’s not just technology changes that are required to get to this goal - new game design and game mechanics are needed too. Without mechanics to prevent every single player going to the same location, a large mega shard will be very hard to achieve, especially on the client. For example, there could be a mechanic to temporarily close jump points to crowded locations, or create new layers for certain locations.

While the backend is designed to scale horizontally, the game client runs on one single machine and is limited to a definite number of CPU/GPU cores as well as memory.

Only once we overcome these hurdles, and accomplish one mega-shard per region, will we be able to take on the final boss: Merging regional shards into one global mega shard.

This comes with its own set of issues, as locality plays a big role in the player experience. For example, latency between services within the same datacenter is much lower than latency between services that are hosted in two regionally-separated datacenters. And while we designed the backend to support one global shard, it is an operational challenge to deploy the backend in a way that doesn’t favor one group of players over another.
Sigue siendo el objetivo, Y aclaran:
"Empezamos con fragmentos pequeños, y el primer objetico es llegar a tener un fragmento por región"
Y más adelante dejan claro que:
"Una vez superados los obstáculos y conseguido el magafragmento regional se enfrentarán al boss final: fusionar los megafragmentos regionales en un único megafragmento global."

Salu2 :)
 
Adamanter said:
Is the true end goal one single shard for all players?
This is our ambition, however giving a definite answer is not possible at this point.

We will start with many small shards per region and slowly reduce the number of shards. The first major goal will be to reduce this to only needing one single shard per region. To get there, our plan is to gradually increase player count per shard and constantly improve the backend and client tech to support more and more players.

It’s not just technology changes that are required to get to this goal - new game design and game mechanics are needed too. Without mechanics to prevent every single player going to the same location, a large mega shard will be very hard to achieve, especially on the client. For example, there could be a mechanic to temporarily close jump points to crowded locations, or create new layers for certain locations.

While the backend is designed to scale horizontally, the game client runs on one single machine and is limited to a definite number of CPU/GPU cores as well as memory.

Only once we overcome these hurdles, and accomplish one mega-shard per region, will we be able to take on the final boss: Merging regional shards into one global mega shard.

This comes with its own set of issues, as locality plays a big role in the player experience. For example, latency between services within the same datacenter is much lower than latency between services that are hosted in two regionally-separated datacenters. And while we designed the backend to support one global shard, it is an operational challenge to deploy the backend in a way that doesn’t favor one group of players over another.
Sigue siendo el objetivo, Y aclaran:
"Empezamos con fragmentos pequeños, y el primer objetico es llegar a tener un fragmento por región"
Y más adelante dejan claro que:
"Una vez superados los obstáculos y conseguido el magafragmento regional se enfrentarán al boss final: fusionar los megafragmentos regionales en un único megafragmento global."

Salu2 :)

71j6hmii22t71.jpg


La diferencia es que ese párrafo del Q&A es un texto cuidadosamente redactado con calma y paciencia antes de publicarlo, que carece de compromisos. Si comparas con otros párrafos, que concretan fases e incluso meten fechas (que creo es un error, por otra parte), la naturaleza de este texto es muy diferente.

Mientras que la conversación en Twitter es un punto o dos más libre y directamente ejecutada por el experto, sin intermediarios.

Y te lo dice bien clarito: "To go beyond that would require a global shard which I mentioned earlier would need further  R&D and design considerations and could very well have fundamental limitations that are not acceptable for a game of our scale"".


De hecho en el Q&A ya se ponen la venda antes de la herida y hablan de limitaciones. Para seguir usándolas en el futuro en sus comunicaciones, en mi opinión.

Esto es lo más cercano que vamos a tener a una negativa en lenguaje corporativo, pero puedes esperar sentado, es cosa tuya, pero para el lector casual que era yo y sin conocimientos para contrastar las ideas felices como también yo XD, no voy a dejar de postear esto.

Y por como lo expresan y los ejemplos que ponen en el propio Q&A, el regional shard está a suficientes años de distancia y es suficientemente complejo, como para que no sea cosa segura por si misma.
 
Atrás
Top