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?

SEQ.BREAKER DEV. JOURNAL # 21: TILESETS TO THE RESCUE!

Rather lazily, I've been making walls of my wall object. That is, every 16x16 pixel block in the above picture is actually there, an actual object, even if there's no way the player can interact with it. For the first level, this presented no problems. But for the second, which is substantially larger (each room, again, not being a separate "room" but one continuous interconnected space) and features a lot of water (with each 16x16 block of aqua being, yes, an object), the sheer number of objects caused a lot of slow-down. As in, the game was running at about half-speed.

Now, there's nothing going on, code-wise, within those instances-- no alarm events, no detections, all the collision information for those object types are contained inside the player object-- but it still was putting a tremendous strain on the computer. And as soon as this happened, I realized, I'm going to have to go in and remove as many as those objects as possible, replacing them with tilesets (which take up far less memory).

Now, I love working on my game, but one thing I hate doing is tedious work, such as, oh, I don't know, going into a room and clicking on swaths of 16x16 objects and then replacing them with tilesets. But tonight I finally got off my ass and did it, and as a result, the game is running at the brisk and intended speed of sixty frames per second.

Remember, game makers: tilesets are your friends.

SEQ.BREAKER DEV JOURNAL # 18: ON INSULTING YOUR AUDIENCE

It's kinda neat to stop and think about how the game has changed since the beginning. In an earlier dev journal, I wrote about how I wanted to step up the game's presentation: better graphics, better music, a more cohesive narrative element. And just a few short weeks ago, I decided to do the opposite, going even more lo-fi than usual and thus embracing the indie freeware game cliche. To match the new art style, the narrative elements have been drastically scaled down, with the once detailed and nuanced mission briefings reduced to a few, bold, sometimes surreal imperative statements.

This use of the imperative-- a very peculiar and deliberately "naive" sort of imperative with almost no punctuation, rendered all in uppercase letters-- extends to the game's instruction manual. For example, it prefaces the walkthrough section (detailing briefly the sequence you are intended to break) with

THIS IS HOW TO DO IT IF YOU ARE LAME
DON'T BE LAME
BE AWESOME

and sums up a particularly difficult section of the game with

THIS PART IS EASY UNLESS YOU SUCK AT GAMES

Which might rub some players the wrong way, I know. But I think the tone is actually pretty amusing, and I hope it strikes players the same way. As with most things, however, there is a delicate balance to be maintained, a line that one has to be careful about crossing.

The second mission charges you with rescuing six adorable kittens that have been kidnapped by nefarious Canadians-- which should tell you something about how seriously I'm taking the game's new narrative direction. To transport said kittens, you acquire a Kitten Gun, which will shoot them across chasms and through special Kitten Doors, et cetera.

I was telling my wife (like myself, very much a cat person) about this item, and she expressed concern: "You won't be able to hurt the cats, will you?"

"They're invulnerable to all the enemies," I explained, "but there is one way to hurt them-- something you have to do very deliberately, something that can't possibly be done by accident-- and if you do, you get an automatic game over. A screen pops up and yells at you about it and then the game blips off."

"What does the screen say?"

It says,
WAIT
DID YOU JUST MURDER A KITTEN WITH THE [REDACTED]
YOU [EXPLETIVE] [EXPLETIVE]
YOU DON'T DESERVE TO PLAY MY GAME
GO KILL YOURSELF

And my wife, perhaps wisely, decided that that last part probably crossed the line a bit, and requested that I delete it.

Like I said, a delicate balance.

SEQ.BREAKER DEV JOURNAL # 17: ALL ABOUT ITEMS

Because the Metroidvania genre turns on gaining access to new areas as you acquire new tools, it stands to reason that a fair amount of the designer's attention should be focused on creating a variety of useful tools. And, because Seq.Breaker is about getting by with as few tools as possible, these tools have to be extra useful-- they have to be constructed with certain "unintentional" properties that the player can exploit in order to get to places they "shouldn't".

My current estimate is that there are going to be fifteen or sixteen different items in Seq.Breaker. If that sounds like a lot, consider that they're going to be distributed amongst the game's three missions. That is, at the start of each mission you have zero items at your disposal and in each of the game's missions you have access to a different set of tools.

These tools don't overlap at all. The first mission gives you access to a shield power-up, a standard gun, a laser gun, and bombs. This mission is very action-oriented, hence the preponderance of weapons (though it should be noted that someone breaking the sequence can complete the stage without killing a single enemy). The second mission is much more navigation-focused: there's scuba gear that allows you to spend more time underwater, an air jump power-up that allows you to reach higher and farther platforms, a "shelf gun" that appends quickly-disappearing platforms to the sides of walls-- and so-on. In total, there'll be six tools for the second mission, and only one of them-- acquired just before the game's first proper boss battle-- is a weapon. With almost no offensive capabilities and only one hit point, this second mission is going to be quite a challenge (especially if you're following the sequence).

For the third mission-- which, as I've said before, is about the size of your average freeware Metroidvania game all on its lonesome, with several bosses and branching paths and so-on-- I'm going to be giving the player five or six brand new tools.

So, each level has its own enemies and items, with absolutely no overlap in those two categories. In a way, they each feel like separate, individual games; I like that. It puts the emphasis on the connection factor, on the big idea, on breaking the sequence.

SEQ.BREAKER DEV JOURNAL # 14: THOUGHTS ON GENRE

The "Metroidvania" or "Exploration Platformer" genre-- which is one that Seq.Breaker in some ways seeks to subvert and/or pay tribute to-- is best thought of as a series of problems and answers nested within one another.

For example: to get past the laser barrier in Seq.Breaker's first level,
you need the laser gun.

But to get the laser gun, you need to get past this set of spikes.

And to deactivate this set of spikes, you need to pull a switch, which is guarded by this creature, which must be defeated with the zapper.

Which means, of course, that you need to get the zapper to beat the creature to flip the switch to turn off the spikes to get the laser to eradicate the barrier. It's like the gaming equivalent of giving a mouse a cookie.

There's a certain elegance to this construction, but also a certain nagging feeling that it's not really as non-linear as it seems. How much exploring are you really doing, after all, if you're doing it exactly the same way as everyone else? This is, again, the challenge I've set for myself-- I don't want to simply create two sequences, one long and by-the-nose, the other short and clever, but rather use this genre to create a context for exploration and experimentation.

SEQ.BREAKER DEV JOURNAL # 13

Well, I've finished the first level more-0r-less to my satisfaction, making sure "both" games-- the One True Sequence and the Breaking Thereof-- are playable and intertwined enough that it won't drive the player too crazy.

This first level-- which, in a meta-joke that probably amuses only myself, I'm calling Mission Four-- is pretty short and schematic, with there only being one way to properly break the sequence, and the "first" game being chock-full of hints as to how you might go about playing the second one. It's more of an overt puzzle, this first level, and so in a way, it's cheating a little. After all, I'm not really asking the player to think outside the box, but rather presenting them with one box contained within another and daring them to find it.

This is the slippery slope that made Ultrageist lamentably straight-forward; that is, if you're going to beat Ultrageist, you had to do it the One True Secret Way that was hinted at by the One True (False) Sequence. As such, it wasn't very strategic and doesn't have quite the amount of replay value I want it to.

It's a trap I'm eager to avoid in Seq.Breaker. Certainly, the first level falls into that trap, because that first level, like all first levels (even if it's called number four!), needs to teach the player how to play the game. And presenting a fairly simple box-within-a-box, with ample hints, should indeed impart that information and the game's sensibility.

For the second level, however, I've decided to create two boxes-within-a-box; that is, I'm designing two specific ways in which you might break the One True Sequence and thus thwart the Ninja Looter. I'll give the player hints that apply to both of these boxes, and then it's up to them to do the rest of the mental work that leads them to a solution.

For the third and final level, I'm going to devise a general set of sequence breaking requirements that could be fulfilled any number of ways. My plan is to be just restrictive enough that it takes some thinking on the part of the player, but open enough to encourage creativity. In some ways, this final level might be easier to pull off than the other two, and that's fine; this third level, more than the others, is what the game is really about.

Length-wise, I intend to give it that weight. The first two levels are pretty short. The first stage, if you follow through the One True Sequence, will take you around seven or eight minutes to complete (provided you don't get clumsy). Breaking the sequence will get you through the level in less than two minutes, but that depends of course on how long it takes you to figure it out. The second level I anticipate being about twice the length of the first.

But the third level should run just under an hour to complete the One True Sequence at full-speed with no deaths or mistakes. Comprised of at least four interlocking areas with multiple boss fights, it is meant to function almost as a whole game by itself. Like I said, this is the level that the game is really about, the level that's intended to fulfill the potential of the concept.

Let's hope I'm up to the challenge.

SEQ.BREAKER SCREEN CAPTURE, OFFERED WITHOUT COMMENT.

SEQ.BREAKER DEV JOURNAL # 11: PRODUCTIVE 24 HOURS

Seq.Breaker's new art direction has proven to be very refreshing. I've started the entire game over again and already:

• I'm half-way through with the designs of the first level, now cryptically called Mission Four.
• I've created the basic movement code for the player character, and added some kickback for the weapons.
• I've thrown out the old life-bar system in favour of a two hit point system, in which the extra hit point-- represented by a circular force-field-- regenerates over time.
• I've created the very simple HUD and eliminated the need for both a map screen and a radio support character.
• I've created most of the enemy types for the first level and implemented an enemy respawning feature that's so simple, I can't believe I didn't think of it before. This I will share with you:

This explanation is going to sound a little wonky to people who aren't familiar with Game Maker, so fair warning. It's also going to be a few paragraphs before we get to the respawning fix.

As mentioned before, the game is not a scrolling platformer; rather, the player sees each room as one whole. When they leave one room, the game cuts to the next, and so-on. Some games that utilize this approach, like Alexitron's excellent Metroidvania game The Power, take the form of dozens of different rooms, with room-switching collision objects that are coded to take you to different rooms depending on where the room is located.

While it works for him, I'm not really a fan of that approach. I find that it makes the movement too clunky; jump from one room into the next, and your jump isn't continued but comes to a dead halt. What I've done instead-- which is something I also did in my game Run Jump-- is that I make each level its own "room" (as the Game Maker program defines a room) into which I place an invisible object upon which I center the view-- that is, the game's "camera". This way, we only see one screen's worth of information.

At the borders of the screen-- top, bottom, left, and right-- I have four more invisible objects. The left and right objects are one pixel wide and 320 pixels tall, while the top and bottom are one pixel tall and 640 pixels wide. That is, these invisible lines run the entire perimeter of the screen, and when the player collides with them, they're coded to move the center camera object one screen's worth of pixels in the proper direction. The four lines themselves are coded in their Step Events to always always always be a certain number of pixels away from the camera object, and so they naturally move with it. This distance is actually a twelve pixels more than the margins of the screen for each line; otherwise, if the player moved right and the screen/lines jump right, they'd be right in the middle of the left line, and the screen would jump back and forth. (The back-and-forth jumping is still a bit of an issue moving vertically, so I'm still working on the proper fix.)

One problem with having an entire level active at the same time is that it can cause quite a bit of slow-down-- especially if there are projectile objects to be found. The solution is to input a "Destroy Self" command in the "Outside View 0" Event for each projectile object.

That Event is also the key to respawning enemies (see, I told you we'd get to it!). In games in which a given level or area is a whole bunch of rooms, respawning enemies is as simple as re-entering (and thus re-creating) the room over again. But because my level is really one giant room, I don't have that luxury; if the player backtracks through an area after having killed all the enemies, she'll be faced with lots of empty content. And nobody wants that.

And so, in the Destroy Event for each enemy, I have it set up to Create a new object at 0,0 relative-- that object being called "enemy_1_respawner" or "enemy_2_respawner" and so-on. That invisible object will do nothing while the player is on the screen, but as soon as they leave-- taking the camera object and the view with them-- the Outside View Event for that object will kick in, commanding it to Change Self Into (whatever the enemy type was, "yes" for performing events).

Insanely simple, but very useful.

Anyway-- as you can see, it's been a busy twenty-four hours. Perhaps a little too busy; the wife isn't exactly happy about me spending this much time in the computer room. :-O

SEQ.BREAKER DEV JOURNAL # 10: EMBRACING THE CLICHE

My oft-stated intention since this project's first conception was to really step up my game in terms of presentation, not only to make it more attractive to the potentially disinterested, but to give the player a more complete experience-- music and visuals that evoke mood and atmosphere, dialogue and story that give a more compelling context to the experimental gameplay. And while my composer, C. Filipe Alves, is hard at work on some tracks, I've had more trouble with regards to the artwork. By which I mean, I've had no success at all in attracting collaborators, despite trying several different indie gaming forums.

For some, this wouldn't be a particularly insurmountable obstacle-- substitute rectangles for this, circles for that. But without actually seeing what it will look like, I have only a vague idea at best of what the game will feel like; also, it is frankly impossible to playtest a game in that state: I've never met a player yet who was able to "look past" inelegant square and circle proxies to the gameplay underneath. The lack of art slows the entire process down to the crawl, and I've begun to feel my enthusiasm for the project dwindling.

That's why I've decided to embrace the indie gaming cliche and go as lo-fi as possible with the graphics. I'm not talking about simply using my inelegant proxies, but about creating simple, blocky art using 4x4 pixel squares that emphasize the way each sprite has been constructed. It's better than trying and failing to create more detailed art, and better still than having no game at all.

I'm also considering scaling down the dialogue and story in the same way-- trading my character interactions and careful parsing for something more naive, earnest, and idiomatic. While that, again, puts it in the same circle as a lot of other freeware games, it would match the presentation in a more cohesive way-- thus creating a more cohesive overall experience, which was my goal in the first place.

We'll see if things come together any faster with this new approach.

HEXTOK Session 2.

Tom played two games of Hextok today with Jamie Maurer, one of our play-testers. The first game, we played on the revised version of the symmetrical map that had given the other testers trouble in the last session. This time, the game lasted only twelve turns-- confirming that, even with revisions, it's a pretty shitty map. So, out it goes.

We thought extending the mountains would make the gameplay more dynamic. It didn't.

The second game, we played on the asymmetrically-balanced map that's been played twice before: in the last play session, it lasted nearly thirty moves, and in Tom and Mary's first play-through (call it Session Zero) the game lasted fifty-nine turns. This time around, it lasted sixty-seven, and there were a lot of reversals and come-backs, right up to the last several turns. And being that one of the goals of the game is that it should facilitate quick come-backs and table-turning, I think this particular map shows the game off pretty well.

One thing we did notice in both games (Jamie won both, by-the-by) was that neither of us opted to use the four-point buy to heal a level-one or level-two unit. In the previous session, the four-point healing option extended to level-three units, which basically kept the level-three units immortal if the player was holding onto enough bases.

It was abused so severely and made the game so lopsided that I removed the healing for level-three after that first session. In this session, though, there was no point in spending four points to heal a level one or level two since you could just as easily spawn a new level one for two points or level two for five (two for a L.1 plus the three points to upgrade). I briefly considered sliding the points down, but both Jamie and I found the game very high stakes when you couldn't correct a mistake or compensate for an opponent's advance.

The removal of the healing system makes the game both simpler and deeper, and as far as my design goals are concerned, that's a compelling combination.

HEXTOK!: Q.A. # 1

Last week, I very quickly whipped up a quick and simple small-scale multi-map hex-grid based tabletop tactics game in the course of the evening. My goals in doing so were as follows:

• I wanted there to be very little for the player to keep track of in terms of stats/points/etc. For this reason, I used a simple two hit point system, with one side of a token (such as a coin or button) representing two hits and the other representing one.
• I wanted to have an in-battle leveling-up mechanic, which in my experience is usually the purview of video game tactics games and not their table-top brethren. This game features three levels of units, with a simple point-spending system to recruit new units/level them up.
• I wanted to have a very forgiving comeback system that prevents what David Sirlin calls the "Slippery Slope": that point in the game where one side has it pretty much in the bag, and the other side spends the next twenty turns knowing they've already lost. Players earn points for defeating enemies and holding bases, but also when they're down to one or two units (out of five). Respawning is cheap (healing less so), and a forced spending mechanic that resets your pool to zero whenever it hits ten prevents one player from securing a tremendous numerical lead on the other.
  

The resulting game, Hextok, had its first Quality Assurance session today. And even though (and perhaps because) a number of major changes were made to my original design in its wake (more on that a graf or two hence), I'm very pleased with the results so far. First and foremost, the thing is playable, and I know that sounds like a silly thing to worry about, so let me explain.

I try to play-test all my video games as extensively as possible, and have always benefited from the process immensely, rethinking and and refining and redesigning not only things like the user interface, but whole game mechanics and level designs. But before I ever sit anyone in front of a computer and say, "play this!", I've played through it on my lonesome dozens of times. I try to get my game pretty damned polished and bug-free before I let anyone else touch it; if a concept I'm working on isn't fun or working for me, I know it's not going to work for anyone else, and I usually scrap work on it or restart before my play-testers ever catch a whiff of it.

But since this is a board game, and a two-player board game at that, I don't have that luxury; I can't see if the game is fun, if it works, if it fits together, or if there are glaring and obvious mistakes in its design, until I get another person in the room. I'm very picky about unveiling something that I think is only half-formed, but in this case I didn't have a choice. My worse nightmare is that the game would be a confusing, broken mess, and that my play-testers, upon leaving, would stop on my porch and shake their heads sadly.

That, fortunately, wasn't the case. The players had fun-- with the first map more than the second-- and there were several thoughtful "hmms" as they tried to figure out a way out of a predicament or turn the tables on the other player.

That's not to say it went off without a hitch; as I said, there were some major changes made to the rules, mostly nerfing the level three unit. In the version I presented them with, the level three unit moves eight hexes, does instant-kill damage, and moves through water at a cost of two movement points per hex. On the game's relatively small board (103 hexes altogether), the level three just dominated the game.

This was exacerbated by the fact that the player was able to spend a finite number of points before the game to recruit from all three levels. Even when one player had five level-one guys and the other one level-three and one level-one, the second player managed to route the first at every turn, causing his ranks to drop like flies.

One of the players, J.D., suggested a very smart nerf on the level-three: reduce his movement to five hexes, like the first. This makes the second stand out more-- he moves eight hexes and has a wider attack range than the other two-- without getting rid of the level-three instant kill that was so vital to making it desirable. And the water hexes-- which cost two movement points for the level-three but were impassable for the other two levels-- would be even more of a challenge.

They were, in fact, too much of a challenge. The next game, they played with this five-hex movement rule for the level-three, and the water just slowed the pieces down so much that the sense of power was gone. And so, we removed the slowdown on the water hexes-- the level-three unit moves five hexes only, and can move through water, but there's no difference in his movement speed.

The other problem we noticed is, with a four-point across the board buy per unit to recover a lost hit point, that a level-three piece was basically rendered immortal if its player was holding enough bases. The other player would attack the level-three, the level three would heal itself for four points and kill the other unit, repeat, repeat, repeat. Discussing it with the play-testers, the idea was bandied about that we should make the level-three heal cost more than the other two levels. I was reticent about this, having concocted what I thought was a simple and easy-to-remember point scale: 2 for a level one, 3 to level up to two, 4 to heal, 5 to level up to three. That's 2,3,4,5, simple and clean.

What I decided instead was to remove healing for the level-three unit entirely, making the piece as valuable as a Queen in Chess. (Because it is so deadly, one wants to be extra careful with it.) And this (I think) should prevent the ugly kind of losing-loop I want so strenuously to avoid.

Feedback from my gamers also convinced me that a level three player should not be available for a starting party, and that led me to discard my prior (and somewhat confusing) system that allowed for various strategic starting line-ups in favour of five level-one units for each player: equal and balanced, ensuring that no player dominates the game right out of the gate.

There'll be a few more local QA sessions before I start contacting web-folk to play-test for me; if you're interested in being part of the latter, drop me a message in the comments field below, or shoot me an e-mail at milos_parker at yahoo dot com.

Seq.Breaker Dev Journal # 9

Earlier today, I sent the track list/descriptions to my composer for this project, C. Filipe Alves. I'm really excited to hear what he has in store for me.

While I still have the player character sprites that were created by "Captain Ricco", I haven't found an artist to tackle the environments, objects, NPCs, and enemies just yet. And there's two reason for this: one, I'm not sure what I want stylistically, being torn between going really colourful and cartoony and going really moody and muted. Two, I'm not sure quite yet at this point in the process exactly how many sprites I'm going to need and what they're going to be of, and I'd rather give a prospective artist a complete list instead of peppering them with updates.

But while I'm making the game, they have to look like something, and so I've quickly whipped up some temporary sprites. They're pretty awful looking, I know, but they work better than coloured blocks and circles at the very least.

Anyway, I thought I'd share some of them.

Here's a health power-up. This doesn't restore health (that's what save points are for!) but rather ups your maximum.

This is a piece of destructible rubble hanging from a ceiling or from another piece of rubble.

Here's a very basic, stationary enemy that spits out projectiles upwards.

This bloke's yellow shell repels your laser-beam weapon, requiring you to fall back on your weaker concussive blaster.

Now for a look at the general idea of the boss of the first level. This first design looked a bit off-- even off-er than my other terrible attempts at artwork--

-- and so I took away the eyestalk and added some more shelled armour around the eyeball.

The boss's eyeball is its initial weakpoint; keeping with the "yellow shell = laser proof" motif, the player needs to use their concussive blasts to damage it. (That said, the laser does come into play during this fight.) Blast it enough, and the eye goes closed, disabling another area of its defense-- you'll have to play the game and see the fight to see what I'm talking about-- for a brief period of time.

But the change was too subtle. Let's look at those two sprites again so you can see what I mean:


And so I added these three red marks to call attention to the boss's stunned state (the boss will also be flashing when stunned/damaged, something that's done with an alpha overlay).

Again, this sprite won't make it into the final game, as it looks god-awful, like all my sprites do. But it does give you the general idea, and having figured out some of the game's potential visual language-- calling greater attention to the stunned state, the use of yellow as a laser-proof colour-- it should help my eventual artist(s) when the game gets to that point.

Seq.Breaker Dev Journal # 8

One of my stated goals in making the game that's now called Seq.Breaker is to provide a stronger narrative context for the gameplay. By this I don't mean that there's going to be some kind of knotty plot to unravel with a bunch of twists and turns and double-crosses, but that I want to use the tools of narrative-- dialogue, characterization, humour, world-building-- to imbue the setting with a greater sense of life and verisimilitude, and to build up one particular narrative thread to help keep the player motivated.

That thread is the question of what happened to the protagonist's husband during her mission to "the colonies"-- a mission that was otherwise such an unqualified success that she's famous in her field, considered to be at the absolute top of her game, even as a gnawing sense of personal failure and loss prevents her from enjoying that success.

I wanted the player character to be famous and successful because I thought that would give the player a subtle sense of empowerment. You're no neophyte getting your hand held through a tutorial, you're a competent professional specializing in creative solutions to dangerous problems. When the help character for the first mission butts in, he's very aware of how unnecessary he really is, and that feeds into his nervous personality-- always apologizing and second-guessing himself, lacking the confidence that, it is implied, the player has in spades.

The problem is there's a degree to which this is amusing and a degree to which it really isn't, a degree to which his constant apologizing grates on the player's nerves and seems to violate the integrity of the fiction: why would a super-star sequence breaker be working with such a nervous, redundant scanner?

Another problem with this set-up is that that narrative thread-- what happened to her husband on the colonies?-- might excite the player's curiosity, but it doesn't give the player a compelling reason to play the game the way it's meant to be played. There's a reason, after all, why the game is called Seq.Breaker. The whole point is to encourage the player to engage in meta-gaming, and if that central mystery of what happened is answered regardless of whether you adhere to the sequence of break it, there's not really any incentive to engage in the kind of thinking that would break the sequence. This is a major problem that needs to be fixed.

And so, I've done a great deal of rethinking about that narrative thread and the player's position in the game's world. The game now begins a year after the colonies mission. Far from being her greatest success, it is now her most daunting failure, both personally and professionally-- the first such failure in what was once a supremely promising career. No matter how she tried, she just could not break the sequence-- and her husband dies as a result. Her colleagues, for the most part, are sympathetic, and in the time since, many scanners and breakers have looked at the colonies mission and found that they, too, were unable to think of a way to break the sequence. Still, she blames herself.

At the game's start, she is embarking on her first mission in a year: she's a bit rusty and unsure of herself. She knows she has the skills and brain-power to do the work and is eager to prove it to herself and others; she's eager to throw herself in her work to distract herself from her loneliness.

So, now, the first mission has two characters with something to prove, two characters who are slightly unsure of themselves. Her scanner is still nervous, still anxious, but now he seems more helpful, seems like he relates to her more. Her journey is his journey.

And when we finally do see the colonies mission, it's been built up as something that's daunting and impossible. There's no way to break this sequence, the player is told, no way to save the life of her husband. Which, in a game that's explicitly about sequence breaking, is an implicit challenge, a dare. Now the player has a reason to think outside the box, a reason to meta-game.

I'm much happier with this new narrative context; it's one that's tied more closely to the game's central gameplay idea.

Seq.Breaker Dev Journal # 7

A few quick updates, because it's been a while:

• I've started the game over again from scratch. This is something I routinely do when I'm making a game, sometimes three or four times, sometimes as far as 3/4 of the way through the game. I find I'm able to make a more refined and elegant experience if I start over from the top.
• I've decided to go with a new graphical style, and am currently looking for an artist to execute it. The style I'm looking for is now a bit more cartoony, something akin to what you'd find in the Metal Slug series or Gunstar Heroes.
• I've decided to make the screen dimensions less extremely wide; it made the game feel slower. Not that the protagonist was moving slowly-- just that the extremely long rooms made it feel like you were lagging.
• Story-wise, I've decided on a change that I think will provide a very interesting incentive towards the sort of meta-gaming that I want to encourage. More on that later.
• I've also changed the name of the game from the unwieldy Sequence Breaker to the shorter Seq.Breaker. This will also help the game stand out in google searches (I hope).
  

More to come in the near future. Stay tuned!

Sequence Breaker Dev. Journal # 6

The first mission of Sequence Breaker is nearly complete, and by complete I mean almost everything is in place and working, even if it all looks like a bunch of ugly circles and clunky rectangles at this stage in the game. As I prepare to start work on the game's second mission, I find myself faced with a rather peculiar challenge.

To recap: the point of the game is to present the player with a Metroidvania-style sequence and encourage them to break it by thinking deeply and creatively about the game and the level design. In a previous dev. journal, I said that this was akin to designing two games simultaneously: the game I want them to play (break the sequence) and the game that's in place to facilitate that (the sequence itself). And both games have to work, have to be playable and fun and well-designed. So, if I do my job right, there'll be a lot of content the player never has to see and is encouraged to skip over. Hold onto that, we're going to come back to it in just a moment.

Another goal in creating Sequence Breaker is to step up my presentation, and that includes using more of a narrative element than I have in my previous experiments in game design. For the first time, there are characters and dialogue, and at the center of the game is the mystery of what Mrs. Max did at the colony, and how those actions made her both a legendary hero and a widow.

The protagonist being silent, and her creator being endowed with an innate impatience of cut-scenes, the set up for the colony flashback mission that forms the bulk of the game is peppered through-out the dialogue: a passing mention of the colonies there, an oblique reference to what she's lost here.

So, instead of having a textbox solely and unrealistically for a character to bring up her past, my plan is to work these details into the natural flow of the more informative textboxes. For example, when Stanley Six, your assistant for the first mission, points out that your way is barred by a pile of rubble that can be removed with a nearby explosive, he apologizes for pointing out something so obvious to "the hero of the colonies". Otherwise, the player might feel like the backstory hints were being shoved down their throats, might start to resent it; fold it into something useful, and they don't feel like you're wasting their time.

And all this would be fine and dandy, if it wasn't for the fact that I'm designing two games-- one of which gives the player a linear sequence and, should they follow it, helps them along with mission assistants who'll pipe in information about, say, a pile of rubble that needs exploding, and the other, more non-linear sort of game, in which most of that first game's content (enemies, rooms, power-ups, and dialogue) is skipped over completely.

And therein lies the problem I'm grappling with at the moment: if skipping over content *is* the point of the game, how do I impart the necessary information and context without hedging the player in? And how do I make them curious about it without compelling them to play through the full-sequence in search of extra tidbits-- that is, without working against the desire to encourage players to think outside the box? It is, I think, going to be a delicate process, a balancing act that, at this moment, seems slightly daunting.

SEQUENCE BREAKER DEV. JOURNAL # 5

My games are usually experimental; I take an unusual mechanic and seeing if the end result is still playable. And sometimes it takes more than one attempt to get it right; I think the original Side Saddle is something of a noble failure, while its boss-battle puzzle-shmup sequel better delivers on the original's essential game-play ideas. With my focus set so squarely on game-play mechanics, I've seldom had the time or the inclination to craft any kind of storyline to give them context. (And, honestly, what kind of storyline could there be for an abstract game like Side Saddle 2 or Ultrageist?)

But in Sequence Breaker, as I've said before, I want the player to have a more complete aesthetic experience, and story is a part of that experience. More than that, I feel that the big idea of the game is better served if there are story elements to give them context. "Shoot-out-the-side-in-a-vertical-shmup" is readily apparent from the moment you press the fire button; "find-ways-to-skip-over-content-and-do-things-out-of-order" is a little harder to grasp just by looking at a screen and pressing a button.

The World of Sequence Breaker

The player character, Mrs. Max, is employed as a "Sequence Breaker"-- a freelancer hired to find creative, clever, quicker solutions when a more linear solution, overly beholden to conventional logic, would be too costly or endanger too many lives. When, for example, a bad-ass space-marine squadron gets said bad-asses handed to them by the big ugly son-of-a-gun with twenty eyes and six mouths, a Sequence Breaker like Mrs. Max finds some sneaky way to avoid it altogether.

Athletic, resourceful, self-sufficient, Mrs. Max is a consummate professional, at the top of her game, having become the stuff of legend after an especially impressive mission she pulled off at "the colony". Where the colony is and what she did to earn her fame will be revealed in a flashback that is also the game's biggest mission. Think of the colony mission as being akin to the Pandora's Temple section of God of War, and you'll get some idea of how big it is in relation to the rest of the game.

But Mrs. Max doesn't like to talk about the colony mission. Her fame came at a price: the life of her husband. I'm well aware that "how-she-became-a-legend" isn't a good enough hook to hang such a huge chunk of the game on; "how-she-became-a-widow", on the other hand, might just do the trick.

There's a danger inherent in such a plotline, a potential for maudlin and eye-rollingly sappy dialogue. It's a danger I'm trying to very consciously undercut by making Mrs. Max a silent protagonist, defined by her actions and what others say about her. My hope is that enough will be implied by the circumstances in which she finds herself and the observations of the speaking characters that she'll be more than a cipher, without losing some essential sense of mystery.

Monologues

Because Mrs. Max is a silent character, I'm not employing dialogue trees or giving the player much autonomy over the flow of the story/conversation. But since the point of the game is to give the player autonomy over the story they're telling by playing the game, to let them control the flow of the levels in terms of how they choose to follow or break the sequence, I think this is a fair trade off.

And so, the game's verbiage doesn't really take the form of dialogue, but of monologues and soliloquies. And I keep these two terms in mind when writing, because the connotation that both have is of a speech that reveals something about the person giving it. And so, when Stanley Six, your "scanner" for the first mission, contacts you to let you know about the switch at the end of a hall, he's doing so in a way that reveals his intense nervousness and social ineptitude. When Myron Gas, your character's boss, gives you the outline for your mission, it's peppered with his cynical, sometimes vulgar, sense of humour.

These characters, and the others, are also intended to be foils for Mrs. Max: Six is nervous, but she's cool and collected. Gas is low and vulgar, she's stoic, maybe even classy. I don't want to be attributing too much to this or seem like I'm reading too much into it, but I do think the cast of characters that I surround Mrs. Max with will give the player some sense of who she is by dint of who she's not.

It's important, though, that I don't bog the game down in reams of text; I'm the sort of player myself who will skim over the writing and impatiently skip over cut-scenes because I want to get back to actually playing the game. My challenge is to to make the words relatively concise-- no radio contact/update should last more than a single text-box-- and to keep them engaging, make them something the player would actually want to read and take pleasure from.

And I think it's a challenge that I'll be able to meet. A couple of dev. journals ago, I talked about how I relinquished control of the music and artwork when it became apparent that I wasn't good enough. But writing is something that I do think I'm good at; I'm a published author, for chrissakes, and my superhero novel Jolt City won several awards in its original, serialized form. If there's any area of game design where I have some inkling of what I'm doing, it's the writing-- ironic, given how stringently I've avoided it in the past.

SEQUENCE BREAKER DEV. JOURNAL # 4

In my last dev. journal, I briefly discussed the importance of a game's overall aesthetic experience-- a combination of gameplay, story, art, sound, level design, and what I would call the game's "presentation style". It's that latter aspect I'm going to be talking about today.

A lot of 2D platformers are also referred to as "side-scrollers", since the screen scrolls with the player as they move through a given area. Not so Sequence Breaker; each screen is a distinct entity, giving the player a full and comprehensive view of their immediate challenges. Once the player moves to the other side of the screen (or back), the camera switches to the next screen.

It's an approach I also used in my platformer Run Jump. That game revolved around what I would call "platforming puzzles"-- not puzzles as in, push-the-block-onto-the-pressure-plate, but puzzles as in figure-out-how-to-use-your-acrobatic-skills-to-overcome-this-obstacle: puzzles that are solved by platforming. If it had been a side-scroller, the player wouldn't have been able to grasp all the elements and thus wouldn't have time to consider all their options.

And while this game's "puzzle" elements-- that is, figuring out how to "cheat" and "break" the game-- aren't as pervasive as those in Run Jump, I figured that Sequence Breaker would benefit from a similar approach, and that the static compositions would make the layouts more memorable, more resonant, and perhaps even just shy of being elegant.

To emphasize this further, the game is presented in widescreen. Not the usual widescreen, but the really wide widescreen, the sort that always lends a certain classy and formal air when used in filmmaking. Cinemascope, the King of Aspect Ratios, is typically 2.35:1-- that is, the screen is twice-and-some-change wider than it is tall-- and my game is 640 pixels wide by 280 high, or about 2.29:1.

What the game might gain from such a presentation style it also loses in verticality. A vertical platforming sequence, like you'd find in the original Metroid, would be impossible; a long drop would have muted impact at best. Though each mission unfolds over a large series of rooms, most are going to end up connected left-to-right. The winding, corkscrewing layouts that sometimes make level maps aesthetically pleasing to look at in their own right are replaced by a series of long corridors stacked ontop of one another.

In an overhead action-adventure game, or a 3D action game, such an approach would be unforgiveable-- which is one reason why I wouldn't create such a game in such a long, horizontally-oriented aspect ratio. In a platformer, though, it feels about right, and I think losing those sort of vertical platforming sequences (which, let's face it, can get a little annoying at times) is a fair trade-off for what I hope the widescreen presentation will add to the experience.

NEXT TIME: Storytime

SEQUENCE BREAKER DEV. JOURNAL # 3

I'm going to be blunt: I have all the artistic skill of snail trying to wrap its slimy tail around a half-eaten crayon. But I'm also a stubborn autodidact who wants to do everything himself, and has only recently begun to rely on other people.

My reluctance to do so comes from my experiences as a filmmaker; until you've been there, you can't imagine how frustrating it is to get into an editing room and find out that someone else forgot to turn the mike on. Depend too much on others and you can get burned; depend on yourself, and you've no one but yourself to blame when things go wrong. That's the way I prefer to work, or at least it was until I started making films with my wife-- the only other person I trust with a camera.

Bringing this back to games, I've made it a rule from the beginning to rely on myself for every aspect of the game's creation, from the art to the level design to the coding (minimal though it may be, as I utilize the Game Maker engine) to the music.

If my artistic abilities are crude and perfunctory, my musical stylings are even worse-- atonal blisters that would give even John Adams pause. It quickly became apparent that my ear-violating "melodies" were not only irking players, but indeed tipping the scale towards outright loathing. And so, after my first few games-- most of which, lucky for your ears, are no longer online-- I started outsourcing my music. First, I took baby-steps and downloaded a free pack of songs by a composer named Lateksi2-- his music, for example, adorns both my platformer Run Jump and the original Side Saddle.

Then, I went looking for brand-new compositions and got submissions from two different composers. One of them, Nathanael Crane, I've used for both Side Saddle 2 and Ultrageist. The other, C. Filipe Alves, will be working on the music for Sequence Breaker.

I might have went into my search for composers thinking of the music as background, a necessary filler; as a filmmaker with fairly Dreyer-ian ideas about the importance of visual rhythms, I tend to avoid music altogether. But working with Nathanael, and listening to Alves's other compositions, I've come to see my composers as vital collaborators, co-creators, whose music is not filler but an important part of the game's over-all aesthetic experience.

One argument you hear a lot, and an argument that I used to make in my game design articles, was that if you took a current generation game and just replaced all the artwork with blocks, it would still play the same, it would still be the same game deep-down, so pretty graphics really don't matter. But such a game wouldn't feel the same. The vibe would be different. A Super Mario Bros. with Intellivision graphics might still control like Super Mario Bros., but it wouldn't be bright-and-bouncy, wouldn't feel like Mario, wouldn't play like Mario.

Aesthetics matter; sound and picture and story aren't more or less important than the gameplay, but rather all tangled up with it, all working together to create an experience that's hopefully worth having. Players complained that my blocky graphics for Ultrageist felt kinda dead in the game's black play-space. A day later, I had implemented the current "growing circles of overlapping colour" motif, and not only did those complaints lessen, but I found myself that the game was more fun, more entertaining, more engaging with this simple addition.

And it's with a renewed devotion to crafting not just a gameplay experience but an aesthetic one that I've come to face facts: if I suck at art, I shouldn't be doing all the art for Sequence Breaker. I've already secured the services of one artist for the player character's sprites, and will soon be looking for people to bring my enemies and backgrounds to life while I concentrate on the game's story, pacing, and level design-- areas that are, at least in theory, ones in which I've demonstrated some slight modicum of talent.

All my games have been largely experimental, and small-scale. For this game, I intend to break this sequence of my own design and to create something with a bit more polish, something that provides the player with a somewhat fuller and more satisfying experience.

NEXT TIME: Widescreen.

SEQUENCE BREAKER DEV. JOURNAL # 2

Setting aside some gorgeous character sprites created by a very talented chap who goes by the handle Captain Ricco, Sequence Breaker is still in the wire-frame, big-ugly-blocks-in=place-of-art stage of things, so you'll forgive me if I withhold any actual screen-shots at this point in the process. I do, however, have this:

It's a room-by-room layout of about a third of the game's first level. At the moment, the game is divided into two missions, one being relatively small and somewhat linear and the other being much larger and free-form-y. The second is really the heart of the game, the first more of a tutorial, as it were. More on that, and the challenges it presents, in a later dev. journal. Right now, I'm going to go room-by-room here and, without giving too much away, try to explain how I'm designing two games at once. I hope this isn't too boring or wonky, but if it is, my apologies.

To state it simply, the first game presents the player with a sequence and the second dares you to break it. That first game and its sequence unfolds as follows:

Positioning ourselves in the room labelled START/MAP, the reader can probably deduce that the room is both the point in which the player starts the level and that it contains a map indicating your current position and that of your objective several floors down. To get from this top-floor to the bottom, you have to travel two rooms to your left, but the very first adjacent room contains a long bed of spikes. The player's radio-assistant explains that the force-bridge that should be covering the gap has been cut off, and that the switch to activate it, in classic video game fashion, is at the other end of the floor.

And so, the player embarks to the right, confronting her first enemies. These enemies are shorter than the player, thus necessitating that you position yourself on a lower platform before firing. With the most basic type of enemy, a small, unmoving blob without any kind of attacks, this is a piece of cake. It's a little trickier for his slightly-larger brother, who, while still stationary, spews out bullets that fling upwards before fluttering down at his sides. To defeat him, the player must get into position, fire rapidly, and then get out of the position before its bullets hit you.

The next screen takes this basic principle but ratchets it up considerably, also adding those sort of annoying moving-around-a-block-type enemies into the mix. On the previous screen, there was a health power-up (ala a Zelda heart container) at the end of a passageway the player couldn't reach; that passageway continues through this screen.

On the following screen (third from the starting point now) the player can see a way to access this passage, but it, too, is blocked by a bed of spikes. Perhaps the player can reach it after they turn on the switch, which is now tantalizing close. There's more to this screen, however; in order to progress to the right once more, the player must use a sort of spin/feathering move to extend their leap.

A brief digression: my earliest conceptions of this game had at its center an extremely nimble and athletic protagonist, able to wall-jump, wall-slide, dash through crevices, and a host of other parkour-y kind of things. I scaled it down considerably, not because they presented particularly difficult programming challenges (for wall-jumping and even ceiling clinging are vital parts of Run Jump) but because they gave the player too many options. And, don't get me wrong-- giving players options is the idea, and it's part of what the meta-gaming at the heart of the concept is all about-- but I realized I would be spending so much time explaining all these moves and turn the first level into one boring "now test this skill" after another. It might also overwhelm the player; if you give the player a dozen different moves and then say, now try to break this sequence, it can get pretty frustrating. But if their repertoire is intuitive and easy-to-grasp, they'll spend less time scratching their heads and more time figuring things out.

And so, I took away the wall-jump, the wall-slide, the dash-move, all the sort of parkour/free-running cliches. Now, it's just the basics: run, shoot, jump, with one simple-to-grasp wrinkle-- tapping the x-button in mid-air will execute a spin-move, slowing your descent.

Since I want to make sure the player is aware of this skill, I needed to put it fairly early in the first sequence. This particular spot, after the first two action-rooms but before the first mini-boss, also gives the player a bit of breather. I don't think it's usually a good idea to put a mini-boss right after a tricky bit of combat; the change-up gives the player a chance to relax and also builds up a subtle sort of anticipation.

And so, the next room is the mini-boss, which asks the player to move from a safe position to a dangerous one, attack, and then move back. The mini-boss has thirty hit-points, more than one would usually assign for such a creature, and there's a reason for that, so hang onto it.

After the mini-boss, we find the switch for the force-bridge. In that same room, there's a very small and easy-to-avoid bed of spikes. And you might ask, why put a tiny bed of spikes in this room with the switch? The reason is, as soon as you pull that switch, all the spikes in the stage are bridged-over. Whenever the player pulls a switch in a game, he or she should be able to see the results instantaneously. This is important, so I'm going to bold-face it in case you're just skimming along:

Whenever the player pulls a switch in a game, he or she should be able to see the results instantaneously.

Boo-yah!

Now the player back-tracks, and as we all know, back-tracking can be a pain. But it also can be a lot of fun, and it can be used as positive reinforcement. Now that the player's pulled that switch and the threat of the spikes are neutered by the force-bridge, she can take the high-road, breezing through the screens, avoiding enemies, and nabbing that health power-up, boosting their max HP. It further rewards the player for accomplishing this particular task, has them feeling good before they get back to the spike-bridge they wanted to cross in the first place.

Crossing the bridge, the player can now descend to the second level, only to find, one room over, another obstacle: a glowing barrier. There's no assistant this time to tell you where to go, because, this being a 2-D sidescroller, the only other choice is to go left.

Passing the elevator, there's another map room. Since I'm going with maps built into the physical terrain instead of in a menu, it's important that I include at least one map on every floor/wing. More than that, though, it tells the player that the room below is a dead-end, meaning that it probably contains the solution to that barrier.

And, voila!, it does, in the form of a laser or ray weapon. In the room with the power-up, there's another barrier, and on the other side of that barrier, another health booster. Firing into the barrier dissolves it momentarily, allowing the player to pass through it and get that health boost-- by now, she's doubled her hit-points. And, again, I put the barrier in the room with the weapon power-up so that the player is immediately aware of what it does and what it can do.

For the same reason, I put a couple of the enemies from the first floor in this room. While they took a few shots apiece before, a single laser-beam cuts both of them down in one fell swoop.

Taking the elevator back up and moving back to the first barrier, the player then finds themselves in a timed puzzle room revolving around firing the laser at the barriers. This is intended to further acquaint the player with the weapon, and to mark this floor as "the laser beam-heavy section of the level". I find that such a theme gives a game a better sense of flow and of place.

I also want the player to feel powerful with this laser beam, which is why the next room has a whole score of low-level enemies that can be taken out, every one of them, with a single shot. The following room pits the player against not one but two(!) of those thirty hit-point mini-boss creatures from the first floor. And they, too, are downed in one fell swoop. That's why I gave the first one so many hit-points. He was difficult, frustrating, time-consuming, and now? Now, he's reduced to a mere goomba by my laser-beam.

Having taken you through all this at some considerable length, I hope I've not only demonstrated some principles that could be useful to other independent game designers, but also given you some idea of the time, effort, and thought I've put into this first game-- the game that actually only exists to create a context for the second, for the "real" game that tasks the player with finding a smarter, quicker, easier way.

And, indeed-- it's possible to get the laser-beam before fighting that first mini-boss. It's possible to get to the third floor without flipping the switch or gaining the laser-beam at all. It's even possible to get through the entire first mission without picking up a single item or killing a single enemy.

All these things are not only possible but actively encouraged; when you first come to that pit of spikes blocking your access to the second level, your radio-helper will tell you about that switch on the other end, as I've already established, but he'll also say, "though I think you can probably figure out a better way if you put your mind to it" (or something to that effect). I also plan on implementing a trophy/achievement system that challenges you to, say, "clear the level killing no enemies" or "getting zero percent of the items" or "in less than one minute". And the player, confronted with that, will hopefully say to themselves, "Okay, so let's figure out how I do that."

The trophies, the dialogue, the title, and the steep enemy/platforming difficulty inherent in playing game number one is all intended to encourage the players to get good at game number two. And that couldn't and wouldn't work without having a playable, reasonable, well-paced game number one in place.

SEQUENCE BREAKER DEV. JOURNAL # 1

My next game is called Sequence Breaker. The name comes from the practice, especially prevalent in Metroidvania games, of doing things out of the proper order and/or skipping over chunks of the game entirely, usually by exploiting some incredible feat of gaming skill to get to places you're not supposed to be just yet.

In that the game is intended to encourage the player to look closely at it and to discover ways to "cheat", it could be considered something of an extension of Ultrageist.The difference is that Ultrageist, by dint of its three minute time limit, kinda bends the player to its will. If you don't figure out the little tricks, you don't get any farther in the game. Ultrageist was in many ways a deliberately frustrating game, in which nothing was explained to the player-- pretty much the antithesis of how one should go about designing a game. Certainly it was a very different process than Side Saddle 2, which was play-tested up the wazoo, as the various "making-of" videos can no doubt attest.

So one thing that sets Sequence Breaker apart from Ultrageist is that it's not being built to frustrate. The point of the game is to think more deeply, to tease out loopholes and then exploit them, but the game doesn't punish you for not figuring it out.

Another difference is, of course, that Sequence Breaker is a platformer. Shmups, by their very nature, only have a handful of rules and types of interactions, and as a result the potential for "bugs", loopholes, and exploits is relatively limited. Platformers, on the other hand, are complex enough to support this kind of meta-gaming on a large scale, and also to deepen it beyond Ultrageist's simple "at this part, do this" and "here, you do that". Too many of the levels took the form of this sort of schematic puzzle, and that's something I want to avoid in Sequence Breaker, something that I think the metroidvania formula will perversely help me to avoid.

Metroidvania games, after all, take the form of puzzles-with-obvious-schematic-solutions themselves. This ledge is too high, so we need a high-jump power-up, which is behind this wall of ice, so we need the melting ray, which is on the other hand of this lava pit, so we need a grappling hook. All that, just to get to the other side of a ledge. It's fun but also somewhat mindless, and not really all that "non-linear".

But by presenting the player with that sequence, and telling them, hey, see if you can break it-- it's right there in the title! (not to mention the dialogue)-- my hope is that the player will start really thinking about the game's rules, their character's abilities, and the "unintended" ways those can interact. As such, I find that I'm really designing two games-- one very tight and linear, holding the player's hand every step of the way, directing the experience as best I can, and a second one, that's looser, more non-linear, with multiple avenues for the player to pursue if they're not afraid to give it a shot.

And while that second game is what Sequence Breaker really is, what it's intended to be, the first one isn't just an after-thought, nor can it be dull. Because if the player chooses to play the sequence from start to finish, it still has to work, make sense, and provide the player with the pleasures inherit in the genre. And that will be the subject of my next dev. journal.