- Independencia y seguridad parametrizada de los GameComponent
-
A la hora de crear un GameComponent, debemos de asegurarnos de que éste proporcione la mayor
independencia del juego externo que lo utilice, ofreciendo una interfaz
(conjunto de métodos y propiedades) que faciliten al máximo su uso. Así pues, veíamos un ejemplo en mi anterior
post donde se debatía como acceder al ContentManager o al GraphicsDeviceManager
desde un GameComponent.
Del mismo modo, si alguna de las propiedades que debe
ser pasadas al componente se realiza de forma incorrecta, este no deberá de
“reventar”, sino simplemente no mostrarse y dejar de actualizarse. Para
conseguir esto último, podemos usar el siguiente procedimiento. En el método Initialize(), el cual es invocado automáticamente por el entorno
antes de ejecturar el GameComponent, deberemos de asegurarnos que todas las
propiedades consideradas de inicialización obligatoria, poseen un valor
correcto. Si ello no es así, forzaremos a que dicho componente no sea pintado
ni actualizado usando las propiedades Visible y Enable respectivamente.
Ejemplo de
pseudo-código:
public override void
Initialize()
{
if (todas las propiedades cargadas por el usuario
poseen un valor correcto)
{
/*Inicializamos propiedades internas del componente *transparentes al usuario*/
}
else
{
this.Visible = false;
//No se llamará a Draw
this.Enabled = false;
//No se llamará a Update
}
}
De
este modo evitamos errores “feotes” cuando el usuario cargue nuestros
GameComponents las primeras veces y se le olvide inicializar o lo haga de forma
incorrecta, alguna propiedad o parámetro.
Un
saludo. Ramón Tébar Bueno
Coordinador
Albacete DotNetClub
- Mi primer GameComponent en XNACommunity
-
Desde el nacimiento de
XNACommunity en Codeplex, el compañero Javier Cantón nos invitó a Cesar Reneses
y a un servidor a colaborar en la coordinación de dicho ‘site’. ¿Quién no ha querido hacer alguna vez un
juego? Ahora tenía dicha oportunidad y además con la colaboración de un crack
como Javier o Viciente .
Como ya sabreis, la finalidad
de XNACommunity es crear una inmensa colección de componentes (los llamados
GameComponents) que puedan ser usados por otros usuarios en sus nuevos escenarios. De este modo, podríamos conseguir juegos de forma muy
rápida y sencilla.
Como siempre voy un poco liadillo, no había
tenido tiempo de aportar algún GameComponent a la lista, y solamente me había
ocupado de animar a la gente para que se apuntara y mover un poquito el
ambiente. Pero ya he dejado de ser virgen!! . Ya podeis descargar otro nuevo componente el cual he
colgado recientemente.
El componente se llama
ImagePath y permite dibujar texturas en
2D en nuestros escenario de forma sencilla con simplemente indicarle el path de
la imagen. Pero lo mejor de este es la
posibilidad de agregarle un movimiento indicándole un camino a recorrer,
pasándole una lista de puntos. La imagen se moverá según aquel con una
velocidad constante, la cual también es inicializada por el usuario.
Como última cosa, ANIMAROS A
PARTICIPAR !! Es muy sencillo hacer pequeños juegos con esta tecnología de XNA .
Y en el momento que tengamos una colección amplia de GameComponents podremos
hacer cosas muy chulas.
Un saludo.
Ramón Tébar Bueno –
Coordinador Albacete DotNetClub
- ¡¡Vaya peazo sorpresa, MSP!!
-
El jueves pasado, mientras participaba en una
de las charlas que organizamos con Albacete DotNetClub semanal o
quincenalmente, mis compañeros Cesar Reneses y Pedro Gonzalez (también
pringados como coordinadores) se les escaba alguna sonrisilla. Desconocedor
todavía de mi gran sorpresa, continué con la charlilla suponiendo que tendría
algún moco en la nariz o me habría dejado la bragueta abierta.
Al final no resultó
ser así, ambos compañeros se habían enterado de que me habían nombrado MSP y
daban ya por hecho una invitación con toda copa pagada.
¡¡Vaya peazo sorpesa, soy MSP (Microsoft Student Partners)!! Hace algo más de un año, cuando entre a esto
del mundillo .NET, lo cual debo agradecer a dos tremendos mostros (no sólo
físicamente, J
jeje, sino como personas, entusiastas y conocedores de la tecnología): Cristian
Manteiga Pacios y Jose Carlos Temprado (“El Thempra”), no esperaba nada de
esto. De hecho, el inicio en el club fue por la llamada curiosidad del
aprendizaje. ¿Cómo haría esta cosa? ¿Y esta otra?. Hay es donde te encuentras a
personajes como los antes nombrados que tienen respuestas para la mayoría de
estas preguntas, y que por supuesto y más importante, están dispuestos siempre
a contarte.
Como decía, mi inicio fue tardío y todavía me quedan muy
muchas cosas por aprender, sin embargo, si algo no ha faltado desde el inicio
son muchas ganas de trabajar y curiosidad por seguir conociendo.
En cualquier caso, por encima del conocimiento, este
mundillo tiene algo mejor: la gente que lo forma. He tenido la oportunidad de
conocer a gente maravillosa, que por muy reconocidos que sean, siguen siendo
personas totalmente accesibles. Ejemplo
de ello es David Carmona o Ethel. Del igual modo, he podido conocer a otros
cracks compañeros de los demás clubs de España, como Javier Cantón, David
Carrascosa, los Jordis de Barcelona, Ricardo Valera, Marcos Cobeña, Miguel
Angel Ramos … buff, todos unos “machines”.
Sin embargo, también debo agradecérselo enormemente a otras
personas más cercanas, tales como Cesar Reneses y Pedro Gonzalez, ambos
coordinadores de Albacete DotNetClubs con los que he compartido un motón de
aventurillas durante este tiempo. También agradecérselo a Jonas y a Juan Luis
(coordinadores y compañeros de Albacete) su apoyo y colaboración en toda
actividad. A todo ellos, les animo a que
sigan trabajando para que se unan a la lista de MSP’s.
Finalmente, un último
agradecimiento muy muy grande a la persona que tal vez más “sufra” los efectos
colaterales de la tecnología: mi querida novia Delia.
Un saludo para todos y nuevamente muchas gracias!!
Ramón Tébar Bueno
Coordinador Albacete DotNetClub
Microsoft
Student Partners MSP
- Curiosidades. Serialización en Compact Framework.
-
Como algunos ya sabreis, serializar un objeto en Compact Framework se
realiza de forma idéntica a como lo podamos conseguir con las librerías del
Framework. Pero ¿alguno habeis analizado el xml resultante de la clase
serializada? ¿habeis notado algo estraño?.
Vamos a poner un ejemplillo muy usual ( código en C# ) . Tenemos la
clase "Configuracion.cs" tal que:
public class Configuracion
{
public string IP;
public string directorio_local;
public Configuracion() { }
public Configuracion(string IP,
string directorio_local)
{
this.IP =
IP;
this.directorio_local = directorio_local;
}
}
Desde nuestro programa principal, en la sección que deseemos, serializamos
dicha entidad de la siguiente manera (todo esto, del mismo modo para el Compact
Framework y Framework):
XmlSerializer
serializador = new XmlSerializer(typeof(Configuracion));
string
path_destino = "./config.xml";
/*Para
CompactFramework, usaremos:
* string
path_destino = GetAppPath()+ "config.xml";
Ver al final del
artículo dicha función*/
StreamWriter
writer = new StreamWriter(path_destino);
Configuracion config=new Configuracion("192.168.0.2","directorio_prueba");
serializador.Serialize(writer,
config);
Console.WriteLine("Configuración serializada");
Si ahora nos vamos al directorio del ensamblado de la aplicación,
encontraremos el archivo ‘config.xml’. Veamos los resultados:
Framework:
<?xml version="1.0" encoding="utf-8"?>
<Configuracion
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<IP>192.168.0.2</IP>
<directorio_local>directorio_prueba</directorio_local>
</Configuracion>
Compact Framework:
<?xml
version="1.0" encoding="utf-8"?><Configuracion
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><IP>192.168.0.2</IP><directorio_local>directorio_prueba</directorio_local></Configuracion>
¿Qué diferencia le ves?
La librería System.xml del señor
Compact Framework intenta ser eficiente eliminando tabuladores y saltos de
línea (\t y \n), lo cual no hace la correspondiente del Framework.
Como añadido extra muy interesante, podemos obtener el path donde corre
nuestra aplicación de dispositivo móvil con la siguiente función proporcionada
por nuestro compañero Paco de Oviedo (también aparece en el primer entregable
de la revista Student.NET)
/// <summary>
/// Devuelve el path de la aplicacion para poder acceder a los recursos
/// </summary>
/// <returns>El path de la aplicacion</returns>
private string GetAppPath()
{
System.Reflection.Module[]
modules = System.Reflection.Assembly.GetExecutingAssembly().GetModules();
string aPath =
System.IO.Path.GetDirectoryName(modules[0].FullyQualifiedName);
if ((aPath != "")
&& (aPath[aPath.Length - 1] != '\\'))
aPath
+= '\\';
return aPath;
}
Un saludo. Ramón Tébar
Bueno
Coordinador Albacete
DotNetClub
- Uso del ContentManager dentro de un GameComponent
-
El ContentManager es la entidad
encargada de gestionar la carga de archivos externos tales como modelos, imágenes , fuentes, etc.
Por defecto, cuando nosotros creamos un nuevo Game Proyect para XNA desde
nuestro Visual Express, la clase Game1.cs contendrá declarado por defecto un
ContentManager.
Si queremos que nuestros
GameComponent cargue recursos, necesitaremos usar a dicho gestor. Las preguntas
que nos surgen son ¿cómo recupero o accedo al que ya tiene mi juego sin crear
uno nuevo? ¿O por qué no crearnos uno nuevo para cada GameComponent y que el
juego principal mantenga el suyo para lo
recursos generales? ¿Se podría hacer algo parecido a lo que hacemos con la
entidad GraphicsDeviceManager desde un GameComponent:
IGraphicsDeviceService graphicsDeviceService = (IGraphicsDeviceService)Game.Services.GetService(typeof(IGraphicsDeviceService));
??
Esto mismo le preguntaba a Javier Cantón.
La mejor solución que me
comentaba nuestro Gurú de los video juegos sería
pasarle el ContentManager del Game principal a nuestro GameComponent como una
propiedad, de forma que no instanciemos nuevos ContentManager en el interior de cada uno de estos, realizando un
uso más eficaz de la memoria.
La otra solución eficiente sería
obtenerlo de forma similar al GraphicsDeviceManager, pero eso no es posible.
(Si fuera posible, ya estais tardando en escribir!!)
Un saludo.
Ramón Tébar Bueno – Albacete DotNetClub