Thursday, March 31, 2016

Hammer devlog 08

note: this has been migrated from elsewhere, and formatting may be a bit wonky

I said the next thing I was gonna do was going to be the energy meter.

Apparently I lied?

[​IMG]

I looked at the snazzy official Unity tilemap tools with no discernable release date and despaired. Then I looked at the free Asset Store tilemap tools and also despaired. (There might be some nice paid things, but I'm a broke fuck.)

Then I found the amazing UnityTileMap library and found it to be just what I needed!

So I ripped out the ghetto level layout system I was using and incorporated this. UI is a little janky - and it doesn't play well with my game's unit scale out of the box, giving me a hilariously fucked-up workflow for editing tilemaps ATM - but the underlying code is solid and does what I need it to. At some point before I get to actually doing real non-test level designs, I'll probably want to go in and get the tilemap editor working in a way that's a little bit less of a pain.

I also did some quick programmer-art dungeon tiles, which you can see here.

This, of course, broke everything. But that was a good thing, because I had a lot of hacked-together logic that I knew I'd have to replace before it'd be practical to actually expand this to a full game anyway!

Under the principle that something simple and effective, if clunky, was preferable to an elegant solution that would never actually work, I did this by implementing something called a WorldController.

The WorldController is, uh, much less exciting than it sounds. It's a MonoBehaviour that stores references to a bunch of specific "always in the scene" objects (player, reticle, a set of rooms, etc.) and facilitates letting GameObjects find all of these without a bunch of redundant GameObject.Find calls. It should really be a struct as opposed to an object - it doesn't even have methods; it doesn't even make sense for it to have methods, it'd just be a Big Ball of Pointers if I wasn't writing managed code - but I have surrendered to the "MAKE IT A MONOBEHAVIOUR" Unity devil on my shoulder. I can sit a WorldController in a scene, populate its fields, and then start putting things down and having them Just Work.

Some other things:

I've decided on, at least, a working title, because it's helpful to have something to call this thing other than "this thing." Being as this is an over-the-top shmup-RPG where the player faces off against an array of dead presidents turned Wacky Boss People in order to rescue their ninja boyfriend: the tentative title I'm playing with is Jacqueline Hammer vs. the Liberty Gang.

Having cleaned up the worst of my messes and come up with something to call the repository: the GitHub is up. I'd certainly like to retain the ability to try and go commercial if I get this to a point where I've finished the current prototyping/mechanical testbed phase and I feel satisfied enough with the core of what I have going that I think it could produce a product I'd be comfortable charging money for - as mentioned, I am a broke fuck, and plus I imagine saying I've shipped a commercial indie title looks good on a resume for a more pays-the-bills sorta job - but at the current time, I'm not exactly worried about anyone seeing in-development content - because there's nothing here that really counts as content - and I'd certainly love to hear thoughts or criticisms re: what's already in place.

Also, yeah, I'm aware that the code that keeps the enemies in the room was still broken at the time I captured that gif. I've fixed that again in the intervening time.

Wednesday, March 30, 2016

Hammer devlog 07




note: this has been migrated from elsewhere, and formatting may be a bit wonky

[​IMG]

HUD isn't doing anything yet, but the energy system is in place. The shotgun won't fire if you don't have 5% to spend on it, and at zero energy you die. You can see a death at the end of the gif here - no real handling of it (the game continues, you're just dead - the most realistic death system ever) but you run out of energy and your controls lock while you enter the death animation.

Which is just the stand animation, but I can do a death anim later on. Point is: you're dead, you can't do shit, woo.

Also, it's probably really obvious here that the enemies came before the shooting, because, man, the fact that these are basically Keese With Guns (as befitting the whole Zelda With Guns thing, I guess) makes trying to pick them off with the two weapons that exist right now a serious pain. I mean, there should be some weapons eventually that are equipped for handling things like these (homing properties or piercing shots would make them much more manageable, I think) but this shotgun is not among those.

Anyway, screen scrolling. It's a thing! I'm also going to get a smooth-scrolling multi-screen room mode together later on, but at the moment the primary focus is combat scenarios, so given how integral the small playfields are to the way I want combat to work here, the larger-playfield mode isn't really that important. It might be used in a few bosses, but mostly it'd be for puzzle rooms, towns, and other areas where combat is purposefully a minimal presence if it exists at all.

Before any real combat tuning happens: I really have to get a working energy bar in place. Watching a variable in the inspector to tell how much health/ammo you have left is, uh, not acceptable.

Tuesday, March 29, 2016

Hammer devlog 06

note: this has been migrated from elsewhere, and formatting may be a bit wonky

Bullet graze rewards are a fun concept, actually, and I might play with that some. Creates an alternative means of recovering energy within firefights, which is great in itself, because if I can get that system working it lets me do much more dynamic boss fights without necessarily being constrained by the requirement that they spawn trash mobs in periodically so you can keep firing.

In practice, I will note that I'm not sure encouraging long chains will be workable given the limited screen size? Seems like the system would accomplish a similar goal while more reliably being something the player could put to work for them if you tie a small immediate bonus to an invisible multiplier that increases each time you graze a bullet, but degrades quickly over time (as in: 5 seconds, it's back to zero) and resets immediately if you get hit or change screens.

Also makes more sense from a UI point-of-view, probably. I've got four shades of gray and 23040 pixels to work with, meaning that it's hard to find screen space for an extra UI element - but if I immediately release energy into the bar, that's an effectively free way to provide immediate visual feedback that reinforces "yo, nice work what with the dodges and shit, yo." First you get 1px on the bar, which is nice but not really enough to do much of anything, but as you keep dodging, you get exponentially more added to that bar, and (with a snazzy sound effect for each addition, of course) you can get a lot out of that!

But things generally hit hard enough that, since getting these bonuses requires you to purposefully occupy less safe areas of the screen, it's very easy to lose everything you've gained in one or two hits, if you don't know how to manage that risk.

Larger hitbox (the grazebox) surrounds your main hitbox.

For extra fun: the grazebox also exists while standing still, allowing for some crazy Hail Mary shit where you can get substantial (more than a few multiplier levels for free) graze bonuses by positioning yourself just right and then not dodging. But if your spacing is off at all, you just take the hit. So it becomes a high-risk/high-reward strategy that you can use to turn the tables in your favor when things are bad, but which screws you over even worse if you misjudge anything.

Anyway, though!

[​IMG]

Pulled some things together. Proper hit detection for player and enemies. The enemies don't actually have a proper death animation, but you can shoot them, and they'll lose HP, and they'll die. You won't lose HP because the energy system doesn't actually exist yet, but if they hit you they will wound your pride.

Shooting is looking much better; it's still nothing I'm happy with, but it definitely feels a lot snappier and more fun. The weenie gun is still markedly weenie without feeling as utterly useless as it did before, and now there's this shotgun, which fires a huge cloud of shit that hurts like a motherfucker, but roots you in place until it finishes its long-ass cooldown time. Both of these weapons, of course, currently share a lack of satisfactory visual cues, which is something that will happen when I get some placeholder weapon-specific graphics in. Like, that shotgun would feel a lot nicer if it had a beefy recoil animation for after you fire, I think.

Not visible: they do have different firing sound effects. The shotgun's is this really nice white-noise blast; it still feels kinda janky in gameplay, but it's not quite as bleh as in the gif just because it sounds weighty and impactful, even if it doesn't really look it.

I guess the next step is to turn this into something at least resembling a game, then? Which means I need to get the energy system and screen scrolling working. I also want to get the aforementioned weapon-specific firing animations, a death animation for these enemies, and on-hit knockback for everything.

Sunday, March 27, 2016

Hammer devlog 05

note: this has been migrated from elsewhere, and formatting may be a bit wonky

[​IMG]

Testing a very rudimentary enemy AI. There's no real hit handling yet, (although bullets can collide with scenery) but things are at least starting to come together.

These little ghosty guys are really obnoxious, but they're obnoxious in exactly the way they're supposed to be. They fly around the screen unpredictably, moving through walls with impunity, and (so long as they're not within a wall) they fire on you at frequent irregular intervals.

Also, they know where your reticle is and they'll run from that shit, forcing you to aim indirectly. Which is fun, because it gives you two choices: aiming past them gives you more control, but it leaves you open, and they're going to come in closer. Aiming in front of them gives you a lot less control of your firing trajectory, but keeping your reticle close keeps them away, so they don't charge in.

There's still only one player weapon, which is this weenie gun.

If I were doing something other than very preliminary test work here, I would probably not put five of these fuckers in one room at a time when you only have the weenie gun.

also, playing with some really shitty collision code for enemies - yeah, the variable ending lag on the roll is one of those ideas that's cool on paper but feels like trash ingame. Just pulled that. Given the intensity of combat and the tiny playfield, that extra layer of lag is completely unnecessary - there's never a time when you can just keep ROLLIN' ROLLIN' ROLLIN' COME ON because space is way too precious and even the minuscule startup lag on your dodges is more than enough to dis-incentivize button mashing.

Friday, March 25, 2016

Hammer devlog 04


note: this has been migrated from elsewhere, and formatting may be a bit wonky

Not the next prototyping milestone, but an interim update:

[​IMG]

Aiming is in, and while I haven't gotten the player firing controls up and running, I did a quick-and-dirty test just barfing bullets onto the screen regardless of player state. Works great- cursor is responsive & precise; bullets trace a path along the vector that leads from player position through reticle position at time of firing; sprite movement is kept nice and chunky and pixel-locked no matter what path the bullet needs to trace.

Initial stress test with a 1600-entry object pool for player projectiles is actually fine. I'll probably wanna trim that down nonetheless once I have enemies on screen, of course. That being said, though: great thing about the GB Zelda-style screen scrolling system is that it lets me cheat a lot with costlier logic. I know exactly what's onscreen at any one time, and can set only those objects to active. Like, those bullets - they get put back in the pool the very instant they leave the viewport, because there is never a time when I give the slightest shit about what's happening outside the viewport.

EDIT: the framerate in-game is buttery smooth, fwiw - it's just the gif being kinda janky

Thursday, March 24, 2016

Hammer devlog 03

note: this has been migrated from elsewhere, and formatting may be a bit wonky

I guess now we need to talk about the rhythms of gunplay, player weapon variety, and the sorts of enemies we're going to be encountering.

The dodge is already in place, and that helps make these mechanics a lot clearer than they were before. The player has a huge degree of very safe mobility - you can cross half the screen worry-free on a whim. You can turn on a dime. And since I don't want to have the usual ending lag on successful dodges, you can keep doing that if you're good.

So this says two things right off the bat:

a) the cost of attacking - particularly powerful attacks - needs to come, in part, by forcing you to compromise that exceptional mobility. You can never dodge in a firing animation, and a lot of the more dangerous weapons actually root you in place while you fire! This forces you to think about where you're going more carefully, instead of just rolling out of the way whenever you've got something incoming and feeling safe with that strategy - spatial awareness and territory control are key. Dodging gets you around the screen real easily, but you can't just ignore room layouts. I want a game where you need to perform split-second analyses of enemy positions, firing patterns, and environmental features to find where on the screen you need to be if you want to attack right now. Watch the enemies, get a feel for how they behave, and try to find safe firing positions for the weapons in your arsenal that seem appropriate for the current scenario.

A "safe" weapon, in this context, is one that can be utilized effectively from a variety of positions at any given time. There are a lot of properties that could make a weapon safer! Shorter firing animations, spread or ricochet fire, walk-while-firing, firing through walls, burst damage as opposed to stream-of-fire - all of these have the effect of making the weapon less punishable, and since I want to encourage the player to take risks, the cost of a less punishable weapon is that it's less destructive. But even if you're good at the game, it's not always practical to use the highest-DPS tools in your arsenal at all times - the energy system makes for a nice balance here. Riskier weapons let you do more damage, but taking stupid risks then cuts the amount of energy you have for doing that damage. But, of course: there's also an inherent danger in keeping a skirmish going longer than you have to, and the relative weights of all these different factors shift from moment to moment. Spur-of-the-moment situational analysis is what makes the difference between a good, smart action game and a button masher, and it's important to make sure we preserve that.

b) there's a very specific balance that needs to be hit with the amount of hazards present on the screen at any one time. A dodge as effective as the one we're using makes more limited firing patterns a nonissue - you can always get well clear of them, and you can roll right through them. The screen needs to be busy enough that you can't just dodge wherever you want - you need a destination when you hit the button, territory that you want to control which you expect to do something useful for you. But shots that aren't a threat are also a problem! If you roll through a shot, you don't have ending lag on that roll, and you can come out of it immediately into another. A random bullet going nowhere through territory you don't want actually helps you more than it hurts you, because you can roll through that to keep yourself more mobile than you necessarily "should" be. Firing patterns need to be about putting pressure on the player, not just pretty bullet-hell fractals. If a bullet is on screen, it should present a problem. As the player, for each and every bullet on screen, you should at least be able to say "I really wish that wasn't there."

But as powerful as our dodge is, it's not without limitations even if you do get out of the ending lag, and even if you are rolling into a decent attacking position. You take a few frames to step into the roll, and you take a few frames to step out of it whether you're going to whiff or not, and you're vulnerable at each of those points. If this is going to feel fair, I have to make allowances for the timing of the i-frames - you have to be able to see an attack coming quickly enough to roll through it, and you have to have somewhere to go within the roll radius that'll be safe at least long enough for you to step out of the roll and step into another.

The design that's taking shape here is that of a shooting game that's kinda mean, one that expects a lot of the player - but that means the player will have equally high expectations of the game. When the consequences for slipping up can be as dire as they are here, and the amount of pressure you're under basically at all times within combat is as high as it is, as a player you need to feel like your failures are always your own fault. You need to be able to look at how you died and say "well, I earned that." You need to be capable of learning from your mistakes and improving, instead of simply feeling like you got fucked over by the system.

So there's a very delicate balancing act that I'm gonna have to work around here.

I think it's clear with what I know about the rhythms of gunplay here that I'm not going to get that feature to a useful place if the player only has a single gun - the versatility of your toolset is too key to the system. I'll need, then, to get this up and running with a pair of weapons that allows me to play with the risk-reward dynamic in miniature - something safe but kinda wimpy, and something lethal that demands careful attention to positioning.

I'll also need to design an enemy AI that can provide some amount of legitimate pressure, even at this early stage! It doesn't have to be pretty, or reusable, or good - but I need something that gets the appropriate game feel to come together. The goal of this prototyping phase is to work in tandem with my paper design, to help to draw a clear picture of the mechanics I'm building around - each "step" in the sequence needs to elucidate those mechanics further.

Wednesday, March 23, 2016

Hammer devlog 02

note: this has been migrated from elsewhere, and formatting may be a bit wonky


https://02456e4115ec8ed82d17133ba955ebe02ad97cd1.googledrive.com/host/0B-_i8p-5f46Fak9MOEZnQmZ2czg/

I have a thing now. It takes a while to load.

This thing is:

a shitty placeholder character walking and/or rolling around a featureless void while shitty placeholder BGM plays. There is a box in the void. If you try to walk through the box, you will not walk through the box.

The code is kinda terrifying right now, but I've done like two hours of actual programming here, so, y'know, whatever. Most of the time was spent doing the assets, setting up Unity project settings, and putting the state machine & animations together.

Input handling is serviceable, and while the roll's likely to change once you actually have shit to dodge with it, at the moment I've gotten that to handle in a way that I actually do quite like. Try playing around with it - you have a lot of control over the distance and heading of the dodge just using WASD, and there's a satisfying transition from walking speed > dead stop > rolling speed.

The problem here is, of course, the roll whiff ending lag. I wanted punishing, but, uh, I really think I overdid it there. It feels sluggish and horrible even before there's anything to pressure you - even simple enemies will make that penalty completely gamebreaking. So that's gonna need more than a little bit of adjustment.

Next steps: Guess I'm going to have to think some more about combat! Need to get some sort of player gun up and running and implement a basic test enemy. You shoot it, it shoots you, everybody's happy and/or bleeding. Probably gonna be another design dump before anything playable, of course - I don't really understand those systems well enough to do something useful with them yet.

Tuesday, March 22, 2016

Hammer devlog 01

note: this has been migrated from elsewhere, and formatting may be a bit wonky

I like shooting games.

Not, like, that boring first-person shit, and only marginally that acceptable first-person shit like Doom. No, I like shooting games, like, the kind where you've got a spaceship made outta exploding cardboard and sometimes the console physically can't keep up with the amount of bullets and explosions and shit on screen and it's like, whoa, and this is totally a legit sentence and I'm not just pulling it outta my ass.

Okay, so something I probably should've led with: when I say "from scratch," I mean that I literally hadn't even thought about this project until I hit the New Thread button back there. We're working from the ground up here - starting with design. I haven't written a line of code, I haven't done any graphics or music or anything. And I'm not gonna use anything that's already laying around, except maybe as a placeholder. Literally the entire development process is gonna be documented in this thread. Think of it like improv jazz, except video games, and oh my god did I just type "think of it like improv jazz" I'm a fucking hipster when did I turn into a hipster?

Okay. Okay. I'm a hipster, fine. Well, being a hipster: my favorite 2D Zelda (by which I mean the clearly, objectively best one) is Link's Awakening.

I'll get to why that's relevant, maybe?

Okay, so something else I wanna play with: free-roaming shmup controlled with WASD+mouse. Character moves on a 2D plane, mouse controls cursor, you shoot toward the cursor. Decoupling movement from aiming lets me get really fuckin' mean with bullet patterns and the like. Think of how Sin & Punishment 2's side-scrolling sections worked - Wiimote let you aim wherever you wanted, so it was possible for that game to throw shit at you that'd be ludicrously unfair in a more conventional shmup. And the freedom of movement you've given by being able to shoot in any direction is something that game didn't do much with that I want to explore more fully - so: Zelda. Dungeons, overworld, all that good shit, and all it full of giant, like, buckets of bullets that fly all over the place like WHAM ZOOM WHOOOAAAA and try to murder you. Got that? Great?

I'm putting a mouse in the player's right hand, which means I wanna keep controls pretty simple. Mechanics should be very quick to learn; difficulty should come from scenarios, not wrapping your brain around how to make your character do anything. So: here's what we're doing.

WASD: move
left click: fire primary weapon
right click: fire secondary weapon
double-tap direction key: dodge roll
Enter: bring up menu screen

We have Zelda DNA, and by Zelda I mostly mean just Link's Awakening because, y'know, why would you even want that other shit? So primary and secondary weapons are literally just slot 1/slot 2, not a deal where there are two different classes of weapon or something. Keeping it simple, yeah? You hit the mouse button and you fire the weapon in that slot toward the cursor. You can bring up the menu screen at any time, which pauses the game and lets you change the weapons in those slots, because we're going full Zelda, except more awesome because how many of your Zelda things are guns? All of your things are guns here. Like, even if I wanted a locomotion tool: that's a gun. It fires a thing toward the thing. Maybe it's a grappling gun, maybe it's a really big gun that's loaded with you - whatever, man. It's a gun. It fires a thing toward the thing.

Okay, now let's talk about that dodge roll. Dodge rolls are, like, really fucking important, and how this works is basically gonna shape the entire combat system.

I want the player to be able to dodge basically everything, and I don't ever want you to be in a situation where you need to dodge and you can't despite having played well. That means this is a powerful dodge roll. But that's dangerous, because it means that we could potentially wind up with something exploitable. If you wanna see how a powerful dodge can go very wrong, play Metroid Other M. I mean, don't play Metroid Other M, nobody should play Metroid Other M, if you run across somebody who's currently playing Metroid Other M you should put the gun to their head and pull the trigger because that's a mercy killing, you're doing them a favor, man, the longer you hesitate the more they suffer.

But if you did have the misfortune of touching that shitfest: man, that dodge is fucked, right? It's long, it's basically all i-frames, and it doesn't really have any starting or ending lag, and there's no stamina system to punish you for spamming it. The optimum strategy for fighting shit in Metroid Other M is to hammer on the D-pad like a cretin and hit the fire button whenever you're charged. It's fucking terrible. We don't want that.

We also don't want a stamina meter, though. Kid Icarus: Uprising is a game I love to death, and it's a game that balances a dodge roll that could be just as spammable as Other M's by tying it to a very limited stamina meter, and that works - but it changes the way you approach the game by creating very distinct offensive and defensive phases. When you go on the offensive, you get as much mileage as possible out of that dodge and focus on hurting shit; when you're on the defensive, you want to recover stamina, and you avoid taking risks or going after enemies if possible so that you can get back to a proper offensive position as quickly as possible. That's a really interesting rhythm, and it can be really beautiful how that game will make that tempo switch six times in six seconds - but that's not what I wanna do here. The Zelda structure carries with it a totally different pattern of action and rest - we're inheriting the whole screen-scrolling system from the Game Boy Zelda games, and that means we need to build around skirmishes. When you enter a screen with enemies on it, your first priority is to remove them before they remove you, and once you've done that you can focus on whatever else is happening. Kid Icarus (by which I mean the only Kid Icarus game that actually even sorta matters, because the side-scrollers kinda sucked, yo) is a more pure-blooded action game, one where you're either currently in combat or moving from one combat site to another; we've got puzzles and dungeon navigation and shit for our downtime. We don't need those moments in combat where it's okay to take a breath - you can take a breath once the screen's clean; right now, you wanna kill these dudes, you dig?

Okay, so: powerful dodge, no stamina meter. How do we keep that dodge as useful as it needs to be without making it spammable?

[​IMG]

Answer: no startup lag, decent amount of i-frames, variable ending lag.

Let's break the dodge down to three discrete phases:

1) player hits the dodge button, enters dodge
2) player is invincible
3) player is vulnerable during ending lag

If the player is spamming the dodge, they're gonna use it at times when combat doesn't demand they use it, and that's what we want to be punishing.

If you dodge successfully - that is, a bullet passes through your hitbox while you're invincible - we skip the ending lag entirely. Doesn't happen. You made a precise, artful save and that's rewarded by letting you immediately come out of that and start hitting things and dodging more hits. Chain a few of these dodges and you should feel like a badass - if your timing is good enough, you can just dodge into another dodge and dance around in a hail of fire.

But you can't do that forever, because you can't fire during the invincible phase of the dodge! Anything onscreen will still do damage, but the fire buttons don't do shit for that - let's go with 15 frames - that you're invincible. Positioning still matters, then, because the only way you can get back to punishing things is if you're free and clear. What the powerful dodge does is give you the freedom to do that - you can dance around the screen and get to good firing positions as enemy positions and bullet patterns make them available.

The nature of this system also allows me to encourage different weapons on different screens in an organic way, instead of having the common "GET THE SPREAD GUN > FIRE THE SPREAD GUN > GOTO LINE 10" anti-pattern. Rapid-fire weapons have superior DPS, but they require you to be able to hold a position for a second or two to do real damage, because if you're just firing a stray round off between dodges a machinegun isn't going to do much. Slower, single-shot weapons let you pack more oomph into the shots you can get an opening for. Different screens will have different properties - enemy types, enemy numbers, availability of cover - that'll change the weapons you want to use.

In effect: shooting becomes a Zelda puzzle. The properties of your weapons synergize with the properties of the skirmishes to create a lock-and-key pattern, where (ex) you can find that the spread gun isn't actually doing much, but that wildly impractical lightning gun you picked up three hours ago and figured you'd never use again can tear through the room, because its weird-ass firing pattern is ideal for hitting multiple targets with environmental cover from the shitty real estate they're forcing you to inhabit.

What happens if you do take a hit, though? I'm not quite nuts enough to posit a Zelda-like where you die if you take one hit, but I also want those hits to matter, and (for bonus points) I'd like to avoid scenarios where the best move is to play it safe and try to wait for a health refill pickup.

I really like F-Zero, and I swear that's not a non-sequitur.

One of the things I find most interesting from a design POV is the way the post-SNES games don't have a boost meter. You boost by burning through your life bar. I love what that does to the rhythm of the game - boosting becomes an inherently risky venture, since you're less able to survive collisions for each boost you use, and health refills are available maybe two or three times in a lap. But it's also something you want to do as much as possible, because, y'know: racing game. Gotta go fast. And, besides, even if you have a comfortable lead, it can be more dangerous (even in terms of how full your life bar is!) to not boost than it is to boost - the AI is brutal, and if you give them the chance they'll ram away half that life bar and leave you in the dust. And then you're still out of boost power, but now you're also in 20th place. There isn't a safe play; you just have to weigh two different kinds of dangerous.

I'm totally stealing that.

Each shot from your weapon uses a certain amount of your energy. If you run out of energy, the only thing that you can fire is the basic weenie gun.

Each hit you take also drains an amount of that energy, and if you get hit at zero energy?




Attacking hurts you. Not attacking hurts you more, because you do have to attack. Dodging and using the room layout for cover become critical not just for staying alive, but for conserving that "ammo" to use in actually attacking things.

How do you replenish this currency? I don't want health pickups, right? The obvious solution is for it to regenerate automatically, but automatic health+ammo regeneration and cover and OH NO IT'S A COVER SHOOTER ABORT ABORT ABORT.

Well, I want "aggressive," yeah? So how about just restoring your energy meter to full each time you kill something?

That's a fun concept. It creates a situation where, when you're in a bad spot, the only thing that can save you is to just say fuck it and go on the offensive. And it plays nicely with our powerful dodge - because that's always an option, even when you're out of energy, so you always have a fighting chance. Even if you're shooting a giant monster to death with the weenie gun while trying to avoid any sort of hit lest you immediately keel over dead: you have a chance. But the only thing that'll let you seize that chance is if you quit worrying about the legitimate danger you're in and just... take a breath and go to work. You've fucked up, and now you need to be perfect if you're gonna survive - but you can do that, and if you do, you'll be good as new.

Yeah, I really like that. It also creates a fun layer where, in difficult skirmishes, you don't necessarily want to pick enemies off one at a time - each one is a walking change of batteries for you to use, and you might need that. So you want to keep as many as you can manage on death's door, and only actually kill them either when necessity demands it or you're ready to move on. You voluntarily maintain more pressure on yourself than you have to because that pressure also contributes to keeping your options open.

Designing bosses around this system requires that they bring in adds.

Since we're Zelda up in this bitch, there's a light RPG/character-progression angle. Part of this is filling your inventory with guns - but I don't want the player to feel like that's all they're doing. And if that is all you're doing, then having a sense of power progression necessitates that some of the earlier guns will be plainly outclassed by later ones, and I definitely want to avoid that. Every gun should have its own distinct role that remains relevant into the endgame. The player should both unlock additional options for combat and traversal (in the form of guns) and improve in objective statistical terms.

We have one currency we use in combat - that energy meter. It's health and ammo in one big pool.

Okay, then: let's work with that. You can find energy tanks (but not Energy Tanks because I would get sued and I'm too broke to be sued) lying around, and each one adds 100 energy to your starting 100 points. The more of these generic-non-trademark-infringing-tanks-of-energy you have, the more durable you are. Easy enough.

But here's the problem: if you have a gun that's balanced to be usable for an entire skirmish with 100 energy, then having 800 energy doesn't do that gun much good. And one that takes 50 energy a shot to do a shitload of damage - that's a risky last-ditch thing with 100 energy, but 800 energy makes it a mainstay of your arsenal. We don't want this.

Okay, we want to increase the amount of damage the player can do - because you should feel a hell of a lot more powerful at endgame! - but we want that to be gun-agnostic. And we want the relative energy-efficiency of your guns to be more or less fixed, no matter how much energy you have: each gun has its thing, and it does its thing.

Okay, great: damage dealt by each (non-weenie-gun) shot is determined as follows: ShotEnergyCost * GunMulti. And the cost-per-shot is proportional. Each gun uses a certain percentage of your maximum energy for each shot. Having more energy makes you more durable, but it doesn't give you more ammo - every gun retains its own role, even the 0-energy weenie gun. More energy does, however mean more damage output - 10% of 800 is a hell of a lot more than 10% of 100!

There's a clear power gradient in play that doesn't muck up the cleanliness of the system with 500 different types of power-up and doesn't smooth out the fundamental differences between your various guns. That's good shit!

Well, okay. We don't really know what these guns are or what you're shooting with them or where you're shooting them yet, but you know what? I think there's enough design work here to try and get a prototype up and running to experiment with character controls, so that's the next step.

Before that, though: let's talk about aesthetics real quick.

Since this is apparently at least in part a love letter to Link's Awakening - and, well, because I like the Game Boy - we're gonna do this with an aesthetic based on that of a grayscale Game Boy game. 160-by-144 resolution, four shades of gray, and one background layer, one window layer, and two sprite layers. I'm not gonna fret too much about making sure what I'm doing would be technically possible - let's be clear, the amount of sprites I wanna throw at this shit would probably make the Game Boy chug - but I don't wanna do anything too crazy with scaling or rotation. I want to at least preserve the illusion that this could sorta run on a Game Boy, maybe.

That aesthetic is important because:

a) the limited resolution informs how combat works - sprites are small, but even so, screen real estate is limited; the number of enemies on one screen will have to be relatively small to keep things manageable, and even a single block in the middle of a room can be very powerful as cover

b) it enforces limits on graphical fidelity that keep art within the bounds of what can be done at least somewhat efficiently.

I also want to have at least an elevator pitch from a narrative point of view, both as something to keep in the back of my mind while working from here on out and as a defense against the fact that if I don't yank this band-aid off right now I'm going to wind up with some ludicrously self-indulgent shit down the line. So let me fire up my copy of the Official 8-Bit Action Game Plot Generator real quick-like:

"You are a GIRLFRIEND. Your NINJA has been kidnapped by PRESIDENTS. Are you a bad enough GIRLFRIEND to save the NINJA?"

Maybe I shouldn't have pirated that. But, well: I'm a man of my word (not even - ditch the man part, I'm basically just a giant ever-expanding mass of my word, like Tetsuo at the end of Akira, you dig?) so that's the concept.

Next post should contain an initial prototype. I'll probably want some thoughts on character control at that time.