A little while back I took a long, hard look at the game, and decided that it was too simple. Now, there are a lot of reasons to keep the game as simple as possible, mainly with respect to production, but I couldn’t deny that I just wasn’t having much fun playing my own game. Yes, it’s supposed to be a silly game, but ultimately, it has to also be good. That’s why I previously added a bunch of different weapons, and recently decided to add a few more features.
Before I get into that, I had another problem to solve. The teleporter I had created wasn’t working properly, not in terms of programming, but design. The most obvious issue was that you could only throw the teleport object within a small range around the player. This is because the camera is not zoomed out enough to allow the player to see the entire arena, and the teleporter goes wherever the mouse is pointed.
It’s true that you don’t have to teleport immediately. For example, you could throw the teleport stick into a corner, walk all the way to the opposite corner, then activate it to teleport the maximum distance in the arena. However, that takes time, and destroys a lot of the utility that the teleporter is supposed to provide.
White dots represent path, yellow dots represent “bounces.”
To solve this problem I figured I’d give the teleportation object a few “bounces.” The idea is that the player throws it to a certain spot, but then it bounces a few more times before coming to a rest. Because this makes aiming a bit tricky, the teleport was changed to charge up over a second, and the UI replaced the standard UI so the player knows where they’re throwing the teleport stick. You can see that in the screenshots above and below. Above is a short throw, below is a distant throw.
Unfortunately, this doesn’t work for a number of reasons. First of all, if the player can throw it from one side of the arena to the other, the camera should probably zoom out and let them see the whole area, because no possible UI can allow the player to throw precisely when they can’t see the eventual landing spot. Alternatively, it’s not clear that the UI/charging is necessary. After a while, the player will get used to the trajectory of the teleporter. That’s how most frag grenades work in games. Most games don’t need any special UI/windup to show this.
Not the best screencap, but you get the point.
As for the charge/windup itself, I also found that irritating. The longer the charge, the worse the teleport becomes. This is because you can’t do anything else while you’re winding up to throw, so the opportunity cost becomes greater. However, a short charge makes it impractical to aim the teleporter. In practice, the player needs at least a second to aim properly. Couple this with the fact that you still can’t aim properly when throwing off screen, and we’re effectively back to square one, with the teleport being a short range hop unless planned around, just now with an annoying chargeup time.
To fix this, let me back up a second. Before the teleport was in the game, a few people gave constructive criticism, asking for something akin to a short roll. I understood where they were coming from, but I’ve complained about rolls/dodges before, with good reason. To be fair, my main issue with a dodge mechanic is the i-frames, which tends to turn combat into a glorified game of Simon Says, where the player presses the “dodge” button to glitch through damage. That needn’t be a part of any roll/dodge in general, so it’s not a huge issue.
Unfortunately, in a top down 2D game, controlled by WASD keys, you only have eight possible directions of movement. If you want to let the player hop/slide/teleport with a full 360 degrees of freedom, you have to use the mouse. Once you’re using the mouse if feels far more natural to have the player throw something, as opposed to rolling. This practical concern alone mostly ruled out the idea of a dodge/roll/slide.
Second, the disconnect between the throw and the actual teleport gives the player more tactical flexibility. They could throw the teleporter and then never use it, use it half a minute later, or use it the first frame that it lands.
Third, after landing, the teleporter radiates energy in a direct line towards the player for a few seconds. This adds another factor to positioning for the player. Not only do they have to position themselves to avoid damage, get in melee range, go behind cover to escape projectiles, get out of cover to snipe enemies, etcetera, they now have to factor in their position relative to the teleporter, if they want to deal maximum damage to enemies.
Fourth, to encourage aggressive play I gave the teleport an AoE damage effect upon use. That way the player is encouraged to teleport into enemies, at least some of the time, as opposed to teleporting to a safe place. It’s another dynamic factor to consider. Theoretically you could give a roll an AoE, but it would be very odd.
The design made sense, but it didn’t work in practice, so I scrapped the initial idea, and went with a far simpler system. First, I made the teleporter damage enemies it passes through when in the air. Then I gave it an extremely generous hitbox, which makes lining up multiple hits far easier. Yeah, it’s bullshit, but it’s bullshit on behalf of the player, so it feels good. It’s the same reason why the enemy projectiles have hitboxes that are smaller than their apparent size.
The green represents the hitbox.
Second, I made the teleporter come out immediately. No charging, and no UI to show where it’s bouncing, because it no longer bounces. Instead, it continues on until it hits a wall, at which point it stops. That way the player can throw it across the arena. In flight, they can see where it is using their minimap, as it’s the bright teal circle.
It was a pain to capture this, since the key to jump to the teleporter overlaps with the key to pause Unity.
Third, they no longer need to wait for the teleporter to land before they can jump to it. If the player sees a juicy clump of enemies, even if slightly off screen, they don’t have to precisely aim at them, nor do they have to factor in the windup time. Instead, all they need to do is throw the teleporter in that direction and trigger it when it’s in the middle of the pack of enemies.
The new version is fun and practical to use, unlike the original version. So why didn’t that work? I think in part it’s because the movement speed in the game is fairly high, while the arena is fairly small. As a result, placing the teleporter in a spot and then jumping to it later wasn’t all that useful. Yes, it’s good to get there faster, but almost never worth the ordeal of setting that up ahead of time.
Secondly, the location of enemies/things ten seconds in the future is far more uncertain. As a result, immediate teleportation is massively more useful than anything set up ahead of time. That’s even more true when using the teleporter offensively, since herding the enemies to the right spot while playing the game normally is nearly impossible. It therefore feels almost random when the teleportation is effective, because the game is too complicated for any person to reasonably work things out ahead of time.
However, I think I could have tweaked and tuned the set-up version until it was useful, even overpowered, but there was another reason why I didn’t do that, far more important than anything mentioned previously: it simply didn’t feel good to use. The new version, where you throw it out in a direction, and can jump to it as soon as it leaves your hand, feels snappy and responsive. The old version felt weird and clunky. I can’t necessarily explain why. It’s kind of a shame how (theoretically) deep game design plays second fiddle to the nebulous concept of gamefeel, but it is what it is.
VARIOUS HEALTH MECHANICS
Sticking to the theme of adding more player options, they now have two user controlled shields. The first, which I’ll call the overshield, simply adds a very large, but very rapidly decaying shield around the player. If you ever played Overwatch, just think Lucio’s ult, Sound Barrier, but for one person. The point is to give the player the option to temporarily tank a few hits, or be safe for a brief amount of time, enough to move through a very dangerous area. It triggers automatically upon taking damage that would have otherwise killed the player, but skilled players will actively trigger it so as to maximize their uses. Right now it’s represented by the giant purple circle below.
The white slashes, which are animated when in motion, are another shield, which I’ll call the hardened shield, that stops 75% of the incoming damage. Why both of these? I figured that I might as well try both and see what works best for this game.
After implementing the hardened shield I realized that it had almost no utility by itself. In many games that would have been great, but this game is largely based around avoiding damage. Most things hit quite hard, so taking damage at all is so bad that even massive damage reduction often doesn’t do all that much for the player. Also, I’m running out of keyboard real estate, so I put this on the 1 numerical key, which means your ring finger has to come off the WASD keys to hit it. That makes you more likely to get hit in the first place, so it just wasn’t enough, in and of itself.
However, I thought this could be combined with something offensive. That way the player has incentive to use this as often as possible, while being able to take some more risks. I dusted off an old, discarded ability that I’d made, which basically just radiates damage for a while, and set that to trigger simultaneous with the shield. I am pleased to say it works quite well, and the combination makes both abilities viable. You have a reason to use the shield, since you’re radiating damage, and can be far more aggressive then normal, due to the damage reduction. However, since you’re never invulnerable, it’s not a get out of jail free card for any situation.
Since these two abilities are quite powerful, I decided to give them fairly long cooldowns. I played around with a few numbers and settled, somewhat arbitrarily, on thirty seconds. This seems to be short enough to be relevant, while also being long enough that you have to balance waiting for a good, productive moment to use them, while not waiting too long, so it can start charging again earlier and you get more uses.
The programmer art UI still looks like trash.
Finally, I wanted the enemies to drop something of value that the player has to pick up. This adds another layer of decision making both in terms of positioning the player, to gather the pickups, as well as herding the enemies before death, to manipulate the location of these pickups. They can be seen as the little candle things below, not because they should be candles, but because that’s an art asset I had lying around.
However, I wasn’t sure what the pickups themselves should be. They could be purely for score, and while I respect meta/arcade things like that, I always prefer there to be at least some in game justification for the player to go out of their way to pick them up.
Some obvious options get dangerous as the enemy count grows. For example, if each pickup gives the player some small amount of health, then it’s possible that more enemies actually makes the game easier, or at least makes the game much less difficult than intended, as the player is healing for more. That’s true if they regen a bit of shields as well.
There is no ammo in the game, and while I don’t have anything against that in general, I don’t think it works here. Even if we did have ammo, we have something of the same problem, where the ammo scarcity isn’t really increased through more enemies, since more enemies means more ammunition.
Finally, I decided that the pickups should reduce the cooldowns for various things, such as the shields that I just implemented and the teleporter. However, we have something of the same problem. The hardened shield radiates damage in an area. We don’t want to nerf it to the point where it’s useless, but if the pickups reduce the cooldown then it’s not hard to imagine a situation where, with enough enemies, the player can use that to mow them down, spend just a few seconds pickup up cooldown reduction items, then mow them down again.
The solution I settled on was for each pickup to logarithmically increase the cooldown rate, up to a maximum of 2x. When the cooldown rate has been maxed out, instead of taking 30s to recharge the shield, it would take only 15s. The first pickup increases the rate to 1.5x, the second to 1.75x, and so on. This boost only lasts for one second. Taken together, this makes it definitely worth it to the player to pick these up, but it’s never anything that provides some radical, game breaking power.
Anyway, I’m taking a small break from focusing on the gameplay, and creating the cutscenes. Ideally, there would be a few actually filmed cutscenes, but even something as simple as two people sitting in a chair talking requires a level of production that we just might not have. Instead, I’m creating cutscenes similar to the old Starcraft 1 pre-mission cutscenes, which looked like a bunch of avatars on a zoom call. I’ll write about that later.
