Sunday, October 9, 2016

The coolest trick the Pokémon games ever pulled was broken before it happened

This isn't another Hammer devlog, I'm afraid. I'm still working on that, but it's kind of on the back burner right now; I'm putting most of my energy into job hunting!

This is just a blog post containing some thoughts on Pokémon - or, rather, one specific Pokémon, and the really nifty trick it almost pulled from a game-design perspective by blending mechanical edge-cases with the social nature of the Pokémon games.

Basically: it occurred to me recently that it's a real shame Shedinja happened after the Pokémon games were A Thing instead of back during generation I. Everybody just found out about it from external sources, really; no one discovered it. And that's a shame, because it means that Shedinja isn't half as cool in practice as it should be - but mechanically this thing is great, if you don't go and document exactly how it works before anyone actually finds it on their own.

Saturday, August 20, 2016

Hammer devlog 38


Some new visual effects: First off: fixed the pop-in that was happening with FX layers.

More notable: the "scanlines." (they're not actually scanlines, but hell if I know what they're called) But, yeah - now there's a neat little screen overlay effect that emulates the line artifacts between the physical pixels on the Game Boy's LCD screen, which makes the low-res pixel art here look a lot more natural. I actually have a script attached to the camera that generates that overlay texture based on the screen resolution, which lets me create these rigid borders between my giant pixels no matter what you're actually rendering at, and successfully creates the illusion of a lower-resolution display. Advantage of going after the Game Boy aesthetic: it's not a CRT, it's just a really shitty LCD, and that's way easier to fake convincingly.

Also visible: there's a subtle color-accumulation motion blur on the main camera now. Just a standard image effect, but it took an embarrassingly long time to calibrate it - goal was to capture just a bit of the authentic ghosting, but without actually doing DMG-001 fuck-this-shit ghosting. Targeting a look more like the Game Boy Pocket or the Game Boy Color - slight ghosting, enough to be perceptible, but not enough to hurt playability. Can't really get the aesthetic to work without the ghosting effect, though - the LCD ghosting creates this gauzy, dreamlike effect, which is a big part of what makes Game Boy games look like Game Boy games.

Also also: an enemy that's nowhere near done.

Monday, August 15, 2016

Hammer devlog 37

Testing some more art for this tileset. Just a quick video to get some feedback on the how the tiles work in use. No real gameplay - just wandering around that new room. Couple of tiling goofs with the snowdrift up top, but it's a good general idea of how these exterior ruins areas should look.

Also notable: firing the gun that teleports you where your projectile lands in a room that's mostly pit is a bad idea. I'm fine with that behavior - it's silly, but in a "what did you expect" way. The room is nothing but shoot-through walls and pits! Of course that thing's not a good idea!

Tempted to add a background tilemap to this room and write up a parallax scrolling system; I think I like the buildings, but they'd provide a much stronger sense of the depth of the gorge if you had a decent parallax setup going with them. Layered scrolling would break the aesthetic a bit, but I've already got effects going on here that are well outside of what the Game Boy could do - that blizzard is in "probably doable in a demo" territory on GB hardware - and I don't think it would hurt the feel more than the illusion of depth would help.

Speaking of that blizzard: yeah, doesn't really work in this room. There's a snowdrift at one end and some scattered patches elsewhere on the structure, but you've got that wind SFX going and that crazy blizzard flying around. Probably gonna do a light-snow FX layer for rooms like this.



Parallax and a light-snow effect.  

Tuesday, August 9, 2016

Hammer devlog 36

Anyone paying attention to this devlog may have noticed that I've stopped being as good about updating it as I was. Well, uh, when I started this project it was just "something to do a devlog for." As is, this is a game I'm actually looking to make and to release. Unfortunately, that does mean I'm reflexively going to hold my cards closer to my chest - if I'm looking to create moments and sequences that have specific effects on players experiencing them for the first time, I'm going to be somewhat more timid about talking about exactly what I'm doing there. Sorry! I'll still try to keep a decent flow together, but odds are the devlog's gonna get increasingly high-level and detached from finer design points.

Anyway, though: this is just a technical thing, so that's not a problem that we really care about.

I hacked animated tiles into the off-the-shelf tilemap class I was using. Basically, I can set a specific tile ID to represent an animation, and give it references to other tiles in the tileset that it'll cycle through at a predetermined interval. Nothing fancy, but it's something that'll let me do a lot of really cool things with environmental details, background effects, etc. What you're seeing here is just a floor that cycles through some random wall tiles, lol - but the feature is in place and it works great, which is the important thing. If I want, say, animated water tiles now: I specify the way the water tiles animate, and then I just lay those down as part of the tilemap and they do their thing.

You can also see some other things - the least visible (but most notable) is the player movement, which is a little faster, more responsive, and feels a lot nicer in combat scenarios. TBH I'm probably going to have to set a deadline after which I can't touch that, lol. Otherwise: gonna be pushing git commits five days from launch with the same "character movement is less terrible" commit message I've used way too many times already. But getting that right is really important, so I'm more than willing to go back and try to massage it into something nicer as often as is necessary, right now.

Also visible: the energy meter is gone. I'm still prototyping the mechanic that you see there, and I'm not really entirely happy with the way it works right now. When I am, you'll see a detailed explanation of what the hell that meter is and how it works.

Friday, July 8, 2016

Hammer devlog 35


Pitfalls and a very WIP flamethrower weapon.

The flamethrower isn't exactly balanced right now, lol. It's seriously underpowered. But it's a neat effect; I just need to make the damage output and the hitstun worth putting up with the range.

Wednesday, July 6, 2016

Hammer devlog 34


There are a few things going on here.

The first thing you'll notice is that the left room has changed up a bit. I've done yet more tuning with that test encounter to try and improve the feel of combat. The enemies themselves are also a bit better - the AI has changed a little bit, and that combined with the new room layout feels more "tough, but fair" compared to the older versions.

The next thing you'll notice: new bullet graphics. I've completely revamped the way bullet graphics work. It's not the prettiest thing in the world.

(Mecanim state machines don't allow for instant state transitions, so I actually use a set of lookup tables to determine a state ID to poke into the animator whenever I fire a bullet, because that's the only way to keep it from taking two frames to load into the state with the appropriate clip attached to it. There is a no-shit region declaration, because the arrays that are already in place are like 90 lines, and by the time all of the shot types I'll want are implemented you'll probably have around 1000 lines of "shot_SomeFuckingThing = { animator.StringToHash("shot_SomeFuckingThing_down"), animator.stringToHash("shotSomeFuckingThing_up")..." going on there. Every shot type needs its own value in one of the primary lookup tables, and if its graphics aren't angle-agnostic, it needs its own secondary lookup table to determine which state corresponds to which direction. It's horrifying. The good news is that this actually makes the code itself surprisingly elegant - do some quick math with the weapontype to determine which lookup table we need to use, then turn that value into an index to use within that table and (if necessary) cast the calculated direction back to int and pass it to the secondary lookup table as an index. But, man, those tables are obnoxious.)

Anyway: I can change bullet graphics with angles now. I can also do animated bullets!

The last thing you'll notice: what happens when I touch the ladder at the end of the gif. Replacement rooms are implemented. Literally just another room object that's attached to a ReplacementRoom controller, placed out of level bounds, and told not to install itself into the big World.Rooms array on level load - the ReplacementRoom just watches a flag, and when that's true - and the target room hasn't already been replaced by a higher-priority replacement - it destroys the old room, moves the new one into its position, installs that in World.Rooms, and iterates over all the in-level warps and doors pointing to the old room in order to make them point to the new one. This is kinda costly for simple room-state things - you'd never implement something like that ladder as a ReplacementRoom - but it allows for dramatic changes in level configuration in response to things that occur within the game, which is great. Think of Link's Awakening's Eagle's Tower - you activate a switch, and the entire center of the dungeon map changes seamlessly. ReplacementRoom enables things like that. It's not animated, and I wouldn't actually want to do anything as dramatic as what happens here while the player is in the room, but it provides the ability to substitute a completely different set of tilemaps, collision, and room objects on a whim.

Final note: the ladder isn't actually broken. It looks like it is, but it's not. What happens here, basically: when you touch a rope ladder, it sets the flag immediately in order to ensure that the shortcut remains accessible even if the player leaves the screen or dies while the ladder is still unrolling. It's just a quality-of-life feature - you can't lose a shortcut you've activated just because you didn't wait for the animation to finish; if you don't want to use it right now, you don't need to stick around and wait, you can just start it unrolling and walk off. But the rope ladder in the replacement room is actually a different GameObject, given the way that system works! So rope ladder 2 wakes up, immediately discovers that its flag is already set, and activates itself without the animation. It's just a weird quirk of gluing two shitty test objects to the same flag - the rope ladder works, the replacement room works, but the replacement room using the flag makes the rope ladder look like it's broken.

Sunday, July 3, 2016

Hammer devlog 33


Revamped the way player movement and collision work behind the scenes in order to facilitate ice physics.

So, there are ice physics now.

I'm not thrilled by these exact ice physics; there'll probably be some tweaking and rebalancing of the way this handles momentum. But it's a proof-of-concept for zones within rooms that modify player physics, which is the important part.

Saturday, July 2, 2016

Hammer devlog 32

Did a lot of behind-the-scenes design stuff over the past few days; feeling much better about that. But that's not what I'm posting!


Finding and utilizing permanent shortcuts that you can open up in the world is a key part of progression in this game. So objects like this rope ladder are probably gonna be pretty commonplace. Obviously, shortcuts shouldn't just amount to "rope ladders errywhere," but in a certain sense anything else is just a fancy version of this ladder anyway.

Also, yes, that's just sitting in the middle of an indoor room. I was initially actually-bothering with room layouts here because I wanted to make sure my tilesets were sufficient to build a level from - now that I know that they are, I'm willing to admit that my strategy, such as it is, is basically just "puke objects all over the floor."

Monday, June 27, 2016

Hammer devlog 31


Title logo w/ animation, working title.

Also: level loader! I can load the player in at arbitrary coordinates within an arbitrary level - just point to a set of room coordinates on the target map and an entry point within that room. Totally seamless. This is important to have in place, given how I intend the world structure to work.

I'm rapidly reaching the point where I'm going to need to start looking seriously at doing more detailed systems balancing and designing actual content.

I haven't written a design doc yet, because I was just doing prototyping up until now, but at this point I have a firm enough handle on things that I'm going to have to do that. Uh, well.

Friday, June 24, 2016

Hammer devlog 30


Testing a more feature-complete take on the in-game menus.

The System tab will eventually let you respawn immediately, open the options menu (this is the entire reason that the options menu is decoupled from everything else on the title screen to the extent that it is - I want to be able to prefab it, drop it in, and have it pop up here), exit to title, or quit to desktop, but right now it does exactly none of that.

The gear tab is still very much incomplete - you should notice a bug in this gif!

The weapons tab is nothing new, although that horrible background is gone now, so that's nice.

This is a new font; it's probably not the last font I'm going to try, because I'm not that thrilled. I can get really nice rasterized rendering out of it, but it's not as legible as I'd like.

Wednesday, June 22, 2016

Hammer devlog 29

I have been very busy today, but mostly because I decided to say "fuck it" with my homegrown input manager, suck it up, and implement the old-ass free version of InControl. There was, in fact, much less headache in dealing with the lack of updates than I'd expected there - literally, the only thing that's come up right now was a single one-line fix. And that'd still compile; it was just a deprecated thing that spat complaints into the console window.

But I did do one more visible thing. It wasn't actually a lot of work - just gluing some things I'd already done together - but cool features that come for free because of good development practices are the best kind of cool features.


Nifty little blizzard effect. Not too overstated, but it doesn't compromise visibility too much and it makes the outdoor areas of this test map (since I'm probably gonna recycle some variation on this tileset when I get to doing actual content) look a lot nicer. The heavy lifting's done by the generic scrolling-layer-looper thing I'd already done; the only new things here are the blizzard graphics and the FX layer thingy that makes sure the scrolling layer is only active if you're in (or entering) an applicable room.

Sunday, June 19, 2016

Hammer devlog 28

Took a break from horrible boring menus and behind-the-scenes data management because I was going to put a pair of scissors through my temple if I kept that up. I felt like an application programmer, except I was trying to build my application in Unity and the UI tools were off limits. It was like living a nightmare.

A nightmare I still have to go back to, mind you, because that shit's not nearly done...

Anyway, though:


Ledges! You can hop down them. They make a hoppy sound. For some reason the hoppy sound doesn't show up in the gif, and I can't seem to make it no matter how many times I try. Why does the jiff specification not allow the embedding of hoppy sounds?

Also visible at the end of the gif: I fixed up the way player hit detection works a little bit. Hit anim is nicer, stun is less obnoxious, and you carry more useful i-frames out of a hit.

Monday, June 13, 2016

Hammer devlog 27

Oh, right, another thing:

One of the passive upgrades is something I've had an inkling about for a while, but I haven't really been clear on how it'd work. I like the idea of having autoscrolling rooms, you see? I thought it seemed like a fun genre changeup that still maintains enough of the main gameplay loop that autoscroll rooms are a "change of pace" without feeling disconnected from the rest of the game in a mechanical sense. You still have the same character, same resources, same controls; it's just that now you're trying to fire and maneuver as you're whisked from point A to point B at a breakneck pace, instead of putting those tools to use in the more cerebral game about space control and pattern recognition that the "standard" combat is.

"Cerebral" is a relative term, of course - because combat is never exactly slow. I love Dark Souls to death. I even tolerate Dark Souls II, mostly for its DLC. I haven't been able to buy Dark Souls III yet on account of being broke af, but I'll probably like that, too! But I'm bringing these up because, while there are definitely some Souls-y aspects to this game, they also offer a really useful contrast as far as pacing goes. Dark Souls wants you to watch patiently, avoid going in half-cocked; it's a fairly gentle game moment-to-moment that finds difficulty to allowing your mistakes to accumulate. Hammer does not do that. Hammer is the kind of game where if you're doing perfect for 90% of the battle and then you spend a couple seconds dropping the ball, you're dead. The player is much more powerful relative to foes than they are in Dark Souls because they have to be - you're expected to perform with speed, efficiency, and precision in equal measure. But the nature of playing efficiently does preclude the purest sort of reactive arcade action - the energy system will punish you for tackling encounters without a gameplan, right? You have to prioritize targets and use space to maximize your own opportunities for offense while minimizing the times at which you're exposed.

Autoscroll rooms, then, are a "different" kind of shooter: pure bullet hell, fast enough to make ground combat seem kinda pokey, with much more emphasis on simply... reading stimuli and reacting to it. No level terrain, no cover, no hazards or obstacles - just you and wave after wave of foes, and your goal is just to keep yourself alive until you're automatically delivered to your goal. The situation is too fluid to make a plan that'll do you a damn bit of good, and while there's less mechanical complexity here it can be difficult to stay alive in spite of that just because of how fast everything is shifting and changing.

I don't want autoscroll rooms to be a frequent thing, mind you; they should be a fun, kinda stressful break from the more standard gameplay rhythms. Equal parts refreshing, even relaxing - you're not expected to be working out battlefield tactics with bullets flying at you from all directions; you have exactly one tactic, "dodge things, fire at them," if you get into the zone it should feel kinda Zen - and harrowing. You're having a blast the whole autoscroll interlude - let's say we want these to be about 90 seconds long on average - and then you're really glad it's over.

So basic gameplay rules of an autoscroll room:

a) you're automatically pushed forward along a "room" without room collision at considerable speeds. You can maneuver freely around the screen with the same controls you'd use for walking.
b) enemies fly in - mostly, but not always, from the same direction you're moving in. These are fast-moving, somewhat more regular in their patterns than standard foes so as to be easier to read, and typically very deadly and very frail. You're going to have great difficulty taking more than two hits and surviving, in most cases, but you can also kill something with basically whatever weapon feels good, and the free flow of energy lets you be cavalier with expensive things that you normally have to be much more reserved about playing with.
c) the bottom of the screen has a progress meter - literally, a track representing the total length of the autoscroll room w/ a player icon that moves from one end to the other; you know exactly how much longer you need to hold out at all times, which can be both reassuring (just a little longer) and really harrowing (FUCK I AM GOING TO DIE LIKE FIVE FEET FROM THE END OF THIS STUPID THING FUCK)

As for the role autoscroll rooms play in larger game structure: well, I think I'd be remiss if I didn't take advantage of the obvious fact that, given the Metroidvania aspects of this game, you're going to notice that 90 seconds of autoscroll is a long fucking room. That's enough to cross a huge amount of space.

So: autoscroll rooms act as quick transport between outlying regions. An autoscroll room is mechanically and aesthetically "other," compared to the more standard gameplay types, and it takes place in a space which suits that. When you enter the autoscroll area, you're shunted off into a... "tunnel" or "wormhole." Aesthetically, I like the idea of rendering this by actually using a garbage mix of tiles from the two connecting regions, with each "side" of the autoscroll room having greater quantities of tiles corresponding to its associated region. You're poking a hole in the world and speeding through a space that doesn't behave by the same rules to get where you're going - so working with my Game Boy aesthetic, a "glitchy" garbage screen (think the g1 Pokémon games'"glitch cities" for a quick idea of what this looks like) is an effective way to get that concept across.

You never have to enter an autoscroll room to get where you need to go, but it might be the most efficient path. World design rule here: there should be a back way into any space of any importance. If you need to get somewhere, there should never be a scenario where you don't have multiple options, either in the tools you use to get there or the path you take. So, from this angle: anywhere you go using the autoscroll rooms is still connected to the rest of the world, and you could get there without ever entering the autoscroll, if you wanted. But being comfortable using the autoscroll mechanics as a means of getting around can be useful. You might, for example, be able to dive just a little bit deeper into a space you've already made some decent progress in, find an autoscroll entrance, and come out deep into a region you haven't really touched yet, really close to the boss! Exploration is rewarded - and since autoscroll rooms are difficult challenges located at far reaches of the world, tied to a hard-to-obtain "key" item, the rewards you can get out of taking that leap can be huge. This falls back to boundary-crossing as a theme - entering the autoscroll room is choosing to "cross over" and take a step into the unknown. You either die or you get spit out somewhere interesting.

Narratively, then: keeping in mind the sort of thematic content and aesthetic language I've been working with, and the role these spaces play, I feel like it works really well to have the autoscroll rooms situated in a "world of mirrors." Literally - each autoscroll is the non-space that connects a pair of arcane mirrors located in the world. We'll call these looking glasses - devices dating back to times long since faded from memory, constructed to allow their masters to keep perpetual watch on... something. Built in pairs at spatial extremes - a great mirror and a sentinel's seat; each sentinel keeping vigilance over their own station, their counterpart's... and each other. But now the seats are empty, the mirrors dusty and forgotten, and whatever they felt it was so key to keep watch over can no longer be seen.

The key item that you hold to gain access to these spaces: the Sentinel's Mask. Again, we're just trying to go for broad strokes right now; tone, themes, important images - let a more coherent narrative emerge naturally from these concepts. So, the Sentinel's Mask - the cursed mask of one such sentinel who fled their duties. Whatever they saw during their watch broke them; they abandoned their post, and with it the ceremonial mask that these sentinels used to hide their individual identities from their counterparts. The mask of dereliction of duty is an affront to whatever power enables the looking glasses to function. When it's brought into their presence, they shatter instantly to deny the traitor their use. But there's a perverse kind of usefulness to this thing - because while it does mean that you can't see the looking glass's destination any more, you can also step through the broken mirror and emerge on the other side.

Hammer devlog 26

Most of what I've been doing this week hasn't been particularly visible.

But here's a gif of something that's subtle but definitely there:


So part of the big input rework that went on here involved fixing the shitty, janky way the analog aiming behaved before. This isn't perfect, but it's much nicer-feeling; the reticle moves reasonably fast if you need it to, but there's enough of a curve to its move speed that you can make minute adjustments by gentler motions of the stick.

Monday, June 6, 2016

Hammer devlog 25

Let's talk about what happens when you hit that New Game option anyway, though.

Here are my immediate goals with the opening sequence:

- establish player's understanding of mechanical fundamentals well enough that I don't need to lean on further tutorials, and can trust they have the baseline competence necessary to navigate the world and respond to challenges
- establish tone - surreal, otherworldly, dreamlike, but unmistakably hostile; an initial "crossing over" that establishes that whoever your character was before is unimportant, that what happens from here is what matters, and allows the player to inhabit that avatar without really feeling burdened by preconceptions about what that character is supposed to be
-provide initial goal of game progression: kill three bosses at extremes of the world, take their monolith fragments, bring those to the stone circle; establish that this is probably a bad idea and rely on player curiosity and the drive to make progress to see that happen anyway

I don't exactly have a fully-formed narrative here, but I have some scattered ideas, and this is what the opening needs to do for those.

Mechanically, I want to start the player off without a single weapon. Mobility is paramount and that needs to be the first skill you learn. Once you've got dodging down, you acquire the starting pistol, and you can start to fight back against things and learn those mechanics.

Navigation is also an important skill to teach here. The world is sprawling and interconnected, and not every path is visible right away. So this intro area needs to be complex enough that it requires you to put some genuine thought into getting around and moving toward your goal.

So here's the basic script: player starts in a safe room, given the narrative suggestion that they're fleeing... something. Not just "something"- something that you've earned? A miserable fate that you've got coming, but somehow you've wound up here instead. Details aren't really important right now, just tone. This is a room with a gate, and when you cross the gate you wind up... somewhere else. For now, let's call this area the Oubliette. Basic concept - it's a purpose-build tutorial level that mixes the three main regions' tilesets, switching it up from room to room and giving you a sampling of the kind of places that exist in the game world. A surreal, disconnected, nonsense space; something that makes it clear that, whatever happens, you can't go back - this place physically should not exist, and even if you can cross over one way there's no reason to think that something so capricious can be treated like a "normal" space, that it's the same thing whether you're coming or going.

You enter the Oubliette, you're immediately beset by enemies. You're unarmed and things are still pretty linear right now; you wind up just making a mad dash "forward," naturally learning to use the dodge roll because it's the only thing you have to keep yourself alive. This teaches you - the timing, the spacing, the i-frames, and since you will take hits, it also encourages you to learn to work with the dodge regen and use that to stay alive. You cross the length of the Oubliette and wind up reaching another safe room, which contains a checkpoint thingy (because you should die when you first start trying to handle combat, and this teaches you that death isn't that big a deal) and the starter pistol.

With the starter pistol, you can leave this room and start fighting the things that you were fleeing - very basic, easy foes. After making your way a few rooms back, there's a cave blocked by a destructible barrier, and the pistol enables you to enter that; this cave is a fairly short area, but it lets you make your way onto the upper level of the room you entered the cave from, and from there you can explore "backstage" areas of the other Oubliette chambers until you make your way to an unfamiliar room. The foes here should be a bit more complex, but still very manageable; the goal should be that you impress yourself by not dying in this fight. It does, however, instill in you an appreciation for the advantages offered by proper control of space and target prioritization, and it makes it clear that the best possible move if you're in a tight spot is "kill literally anything."

After this slightly steeper challenge, there's a very simple puzzle. This space feels a bit more "definite" from here on out; you enter a room with a valley that's spanned by a clockwork bridge which is currently unusable, and you have to turn interconnecting gearwheels to try and get each of the separate platforms that constitute the thing to be in the down position at the same time. From here, you go through a largeish room without any real enemies or puzzle elements or anything - just an atmospheric space that's supposed to get you relaxed, get your guard down; the intro's gone on long enough now that you're probably feeling like it's gotta be about over, and you did a harder fight and then opened a "door" back there, and this area feels different from the earlier ones, so there's probably, like, a cutscene or some shit?

End of this room, cross into the next: you're shut in a tight space with an endgame enemy. It wrecks your shit. You come to, washed ashore on the beach in the starting village; a set of cutscenes follows that gives you your first energy-consuming weapon and your first Taboo, then sets you loose on the world.

Mostly unrelated: Thinking it over, I'm gonna kill the minimap. I'm glad it's a horrible broken piece of shit, because that's prompted me to ask why I have a minimap. But in truth I really don't need it, and I think I can produce a stronger game without it. Navigating the world is a skill the player needs to develop, and for my part as the [LITERALLY EVERYTHING] I need to design a world that's navigable; that's, if complex, comprised of distinct, memorable spaces that intersect in ways that make intuitive sense - no identikit corridors; every room is distinct. The minimap would only serve as a crutch to let me get away with inferior world design, then; it's going.

Hammer devlog 24


Fixed up the shitty shading on those clouds a bit, cleaned up the scrolling code, added the animated FG elements to the title screen, and did a proper title menu.

I dunno what "Extras" is, but I figure I'll probably cram something there.

Exactly one of these options does anything right now, and I'm sure you can guess which one! The others just play a NO YOU CAN'T DO THAT sound effect.

The only way to actually go from title screen to gameplay, at the moment, is by leaving the title menu and hitting the primary fire button to trigger the separate debug start. But I can totally get the submenus in place now!

Although New Game would require actual content development and Continue would require both content and a save system... so, uh, Options is probably gonna be the only thing that works there for a while.

Sunday, June 5, 2016

Hammer devlog 23


Title screen with some ugly placeholder art.

I actually went ahead and did this because I was really dreading trying to get a smooth scrolling background working in Unity - expecting lots of pixel-warping and related jank.

In actuality: it was really easy and it worked fine the first time. Always nice when that happens, I guess?

I guess if this is in place, it might be wise to actually start on some front-end menus and shit, huh? I mean, at the very least, I really need to get the control config menu working now so I'm not changing a bunch of hardcoded values to test different control schemes, lol.

Hammer devlog 22

edit: If you look at the gif in this post, you might notice a bug with the reticle! That's already been fixed.
Took a bit of a break because I was wanting a bit of time to digest some design issues.

Result of this was a pretty massive rework of how dodging functions; feels a lot better now, and the code's all pretty to boot. But that's kinda hard to show off!

Tonight, though: much more interesting-looking things were done!


So what you see here is:

- the beginnings of the passive upgrade item system - there are actually two upgrades in play here. One of them is a passive thing that just gives you faster dodge rolls that can cover more ground. The other is the fireball dodge thing that you see here - instead of just dodging safely through things, you're engulfed in flame and fuck up anything that gets in your way.

That being said, that powerup really isn't balanced at all right now, lol. The basic rhythms of combat rely on the idea that you have to burn through your life to do real damage to things; the dodge fireball is an effective offensive option that doesn't consume any energy to use! And it can't be made to consume energy, because the attack is attached to your dodge. It does compromise your spacing, but when you're blasting around the screen in your copious i-frames and murdering shit by charging through like a meteor "compromises spacing" isn't really much of a trade-off. Probably, what I'm going to do is change the behavior of that upgrade so that you only burst into the full, damage-dealing fireball during a very small window within the dodge animation. Make it effective, but really squirrely, and high-risk/high-reward because if your spacing or your timing is off, you're probably gonna wind up in an enemy's hitbox right after your i-frames wear off - so it's less "why even bother with guns" and more a free source of damage during normal maneuvering that can also enable some really bold last-ditch plays if you're in a bad spot.

- gamepad support.

I do not have first-class Wiimote support, although thinking it over I don't think that was a joke, which means I am actually going to make that happen at some point.

This is just XInput gamepads!

I've got a neat new input manager set up, so now I can just refer to specific virtual buttons and let that decide whether I mean keyboard keys, gamepad buttons, or joystick axes.

The cursor is being controlled with the right stick here. It's kinda fucking terrible! Admittedly, the right stick will never really be adequate - this is a floating cursor game as opposed to a twin-stick game; being able to track foes completely independent of your movement is a pillar of the design; that won't and can't change - but even considering that, this could definitely feel a lot better, and it needs to.

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 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 " - 16 if anchor point >, else + 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.

Thursday, April 28, 2016

Hammer devlog 17

I did an event flag system this morning. No gif because it's an event flag system: just take my word for it, if you open the chest in the starting room and reload the scene it stays open. Excitement!

Anyway, I had one of those moments while I was doing it: I was lamenting how I couldn't very easily fit all my event flags into one enum, and I was thinking of a way to handle that! I had halfway designed this completely ludicrous solution which would require a custom inspector, and included both an int to cast to the necessary enum and a separate index value that we'd use to look up the enum type to cast to and the parameter in GameStateManager we needed to compare that to.

Basically, it would've been a giant clusterfuck that'd break horribly if you looked at it wrong.

But then I realized that, no, wait, why was I trying to do this?

So I just defined a generic FlagManager type and decided that things would take a reference to that, and I could then extend FlagManager to implement the abstract methods that'd actually do the heavy lifting. You don't need to do some overcomplicated quasi-dynamic type system to figure out which enum this flag should be cast to and what to compare it to - just stick the appropriate FlagManager on the thing, pick the flag from the dropdown, point the thing that needs to look at the flag to the FlagManager.

I spent more time designing and scrapping the ludicrously overcomplicated, look-how-clever-I-am solution to the problem of "event flags" than I did actually implementing the thing that's in place and works. And it's not even ugly or anything? There's a little bit of code repetition that's completely fucking worth it because it lets me Just Say No to dynamic typing, but it's eminently readable in the way that the "smarter" solution I came up with in the first place definitely would not have been.

I do hope the compiler basically inlines the FlagManager object out of existence, though, lol. Since an enum isn't a "real" type - it's just a friendly face for the integral type behind it - it'd be really embarrassing if the result of this design was that I wound up repeating the same tiny section of machine code 20 times and having different things using different repetitions of that code to do their checks for no apparent reason.


Event flags being a thing means keys can be a thing, so keys are now a thing.

Also: man, I really need to build a fight that's not complete shit sometime soon. Well past the point where that room with the ghosts is useful. 


WIP minimap and a subregion name popup thing. Subregions are different "areas" within the same scene, so of course the minimap doesn't try to fill cells that exist but aren't part of the current subregion.

Minimap only tracks rooms right now; it doesn't include any support for identifying which rooms you've visited, and it doesn't display connections between map cells. But it does populate automatically based entirely on the layout of rooms in the level and behave nicely with big rooms, so that's cool. Tracking visited rooms is easy enough and I just haven't bothered to implement it yet, but I'm not entirely sure how I want to handle connections. I definitely want this to display that information - but the problem is that (as you can see here!) internally, there's no such thing as a room-to-room connection. Every room is connected to its adjacent rooms; some of them just have collision in the way. I don't want anything as clumsy as a separate array stored with the RoomController that just tracks where to draw connections and whether they're room-to-room or represent fused big room cells, but I might have to do that, really. I could generate connections at runtime from big room cells, but there's nothing reasonably performant I can think of to go over the entire level and immediately check which cells are accessible from which which doesn't leave room for error. And I want to be able to do this within the space of one frame, so - probably am gonna have to suck it up and have rooms specify their connections manually?

Obviously: I really need to optimize the code that handles player world coords updating on big maps. That framerate is pretty gross considering there's nothing else on the map.

Monday, April 25, 2016

Hammer devlog 16


Weapon pickups. Progression!

At the end of this gif, you can also clearly see the new energy regain animation - which is a "fake bullet" that enemies "fire" on death that tracks the player with ludicrous homing properties and heals you on contact whether you're dodging or not. This is a lot more intuitive and nicer-feeling, (Even if you can't really see the graphic against the floor that easily right now...)

Which brings us to the next point: homing bullets. They're in and I've got a neat little setup that gives them a lot of granularity - anything from ludicrous Macross missiles that do hairpin turns in the air to chase their prey to a more subtle aim-assist. I just don't have any visual way to show that off apart from the health whatsit homing right now, sorry!

Overworld textboxes!

With the ability to slice up a block of text of arbitrary length into smaller blocks that can be printed in sequence, and an awareness of where the player is on the screen such that they'll try not to cover that position.

Also, the item pickups now have a textbox and a fanfare and a pose and everything. Which feels a hell of a lot better than "walk into gun to get gun."

Thursday, April 21, 2016

Hammer devlog 15

This isn't action either.


Implemented a tile priority map system so bullets would behave in a more logical, psuedo-3D manner on big maps with a lot of steps and cliffs and whatnot, like this one. Basically: before a bullet even does its collision checks for the frame, it looks at where it is relative to the priority bounding boxes. If it intersects a lower-priority bounding box, it keeps moving even if there's a scenery collider there, because that collision is "under" it; if it intersects a higher-priority bounding box, it assumes that it hit something whether there's collision there or not.

This is a really silly thing to do in Unity, because Unity is a 3D engine and it could just do the proper 3D collision logic even if it was displaying a bunch of sprites on an orthographic camera, but it's necessary for the aesthetic and gamefeel I'm going for. I don't want to handle this the "right" way, per se - I'm trying to create the illusion of a game running on a much simpler piece of hardware than any this will ever run on. I want bullets with piercing properties to climb "up" walls and hit things on top of them; that sort of thing - at once obviously nonsensical as a representation of physical systems and intuitively correct as the behavior of a fairly primitive 2D environment that fakes 3D logic only to the extent that the GBZ80 and 8 kilobytes of RAM will let it get away with that.

Sometimes, you want to make sure that the wires are visible.

I also made the Demon's Spine's behavior a lot less janky and unpleasant. You can get a feel for what that's good for here.

Also also: your energy regenerates in checkpoint rooms, which is just a quality-of-life thing that lets you ensure you do have enough energy to get around, even if you don't have a firefight to get into.

Wednesday, April 20, 2016

Hammer devlog 14


This is a menu. Weapon select menu is in. It does all appropriate menu things and complies with all standards and regulations. It looks at the weapons you have unlocked, puts a revolving selection of sprites on screen, and tells the weapon manager that your equipped weapon is whatever is in the center slot here.

It also puts some text on the bottom of the screen to tell you what's happening.

That background is kinda hideous, I know, but I can change it!

To be honest, I'm not too stoked about this menu in general; I can see it being a bit of a pain to scroll through a decent-sized list of weapons. But it does what it needs to and conveys the information it needs to, so I can work with this for now, and drop in something nicer down the line if I really want.

Fun fact: there's not actually any of the nice Unity UI stuff happening here, because having Unity handle this in a resolution-agnostic manner would completely break my aesthetic! This is just a bunch of ordinary non-UI sprites doing ordinary non-UI sprite things. I'm already twitching a little bit over the fact that I can't completely eliminate font smoothing and it's introducing intermediate shades of gray that are outside of the 2bpp grayscale palette I'm working with. I'm not entirely certain that I won't wind up rolling my own bitmap font solution at some point.

Saturday, April 9, 2016

Hammer devlog 13

Trying to keep providing updates at a decent clip, even if I don't feel too great about the content in question! But it works, which is what matters at this stage.


So, this is really shitty - it's not a dynamic fight at all, and the boss should really move to track you with its standard shots - but it's recognizably a boss fight with its own mechanics. Dude sits still and shits bullets until he decides to try to run you down, then covers his ass during the vulnerable period after he finishes those shadow charges by summoning that crazy arrow-rain attack. You need to look at the layout of the projectiles and your screen position quickly to find a safe firing position during that brief window of opportunity.

There are these eye-things on the floor that'll hurt you if you run into them, and they're making the otherwise-optimal corner positions a whole lot less desirable. You can shoot the eyes to destroy them, and they even count as enemies, so they'll refill your energy - but these are the only energy refills in a very dangerous fight, meaning you have to be smart about when to pick them off.

Not shown: if you pick all four eyes off, the boss starts using the horizontal and vertical arrow rains simultaneously, instead of picking a pattern at random. Don't get greedy!

This is, as mentioned, a shitty boss. This is Bed of Chaos levels of shitty boss!

But it's a boss. Which means I can build the furniture of a boss fight around it. The kind of detailed, in-depth design that'd be required to build a good boss fight isn't happening right now because the mechanical fundamentals aren't solid enough yet - anything I do at this stage is a shitty boss, so this is as good as any.

So my immediate priority is getting things in place for some sort of progression now.

The progression in question is: a key should be dropped in the Fuckton of Ghosts Room, which is required to enter the Shitty Boss Room. Beating the Shitty Boss will result in dropping a third weapon.

Some sort of placeholder inventory menu will allow you to equip the third weapon, and that'll resolve an otherwise-intractable obstacle in the snowy room.

Monday, April 4, 2016

Hammer devlog 12


Dying'll now respawn you at the last checkpoint you activated and reset all the enemies or other volatile objects in the area.

There's an animation bug you can see with one of the enemies respawning here, which I need to track down.

Also, since this test map is fucking nonsense, you respawn on the wrong side of the false wall and get stuck in the collision. It goes without saying that you'd want to use a save flag for a false wall that could be accessed from the wrong side, instead of just resetting it whenever the level is refreshed.

Saturday, April 2, 2016

Hammer devlog 11

Before we can talk about death, and how that's handled, and what that means... I guess we've really gotta take a deeper look at the overall structure of the game, huh? Until now, we've been focused squarely on the moment-to-moment things, but that's only half the story, really.

Okay, so: we're definitely strongly influenced by 2D Zelda games - particularly the Game Boy titles - and the combination of an open, exploratory world structure, action/puzzle dungeon crawls, and light RPG elements. However, we can't just do that. The moment-to-moment demands of a Zelda game are very manageable; it can ask you to perform through the length of an entire dungeon, without a break, and that's fine, because there are relatively few moments when you're really put into a do-or-die position in a given Zelda dungeon. By contrast: every combat encounter here is do or die. If you don't take the enemies seriously, even trash mobs can proceed to kill you with brutal efficiency. And, from another angle: the place where Zelda does have its difficulty is basically irrelevant for Hammer. Our systems don't just make resource conservation irrelevant; they make it impossible. Fire away and keep firing.

Well, let's think some more about what we do want with the Zelda formula: First thing: inventory-driven exploration a la lite-Metroidvania. The various guns you acquire open up new paths and passages. I mentioned a grappling gun as an example, earlier - but it's not just that. A flamethrower can melt the ice blocking off a cavern entrance; a grenade launcher can just blow up cracked rock walls; a flying drone can adjust its path based on your cursor as it moves, following paths no conventional projectile could. Each gun you acquire opens up new possibilities, and not just in combat - but as a tool for moving around and solving puzzles. And the problems these weapons solve can almost always be solved in multiple ways, creating a very satisfying effect where you can sequence break freely if you solve puzzles with the "wrong" weapons. For example - think of the shotgun that's implemented right now. It's something that presents itself as a very conventional, mostly-just-combat sort of tool - but you might be able to abuse its spread firing pattern, and that's encouraged. You might have a scenario where you're intended to position mirrors and prisms to guide a laser beam through a maze so it can strike two switches simultaneously, but if you line yourself up just right and fire the shotgun, it does the same thing without all the hassle. That's good. The starting gun is the only one that should be mandatory. Everything else is just a potential means of solving problems, and the order in which you tackle different sections of the world and how difficult you find them will vary with the tools you happen to have available to you. Adaptability is the name of the game, both on the micro level - within combat, recognizing where you need to be at any given moment and being there, reading the rhythms of battle and feeling what to do at any given time - and on the macro level. You're rewarded for seeking out new tools and thinking of unconventional applications for the ones you have. The "everything is a gun" paradigm amplifies this - exploration and puzzle solving require you to make heavy use of incidental functionality of tools designed for combat first and foremost. It gets you in the right mindset.

What we don't need here: the hard division between "overworld" and "dungeon" spaces. Exploration isn't something that happens in a separate space to the more complex puzzles and combat scenarios - you're continually encouraged to keep your eyes peeled and be willing to change your plans. The "dungeon" spaces wrap around on themselves, intertwining with each other in a very Metroid-y way, and the "overworld" is scattered throughout the map to provide a more natural rhythm for the brief, intense nature of our firefights. Brief "sprints" - frenetic ballets with bullets and mind-bending environmental puzzles - are more naturally punctuated with open, atmospheric and exploratory spaces at a more regular rate than can be provided by adhering rigidly to Zelda's formula.

It's worth considering what Zelda's dungeons do for the overworld exploration, though! They take a situation where the player is just sort of dumped on a sprawling map and give you direction. You have a clear set of goals and at least a rough idea of where you need to be heading off to accomplish them, and that's something we want to preserve.

So, at a broad structural level: Metroidvania-style world plan, heavily interconnected, and mixing short groups of intense, challenge-focused chambers with larger areas that are allowed to be quieter, more restful, focused primarily on pure exploration. Each "main" area is home to one of the game's bosses, and your goal is always explicitly to kill each of these bosses in order to advance to the endgame - but you can choose which order to tackle them in, and you'll generally have to partially explore at least a few different regions before you come face to face with any of the bosses. They exist at the farthest reaches of the world, basically - encouraging the player to explore because "pick a direction, keep walking until you see a president, shoot the president" is a sound gameplan. Guns are distributed throughout the world, some hidden away in secret chambers, others at the end of difficult gauntlets, and some even simply on store shelves - and each of these makes the player stronger by increasing the number of strategies available to them.

Getting around a world like this could be difficult, tedious if done poorly, and the nature of how bosses are distributed requires you to explicitly head for the areas furthest from anything else. So it probably makes sense for fast travel to be a thing, and more specifically, for fast travel to be unlocked for an area by defeating its main boss. Defeat the boss and the nodes throughout become active as fast travel points - you've slain the area's master; you are the area's new master. Fast travel isn't exploitable, since reaching the boss requires you to prove your mettle against the region's themes and gimmicks; getting the right to zip around freely comes as the culmination of a gradual process of getting control over the initially-hostile elements of the region and putting them to work for you, at the moment when the area in question ceases to be somewhere where you have an end-goal and instead becomes a place to move through en route to other destinations and comb over for missed secrets.

These fast travel points are a natural checkpoint system. Highlighting them on the map screen provides a clear set of intermediary goals for the player as they make their way around the world. Travel means combat, and combat is inherently dangerous - intense, stylish, rewarding, but having high execution demands and being very punishing if you can't keep up on either a tactical or a reaction level - so finding these nodes is a key part of constructive safe pathways through the world, whether your destination is the next boss or just that funny-looking rock you think might have a cool gun under it. When you die, you respawn at the last one of these checkpoints you visited. And since these checkpoints are very visible, very obvious, you know exactly where and when you last visited one - so when you wander into a combat scenario, you have to decide whether to push through or to back off and keep exploring. When you're far afield, fighting isn't always the best option - especially if your current tools aren't really suitable for the fight in question.

The only progress loss for death, though, is being returned to the last checkpoint. You don't lose any resources or equipment. You even keep any map cells you've filled in. You just wake up in the last checkpoint room and continue on. You should never feel like your time is being wasted - even if you walk into a room and promptly get your ass handed to you, you're respawned relatively close, and you now know "maybe I shouldn't go in there yet." Easing the metagame around death enables me to get as mean as I want with a clean conscience.

Hammer devlog 10

I think this is an important milestone: this is finally looking somewhat like a video game.

I did another WebGL build.

Click on this and it'll take fucking forever to load, but when it's done, it'll promptly dump you into a firefight. You will probably die. When you die, you'll have to reload the page again because dying is just a softlock.

Move with WASD or arrow keys, double-tap a direction to dodge in it, aim with the cursor, fire the shitty weenie gun with the left mouse button, fire the slow fucking shotgun with the right if you have enough energy remaining. Try to kill all five ghosts. You'll need to put that dodge to work, though, and make good use of the blocks in the corners for cover.

It's still really rough, obviously! But this is the first time since I started this project that I feel like this first proof-of-concept firefight basically works. It's tough, but fair, at least within the bounds of something this early. (Obviously: it's not "fair" by release standards. You start in an exposed position, and they're random enough that if they all do the right thing right when the map loads you're completely fucked.) Reflexes alone won't win it for you, and neither will executing the right tactics poorly - you need situational awareness and adaptability, the ability to quickly form a workable gameplan and then change that as the situation around you changes.

If you kill all five ghosts, you're allowed out of the room. You can then wander around some test rooms, or even take a WIP warp event on one of the staircases to arrive in a room with no collision with the camera controller in an inconsistent state that will basically guarantee anything you do ends in soft and/or hard locks. Excitement!

A design snarl that occurs to me at this time: at a structural level, this is very Zelda, but the moment-to-moment gameplay is much more demanding than Zelda, with death being a very real possibility at any given time. Some time later today I'm gonna hash out how I want to handle death in this thread, because if I handle that "like Zelda" it'll be tedious and unfun. I can't handle death like an arcade shmup, either, of course, because this is a hell of a lot less linear and controlled. So that should be a fun problem to work out!

ALSO: WebGL really isn't my target platform. So, a quick warning - make sure you keep the cursor on the display. If you right click the background, you open a context menu instead of firing, and you're almost certainly dead.

Friday, April 1, 2016

Hammer devlog 09


On display here: energy bar and big rooms.

Big rooms were actually way more of a pain in the ass than I was anticipating, but whatever: they're in and they work. The scrolling could maybe be a little cleaner, but y'know, whatever. If the most readily apparent issue is purely cosmetic, that's a good day's work in my book.

I also went ahead and beat the tilemap editor into actually working. That's not visible here, but rest assured that it was an integral part of making the copy-pasted Big Room there happen.

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?


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


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!


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.