Side Saddle Series

• The player's weaponry controls the shorter horizontal plane.
• The player has access to "towers" which also attack enemy ships and draw their fire. These towers are placed after earning so many points.
• Bosses are comprised of multiple "parts" that are destroyed or reduced as the player attacks them.
  

Self-Identity.

I'm a board game designer now. I'll still dabble in video game design-- SEQ.BREAKER is still in the works-- but chances are this blog is going to be dormant for a while.

PLAYING HEXTOK

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 # 25: SAW BLADES (PART ONE)

When I write fiction, I can't skip around. If I'm stuck on a sentence-- a telling detail, perhaps, or a wisp of dialogue, or a character's name, or a macguffin-- I can't just skip ahead to another scene or sentence. I am completely stymied until I resolve the road block that I've made for myself.

I have the same problem in game design. If I know that this section requires the player to solve a couple of puzzles, and that section requires them to fight a boss, I can't skip ahead to designing the boss even if I'm absolutely stuck with regards to coming up with said puzzles. It's an irritating and counter-productive quirk, especially on an ostensibly non-linear game like Seq.Breaker.

But stuck I am, and of all things, I'm stuck on a sprite. Remember, I switched over to the current ultra-pixel-y style-- each sprite is comprised of 4x4 pixel monochromatic blocks with one pixel gaps in-between-- in order to avoid these kind of blockages and delays. But that very same style is actually part of the problem.

See, I want to confront the player with some circular saw blades that move up and down (and left and right) along a track. In a level partially populated by lumberjacks, a saw blade makes some kind of sense. It's also a concept a player can grasp pretty readily, as ingrained in their vocabulary as pits of spikes and fireball-spewing lava. Player sees a circular saw blade moving along a track, and the first thing they think is: alright, that's dangerous, I'm gonna stay away from it.

The problem is, it's very hard to render a circle in 4x4 monochromatic blocks with 1 pixel gaps, and even harder to put teeth on said circle in said method, and especially hard to get this to fit in a nice 32x32 pixel space-- or, to be more accurate, given the art style, in 11x11 monochromatic blocks.

Another problem is, if you look at any reasonably threatening saw blade, 2-D or otherwise, it's not the teeth that are scary, but the blur, the very speed with which the blade rotates. And this art style isn't one that blurs particularly well; in fact, the protagonist's walk animation looks appealing because it's been slowed down to the point that it cautiously emphasizes each frame.

I suppose the thing to do is to find something else that serves the same function, something that isn't so resistant to the art style I've grown rather fond of, but that would still make sense environmentally and be easily "read" as dangerous. But rack my brains as I do, I can't really come up with anything. I am, at the moment, really and truly stuck, and it's caused work on the game to grind to a terrifying halt.

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 # 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 # 20: OH NO MY BUTT

I just finished writing/implementing a short cut scene in which two lumberjack terrorists discuss the impossibility of the player breaching their sanctum and rescuing the kidnapped kittens within. At which point, of course, the player character darts past them.

Then their butts explode.

Yes, it's that sort of game.

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.

Wedge playtest.

Tonight, we had the first play-test for Wedge, my second board game. I was a little worried going in, because I wasn't quite sure if it was going to be fun or terrible. To make a long story short, I'm leaning towards the former.

Wedge started as a political simulation but quickly (and wisely) became about strategic spatial domination of the board. The game is for four players, divided into two teams, but only one player wins the game. On each turn, you decide whether to "work together" with your teammate, enabling each to also place one of their stones next to yours on your turn, or whether you want to "work apart"-- only you get to place a stone (sometimes two stones). The first player to get rid of all their stones win the game.

It's a little more complicated than that-- the teams build chains of stones to grant themselves bonuses and try to prevent the other team from getting a longer chain. And a "team loss" mechanic-- if you cannot make any legal moves, both you and your partner have lost the game and the player on the opposing team with the least number of stones wins by default-- allows players that've fallen behind to win the game with some cunning maneuvering. (At least in theory, anyway.)

With its hybrid of co-op and competitive game styles, I was, as I said before, really unsure if it was going to "work". I'm more sure of it now, but it's also been confirmed that it has a smaller appeal than something like Hextok. That game's points system allows for some speedy recoveries and reversals, and the head-on one-on-one competitive tactics play on a relatively small map has, thus far, proven to be pretty fast-paced and accessible.

Whereas Wedge-- at least from this single play session-- seems to be slower, knottier, nerdier, and much more unforgiving of mistakes and blunders. That's not necessarily a bad thing-- I'm sure there's an audience for it, just less of an audience than Hextok.

Speaking of the latter, the play-testing seems to be going quite well. (If anyone else wants to get in on the testing, be sure to e-mail me at joltcity at gmail dot com.) I might be organizing a tournament locally that will help promote Hextok (and get it some more testing, sneaky-sneaky!) and I'll try to document it in some way if it does come to pass. As for Wedge, I'm looking forward to seeing if it has legs, as soon as I can get four people in a room together again.

CALL OF THE WEST campaign setting.

Call of the West is a D&D campaign setting that melds high fantasy, the mythical Old West, and steampunk elements in more-or-less equal measure. In the mythos of this world, the gods split the great continent into two thousands of years ago with a river. East of the river, the land was civilized, ordered, prosperous, good, and safe. West, the land was a desolate waste filled with danger, mystery, evil, and monstrous beasts. The West has largely remained unexplored and forbidden. Until now.

Now, some children of the East feel drawn to the West. Some might be thrill-seekers enraptured with the promise of discovery and adventure. Some might seek understanding of the West or the reviled (perhaps unjustly) tribal gnolls that roam it on the back of giant turtles. Some might relish the chance to reinvent themselves in a strange new land, while others might be running to escape the responsibilities (or consequences) of their past. All the players are Easterners, and the first batch (more on this later) set out together on a wagon train.

I like this set-up, and it's intended to accomplish a few different things. First, it gives a bunch of strangers a more compelling reason to be in the same locale than, "Hey, you're all in the tavern and someone gives you a quest". (Of course, the first thing one of the players did when they got to the Dwarven mining community of Firepalm is look for a tavern and ask if there were any jobs that needed doing.) Secondly, at least potentially, it gives each player a specific motivation for being in the area, and thus a specific impulse that they can role-play. That also makes it easier for me to craft stories coming out of the characters and their motivations. Thirdly, the "let's just see what's out there"/road trip/no home-base-of-operations vibe allows for a more episodic "Dungeon-of-the-Week" structure. That way, it's alright for a player to miss a game, for new players or guest stars to join, without upsetting the sense of a cohesive world.

None of this is new stuff, of course-- but I find that by foregrounding it, making these features a deliberate part of the campaign setting itself, it makes it easier. The setting also makes ample room for my own personal D&D leanings. For example, with few civilized outposts the farther west the players move, there are no shops and thus no reason for the players to accumulate wealth; I never found "I just got 400 gold!" a particularly compelling reward. Instead of buying things, they'll find them-- a lot of hand-crafted pieces of loot. Instead of stocking up on supplies, it's up to the players to find the resources in the natural world that they need to survive (this is a harsh, barren West, after all).

The West also gives me more options, story-wise: not only do I have fantasy tropes to call on-- cursed tombs, monster-ridden dungeons, powerful artifacts, hordes of undead beasts, nefarious traps-- but I can throw in stagecoach robberies, revivalists, prospectors, temperance, Cowboys-and-Indians, drunken doctors, hookers with hearts of gold, showdowns at noon. This setting-- not exactly our West, but not exactly Medieval Europe, either-- allows for a more colloquial sort of speech than the sometimes stilted and flowery speech one associates with a fantasy milleau.

The Steampunk elements were a late addition to the setting-- one that's been shoehorned in, though with very little difficulty, because of player interest. One of my players created a Tesla-like Wizard named Irving, while another requested that his Filliam be an inventor with a repeating crossbow in place of one of his hands. You should have heard the giggles of glee when they crossed paths with an atypical gnoll in victorian dress wearing a bizarre pair of glow-in-the-dark goggles.

It's more, however, than just a bit of player fan-service, as it were. I soon came to realize that the steampunk elements bridge the gap between the two perhaps disparate settings of the Old West and your standard D&D fantasy world, in that certain aspects of steampunk are grounded in the West but that it possesses, above all, the thrilling sense of discovery and wonder that is part and parcel of D&D at its best.

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.

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?

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 # 16: DIFFICULTY AS DETERRENT

It is a truth universally acknowledged that extremely difficult games can be the most rewarding-- provided, of course, that the challenge is fair and arises from game design and not shoddy mechanics or programming. The greater the struggle, the sweeter the sense of accomplishment, et cetera: all common knowledge, old-hat, game design 101.

Seq.Breaker has a high difficulty level, but it's not intended to directly function in this same way. Rather, the difficulty is intended to be almost a kind of deterrent to taking a heads-on approach, a way to motivate the sort of outside-the-box player thinking upon which the game turns. If an area is much too hard, chances are there's a way to skip it; if a boss is giving you grief, there's some sneaky clever oh-my-god-I-can't-believe-I-didn't-think-of-it-before way to take him out of the picture. By making the game insanely difficult, I hope to get the player to work smarter and not harder.

And, if the player wants to man-up and do it the "correct", not-quite-impossible, non-sequence-breaking way, more power to 'em. There'll be that conventional sense of reward waiting for them on the other side. But if they break the sequence, I think they'll find an even greater sense of reward-- "I'm smarter than that lava boss, so there."

And either way, you'll always unlock the next mission; there's no penalty for playing the game you want to play it. That's important to me, and I need to keep that in mind as I continue working on the game.

SEQ.BREAKER DEV JOURNAL # 15: DOING IT WRONG ON PURPOSE.

Brief update: back to work on the game after a couple weeks of hiatus. I've decided to use water in this second mission; said water gives a player an air meter to contend with (at least until/if they pick up the Scuba Power-Up or some-such) and imbues them with a "floaty" jump (think Mega Man).

In implementing the "floaty" underwater jump in Game Maker 8, which involved tweaking both the gravity in the step event (but only when a certain variable was triggered by colliding with my deep_water object) and the vertical speed in the jump event (your jump speed is -4 instead of the usual -5, which, combined with the lower gravity acting upon you, gets you higher up but at a slower speed). In implementing this, and, most importantly, the constantly-resetting alarm events that turn this special jump off, I realized that I could approach this two ways: one way was solid and elegant, ensuring that the player only floaty-jumped when I wanted them to; the other way was an inelegant work-around that allowed them to get to places they weren't supposed to be. Seq.Breaker being the name of the game, I chose the latter, and it was kind of fun to create the coding equivalent of a Rube Goldberg machine-- i.e., going out of my way to make it more complex than it needed to be and intentionally buggy.

D&D Adv. # 1: The Curse of Firepalm Mine!

So, after roughly sixteen years of hemming-and-hawing, I finally ran my first game of Dungeons and Dragons today. It is, in fact, only the third or fourth time I've been present at a D&D game-- a grievous lapse in my geekery, to be sure. How did it go?

It went okay. At the start of the session, I tried too hard to set a certain atmosphere that ran counter to the rather goofy, rambunctious mood of the players; I also tried too hard to try and get them interacting with each other.

Things got better once they descended into the dungeon-- the Firepalm Mine in question. I made a few pretty questionable lapses in design that only became apparent roughly five seconds before they came into play: among them, the fact that, in giving them the quest to discover what was going on at Firepalm Mine, the mayor of the Firepalm settlement asked them to return with a bag of Firepalm Ore, and that said bag of ore was part of the loot on the body near the entrance to said mine. One of the players tried to convince the others to just go back to town at that point-- which was a nice bit of role-playing on his part that gave the others a foil to bounce off of. I could, I suppose, have just conveniently "forgotten" that that particular piece of loot was on the body, but I figured since it would come in handy in the big fight, it was better to let them find it. Of course, because it was something that was needed to complete the quest, they never took it out of the bag.

Speaking of fights, I had two of them. First, was a tense ambush encounter in which six gnolls (four level one, two level two) close in on the players from two sides, trying to pincher them in. This one was pretty tough, and took up most of the session in resolving. I figured it would be longer but far less challenging than the second encounter, which pit them against three "firedwarfs"-- that is, insane dwarfs who are constantly aflame and catch the players on fire with their melee attacks, made up of two level twos and one level three.

But the players never came close enough to the firedwarfs to be on the receiving end of one of those melee attacks, using a number of ranged attacks to chip away at what I thought were impressive health numbers. The other problem, though, is that I had given the players a custom-made Ritual Scroll just before this final encounter. And while, yes, I totally intended for them to use The Ritual Scroll of Blunderbuss Time, I thought it would give them a little edge in a tough battle. For some reason, it never occurred to me that giving the players two turns in battle for every one of the enemy's turns would make it ridiculously anti-climactic.

So: my enemies weren't tough enough, my loot was too good, and my ability to improvise-- which led to me pulling a last-minute and not-entirely-consistent-with-the-story-clues What-A-Twist finale pretty much out of my ass-- was kinda sucky.

But, the players seemed pretty satisfied with my dungeon-mastering, and everyone seemed to have a lot of fun (even if interest lagged from time-to-time). So, I'm very glad I did it, and I very much look forward to running my next (and hopefully improved) game a fortnight from now.

Video Games Need More Gay

Click To Play

"Wedge".

I came up with a new board game yesterday while I was recovering from my surgery. So far, it's pretty terrible.

Most games-in-the-works are terrible because they're too complicated, with layers and layers of rules and systems obscuring the Bright Shiny Fun at the center. But in this case, it's just the opposite: it's all center, and right now it's not particularly Bright, Shiny, or Fun.

I think it can be, though. The idea at the center is that you, and the other players, are trying to win voters by shifting your position on unnamed wedge issues or by forging alliances with your competition. It's a wonky, geeky, nerdy kind of idea, but I think it's one that can result in some interesting inter-player dynamics. But right now, it's boring as hell. It's lacking That Special Something-- that mechanic or compelling goals dichotomy or flow-of-play-- that makes it worth playing.

I found that special something with Hextok, I think-- I'm really happy with the game, happier perhaps than I've been with anything I've created (book, movie, video game, you name it). We'll see if I can't get lightning to strike twice here.

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.

The Two Rules of Game Design

There are many rules to designing games. Above all, there are two game-design rules that control all others. First, and most important is:

Keep It Simple.

The second rule is nearly as important but is a bit more complex in its use. The second rule is:

Plagiarize.

Plagiarism is a dramatic way of saying, "Use available techniques." If you try to plow too much new ground, you're not going to get very far, and you will have an extremely difficult time in keeping your game sufficiently simple to be manageable.

-- James F. Dunnigan, The Complete Wargames Handbook (Revised Edition, 1992), p. 114

Offered not because I necessarily agree or disagree, but to spark thought and discussion.

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 DEV JOURNAL # 12: "NINJA LOOT!!!"

The biggest challenge with this project has been trying to create an in-game context for the sequence breaking. I'm not talking about the narrative back-story-- to recap, the protagonist is a "breaker" famed for finding creative solutions to what would otherwise be dangerous and time-consuming covert military situations-- but about motivating the player to break a given sequence. Remember, I don't want to punish the player for not exploiting loopholes by denying them access to the rest of the game (the way I did with Ultrageist).

I think, however, I've found that solution, and like so many things in the last few days, it came with the game's new aesthetic. When I had intended to take a more realistic approach to the game's graphics (and physics), I had tried to encourage sequence breaking through lots of support character dialogue and cut-scenes; break the sequence, I was saying, and you'll find out what really happened in the Colonies. But this approach wasn't particularly compelling.

The support dialogue and mystery story elements seem out of place in the spare, simple world of Seq.Breaker as it exists currently. That's when I started playing with the idea of some kind of silent rival; what if the rival swooped in (in classic villain fashion) and stole whatever you were after once you had done all the hard work for him? And what if you didn't do the hard work-- what if you, well, broke the sequence? He wouldn't be able to do his swooping. And if the player failed to break the sequence, maybe the scene with the rival could impart some kind of information, some hint or clue, as to how they might approach it when trying the mission again.

This all came together in my head in about the time it likely takes you to read this sentence, and the end result is the Ninja:
My hope is that when that smug, smarmy Ninja shows up and steals the macguffin, you'll want to show him; given the opportunity to either retry the mission or move on to the next, you might be more inclined to retry. Giving the player a villain that can only be thwarted by breaking the sequence, I think, proves a better motivator than having people yakking your ear off about how creative you are or watching the protagonist moping about in her room.

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.

Game Maker .DLL Recommendation: Sin Bass

For all my previous games, I've employed MIDI format music-- sometimes to my composer's chagrin. I'm just not what you'd call a technical person-- one of the prime reasons that I use the Game Maker program!-- and my previous attempts to implement other formats (like MP3 or ogg) or to use .DLLs have fallen woefully short.

At least, they did until I came across the Sin Bass DLL on the Game Maker Community forums. This .DLL, created by Sindarin, and its accompanying set of scripts, makes adding high-quality music, and applying all sorts of nice bells-and-whistles, such as fades and pitch adjustments, so simple that even Tom Russell can do it. My composers, both for Seq.Breaker and Side Saddle 3, are as excited as all get out.

If you're still using MIDI music, and you'd like to step up your game, Sin Bass is a great and accessible way to do it.

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.