Update gif:
(Right-clickers, yes I am typing this at 3:44 am. The background is messed up since I screwed up the camera with some file and I suck at Unity's UI enough to not care about fixing it, so ignore that. You can also see some of the test objects that I just leave laying around in the scene.)
Quite a bit is going on here, but I'll keep this brief.
The first change you see is the pause. That's nothing major, just a pause screen that can get toggled. I some checks for it on the base function for enemy attacks, so hopefully I'll not need to mess with that again except for cutscenes/transitions.
The second thing, more worthy of an update-blog, is the downward throw after the second enemy is grabbed (it's set to such a much higher velocity, hence the choppy animation). I added in a very primitive combo management system into the game - if the game is unpaused, and the player presses an attack/action key (stressing that left/right and jump are not included, for reasons I'll get to in a moment), the input gets logged into a keypress queue. Each item in the keypress queue is tied to a timer that lasts around a fifth of a second. After this, the queue is checked to see if the first item is expired. If it is, the queue is stepped through. This way, the player has time to press a follow-up key before their move actually executes. ALTERNATIVELY, once it reaches the end of the queue, if the player is at some move that has potential children, they're given a little more time to add new inputs to the queue before executing. This way they have time to input longer combinations.
To demonstrate, let's say use the simple [Strike(A), down] move in the gif. When the first item in the queue expires, the items get cycled through. All combos in the game are stored in a tree-node structure, beginning with a blank-input item that steps through children by the input key in the next queue item. The initial item, of course, has every key mapped, but for the children downwards, each of them has a moveID, and (possibly) children mapped to a follow-up input. So, the queue here goes from [start] to [horizontal strike]. If the next queue item is the down arrow (or S), then the returned move will be the [downward throw]. Otherwise, the [horizontal strike] is returned as the active move. Because of this, I can't do anything with left, right, and jump since it isn't fair to have a player screw up a combo by readjusting themselves in midair for an endless runner. On the other hand, I can easily map moves inputs without much effort, add them to the player's arsenal (making an unlock system), and even tie the same move to multiple input combinations, so I'm happy with the tradeoff. The main downside is that I cut myself off from doing complex followups for specific moves, so this is less "combo" and more "complex single-strikes," but whatever.
Once the player gets an active move that's actually a defined move (as opposed to up/down which just eats the input and moves onto the rest of the queue next frame), the move is executed, the queue-addition is locked for the attack duration, and the queue is cleared after the attack is finished. Hypothetically, this could be changed to include a follow-up move tree for complex multi-chain combos or whatever, but that's not what I want to do with this game.
A lot of the game base is close to completion now. That leaves only a few follow-ups: pickups, reworking object/platform spawning as the camera scrolls, external menuing and level transitioning, and animation/sounds. In that order, since doing animations start the official look of the game (that's why I've been mentioning it so often despite not having any plans for it - it marks the actual start of development).
EDIT (not worth separate post):
Turns out menus, powerups, and scene transitions aren't that difficult, so rather than just make an update that's just "the basics of a menu are made adding more later," I'd like to put some very specific goals here to come back to:
Edits as I do them preceded with an asterisk.
-Pickups
--Healing item (*Works, I think. I need to finish the training room's missile launcher so I have something that can damage the player without killing them.)
--Invincibility item
--Extra life(?)
--Damage-up (rework how damage is done, and limit this powerup to tier 1 stages)
-Menuing:
--(All) Options (volume for sounds, volume for music, cutscene mode (arcade/cinematic ; cutscenes minimal, or enabled with dialogue))
--(Main) Level Select (add in dynamic level loading) (*Works, but I don't like the UI for it so far. Need to change to a scroll-down list with a preview screen to the right. This isn't a high priority.)
--(Ingame) Combo List (build a list of all combos the player has access to. TODO: names each move the player has for IDs above 0) (*Horizontal Strike and Downward Throw name added, but no other important moves have been added so far.)
--Remember to pause/unpause timers correctly for scene transitions
-Levels:
--Set speed tiers (0-3)
--Practice Room (0): Very basic area enclosed off. Speed tier 0 (stationary). Only things there are a master-control computer (quits the scene if the player enters the far-range, aka leaves the room), provides a wall for other purposes, and drops a box if the player enters a certain range. Retain in final game for players to mess around in. (*Missile spawning instead of a box at the moment, to test damage. Missile needs finished before getting set to a prefab; will add this in addition to the box spawn.)
--Practice Rooftops (-): Like Practice Room, but with the speed tiered at 1 (5). Cut this off from player access - debug only for testing mobile objects
--Level-end move: If the player is above ground, grab all powerups, then slam down and immediately delete all enemies. Afterwards, the player's input is cleared and the game pseudo-paused.