SEQ.BREAKER DEV JOURNAL # 11: PRODUCTIVE 24 HOURS

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

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

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

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

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

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

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

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

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

Insanely simple, but very useful.

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

SEQ.BREAKER DEV JOURNAL # 10: EMBRACING THE CLICHE

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

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

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

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

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

HEXTOK Session 2.

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

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

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

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

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

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

HEXTOK!: Q.A. # 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Game Maker .DLL Recommendation: Sin Bass

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

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

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