Opiniones sobre arquiectura C/S y editores de mapas.

[Ying]

Hum hum, cuantas respuestas xD

A ver.
Por ahora me habeis dado una bonita colección de ideas del asunto cliente/servidor, desde trabajo de campo hasta manuales. Alguien tiene por ahi algun manual de que considere interesante? Los que he ido encontrando tienen bastantes añitos, y no es que sean malos, pero con la tecnología no está de mas aprovecharse de lo mas reciente.

Lo que tengo en la cabeza (y en el documento de diseño):

Se empleará una arquitectura Cliente – Servidor, usando una mezcla de TCP y UDP  dejando la parte crítica a TCP y el resto a UPD junto con predicciones sencillas.
Jugarán juntos hasta un máximo de 16 jugadores, 8 por equipo.  Se usaran puertos "non-blocking" junto con select(). De librería usaremos Winsock2.

Como optimizaciones, comenzaremos por no enviar cualquier cosa que no se muestre en la visión/ oido del personaje, con un cierto margen de distancia.
Usaremos un sistema de prioridad para repartir el ancho de banda, de la siguiente forma:
• Bots: 8.0
• Objetos movibles: 7.0
• Proyectiles: 6.0
• Peones (bots no combatientes): 4.0
• Criaturas decorativas (como peces, por ejemplo): 2.0
• Decoraciones: 0.5

Sobre el editor de mapas...

@StraT: Si, el sistema de eventos estaba diseñado y lo vamos a montar con LUA para que sea lo más flexible posible.

@Prompt: Pese a que el editor del grome no me sirve porque se pasa 3 pueblos de los que tenia en mente, la sección de   Features tiene las características mas importantes del motor, de ahi he sacado un par de ideas interesantes :3 Gracias!

Por lo demás, si, es 3D pero yo también opino que es más o menos lo mismo en 3D q en 2D, sobretodo a nivel de diseño.

Gracias!!
Alguna sugerencia mas?[/quote]

[Calantra]

Cosas interesantes en un editor de mapas (aparte de la obviedad) es, por ejemplo, un sistema de colisiones. Tan simple como poder leer en el motor qué tiles son "walkables" (es que caminables no queda cool) y cuales no.

Se les pueden llamar sólidos, suena mejor no?.  :wink:

Como optimizaciones, comenzaremos por no enviar cualquier cosa que no se muestre en la visión/ oido del personaje, con un cierto margen de distancia.
Usaremos un sistema de prioridad para repartir el ancho de banda, de la siguiente forma:
• Bots: 8.0
• Objetos movibles: 7.0
• Proyectiles: 6.0
• Peones (bots no combatientes): 4.0
• Criaturas decorativas (como peces, por ejemplo): 2.0
• Decoraciones: 0.5

Creo que counterstrike usaba algo parecido + un sistema de predicción, lo que pasaba es que a veces disparabas al aire y le volabas la cabeza a al que le salia de los webs del juego. :lol:
Salu2.

[tamat]

Usar el cono de vision? mal, si el jugador se da la vuelta rapidamente verá que no hay nadie detras suyo y luego aparecerá todo. Mejor usa distancia al jugador.

[Prompt]

Usaremos un sistema de prioridad para repartir el ancho de banda, de la siguiente forma:

Se puede saber que es esto? xD

Se tiene un ancho de banda / segundo, y un tamaño máximo por datagrama, imagino que toda esa lista es UDP. Creo no entender lo de la prioridad, vas a descartar paquetes si alguien dispara cuando hay miles de bots en pantalla?

[Ying]

@tamat: Buena puntualización, cuando lei tu post pense "menuda chorrada, obviamente que es un radio, y no un cono" y despues fui, lei lo que habia escrito yo en el diseño... y efectivamente, ahi no pone nada de un "radio" de vision. -.-U Asi que probare escribir lo que quiero decir, en vez de suponer que la gente va a intuir lo que pasa por mi cabeza xD Gracias xD

@Prompt: Es exactamente el mismo sistema que usa el quake, simplemente que habiendo una cantidad de datos que se pueden mandar por segundo, en el caso que el total de datos exceda esa cuota, la prioridad para que se mande un determinado dato, priorizado según como afecta la jugabilidad.
Si te interesa con más detalle, y todo el sistema de networking + optimizaciones del Quake, lo tienes aqui