So, my LD20 entry was my return to game-making after a considerable hiatus. I didn’t do much in the way of exploring new technology or tools, opting instead to stick with what I knew and focus on turning in a solid result. What went well, and lessons learned:

Going over a collection of design ideas, figuring out which one I was tending to gravitate toward, and then getting some sleep to let my brain digest worked amazingly well. When I woke up, the idea was much “cleaner” in my head – scraps of notions that weren’t going anywhere had been pruned away, and the core notion of “what does this game feel like” was a lot clearer as a result.

I spent 3 or 4 hours making the movement controls feel awesome, before coding any other aspect of the game. I mean, I literally just sat there with a black circle hopping around on a black line, tweaking variables, augmenting equations, until I was having fun making that dot move around. Taking a principle I’ve been aware of in game design, and putting it into dedicated and deliberate practice, really paid off. If you want a game to be truly, viscerally satisfying, then each building block that goes into the gameplay should be satisfying on its own. I recall a story that in the early development of Super Mario 64, the game started with just the physics – an untextured cube running around an empty room. And Miyamoto wouldn’t let development progress further until that was fun. That’s another benefit to the Dragondot franchise, I think – the minimalist graphics make me focus on movement to convey things instead, and movement can be ‘felt’ more viscerally by the player than animation on its own. There’s the special attack with the knife weapon, for example, which is intended to be an acrobatic backflip sort of thing. And I think I managed to convey that with the way the attack is done, which is made up of basically three numbers. Three numbers, versus who knows how many hours it’d take for me to make a pixely character animation look decent doing the same thing.

On a related note, I discovered once again that you should never feel guilty about seizing the opportunity to make something more awesome when an opportunity inspires you. One of the core concepts of the game is picking up a fallen enemy’s weapon, and I wanted to make that moment feel cool. So I spent a good several hours making a sweet sound and particle effect to announce the occasion, even though at that point I’d done absolutely no code for enemies or combat mechanics. In terms of productivity in a ‘crunch’ situation like Ludum Dare, passion beats the pants off of diligence. I procrastinated on the combat mechanics for quite some time, because when I started working on it, my immediate response was “this is a cool design, but it’s gonna be really unpleasant and boring to code. I’ll slog through it later.” So instead I worked on adding awesome in other areas. Particle effects are always one of my favorite things to do, so I did some of that. Then later, I came back and looked at the elaborate weapon code I’d designed, and went – you know what? I can make this way less featureful, do some fearlessly kludgey code, and still do 80% of the cool stuff that this game actually wants. Ranged attacks, attacks at different angles, attacks that vary based on your current movement – all that was in the initial design concept, got cut, and the core of the game is healthier for it.

I was a bit torn as to whether I wanted to have lengthy levels you walked through, or a series of discrete screens. I went with the latter, and in retrospect I’m certain that was absolutely the right choice, at least for a 48-hour development cycle. Having things compartmentalized like that, much like the original Dragondot, let me develop and test monsters modularly. I could do 3 rooms, variations on a theme, and then say “okay, they’ve learned their way around these critters, time to throw a new one into the mix”, and just go code that. And if there needs to be a new variable for a monster or weapon to hook into, I just toss it into the base class, set a sensible default, and then it’s an easy new dial to twiddle for future design. For instance, the club makes you move slower – I added a ‘weapon weight’ variable and a multiplication in the appropriate movement functions, set the default to one, and then increased it for the club. As it turns out, that’s the only weapon that has a higher weight, but the design space was open for more after that point.

There are a few areas that I wish I’d had more time to dedicate to, though I’m happy considering the game “done” at this point and don’t feel the need to polish it up for a Jam version like I did last LD. In particular, the worg fang works great for a boss weapon, but the same thing that makes the boss difficult but beatable makes it kind of a lame weapon for the player – you’re wide open after attacking, and the speed tradeoff just isn’t worth it. In retrospect, I probably could have given it a more aggressive primary combo attack. The pacing between rooms isn’t as well-tuned as I’d like it to be – while I made sure that individual rooms were beatable, the spacing of hard and easy rooms is a bit haphazard. Room 7 is basically the ‘midboss’ of the game, and can be rapidly lethal unless you’ve mastered dodging the worg’s lunge and turning enemy attacks against each other.

That’s another thing about difficulty, in a development setting like this – I’m doing all the coding and playtesting, so I’ll be getting practice against a boss as I tune its AI and such. So when I get an enemy into a state that I find “tough, but satisfyingly beatable once you figure out the trick to it”, it might be a bit brutal when you’re just coming into it fresh. I woke up this morning and tried to do a “fresh” playthrough of the game, and kept dying in room 7 over and over. So yeah, it’s not just you.

The AI in this game is kind of a happy accident. It’s stupidly, stupidly simplistic, and I think it’s mostly the fact that moving around is so much fun, and that enemies show up in groups, that keeps the player distracted from it. Basically, they’ve got some really simple rules tied to virtual button-presses; if the player is left of me, hold down the left key, if they’re closer than a certain distance mash the attack button. That’s pretty much all there is to it, for most enemies. But it works. The ninja enemies seem sophisticated, jumping over your attacks and leaping to intercept you in the air… If you don’t want the magic of their AI spoiled, don’t look at the code, that’s all I’ll say. Actually, don’t look at the code anyway – as usual for my time-crunched style, it’s uncommented, hacky, and horrendous. There’s four or five important-sounding vestigial classes, like Attack and Melee and Weapon, that don’t actually get used anywhere. I did put one easter egg in the code itself, in the bit that handles the extra “ending” of the game. Fun with variable naming and whitespace abuse.

Anyway, I appreciate you reading through all of this, so I’ll let you in on a secret – I once again forgot to remove the cheatcodes I put in when testing the game. Oops, silly me.