Recently, I was helping a friend move and he wanted to know why I was spending so much time on Seq.Breaker's second level. Part of it-- a lot of it-- had to do with being stuck on a sprite (as I described in Dev. Journals numbers 24 and 25) but it also has to do with the game's presentation style. Each 640 x 320 screen is presented as a single entity; the game does not scroll but rather "cuts" from room to room. Because each room is presented as a distinct unit, each room has to function as its own thing, with its own challenges and reason for being, with no fluff or filler.
Even if it was a scrolling game, I'd try to keep things pretty tight, but looking at each room individually really drives this idea home and brings it to the fore of the design process. Every room, I say to myself, "Why is this here? Does it have a purpose? Does it work a distinct unit of gameplay, almost like a level in its own right? Is it memorable?" And, often finding that my work doesn't answer all those questions quite to my satisfaction, I clear out that 640 x 320 pixel space and start again. And again. And again, until I'm happy with it, and then it starts all over again for the next room. And since-- as I discussed in # 24-- I just can't bring myself to skip around when designing something, I will often spend days trying to get a single screen just right.
These three rooms took me about a week to get right. Click to make them larger, as the shrinked versions look really awful and don't get across the game's aesthetic.
One advantage to taking it one 640 x 320 parcel at a time, besides that it will hopefully result in a stronger game, is that it saves me work in the long run. If I want to change a screen's worth of something in a scrolling level, I'd likely have to make changes to the terrain/challenges that come before and after it, perhaps redoing a massive portion of the level because of a small part of that level. Whereas with this room-by-room approach, I only have to worry about, and make changes to, that single screen.