Bookmark and Share

Svårighetsgrad
Svårighetsgrad
Betyg (3 röster)
BetygBetygBetygBetygBetyg
 

XML i XNA

Inledning

Denna gång var det dags att kika på hur vi kan spara data i XML med de vertyg som finns i XNA. Som exempel kommer vi att hantera animationsdata till olika karaktärer, något som är ganska vanligt i spel. Vi har i äldre artiklar tittat på animationer och serialisering av data till xml. Denna gång kommer vi att presentera ett användbart exempel. Målet är att beskriva animeringar via XML och utifrån en "sprite sheet" (bild med 2D animationer) kunna ladda in olika animationer.

Nu skiljer sig den XML-serialisering som finns i XNA-ramverket mot den som vi kanske vanligtvis använder för windowsapplikationer. Serlialiseraren vi skall använda idag heter ContentSerializer och är en del av XNA-ramverket (Microsoft.Xna.Framework.Content).

Det finns många artiklar på nätet som argumenterar för eller emot användandet av den "vanliga" XML-serialiseringen (XmlSerializer) i XNA-spel. Se inte denna artikel som varken en rekommendation eller ett ställningstagande utan som en möjlighet att lära mer om den XML-hantering som finns i XNA från början. Glöm inte bort att XNA omfattar både Windows, XBox 360 och Windows Phone mobiler, därför kan det vara en poäng att använda XML-hanteringen i XNA då denna ska fungera på alla plattformar.

Datan

Vi börjar med att göra en modell över den data vi vill representera. Målet är att vi skall kunna ladda objekt utifrån data specificerade i XML-filer.

bild

Vi tänker oss en design där Character innehåller namn (Name), position på skärmen (Position), animationer (Animations) samt logik som sköter uppdatering (Update) och uppritning (Draw). Till detta behöver vi en klass Animation som beskriver en animation. Animationen innehåller namn (Name), texturhänsvisning (Asset), bildrutor (Frames) och aktuell bildruta (CurrentFrame) samt logik för uppdatering (Update) och nollställning av animation (Reset). Sist men inte minst behöver vi en klass Frame. Denna innehåller en rektangel (Rectangle) som beskriver vilken del av texturen (Asset i animationsklassen) som grafiken skall hämtas från samt hur lång tid bilden skall visas (Duration).

Dataklasserna måste placeras i ett separat projekt av typen "Windows Game Library". Detta för att både spelet och vår "Content" måste känna till klasserna. Gör vi inte detta så kommer XML-serialiseringen inte att fungera då "Content" inte kan referera till vårt spel utan att det blir ett cirkulärt beroende. Mer om detta senare. Vi kallar vårt "Windows Game Library" för "DataModel",

bild

Nu tar vi en titt på klasserna.

På egenskapen Center har vi lagt till attributet ContentSerializerIgnore för att utesluta denna egenskap från serialiseringsprocessen. Detta då Center är en beräknad egenskap utifrån data som vi kommer att spara ändå.

Vi har en vanlig lista av typen Frame. I uppdateringen mäter vi tiden som passerat sedan förra uppdateringen och undersöker om vi behöver byta frame. Når vi slutet av animationen så börjar vi automatiskt om. CurrentFrame väljer vi att inte spara, återigen med attributet ContentSerializerIgnore.

Grafik

Vi måste ju ha lite grafik att testa med innan vi sätter samman allt. Vi ha valt lite grafik från opengameart.org som föreställer en kanin. Denna grafik ligger med i projektet som du kan ladda hem i slutet av artikeln.

bild

Serialisering

Nu kommer vi till det viktiga. Det finns vissa saker som måste uppfyllas.

Lägg till referenser

Både "Content"-delen i vårt spel och själva spelet måste känna till projektet "DataModel" som vi skapade i ett separat "Windows Game Library"-projekt. Vi navigerar till "References" och väljer att lägga till. Se bild.

bild

Välj fliken "Projects", välj projektet "DataModel" och sist "OK".

bild

Skapa en XML-fil i Content

Högerklicka i "Content"-projekt och välj lägg till. Välj sedan "XML" i listan. Vi valde att kalla XML-filen för rabbit_data.

bild

Regler för XML-filen

Några snabba regler. Vi återkommer till dessa efter XML-filen.

Några slutsatser vi kan dra från exemplet ovan:

XML-filen passerar "Content Pipeline" och blir kompilerad till en "rabbit_data.xnb" tillsammans med all annan "content" man kan tänkas ha. Detta kan vara en fördel då den vanliga användaren får svårt att redigera filen så på så viss får den ett enkelt dataskydd. Nackdelen är att XML-filen måste kompileras om när ändringar görs.

Formatet på t.ex. TimeSpan var nära omöjligt att hitta på nätet. Dålig dokumentation får vi nog lägga till egenskaperna för XML i XNA. Övriga datatyper som Color, Matrix etc. finns det exempel på internet likaså array'er av int och liknande. Google är din vän.

Inladdning av data

Nu komemr den enkla biten, att ladda in data. I vår LoadContent kan vi nu skriva:

I exemplet så hanterar vi texturerna som behövs lite speciellt. Om ni minns så hade varje animation en Asset som var namnet på en Texture2D content. Vi måste någon gång ladda in de texturer som animationerna använder. Det finns andra sätt att lösa detta på men artikelns mål var att belysa XML i XNA.

Ett exempel

Vi har samplat kod, grafik etc. i ett färdigt projekt för dig att ladda hem. Vi har lagt in lite logik för att uppdatera karaktären och själva uppritningen. Genom att rycka på N kan vi växla mellan animationerna.

bild

Avslutning

Följande fördelar kan vi konstatera med XML-hanteringen i XNA:

Det finns givetvis en del nackdelar, då jämfört med XmlSerializer

Kommentarer

2 inlägg