SEQ.BREAKER DEV JOURNAL # 26: ROOM-BY-ROOM

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.

SEQ.BREAKER DEV JOURNAL # 26: SKULL-THINGIES AND RELEASE WINDOW

In our last exciting episode, I explained that I was suffering from designer's block; unable to come up with a sprite for a rotating saw-blade-gliding-along-a-visible-track that fit in the 11x11 pixel space allotted for it, and unable-- for what are no doubt unhealthy psychological reasons-- to work on anything else until I had solved that problem, work on Seq.Breaker stopped altogether. And then, yesterday, I created a glowing electric skull-thingy, and while that doesn't quite fit in as well with the Canadian Terrorist Lumberjacks Who Have Kidnapped Four Adorable Kittens theme, it does the job it needs to do: it tells the player, hey, don't touch this thing.

And so, work has proceeded apace on the game once more, as I craft what I'd call "platforming puzzles". This is different than the sort of thing you'd find in a puzzle platformer like Braid; it's not so much a formal puzzle with keys and such, but rather, a question of, how do I use my abilities and tools to get from one side of the screen to the other?

If the game is intended to be free-form, sections like the ones I'm designing currently are less free; everything's calculated to require exact precision on the part of the player, without much wiggle room for error. (Though, again, the "save anywhere, anytime" feature should make it slightly more palatable.) There is, however, a method to this madness, a reason why a game that's about breaking the rules and exploring possibilities would give you rooms and challenges that can only be overcome in one specific way. And that is, simply, that the "solutions" to these "puzzles" often emphasis a facet of a particular tool that might not otherwise be noticed, and said facet plays a large part in one possible way to break the sequence.

Or to put it another way: if you're going through these sections, having not broken the sequence and thus doing it "wrong", these same sections point the way to how to do it "correctly"-- how to use one item when you think you need two, how to avoid even picking up another item altogether, et cetera.

Despite the fact that I've just got back to work on this game, I think the pace at which I work on it is going to slow down a bit. Partially, this is because the third level, as I've mentioned before, is meant to be something approaching the size and scope of a full Metroidvania game on its lonesome. Partially, it's because that third level is meant to be the most non-linear and most free-form, which requires a lot more thinking on my part. Partially, it's because I've also started teaching myself how to use the Unreal Engine, so that-- once I've kinda sorta figured it out in, like, two years-- I can also make three-dimensional (but not "3-D") games. Partially, it's because I'm also a filmmaker, a dungeon master, a board game designer, and a husband, and partially, it's because winter is fast approaching, and I tend to get moody and lazy at that time.

That's a lot of partiallys, so let me just say that I'm more than partially partial to Summer 2011 for the game's release.