Re: [escepticos] Re: Un muy misterioso asunto. (para mi)

[Tei <421621@...>]

[..]

>
>Según mi opinión (nada experta, ojo) el programa debe
>conocer "el mapa", es decir, los objetos inamovibles
>dentro del escenario (montañas, edificios,
>decorado...) y los "objetos móviles" (jugadores,
>proyectiles...). La parte que he llamado "mapa" es
>fija para todos los jugadores y el programa en cada
>uno de los ordenadores clientes lo conocerá de
>antemano. Y menos mal, porque suelen ser archivos
>bastante gordos para andarlos pasando por Internet en
>cada partida. En cuanto a los objetos móviles sólo es
>necesario transmitir su posición, orientación...y poco
>más. Estos datos, parece que deberían poder mandarse
>en bastante poco espacio.
>Lo que quiero decir es que si el problema fuese el
>envio de datos al nuevo jugador, parece que todos los
>jugadores tendrían ese problema. Quiero decir que no
>hay diferencia entre los datos que habria que enviar a
>un nuevo jugador y los que habria que enviar a un
>jugador que ya estuviese jugando.

Despues de leer tu correo, he llegado a la conclusion de que das en el
clavo al respecto
de que el problema esta en la arquitectura, puede ser un lio gestionar una
nueva conexion
cuando la gestion no es centralizada, sino p2p.

De todos modos te comento el resto del email.

Si que puede ser una sobrecarga mayor la entrada de un sujeto que el frame
Nesimo.
Se me ocurre que estos sistemas funcionan mediante una imagen almacenada
del estado
de los objetos fisicos en el escenario (desde una bala a un brazo), cuando
se conectan
deben enviar todos los datos (posicion, angulo, escala, textura, cuadro,
transparencia, etc..)
y en cuadros posteriores solo se envia la informacion delta, la que ha variado.

Luego, en un juego como este puede interesar que los jugadores intercambien
entre si "pieles"
de sus jugadores, que se podrian personalizar con anagramas de a que club
de luchadores pertenecen (clan), caras mas fieras, color de piel, foto
sobreimpresa en la parte de la cara, etc.. en desarrollos anteriores
(quakeworld) esto existia ya, lo que restaba anonimato
a los combates y mejoraba la experiencia. Quizas ahora no lo usen, claro,
pero cualquier
cosa similar ya seria sobrecarga al respecto.

Lo que yo pienso al respecto es que estas cosas no tendrian porque ser
problema, simplemente
se retarda el cuadro en el que efectivamente aparecera el jugador en el
mapa a que todos
tengan todos los datos.

>
>Alguien podría decir que los datos para los jugadores
>que ya estan jugando "viajan" por una conexión que ya
>está establecida (me refiero a que los enrutadores ya
>saben por qué caminos tienen que mandar la información
>desde esas direcciones de origen a esas de destino,
>porque "han estado haciéndolo durante toda la partida"
>(que no se me tire al cuello ningún purista, que lo
>pongo así para que lo entienda todo el mundo),
>mientras que cuando les llegan los primeros paquetes
>desde y hacia la dirección del nuevo jugador tienen
>que "mirar por donde los mandan" porque no saben a
>priori por que caminos mandarlos. No sería problema,
>porque se podria hacer empezar al jugador con el delay
>necesario (desde su requerimiento de empezar la
>partida) para que el camino estuviese establecido.

sin duda los encaminadores tienen estrategias y las comunicaciones largas
se benefician
de ellas, pero no creo que la arquitectura se construya para
beneficiarse/evitar estas
estrategias que en principio son transparentes y encima dependen mucho del
"tiempo" en la red.


>
>Creo que alguien menciono algo sobre que el juego en
>cuestion era peer to peer, de manera que era cliente a
>cliente, sin servidor. Me gustaria que alguien me lo
>explicase un poco (en que consiste y que ventajas
>puede tener para este tipo de juegos). Si quiere decir
>que no hay servidor al que cada jugador le manda los
>datos de sus movimientos para que procese el resultado
>(o no) y les envie a todos los jugadores las nuevas
>posiciones de los elementos móviles, ...pues me parece
>que puede haber un pequeño follon, puesto que cada
>programa cliente deberia establecer conexiones con
>todos los demas (¿igual por eso solo es "optimo" para
>4 "miseros" jugadores?). Puede montarse un bonito lio,
>si tenemos en cuenta los problemas tipicos que suele
>haber (lags, fallos de conexión...) no se..., no me
>parece muy buena idea. Por eso me gustaria que alguien
>me aclarase en que consiste y que ventajas puede
>tener.
>

aqui das en el clavo, aunque quizas lo que falte ver es que quizas la
ruptura final
que hace inmanejable para un programador demostradamente competente es la
prediccion
de la posicion de los objetos tras todos los eventos de los que hablas

>
>

goyo:

>> > En principio con una buena gestion dinamica
>> > de las tablas de datos no veo que sea imposible
>> incluir jugadores nuevos
>>
>> ¿Desde cuándo las cosas que no hace un programa es
>> porque sean imposibles?

no, es verdad, aveces hasta se realizan cosas que parecen imposibles. (o se
parece hacer
cosas que realmente lo son)

>> Léelo así: implementar una solución para incluir
>> nuevos jugadores con un
>> rendimiento razonable tanto para el nuevo jugador
>> como para los anteriores y
>> a un coste también razonable (sustitúyase
>> "razonable" por las
>> especificaciones que el fabricante considere
>> oportunas). Demasiados
>> parámetros desconocidos como para afirmar que sea
>> posible o imposible.
>

en este caso ya hay unos plazos para la presentacion y la parte importante
del codigo al respecto, aunque sea globalmente auxiliar, no esta echa...


>>
>> Saludos
>>

Saludos

>> Goyo
>>


Jaw:

>No creo que los datos que tenga que procesar el
>ordenador le supusiesen demasiada carga (quiero decir
>como para que esto supusiese el "cuello de botella"
>del problema), me parece que es mas critica la
>conexion.


cierto, ultimamente los procesadores graficos son de varias generaciones
mucho mas modernas que las CPU  y cuentan con buses mucho mas rapidos a
memorias mucho mas rapidas. El trabajo importante es realizado por la tarjeta,
y la CPU se mantiene inactiva la mayor parte del tiempo. Al menos en software
de juegos...

..de todos modos toda esa potencia (que es ridiculamente inferior a la de
la tarjeta)
es un potencial para emplearlo en bastantes asuntos interesantes.

los motores 3d previos a las tarjetas 3d tenian todos feelings and lookings
distintos,
mientras que los actuales se parecen demasiado. El procesamiento por la CPU
proporcionaba
aspectos diferenciadores muy interesantes.. quizas se emplee para lo mismo
hoy en dia,
aunque las nuevas tecnologias de shaders y pixels shaders crearan
realidades visuales
mas interesantes de lo que estamos acostumbrados a ver (incluido en el
cine), interesantes para el ojo.. digo, por contrastres, luces, sombras,
etc.. Tenemos el ojo muy cansado de ver,
aunque aun no lo ha visto todo, y ese todo supongo que llegara con los
pixel shaders.


> Me refiero a que el tipo de calculos que
>realizan estos juegos son más bien sencillos, y la
>"física" también (me parece, si alguien lo sabe a
>ciencia cierta, me gustaria que me lo exl¡plicase).
>Sólo hay que implementar las colisiones (no permitir
>que dos objetos sólidos penetren el uno en el otro,
>OH, PRODIGIO), la gravedad (los jugadores y los
>objetos "gordos" (las balas no) lanzados la sufren
>(OH, una ecuación para calcular la velocidad en cada
>instante más otra para calcular la "pupita" que se
>hace el jugador cuando colisiona a 80 Km/h contra el
>suelo). Y estamos hablando de ecuaciones realmente
>simples, nada de ecuaciones diferenciales, integrales,
>ni nada por el estilo.

puede ser aun mas cutre. En lugar de colisionar con formas que se adaptan
al objeto,
este se rodea de una "caja" frente a la que se calculan las colisiones. De
todos modos
parece que este nuevo motor hace estas tareas mas interesantes y en los
videos se ven
cuerpos humanoides cayendo por escaleras con una fisica realista.

aparte de reproducir esa fisica de la que hablas, hacen predicciones de la
posicion de los objetos futuros, se pretende permitir que los objetos se
muevan en los clientes a su gusto,
aunque aun no sea efectivo el cambio hasta que no ocurra en el server...
esto permite jugar fluidamente aunque los datos lleguen cada medio segundo
o mas... claro que esto es arquitectura cliente servidor y estamos hablando
de un nuevo motor con arquitectura cliente-cliente, en el cual no se si
dejara de haber prediccion o estara por cuadruplicado ...

>Lo más sofisticado que he
>visto, aunque seguro que hay algún juego que tiene
>algo "mejor" es la pérdida de velocidad de las balas
>al atravesar materiales, según la bala, el material y
>la distancia recorrida dentro del mismo, pero seguro
>que lo hacen con una aproximación sencilla de calcular
>y que de el pego. Tal vez si quisieran mostrar el
>impacto del proyectil según la parte del cuerpo,
>teniendo en cuenta que esta formado por organos y
>zonas de distintas densidades y quisieran que fuese
>muy cercano a lo que ocurriria relamente, pues....no
>se podría jugar, pero o estoy hablando de programas
>para simular procesos fisicos, estoy hablando de
>juegos. Hay progamas por elementos finitos para
>simular colisiones que pueden estar toda una noche
>corriendo en doce procesadores en paralelo para
>simular una unica colision (la deformacion del coche).

aja. Claro. Nunca es lo mismo un simulador cuyo fin es el tiempo real, por
ejemplo un robot
que mueve cargas por un almacen (y que no se puede permitir el lujo de
hacer calculos intensivos) o de un videojuego, y los calculos de muchos
decimales y sin aproximaciones, trucos, etc.. de un simulador que intenta
conseguir la mayor fidelidad a la realidad no importa el coste.

luego ocurre que esa fidelidad es interesante para juegos y
robots-que-mueven cargas y segun la
potencia de la tecnologia se traen calculos de uno a otros. La potencia de
las cpu de graficos
es hoy en dia brutal. Frente a CPU brutalmente potentes de 32 bits, tenemos
CPU de 64, 128 bits, y arquitecturas dedicadas. Creo que hoy en dia tenemos
en el teclado uno de esos chips que en tiempos habrian necesitado una
piscina para refrigerarse. Supongo que con el tiempo se integraran estas
arquitecturas en las placas, para tener video y sonido de callidad DVD
corriendo sin impacto en el sistema.


>Eso si es un cálculo que podríamos llamar complejo,
>pero es que los fenomenos fisicos se intentan
>reproducir lo más fielmente posible.

ya

>Ojo, en todo lo anterior me refiero al proceso de
>DATOS, no a los cálculos para GRAFICOS que tienen que
>realizar las tarjetas gráficas para representar la
>escena y, para las cuales la presencia de más
>jugadores es equivalente a un escenario más complejo,
>a efectos prácticos un jugador sería equivalente a un
>objeto "de mobiliario" (polígonos y texturas).

tambien ciertos calculos se pueden realizar sobre una zona de memoria, de
modo que las potentes tarjetas graficas actuales serian utiles (a pesar de
su poca fidelidad) para procesar señales al estilo de lo que se hace en
vision artificial (encontrar contornos), etc.. lo malo es que hoy en dia no
cuentan directamente con estas herramientas (filtros), una pena, porque es
mucha potencia que esta ahi dormida (mientras no se juega). Esas pedazo
tarjetas 3D actuales procesando señales de SETI en home serian la hostia :]

>
>Saludos,
>
>Nanda.
>
>
>

saludos