Deus Verve Makes Games

Giving upgrades individual costs was simple—I already had a function that sets up all the variables for each upgrade and then passes them along to the menu for display, so I just added in their cost as one of those variables. I haven’t actually given any of them an individual price, just a default one, but the code works, so I can do that easily enough now.

Rerolls are done, quick and dirty. I need more buttons on the upgrade shop menu screen, but given how busy I’ve been the past few weeks I prioritized the functional code with a placeholder keyboard command over having a GUI button. The tricky part was deleting all the of the existing upgrade choices so the new ones could go up. It wouldn’t be great if you bought and upgrade and the previous one was there beneath it—especially with the rarity particle effects. On the bright side, seeing a common upgrade with the Rare effect behind it told me whether or not it was working.

Rerolling itself on a design level is pretty simple. I start at a flat cost which doubles every time you reroll. I may increase that starting cost each time you clear a level but that’s a decision that will need playtesting, so I can worry about it later. What matters is that you can now, technically, buy a large number of upgrades by buying out the shop, rerolling to replace what you bought, and repeating until you’re out of cash. Since the design goal of this game was to give you some ridiculous bullet patterns, this is actually fantastic for me. Remember: do your GDDs so you think of this sooner. I am a bad example.

-DeusVerve

DevLogs like these are brought to you by Patron(s) like Haelerin!

Yeah stores are really easy. Throw in a “>= money” and you can do whatever you want. I did forget to show in that GIF that clicking an upgrade doesn’t do anything if you can’t afford it (except turn it green to show it was clicked on), but it’s fully functional. All that’s left is to give each upgrade its own cost as a variable that I can check instead of making all upgrades cost the same amount. And what I’ve noticed is that you tend to get somewhere between 20 to 40 coins per room. I’ll do some runs and see how much money I’m averaging per floor to give myself a framework of what should cost what, but that’s where the 75 number from that GIF came from. I knew that I’d be pretty likely to have enough for multiple upgrades but not for all of them.

-DeusVerve

DevLogs like these are brought to you by Patron(s) like Haelerin!

This game needs more push and pull. Risk vs Reward. And, luckily, there’s a fairly easy way to do that which I’ve previous discussed: money. If enemies drop money on death, and upgrades cost money, there is incentive to hunt down enemies for their money, potentially taking damage in the process. Also this means that the player can get more than one upgrade per upgrade screen, leaning into the power fantasy aspect of going wild with all the upgrades like a bullet hell boss.

Normally this is the kind of decision that should be made earlier in a game’s development, possibly aided by using some kind of document to think through your design, but alas.

As another benefit, I will eventually be changing my dungoen generation code slightly. Right now I hard coded the player to be in the bottom right and the exit in the top left, but I want to change that up to encourage more exploration. Enemies rewarding you for it by exploding into coin pinatas will do that job nicely.

These are the thoughts I had this week while working on drone sprites, which are, I think, some of the last placeholders in the game that don’t need me to figure out the stupid camera thing.

-DeusVerve

DevLogs like these are brought to you by Patron(s) like Haelerin!

I’m still trying to decide what sprites to make for the drones. I only have so many themed items to choose from, and sure, I could make multiple variations of one kind of sprite, but that feels both lazy and like it would be potentially confusing to players who mistake one sprite for another in the heat of the moment. Plus, I have to figure out what causes my screen tearing and fix that. My proverbial money is on some kind of screen refresh rate desync.

In the meantime, I finally fixed a minor issue that I’ve had for a long time: the enemy spawn-in timing. Because I’m creating both the particle effect and the enemy at the same time, the enemy would be visible before I want them to be, which basically ruins the summon animation. Furthermore, enemies immediately begin to move upon summon, walking out of the animation. If I had thought ahead about how I wanted my state machines to function, this would be an easy fix, and I suppose I could still implement that more elegant state machine, but for now, I went with something quick and easy. I set them to an unused state by default, meaning that the enemy isn’t actually doing anything—including taking damage—with a timer set to activate them at the right point within the summon animation. By making them invisible until this occurs, the summon animation now looks exactly as I wanted it to.

Well, except for the bomb guys. I made them faster so they move out of the animation a littler sooner. It’s nothing I can’t fix.

(Note: There should be a GIF here but I couldn't get the damn thing under Tumblr's 10MB restriction, which is especially annoying because it doesn't feel like it's a GIF that should be 20MB. The Patreon article has the GIF and is free)

-DeusVerve

DevLogs like these are brought to you by Patron(s) like Haelerin!

There’s a technique called nine-slicing. I almost feel silly for forgetting about it, but to be fair I don’t use it often. The basic idea is that I can take a sprite and divide it into nine sections, which will scale differently. The corners never change, the borders stretch along their respective axes, and the center then stretches to fit. It’s extremely useful for making UI boxes and windows of various sizes. I used it for the barrier.

As you can see, the single square sprite animation becomes two different rectangles without any difficulty.

The actual animation itself was pretty straightforward to make. A bit of gradient trickery combined with transparency to make it fade in and out ever so slightly, while using a similar trick on an expanding square shape. Making sure that the square expanded the correct amount each frame was a little tedious, but not exactly hard.

-DeusVerve

DevLogs like these are brought to you by Patron(s) like Haelerin!