Hi there, I jus tgot my file routines working and am developing my map fileformat. So what do I need in a map fileformat? I got an identifier string (To check if it''s a valid map file for my game) a module name which is the scenario or sector name, a MapWidth and Height (In tiles) then the MapTopX and MapTopY starting positions (In pixels how far we are from the top of the map) What other small stuff should I have? Of course after all the little things, I''ll have a big chunk of data to represent the tiles and heights of the tiles. I was thinking of adding a checksum of the map file seems how they''ll be transferred over networks and the internet and have the chance of being corrupted. Any other things to add? Thanks, Ben __________________________ Mencken's Law: "For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons." - Popular Mechanics, forecasting the relentless march of science in 1949

So while waiting for the yet to come responses I looked at the C&C file formats and am trying to find the WarCraft formats and stuff. C&C used compression on their images! Simple but still compression. Should I? It was very simple and easy to implement, but is it worth it?

Thanks!
- Ben

You might want to include a map name string and an author string if you plan on distributing your map editor.

- Daniel

Here are a few ideas for the map file format:

-Characters, put their data at the end of the file with some kind of data on the tile data that indicates they are there.

-Multiple layers, store one layer, then another, etc. or store one tiles from one layer, etc.

-Multiple Bitmaps per tile, for tile animation

-Z height and width (for hills and stuff like AOE)

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

Map file formats is something I''ve been struggling with for awhile now myself, as well. Has anybody writtin any tutorials on the subject? I''ve seen ample tutorials/articles on isometric tiling routine, but they all use static arrays to store locations.

That said, here''s my thoughts:

Together with a college professor I had, we came up with the following (bear in mind, we never implemented anything, only discussed it). We thought to have two files. One file, the table of contents, or index, would store all of the info about the map like height, width, depth(layers), as well as author info, etc. The second file would be the ''map'', i.e. it would contain linear chunks of data that represent x/y locations.

Ok. Not the best explanation. I''ll try to clarify with an example: map file has the following data(commas are not stored, only to make it legible, the data would be binary):

2,6,7

where 2 = grass tile
6 = wall tile
7 = roof tile

The other file, ''index'', would have a series of x,y locations structs that each have the ''address'' of the corresponding ''map'' data in the map file.

The main reason we thought doing it this way might be a good idea, is that you could easily scroll the world and unload parts of the map that aren''t in use. You''d only need to keep the entire ''index'' in memory and from there, any pieces of the map that you want, such as, the immediate location(obviously) of the player, and anywhere nearby, say 10 x/y blocks in each direction.

Anyways, I''m not sure if this whole post made sense or not, but I hope it was helpful to somebody. If anybody wants clarification, (or more confusing examples...) let me know.

David

Alright well I like the idea of the author and map name. Ummm in terms of layers, I figured out a way of using a sinlge layer while being able to represent 25 layers (Like in SimCity). Basically the MapData itself is a grid of MapWidth*MapHeight, so each tile''s x and y position are denoted by there position in memory. Make Sense? Now in memory each tile has 2 Bytes reserved, 1 byte to represent the tile type, and 1 byte to represent tile height, which may later on become something like lower nibble (4bits) for tile height and higher nibble for other proberties. But not right now.

So when I paint the tiles I add the tile height (Z co-ord) to the tiles y position to offset it "above" the lowest plane. It works well and can go very high while only having to loop through my MapData once! I used to be using a 5 layer system which would obviously cost me 5 times the cpu cycles because I had to cycle through each list.

Now that make great terrain, however I think I''ll be switching to 3 bytes per tile, as I''m probably going to have more than 255 different tiles (Value 0 is a don''t paint tile). Also I think trees will end up being tile values, and already I''ve got 5 terrain surfaces (Grass, Sand, Snow, Dirt and Water), which each have several different main tiles as well as transitions to all the other tiles and hills (Like in AoE) and we''re working on cliffs... so yah definately 3 bytes per tile.

After this I use a linked list system to store all the units data, which included Buildings, Units, and Wall/Defense structures. So that''ll be in a different format. I think this seems to be working well as it''s fast and only takes up 131kb (w/ 2bytes per tile on a 256x256 map) which is MUCH better then that guys a couple days ago who needed 74 mb for just data?? That was silly...

Anyhow I won''t be using layers like the traditional sense but more of a 3D format for each object (x,y,z) although the z is restricted to multiples of 8 pixels. (Each hill level will rise 8 pixel above normal.)

Would you guys like to see some of the art? I''m entering it in the ISO conetest in December hopefully (I''ll just put them in JPG format so you can''t take them! He, he, he... w/ high compression... ;-)

Just thought some of you may be interested in seeing other iso projects at work!

- Ben

yes i would be interested in seeing your iso engine in action