Telegraph Investigation: Log Nov 11
Playtest Notes
• First some things people liked: particles from successful hits, hover movement, increase in enemies as player succeeds, feel of speed from lines underway (will be adding wireframe foreground and background objects to add to this effect), stickman/vector aesthetic, “this is awesome.”
• Confusion about why losing balance. Doesn’t expect hard hit to lose balance (I’ll change it to automatically hit when bar is full, instead of losing balance), expects left/right to factor into “catching self” when “losing balance” (suggests a more involved interaction with being hit, can explore in next iteration).
• QWAS 4 button “SNES” layout feels awkward to people, people agree WASD would make them happier and also want a way to attack into foreground/background instead of just forward/backward (will change from old attack scheme to A/D being strike forward/backward and W/S as grab foreground/background).
• Players keep holding up against forward or backward boundary (will modify engine to create impression of “limitless” forward and backward movement without consequence)
• Some players wanted to tap rapidly/aggressively to hit harder rather than holding the button longer (considering experimentation with a consecutive combo series like Double Dragon’s). Fast attacks seemed like more powerful strikes than slow attacks.
• Flash was inadequate as telegraph for people to attack or defend appropriately (will need to elevate this to the animation timing as planned).
• Some players got knocked down quickly after respawning (will introduce a flashing/invulnerability time on reset, at least for player).
• Multiple players wanted to be able to cancel out of one attack animation to immediately interrupt it with another attack.
• One player’s color blindness led me to remember that it’s important to use more than just red and green to distinguish the fingers (currently thinking about head decorations, like a halo and horns).
Planned
My goal as stated in last week’s alpha log, including a bit of optimistic catch up but written before the playtest:
> “for next week’s build I should have all 4 at Target of Expectation level.”
Target of Expectation level from the original design doc post describes the following:
- Hover implemented as a basic physical simulation, involving (though partially automating) some corrective tilting to avoid overshooting
- Press-time-as-force used to perform different attack animations, rather than the same animations at different speed, though with engine support for different animation rates through multiple frames
- Telegraph done in an exaggerated but easily readable fashion, a la Mike Tyson’s Punch-Out!! gestures before major attacks that leave an attacker vulnerable
- Grab mechanic as tap-retap escape or throw, as described in pitch
I still did 1, since based on player feedback it seemed important to the concept of balance for the player to get knocked around and be able to correct/catch themselves.
Item 2 and 3 I’ve combined and jumped straight to the goal of 3 from the original “Desired High-Bar” spec level, adapted a bit based on feedback. Now while the attack button is held the player draws back into a windup sort of pose, and release throws the hit. Grab no longer has a windup effect since players indicating that a “hard” grab didn’t make sense to them, but instead since grabbing is a foreground/background attack holding it causes the board to tip and thus steer more laterally, so that holding the grab button extends range but holding too long (in a way that’s clear from the visualization) can leave the player out of control or tipped.
On the note of item 4, in response to feedback since the old notion of defend wasn’t making sense to folks I’m also jumping there straight to the “Desired High-Bar” goal of a “Grab mechanic as more involved counter-recounter chain of quick attacks” complete with a different camera behavior during that exchange. This is a significant addition of poses and code though, and so I’ll be postponing this part for next week. So it’ll be there for beta test but isn’t even partly caught up in implementation yet as of today.
Also, of course, the parenthetical solutions mixed into the playtest notes above were now on my todo list, split between this past week and the next/current week since this time I won’t have a fresh round of playtest feedback added on.
Accomplished
I’ve stayed on target of getting roughly half of my playtest feedback integrated, although I’m optimistic that tonight after class when I get a bit more time I’ll be able to catch up with that goal. I’ve prioritized the items that people complained most about or ran into most often, including: switching to WASD for foreground/background grabs instead of the QWAS forward/backward attack and grab system, getting rid of boundaries by simulating infinite road, invulnerability after respawn, no longer causing player to fall from holding hit too long (automatically throwing the hit instead), respawn flashing invulnerability time, and telegraphing by animation draw back rather than color flashing (player only at this point, next getting the AI to do it), and board physics that get influenced when the character gets struck so that balance can be “caught” after being pushed if counteracted quickly (a variation of the tap-release reaction time mechanism initially intended for grapple).
Problems
Not really problems per se, but the playtest as noted above has altered and added some todo items. That’s certainly to be expected. Watching people play in the playtest was incredibly helpful since it gave me a clearer picture of how they wanted to play it, which I’ll be adjusting the game to reward. The work done for the start of last week, centralizing the character code between player and AI and in establishing a common set of poses to animate from, greatly simplified meeting this more recently week’s goals without requiring a bunch of prefab twiddling or unwanted code duplication, though had I not been prepared in that way it would’ve likely been a problem about now.
One thing I realized during testing was due to how the charge up meter worked the player’s action didn’t happen until release, which got in the way of real-time feedback – at least on the character itself, where the player’s attention is the whole time. The connection to immediate animation wind up position should mitigate this problem though by providing instant feedback, and likewise for the grabbing system which will combine foreground/background grab animations with movement tilting/falling in that direction.
Plan Moving Forward
Combo series for rapid attacks, the grapple system, attack interrupt, distinguishing player from AI by head shape/decoration instead of just color, AI telegraphing by animation rather than flash (as the player now does), and adding some polish elements like foreground/background wireframe buildings whipping past. The way that playtesting has melded some of my timing plans actually puts me right on track with regard to the initial schedule, since meeting the adapted goals will overlap with getting up to the point in spec originally set for the beta playtest.
Comments are closed.