I've seen the bitmap to level trick used before, but most "normal" (not developed under severe time constraints) games would eventually have a level editor implemented alongside the game. Personally, I'd be more likely in this situation to implement it as a text file and edit it with emacs picture-mode.
I've also heard of some bitmap-as-data atrocities. A colleague who worked with an engine from a certain well known single player RPG described how bitmaps were used in that engine to control animation states. Like, if walking and getting hit, which animation takes priority. There are as many ways to implement that system as there are game developers. For some reason this developer elected to store those matrices as BMP files, and edit them using a paint program.
The bitmap as level trick is a great shortcut for prototyping and rapid development, perfect for this contest. But I can't imagine the thought process that led to using one for animation data.
emacs picture-mode would be handy, otherwise it's difficult to maintain fixed-width. In practice, I have a lot of trouble with it. I think huge maps (those 10x10 ones) could be a problem, simply due to size; paint programs have zoom as standard, and of course the natural size for a pixel is pixel-size. Though I'm certain emacs has arbitrary zoom-mode.
At least he was using a data-driven approach. There's a lot to be said for that (as opposed to coding it), provided you can find a good representation. As Brooks ~ said "show me your flowcharts and I will continue to be mystified; but show me your tables and all will be clear." He's talking about communicating it to another, but a (appropriate...) data-driven approach is also more flexible, simpler and easier to reason about, because it embodies an abstraction and isomorphism of the solution space. Of course, if it turns out insufficiently rich, you'll wish it was code (or at least that it can be supplemented with code.)
A year ago, when I was developing a retro Pacman for cellphones (J2ME) as a university project, I decided to use a text file to store maps. It was before I knew about emacs picture-mode, and I was working on Windows, so I actually used MS Excel for the job.
You resize the cells to make them square, insert a formula that will rewrite all cells from a given row into a single string (so you could then just copy a column with those strings and paste directly into Notepad, or something), and then you can use convenient navigation with arrows, tab and ENTER to create the map (also filling entire row or column by one mouse drag was handy). Moreover, if you add "conditional formatting", you can make all different tiles appear with different colors and font styles (like walls with dark background or pickups colored in gold, green, etc.). It's a 2-minutes-to-do, poor's man map editor for tileset-based games :).
I've also heard of some bitmap-as-data atrocities. A colleague who worked with an engine from a certain well known single player RPG described how bitmaps were used in that engine to control animation states. Like, if walking and getting hit, which animation takes priority. There are as many ways to implement that system as there are game developers. For some reason this developer elected to store those matrices as BMP files, and edit them using a paint program.
The bitmap as level trick is a great shortcut for prototyping and rapid development, perfect for this contest. But I can't imagine the thought process that led to using one for animation data.