Hola a todos, soy nuevo por aquí asi que aprovecho para presentarme:
Soy Jaime, Ying para los amigos, y estudio en la politecnica de valencia, al tiempo que muevo un poco el mundillo de los videojuegos por mi zona.
Ahora a lo que iba, estamos diseñando un pequeño motorcillo de videojuego 3D para el curso que viene y probablemente el otro, y queria saber que ideais teniais sobre los temas del título:
- El motor está pensado para ser multiplayer, con arquitectura Cliente/Servidor y usando UDP. Nunca he hecho nada parecido antes y queria saber que ideas, sugerencias o enlaces interesantes podriais tener sobre el tema, sobretodo sobre el servidor y optimizaciones en la transferencia de datos.
- A pesar de haber herramientas de terceros que son estupendos editores de mapas, estamos ilusionados con hacer el nuestro para el motor y querria saber que es lo que más se agradece en un editor de mapas y posibles implementaciones.
Aun estamos escribiendo diseño, así que cualquier idea en cualquiera de los dos temas es bienvenido. Puede que más adelante hable del motor en otro post aparte, así que por ahora solo quiero saber que opina esta comunidad de esos dos temas.
A ver que ideas teneis! Gracias!
Cita de: "Ying"Soy Jaime, Ying para los amigos
Hola Jaime........... :P hehehee
Cita de: "Ying"
- El motor está pensado para ser multiplayer, con arquitectura Cliente/Servidor y usando UDP. Nunca he hecho nada parecido antes y queria saber que ideas, sugerencias o enlaces interesantes podriais tener sobre el tema, sobretodo sobre el servidor y optimizaciones en la transferencia de datos.
UDP para que tipo de juego? porque lo mismo es una tontería usar UDP. Si utilizas UDP o reimplementas reordenacion de paquetes y que te lleguen todos o implementas una predinccion con ajuste de la posición y demás del jugador para cuando lleguen los paquetes. Sin más datos poco te puedo decir.
Cita de: "Ying"
- A pesar de haber herramientas de terceros que son estupendos editores de mapas, estamos ilusionados con hacer el nuestro para el motor y querria saber que es lo que más se agradece en un editor de mapas y posibles implementaciones.
No lo hagas... usa cosas tipo photoshop y cosas así aunque tardes mucho más, ya que al ser el primer motor y juego, lo tirareis todo a la basura. Tomaoslo como algo tipo "learning". El desarrollo de una herramienta que haga que el desarrollo de juegos en vuestro motor / modificaciones puede tardar más que el desarrollo del mismo motor!
(que de veces desarrollador...)
He dicho!
Saludos.
¿Qué otras cosas habéis hecho antes de este proyecto?
A ver, por partes...
No es el primer motor de juego, auque el anterior que hicimos es en 2D y ese si que fue para aprender, por lo que es bastante patatero. El codigo y demás se puede encontrar aqui:
http://www.assembla.com/wiki/show/insania_caged
aunque no recuerdo si el svn era publico o habia que estar reguistrado, en todo caso, era un rpg clásico, en 2D, visto desde arriba, donde llevavas a tu grupo de personajes e ibas por ahi descubriendo la historia del juego y matando bichos. Lo tipico. Incluia editor de mapas q los guardaba a XML, pero mas como herramienta interna para no tener que editar las miles de lineas de los mapas a mano.
Aparte de ese projecto que es el unico que ha hecho el equipo juntos, pues depende de quien. Yo por ejemplo antes de eso hice un chapuza-juego con allegro que nunca llegue a terminar, pero si que tenia un editor de mapas, en el que descubri lo terrible que es la GUI de allegro si quieres customizarla -.-U. Y también trabajé en un pequeño motor de un amigo de EU llamado ZXgame engine, que aun sigue en proceso aunque yo ya no colaboro.
ESTE juego/motor pues está orientado a un hibrido de acción plataformas. Nada fuera de serie, pero con un enfasis en el trabajo en equipo y combinaciones de habilidades. Dos equipos de 2 a 8 jugadores juegan en uno de los mapas disponibles y gana el que antes/mejor cumpla los objetivos del mapa. (Los modos tipicos, deathmatch, captura de bandera, ect...).
De lo que hay que hacer para este motor no hay mucho que me pille con los pantalones bajados, por asi decir, excepto la arquitectura cliente-servidor que nunca he implementado, y aparte quiero hacer un buen editor de mapas esta ronda, ya que cuento con gente que hace mods, pero no tienen idea de programar, asi que proporcionarles una herramienta de editor de mapas me cunde mucho.
Despues de saquear gamedev por manuales de arqutecturas multiplayer y pasarme media campus party leyendolos, queria algunas opiniones de gente real q me dijera que habian implementado ellos, o que pensaban que era mejor y seguir investigando en esa dirección.
Bueno, espero a ver que me decís!
Cita de: "Ying"Bueno, espero a ver que me decís!
Pues yo te recomiendo que hagas investigación de campo.
Coger Quake y machacar la red.
Y luego, te vas a Sourceforge y te miras unos cuantos proyectos que estén más o menos avanzados... y machacar de nuevo la red.
Montas las pruebas en red local, con un sniffer y metiendo tráfico para ver qué tal.
Con eso te harás una idea de por dónde van los tiros.
Se me olvidaba comentar.. XD
Por lo que yo he visto por ahí la mayoría de juegos tienen una mezcla. Normalmente se usa TCP para evitar todo el engorro que comentaba
Prompt en tareas de control y tal... y luego para tareas menores o no sensibles a la pérdida se usa UDP.
Que bruto eres DarkFenix... un sniffer de paquetes y leer codigo de Quake, suena cruel.
Hay muy buenos papers sobre logica de juego a través de red. No tengo enlaces pero hay miles aplicado a cientos de cosas...
Cita de: "Prompt"Hay muy buenos papers sobre logica de juego a través de red. No tengo enlaces pero hay miles aplicado a cientos de cosas...
Sin dudas!
Pero es peligroso y fácil caer en
la espiral del manual, por eso recomendaba otro punto de vista complementario... y no es tan bestia, hombre... :)
Sigo vuestras contestaciones con interés, gracias a todos los que habeis contestado. Que más teneis para mi?
Wenas, yo sólo hablaré del editor de mapas.
Si de verdad os hace ilusión hacer uno, hacedlo, porque lo cierto es que no conozco ninguno que me convenza demasiado.
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.
Otra cosa que podría ser interesante (aunque me falta madurarla) es poder marcar ciertas casillas con "eventos", esto es, algún tipo de "algo" que le indique al motor que en esa casilla hay un evento, cómo se activa, y en qué consiste.
En fin, espero que te sirva.
Un saludo
Grome, buscadlo :)
Cita de: "StraT"Otra cosa que podría ser interesante (aunque me falta madurarla) es poder marcar ciertas casillas con "eventos", esto es, algún tipo de "algo" que le indique al motor que en esa casilla hay un evento, cómo se activa, y en qué consiste.
A esto se le conoce como Triggers. Yo de programar esto tendria implementado o bien triggers especificos por codigo en el juego/motor o bien algo en plan scriptable que se pueda definir mediante un archivo XML o similar. Luego simplemente seria hacer que el editor te mostrara una lista de los triggers disponibles y opciones para indicar sus parametros tales como entidad que vas a activar o accion del juego a ejecutar. Esto lo mejor para comprenderlo, o al menos a mi en su dia me ayudo mucho, fue trastear con el editor de mapas del Half-Life.
Salu2...
No se si me he perdido algo, pero si ellos dicen que "estamos diseñando un pequeño motorcillo de videojuego 3D ", ¿por qué estáis hablando de editores de mapa 2D? :?
Segun he entendido quieren hacer tanto el motor como las herramientas/editores , y les han dado una lluvia de consejos/ideas.
Cita de: "tewe76"No se si me he perdido algo, pero si ellos dicen que "estamos diseñando un pequeño motorcillo de videojuego 3D ", ¿por qué estáis hablando de editores de mapa 2D? :?
3D o 2D que mas da, la filosofia de un editor de niveles siempre es la misma: generar informacion del nivel ya sean tiles o mediante objetos geometricos, indicar informacion de zonas de utiles, ubicar entidades, triggers, etc... :P
Salu2...
Hombre, qué más da, qué más da... :roll:
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):
Citar
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 (http://www.quadsoftware.com/index.php?m=section&sec=product&subsec=editor&target=editor_create) 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]
Cita de: "StraT"
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:
Cita de: "Ying"
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.
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.
CitarUsaremos 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?
@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 (http://unreal.epicgames.com/Network.htm)