Ir al contenido

publicidad
publicidad

Foto

Desarrollo de videojuego [XNA]


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
60 respuestas en este tema

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#16

Escrito 20 febrero 2009 - 21:12

Una pregunta, el menú como lo hiciste? Hay algun tutorial?


Si no estoy equivocado, creo que hay plantillas o "starter-kits" que te ayudan con todo el tema de los menús (incluyendo efectos de transición y todo).

El caso es que los menú que he incluido en el proyecto los he hecho sin usar plantillas ni tutoriales sorry..

Aun así poniendo en google "xna menu" salen muchos resultados y alguno que otro tiene buena pinta.

Un saludo!

PD: Si después de mirarte algún tuto sigues teniendo dudas mándame un MP y te intento echar un cable ;)

  • Ollydbg

  • Valefor

  • vida restante: 100%
  • Registrado: 05 sep 2008
  • Mensajes: 6.259
#17

Escrito 21 febrero 2009 - 13:47

Hola, aprovecho este hilo para no abrir otro preguntando algo relaccionado con el XNA.

El caso es que estoy empezando con XNA para hacer algo en 3D y estoy un poco perdido.

Por lo pronto ya sé como cargar un modelo 3D, moverlo por la pantalla y rotar la cámara con el ratón y ver el objeto desde "distintas" posiciones.

Tengo tantas preguntas que no se por donde empezar.

1º) Meto en el Content Pipeline un modelo 3D con extensión *.x, aunque he visto que también se pueden incluir modelos *.fbx. ¿Con Blender se pueden realizar tanto los archivos *.x como los archivos *.fbx? (según he leído aquí tiene exportación a FBX, pero si alguien que sepa usar el Blender puede confirmarlo pues mucho mejor)

Por cierto, ¿para usar Blender que versión de python es necesaria?

2º) Por lo que he podido ver, al usar el método CreatePerspectiveFieldOfView en la matriz de proyección estás indicando que únicamente se "pinten" los objetos que están comprendidos entre el near plane y el far plane. Esto me parece bien, lo que no sé si esto es un frustum o no. Yo creo que no.
Por lo que he podido mirar en la MSDN, un frustum lo defines como el producto de las matrices de visión y de proyección, algo como [code:1] Frustum = new BoundingFrustum(m_ViewMatrix * m_ProjectionMatrix); [/code]
Luego calculas los boundingbox de todos los objetos de la escena y miras si estos boundingbox están dentro del frustum. Si es así dibujas el modelo, si no, no lo dibujas
[code:1]
BoundingBox box = new BoundingBox();
foreach(clsTile Tile in CurrMap.TileList) {
if(Tile == null)
continue;
else {
box.Min = Tile.Position;
box.Max = new Vector3(Tile.Model.Position.X + TextureWidth, Tile.Model.Position.Y + 50, Tile.Model.Position.Z + TextureHeight);
}
if(Camera.Frustum.Contains(box) != ContainmentType.Disjoint) {
if(Tile.Walkable == BlockStyle.Walkable){
Tile.Model.Scale.Y = 0.1F;
} else {
Tile.Model.Position.Y = 50;
}
DrawModel(Tile.Model);
}
}[/code]

Esto también me parece correcto, pero aquí me surge una duda. Ese código pinta todos los objetos que están dentro del frustum, pero que ocurre con los objetos no visibles que están dentro del frustum. ¿También los "pinta"? (llamo objeto no visible a por ejemplo un modelo que, estando dentro del frustum, está en otra "habitación", y dicha "habitación", desde la posición actual, no se vé?

Bueno, básicamente esas son mis dos preguntas.

Saludos.

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#18

Escrito 21 febrero 2009 - 18:33

Lo siento Ollydbg,

Pero en 3D con XNA no tengo ninguna experiencia...

Aunque sí te aconsejo que crees otro tema distinto porque aunque éste está relacionado con XNA, no tiene nada que ver con lo que planteas :P.

Un saludo.

#19

Escrito 21 febrero 2009 - 20:59

Yo tengo pensado en hacer uno en 2D, mas que nada para ir sabiendo como va, y luego pasar a 3D

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#20

Escrito 27 febrero 2009 - 13:54

Actualizo por aquí también para que por lo menos se vea que sigo en ello.

Ya está terminada la versión 1.0 del proyecto Anti-Heroe, aquí teneis un enlace por si le quereis echar un vistazo y opinar.

Se ha incluido el uso de la cámara para visualizar la pantalla, el sistema de colisiones y la posibilidad de crear mapas (de momento a pelo con el bloc de notas).

Un saludo.

  • Ellolo17

  • Zodiark

  • vida restante: 100%
  • Registrado: 16 nov 2006
  • Mensajes: 6.208
#21

Escrito 27 febrero 2009 - 14:55

Una pregunta, el menú como lo hiciste? Hay algun tutorial?


Yo en mi motor -DarkBasic, distinto a XNA y a cualquier cosa del visual studio- lo hago de la siguiente manera:

Me creo una imagen que será de fondo.

Me creo un objeto con esa imagen de fondo, un texto y coordenadas de inicio y tamaño.



Antes del menu se crean asi con una funcion todos los botones que no es mas que crear una capa grafica sobre el fondo que puede ser animado, estatico, en 3d, etc...

En el bucle principal del menu en un momento llamo a la funcion de comprobar el raton.
Esa funcion coge la posicion del raton en la pantalla.

Comprueba si el raton esta en la coordenada x de los botones. Y de los que se cumpla eso comprueba si esta en la coordenada y de esos botones -vamos, entre el punto inicial y el punto inicial + tamaño-


Si esta en esas coordenadas se cambia una variable del raton con el numero de boton sobre el que esta, y se hace que ese boton tenga algun efecto grafico si eso.

Y al hacer click en vez de comprobar la posicion, como eso ya lo ha hecho, simplemente hace un select case en funcion del valor de la variable del boton y segun el valor hace una funcion u otra -cargar menu de opciones, iniciar partida, cargar ultima partida, salir...-


En el fondo es mas facil de lo que parece ^^u

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#22

Escrito 03 marzo 2009 - 10:37

Hola de nuevo forer@s,

A la vez que actualizo la información del proyecto, os quería pedir algo de ayuda.

He decidido cambiar el planteamiento del juego, y lo voy a dirigir a crear un mundo persistente con soporte para varios jugadores (estilo WOW).

Por lo que ahora voy a dividir el juego en 2 aplicaciones, por un lado voy a crear un servidor dedicado y por otro los clientes de los jugadores.

Lo que os quería preguntar es si alguno teneis experiencia trabajando con hilos (threads), ¿me podeis recomendar algún tutorial para C# que me pueda servir para ir documentándome?.


La idea es:

- Las aplicaciones cliente tendrán el proceso principal para manejar determinados aspectos de la lógica del juego y un hilo aparte que se encargue de la comunicación con el servidor dedicado.

- El servidor dedicado tendrá un proceso principal que estará a la espera de que le lleguen comunicaciones. Y aquí se me ocurren dos ideas:
a) El proceso principal tiene una lista de los jugadores conectados y cada vez que se conecta un jugador nuevo lo añade a la lista, y un hilo se encarga de actualizar a todos los jugadores conectados.
b) El proceso principal está a la espera de que se conecten jugadores, y crea un hilo por cada jugador para mantener la comunicación con él.

Me gusta más la opción b) por ser el modelo cliente-cervidor típico, pero con muchos jugadores esto podría llegar a ser intratable, ¿no? (lo digo pensando en cambios de contexto a nivel del sistema operativo)

¿Qué opinais de esas dos opciones?, ¿cuál creeis que puede dar mejor rendimiento?.

Un saludo y gracias por adelantado ;).

#23

Escrito 03 marzo 2009 - 14:43

No sé si te será de utilidad pero he encontrado esto:

http://msdn.microsof...ing.thread.aspx

http://basicshabaj.b...reads-in-c.html

  • gothmog_es

  • IGNIS EXCUBITOR

  • vida restante: 100%
  • Registrado: 01 nov 2002
  • Mensajes: 22.690
#24

Escrito 03 marzo 2009 - 19:00

Aquí se comentan algunas cuestiones sobre programación de MMORPG, incluida la que dices. Por desgracia no ahonda demasiado, pero te puede dar una idea:

http://www.devmaster...uilding-mmorpg/

El resto de artículos relacionados con mmorpg también tiene buena pinta:

http://www.devmaster...les.php?catID=7
También he encontrado un libro que trata justamente de MMORPG y XNA. Si puedes encontrarlo tal vez te resultaría de utilidad. A lo mejor si se lo pides a tu tutor/biblioteca lo puedan encargar, aunque supongo que para cuando lo tuvieras en tus manos ya sería demasiado tarde :D

http://www.amazon.co...h/dp/1584505931

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#25

Escrito 03 marzo 2009 - 20:40

Muchas gracias por los aportes a ambos, en serio ^^.

Los que me has puesto NullPointerException los he mirado antes y me están sirviendo mucho, y ahora le echado un vistacillo rápido a los que has puesto gothmog_es y también me vienen muy bien para ver pros y contras de algunas de las opciones por las que he optado (las ventajas y desventajas del multi-threading por ejemplo).

Ahora metiéndole mano al código (al final he optado por el multi-threading) está pintando muy interesante, pero he caído en la cuenta de un problema relacionado con las redes.

Nosotros por ejemplo cuando jugamos a cualquier juego por internet, utilizamos un puerto para la comunicación, el que sea. Lo que me pregunto es, ¿cómo se hace eso?, para mantener varias sesiones con muchas personas, y que todas corran por el mismo puerto..

El problema es el siguiente: si dejo un socket escuchando por un puerto hasta que llega un jugador, y se conecta una persona hasta ahí todo bien. Pero a continuación no voy a poder escuchar por ese mismo puerto a una nueva conexión porque ya lo estoy utilizando..., ¿sabeis cómo resolverán ese problema en este tipo de juegos?

  • The_Hans

  • Ultima

  • vida restante: 100%
  • Registrado: 27 ene 2004
  • Mensajes: 7.490
#26

Escrito 03 marzo 2009 - 20:47

deviax, ¿qué utilizas para grabar vídeo? Yo siempre he usado fraps pero no sé si tengo algo mal en mis códecs o qué carajo pasa pero no me graba nada, sale todo en negro. Voy a probar a reinstalar códecs primero pero me da rabia, quería colgar algún vídeo xDD

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#27

Escrito 03 marzo 2009 - 23:11

deviax, ¿qué utilizas para grabar vídeo? Yo siempre he usado fraps pero no sé si tengo algo mal en mis códecs o qué carajo pasa pero no me graba nada, sale todo en negro. Voy a probar a reinstalar códecs primero pero me da rabia, quería colgar algún vídeo xDD


Hola The_Hans,

Para grabar los vídeos uso el programa CamStudio que es freeware, te permite grabar todo el escritorio, o seleccionar una región de la pantalla y sólo grabar esa parte.

Como el fichero de vídeo que genera ocupa mucho mucho (no sé si lo llegará a comprimir o se quedara en formato RAW), le paso el Total Video Converter y comprimo con DivX a calidad media. No sé si el propio Total Video Converter traerá los codecs, pero yo el codec-pack que siempre tengo instalado es el K-lite.


Por otro lado, respecto a como resolver mi problema, esta tarde/noche se me ha ocurrido una buena idea. Coger un puerto (por ejemplo 5000), y estar escuchando ahí por TCP a que lleguen las conexiones. Cuando llega una conexión creo un nuevo hilo, y ahora en lugar de comunicarme por el puerto 5000 en TCP, cierro esa conexión (así ya puedo recibir nuevas conexiones por ahí) y a partir de ahora se comunicarán por el puerto 5000 (por ejemplo) en UDP. Al ser el UDP un protocolo no orientado a sesiones, con controlar que dos hilos no se comunican en el mismo instante, puedo mantener así las sesiones de varios usuarios.... Finalmente para desconectar uso otra vez TCP por el puerto 5000 (así que tendré que controlar ahí dos comandos, de inicio de sesión, y de cierre de sesión del jugador). Asi que tendría siempre un hilo corriendo escuchando al puerto 5000 de TCP, y luego tantos hilos como jugadores haya conectados que hablarán a través de UDP. Creo que puede funcionar, en fase de pruebas se verá que tal da la talla....

  • Ollydbg

  • Valefor

  • vida restante: 100%
  • Registrado: 05 sep 2008
  • Mensajes: 6.259
#28

Escrito 03 marzo 2009 - 23:39

deviax por experiencia propia te diré el depurar un código que utilice hilos puede ser peor que una tortura china. Además debes tener en cuenta lo siguiente (es posible que ya lo sepas). Es absolutamente necesario el uso de delegados (en el argot se conocen como "punteros seguros") para cualquier modificación del interfaz que se realiza a consecuencia de la acción de un hilo. Te comento esto porque si no has trabajado nunca con hilos puedes pensar que esto es correcto: (en pseudocódigo)
[code:1]Condición X
Iniciar Thread A
En función de la condición X, ejecutar en el hilo A la subrutina B
Subrutina B
[/code]
Si lo haces así, obtendrás una preciosa excepción de Windows. La solución, utilizar delegados
[code:1]Declarar Delegado X
Condicion X
En función de la condición X, inciar el Thread A, pero en vez de ejecutar la subrutina B, has de llamar al Delegado X
El Delegado X crea un "puntero seguro" a la subrutina B
Subrutina B
[/code]

El ejemplo más claro para ver esto es crear un pequeño programa, que conste únicamente de una etiqueta, pongamos un Label1.
Te creas un hilo que cada segundo escriba en esa etiqueta el contenido de un contador (tipo Int Condador; Contador ++;, por ejemplo)
Ya verás que si no utilizas delegados, cuando intentes hacer en la "subrutina B" algo como: Label1.Text = Contador; se provocará una excepción)

Hay multitud de documentación en la MSDN (God Bless MSDN), pero yo antes de intentar meterme en una arquitectura cliente-servidor primero provaría eso, hacer un programa supersimple (sin utilizar sockets ni las clases Using.Net; ni nada) para ir cogiendole el tema a los threads.

Saludos.

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#29

Escrito 04 marzo 2009 - 00:21

Muchas gracias por la información Ollydbg,

Esta mañana he estado leyendo sobre la cantidad de problemas que da el uso de threads ante estas situaciones (lo que me comentas de acceder a variables desde distintos hilos). Y decían exactamente lo que me cuentas, que para solucionar este problema se hace uso de delegados, el único problema que tengo es que nunca he trabajado con ellos (teniendo verdadera idea de como van.., ya que para crear los hilos si no me equivoco estoy haciendo uso de ellos, o para manejar eventos en las interfaces gráficas también).

Primero lo voy a intentar haciendo unos truquillos que he visto en una web, básicamente consisten en definir variables estáticas para que se comparta esa información entre los hilos (de momento en el servidor sólo se tendrán que calcular las coordenadas de los jugadores, así que se trata de un único List que guardará coordenadas para enviarlas y actualizarlas). Y para evitar problemas derivados de la concurrencia, crear una variable auxiliar (también estática) y usarla de semáforo con el método "lock()" (así defines secciones críticas según he leído). Si funciona perfecto, sino como me dices tendré que pegarme con los delegados.

Aun así, como decía antes muchas gracias por la información ^^, ya os comentaré como salió la cosa por si a alguien le interesa la idea.

Un saludo.

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#30

Escrito 09 marzo 2009 - 14:48

Hello again,

Finalmente la idea que comentaba funcionó sin dar problemas de concurrencia.

La idea que he seguido es tener 3 hilos, uno escuchando por un puerto de TCP la conexión de los jugadores, otro hilo para enviar las coordenadas de todos los jugadores a los jugadores (uno por uno) por UDP, y otro para recibir las coordenadas de los jugadores también por UDP.

Los problemas que he observado.., los evidente de UDP, pérdida de paquetes. El resultado de esto es inadmisible para un MMORPG, el servidor le manda al jugador la coordenada 5 por ejemplo, y la siguiente coordenada que le envía es un 45 (vamos, que pierdo 40 actualizaciones). Este problema seguramente sea debido a las secciones críticas con el mutex y al uso de UDP.

Por eso recurro de nuevo a vuestro consejo. Tengo decidido que hay que usar TCP, no puedo permitir que si dos personas están dándose de palos, uno utilice una habilidad y esta no se lance porque no le llega al servidor o al otro jugador... Así que tengo planteadas dos alternativas:

OPCION 1.
Tener un servidor con un solo proceso, que de forma cíclica vaya alternando por todos los jugadores y pidiéndoles lo que han hecho y actualizándoles con lo que han hecho el resto. En pseudo-código:
1. Cojo un jugador
2. Recojo su último movimiento
3. Le mando los movimientos de los demás
4. Cojo el siguiente jugador y voy a 2.
PROBLEMAS DE ESTA OPCION.
Al ser TCP bloqueante, todos los jugadores tendrán que esperar a que un jugador envía y reciba la información y si se queda colgada la conexión del jugador, deja a todo el mundo esperando (esto se puede controlar, pero ya asumimos que se pueden producir retardos). Además de que continuamente está estableciendo y cerrando conexiones, lo que supone una gran pérdida de eficiencia en la comunicación.


OPCION 2.
Tener un servidor con tantos hilos como jugadores. Cada proceso gestiona un único jugador, por lo que está constantemente recogiendo el último movimiento y enviando los movimientos del resto de jugadores.
PROBLEMAS DE ESTA OPCION.
Supone la definición de secciones críticas de código y su control para evitar la concurrencia (ya que todos los hilos accederán a la misma estructura de jugadores para comprobar las coordenadas del resto). Y al establecer secciones críticas ya se está bloqueando a los otros jugadores hasta que uno termine, además de que lo hace sin ningún orden y un jugador podría tener peor conexión que otro (esto se puede controlar introduciendo otro hilo que controle los turnos de los jugadores, pero ya supone perder velocidad de proceso).


¿Qué opinais de las opciones?, ¿os decidiríais por alguna?, ¿optarías por otra solución?

Una vez más lo siento por la extensión, pero es que quiero que veais con todo detalle los problemas que yo veo por si alguno tuviera ideas concretas para evitarlos..

Como siempre, muchas gracias por adelantado ;).


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
publicidad
publicidad