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.
Wednesday, September 22, 2010
Friday, September 10, 2010
SEQ.BREAKER DEV JOURNAL # 24: 3 APPROACHES TO HEALTH.
One advantage to the game's structure-- each mission is completely self-contained, with its own items and hazards that don't carry over to the other missions-- is that I can approach each mission almost as its own game. I've decided to further emphasize this structure by taking a different approach to the player's health in each of the game's three missions.
The first and shortest mission is pretty combat heavy, with lots of enemies to shoot and lots of things to shoot them with. Because it's so focused on action, I'm giving the player a recharging shield. Whenever you get hit, the shield goes away for a handful of seconds. Survive during those tense moments, and your shield pops right back on. This is the approach I talked about way back in Dev. Journal # 11, and I initially thought it would be the standard approach for the entire game.
But, because the shield is a power-up-- an item that you acquire-- and because one of my "rules" is that once an item appears in a mission, it would not reappear in any other missions, I felt it would be more interesting to find a different solution.
In the case of the second mission, that solution is no solution-- that is, the player has no health or defenses. Nor, in fact, any offenses; the second mission, which is roughly twice as long as the first, is all about navigation, with each item increasing your ability to get around the level and reach previously impossible-to-reach places. It's not, however, hazard free, as the level is full of fish, torpedoes, underwater mines, machine guns, and exploding-butt-lumberjacks that will have to be avoided with tricky, precise platforming and the usage of your various items. And while this one-hit death-a-palooza is balanced out by an ability to save anywhere at anytime, it is likely the most difficult level in the game in terms of requiring the most of the player's reflexes. (However-- as I hinted in my dev journal "Difficulty as Deterrent"-- this extreme difficulty exists to encourage the player to avoid it as much as possible; breaking the sequence will transform the level into something of a cakewalk.)
The third mission is by far the longest, functioning pretty much as a complete Metroidvania-style game, with multiple bosses, paths, and items to acquire. If the other missions are pretty bare-bones and narrowly focused (the first on action, the second on navigation), this one is intended to be much broader, deeper, and robust. For this third mission, I'm going with a more traditional approach-- a health meter that is upgraded as you find Health Upgrades and refilled with pellets dropped by enemies. This mission will also feature an ammo system-- unlike the other two-- with a similar capacity upgrade and pellet-drop mechanic.
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.
Wednesday, September 8, 2010
SEQ.BREAKER DEV JOURNAL # 23: CONTENT WALLS AND CHAPTER STOPS
As hard as this game is going to be, as much as it's going to (playfully) insult its audience, as dadaist as I'm making the story elements-- I still don't want to put any unnecessary walls between the player and their enjoyment of the game. By "wall" I mean anything that stops your progress completely, dead stop, no other options. If you don't break the sequence, that's okay, you can go ahead and take on the next mission anyway. In fact, you can complete all the game's missions "the wrong way" by following the in-game walkthroughs, and there's no penalty for that.
When the player dies, they go back to the beginning of that area-- but with all their collected items and thrown-switches intact. The player also has the option to save their game at any time via the pause screen. So, if they see a series of tricky jumps, they can make a save beforehand and reload it as often as they like (rather than going back ten screens). I don't want to give the player any reason to say, "This is bullshit, I'm done with this game."
At the same time, I want there to be a tangible reward for breaking the sequence. While each mission, and ultimately the game, is going to end differently depending on whether or not you break the sequence, I'm planning on including a fully-functional platformer as a bonus game, accessible only once you've broken the sequence for all missions.
Problem: what happens if the player breaks some of those sequences and not others? If you had to start a new game and do it all over again, it would be kind of irritating; it would put a wall between the player and the content. Solution, and a simple one at that: I've implemented a menu that allows you to replay any unlocked mission, and keeps track, through the appending of a simple icon, as to whether or not you've broken the sequence. And when all sequences are broken, viola!, the bonus game is unlocked.
It's a feature that's becoming more common in indie games. For example, Paul Eres's astonishing Immortal Defense allows you to replay any of the game's 90+ levels, and always uses your highest score for each level to calculate your "cache"-- basically, the money you use to buy your towers-- for the next stage. Matt Thorson's Jumper 3 and McEntee-McMillen's Meat Boy are but two other examples.
I think, however, it should be more than common-- I think it should be a standard feature of every non-RPG game that's longer than fifteen minutes (and I think RPGs should, combat aside, allow you to save whenever you damn well please). You can open a book to any page, and you can select any chapter stop from a DVD menu; why not offer the same freedom in this art form? Set aside technical considerations for the moment, and let's look at this aesthetically: what's lost by this approach, and what's gained?
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?
Monday, September 6, 2010
d20 Poker
The adventure I have planned for my Dungeons and Dragons group this coming Sunday hinges, in part, on a sort of poker game-- that would be the Old West part of my proposed genre trio High Fantasy, Old West, and Steampunk reasserting itself. The problem, of course, is that I don't actually know how to play poker, and that I'm not sure if my players do either, and, hey, we came here to play D&D anyway so what's with this poker, what's next, are we suddenly going to find ourselves playing a high-stakes game of Acquire against a bugbear so you can finally stop yammering on about you can't find anyone to play it with-- and, geez, I guess that's three or four problems, after all. So, um, problematic, that.
But I don't really want my PCs to play poker, but rather, "poker"-- that is, the art of lying to your opponent, of knowing when to bluff and when to call. That part seems to be a lot more fun than remembering what card trumps what, and that's the part that actually gives them something to roleplay. Which is kind of the point.
So, what I'm going to present them with on Sunday is what I'd call d20 poker. The characters in the game are playing some variation of a card game, but the players will just roll their d20, with the highest number winning. Once they've rolled the die, they can up the ante, match that ante or fold, bluff their opponent(s) into folding, and call it when the ante isn't being upped.
I won't know until Sunday how well it works, but it seems, from a purely mechanic standpoint, to be a fun, accessible and fast-moving way to simulate that sort of conflict in a role-playing context. I'll be sure to let you know how it goes after we've given it a try...
But I don't really want my PCs to play poker, but rather, "poker"-- that is, the art of lying to your opponent, of knowing when to bluff and when to call. That part seems to be a lot more fun than remembering what card trumps what, and that's the part that actually gives them something to roleplay. Which is kind of the point.
So, what I'm going to present them with on Sunday is what I'd call d20 poker. The characters in the game are playing some variation of a card game, but the players will just roll their d20, with the highest number winning. Once they've rolled the die, they can up the ante, match that ante or fold, bluff their opponent(s) into folding, and call it when the ante isn't being upped.
I won't know until Sunday how well it works, but it seems, from a purely mechanic standpoint, to be a fun, accessible and fast-moving way to simulate that sort of conflict in a role-playing context. I'll be sure to let you know how it goes after we've given it a try...
SEQ.BREAKER DEV JOURNAL # 22: JUST STOP DOING IT WRONG
Play-testing can be a tricky thing. It is not just about making sure the end product is relatively free of bugs, but also about making sure the game is fair, easy to understand and to play, that the "rules" of the game are consistent and coherent. Most of the time, what the play-tester has to say is one hundred percent spot-on-- such-and-such a part is too hard, such-and-such doesn't really make sense-- and some of the time-- not often, but some of the time-- they're wrong.
Usually, when it's the latter, it's kind of obvious-- weird suggestions and nonsensical complaints being two of the biggest red flags. But sometimes, you'll think your tester is dead wrong when they're dead right, and you've been blinded too much by your own ego, your over-familiarity with the game, your laziness, or a combination of all three to see the painfully obvious truth.
In Seq.Breaker's first mission, the player has access to a bomb weapon, which explodes upon impact. If the player is caught in the blast, they take damage. If the player threw the bomb down from higher ground, they'd be quite safe, but if they just stood there and threw it, they'd get hit. Well, I thought, you just have to jump before you throw the bomb, and I went to work designing an area with low ceilings and tricky jumps in which you needed the bombs. A nice challenge, I thought.
But my first play-tester never jumped before throwing the bomb. He kept getting caught in the blast, and he kept getting frustrated. "I don't think it's fair," he said, "that I have to get hit to use the bomb."
"Well, you can jump up and then use it, and you won't get hit," I said.
And so he tried to do just that. But in that tricky jump section, he kept taking damage due to inaccurate timing.
"I thought you said I could jump and I wouldn't get hit," he said.
"You got to time your jumps."
He didn't do much better. Afterwords, he expressed his reservations.
"It's fine," I said, "you have to just stop doing it wrong." Which was kind of an ass thing to say, and I realized it as soon as it came out of my mouth. It was also a tip-off that I was in the wrong in this case; having to jump before throwing the bombs was not as easy to figure it out as I thought it would be, nor was it fun. Having a weapon or mechanic that bends the player to its will is-- in most cases-- not particularly strong game design.
I was blind to see that because I was too pleased with my own level design; I was too familiar with the game, to the point that things that didn't quite make sense seemed to; and, above all, I wasn't looking forward to sitting down and tweaking the movement speed and gravity for the bomb. Which took me all of ten minutes to get right.
Now, the player can stand still and toss off their bomb without fear of being hit; it's only if they keep moving towards it that they'll feel its wrath. It's fair and it makes sense, and now all that remains is to give my play-tester an apology...
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...
Friday, September 3, 2010
SEQ.BREAKER DEV. JOURNAL # 21: TILESETS TO THE RESCUE!
Rather lazily, I've been making walls of my wall object. That is, every 16x16 pixel block in the above picture is actually there, an actual object, even if there's no way the player can interact with it. For the first level, this presented no problems. But for the second, which is substantially larger (each room, again, not being a separate "room" but one continuous interconnected space) and features a lot of water (with each 16x16 block of aqua being, yes, an object), the sheer number of objects caused a lot of slow-down. As in, the game was running at about half-speed.
Now, there's nothing going on, code-wise, within those instances-- no alarm events, no detections, all the collision information for those object types are contained inside the player object-- but it still was putting a tremendous strain on the computer. And as soon as this happened, I realized, I'm going to have to go in and remove as many as those objects as possible, replacing them with tilesets (which take up far less memory).
Now, I love working on my game, but one thing I hate doing is tedious work, such as, oh, I don't know, going into a room and clicking on swaths of 16x16 objects and then replacing them with tilesets. But tonight I finally got off my ass and did it, and as a result, the game is running at the brisk and intended speed of sixty frames per second.
Remember, game makers: tilesets are your friends.
Subscribe to:
Posts (Atom)
