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.

SEQ.BREAKER DEV JOURNAL # 24: 3 APPROACHES TO HEALTH.

One advantage to the game's structure-- each mission is completely self-contained, with its own items and hazards that don't carry over to the other missions-- is that I can approach each mission almost as its own game. I've decided to further emphasize this structure by taking a different approach to the player's health in each of the game's three missions.

The first and shortest mission is pretty combat heavy, with lots of enemies to shoot and lots of things to shoot them with. Because it's so focused on action, I'm giving the player a recharging shield. Whenever you get hit, the shield goes away for a handful of seconds. Survive during those tense moments, and your shield pops right back on. This is the approach I talked about way back in Dev. Journal # 11, and I initially thought it would be the standard approach for the entire game.

But, because the shield is a power-up-- an item that you acquire-- and because one of my "rules" is that once an item appears in a mission, it would not reappear in any other missions, I felt it would be more interesting to find a different solution.

In the case of the second mission, that solution is no solution-- that is, the player has no health or defenses. Nor, in fact, any offenses; the second mission, which is roughly twice as long as the first, is all about navigation, with each item increasing your ability to get around the level and reach previously impossible-to-reach places. It's not, however, hazard free, as the level is full of fish, torpedoes, underwater mines, machine guns, and exploding-butt-lumberjacks that will have to be avoided with tricky, precise platforming and the usage of your various items. And while this one-hit death-a-palooza is balanced out by an ability to save anywhere at anytime, it is likely the most difficult level in the game in terms of requiring the most of the player's reflexes. (However-- as I hinted in my dev journal "Difficulty as Deterrent"-- this extreme difficulty exists to encourage the player to avoid it as much as possible; breaking the sequence will transform the level into something of a cakewalk.)

The third mission is by far the longest, functioning pretty much as a complete Metroidvania-style game, with multiple bosses, paths, and items to acquire. If the other missions are pretty bare-bones and narrowly focused (the first on action, the second on navigation), this one is intended to be much broader, deeper, and robust. For this third mission, I'm going with a more traditional approach-- a health meter that is upgraded as you find Health Upgrades and refilled with pellets dropped by enemies. This mission will also feature an ammo system-- unlike the other two-- with a similar capacity upgrade and pellet-drop mechanic.

SEQ.BREAKER DEV JOURNAL # 23: CONTENT WALLS AND CHAPTER STOPS

As hard as this game is going to be, as much as it's going to (playfully) insult its audience, as dadaist as I'm making the story elements-- I still don't want to put any unnecessary walls between the player and their enjoyment of the game. By "wall" I mean anything that stops your progress completely, dead stop, no other options. If you don't break the sequence, that's okay, you can go ahead and take on the next mission anyway. In fact, you can complete all the game's missions "the wrong way" by following the in-game walkthroughs, and there's no penalty for that.

When the player dies, they go back to the beginning of that area-- but with all their collected items and thrown-switches intact. The player also has the option to save their game at any time via the pause screen. So, if they see a series of tricky jumps, they can make a save beforehand and reload it as often as they like (rather than going back ten screens). I don't want to give the player any reason to say, "This is bullshit, I'm done with this game."

At the same time, I want there to be a tangible reward for breaking the sequence. While each mission, and ultimately the game, is going to end differently depending on whether or not you break the sequence, I'm planning on including a fully-functional platformer as a bonus game, accessible only once you've broken the sequence for all missions.

Problem: what happens if the player breaks some of those sequences and not others? If you had to start a new game and do it all over again, it would be kind of irritating; it would put a wall between the player and the content. Solution, and a simple one at that: I've implemented a menu that allows you to replay any unlocked mission, and keeps track, through the appending of a simple icon, as to whether or not you've broken the sequence. And when all sequences are broken, viola!, the bonus game is unlocked.

It's a feature that's becoming more common in indie games. For example, Paul Eres's astonishing Immortal Defense allows you to replay any of the game's 90+ levels, and always uses your highest score for each level to calculate your "cache"-- basically, the money you use to buy your towers-- for the next stage. Matt Thorson's Jumper 3 and McEntee-McMillen's Meat Boy are but two other examples.

I think, however, it should be more than common-- I think it should be a standard feature of every non-RPG game that's longer than fifteen minutes (and I think RPGs should, combat aside, allow you to save whenever you damn well please). You can open a book to any page, and you can select any chapter stop from a DVD menu; why not offer the same freedom in this art form? Set aside technical considerations for the moment, and let's look at this aesthetically: what's lost by this approach, and what's gained?

d20 Poker

The adventure I have planned for my Dungeons and Dragons group this coming Sunday hinges, in part, on a sort of poker game-- that would be the Old West part of my proposed genre trio High Fantasy, Old West, and Steampunk reasserting itself. The problem, of course, is that I don't actually know how to play poker, and that I'm not sure if my players do either, and, hey, we came here to play D&D anyway so what's with this poker, what's next, are we suddenly going to find ourselves playing a high-stakes game of Acquire against a bugbear so you can finally stop yammering on about you can't find anyone to play it with-- and, geez, I guess that's three or four problems, after all. So, um, problematic, that.

But I don't really want my PCs to play poker, but rather, "poker"-- that is, the art of lying to your opponent, of knowing when to bluff and when to call. That part seems to be a lot more fun than remembering what card trumps what, and that's the part that actually gives them something to roleplay. Which is kind of the point.

So, what I'm going to present them with on Sunday is what I'd call d20 poker. The characters in the game are playing some variation of a card game, but the players will just roll their d20, with the highest number winning. Once they've rolled the die, they can up the ante, match that ante or fold, bluff their opponent(s) into folding, and call it when the ante isn't being upped.

I won't know until Sunday how well it works, but it seems, from a purely mechanic standpoint, to be a fun, accessible and fast-moving way to simulate that sort of conflict in a role-playing context. I'll be sure to let you know how it goes after we've given it a try...

SEQ.BREAKER DEV JOURNAL # 22: JUST STOP DOING IT WRONG

Play-testing can be a tricky thing. It is not just about making sure the end product is relatively free of bugs, but also about making sure the game is fair, easy to understand and to play, that the "rules" of the game are consistent and coherent. Most of the time, what the play-tester has to say is one hundred percent spot-on-- such-and-such a part is too hard, such-and-such doesn't really make sense-- and some of the time-- not often, but some of the time-- they're wrong.

Usually, when it's the latter, it's kind of obvious-- weird suggestions and nonsensical complaints being two of the biggest red flags. But sometimes, you'll think your tester is dead wrong when they're dead right, and you've been blinded too much by your own ego, your over-familiarity with the game, your laziness, or a combination of all three to see the painfully obvious truth.

In Seq.Breaker's first mission, the player has access to a bomb weapon, which explodes upon impact. If the player is caught in the blast, they take damage. If the player threw the bomb down from higher ground, they'd be quite safe, but if they just stood there and threw it, they'd get hit. Well, I thought, you just have to jump before you throw the bomb, and I went to work designing an area with low ceilings and tricky jumps in which you needed the bombs. A nice challenge, I thought.

But my first play-tester never jumped before throwing the bomb. He kept getting caught in the blast, and he kept getting frustrated. "I don't think it's fair," he said, "that I have to get hit to use the bomb."

"Well, you can jump up and then use it, and you won't get hit," I said.

And so he tried to do just that. But in that tricky jump section, he kept taking damage due to inaccurate timing.

"I thought you said I could jump and I wouldn't get hit," he said.

"You got to time your jumps."

He didn't do much better. Afterwords, he expressed his reservations.

"It's fine," I said, "you have to just stop doing it wrong." Which was kind of an ass thing to say, and I realized it as soon as it came out of my mouth. It was also a tip-off that I was in the wrong in this case; having to jump before throwing the bombs was not as easy to figure it out as I thought it would be, nor was it fun. Having a weapon or mechanic that bends the player to its will is-- in most cases-- not particularly strong game design.

I was blind to see that because I was too pleased with my own level design; I was too familiar with the game, to the point that things that didn't quite make sense seemed to; and, above all, I wasn't looking forward to sitting down and tweaking the movement speed and gravity for the bomb. Which took me all of ten minutes to get right.

Now, the player can stand still and toss off their bomb without fear of being hit; it's only if they keep moving towards it that they'll feel its wrath. It's fair and it makes sense, and now all that remains is to give my play-tester an apology...

SEQ.BREAKER DEV JOURNAL # 19: WALKTHROUGHS

So, one problem with making a game about sequence breaking is that it asks for a certain investment, both in terms of time and ingenuity, on the part of the player, and that asking for that kind of investment up front often puts a wall between the game and its potential audience. In order to break a sequence, after all, you have to become familiar with the sequence and dicker about with the game's physics/mechanics/interactions/what-have-you. Before you can really play the game, then-- as it is meant to be played, in a way that delivers the sort of experience that would make it unique and thus worth playing-- I'm effectively asking you to spend a fair amount of time with it.

This is a problem I've been aware of from the start, and I've got a couple of solutions. First and foremost, it's making sure that the "fake" game-- the sequence you're meant to break-- doesn't just exist to give context to the "real" game, but that it functions as a complete game and provides the pleasures inherent in the genre-- gaining power, gaining access to more areas, et cetera. This "fake" game might be insanely difficult-- insane difficulty being a prime motivator, I think, for creative thinking-- but it's not impossible, and the player can save the game at any time from the pause menu, effectively setting their own check-points. So, if a player does end up spending a few hours with the "fake" game before they dip their toes in the "real" one, it's hopefully not an empty or worthless experience.

The other solution is to give the player walkthroughs, taking them through the One True Sequence for each mission. Armed with that information-- or so I hope-- they won't be wasting time trying to figure out the "proper" way to complete the mission, but instead will spend that brain-power on finding the sneaky clever sequence-breaking ways to do so.

I was going to give the players these walkthroughs via the support characters, but when I removed those narrative elements from the game to suit the new aesthetic, I just plopped the walkthrough right into the instruction manual PDF. I realized, however, that this wasn't particularly user-friendly, and that asking a player to print up the manual is just adding more brick to the hypothetical law that might prevent them from getting into the game. And so, there is an in-game version of the manual and walkthroughs that can be accessed with a push of a button, which I just implemented today.

Wedge Update, Updated.

One thing you've probably noticed from even a cursory examination of this blog and the various dev journals it is composed of is that I change my mind a lot and dither back and forth. This is, I think, a normal part of the game development process-- at least for me-- and since my dev journals and blog posts are created in the very thick of the process and not after the game has been completed, you the reader get a glimpse into this.

All this is to say that, a handful of hours later, I've decided that allowing an entire team to win Wedge when a member of the opposing team has no legal moves left is a terrible idea that waters down the central concept-- that is, a game played in teams that can only be won by a single player. In the span of those few hours, I could see in my mind's eye the possibility of the two teams simply playing the game as teams, with no incentive to play selfishly, and thus no tension, dynamic or otherwise, between the co-operative and competitive impulses. And that being the whole point of the game...

And so, while I'm sticking with the revised board design, I've changed the win-by-making-the-other-guy-lose condition to award victory to the player responsible-- i.e., the last player to make a legal move wins the game all by herself, and does not share the win with her teammate. This might make the game a little more cut-throat, and emphasizes solo winning and strategy for all four players. Well, at least in theory. I still have to get some people together to play the damn thing more than once.

Wedge Update.

Shortly after posting my recap of the first Wedge play-test, I got to thinking about how I might add a little more balance, how I might increase the chances of winning for a team that's lagging behind. They might never be able to get rid of their stones quick enough to match a player with a commanding lead, but they can-- through canny maneuvering-- deny him and his teammate spaces in which to make legal moves. The mechanic is there; how do I make it more feasible?

The simple answer is, I shrunk the board. What was once an 8 x 15 grid-- 120 squares, one for every stone-- is now 7 x 15. With 15 more stones than squares, it will likely requires more skill for a player to use up all thirty of his personal supply. (This might, I hope, add a bit more tension to the game.) I've also added three black squares-- one at the center of the board, one at the left-most border and one at the right-- in which no stones can be placed. This brings the total number of available squares down to 102, and should-- should!-- affect the ways players approach building their chains and fighting for territory. It's a simple little wrinkle to the formula that I'm hoping will result in a deeper and more nuanced experience.

I've also revised the winning conditions slightly; before, if a player had no legal moves, victory went to the opposing team player with the smallest number of stones. Now, while a player who uses up all his stones still achieves lone victory, a victory won when someone has no moves left is shared by both members of the opposing team. This might-- might!-- help motivate a player lagging behind his own teammate to step up his game so that he can share the victory.

I say should and might and likely because we have to try the damn thing out before we can start proclaiming what it does and doesn't do. But I've got my fingers crossed.

The Cavalry Just Over the Hill.

Having presided over exactly one complete adventure, I'm still very much a newbie as far as Dungeon Mastering is concerned. While it has some things in common with other sorts of game design-- be it board-based or electronic-- I can't really test it the way I can other designs. It's meant to be played exactly once, and if something's off-- if, say, an encounter is too easy, like my big epic boss fight that ended three rounds in without any players sustaining any damage-- then it kind of spoils the experience. There's no way for me to tell if something's not working until we break out the battle grid and start rolling some dice. (Or, story-wise, until their eyes glaze over or they respond to a serious NPC with some wisecracks.) (Or, puzzle-wise, until they miss the "clue" that I thought, wrongly, was obvious.) (Etc.)

I'm sure it's something that I'll develop a better knack for as I get more experience with it-- I'll be able to eyeball an encounter and say, yes, I better nerf this down a bit, or, alternatively, beef it up. But until I get to that point, I'm still faced with the idea that I might be sending my players into the jaws of certain doom-- certainly not something I want to happen to a group of mostly-newbies their second or third time out.

So I've built in a fail-safe to each of the encounters for my second adventure, one that I can call on should the going prove to be a little too tough-- a sort of cavalry that comes to the rescue. They're not an actual cavalry, despite the campaign's Old West flavour. What they are, precisely, I won't spoil here, in case one of my players is reading. But I will say that they're specific to each encounter, and that they're set up, in a non-obvious way, within the story of the adventure.

That's the important point, I think. If the players are getting their butts whupped, and all of the sudden, a giant dragon flies down and scoops up the baddies in its talons, it'd feel kind of cheap and obvious. But if there's a sudden influx of allies that make sense within the context of the storyline that enable the players to turn the tide, if just barely-- well, that's something exciting and epic and thus an altogether appropriate conclusion to an evening of dungeoneering, yes?