Why are traditional tilemaps still popular?

Wouldn't 2d overhead worlds be much more interesting with arbitrarily placed stuff? 2d objects as various sized rectangles: wall, water, lava, dirt, whatever.
A tilemap ( 64x64 pixels/ cell) with list<gameobjects> could handle efficiency.

Traditional image tilemaps add an extra collision detection step. It requires a rework of the tilemap if you want to change one tile in the tileset.

Do traditional image tilemaps make game programming easier?

Computers are discrete systems, rather than continuous systems - it is simply impossible to create a continuous playingfield (or board) in a computer. Hence you make a discrete board, and a regular grid gives you a tile map.

You can do this easily with tilemaps.

Depends onhow you design you tile storage system. It doesn't have to.

Yes of course, that would look better, but you would need a lot of art(backgrounds, object), and it would take more memory.
The good thing about tilemaps is that you can create a whole world with just a few tilemaps, and they require very little memory, the bad things is the unavoidable blockyness.

One reason is tradition as you already said, and the other is lack of art, most programmers doesn't have a lot of backgrounds and other stuffs to put in their games, so is very easy to rip some tilemaps from some games and use them.
BTW there is a guy here(I don't remember his name) who wrote a tilemap ripper utility.

Because:
(a) they're easy to explain;
(b) in libraries like Allegro they're much easier to draw;

That isn't really true. Look at the "new Allegro demo game" (which the devs assure me will definitely be in the next release of Allegro, honest) — that's a 2d sidescroller with a vector based level and it's level would be tiny compared to a similar tilemap (even one with the level of variation sufficiently reduced) were it not stored in a human-readable ASCII format! For the purposes of debate, it is attached.

It's on the Allegro SVN server, which via HTTP can be accessed here. It looks like things have changed a bit since I last worked on it but an OS X version (PowerPC only, but works under Rosetta) is on the website in my sig.

EDIT:
{"name":"DemoGame.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c2001210e622cbcc3223606fc1a4894.png","w":720,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c2001210e622cbcc3223606fc1a4894"}
A screenshot (which is now probably out of date).

Also just from browsing I notice that level.txt is gone, replaced by level.dat (at around 1/4 the size) and I think there was some talk of doing something nicer with the clouds and trying to use the Allegro GUI in it somehow? And someone said it might be fun to at least make it capable of doing several levels rather than just loading one, then moving from it to "congratulations, get programming"?

It's up on top — if you build sufficient momentum going round the curve that passes by the exit door to get up onto the platforms on the top, then head across them quite far to the left you'll find it. It's shortly before you drop back down to the start of the level.

That may be true, but it isn't the complete story, or I could just draw my entire level as a single bitmap and then say it only occupies 1 byte because I have a 1x1 tilemap referencing that bitmap!

Anyway, file size considerations aren't really that relevant. In a tilemap you pay for level size and level complexity, but increases in complexity are hard to quantify because they take effect partly through requiring a greater variety of tiles and partly through crushing whatever compression you're getting on your map.

In a vector map you pay only for complexity, to an extent size comes "for free". But compression isn't so obvious, in particular for repeated sections of level or if you want to expand your level. If you use a sectoring system, you can get a lot of position information implicitly, the same way that the world positions of tiles are implicit from a tilemap. In that case you could probably use fewer bits to store coordinates.

Another form of vector map would just involve a whole load of reusable segments that are positioned, arbitrarily stretched/rotated and combined to form the map. Then you can build some very complicated maps using very little storage. It also depends what you want to do with your map. Suppose you just wanted a series of loops, jumps, etc, for a game like the SNES game Uniracers. Then you could construct some curves and some loops, and just store a linear sequence of the order they come in. Position and orientation are implicit from the other pieces encountered to date. That approach would yield a non-tilemap approach that was absolutely tiny compared to the tilemap equivalent.

This is all a bit of a false debate though. Nobody picks their map format based on memory footprint when both types are so tiny compared to available resources. And the fact is that for some purposes a tilemap is smaller, for some it is a vector map.

In case anybody does want to turn this into some sort of holy war, I cite now the example of Acornsoft's Citadel for the Electron*/BBC Micro that uses a vector map on an 8bit micro with only around 20 kB storage total once the framebuffer and OS buffers are removed, and manages an interesting and large level.

• which runs this game while operating at below 1 Mhz