Personalmente, sono più un fan dei formati binari con sezioni (come Windows PE, solo molto più semplice). Sono anche più facili da analizzare (ma questa è solo la mia opinione .... Ho lavorato con XML abbastanza da farmi venire il mal di testa, controllando se getElementByName ha restituito un singolo valore o un elenco di valori ... ugh). Quindi, se fossi in te, lo farei in questo modo:
".MMF\0" // magic value at the start, null-terminated string. stands for My Map Format :)
char header_length // useful when parsing. char is a byte, of course, an unsigned one
char version // version of the map file. (you don't really need ints here, because you probably won't be needing more than 255 versions for example, but you can also use them)
char* map_name // null terminated string describing the name of the level/map
char* author_name // if you are going to have a map editor for the general public, it would be nice to credit the person who made the map
int width // it's probably wise to plan ahead and expect an int here when you're parsing the file
int height
".layer\0" // we begin another subsection
char header_length
char type // type of the layer. for example, you can put 1 there if you want this to be a layer describing different tiles/block in a Terraria like game
".data\0" // yet another subsection. this will hold the data for the tiles
// in a hypothetical terraria 2d game, you would lay down tiles from
// the top-right corner (0,0) and then begin writing row after row
// write(1,0); write(2,0); write(3,0); ... then write(0,1); write(1,1);
// write(2,1); write(3,1); and so on..
char t1 // tile at (0,0). for example, value 0 is empty, or passable tile
char t2 // tile at (1,0). this might be a dirt block - value 1
char t3 // tile at (2,0). a rock, perhaps? value 3
(...)
char tn // tile at (width-1, height-1) or the bottom-left tile
".layer\0" // another layer.
char header_length
char type // let this on be of value 2, and let it describe portals.
// putting portals in a game makes it instantly 20% cooler
".data\0"
char t1 // 0, no portal here at tile (0,0)
char t2 // still nothing
char t3 // nope, try again
(...)
char t47 // at some location, you made a red portal. let's put 1 here so we can read it in our engine
(...)
char t86 // looke here, another 1! you can exit here from location corresponding to t47
(...)
char t99 // value 2. hm, a green portal?
(...)
char tn // bottom-left tile, at (width-1, height-1)
".layer\0" // another layer
char header_length
char type // value 3, player&enemies spawn points
char something // you don't have to have header len fixed. you can add stuff later
// and because you were smart enough to put header length
// older versions can know where the stuff of interest lays
// i.e. version one of the parser can read only the type of layer
// in version two, you add more meta-data and the old parser
// just skips it, and goes straight to the .data section
".data\0"
char t1 // zero
char t2 // zero
char t3 // zero
(...)
char t42 // a 1 - maybe the player spawn point. 5 tiles to the right
// there's a red portal
(...)
char t77 // a 2: some enemy spawn point
(...)
char tn // last tile
,
vantaggi:
- Sembra fico.
- Ti fa pensare di sapere qualcosa sulla programmazione, fare cose alla vecchia maniera.
- Puoi scrivere manualmente i tuoi livelli in un editor esadecimale:
- Generalmente più veloce di INI e XML, sia dal punto di vista della scrittura che della lettura
- È un lungo flusso di dati byte, davvero. Non c'è bisogno di perdere tempo per renderlo bello, dal punto di vista del rientro (come quello che vorresti fare con XML).
- È facile aggiungere elementi nelle intestazioni. Se un pezzo di dati arriva nella parte inferiore dell'intestazione, è possibile indicare alle vecchie versioni di parser di evitarlo e passare alla parte del file che comprendono.
svantaggi:
- Devi prenderti cura del posizionamento dei dati.
- I campi dati devono essere ordinati.
- Devi conoscere il loro tipo in parser - come ho detto, è solo un lungo flusso di byte.
- Spostando i dati di una posizione (ad esempio, si dimentica di scrivere il tipo di livello; il parser si aspetta un byte lì e trova il valore di '.' - non va bene) confonde l'intero array di dati da quel punto in poi.
- Più difficile saltare subito - non c'è API, nessuna funzione come getLayerWidth () - devi implementare tutto da solo.
- C'è potenzialmente molto spazio sprecato. Prendi il terzo strato per esempio. Sarà sicuramente pieno di molti zeri. Questo può essere eluso se si utilizza una sorta di compressione. Ma ancora una volta, questo è un casino con cose di basso livello ancora una volta ...
Ma la cosa migliore di questo approccio secondo me è che puoi fare tutto da solo. Molti tentativi ed errori, ma alla fine, si finisce per imparare molto.
