Preamble:
I’ve been working on a long effort to identify things in frogatto’s core gameplay that are annoying. I’m convinced that these cause a “death of a thousand cuts” to enjoyment. I think the primary emotional poison is that the player’s abilities feel unreliable, and like unreliable equipment, their failure to function correctly in a life-and-death situation feels like a betrayal - like a mule suddenly refusing to move when his rider’s life depends on it doing so. You count on these abilities to always work given the correct input - if you point a gun directly at a target and your aim is true, it should always hit the damn target. It’s infuriating if you do something with visibly almost identical conditions, and due to some really small edge-case differences, it works in one situation, doesn’t work in the other, and it’s not visibly obvious why it didn’t work. Often these misfires kill you, or cause you to be hurt, because something you were counting on to prevent damage, doesn’t.
In fixing these, we need to avoid having “sacred cows” - that is, aspects which we refuse to alter for idealistic reasons. A classic example is realistic physics - we can and should violate even the most basic physical laws if it makes gameplay better. One important note is that although adhering to visible rules for the player’s enemies is important to make the game feel fair, it’s almost always okay to break the rules in favor of the player. It doesn’t feel like cheating.
This list is meant to catalog things we’ve already fixed, and things we intend to fix down the road.
Example:
One thing we’ve already fixed, was frogatto tongue-grabbing acorns. It used to be very hard, prior to our extending the tongue’s grab-area well-outside the opaque pixels (having a 1-1 correlation with opacity was a sacred cow). Acorns moved quickly in a vertical direction, so fast that the window of being able to hit them with the tongue was perhaps only a frame in length - in fact, possibly less (it’s possible that they were moving fast enough to skip-over the tongue’s collision area entirely). The result in game was that you’d see an acorn immediately in front of you, you’d hit the tongue-button… and given these seemingly identical initial conditions, sometimes you’d grab the acorn, sometimes not.
It felt like a coin-toss as to whether it succeeded, and that sort of behavior has no place in frogatto.
Fixed:
-
frogatto’s tongue-grabbing had a tiny vertical collision area. This was fine for making contact with things moving horizontally, it was broken for things moving vertically. We fixed this by expanding the hit area to a large region around the tip of the tongue.
-
frogatto’s feet used to be a single point, representing his vertical midline. He would often jump onto objects, and visually look like he should be able to stand on them, but fall off because his midpoint wasn’t over their solid top. We fixed this by making him check not a single point, but a wider, horizontal line.
-
frogatto’s primary attack requires two enemies to be present, and there were often situations in game when two were not (including possibly having killed one already). We’ve fixed this by creating a supply of respawning ammunition objects.
-
frogatto’s attacks used to cause him to cease to accelerate for the duration of the attack, often causing the player to fall, die, or get hit. We fixed this by allowing frogatto to keep walking whilst spitting or using his tongue.
-
changing direction during the extension of frogatto’s tongue used to cause the tongue (which was being relied on to nullify an oncoming threat) to disappear, causing frogatto to get hit. We fixed this by making frogatto’s head a separate object which was able to continue facing in that direction for the lifetime of such an attack, allowing it to complete in the intended direction.
-
we used to have some team-status bugs in thrown enemies which meant that sometimes they inconsistently failed to deal damage (due to some unexpected code path failing to change a variable). This resulted in an enemy becoming permanently harmless; or sometimes resulting in frogatto being hurt by his own projectile. This has been fixed by making team a property, rather than a variable.
-
there were odd situations in which enemies would ?cancel out? of certain states; where behavior from one state of a multi-state object would ?leak? into another state by the object running into some trigger that almost never got called in normal circumstances, but could very rarely ?derail? the object into some other state. For example, a flier bumping into ground might start walking, or might get stuck. A swimmer might fly if for whatever reason it escaped from the water. A frequent one was thrown enemies canceling their stun early.
-
when you spat out an enemy, it wasn’t possible to re-grab it until it turned back into an enemy (due to frogatto being unable to grab anything on his team). Because some thinks like enemy-shots you could grab-and-refire never got switched back to the enemy team, you could never re-grab them. We’ve changed this so that the only stuff frogatto won’t grab is stuff flagged as actually being part of his body.
-
frogatto couldn?t jump on top of enemies during his post-hit invincibility; he was completely intangible the whole time. Now, he?s intangible only until he?s outside of the enemy?s solid-area.
-
rare situations could trigger two additive effects that made frogatto go up, both frogatto jumping, and frogatto bouncing at the same time. Other situations could result in a jump being robbed of almost all it?s upward velocity. We found what caused this and fixed it.
-
frogatto sometimes stood on objects he’s supposed to bounce off of, by “walking onto” them - if he transitioned into being on top of them without having any y-velocity at that time (possible when walking off a ledge, or in rare cases for a single frame at the apex of his jump. We fixed this by causing him to fire a bounce event if he’s ever “standing” on an enemy flagged as bouncy (since of course that shouldn’t ever be possible), but this fix might not apply to non-bouncy enemies that are nevertheless supposed to “do something” when jumped on.
Broken:
-
due to the tall arc, it’s possible given the right conditions to spit a projectile at an enemy immediately in front of you, and fail to hit it. Possible solutions include greatly widening the hit area of spat projectiles, changing the physics of spat projectiles so they either have a lower arc, or so they travel forward without being affected by gravity for the first 1/3 of a typical trajectory.
-
the run-attack can be triggered by accident when you intend to use a tongue attack. We will be removing the run attack. Its stun effect will probably be salvaged for some power/ability.
-
The walljump is nice when it works correctly, but once you’ve entered a wall-cling, the only option for movement is the reverse of the direction you came from. If you enter a walljump by accident by undershooting a ledge, you’re forced to move in the opposite of the direction you came from. This is extremely common for ledges which the player can normally clear with his standard jump height. This can kill you, and needs to be fixed; I’m not sure how to fix it but I do have a few good ideas.
-
the gradual downward-slide in the walljump is probably unnecessary.
I think we should change it so that: if you hold the arrow key pointing towards the wall, you cling on without any downward slide. If you don’t hold this key, you immediately fall at a normal speed. Regardless of any arrow-key being pressed, if you press jump whilst near a wall, you’ll do an immediate outward wall-jump which is able to cross most columns (the current walljump you get without the away-arrow is largely useless; I propose giving it enough sideways momentum to make it useful). I’m not sure if this will solve the issues, but we need to make some attempts at doing so.
Another thing I’m speculating on is a small bit of ledge-forgiveness if you manage to miss a ledge by a tile or two. The danger here is that a naive implementation just power-creep’s the player’s jump height to effectively be one tile higher. It’s possible that giving the player this forgiveness only up to the tile-height his jump allows would negate this, but it’s also possible this may feel inconsistent and unfair when it doesn’t work (it may not be obvious why).