Powerups



This week was dedicated to working on powerups for the player's various abilities. Some of them were a cinch to implement, others were deceptively complicated, and all of them are OP. Here's a video showing off most of them:



So in order of implementation, we have:

LASER

Each pickup divides the time between shots in half. So the first one doubles your fire rate, and you
get diminishing returns from then on. Beyond the third or fourth pickup, the difference is barely noticeable, and the framerate provides a hard limit to how fast you can fire. But I don't nerf the damage per shot, so this will pretty much melt anything in range.

This was as easy as changing a single timer on the player object. The time consuming part was creating the powerup itself, and reworking the onscreen text to be able to display multiple notifications at a time without overlapping.

In general, I like to lean away from simple stat upgrades that don't alter mechanics; but in this case, doubling the fire rate makes a huge difference to how the game is played. Mostly because the laser no longer feels like a peashooter.

The powerups are all the same shape right now but are color-coded. But because the objects are so small, getting colors that are recognizably different from each other, and still look good, isn't easy for such a large number of objects. 

CANNON

Shots turn explosive. Changes a global setting on pickup which causes every bullet to create an explosion when destroyed. This already kills anything in one hit, so additional pickups just explode in a shower of upgraded bullets. This one was so easy to make. This might(?) be the least OP of all the upgrades, until you combine it with the teleport powerup....

RAILGUN

Turns the weapon from a single shot to a constant beam. Oh man, I created so many bugs getting this to work the way I wanted. Just adding it wasn't difficult, but so many small tweaks required something else to change, and every time I tested it I wanted to tweak something or add another effect. Here's an early video of it working:



The code relies a lot on checking what sprite the player is using, which is something a lot of the other code already does. At the time, this seemed simpler than introducing a lot of new variables, but it produces weird bugs once you get other bits of code that also change the sprite. So a side effect of getting this to play nice with everything else is that the player can no longer teleport or use the shield while another animation is playing. It makes sense, but it also makes the game more difficult, because you can't interrupt one ability with another.

Anyway, this thing is hilariously overpowered. Just sweep it across the screen and watch everything die. There are no enemies that demand this amount of firepower yet. And you are very likely to kill yourself trying to use it. It feels designed to make the player lose control and go mad with power, it prevents you from using your shield, and the recoil is a great way to die quickly. [Unless you cheat by giving yourself 20,000 health, as I did for the recordings.] Since the recording, I've tweaked it so that as long as the barrel hasn't cooled down, the weapon can be fired instantly, which encourages you to keep firing, which means more recoil. It also overheats and causes you to explode, which will be a fun thing for players to figure out on their own.

TELEPORT

I had a couple of different ideas for what this should do, and this wasn't one of them. But I wanted to see what would happen if teleporting just created copies of the player object. That was amusing and disastrous, but I'm kind of surprised it didn't just crash immediately.



Anyway, that's the idea I ended up running with, but the final version is a lot less chaotic. Now, it creates a separate object type with simplified code, that takes most of its cues from the player object, instead of directly from the inputs. You can have up to 4 copies of yourself with enough powerups, and enemies will target the copies. They get recreated every time the player teleports. It doesn't seem that powerful, until you end up with 4 of them that all have upgraded fire rates.

My favorite thing about this one is that beyond the 4th upgrade, picking up a powerup will just spawn an NPC version of the player, which flies off to do its own thing. You can't hail them yet, but that's on my list of things to add. I doubt many players would even last long enough to see this, but it amuses me.



SHIELD

Haven't started on this one yet, and I'm still trying to decide what it should be. Leaning toward a charge effect that releases a nova when the shield is let down. This one's also going to be a pain to code, I think, plus a couple of new animations from scratch.

So I wrote the above paragraph and then immediately started working on the shield. Went with something simpler and closer to its original functionality. Aside from looking more powerful, the upgraded shield now lets you pass through objects instead of bouncing and causes a lot more damage per step of collision, which usually destroys anything you run into. As with the other powerups, any copies of yourself from teleporter upgrades also have an upgraded shield, with absurd results. I debated whether to also allow the player to control their movement with the shield up, but that would be the equivalent of just making them invincible permanently (or as long as they felt like holding the shift key).



Every powerup has a particular, thematically relevant behavior if picked up when you already have it.  Not sure what the shield item should do, though, so for the moment it just spawns NPC players exactly like the teleport pickup. This is partly because I'm too lazy to make something new, and partly because I really like that behavior, and it otherwise doesn't happen very often.

MISSILES

I haven't even added this weapon yet, but when I do, the powerup will be similar to a MIRV. And that's *probably* the last weapon I should add. Things are starting to get complicated, and I'm running out of easily accessible keybinds.

One of the project goals is still not having a HUD of any kind, so things need to be simple enough to memorize, and adding a weapon selector is out of the question. I think the powerups are a good way to add some variation to that simplicity, plus the usual risk/reward factor that they add. If I go beyond the prototype stage, they can also serve as a per level goal, since they won't be permanent upgrades (unlike the weapons themselves).


NEXT UP

Yeah, I have no idea. Still have more enemy designs to add. The first part of this past week really went to cleaning some backend things up so I could make the new stuff work. Also on my list is adding some atmospheric particle effects like I had in my original prototype. Which will require me to get reacquainted with that system. I also decided to try increasing the room size this week, to feel more open. Even at only 1.5 times larger, it has a huge effect on the density of objects, and I had to rework the spawn code so that objects could spawn inside the room (but out of the player's view). Most of them still don't do that yet, but at least I know how to make it work. I like having a larger area to move around in, but I'm starting to worry about performance. The game has a LOT of objects moving around, and most of them can collide with each other, and I'm pretty sure the bounce function is slow. Not to mention a lot of the other effects I use, like the fire, work by creating new objects every single step, which all have to run their own code. [I could use the engine's dedicated particle system for these effects too, but I found the results much uglier than my hacky approach.]

I don't REALLY need to have a larger playable space. This is an arcade game based on a design that confined itself to a single screen, which gets more engaging with higher object density. On the other hand, being able to move around freely does add an interesting "I-wonder-what's-over-there" dynamic, so it's a balancing act between those two aspects. But for this particular project, if I have to sacrifice one for the other, that sense of discovery is less important than the overall feel of moment-to-moment play.

Eventually, I'm going to have to decide what to do about the background. There is no parallax on the starfield right now, which is fine because it's just white dots, and serves to indicate movement. If I ever want a more detailed background, though, it's going to look very weird without parallax, which probably means I will need multiple layers. But the nice thing about the current system is that everything about the layout of what's onscreen is generated, because they're all interactable objects. If I want to have a detailed background that retains that dynamism, that's going to be a lot of work. It's also likely to hurt the readability of the objects in the foreground, so it might end up being best to stick with something simple and uniform for now.

I guess once I finish off the powerups, I should go back and add a new 'enemy' to the rebel faction, so they each have two. That's going to be a little guy on a hoverbike who tosses molotov cocktails. Though I have serious doubts about whether I can make something like that visually identifiable with such a small sprite. That is going to be a continuous issue on this project, I think. If I make interior areas later on, I have to make sure to render objects at a much larger resolution. On the other hand, the tiny objects help disguise my terrible art.


FUTURE PLANS

I think of this project in two stages: the prototype that I'm making now, and the eventual finished game. Essentially, the prototype IS the game, or the parts of it that make up the defining mechanics. The 'finished' version is the metagame, campaign, and story elements that sit on top of that; plus the ways in which those things tie into the main game. In other words, it's the introduction of a slower-burning, more expansive gameplay loop separate from the core mechanics but feeding back into it. It's also the part that I should not be working on until this prototype feels like a complete package in its own right. So aside from tweaks, bug-fixes, and maybe a couple of visual enhancements, that means adding enough mechanical variety to keep things engaging. Mostly through new enemy types. When that process will be finished, I'm not sure. It's tempting to just keep on eternally adding new types of stuff with their own behaviors, because this miniature sandbox approach means that any addition feels like an expansion of the possibility space.

The other major change that should help keep things interesting for this limited prototype will be an event system, that controls various spawn rates. At the moment, each object type works on a timer. Even if I randomize those, the result is going to be a fairly consistent amount of chaos, that will probably feel like something is always happening, but nothing is ever changing. So instead of just randomizing everything, having some sort of scripted events that can trigger to overturn the default ecosystem should make a session feel much more dynamic. That will probably be tied into a scoring system as well. I was against adding a visible score for a long time, because it's just not one of my interests. But some progress metric will probably get added to the pause screen at some point, which will also be used behind the scenes to control the stuff mentioned above. 

In any case, at least feeling like I have some parity with my first prototype would be nice. Just off the top of my head, I can think of at least five enemy types that were in that that aren't in this, some of which were more interesting than anything I've done here. Unfortunately, a lot of those designs don't work in this new context, because they relied on the entire room being on the screen at once. In some cases, I can tweak the design a bit, in most cases I'll need to think up something new.

Now trying to take a day off from working on this, if I can....















Comments

  1. The physical-objects-in-the-world versus performance problem is classic. One thing to think about might be to turn off physics for objects outside of the screen, or some range outside of the screen (i.e. another "screen away" in all directions). It's something I've been trying to account for from the ground-up in my engine, but the reality is I'm so far away from it being a real problem that I'll probably have to change a lot when the time comes.

    ReplyDelete
    Replies
    1. Yeah, that's something I've avoided trying to figure out so far, but I might need to address it at some point if I want to be able to have larger playable areas. My hope is that it won't be an issue for this project, since the scale is fairly limited.

      Delete

Post a Comment