Proyecto fin de carrera xna

[kiko_L]

Hola a todos, primero decir que este tema no sé muy bien donde ponerlo: es un trabajo en proceso, pero no de modelado, ni animación, podría ponerlo en videojuegos, pero no es un videojuego exactamente, es más bien una aplicación.

Me explico mejor: hace un tiempo dejé el proyecto fin de Carrera (curro + proyecto de = aburrimiento y fracaso) así que, me he decidido a empezar otro en algo más divertido.

Se trata de programar una aplicación en XNA (entorno de desarrollo en c# para programar en DirectX (http://es.wikipedia.org/wiki/microsoft_xna)), en la cual cargaré una escena creada en 3d Studio Max (una habitación) y la cual podré recorrer con el mando de la Wii conectado a mi ordenador.

Dado que mucha gente hace la típica pregunta quiero hacer un juego ¿cómo se hace? He pensado que está podría ser una buena oportunidad para que la gente se inicie en la programación de juegos o aplicaciones 3d.

Espero que a la gente le interese y poder así ir explicando los pasos que voy dando (creación de cámaras, carga de escenas, iluminación, etc.)
Edito: se me olvidaba comentar que también se pueden programar juegos y aplicaciones para la Xbox 360. Un saludo a todos.

-- IMÁGENES ADJUNTAS --

[a caramecha]

Adelante te sigo.

[Rompecabezas]

Yo también me apunto a seguir el hilo que seguro que hay muchas cosas interesantes que, aprender. Coño y además de Pamplona, eso hay que verlo.

[kiko_L]

Gracias a los dos. Aún no sé muy bien como enfocarlo. No sé si ir poniendo avances que consiga o hacer un minitutorial, o una mezcla de las dos. Aún estoy verde porque estoy aprendiendo, pero creo que no es mala idea ir poniendo aquí lo que voy aprendiendo a modo de repaso. Saludos.

[Sadyk]

Yo iría subiendo avances explicándolos y resolviendo las dudas. Seguiré el hilo, me parece muy interesante el tema de XNA, pues tengo un manual, pero no me decido a empezarlo, porque no se c#.

Pero algún día lo empezaré (por algo me gaste los 30 euros).

Lo que me ha llamado la atención es lo del mando de la Wii, como lo piensas hacer? Me parece muy interesante.

[Hulkong]

Suerte, tienes al público expectante.

[kiko_L]

Yo iría subiendo avances explicándolos y resolviendo las dudas. Seguiré el hilo, me parece muy interesante el tema de XNA, pues tengo un manual, pero no me decido a empezarlo, porque no se c#.

Pero algún día lo empezaré (por algo me gaste los 30 euros).

Lo que me ha llamado la atención es lo del mando de la Wii, como lo piensas hacer? Me parece muy interesante.

Existe una librería preparada para usar el mando de la Wii, y lo primero que hice fue cerciorarme que era compatible con XNA. He visto que hay algún ejemplo hecho por la red, aunque la verdad que no son muchos. Estoy esperando a que me llegue un conector bluetooth que compré para empezar a probar.

Mañana espero poner un poco de teoría básica de cómo es un programa sencillo en XNA. Saludos y gracias.

[kiko_L]

Bueno venga, voy a empezar con lo básico, los requisitos:
* visual c# express edition (gratuito con un simple registro): http://www.Microsoft.com/express/dow...2008-visual-cs (si tenéis la versión profesional perfecto, pero con la express funciona perfectamente).
* XNA game Studio 3.1 (también gratuito): http://www.Microsoft.com/downloads/d...displaylang=en.

Simplemente con estos dos instaladores tendríamos todo lo necesario para empezar a hacer nuestros juegos.

Os pongo también unos enlaces de interés:
* desarrollo dirigido a Xbox 360: http://www.xbox.com/en-us/dev/regdev.htm.
* comunidad XNA: http://creators.XNA.com/en-us/.
* blog sobre XNA: http://aprendiendoxna.wordpress.com/.

Libro sobre XNA:
* learning XNA 3.0 (oreilly) :http://oreilly.com/catalog/9780596521967 (lo estoy leyendo y es muy interesante).

[kiko_L]

Lección 1 tSi no se tienen nociones de programación es mejor comenzar con lo básico. Aquí voy a dar por sabidas muchas cosas en cuestión de programación, como, por ejemplo, qué es una clase, herencia, qué es un método, paso de parámetros, etc.

Vamos a crear nuestra primera aplicación XNA (un juego, aunque no tenga nada). Para ello iniciamos Visual Studio y creamos un nuevo proyecto tipo Windows game (Como se muestra en la primera imagen). Le ponemos el nombre que queramos.

Vamos a ver qué pasa cuando compilamos el programa (Build--> Generar Solución o Ctrl+Shift+B) y lo ejecutamos (Debug--> Iniciar Depuracción o F5). (Se adjuntan dos imágenes).

Lo que obtenemos lo vemos en la 4ª imagen. Es una simple pantalla azul, pero en esencia eso es nuestro primer juego en XNA.

Mañana explicaré la estructura básica del programa (que al final siempre es la misma). Un saludo.

-- IMÁGENES ADJUNTAS --

[kiko_L]

Sigamos con las lecciones:

using system. Using system. Collections. Generic.

Using system. Linq.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Audio.

Using Microsoft.XNA. Framework. Content.

Using Microsoft.XNA. Framework. Gamerservices.

Using Microsoft.XNA. Framework. Graphics.

Using Microsoft.XNA. Framework. Input.

Using Microsoft.XNA. Framework. Media.

Using Microsoft.XNA. Framework. Net.

Using Microsoft.XNA. Framework. Storage.

Namespace miprimerprogramaxna.
{.
/// <summary>.
/// this is the main type for your game.
/// </summary>.

Public class game1 : Microsoft.XNA. Framework. Game.
{.

Graphicsdevicemanager graphics.

Spritebatch spritebatch.

Public game1().
{.

Graphics = new graphicsdevicemanager(this).

Content. Rotdirectory = content.
}.
/// <summary>.
/// allows the game todo Perform any initialization it neds todo before starting todo run.
/// this is where it can query for any required services and load any non-graphic.
/// related content. Calling base. Initialize Will enumerate th rouge any components.
/// and initialize them as well.
/// </summary>.

Protected override Void initialize ().
{.
// todo: add your initialization logic here.

Base. Initialize ().
}.
/// <summary>.
/// loadcontent Will be called once per game and is the place todo load.
/// all of your content.
/// </summary>.

Protected override Void loadcontent().
{.
// create a new spritebatch, which can be used todo draw textures.

Spritebatch = new spritebatch(graphicsdevice).
// todo: use this. Content todo load your game content here.
}.
/// <summary>.
/// unloadcontent Will be called once per game and is the place todo unload.
/// all content.
/// </summary>.

Protected override Void unloadcontent().
{.
// todo: unload any non contentmanager content here.
}.
/// <summary>.
/// allows the game todo run logic such as updating the world.
/// checking for Collisions, Gathering input, and playing audio.
/// </summary>.
/// <param name=gametime>provides a snapshot of timing values.</param>.

Protected override Void update (gametime gametime).
{.
// allows the game todo exit.

If (gamepad. Getstate (playerindex. One). Buttons. Bak == buttonstate. Pressed).

This. Exit().
// todo: add your update logic here.

Base. Update (gametime).
}.
/// <summary>.
/// this is called when the game should draw itself.
/// </summary>.
/// <param name=gametime>provides a snapshot of timing values.</param>.

Protected override Void draw(gametime gametime).
{.

Graphicsdevice. Clear(color. Cornflowerblue).
// todo: add your drawing code here.

Base. Draw(gametime).
}.
}.
}

.

Nuestra clase principal tendrá esta forma. En ella se disitinguen varios elementos clave:
Variables:
* graphicsdevicemanager graphics: este objeto representa el dispositivo gráfico actual de nuestro ordenador. Se podría decir que va a hacer de puente entre nuestra aplicación y la GPU de nuestra tarjeta gráfica. Es vital por todo lo que hagamos en nuestra pantalla va a pasar por este objeto.
* spritebatch spritebatch: este objeto lo usaremos a la hora de dibujar un sprite (se considera sprite a cualquier imagen 2d o 3d integrado en una escena. Un juego en 2d, por ejemplo, se hará mediante la inclusión de varios sprites (enemigos, fondos, etc.)).

Métodos:
* initialize (): en este método podremos inicializar cualquier variable que utilicemos en nuestro programa.
* loadcontent(): se utiliza para cargar el contenido que vayamos a utilizar en nuestro programa (texturas, objetos 3d, etc).
* unloadcontent(): tiene el efecto contrario. Descargar y liberar todos los recursos obtenidos por el programa.
* update (gametime gametime): este método es uno de los más importantes, en el definiremos que queremos que pase cuando se actualice el estado de ciertas variables. Por ejemplo, si queremos implementar una cámara que cuando pulsemos la tecla w se mueva hacia adelante, tendremos que definir en el método update dicha transformación (cómo cambia la cámara para que se mueva).

Vemos que en nuestro ejemplo el programa comprueba en dicho método si el pad de la Xbox está conectado y a continuación vuelve a llamarse a sí mismo (con esto concluimos que el programa no es otra cosa que un bucle infinito que espera a que se produzcan eventos como una tecla pulsada para cambiar su estado).

Se observa también que existe una variable llamada gametime ¿Qué hace esta variable? Pues nos indica el tiempo que ha pasado desde que ha comenzado a ejecutarse el programa ¿y para qué? Para determinar cuando deben pasar las animaciones, etc ya que los ordenadores no siempre tienen la misma velocidad y aplicaciones que en un ordenador van bien en otros podrían ir muy rápido o muy despacio.
* draw(gametime gametime): este es el método que se va a encargar de dibujar nuestros objetos en la pantalla.

Siempre se suele intentar que el método draw sea únicamente el que cargue los objetos, texturas, y que la lógica del programa ocurra en los métodos update de las diferentes clases. Y aquí llegamos a otro punto:
¿Cuántos métodos update se tienen?
Pues pueden ser muchos, uno por clase que creemos. En ocasiones necesitaremos que hagan algo, en otras no. Todo depende de cómo organicemos nuestro código. Veremos esto más adelante.

[kiko_L]

Os pongo una captura de pantalla de un juego programado en XNA (y descargable desde aquí http://exdream.com/xnaracinggame/). El juego es totalmente configurable (conocimientos de XNA) para añadir lo que deseemos (coches nuevos, texturas diferentes, niveles, etc).

Como veis la potencia de XNA es mucha, toda la que vuestro conocimiento os vaya dando. Las posibilidades son infinitas (Shaders, física, colisiones, etc.

-- IMÁGENES ADJUNTAS --

[kiko_L]

Y por último hoy, os dejo un video de una aplicación que hice la semana pasada. Simplemente es la carga de un objeto 3d que hice con 3d Studio Max (y colgué por aquí hace cosa de año y pico) y una cámara libre con la que movernos por la escena.

Espero que el video se vea bien, si no se ve lo cambio.

-- IMÁGENES ADJUNTAS --

[krateos_29]

Parece interesante el proyecto. Le tendré reservado un ojo.

[wurthkiller]

Me parece un tema cojo, apasionante, buen hilo. Estaré atento, aunque por lo poco que he leído veo que esto de la programación se me queda un poco grande (o eso, o es pereza que no sé qué es peor). Pero voy a seguir el hilo con mucho interés, a ver si consigo hacer algo fuera del agro3d.

Mis felicitaciones, es un gran hilo. Un saludo.

Posdata: van 5 estrellas.

[emguepo]

Muy interesante, estaré pendiente de esto, aunque como dicen por ahí esto de la programación me queda un poco grande (o eso, o es pereza que no sé qué es peor. Saludos, excelente hilo.

[kiko_L]

Gracias a todos. Yo que ando metido en los dos mundos (3d y programación) os digo que requiere mucha menos paciencia la programación. Otra cosa es que, al ser menos visual pueda dar mucha más pereza. Pero la gracia del XNA es que podéis combinar ambos mundos.
Ánimo a todos y muchas gracias.

[kiko_L]

Hola a todos, hoy os voy a explicar algún avance que he hecho. Por fin me ha llegado el receptor bluetooth directamente de China. (1,5EUR y sin gastos de envío).

Llevo toda la tarde peleándome con la librería de la Wii, pero por fin he conseguido que funcione. El problema es que el mando parece que está sin calibrar y tiembla bastante para todos los lados, pero he conseguido mover una imagen en 2d por la pantalla. Cuando avance un poco más en las lecciones me meteré con el tema de la wi. Saludos.

[kiko_L]

Creo que deberíamos empezar por el 2d antes de pasar al 3d. Por ello en estos días iré subiendo y explicando el código para hacer un pong sencillo:
Para ello vamos a empezar con el programa que creamos (miprimerprogramaxna).

Antes de empezar a programar debemos crear nuestros elementos gráficos. Para ello voy a crear una imagen que hará de escenario y otras dos que harán de jugadores. También crearemos la pelota.

Una vez creadas las cargamos de la siguiente forma:
En el explorador de soluciones (ver imagen 5) hacemos botón derecho en content y añadimos una nueva carpeta, por ejemplo, imágenes. A continuación hacemos click derecho sobre dicha carpeta y añadimos un elemento existente. Seleccionamos las imágenes a cargar (jugadores, etc.) y aceptamos. Veremos que se han cargado todas las imágenes que vamos a utilizar.

Mañana prometo seguir con el ejemplo. Saludos.

-- IMÁGENES ADJUNTAS --

[Sadyk]

Muy guapo el tutorial, sigue, sigue. Pero no te olvides de tu juego.

[iherrero20]

Muy interesante Kiko, la programación es un escollo que quiero superar, tengo bastantes nociones, pero siempre hay tiempo para aprender.

[Xtreme637]

Gran iniciativa Kiko. Seguiré este hilo muy de cerca. Un saludo.

[Mars Attacks]

Un hilo interesante. Como petición personal, no escatimes en poner enlaces a referencias donde tú mismo hayas ido a consultar información (cómo usar el mando de la Wii en el PC, por ejemplo).

[franchute25]

Ese tío ahí, dándole caña, que guapo las cosas que haces tío.

[kiko_L]

Gracias a todos por los comentarios. Mars, tienes razón. Iré poniendo enlaces a las páginas que consulto. Pero primero voy a seguir con el pong que este fin de semana no he podido hacer nada.

En internet hay bastantes ejemplos de cómo implementar un pong en XNA, pero yo voy a utilizar mi propio método.

Antes de ponerse a programar y después de tener los elementos que saldrán en nuestra pantalla vamos a pensar un poco la estructura de nuestro programa.

La famosa frase de divide y vencerás tiene su máxima expresión en la programación, por ello vamos a dividir nuestro programa en varias clases de manera que, todo sea más sencillo de programar y entender.

[kiko_L]

Por tanto, para nuestro programa vamos a tener varias clases que paso a explicar:
1.- Sprite, CS -> esta clase va a ser la más básica. Es decir, va a ser la encargada de definir los parámetros básicos de nuestros sprites (elementos gráficos) de nuestro juego. En ella definiremos, entre otras cosas, los rectángulos de colisión de nuestros objetos. Estos rectángulos se usan para que el programa sepa cuando cierto elemento ha chocado contra otro.
2.- Spritemanager, CS -> esta clase se encargara de cargar los sprites en la escena y de dibujarlos (que no es lo mismo. Una cosa es cargar en memoria los objetos y otros dibujarlos en nuestra escena).
3.- Jugador, CS -> como os podéis imaginar esta clase será la que defina las propiedades del jugador (con que teclas se mueve, etc).
4.- Cpu.cs -> lo mismo que la anterior, pero para definir al ordenador o jugador 2.
5.- Pelota, CS -> definira el comportamiento de la pelota.

[Rompecabezas]

Esto está que arde, 5 stars, a ver si soy capaz de seguir las instrucciones.

[kiko_L]

Hola a todos. Ayer empecé el pong (aún no lo tenía hecho) y hoy ya lo he terminado así que, voy a empezar a explicarlo. Se podría haber hecho de una forma más sencilla, pero creo que así podré explicar algunos detalles de programación como las clases abstractas, herencia, que vienen muy bien. Antes que nada os pongo un enlace a un curso de c# que es muy completo: http://www.programación.com/tutorial/csharp/1/.

[kiko_L]

En este ejemplo veremos:
* creación de sprites.
* herencia y clases abstractas.
* colisiónes. Os pongo la imagen de cómo quedará al final nuestra solución.

Observareis que las imágenes de los jugadores 1 y 2 no tienen espacio ahora. Modificad las que subí el otro día (realmente no importa que tengan espacios en el nombre, pero por si acaso los quité.

-- IMÁGENES ADJUNTAS --

[kiko_L]

Empecemos por lo básico:
* Clase Principal (Program, cs):
using System;.

Namespace MiPrimerProgramaXNA.
{.

Static class Program.
{.
/// <summary>.
/// The main entry point for the application.
/// </summary>.

Static void Main(string[] args).
{.

Using (Game1 game = new Game1()).
{.

Game. Run();.
}.
}.
}.
}.
Ésta es nuestra clase principal. No tenemos que preocuparnos por ella ya que es el propio Visual Studio la qué la crea por nosotros.
Ésta clase es simplemente el punto de entrada (donde empieza la ejecución) de nuestro programa. Como veis lo único que hace en su método principal (Main) es crear una nueva instancia de la clase Game1 (que explicaré a continuación) y llamar al método Run().
* Clase Principal (Game1.cs):
using System;.

Using System. Collections. Generic;.

Using System. Linq;.

Using Microsoft.Xna. Framework;.

Using Microsoft.Xna. Framework. Audio;.

Using Microsoft.Xna. Framework. Content;.

Using Microsoft.Xna. Framework. GamerServices;.

Using Microsoft.Xna. Framework. Graphics;.

Using Microsoft.Xna. Framework. Input;.

Using Microsoft.Xna. Framework. Media;.

Using Microsoft.Xna. Framework. Net;.

Using Microsoft.Xna. Framework. Storage;.

Namespace MiPrimerProgramaXNA.
{.
/// <summary>.
/// This is the main type for your game.
/// </summary>.

Public class game1 : Microsoft.Xna. Framework. Game.
{.

GraphicsDeviceManager graphics;.

SpriteManager spriteManager;.

Public Game1().
{.

Graphics = new GraphicsDeviceManager(this);.

Content. RotDirectory = Content";.
}.
/// <summary>.
/// Allows the game to perform any initialization it neds to before starting to run.
/// This is where it can query for any required services and load any non-graphic.
/// related content. Calling base. Initialize will enumerate th rouge any components.
/// and initialize them as well.
/// </summary>.

Protected override void Initialize().
{.
// TODO: Add your initialization logic here.

SpriteManager = new SpriteManager(this);.

Components. Add(spriteManager);.

Base. Initialize();.
}.
/// <summary>.
/// LoadContent will be called once per game and is the place to load.
/// all of your content.
/// </summary>.

Protected override void LoadContent().
{.
// Create a new SpriteBatch, which can be used to draw textures.
// TODO: use this. Content to load your game content here.
}.
/// <summary>.
/// UnloadContent will be called once per game and is the place to unload.
/// all content.
/// </summary>.

Protected override void UnloadContent().
{.
// TODO: Unload any non ContentManager content here.
}.
/// <summary>.
/// Allows the game to run logic such as updating the world.
/// checking for collisions, Gathering input, and playing audio.
/// </summary>.
/// <param name="gameTime">Provides a snapshot of timing values.</param>.

Protected override void Update(GameTime gameTime).
{.
// Allows the game to exit.

If (GamePad. GetState(PlayerIndex. One). Buttons. Bak == ButtonState. Pressed).

This. Exit();.
// TODO: Add your update logic here.

Base. Update(gameTime);.
}.
/// <summary>.
/// This is called when the game should draw itself.
/// </summary>.
/// <param name="gameTime">Provides a snapshot of timing values.</param>.

Protected override void Draw(GameTime gameTime).
{.

GraphicsDevice. Clear(Color.White);.
// TODO: Add your drawing code here.

Base. Draw(gameTime);.
}.
}.
}.

La mayoría de esta clase se define también por defecto al crear el proyecto.
Ésta clase tiene algo más de chicha (pero tampoco mucha). La primera parte (using), carga las librerías (lo hace el visual por defecto).

A continuación definimos dos variables que van a ser cruciales para nuestro programa, la primera ya la he explicado anteriormente y la otra la explicaré más adelante tGraphicsDeviceManager graphics;.

SpriteManager spriteManager;.

En el constructor (public Game1 ()) asignamos nuestro graphicDeviceManager a la propia variable graphics. Como veis utiliza la palabra reservada this. Esta palabra.

Se usa mucho en la programación orientada a objetos y lo que quiere decir es que le asignamos a una variable el valor que tiene en dicha clase. Para explicarlo.

Mejor pongo el ejemplo que veis en el método Initialize():
spriteManager = new SpriteManager(this);.

La variable spriteManager ya ha sido declarada anteriormente, pero no ha sido inicializada a ningún valor (digamos que está vacía). Por eso creamos una nueva instancia del tipo SpriteManager (a la qué pertenece la variable que hemos creado (spriteManager)) con su constructor. Este constructor tiene como parámetro una variable de tipo spriteManager y como queremos que tenga el valor actual le pasamos el parámetro actual (this). Sé que parece un poco caótico, pero más adelante se entenderá mejor.

Sigamos.
Components. Add(spriteManager); --> Añade a la clase de sistema Components el spriteManager que hemos creado.
base. Initialize(); --> Llama al propio método para inicializar (lo hace de forma recursiva, pero esto no nos debe preocupar por ahora. Aunque está línea es necesaria).

La carga del contenido (LoadContent()) se va a hacer a través de la clase SpriteManager y que explicaré a continuación (y por eso esta vacía en esta clase).

En el método Update() se llama a base. Update(gameTime) de forma parecida a cómo se hace base. Initialize() (Lo mismo, muy necesaria). Además, se añade una condición que dice que si tenemos el mando de la XBox o compatible y pulsamos la tecla Back el juego se cerrara.

En el método Draw se define el color de fondo y otra vez se llama recursivamente al método Draw (base. Draw(gameTime)).

Antes de seguir os voy a subir el código. Así podéis ir trasteando sin tener que esperar a qué explique todo (que puedo tardar aún unos días). Aún puede que tenga cosas que sobran, porque no he podido revisarlo a fondo, pero la cuestión es que funciona. Eso sí, es difícil de ganar porque el jodido ordenador es casi perfecto. Cuando hagamos mejoras incluiremos niveles de dificultad

-- IMÁGENES ADJUNTAS --

[kiko_L]

Bien, sigamos. Hemos dicho que se crea una clase llamada spritemanager. Bien, pues aquí está:
using system. Using system. Collections. Generic.

Using system. Linq.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Audio.

Using Microsoft.XNA. Framework. Content.

Using Microsoft.XNA. Framework. Gamerservices.

Using Microsoft.XNA. Framework. Graphics.

Using Microsoft.XNA. Framework. Input.

Using Microsoft.XNA. Framework. Media.

Using Microsoft.XNA. Framework. Net.

Using Microsoft.XNA. Framework. Storage.

Namespace miprimerprogramaxna.
{.
/// <summary>.
/// this is a game component that implements iupdateable.
/// </summary>.
///.

Public class spritemanager : Microsoft.XNA. Framework. Drawablegamecomponent.
{.

Spritebatch spritebatch.

Jugador player.

Pelota pelota.

Cpu CPU.

Texture2d textura.

Public spritemanager(game game).
: base (game).
{.
// todo: construct any child components here.
}.
/// <summary>.
/// allows the game component todo Perform any initialization it neds todo before starting.
/// todo run. This is where it can query for any required services and load content.
/// </summary>.

Public override Void initialize ().
{.
// todo: add your initialization code here.

Textura = game. Content. Load<texture2d>(@imágenes\escenario).

Base. Initialize ().
}.

Protected override Void loadcontent().
{.

Spritebatch = new spritebatch(game. Graphicsdevice).

Player = new jugador(.

Game. Content. Load<texture2d>(@imágenes/jugador1).

New vector2(20,300), new point(10, 60), 1, new point(0, 0).

New point(6, new vector2(6, 6)).

Cpu = new CPU (.

Game. Content. Load<texture2d>(@imágenes/jugador2).

New vector2(780, 300), new point(10, 60), 1, new point(0, 300).

New point(6, new vector2(0,6), this).

Pelota = new pelota (.

Game. Content. Load<texture2d>(@imágenes/pelota).

New vector2(400, 300), new point(18, 1, 1, new point(400, 300).

New point(6, new vector2(6,6), this, player, cpu).

Base. Loadcontent().
}.
/// <summary>.
/// allows the game component todo update itself.
/// </summary>.
/// <param name=gametime>provides a snapshot of timing values.</param>.

Public override Void update (gametime gametime).
{.
// update player, CPU y pelota.

Player. Update (gametime, game.window. Clientbounds).

Pelota. Update (gametime, game.window. Clientbounds).

Cpu. Update (gametime, game.window. Clientbounds).

Base. Update (gametime).
}.

Public override Void draw(gametime gametime).
{.

Spritebatch. Begin(spriteblendmode. Alphablend.

Spritesortmode. Backtofront, savestatemode. None).
// dibujamos el jugador, CPU y pelota.

Player. Draw(gametime, spritebatch).

Cpu. Draw(gametime, spritebatch).

Pelota. Draw(gametime, spritebatch).
//dibujamos escenario.

Spritebatch. Draw(textura, new vector2((800 / 2) - (textura.width / 2).
(600 / 2) - (textura. Height / 2)).

Null,color.white, 0, vector2. Zero, 1,spriteeffects. None, 1).

Spritebatch. End().

Base. Draw(gametime).
}.

Public vector2 posicionpelota ().
{.

Return pelota. Getposition.
}.
}.
}.
.
¿Qué va a hacer esta clase?
Esta clase se va a encargar de gestionar los sprites (en nuestro caso jugador1 (player), jugador CPU (cpu) y la pelota (pelota)), es decir, los va a crear.

Cargar, dibujar en la escena y llamar a sus métodos update que nos dirán que hacer si algo cambia en dichos sprites.

Ahora veamos la estructura:
Declaración de variables tspritebatch spritebatch; -> clase de sistema encargada de dibujar los sprites en pantalla.

Jugador player; -> nuestro jugador.

Pelota pelota; -> pelota.

Cpu cpu; -> jugador CPU.

Texture2d textura; -> textura2d usada para cargar el escenario.

Tanto player, pelota como CPU pertenecen a clases (jugador, pelota y cpu) que heredan de una clase llamada sprite.

Creo que voy a explicar en que consiste la herencia, aunque su propio nombre lo indica. Supongamos que tenemos una clase persona que tiene un método edad que nos.

Devuelve la edad de una persona. Supongamos también que dicha clase persona tiene las variables edad, nombre y apellido.

Ahora imaginemos que queremos hacer una nueva clase que se llama jugador. Queremos que esa clase tenga las variables edad, nombre y apellido y además altura. No tendría mucho.

Sentido crearse esta clase con todas sus variables (edad, nombre, etc), cuando ya tenemos la clase persona que implementa la mayoría. Por eso definimos la clase.

Jugador como una clase que hereda de persona y por tanto podremos acceder a todos sus métodos y variables y añadir nuevas que serán propias de la clase jugador.

Más adelante lo veremos mejor.

En la parte de inicialización simplemente vamos a darle valor a la variable textura:
Textura = game. Content. Load<texture2d>(@imágenes\escenario).

Para ello utilizamos game. Content. Load<tipoarchivo>(@localización). En tipoarchivo se podrán cargar muchos tipos de objeto como veremos en lecciones sucesivas.

Llegamos a la parte de carga de contenido:
Spritebatch = new spritebatch(game. Graphicsdevice).

Player = new jugador(.

Game. Content. Load<texture2d>(@imágenes/jugador1).

New vector2(20,300), new point(10, 60), 1, new point(0, 0).

New point(6, new vector2(6, 6)).

Cpu = new CPU (.

Game. Content. Load<texture2d>(@imágenes/jugador2).

New vector2(780, 300), new point(10, 60), 1, new point(0, 300).

New point(6, new vector2(0,6), this).

Pelota = new pelota (.

Game. Content. Load<texture2d>(@imágenes/pelota).

New vector2(400, 300), new point(18, 1, 1, new point(400, 300).

New point(6, new vector2(6,6), this, player, cpu).

Base. Loadcontent().

Aquí lo que hacemos es darle valor a spritebatch que nos servirá en el método draw para dibujar los sprites. Además, vamos a crear una instancia de nuestros elementos.
(Player, CPU, pelota). Los parámetros que le pasamos al constructor los veremos cuando desbrocemos la clase sprite. Aquí nos basta con quedarnos con el concepto de que.

Estamos creando e inicializando nuestros elementos gráficos.

A continuación llamamos a los métodos update de cada uno de los sprites. A simple vista parece un poco raro llamar a todo a la vez, parece un poco caótico, pero.

Estos métodos se quedarán a la espera de eventos que vengan del ratón, teclado, etc. Esto es más eficiente que estar continuamente preguntando al ratón si se ha movido.
(Más conocido como técnica polling (no es coña http://es.wikipedia.org/wiki/polling)).

Una vez que nuestros sprites están funcionando vamos a dibujarlos en la pantalla. Para ello utilizamos el método draw spritebatch. Begin(spriteblendmode. Alphablend,spritesortmode. Backtofront, savestatemode. None), -> le decimos a la variable spritebatch de que forma queremos que gestione los sprites (qué se ve encima de qué, si algún elemento se ve transparente, etc).
// dibujamos el jugador, CPU y pelota.

Player. Draw(gametime, spritebatch).

Cpu. Draw(gametime, spritebatch).

Pelota. Draw(gametime, spritebatch).
//dibujamos escenario.

Spritebatch. Draw(textura, new vector2((800 / 2) - (textura.width / 2).
(600 / 2) - (textura. Height / 2)).

Null,color.white, 0, vector2. Zero, 1,spriteeffects. None, 1).

Spritebatch. End().

Base. Draw(gametime).

Mañana sigo trasteando y explicando código señor@s, un saludo.

[kiko_L]

Hola a todos. Hoy he estado trasteando un poco más con el mando de la Wii y he conseguido manejar el pong con el mando. Os explicaré más adelante cómo hacerlo porque es muy sencillo.

Os dejo el código y varios enlaces para instalar el mando en el ordenador:
Librería para utilizar la Wii en nuestras aplicaciones: http://www.brianpek.com/blog/pages/wimotelib.aspx. http://www.codeplex.com/wimotelib.

Como conectar el mando al PC: http://wiki.truevisión3d.com/tutoria..._tv3d_projects. http://www.taringa.net/mensajes/ebok...ote-en-pc.html.

Básicamente hay que tener un receptor bluetooth (yo me compre uno por dealextreme por 1 euro y medio), conectarlo al USB, ir al panel de control y en dispositivos bluetooth darle a añadir uno nuevo. Mantened apretados los botones 1 y 2 del mando a la vez mientras busca el dispositivo, luego nos saldrá el mando y nos pedirá una clave (elegir la última opción (sin clave)), y le damos a siguiente. Durante todo este proceso no soltamos los botones 1 y 2 (ni siquiera cuando nos pide clave), ya que si no no funcionara.

Hoy me voy a tomar un descanso en la explicación de código que estoy bastante petado.

Pero mañana prometo seguir. Saludos.

-- IMÁGENES ADJUNTAS --

[kiko_L]

Bueno, sigamos con la lección: Voy a hablaros ahora de las clases que heredan de sprite.
* clase cpu:
using system.

Using system. Collections. Generic.

Using system. Linq.

Using system. Text.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Graphics.

Namespace miprimerprogramaxna.
{.

Class CPU : sprite.
{.

Vector2 vecpelota.

Spritemanager spritemanager.

Public CPU (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameact, point shetsize, vector2 velocidad,spritemanager spritemanager2).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad).
{.

Spritemanager = spritemanager2.
}.

Public CPU (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameact, point shetsize, vector2 velocidad.

Int millisecondsperframe, spritemanager spritemanager2).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad, millisecondsperframe).
{.

Spritemanager = spritemanager2.
}.

Public override vector2 dirección.
{.

Get { return velocidad; }.
}.

Public override Void update (gametime gametime, rectangle clientbounds).
{.

Posición += dirección.

Vecpelota = spritemanager. Posicionpelota ().

Posición. Y = vecpelota. Y.

If (posición.x < 0).

Posición.x = 0.

If (posición. Y < 0).

Posición. Y = 0.

If (posición.x > clientbounds.width - Tamframe.x).

Posición.x = clientbounds.width - Tamframe.x.

If (posición. Y > clientbounds. Height - Tamframe. Y).

Posición. Y = clientbounds. Height - Tamframe. Y.

Base. Update (gametime, clientbounds).
}.
}.
}.
.

Lo primero que observamos es que después de class CPU tenemos dos puntos y sprite.
class CPU : sprite.

Con esto estamos diciendo que la clase CPU hereda de la clase sprite. Digamos que es una ampliación de dicha clase.

Declaramos dos variables:
vector2 vecpelota.

Spritemanager spritemanager;.

Vecpelota va a ser una Vector x, y que nos va a indicar la posición en la que se encuentra la pelota. Esto lo vamos a usar para que el jugador CPU se mueva sólo en función de las y de la pelota.

El spritemanager lo usaremos para poder usar métodos que tenemos definidos en la clase spritemanager. Básicamente para conocer la posición de la pelota.

A continuación vienen los constructores. Vemos que hay dos, con diferentes parámetros de entrada, es lo que se conoce como sobrecarga de métodos (ya que al fin y al cabo, un constructor es también un método). Es decir, podríamos tener dos métodos suma cada uno con diferentes parámetros (por ejemplo, suma (numero1, numero2) y suma (numero1, numero2, numero3)). Los constructores los explicaré más adelante.

El siguiente paso es definir el atributo público llamado dirección que es de tipo vector2 y que como veis tiene la palabra reservada override en su declaración. Esto quiere decir que está sobrescribiendo un atributo abstracto que hemos creado en su clase base, que en este caso es la clase sprite. Por tanto estamos re-definiendo el atributo, para que haga más cosas de las que hace en la clase base.
public override vector2 dirección.
{.

Get { return velocidad; }.
}.

El atributo devuelve la variable velocidad (definida en el constructor de la clase sprite) y que, como bien indica el nombre, devuelve la velocidad a la que se mueve el sprite. Con esto podremos modificar la velocidad de la pelota, por ejemplo, (lo veremos).

Lo siguiente es ya le método update propio de la clase CPU.
// sumamos a la posición actual del sprite la dirección (velocidad) obtenida.
posición += dirección;.
//llamamos al método posicionpelota () de la clase spritemanager y lo guardamos en el vector2d vecpelota.
vecpelota = spritemanager. Posicionpelota (),.
//asignamos a la posición actual en el eje y la posición de la pelota en el eje // y. Con esto vemos que el ordenador se mueve en la misma posición y que.
// la pelota. Podríamos multiplicar por un valor aleatorio que le de cierta //estupidez a la máquina. O jugar con diferentes niveles de dificultad.
posición. Y = vecpelota. Y; .
// aquí controlamos que la posición x e y del sprite no se salga de la pantalla.
// así evitamos que el sprite desaparezca por arriba, abajo o los lados.
if (posición.x < 0).

Posición.x = 0.

If (posición. Y < 0).

Posición. Y = 0.

If (posición.x > clientbounds.width - Tamframe.x).

Posición.x = clientbounds.width - Tamframe.x.

If (posición. Y > clientbounds. Height - Tamframe. Y).

Posición. Y = clientbounds. Height - Tamframe. Y;.

Hasta aquí la clase CPU.

[kiko_L]

Sigamos. Clase jugador:
using system. Using system. Collections. Generic. Using system. Linq. Using system. Text.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Graphics.

Using Microsoft.XNA. Framework. Input.

Namespace miprimerprogramaxna.
{.

Class jugador : sprite.
{.

Public jugador(texture2d teximagen, vector2 posición.

Microsoft.XNA. Framework. Point tamframe, int offsetcolisión, Microsoft.XNA. Framework. Point frameact, Microsoft.XNA. Framework. Point shetsize.

Vector2 velocidad).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad).
{.
}.

Public jugador(texture2d teximagen, vector2 posición.

Microsoft.XNA. Framework. Point tamframe, int offsetcolisión, Microsoft.XNA. Framework. Point frameact, Microsoft.XNA. Framework. Point shetsize.

Vector2 velocidad, int millisecondsperframe).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad, millisecondsperframe).
{.
}.

Public override vector2 dirección.
{.

Get.
{.
// devuelve la dirección en función del teclado o el pad.

Vector2 inputdireccion = vector2. Zero.
/*if (keyboard. Getstate (). Iskeydown(keys. Left)).

Inputdireccion.x -= 1.

If (keyboard. Getstate (). Iskeydown(keys. Right)).

Inputdireccion.x += 1;*/.

If (keyboard. Getstate (). Iskeydown(keys. Up)).

Inputdireccion. Y -= 1.

If (keyboard. Getstate (). Iskeydown(keys. Down)).

Inputdireccion. Y += 1.

Return inputdireccion * velocidad.
}.
}.

Public override Void update (gametime gametime, rectangle clientbounds).
{.

Posición += dirección.

If (posición.x < 0).

Posición.x = 0.

If (posición. Y < 0).

Posición. Y = 0.

If (posición.x > clientbounds.width - Tamframe.x).

Posición.x = clientbounds.width - Tamframe.x.

If (posición. Y > clientbounds. Height - Tamframe. Y).

Posición. Y = clientbounds. Height - Tamframe. Y.

Base. Update (gametime, clientbounds).
}.
}.
}.

Como veis la clase es prácticamente igual a la clase CPU. Lo único que cambia es que en el atributo dirección estamos modificando la dirección en función de que tecla pulsemos (arriba o abajo. También podríamos jugar moviendo a izquierda y derecha descomentando las líneas comentadas).

Al final multiplicamos por el Vector velocidad y así tendremos el aumento o decremento del eje y que debemos aplicar a la posición del sprite jugador. Simple, pero efectivo.

En este caso, en los constructores, no le pasamos el parámetro spritemanager porque no necesitamos llamar a ningún método suyo. Al fin y al cabo nosotros somos los que movemos el palito y no dependemos de ningún otro sprite (ni de la pelota ni de la cpu).

Ahora veremos un caso más claro en el que dependemos de otros sprites. La clase pelota.

Pasemos a dicha clase:
using system.

Using system. Collections. Generic.

Using system. Linq.

Using system. Text.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Graphics.

Namespace miprimerprogramaxna.
{.

Class pelota : sprite.
{.

Spritemanager spritemanager.

Jugador player.

Cpu CPU.

Vector2 cpuvec.

Public pelota (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameact, point shetsize, vector2 velocidad,spritemanager spritemanager2,jugador player2,cpu cpu2).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad).
{.

Spritemanager = spritemanager2.

Cpu = cpu2.

Player = player2.
}.

Public pelota (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameact, point shetsize, vector2 velocidad.

Int millisecondsperframe, spritemanager spritemanager2, jugador player2, CPU cpu2).
: base (teximagen, posición, tamframe, offsetcolisión, frameact.

Shetsize, velocidad, millisecondsperframe).
{.

Spritemanager = spritemanager2.

Cpu = cpu2.

Player = player2.
}.

Public override vector2 dirección.
{.

Get { return velocidad; }.
}.

Public override Void update (gametime gametime, rectangle clientbounds).
{.

Posición += dirección.

If (posición. Y > 599).

Velocidad. Y *= -1.1f.

If (posición. Y < 1).

Velocidad. Y *= -1.1f.

If (posición.x > 800).

Resetpelota ().

If (posición.x < 1).

Resetpelota ().

If (this, rectcolisión. Intersects(cpu, rectcolisión)).
{.

Velocidad.x *= -1.
}.

If (this, rectcolisión. Intersects(player, rectcolisión)).
{.

Velocidad.x *= -1.
}.

Base. Update (gametime, clientbounds).
}.

Public Void resetpelota ().
{.

Posición.x = 400.

Posición. Y = 300.

Velocidad.x = 5.

Velocidad. Y = 5.
}.
}.
}.
.

Como veis definimos varias variables:
spritemanager spritemanager.

Jugador player.

Cpu CPU.

Vector2 cpuvec;.

Spritemanager ya conocida, una instancia de la clase jugador (player) y otra de la clase CPU (cpu) y un vector2 con la posición de la instancia CPU.

En el constructor vemos que le estamos pasando dichas instancias (player y cpu) además del spritemanager.
¿Y esto para qué? Pues muy simple, necesitamos conocer exactamente dónde están dichos objetos para ver cuándo se colisiona con ellos. Para ello se los pasamos como parámetro a la clase pelota y así podemos acceder a sus variables y métodos. Es lo que hacemos en la clase spritemanger al crear la pelota y los jugadores. Si os fijáis a la pelota le pasamos los jugadores recién creados.
pelota = new pelota (.

Game. Content. Load<texture2d>(@imágenes/pelota).

New vector2(400, 300), new point(18, 1, 1, new point(400, 300).

New point(6, new vector2(6,6), this, player, cpu),.

A continuación en el método update vamos a aumentar la velocidad de la pelota multiplicándola por -1.1f cada vez que choque contra las paredes superior e inferior. Con el negativo lo que hacemos es que cambie la dirección de la pelota. También haremos un resetpelota () si nos salimos por la izquierda o por la derecha.
if (posición. Y > 599).

Velocidad. Y *= -1.1f.

If (posición. Y < 1).

Velocidad. Y *= -1.1f.

If (posición.x > 800).

Resetpelota ().

If (posición.x < 1).

Resetpelota ().
.

Esta parte es importante ya que nos permite saber cuándo choca. Lo que haremos es llamar al atributo rectcolisión definido en la clase sprite que ahora veremos y junto al método intersects mirara si choca con el rectcolisión de la clase CPU. Dicho de otra forma, tenemos dos rectángulos (uno para la pelota y otro para el jugador cpu), si ambos chocan (lo cual comprobamos con el método intersects de la clase rectangle cambiamos la dirección multiplicando la velocidad por -1 (damos marcha atrás).

Como veréis llamamos a rectcolisión con this, esto es por lo que os expliqué, la clase pelota hereda de sprite y por tanto tiene su atributo rectcolisión (aunque en la propia clase pelota no aparezca) heredado, y por tanto así le estamos diciendo accede a tu propio atributo rectcolisión.

Lo mismo ocurre cuando chocamos con el jugador.
if (this, rectcolisión. Intersects(cpu, rectcolisión)).
{.

Velocidad.x *= -1.
}.

If (this, rectcolisión. Intersects(player, rectcolisión)).
{.

Velocidad.x *= -1.
}.
.

Por último, definimos el método resetpelota () que lo único que hace es decir que la pelota empiece en la posición (400,300) y que lleve la velocidad (5,5).
public Void resetpelota ().
{.

Posición.x = 400.

Posición. Y = 300.

Velocidad.x = 5.

Velocidad. Y = 5.
}.

[kiko_L]

Y ya para terminar este ilustrativo ejemplo, voy a poner la clase de más bajo nivel. La clase sprite:
using system.

Using system. Collections. Generic.

Using system. Linq.

Using system. Text.

Using Microsoft.XNA. Framework.

Using Microsoft.XNA. Framework. Graphics.

Namespace miprimerprogramaxna.
{.

Abstract class sprite.
{.

Texture2d teximagen.

Protected vector2 posición.

Protected point tamframe.

Int offsetcolisión.

Point frameactu.

Point shetsize.

Int milisegframe.

Protected vector2 velocidad.

Const int defaultmilisegframe = 16.

Public abstract vector2 dirección.
{.

Get.
}.

Public rectangle rectcolisión.
{.

Get.
{.

Return new rectangle (.
(Int)posición.x + offsetcolisión.
(Int)posición. Y + offsetcolisión.

Tamframe.x - (offsetcolisión * 2).

Tamframe. Y - (offsetcolisión * 2)).
}.
}.

Public sprite (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameactu, point shetsize, vector2 velocidad).
: this(teximagen, posición, tamframe, offsetcolisión, frameactu.

Shetsize, velocidad, defaultmilisegframe).
{.
}.

Public sprite (texture2d teximagen, vector2 posición, point tamframe.

Int offsetcolisión, point frameactu, point shetsize, vector2 velocidad.

Int milisegframe).
{.

This, teximagen = teximagen.

This, posición = posición.

This, tamframe = tamframe.

This, offsetcolisión = offsetcolisión.

This, frameactu = frameactu.

This, shetsize = shetsize.

This, velocidad = velocidad.

This, milisegframe = milisegframe.
}.

Public virtual Void update (gametime gametime, rectangle clientbounds).
{.
}.

Public virtual Void draw(gametime gametime, spritebatch spritebatch).
{.
//dibujamos el sprite.

Spritebatch. Draw(teximagen.

Posición, new rectangle (frameactu.x * tamframe.x.

Frameactu. Y * tamframe. Y, tamframe.x, tamframe. Y), color.white, 0, vector2. Zero,1f, spriteeffects. None, 0).
}.

Public vector2 getposition.
{.

Get {.

Return posición.
}.
}.
}.
}.

Variables:
texture2d teximagen; -> textura del sprite.

Protected vector2 posición; -> posición en la que empieza.

Protected point tamframe; -> tamaño del sprite.

Int offsetcolisión; -> un offset en la colisión (en caso de que no queramos que choque en cuanto toque el sprite sino más tarde).

Point frameactu; -> frame actual.

Point shetsize; -> esto no lo vamos a usar, se podría borrar.

Int milisegframe; -> tampoco lo vamos a usar.

Protected vector2 velocidad; -> velocidad.

Const int defaultmilisegframe = 16; -> tampoco lo usaremos.

Lo siguiente que haremos es crear el atributo rectcolisión a partir de ciertos parámetros de entrada como el tamaño del sprite, el offset de colisión, etc.

Después van los constructores y el update que no hace nada. Por último, vemos que se llama al método draw que tiene como parámetro (además, del gametime) el spritebatch del que hablamos en la clase spritemanager. Con esto dibujaremos en pantalla todos aquellos objetos de una clase que herede de sprite.

Con esto lo que estamos haciendo es ahorrar mucho código. En este ejemplo puede que no porque solamente tenemos tres sprites. Pero imaginemos que tenemos un pong con mil tipos de Items, power-ups, etc. Para cada uno tendríamos que definir su constructor propio, sus atributos, etc. Con la herencia sin embargo, solamente tendríamos que definir los atributos propios de cada sprite.

También definimos el atributo getposition para obtener la posición del sprite (se utiliza cuando queremos devolver la posición de la pelota a la clase cpu).

Y hasta aquí ha llegado esto. Si tenéis cualquier duda me comentáis, y si soy capaz, os la resolveré. Seguiré poniendo cosas y en no mucho empezaré a habler del 3d, aunque aún le tengo que meter mucha chicha.

Os dejo el código un poco más retocado. Un saludo.

-- IMÁGENES ADJUNTAS --

[kiko_L]

Buenas, ayer estuve trasteando un poco más y logré enchufar el mando de la Wii a una aplicación en 3d. Ahora con el mando puedo mover la cámara hacia donde quiera. La semana que viene prometo empezar con el tutorial de cómo hacer una miniaplicación en 3d. Saludos.

[pigo0019]

En hora buena y espero tener el gusto de ya ver terminado el proyecto, te dejo un saludo desde México.

[kiko_L]

Muchas gracias Pigo, acabo de empezar, pero espero conseguir algo bonito y divertido. Saludos.

[Sadyk]

Que tutorial, enhorabuena, eres el amo.

[kiko_L]

Gracias Sadyk, hoy por la tarde espero poder empezar a adentrarme un poco más en las aplicaciones 3d con XNA. Saludos.

[kiko_L]

Hola a todos, siento esta tardanza con el tema del 3d en XNA, pero entre el trabajo y el proyecto no me da la vida. Espero entre hoy y mañana empezar poco a poco a mostrar los fundamentos básicos que hacen falta para programar juegos y aplicaciones en 3d con XNA. Un saludo a todos.

[kiko_L]

Estoy vivo. Después de tanto tiempo sigo con el dichoso proyecto, pero en un par de meses espero quitármelo de encima. Por fin.

Espero poder seguir con estos tutoriales que los dejé tirados y me sabe mal por si alguien les hacía caso.

Al final mi proyecto consistirá más que en una aplicación, en varias cosas que he ido descubriendo sobre XNA.

Os pongo un vídeo de una cosa que hice con XNA, el motor de iluminación sunburn y el motor físico bepu.

Perdón por la calidad de los vídeos, pero el fraps no da más de sí.




Como veis hay que ser Michael Jordan para encestar una. Un saludo.

[kiko_L]

Buenas, después de toquetear un poco más la iluminación y añadir un skybox (para simular un fondo 360 grados) os dejo unos pantallazos de cómo está quedando. Lo siguiente será mejorar texturas y modelos (trabajo puramente de 3d max) y meterme en el postprocesado de efectos (profundidad de campo, Motion Blur, y demás efectos que os suenan más). Dentro de un rato intentaré empezar con la aplicación 3d que os prometí. Primero haré un ejemplo con XNA puro, es decir, sin motores de por medio. Crearemos una cámara, meteremos unos objetos y luego nos meteremos en reconocimiento de objetos seleccionados y demás. Más adelante hablaré de motores de iluminación como sunburn y físicos como bepu physics que son las cosas realmente potentes y que facilitan muchísimo el desarrollo de juegos(salvo que queráis crearos vuestros propios motores, locos hay muchos en el mundo.

-- IMÁGENES ADJUNTAS --

[Sadyk]

He visto los videos, mola cómo está quedando, supongo que, la cámara y todo lo manejas con la Wii, ¿no? Creo que has hecho el primer juego en primera persona de baloncesto. Saludos, y suerte.

Posdata: estaré pendiente de si sigues el tutorial.

[kiko_L]

Hola Sadyk, gracias. Si, el movimiento es totalmente con la Wii, tanto la cámara como la interacción con los objetos. Los balones se lanzan en función del acelerómetro.

Hoy si que si pondré como cargar un objeto en una escena 3d y crear una cámara para poder movernos en ese escenario.

[Mars Attacks]

Hay veces que no es tan de locos. Por ejemplo, tú mismo has dicho que hay que ser Jordan para encestar. En un juego de baloncesto que quiera ser jugable, el gameplay tendría mano ancha con los tiros que permite entrar a canasta, en función de la distancia a ella, el ángulo y un pequeño factor de probabilidad de encestar tanto más alto como fácil se pretenda el juego. No sé si el motor de físicas que usas permite trampear resultados y calcular cual tendría que ser el tiro idóneo desde tu posición para que entrara y, a partir de ahí, intentar ajustar la trayectoria del disparo real con la trapicheada para que enceste más veces, pero es como en mi opinión sería más apropiado para conseguir una jugabilidad divertida.

Qué ramalazo de añoranza me acaba de dar de cuando estábamos en el hopworld para WiiWare, joder.

[kiko_L]

Hola Mars. Gracias por los consejos, y sí, tienes toda la razón y ya tenía contemplado mejorar eso calculando la velocidad lineal que tendría que tener la pelota en función de la distancia con una desviación en función del acelerómetro. Espero hacerlo en breve.

[kiko_L]

Hola, creo que, visto lo visto, voy a dejar de prometer subir nuevos tutoriales. Últimamente entre mudanzas, no me da la vida así que, os subo unos vídeos de cómo llevo el proyecto para que veáis las cosas que se pueden hacer con XNA. Ahora mismo ya tengo:
-Iluminación avanzada (con motor de iluminación sunburn).

Física (con motor bepu physics).

Postprocesado para el efecto difuminado.

Sistema de partículas (usando dpfs).

[rafa120]

Que guay tío, yo intenté hacer un pong con XNA y ni pude lol. Ya mismo te vemos en alguna compañía ¿no? Un saludo.

[kiko_L]

Qué más quisiera yo que acabar en una compañía. Al principio la verdad es que es un poco desesperante, no obstante, es programación pura y dura, sin interfaz gráfico de ningún tipo, eso puede tirar para atrás de primeras, pero una vez que le coges el truco mola mucho.

[STEV'O]

Como te va? Que interesante tu proyecto, de hecho, he estado pensando en desarrollar algo, así como tu idea original para la u, y creo que tú información me será muy útil.

Te tendré en la mira.

Vayaes broma, pero si te empezaré a seguir. Un saludo.

Y, por cierto, estoy a punto de iniciar el segundo semestre de ingeniería electrónica, lo que quiere decir que ya se programar en c, pero aún no se programación orientada a objetos, tengo ganas de aprender OpenGL, aunque el XNA me empezó a llamar la atención, ahora en primeo lugar quiero saber si con c es suficiente para ofrecer un buen rendimiento, o mejor espero el siguiente semestre que aprenda C++, por otra parte, es bueno el OpenGL para tales fines, o el XNA o el DirectX etc?
En fin, lo que quiero es que por favor me orientes para hacer una buena elección, si necesitas más información me dices.

Te agradezco mucho.