Second Party Games

Side Saddle Series

2011-03-28T09:51:00.000-07:00

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.

2010-12-06T15:08:00.000-08:00

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

2010-11-02T16:24:00.000-07:00

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

2010-10-08T14:56:00.000-07:00

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

2010-10-03T12:25:00.000-07:00

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)

2010-09-22T20:04:00.000-07:00

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.

2010-09-10T10:50:00.000-07:00

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

2010-09-08T20:04:00.000-07:00

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

2010-09-06T20:57:00.000-07:00

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

2010-09-06T12:07:00.000-07:00

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!

2010-09-03T19:41:00.001-07:00

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

2010-08-28T19:40:00.000-07:00

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

2010-08-27T21:37:00.000-07:00

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.

2010-08-26T08:35:00.001-07:00

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.

2010-08-25T22:42:00.000-07:00

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.

2010-08-25T19:16:00.001-07:00

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.

2010-08-24T13:27:00.001-07:00

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

2010-08-23T09:12:00.000-07:00

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.

2010-08-22T18:25:00.000-07:00

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

2010-08-22T00:34:00.000-07:00

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

2010-08-20T14:50:00.000-07:00

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.

2010-08-20T07:56:00.000-07:00

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!

2010-08-15T23:49:00.000-07:00

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

2010-08-14T16:34:00.001-07:00

Click To Play

"Wedge".

2010-08-10T15:10:00.000-07:00

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

2010-08-09T08:08:00.000-07:00

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

2010-08-08T08:20:00.000-07:00

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

2010-08-07T21:45:00.000-07:00

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!!!"

2010-08-04T22:17:00.000-07:00

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.

2010-08-03T23:16:00.000-07:00

SEQ.BREAKER DEV JOURNAL # 11: PRODUCTIVE 24 HOURS

2010-07-31T16:48:00.000-07:00

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

2010-07-30T09:38:00.000-07:00

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.

2010-07-12T20:00:00.000-07:00

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

2010-07-08T21:12:00.001-07:00

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

2010-07-03T10:38:00.000-07:00

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

2010-06-30T21:48:00.000-07:00

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

2010-06-24T11:28:00.000-07:00

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

2010-06-20T20:33:00.000-07:00

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

2010-05-19T12:56:00.000-07:00

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

2010-05-08T16:46:00.000-07:00

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

2010-05-06T15:05:00.000-07:00

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

2010-05-05T20:09:00.000-07:00

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

2010-05-04T22:08:00.000-07:00

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

2010-05-02T19:30:00.000-07:00

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.

Let's Play Wootman: Zero

2010-04-02T11:00:00.000-07:00

Ultrageist Update

2010-03-16T16:35:00.001-07:00

Besides the graphical changes, I've changed the fire button as the previous arrangement seems to have prevented diagonal movement on some keyboards.

You can download it either from Yo Yo Games or Game Jolt. Game Jolt gives me a small royalty-- by small, I mean, a fraction of a penny per download-- so I'll link there.

ULTRAGEIST FINISHED AND RELEASED.

2010-03-13T16:25:00.001-08:00

http://www.yoyogames.com/games/119293-ultrageist#

Ultrageist Diary # 20

2010-03-12T22:19:00.000-08:00

Spriting for the final boss. I have to keep him in tune with the game's over-all aesthetic (blocky, symmetrical, very "sprite-y") and make him big enough to fill the entire width of the screen. Given the dimensions of the screen, this makes him very rectangular. The other characters, both enemies and bosses alike, are very square or circle, very compact, and the art style is fairly simple and uncluttered to reflect this. This boss, being so rectangular, needs some other shapes to break up that dominant shape, to make him more-- well, organic isn't quite the right word, what with the armour and everything, but less like a long ugly box.

Making a change to the third boss that cuts down the time required. I am, however, making the margin for error less forgiving-- i.e., taking damage will restore a lot more of the boss's hp.

Ultrageist Diary # 19

2010-03-12T20:20:00.000-08:00

Having some trouble with the sprites for the last boss-- I want the sprite and its various states of disrepair/blow-up-i-ness to be really spectacular and satisfying and I'm not feeling particularly inspired as of yet.

However, I do know exactly what I want to do for the boss's attacks and how I want the fight to "feel", and I've actually created the objects I need to do that-- just without sprites.

This last fight should depend more on skill and reflexes, and so there isn't an overriding strategy or trick this time around other than, "hit him with your bullets" and "don't get hit by his bullets". Elegant, simple, shmuppy.

Hopefully I'll wrap my head around the spriting during this next week.

Ultrageist Diary # 18

2010-03-09T01:08:00.001-08:00

Changing the bosses from "gods" to "memories", with each memory given a somewhat obtuse title.

When they were gods, each of them went through a number of names-- first, nonsense names, intended to ape the sort of eldritch abominations you'll find in Lovecraft, then poorly-translated Esperanto versions of nonsense phrases, then joke names. The latter included Death Crab for Cutie.

With this current naming convention, the words on the screen have some kind of meaning without detracting from the mysterious atmosphere that Mr. Crane's wonderful music evokes so well. Puns and gibberish get in the way of the experience.

There's a danger, of course, with people investing too much meaning into these "memories"-- this isn't a story game, or one with any kind of deep philosophical theme. And then there's the danger of people being turned off by this naming convention, who would think it a bit pretentious or arty-farty.

Which isn't my intention. I'm just trying to make a neat shooter. Here's hoping I'm able to strike the balance.

Going to bed now. Tomorrow I'll see if I'm happy with these names and that third boss. If so, it's on to the final boss.

Ultrageist Diary # 17

2010-03-09T00:34:00.000-08:00

Happy accident: an unintended result of the collision code for a certain part of the second boss allows the canny player to hit it with several spread-shots at once, skipping over an entire attack pattern. It is now possible to defeat that second boss in about the same amount of time as the first.

I was so pleased to stumble upon this "mistake", as it's exactly the kind of thing I've been trying to build into the game from the start. And I don't think it'll be very hard for others to stumble upon it as well.

In other news, I think I've finished the third boss. He's very different than the others: instead of firing bullets, he uses his body; he has a small weak-point, surrounded by armor that deflects the player's shots; he requires the sort of careful timing that makes for fun boss fights but doesn't lend itself particularly well to the "I-just-beat-the-boss-in-10-seconds" feeling that you might get with the first two.

To compensate for this-- after all, I can't expect a player to beat the whole game in three minutes if there's a boss that deliberately gums up the works-- this boss takes more damage-per-hit than the others. And to compensate for that-- because, after all, I don't want it to be easy-- the player takes more "damage" from coming into contact with the boss and so there's less of a margin for error.

A mistake in this game, especially in the boss battles, can cost the player dearly, and that goes double for the last two bosses.

Ultrageist Diary # 16

2010-03-08T18:36:00.000-08:00

Some screen-shots from level three.

As you can see, these enemies have a trail effect, which helps to emphasize their speed. These enemies are in constant motion, whereas earlier enemies come to frequent stops.

I briefly tried adding a trail effect to the third boss, but because the sprite is much larger, it didn't have the same effect-- instead looking rather ugly and clunky.

I'm trying to iron out a couple of technical crinkles in the third boss. Assuming I can overcome them this week, and that the fourth and final boss is going to come together as quickly as I think it will, the game should be done by the 20th at the latest-- ten days before the deadline.

Fingers crossed.

Ultrageist Diary # 15

2010-03-02T22:23:00.000-08:00

Scratch that. Part of it, at any rate.

Level three has one enemy type, with one hit point, and a constant attack aimed at the player, creating a sea of bullets. Player must strike a balance between safety (i.e., blowing them away) and abusing the bonus system to fill up the bar (i.e., putting that bar at greater and greater risk). Not a mental decision but a twitch decision.

Going to sleep on it, and if I still feel good about it, I'm going to get started on those last two bosses.

Ultrageist Diary # 14

2010-03-02T21:10:00.001-08:00

As stated before, levels one and two each feature two enemy types, a popcorn unit (low-defense, relatively low-offense) and a tank/sponge (high-defense, lots and lots of bullets).

Because I want level three to ratchet up the intensity, to be slightly more spastic, I'm not going to go the same route. Instead, I'm going to create two or tree units that combine popcorn-unit style defense (that is, units that can be destroyed with one or two shots) and tank-unit style offense (that is, a helluva lot of bullets).

While the same basic mechanic from the first two levels can and should be used (and abused) by the player, the third level should manifest itself in a less strategic, more reflexive manner.

Fingers crossed.

Ultrageist Diary # 13

2010-02-28T12:37:00.000-08:00

It's possible for high level players to beat first two levels and bosses in <1 minute.

Ultrageist Diary # 12

2010-02-28T12:26:00.001-08:00

One thing that the first two levels have in common is that each stage has two enemies: a powerhouse unit/damage sponge paired with several weaker, popcorn-type unit. The mechanic that the player can exploit to breeze through the first level and that the player must exploit to breeze through the second is dependent upon these two units. It makes sense, then, that the third level will also feature two units that react in a similar way.

It being the last non-boss level, it's important that it also be the most hectic-- especially since the second level is really more of a puzzle level. I want to reinforce that this is a shmup and that reflexes count.

Ultrageist Diary # 11

2010-02-26T00:41:00.000-08:00

The second boss is complete.
As I mentioned in a previous entry, part of the second boss can only be defeated by using a trick that speeds up the first boss. My thinking, again, is that if a player does slowly eke his way past the first boss, when he gets to the second and figures out how to damage him, the player will put two and two together and apply this new knowledge to the first boss the next time he plays the game.

My composer for Side Saddle 2, the immensely talented Nathanael Crane, is hard at work composing the three minute theme for Ultrageist. The music acts a sort of progress indicator in its own right, an auditory supplement to the time bar: the player will hear a specific musical phrase and know roughly how much time they have left, as in "Hey, this is that really kickin' part, so I'm about half-way through my time" or "oh, crap, here comes those notes, I'm down to the last minute, I'm never going to make it!"

More than indicating progress, it's also intended to instill a feeling of progress from play-through to play-through-- "last time I was only on level 2 when the music started speeding up, now I'm on level 3, I'm doing better at this". That's the feeling I want the player to have-- the feeling that they're getting the hang of it, that they're improving, becoming cleverer, that they're rapidly approaching mastery.

Ultrageist Diary # 10

2010-02-19T15:16:00.000-08:00

Decided to redesign the second boss from scratch. If the second level, as I stated previously, is intended to make sure that the player has grasped the concept under the surface of the first level-- that is, what makes progress quicker in the first level is necessary for progress in the second-- then the second boss should serve the same function: the "trick" or strategy that will allow you to blow past the first boss in a matter of seconds is out-and-out required to beat the second boss.

This poses a couple of problems with the game's visual language and rules, and I'm in the process of trying to balance all these concerns in a cohesive, non-rule-breaking way.

Ultrageist Diary # 9

2010-02-16T20:44:00.000-08:00

Play-testing is an important part of game design, not because it allows you to make sure the game is bug-free-- though all games should be bug-free, I'm looking squarely at you, Elder Scrolls IV, rassum-frassum no reversing-vampirism on the PS3 Game of the Year Edition-- but because it makes sure that the game just plain works: that puzzles can be solved, that goals are clearly stated, that the HUD is easy to understand, and that all the various systems and rules can be grasped in the blink of an eye. In some of my making-of videos for Side Saddle 2, I explained the vital role play-testing played in making sure the game was playable.Play-testing for Ultrageist, however, is a trifle bit trickier. Part of the whole point of the game is that very little of how the game works is explained; it's up to the player to suss out how the various elements of the HUD work together, to stumble upon "flaws" in the system that can be exploited for maximum benefit. It's possible to basically skip over the second and third levels straight to their boss encounters, and in all likelihood it'll be necessary for most players to do just that in order to get to the final boss.

It's the very opposite of intuitive and accessible, on purpose, though not, I must add, in that annoying I Wanna Be The Guy way. This game isn't about frustrating the player, but about the player overcoming frustration: the game plays fair; the rules are consistent and make sense, it just takes a little more time to figure out what those rules are and a little bit of strategy to get 'em to bend in the direction you want.

If the whole point of play-testing is to see if most players can grasp A and B, then a game in which the player has to slowly come to realize A and B is a hard game to play-test. Is the player confused because I did it wrong, or because I did it right? When they get the first of their big "A-ha!" moments, is it because it was well-designed or is it because it was badly designed-- for even in a badly designed game a player will eventually be able to put the pieces together if they play it long enough.

It's a tricky question, and my first round of play-testing didn't get me any closer to an answer. Though it did influence my decision to make the second level more of an overt puzzle level; the optional "trick" that lets you breeze past the first level more quickly is no longer optional in the second level but rather necessary to your progress. The puzzle format allows the game to hint at this particular system more overtly. My hope is that a player who slogged and fought his way through the first level will get stuck on the second level, figure it out, and then breeze through the first the next time around now that they're armed with additional intel. I'm starting to figure this out, I'm getting better at this: that's the feeling I want the player to have as they unlock the mysteries, such as they are, of Ultrageist.

Ultra Geist Diary # 8

2010-02-15T11:36:00.000-08:00

My notes for the second level and boss. Secrets revealed?

Ultra Geist Diary # 7

2010-02-15T09:57:00.001-08:00

I've got the first boss to where I want it and I've made some changes to the HUD.

The orangey-red blocks under the time meter act as a progress meter, with one slot for each stage and each boss. This is meant to give the player a better sense of where they are in the game, and to up the tension (i.e., I've got three slots left but I'm down to my last minute!).

You'll also note some numbers on the bottom of the screen; this is how much you've scored from destroying a given enemy. The game doesn't actually keep track of a numerical score; killing enemies really just fills up the XP bar in the upper right. But I want to cement the idea that killing certain enemies fill up that bar faster than others, and that doing so when the multiplier (between the two bars at the top of the screen) is higher will do so even faster. Just looking at the bar might not do the trick; a higher number is easier for players to grasp.

Onto the game's first boss, or "god":

I'm not going to say much about the above, other than the obvious: as the player depletes the boss's health bar (which doubles for the XP bar) and blows off chunks of its armor, it starts doing different sorts of attacks. It's possible, I've found, to beat the first boss in roughly ten seconds, and indeed the secret to doing so is revealed in one of the above screen-shots.

It's also possible, however, for this battle to last the better part of two minutes-- not the best turn of events for the player, given the game's over-all three minute time limit. This is due to the system that's been put in place of death in this game; taking damage in the multiple enemy stages will deplete your XP meter, while taking damage in a boss fight will increase the boss's health meter. I think this actually ups the stakes more than the traditional "get hit and you die" or extra lives system.

Ultra Geist Diary # 6

2010-02-13T10:36:00.000-08:00

I scrapped my previous plans for boss (sprite) design and went with something a little cleaner. The first boss's sprites are done-- there are fourteen sprites for this first of the four projected bosses.

Enemies and bosses alike in this game are squishy pink tentacle things with armor, and when you kill an enemy, the armor falls off into multiple pieces-- the bigger the enemy, the more pieces. With the bosses, the armor falls off during the course of the battle-- a chunk here, another couple when you reach this threshold, etc., giving the player a greater sense of accomplishment. At least in theory.

Will post more, including pictures, when I have more to post.

Ultra Geist Diary # 5

2010-02-07T18:39:00.001-08:00

Spent most of the day slowly trying to put together a large (400 pixels wide) boss sprite. Large sprites always give me a hard time-- I always end up getting overwhelmed by the canvas and am almost never happy with the results. One reason why the bosses in Side Saddle 2 were orb-based is that it made it that much easier to create a boss one 24x24 sprite at a time.

What I'm doing in this case is going for a deliberately ugly look. The creatures in Ultrageist are squishy pink tentacled things that wear armor, and so the bosses are squishy pink tentacled things entangled with various pieces of armor, hardware, and weaponry.

When I have that first boss sprite finished, I'll share it in another blog post.

Ultra Geist Diary # 4

2010-02-06T21:59:00.000-08:00

First screen-shots. Haven't put in background yet. Sprites are appealingly blocky/symmetrical-- well, appealing to me, anyway. I'm using the explosion sprite that's packed in with Game Maker 8, because I like it very, very much-- otherwise, it's all me, baby.

The HUD: time meter on left, score/experience meter on right, w/ score modifier in the middle, tied to the number of enemies onscreen at a time. This, I think, will be one of the dominant mechanics for the player to exploit-- being smart about how you approach this modifier in the first stage, for example, can shave thirty seconds off your time-- thirty seconds being awfully precious in a three minute shmup.

Discarded the power-up system I was thinking of to keep the game more focused; I think I need to add some kind of progress indicator, though, so that you know which stage you're on and how many stages you have left to go. Would like to do this in a visual, bar-based or intuitive way as opposed to a "level one/two/three" text.

As you can see, there are two weapons in the game. In keeping with Yo Yo's contest rules, both weapons use the same action button. I'm actually going to try to squeeze in a third if I can get the button timing right and if it doesn't complicate things too much.

Ultra Geist Diary # 3

2010-01-30T20:14:00.000-08:00

It's important that as I create my enemy types, I don't lose sight of the simple, fast, satisfying, destructive charm of the shmup genre in the first place. I'm dropping my idea for a reverse popcorn unit because I don't want the player to have to scratch their head as to how they're going to beat this particular enemy. I want the player to be able to kill things with ease.

The puzzle aspect, such as it is, is not about figuring out how to play the game, but figuring out how to play the game better.

Ultra Geist Diary # 2

2010-01-29T19:13:00.001-08:00

When I'm in the early stages of a project-- or, to be more precise, when I've just finished a project-- I flail around a lot, falling in love with and then abandoning concepts left and right, until I put enough effort into one project or another that I feel like I better see it through. It's awfully annoying for those around me, not to mention those working with me on one or another of these projects, not to mention on me, period.

I've restarted Ultra Geist from the ground up about six times now-- a bad sign for my "quick little game"; I've started three or four completely different concepts for Yo Yo Games's Competition 5, one of which I documented earlier on this blog, four of which were shmups, and put a considerable amount of time into both coding and spriting all the various iterations. And they've all been pretty much tossed away.

My current plan is to take a couple of new ideas for Ultra Geist, combine them with some ideas my recent slew of abandoned shmups have stirred up, and basically make Ultra Geist the competition game I've been meaning to work on. We'll see how that works.

Right now, I'm trying to figure out the various types of non-boss units to populate Ultra Geist.

I definitely want a popcorn unit-- a term I stole from Warren Spector, an enemy that doesn't pose much of a threat to the player and can just be swatted away like a piece of popcorn. Think: a goomba: slow, dumb, easy-to-kill. Get a lot of them on a screen, and now they're more dangerous, but not overwhelmingly so.

Conversely, I want to have a sort of anti-popcorn unit. I'm not talking about a tank or damage sponge, though one of those might be nice, too-- I'm talking about a numerous, dumb, slow, and mostly harmless enemy that can't be killed easily, that can't be harmed directly but only through harming other enemies or causing other things to happen that then cause things to happen to the anti-popcorn unit.

This is because one thing I want to do is create units that interact with each other, a sort of web that the player has to untangle and then exploit. How well I can pull this off in a fast-paced shmup is the million dollar question, especially because I don't want it to devolve into a trial-and-error, figure out what-does-what sort of game. I want it to be intuitive, and I want there to be some strategic depth that's a step above "kill these things to do this".

I want the player to have options, different ways to approach it, different ways to maximize their play-time and different but related mechanisms for the players to exploit. The whole point of the game, again, is gaming the system, is looking for "bugs" and holes, is, well, "cheating".

YoYo Comp 5 Entry, Behind-the-Scenes No. 1

2010-01-02T23:40:00.000-08:00

Yo Yo Games is holding their fifth competition, with the theme of "Design a Hand-held game". Games in this contest have to meet certain technical restrictions, the most daunting of which, for me, is that the controls are restricted to the four arrow keys and one (and only one!) action button. Since even my shmups-- the simplest of my games!-- typically have two if not three action buttons, this posed more of a challenge than the restricted screen size.

My answer, at the moment, is to make a sword-fighting game with a heavy emphasis on blocking-before-counter-attacking, timing, and figuring out patterns. That's right: it's Punch-Out!!, but with swords.

More daunting than the basic coding (which is basically done) and enemy behaviours are the spites-- one for each player attack and block, one for each enemy block, and two for each enemy attack (a "taunt" or "tell" followed by the actual attack). I'd like the game to have more of a "cartoony" feel than an "obvious collection of coloured squares of equal size" feel, and the single-screen action would allow for decently-sized sprites despite the low screen resolution. Maybe 100 pixels tall for the player, 150 for the bosses?

Either way, as you can see from the basic player poses I sketched out below, appealing art isn't exactly my forte-- if anyone would like to volunteer their spriting services, I'd be willing to split the prize money (should, of course, the game win) 50-50 with them. Drop me a line at milos_parker at yahoo dot com if you're interested.

Original Side Saddle featured in "100 Games" Video!

2010-01-01T10:31:00.000-08:00

This video, inspired by Paul Eres's "100 Game Maker Games in 10 Minutes" compilation, features 100 games made with Game Maker in 2009. My game Side Saddle is the 47th (the games aren't presented in any ranked order). I am deeply honoured to have my odd little game featured alongside so many other, greater, games, and want to thank Scoz of the Game Maker Blog for including it.

As I'm sure readers of this site are aware, the second Side Saddle came out just a week ago. In that time, it's already surpassed the number of downloads/quick plays of the original on Game Jolt (the original is also available at a few other sites, including Yo Yo Games, whereas Side Saddle 2 is available exclusively at Game Jolt.)

And, since you can never overdose on awesomeness, here's Paul Eres's original "100 Game Maker Games in 10 Minutes" video.

Ultra Geist Diary # 1

2009-12-29T22:18:00.000-08:00

As I prepare to get back to work on our new feature film, and requiring a small diversion to fill my time between my last big gaming project and my next one, I've decided to make a quick, small, experimental game. In this case, "quick" likely means I'll be done with it in two months instead of seven, but so it goes.

This project, Ultra Geist or Ultrageist (haven't decided which yet) draws its inspiration from a number of sources. As is often the case with my games (and the films I make with my wife, for that matter), the kernel for each new work is often contained in its immediate predecessor. With Side Saddle 2, I strived to be as accessible as possible-- offering hints for each boss, explaining precisely how each trophy was to be earned, and making it fairly easy for even the greenest of shmup players to unlock all the bosses. And so, with this game, I thought it might be fun to go the opposite route-- to make the game as inaccessible as possible, allowing the player to discover pretty much everything on their lonesome. (In fact, I'm very seriously toying with writing instructions-- in Esperanto.) There's a tricky balance to strike here, and I'll probably talk about my efforts to do just that as work on the game progresses.

Side Saddle 2 features a bonus game, a "three minute shmup" named after the second boss, Metal Nautilus. Since Side Saddle 2 is a bit more methodical, I wanted Metal Nautilus to be a simple "blast-the-hell-out-of-everything-and-dodge-their-bullets" shmup. Each new stage is unlocked when the player reaches certain score thresholds, and the player is given three minutes to progress to the final boss stage by earning a 1,500,000 points. This is accomplished by using your weapons to rack up combos; racking up high enough combos allows you to skip entire levels/waves of enemies, thus maximizing your play time.

I like this basic mechanic because it encourages sequence-breaking, which encourages the player to look deeper at the game on a systemic level, which in turn helps them become better at the game and feel that sense of achievement. In Metal Nautilus, however, the mechanic isn't delivered on in a really deep or expansive way (nor is it meant to); the system is really paper-thin and doesn't require much strategy outside of "shoot things and don't run into the bullets". I think with Ultra Geist I can build a system that rewards the player's deepening understanding of it, a system with a number of "loopholes" to "exploit" built right in.

Which brings us to another influence: New Super Mario Bros. Wii, and, in fact, most of the 2D Mario games. A famous consequence of the "domino-effect" scoring system in the original Super Mario Bros. is the turtle on the staircase in 3-1; you can jump on the turtle over and over again without touching the ground to rack up dozens of lives.

The creators of New Super Mario Bros. Wii take this loophole, extend it, and build levels around it-- even going as far as to create videos to show players how to rack up "infinite 1-ups" through various feats of incredible skill. That is, they're encouraging the players to step up their game.

What I'm endeavoring to do, then, is to create a quickie shmup that revolves around this sort of "meta-gaming", around discovering and exploiting "mistakes" and "unintentional" consequences. We'll see how that goes.

SIDE SADDLE 2 RELEASED!

2009-12-25T17:11:00.001-08:00

Merry Christmas.

And, hey, how's about a contest?

You heard the man! Upload three game play videos-- that's a perfect "no collisions" run-through for bosses eight, nine, and ten-- and post a link in the comments field below. Good luck!

Side Saddle 2 Trailer

2009-11-27T10:51:00.001-08:00

SIDE SADDLE 2 DEVELOPMENT VIDEO # 7

2009-11-27T01:34:00.000-08:00

This is likely the final development video before the game's release in December.

And, just so you don't have to dig around for the others, here's an embedded playlist. All the videos together run just over 13 minutes.

Escape From Teh Big House FINAL VERSION

2009-11-26T11:19:00.000-08:00

Just what it says on the tin.

SIDE SADDLE 2 DEVELOPMENT VIDEO # 6

2009-11-01T10:10:00.001-08:00

The Home Stretch

2009-10-31T20:47:00.000-07:00

Fun With Boxes

2009-10-21T21:18:00.000-07:00

After designing the "box" for Side Saddle 2 (as featured on the opening screen and instructional PDF), I thought it might be fun to design boxes for my other games as well.

You can play Run Jump or the original Side Saddle at Game Jolt; links are at the side.

SIDE SADDLE 2 DEVELOPMENT VIDEO # 5

2009-10-18T22:16:00.000-07:00

Side Saddle 2 Development Video # 4

2009-09-23T17:52:00.001-07:00

Side Saddle 2 Development Video # 3

2009-09-17T17:42:00.001-07:00

Escape From Teh Big House

2009-09-04T17:49:00.000-07:00

I'm working on my first LBP level. Here's a look at the first version (I'm redesigning the whole thing from scratch, as is often the case with any game or level design I do).

Just to Clarify...

2009-08-16T12:05:00.001-07:00

In one of the earlier posts, I mentioned a sort of growth mechanic-- the longer you go without firing, the more powerful those shots become, but also the larger, thus making you a bigger target. And while the idea of trading off vulnerability (size) and power is still an appealing one, it's not one that I'm exploring in this game, as I think the last video makes clear.

Side Saddle 2 Development Video # 2

2009-08-14T01:48:00.001-07:00

SIDE SADDLE 2 DEVELOPMENT VIDEO # 1

2009-07-12T18:33:00.001-07:00

Side Saddle 2 Development Blog # 5

2009-06-30T18:34:00.000-07:00

I'm not ready just yet to reveal any of the enemies for my boss battle shmup Side Saddle 2, but I am ready to give everyone who might be interested a glimpse at the HUD and some of the basic mechanics.

The little red fellow with the two dots extending out is the player's ship. The dots themselves are his bullets. Pressing the X key causes those bullets to extend outwards for nearly the length of the playing field and then, after roughly half a second, they retract back inwards. You can only fire out the sides-- there's no diagonal shooting as there was in the original Side Saddle. And while I've done away with the first game's ammo mechanic, you're still somewhat restricted as you only have the two extending/retracting dots-- no rapid-firing the enemy into submission.

Destroying the enemies-- or, to be more accurate, destroying parts of the enemy (boss battle shmup, remember?) will fill up the red bar in the upper right hand corner. When it's full, it begins flashing, indicating to the player that they can now place a tower-- the tower being that handsome little devil near the top. Those blue bullets are his-- the tower slowly fires bullets in each of the four directions. Since they provide the only means of controlling space vertically, getting as many towers on the screen as possible is key to winning.

You've likely noticed the five trophy slots beneath the logo. The first is for defeating the boss; the second, for getting a certain number of towers on the screen; the third, for destroying a certain number of enemy parts with one attack; the fourth is for completing the stage in a certain amount of time (timer has yet to be implemented-- I'm thinking upper-left corner); the fifth and final trophy is for beating the stage without dying.

The player has an unlimited number of lives-- as soon as you're hit by a bullet or an enemy, you'll respawn at the bottom of the screen. Being hit will cause the tower meter to empty itself, but other than that there is no penalty for being hit, no way to "lose" the level.

But the player's progress isn't tied to beating each level; it's tied to the trophies the player has earned. Say, for example, that the game opens with three boss enemies which the player can tackle in any order. Before the next two or three bosses are unlocked, the player must win five of the fifteen possible trophies. He could beat all three, pull off the time on one and the towers on another, or even "ace" one boss and ignore the other two if he so wishes. Trophies aren't extras; they're an integral part of the game.

The various trophies are all tied together in such a way that a good player can collect all five in the same play-through; pulling off more combos (trophy 3) results in a faster filling up of the tower meter, which means more towers (trophy 2), which means that you'll complete the stage faster (trophy 4). Recall that getting hit empties that tower meter; getting through the level unscathed (trophy 5) thus allows you to accomplish trophy 2, which, as illustrated above, ties into trophies 3 and 4. (Trophy 1, again, is just for beating the level.)

And now that I've got all that figured out, I think the rest of the game should start coming together a bit more smoothly...

Side Saddle 2 Development Blog # 4

2009-06-09T18:36:00.000-07:00

At least twice when I make a game, I start the whole process-- spriting, creating objects, designing levels, etc.-- over from scratch. The second, third, fourth times through, I find ways to make things simpler, prettier, more elegant, more intuitive, and just plain better.

It's not nearly as frustrating as it sounds; I've come to accept it as a natural and exciting part of the game design process.

And I tell you this to note that the first version-in-progress of Side Saddle 2 has been scratched, and that the second is underway...

Side Saddle 2 Development Blog # 3

2009-06-07T18:38:00.000-07:00

While the first two enemies, whose attacks are largely similar, went off without a hitch, the third has resulted in massive game-crashing slow down. So much does it various behaviours slow down the game that it checks the Step Event before it's done with the Create event-- which means that important variables aren't established and the game has a fatal error.

Grrr...

Side Saddle 2 Development Blog # 2

2009-06-06T18:38:00.000-07:00

First two enemies are complete, title screens created, trophy system implemented. I made myself work on these last two early on because

(a), when I get towards the end of a project, I begin to get tired of the project-- I get to the point where I just want the damn thing to be over with. Things that add to the presentation of the game but that aren't absolutely crucial to it, such as nice-looking title screens and a trophy/unlockables system consequently are not completed;

(b), a corollary to (a), when I have to go back and add a feature to multiple objects-- such as the detection of various trophy wins into each level's control object-- I often miss something or make some sort of small, silly, stupid, game-wrecking mistake that takes several hours to fix. Implementing it from the get-go prevents hassle later on.

I think the development of this game should be very quick-- maybe two weeks at most. The original Side Saddle took several months (from October 2008 to January 2009) to cobble together. A great deal of that time was spent figuring stuff out, fixing stupid bugs, and creating/scanning/resizing/colour the hand-drawn sprites. I hope to eliminate all three of those time-sinks: thanks in no small part to that first game, I've more-or-less got everything figured out; I don't expect to run into any bugs this time around, though I say that about every game that I make; the basic orb motif should take less time and file space than the first game's hand-drawn enemies.

Fingers crossed.

Side Saddle 2 Development Blog # 1

2009-06-05T18:41:00.000-07:00

Back in January, I unleashed Side Saddle upon the unsuspecting internet. As I explained in the Making of Side Saddle post directly below this one, it was an experiment of sorts, my attempt to take several trends in shmups and turn them on their ear. It is, I think, the most successful of my experimental games to date-- the most playable, the most interesting, and the most fun. (My most recent game, the platformer Run Jump, while it attempts to add something new to the mix, is much less of an experiment and more of a full game.) Reasonably pleased with the end result but knowing there was room for some improvement and some other ways to deliver on the short-axis/side-shooting motif, I decided recently to do a sequel.

But, as I also said in that making-of post, the original is not perfect. Many have found particular fault with the ammo system.

To recap it briefly: the player has a stack limit of nine shots. When the player is not moving or shooting, your ammo recharges. Killing the enemies faster, then, gave you more time between waves to recharge your ammo safely; conversely, the longer a given enemy was onscreen, the more points it was worth. And as the auto-fire turret power-up, which sent out shots in all four cardinal directions, was awarded at certain score threshholds, getting a higher score was in the player's best interest. And so: desire for safety vs. desire for score, desire for ammo vs. desire for power-ups. Remove one feature (like the hated ammo system) and you remove it all.

And so, the ammo system was integral to Side Saddle yet also its most despised and weakest feature. Any sequel would have to improve upon it vastly or lose it altogether.

And, after a few days, I decided to drop it, as I think I've found a new power-up system that makes better use of the game's somewhat claustrophobic spatial motif. Your ship in this game is a small circle, which gradually becomes larger and larger. Each time you fire a shot(s)-- like the first game, pressing the fire button will release a shot on each side simultaneously-- the ship's size decreases. If you allow the ship to grow to its maximum size, however, you'll be able to place a power-up turret. As in the first game, these turrets fire up, down, left, and right, greatly increasing your control of space-- at least until it self-destructs after a given periodo f time. The moment you unleash that turret, you shrink down to your smallest size and the process starts anew.

Now, here's where it gets interesting: every time you destroy one of your enemy's orbs-- each of which has multiple hit points-- you grow two sizes. A skillfully placed turret will quickly give you the power to place another, and another. While a good player in the first game could get two or three turrets on the screen with a little skill and a little luck, I suspect that most players should be able to get that many on a semi-regular basis. The first game's ability to shoot diagonally is not present here, so being able to control space in four directions is paramount.

Of course, as you're gorging yourself on your way to turret-dom, you're making yourself a much bigger target for enemy fire. At your smallest, you're a few pixels in diameter; at your largest, over a dozen times that. The already narrower playing field-- remember, this is a vertical shmup in which you shoot sideways instead of up-- and the larger, multi-part enemies (did I mention this is to be a boss battle shmup?) should have players most anxious indeed.

I'm very excited about this project, about the new opportunities for both myself and the player that these new and revised mechanics allow us to explore. I hope you'll share my excitement when the game is complete.

Making of Side Saddle

2009-06-01T18:42:00.000-07:00

Video Games | Side Saddle, Boss # 1 & Beyond

XBox 360 | Playstation 3 | Nintendo Wii

Action games are about controlling space, but in non-arena shmups, both vertical and horizontal, I find the control of space to be too easy. Yes, in bullet hell games, it's difficult to dodge-and-shoot, but in many games you can basically just strafe back-and-forth along one axis-- the horizontal axis in a vertical game and the vertical one in a horizontal-- and rapidly press or hold the fire button to destroy whatever legions of enemies are coming at you.

The player can hang back at either the bottom or left of the screen and fire from there; their shots stretch out over wider axis of the game's orientation.

There are some shmups, of course, that don't allow the player to fall into this trap. Enemies with heat-seeking missiles and arcing bullets prevent the player from getting too comfy. Cactus's great game Clean Asia requires you to ram through an enemy in order to gather the shots used to defeat them. And you don't want to move along one axis in a bullet hell game.

But I was wondering to myself, is there another way to do this? The big problem for me was, again, the way the bullets dominate the longer axis. I considered using "funny" bullets that spin around and I thought about using bullets that peter out after so many seconds. But I couldn't really get either to implement particularly well.

That's when the thought occurred to me of flipping the axis; of having the bullets control the short axis rather than the long one.

In such a game, the player would have to get right next to an enemy in order to shoot them, putting a renewed focus on how the player moves through and controls space. And that's when I started working on Side Saddle, a side-shooting vertical shmup. But there was still a problem; I found that my playtesters were moving along the vertical axis, up-and-down, shooting willy-nilly. Shorter axis or not, it was still the same trap.

And that's where the ammo idea came from; players would now have to conserve their ammo and aim carefully. Accuracy became important. And the reloading motif-- the ammo only reloads when the player isn't moving-- would require the player to think more deeply about the way they moved through space, to consider if they should stop here and for how long.

It also introduced a dynamic tension into the way the player dealt with enemies. If you kill an enemy quickly, you'll have more time to recharge ammo for the next wave; if you wait longer, the enemy will be worth more points but you'll have less time to recharge. And since every 10,000 points gave the player a turret power-up, thus increasing their ability to control space and avoid dying, scoring more points is ideal.

So that, in a nutshell, is the decision-making process that resulted in this game. It's a difficult game, but it's perfectly winnable if the player (1) conserves ammo, (2) fires accurately, (3) stops moving to recharge his ammo, (4) strikes a balance between his ammo-needs and his power-up wants, and (5) uses the entire playfield.

The problem with all that is, it's pretty much hard-wired to support one style of play (the style enumerated above) and to dismiss all others (such as the move-along-one-axis and firing-willy-nilly-at-everything school of shmupping). I stand by the decisions I've made and I think there's a lot of good, challenging, and strategic play in it, that it has a fair amount of replay value.

At the same time, I'm dubious about any game that doesn't allow the player to use their own play style and strategies. While I still think, at least at this stage when it is admittedly still very fresh in my heart and my mind, Side Saddle is a good game, it should have supported more varied styles of play.

Part of the problem is, admittedly, by design-- the whole point of the game, from the start, was to "correct" "lazy" play habits in shmup game play by removing the strategy of moving along one axis while controlling the other with your bullets. But, y'know-- some people like that style of play. (Heck, sometimes I do.) So maybe the whole time I was operating from a false premise.

I'm certainly not trying to dissuade anyone from playing my game--please dear God play my game-- and in fact I hope that the preceding prods some people into giving it a look.