Hvis du kan huske tilbage til de dage, hvor man spillede Warcraft I, og trykkede på sin amiga, så har du helt sikkert kommet fordi Tile-baseret spil, så er du helt sikkert kommet forbi Tile baseret spil. Hvis du f.eks. ser på Warcraft I, så så man det direkte fra oven af. Banerne var bygget op af små firkanter, som der så var et billede i. I fag-sprog, kalder man det for en tile (Kan vel oversættes til byggesten). Disse tile, er der mange af - rigtigt mange. De har den samme størrelse, lad os her side 16x16 pixels, så hvis man skulle have en 256x256 pixel bane (Meget lille), ville man løbe op i 65536 tiles. Hvis man ville have en stor bane, som f.eks. redalert, kunne man let løbe op i 1024x1024, det vil altså sige 1048576 tiles. Alle disse tiles, skal så mindst have noget information om hvor de ligger, og hvad for et billede der er i dem, altså X,Y,Billede. Billedet definere man tit som et nummer, som f.eks. nr. 3, som måske er græs.

Som du kan se er vi alderede oppe i at gemme mange informationer pr. tile. Et X,Y koordinat, og textur nummeret, kan lægges op i, hvad der i C# heder en ushort, som går fra 0 til 65,535 og som fylder 16 bit. Altså gemmer vi 16+16+16 = 48bit.

I computer verdenen er en byte lig med 8 bit, så vi gemmer altså 6 byte pr tile. Det vil betyde at vores 256x256 mappe vil fylde: 65536*6 = 393216 byte = 384 kilebyte. Og hvis vi nu gemmer vores 1024x1024, vil det blive: 1048576*6=6291456 byte = 6144 kilebyte = 6 megabyte.

Nu tænker du nok at dette ikke er så meget, men det er fordi vi kun her snakker om 1 lag. I tile-baseret spil, har man tit flere lag, som hver har deres mening, det kan være:

• Bund,
• Detailje lag (En sten, eller sådan),
• Over (Noget der er over hovedt),
• Objekt lag (noget du kan interaktere med, eller andet)
  

Altså 4 lag. Noget spil har flere, og andre spil har mindre. Men hvis vi tager dette udgangspunkt, så bemærk at vi lige plugselig har en 6 * 4 = 24 megabyte stor fil, for en 1024x1024 map, men 4 lag. Hvordan kan du så forklare at man kunne få mange store og lange spil, på diskkette, som have talrige baner, måske enda i 1024x1024 størrelsen?

Svaret er optimering. Hvis vi kender størrelsen på banen, så kan vi udfra det finde ud af efter rækkefølgen af tiles i filen, finde deres position. Hvis vi nu siger at vi gemmer vores tiles, fra venstre til højre, fra toppen til bunden, så skal vi lige pludselig ikke gemme X,Y, men kun texture nummer.

Det resultere i 1024x1024 situationen til: 1048576*2*4= 8388608 byte = 8192 kilobyte = 8 megabyte. Så vi har altså fået den ned fra 24 megabyte til 8 megabyte. En klar optimering, men som du nok kan bemærke, så har vi stadigvæk et alt for stor fil. Grunden til det, er at man i gamle dage, gemte i bytes istedet for ushort, og så måtte man ellers nøges med 256 forskellige tekturer.

Så i vores 1024x1024 situation, fylder spillet 1048576*4 = 4 megabyte. Altså stadigvæk for meget. Øv også!

Det sidste vi kan gøre er at sige at vi starter med at have en bit som fortæller os om dette felt er tomt eller ej. Dette vil resultere i, at hvis vi have et lag, hvor alt ikke var fyldt (Ville vil især være alle andre lag end bund), så vil vi spare 7 bit, men værd gang der er en tile, ville vi bruge 1 bit ekstra.

Lad os leje at vi har et 100% fyldt bund lag, og vi i vores spil engine, har definere at det er 100% fuld, og ikke har den ekstra bit, så vil den fylde: 1048576 byte = 1024 kilebyte = 1 megabyte

Vi definere nu at vores andre lag er 8% fylde, for vores eksempel, og at vi har den ekstra bit. Det giver:

1048576*0.25    = 262144 tiles fyldte
1048576-262144  = 786432 tiles tomme

En fyldt tile fylder 9 bit, hvor en som er tom, fylder 1, altså:

262144*9 = 2359296 bit = 294912 byte = 288 kilobyte
786432*1 = 786432 bit = 98304 byte = 96 kilobyte
288+96 = 385 kilobyte

Vi vil altså i alt få en fil på størrelsen:

1024+(3*385) = 2,12 megabyte.

Det er stadig for meget, men tænk på at det var de færreste spil som have 1024 maps, og måske kun 256x256 maps, eller mindre, så bemærk at der altså kan være 16 256x256 maps på en 1024x1024 maps. Udover dette, så er det langt de mindste af spil, hvor 20% af de andre lag er fyldt.

Man kunne dog godt lave endnu en optimering, ved at sige at en tile, har en refference til den næste tile. Dette vil kun være fordeltagtigt hvis det kun var hver 17. af felterne der var fyldt i det lag, altså omkring 6% eller under.

Resten af optimeringen bestod i at det var de færreste spil der på den tid have 4 lag, men måske kun 2, og samtigdig så kunne man også komprimere dem, via f.eks. zip, for at få det til at fylde mindre. En 2.12 megabyte fil, kunne derfor nemt komme ned og fylde 100 kilobyte eller mindre.

Bemærk også at jeg ikke er den bedst til tile baseret filsystemer, så er der måske end endnu bedre måde at gøre dette på, men efter mange overvejelse, er det den mest optimerede jeg kan komme på.