v0.1 Feedback Implementation Plans

Hi! A couple of days have passed since the first launch, and feedback / suggestions are slowing down, so I figure this is a good time to write the first of these. I'm hoping do do one of these a few days after each major update, so that I can report on objectives for the next update, feedback to implement, and so on.

Firstly, I want to give a massive thank you to everyone who's downloaded and played. I didn't expect much of anything from this, and I am not exaggerating when I say that the amount of downloads so far is more than what I'd hoped for by a factor of about a hundred. Everyone's also been super positive and constructive with their feedback, which has given me a lot of motivation to keep going.

On to the update stuff:

Naturally, since this is the first release, there's a lot of stuff to go over. I'll try to break this up into chunks so that it can be more easily skimmed.

COMBAT AND PLAYER STUFF -----

So this is the really big one right now. Enemies are weak, and the player is super overpowered in comparison at the moment, which makes fights trivial to the point that in some places attempting to skip the fight is more dangerous than the fight itself if you mess up your jumps.

• Enemies - To be fair, enemies in this location are supposed to be very easy, as the zone is more about cementing other game mechanics like basic controls, switches, save points, etc. Going forward enemies are intended to be more difficult, with more unique AI and movements. At the moment I'm trying to come up with some overall archetypes for enemies that I can fall back on when coming up with them. The list of archetypes currently consists of:
  • Simple - most of the enemies present right now. They just move towards the player and grab them on contact.
  • Swooper / Pattern movement - slightly more difficult than the simple ones, with set movement patterns that they use to try and collide with the player. Think divebombing flying enemies, or ground enemies that jump forwards.
  • Attacker - Enemies with actual movesets, usually just one or two moves, and some more detailed AI that isn't in constant pursuit. This should range from lunges, to actual weapon attacks that deal damage without grabbing (I'll get to this in a moment)
  • Caster - Fires slow moving projectiles that damage or stun. The Squirrels are supposed to do this when finished.
  • Sniper - Similar to caster, but fires a much faster projectile with a telegraphed warning, locking onto a specific position before firing a moment later.
  • Controller - Enemies that attempt to push/pull the player or create environmental hazards instead of actively chasing them.
  • Spawners - Creates more enemies. Might be a little bit difficult to make this work with enemy sizes, but there's at least 1 or 2 places where this could work.
  • Tank - Pretty self explanatory. Enemies with a large health pool that pose more of a threat when left alive in situations with other active enemies.
  • Rusher - More dangerous version of simple with much higher top speed, but slower to change directions at high speed. 

This list will probably grow with time, but this should hopefully be a pretty decent baseline. As for the non-grab damage thing: The idea is that some enemies can have moves that don't result in an immediate grab, but can still deal damage or stun. The reasoning behind this is that it opens up movesets for enemies a whole lot more than if every enemy just grabbed the player on contact. If the player reaches 0 and isn't currently grabbed, they'll enter a downed state. While in the downed state, any enemy can initiate their grab and finisher animation. If no one grabs them after a set time, or the player hits the break grab button, the game will screen wipe, teleport the enemy that landed the final blow to them, and their animation will play.

• Current player moveset - The player is going to get other moves as the game progresses, but the base kit needs to be fixed before I can start worrying about that. The current plan is to keep the flurry attack, but remove the knockback and parry potential from every hit after the first one. This should heavily limit how useful it is in most cases, but make it viable as a way to punish stunned enemies, such as the warden after parrying him. I like being able to button mash the hell out of an enemy, but I want to make sure it can be done in a way that doesn't make the combat boring. 
• Upcoming player moveset additions - None of these will probably show up for a few updates, as they're intended to be unlocked after the first 'big' boss (we're working with Dark Souls style bosses, so 4 big ones with 1 required to be first.) The actual combat ones are a charged hit that the ready attack will graduate to, as well as a weaker ranged attack. Non-attack abilities include your standard things like double jump, glide, and an i-frame dash. Up/down directional attacks are also something that I'm looking at, but aren't immediately important.
• Money, Energy, Health - Both a money system and an energy system are planned, they just don't have any use at the moment. Money will be able to be spent at certain NPCs to upgrade your abilities. Abilities that were gained by beating a boss can be upgraded by talking to the uncursed version of the boss after beating them (also would like to include some text boxes and more detailed spritework for these, as well as maybe a little minigame if you fully upgrade their ability, hint hint).  Energy will be able to empower certain abilities, as well as heal after a channel. I originally was taking inspiration from Pseudoregalia for this system, but after I went in to do some enemy design research earlier I realized that it's almost exactly what Hollow Knight does with it's energy system, minus the attack enhancement thing. Health pickups will be available in breakables, with a random chance of spawning, alongside money and energy. There are 3 tiers of health pickup: small (1/4 base health), medium ( 1/2 health, the fire pickups already present), and maximum (full heal).

ANIMATION AND ENEMY VISUAL STUFF -----

This part's not as massive, but probably will take more time to actually implement than the combat stuff.

• Submit button - one of the most common things I've been asked about across platforms is about adding a oneshot / instant finisher mode so that you don't have to wait around for your health to deplete. The best solution to this I've seen is to add a submit button, which would not only allow you to skip this, but also have unique dialogue. 
• Finisher code rework - Finishers are currently a single script that cycles through each animation step and checks for filters along the way. It's overcomplicated, obnoxious to set up, and very limiting in what it can do. What I'm going to be doing to replace this is turning each step into it's own state with it's own script. Not only will this make it easier to set up, it will remove the set in stone animations steps so each enemy can have completely unique finishers that don't all have to share the same formula. It will also make things like randomized animations much more feasible.
• Health% based grab animations - The idea here is to play further and further into the swallow animation on some enemies based on how much health the player has remaining, with 100% being the base grab. This probably won't be applicable to every enemy in the game, but should hopefully be a nice detail when it can be used. I'm also planning on making this optional for those that just want to play the grab until the finisher is started.
• Gender toggles for enemy animations - going to get this done as soon as possible, because it would be a lot easier to do the finisher rework with this in place already. Pretty self explanatory, allows finisher animations to be filtered based on enemy gender. Current idea for futureproofing is to use 6 switches; M, F, M intersex, F intersex, Ambiguous, and Non-Applicable.
• Longer digestion animations - some people want to see the portrait longer, so struggle loops are planned to be extended.
• Manual animation navigation - Optional settings to manually choose when to move through the different stages in a finisher. This will probably be a different button (maybe the same as the submit button?) so that the entire thing can still be skipped if you just want to respawn.
• Hit feedback - Some sort of hitmarker or flash when you damage an enemy to provide visual feedback.

OTHER THINGS FOR NEXT UPDATE -----

• Controller support - this should be pretty easy as Godot's input system makes this as simple as just clicking the input and the hitting the button on the controller. I could technically do this in like 2 minutes flat.
• More tutorial signs, and parry indication - Signs for jump control and grab break are going to be added, as well as some sort of message or sign to indicate that you can parry the warden. I'm actually really curious how many people know you can do this considering that there's literally nothing that tells you you can.
• Coyote time - Devspeak for the little grace period you sometimes get to jump after already walking off of a ledge. This is really important to responsive platforming.

THINGS TO IMPLEMENT THAT PROBABLY WON'T BE IN THE NEXT UPDATE -----

These are either planned in the long run, or noted as something to look into.

• Android / Linux / HTML versions - I can only test the Android and HTML exports because I don't have a Linus system. Android will likely be the first of these to be done.
• Key rebinding - Response to keybinds seems to be a little mixed in some places, with Z/X for jump and attack being requested. Intended hand placement is Shift /z / x / c / and space, but I will look into allowing custom input maps at some point.
• More save slots - Currently the one save slot has a hard coded directory path, so I need to come up with the script to not only make extras on the fly, but also a way to differentiate between them. Not really worth it at the moment because there's only like 10 minutes of story gameplay tops.

NEW CONTENT OVERVIEW FOR NEXT UPDATE -----

Starting from here, I'm going to try and release 2 areas per update, give or take. This should be pretty simple for the next 2 updates, but will get more difficult to determine which ones to include after that point, as the game's exploration opens up then.

The next update will include a portion of the Limestone Capitol (modern medieval city), and the Redwood Expanse (big tree zone). There isn't any boss in either of these areas (at least not one that you can fight yet) but I'm aiming to have 3-4 unique enemies per area, which should roughly double the enemy count as of now (not counting the Squirrel, who is located in the Redwood Expanse.)

I don't have an update schedule, and I mostly work on this as a hobby project when I'm in the mood to. Time between updates will probably vary pretty wildly, so it could be a while, or it could be the end of the month, but it will get done.

That should be just about everything I can think to cover, so I'll see you all in the next update, or potentially in another devlog if I have anything interesting to show off in the meantime.

Thank you all again!