Tuesday, May 17, 2016

Hammer devlog 21


atm this is where I am with that boss.

I don't know who Nazaan is or how having a destructible tail and a form change qualifies as unchanging. I pulled that name out of my ass so I'd have something to stick over a lifebar, lol.

Anyway, it's getting to be at least a little bit of a fight now! Obviously, this gif has my stats cranked way up and infinite energy turned on for demonstration purposes; in an actual game scenario this thing would be balanced such that it wouldn't lose a quarter of its health from a single volley.

I actually really like the Demon's Spine teleport dash as a combat option and I'm probably gonna rework that pretty massively to open it up, because it's actually a lot of fun to do crazy shit like what I did to open this. It's basically sacrificing the ability to run a useful weapon in that slot in exchange for being able to vault around like a maniac and open up lines of fire that are otherwise unavailable.

I still need to start the second phase, and I really want to give the first phase an extra attack while the tail is out of the way, but I'm not sure what...

Mostly: I really hate what a slow worker I am. This shit is way behind schedule and I need to pick up the pace.

Monday, May 9, 2016

Hammer devlog 20


This is coming along, I guess.

It's not really as involved or dynamic a fight as I'd like atm; probably going to throw some more attacks into its rotation. And it's not really a fight at all right now, lol - you can't hit it, and its most dangerous attacks (Things What With The Tail) can't hit you. There's a whole second phase that hasn't even been started yet!

It's also really easy to bait it into endlessly rotating back and forth to try to get a lock on you right now. Which doesn't do you that much good, since you have to bait it into opening the gun hatches to hit it, but...

And of course the shitty cheat I'm using here to avoid drawing a bunch of extra art can't stay, because perspective doesn't work that way. Although I guess it's at least upbefucked in the same way that the walls are!

And I'm pretty sure I broke the FPS counter at some point because my slowdown code is definitely kicking in in spots here.

But, hey: this is recognizably a boss fight with, like, dynamics and shit. And it's got a boss battle BGM track! And it's a combat use for a big room, to boot!

Something that's obvious playing with this fight: the double-tap dodge is a really elegant solution on paper that needs to die. I'm testing on a Model M, which admittedly is not a gaming keyboard, but - the travel on the keys is just too great; it makes a double-tap not nearly responsive enough for my purposes. Given the emphasis on mobility that exists here, I'm going to have to bite my tongue and add another control: dodging will involve pressing WASD + LShift. LShift isn't ideal, but I don't want to take your hands off WASD or the mouse, so what can you do?

Well, the other thing you can do: gamepad controls are a priority. I like mouse aiming much better, and I'm building around a free-floating cursor as opposed to a more conventional twin-stick shooter setup, so the stick will always be a bit of a liability - but the fact is that a D-pad or an analog stick to move with would be a pretty massive improvement for this game!

The odd-duck mechanics here have one fun result: there's totally going to be a hybrid control scheme available whenever I get to doing Settings and Shit. Hold the left side of a gamepad with one hand, mouse with the other. Question: would it be unprofessional to have a settings screen describe a control preset as "The recommended control scheme. Warning: this will make you look like a complete asshole."?

I am, no joke, sorely tempted to try and get first-class Wiimote-and-Nunchuk support in here at some point. Not because it would make any kind of commercial sense to do that, lol - just because it's the best control scheme for this game, even if it does involve using third-party drivers to connect a dead peripheral to your PC in a completely unsupported configuration.

I mean, I guess if I was talking about commercial sense that ship sailed approximately five minutes into development, though, because I feel like there's no fucking way that "Link's Awakening but Sin & Punishment and also Dark Souls" could be described as something that has a market.

Also, I kinda get the feeling that any employment benefits of the Github are being destroyed by my commit "descriptions," come to think about it. I'm terrible about those, I know.

Friday, May 6, 2016

Hammer devlog 19

ok, so:

Yesterday I did some design work and really WIP art for A Proper Boss.

Most of its behavior I get well enough to implement now. The one problem: its tail.

This guy's got a tail composed of like 8 separate sprites. Segmented. You've seen this before, I'm sure.

The tail is swept around the playing field, getting up in your shit to complicate the space you have to dodge the boss's projectiles in. It's also used for a thrusting attack that punishes you for putting too much space between yourself and the boss to try and cheese it from a safe distance.

(The tail is also destructible and regenerates on a somewhat irregular schedule, but that's not the issue here. I know how to do that!)

The boss moves around the screen freely. The tail follows, being attached as it is, you know, a tail. Tricky part: the boss can rotate in eight directions, (though it only has four "facing" directions - the diagonals are just used as midpoints for animations) and while it can only move in four, it does need to have the tail keep a consistent anchor point at all times during its arc. Where the tail should be anchored moves around the sprite, so that's fun!

I also want this to look reasonably natural, so that's a problem. I'm doing this design in public because I am very much Not A Real Programmer - I don't dislike programming, but tbh I find it much less engaging than pure game systems design, and I've never been one of those crazy people that does crypto for fun; the primary reason I'm not the worst kind of "games programmer" type is that I force myself to at least try to maintain sound habits, and that's entirely because I know I don't have a natural inclination to such and I need to keep a codebase that's not completely unmanageable because I can produce a better game if I can experiment and iterate with some degree of freedom - and I want someone to tell me if I seem to be going about this problem the wrong way.

Okay, let's break this down in terms of behaviors. I'm gonna say right now that there's nothing which has the anchor point change during an attack cycle; if it seems, down the road, that this boss needs such an attack then fine, but right now that'd be a lot of complexity for not much in return.

1) tail follows body

Well, this is the easy part. But I can't use transform parenting here, unfortunately, so it does get a little dicier - remember the "looking natural" thing? I want to enforce a delay on the more outlying segments of the tail, so they respond to movements after the ones nearer to the body, and you get a nice arcing motion and a sense of inertia.

Enemy_BossManta_Tail MonoBehaviour, attached to the main body gameobject: manages the tail segments. Stores anchor point as a Vector3, the last n anchor points as a Vector3[], and tail direction as a Direction. Each tail segment then has an Enemy_BossManta_TailBit MonoBehaviour attached. The TailBit has a reference to the controlling Tail behaviour, and when not attacking uses that to recalculate its own position each frame based on the anchor point, an integer distance-along-tail, and the Direction specified. Distance-along-tail provides both how far out from the anchor point we want to be and which anchor point we're referring to - we only use the current anchor point if we're the segment closest to the body; if we're at least 1 segment away, we use oldAnchorPoints[distanceFromBody - 1]. But since the Tail continues recalculating its anchor point and refreshing that array anyway: we naturally sync up as long as the boss isn't presently moving too fast for us to follow.

This does enforce a speed limit on the boss of no more than 12px/frame, because at no point should there be more than 4px' gap between tail segments. I'm going to go on record as saying I don't believe that I need to have the boss covering more than 4.5 screen widths in a second, so nbd.

2) tail sweep

This is fun because we want an arcing pattern, and we have to force each segment to move proportionally. In a single frame, the further-out segments cover more space than the nearer ones.

So let's kill one layer of complexity right off the bat: fuck doing a real arc. Curves are a motherfucker and there's no reason to bother when I can fake it. The "arc" is composed of six points. There's a start position that we move the tail tip to, and then we bring it through four intermediate points en route to the end position, and from the end position we reset to neutral.

Use a "virtual tailtip" to determine where to position the actual tail segments. This is a Vector3 stored by the Enemy_BossManta_Tail component that just represents where the tip of the tail would be if there was no delay attached to it. We move each segment by (VirtualTailtipPos - lastFrameVirtualTailtipPos) * (1 / (tailLength - distanceFromBody)). And we move segments manually like this by adding a Vector3 to a queue. The segment commits the movement by adding that Vector3 to its transform. This allows us to enforce outlying segment delay even during attacks - start the queue off with a number of Vector3.zero instances equal to its distanceFromBody and it'll "commit" these null movements before it starts processing the actual ones.

Each point in the arc is a separate bounding box. These bounding boxes move around relative to the boss body, such that they're always in the "right" place if it decides to start a swing. We find a heading that drags the virtual tailtip through the first of these boxes, apply it until the virtual tailtip is inside the box, repeat the process with the next one, and continue until the virtual tailtip and real tailtip are both inside the last box. At that point, we reset the tail to neutral.

3) stab

This is easy enough now that we've worked out a lot of the more basic problems. It's basically the same as the sweep, except a hell of a lot faster, and instead of using the fake arc system we just want the virtual tailtip to sit at a point 16px behind the player. This is literally just "player.collider.bounds.center.x - 16 if anchor point > player.collider.bounds.center.x, else player.collider.bounds.center.x + 16," and same for y.


So this guy's basically brainless right now, and it doesn't do anything else, and (surprising no one) there's a bug with the minimap I need to fix.

But, hey: that fucking tail sweep works. 

Wednesday, May 4, 2016

Hammer devlog 18

More thinking about action:

What strikes me with the shooting right now, even with the limited setup that currently exists, is that it's kinda static. Given a specific pair of weapons, you have a strategy, and if you enact that successfully you win. Your options don't really change that much with the ebb and flow of battle, though - if you can manage your energy meter, you're always going to be okay.

I do like the energy system, though! Still, there's a real need to inject dynamism into this system. I don't want a real "resource conservation" layer, - thematically, I want to create situations where each fight is real, each fight is important, each fight can potentially kill you very quickly - but I do want something more limited than your standard weapons which you need to effectively incorporate into strategies.

Let's call this a bomb for now. There are a number of different acquirable bombs; you can only have one equipped at a time; changing what you have equipped isn't as trivial as changing your guns out. I have a vague inkling right now that the center of the game world is a village, with NPCs inhabiting it, and the village and its occupants grow and change as you progress throughout the world; requiring you to visit the village to change the equipped bomb is a good way to encourage the player to touch base periodically and participate in those stories. It's purposefully inconvenient - this is a powerful but limited sort of tool, critical but unavoidably secondary to your firearms.

There's less variation in the different types of bombs that you can acquire - they all have the same usage conditions and they all have, at least, the common effect of wiping enemy projectiles on the screen and rendering you briefly invincible - but there should still be a different variety to choose from. One might, say, spawn a ring of fire that expands outward from the player's position, dealing heavy damage to enemies it strikes - but this sacrifices a lot of the defensive utility other bomb types can offer, because its i-frames are minimal and once a foe's within the ring they're good to open fire again. Another might be a pulse of arcane power that not only neutralizes the bullets it strikes, but actually converts them to restore a small fraction of your energy if they strike you. This is an exact opposite to that firebomb - an almost entirely defensive weapon that's about sustaining and supporting an offensive strategy carried out with your main weaponry. The important part is that each bomb is very much unlike others. You might have a favorite gun, but it's not always going to be appropriate for every situation - if you want to put a nail in, you've gotta use a hammer, you know? But bomb types allow for a kind of build flexibility. There's no point where a specific bomb is "called for"- in as much as bombs need to be incorporated, any of them will work - but your personal play style will inform your preferences, and as you try out the bombs you acquire you'll gravitate toward one or two that - given the hassle of setting a different bomb - are basically your go-tos.

I want bombs to be less expendable within firefights than bullets, but they should still be basically worth using at any given time. You don't save your bombs for the boss - the idea is that every single fight is a struggle to survive, and you give it your all because anything less isn't enough. So: one bomb at a time, 60 seconds to automatically recover it. 60 seconds is a long time in a game this frenetic, and you can't just stall it out to use bombs without thinking. If your bomb is used up, that's a solid minute that you're up shit creek without a paddle - you want to make sure you're bombing because you need to be. But, at the same time, 60 seconds is brief enough that you can assume you'll always have a bomb going into a firefight, and it's brief enough that you can use multiple bombs during extended bouts, boss fights, and the like without stretching yourself too thin. You can't spam bombs, and you have to play smart with them, but if you are playing smart, you can generally assume you'll have one when you need it.

"Bomb" doesn't really fully describe how this works in a mechanical sense, of course; it's clearly of a kind with more conventional scrolling and twin-stick shmup bombs at the most basic level, but the additional effects are all very powerful things - things that can totally change the tide of battle - which don't fit anywhere within that model. Having an idea what a "bomb" of this sort actually is is handy, because a good name - a good metaphor - should give the player an intuitive grasp of both the significance of these tools and the comparative lack of pliability of them.

Thinking about setting for a moment, since it informs that: unfortunately, the ridiculous Liberty Gang concept is probably not gonna stay, lol. Doesn't work with the tonal notes I wanna hit - desperation, struggle; the moment when you've pushed forward through adversity until the unrelenting has relented, and discovered something beautiful and wholly unexpected beyond that boundary that you were never meant to cross. Boundary-crossing - transgression - as a key concept: going places you shouldn't be and confronting a world that seems almost malevolent in its desire to expel you and punish that insolence.

Kind of a schizo-tech sci-fi fantasy vibe I'm getting so far, which works with the emphasis on exploring a world that is alien, enigmatic, and actively out to get you.

So if guns tend to have a more technological bent - even "more magic" ones being decidedly physical, fleshy abominations that nonetheless can be understood, can be reasoned about in physical "does X if you Y" terms, our "bombs" are explicitly magical in nature. There's no physical form to what you find - just a glyph on a wall that's utterly worthless before you've performed the necessary rites and rituals to convert it into a magic that you can deploy at will.

This is a Taboo. This is the first bit of really ironclad setting info, I guess, because this is mechanically mandated: Taboos are discovered embedded in the environment and learned by interacting with the hidden glyph. A new Taboo is never just sitting in the center of an obvious treasure room - the glyphic patterns can be anywhere; a pattern in the dust on a floor, the flow of water out of a rock wall, the shape a pile of rusting scrap has taken over the countless years of its slow decay. They're not brought to your attention, they just are, and they're rare and precious enough that spotting one and successfully learning its Taboo should feel like a Big Deal - and you should feel really clever for so much as realizing that that thing was a Taboo glyph.

Interacting with a Taboo glyph provides a brief message from the past - a message with unclear context, but an explicit element to an otherwise very downplayed story told mostly through environmental details. And this interacts nicely with the environmental storytelling - Taboo glyphs reward you for scouring the environment, both in a mechanical sense (by giving you new tools for keeping a sharp eye on things) and in a narrative sense, by providing crucial breadcrumbs that help you to contextualize things. Taboo glyphs form at the final graves of other, anonymous, long-dead transgressors, others who had the same kind of avaricious spirit that you do in days long past - and staring into the glyph gives you a glimpse into the things these boundary-crossers found in their lifetimes. The Taboo glyph is, in effect, a scar on the world that reveals the boundary that these past transgressors were unable to escape the penalty for crossing. A Taboo glyph isn't simple "a taboo," but rather a token of the specific taboo that killed someone much like yourself.

And if you want to get strong - and you have to get strong to make any headway in this world - then you need to scan every nook and cranny, find the hidden Taboo glyphs, and turn the failures of these past transgressors into a source of power for yourself.

So: you find a Taboo in a strangely formed snowdrift, and you hear the dying words of a past adventurer who fell to the icy corpse-soldiers that patrol these parts - this is the Taboo of someone killed by the sin of intruding upon the land of the dead. This teaches you the new Taboo "Memento Mori" - but you don't have that Taboo set yet! If you want to try Memento Mori out, you have to find the nearest checkpoint and warp back to the village - and if the boss here isn't dead yet, you won't be getting back easily. That's a decision you have to make, and it'll likely depend on how comfortable you are with your current Taboo. If you're not feeling it, an effective new Taboo could be worth backtracking; if your current Taboo really works for your playstyle, then a new Taboo is more a curiosity, something neat to try whenever it's convenient.

At any rate, though: you go back to the village, you talk to a character that we'll call the Necromancer for now, and the Necromancer is able to perform a rite that binds the restless soul which created the initial Taboo glyph to a token, after which you can invoke the token's power simply by thinking a thought that violates the Taboo attached to it. This sets the bound spirit free in a brilliant magical display, but renders the Taboo unusable until the spirit returns to the token. This seems like a simple narrative framework that should communicate the gameplay concepts of the Taboo system to players in a way that feels intuitive, logical, and thematically appropriate: find a glyph in the world 'cause someone like you died there, memorize it when you do but all that actually means is you've memorized a glyph so of course you can't do anything with it immediately, go back into town and Mr. Magic Dude turns that into a spell you can use, (the "bomb") you have to wait for the Taboo to recharge because there's a ghost that's physically released from an item on your person when you use it and it doesn't go back into that immediately.

As for actually using the set Taboo: left click + right click feels like a simple, intuitive solution that doesn't needlessly complicate things by adding extra inputs and doesn't remove your hands from where they should be. Given the fact that Taboos are relatively fixed, I'm thinking you don't really need a full inventory slot for it visible in the HUD - just a little icon that indicates that you have a Taboo available - but of course there should be a screen in the inventory menu that contains the specific Taboo glyph you have set and lets you select that to get some more information on it, plus provides a list of the other glyphs you have available, even if you can't equip them here. No reason to hide that information from the player just because you have to go back to town to set a Taboo - hell; as mentioned, there's a dilemma with the issue of whether to go back to try a newly acquired Taboo out immediately, so providing that information in the inventory is really the least I can do from a user-friendliness standpoint. You can't just equip Memento Mori right here right now to try it out, but you can get an idea of whether you're the kind of YOLO-ass offensive player that "Releases a wave of death in all directions, dealing heavy damage but also hurting yourself" sounds like candy to, or you want no part of having a major defensive tool like your Taboo eat your own energy no matter how much damage it does.


Minimap is fully functional.

This is hands down the scariest, ugliest piece of shit code I've ever produced and I'm fully expecting it to explode for no clear reason down the road, at which point I'll likely just rewrite the entire fucking thing. I literally do not remember writing most of this. It's, just - fuck, it just appeared, glistening in the moonlight and smelling of blasphemous ichor. 


Implemented a really basic Taboo. This isn't even finished yet, but it's in place, at least.

Concept for this is "eyes;" not really sure what I wanna call it or what it does visually - but what it does from a gameplay POV is take possession of every bullet on screen when it's used and then set it to a specific new heading based on the direction you're looking in.

The Taboo cooldown system, casting animation, etc. are all in place. There should really be a more visually significant indicator when your Taboo is ready, of course.