Telegraph Investigation Project Design
Building upon the pitch slides for Brave Courier shown earlier this week, this new submissions contents are in the Brave Courier Project Design document. (That link goes to another public Google Doc, a local export of which I’ve also uploaded on T-Square.)
Copy of that document:
Brave Courier
By Telegraph Investigation
The central details are still consistent with those outlined in the pitch, though elaborated upon and planned out as indicated below.
Detailed Plan
-
a more detailed plan for the game
There are effectively 4 phases to the creation of this game, which are separate from (though collectively in service of) the 4 core aspects. Those phases are:
-
Stickman animation engine improvements (greatly saving time on biped animation authoring, and if done right extending the possibilities of the engine)
-
Implementing or improving upon the 4 core aspects (hover feel, press-time-as-force, telegraphing action/vulnerability, and recoverable grapple) as outlined in the next section of this document about Feature Sets
-
Aesthetic polish including background (lines for silhouettes of mountains, city on horizon, etc), sound effects, particles, music, to help convey atmosphere and a feeling of completeness rather than having a distractingly barren interaction space
-
Reflection and analysis on specific lessons learned about each of the 4 core aspects through their exploration during this project
Phase 1 is foundational, and though largely in place by the time of this documentation it absolutely needs to be completed in time for it to be of use in preparing for the alpha playtest.
Phase 2 is the bulk of the design, and thus is the focus of the Feature Sets section and needs to be at least at “minimum low-bar” by the alpha milestone. I’m opting to initially take a breadth-first approach to implementing the four rather than a depth-first narrow slice into each category, since part of my interest is in how these non-analog and predictive input dynamics can work together. That means in the alpha milestone I can hope to discover which of these areas is most in need of further refinement first. I’ll then seek to get as many of the aspects from Phase 2 as possible up to Target of Expectation level by the beta milestone, but all up to ToE by the final milestone and at least one up to Desired High Bar by that point.
Phase 3 needs to be started by the final playtest, but can partly wait to be wrapped up until the final materials hand-in since it’s specifically content not central to gameplay (or even polish in the sense of game feel). Phase 3 has value to me in helping to situate the core interactions in a more compelling and digestible context, but I also recognize that it’s not the point of the assignment nor a part of its assessment and thus it’s of much lower priority than Phase 2. Aspects of Phase 3 may even wait until after course hand-in, to instead by in by my target date for public release around December 6.
Phase 4 is of specific interest to me as a research student, but even more so than Phase 3 I recognize is not really the purpose of this project. I’m unlikely to give Phase 4 anything more than a passing thought up until course handin of final materials, though at that point I’ll be switching into post-mortem and documentation mode with the goal of writing up these learnings in a fashion I can easily share with the general public (YouTube video and/or blog entry, though possibly a research paper submission depending on what comes out of it).
Feature Sets
-
three feature set targets: the minimum low-bar of you will do, a target that you expect to get done, and a desired high-bar if things go exceptionally well. Plan these out carefully, so that you can definitely high the first, and likely hit the second
Since the core of Brave Courier is 4 different aspects of the gameplay built atop the Hovering Hermes prototype, I’ll mark these feature set targets as a function of how far along each of those aspects gets in development, ranging from first pass to polished intention.
Minimum Low-Bar:
-
Hover implemented basically as laggy input plus board tilt reflecting lateral speed
-
Press-time-as-force used to distinguish light, medium, and hard attacks in either direction, but the difference only affects a tradeoff between how rapidly the attack connects and the probability of it knocking an opponent off their board
-
Telegraph implemented in heavy handed “retro” way (enemy flashes or twitches a consistent brief delay before actual attack and vulnerability window)
-
Grab mechanic as throw which can be interrupted if a counter-throw is attempted early enough in the animation
Target of Expectation:
-
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
Desired High-Bar:
-
Hover implemented in such a way that controlling the board really begins to feel like surfing or skateboarding, complete with the possibility of falling off due to losing control but without those falls feeling cheap or arbitrary, potentially with dynamic character leaning/swaying to resemble an effort to maintain balance as the board moves
-
Press-time-as-force designed into the combat in such a way that their distinction becomes more central to gameplay, for example supporting crouch and blocking defense such that hard attacks miss a crouch defense while light attacks are useless against a block (possibly, for example, interpreting “hard” attack as throw, such that over relying on throw increases player’s odds of losing balance)
-
Telegraph implemented into timed animation sequences, better reflecting how telegraphing occurs in fencing or boxing by having attacker lead with shifting weight toward leg or shoulder etc.
-
Grab mechanic as more involved counter-recounter chain of quick attacks
Timeline
-
a timeline of what you intend to accomplish by the end of each week through the end of the semester.
(October 21: Pitch basic concept to class)
October 25: Submit this project design document. Add functionality to engine to visualize stick figure pose(s) in-editor while not in Play, as well as feedback in that visualization to hint at when any limb is stretched or compressed.
November 1: In preparation for alpha on Monday Nov 4, I’ll have Phase 1 (stickman animation engine improvements) completed, and utilize that for the implementation of first pass (Minimum Low-Bar) at each of the 4 core aspects of Phase 2, aiming for either #2 or #3 to Target of Expectation level
November 8: 2 more core aspects up to Target of Expectation level, potentially a very brief initial foray into Phase 3 (aesthetic polish) to help reinforce tone or otherwise better situate the next round of testing in a less sterile experience
November 15: In preparation for the beta playtest on Nov 18, I’m aiming to have all core aspects of Phase 2 up to Target of Expectation level, plus at least 1 at Desired High-Bar (which being dependant upon testing, feedback, and my own self-assessment at this point)
November 22: In preparation for the final playtest on Nov 25, I’ll give another round of attention to Phase 3 (aesthetic polish) to ensure that I’ll be getting testing in with those elements which I don’t anticipate severely affecting play (to verify whether that assumption is correct), as well as ideally bringing another Phase 2 aspect up to Desired High-Bar, although I anticipate that this week will largely be dedicated to bugfixing and related polish in reaction to the beta playtest.
November 29: In preparation for final materials hand-in, focus on this point will be on tuning adjustments in response to testing, and finding or fixing known bugs, but not on adding anything new or making any severe changes.
December 6: After the course requirements are over, for this date I would like to have publicly posted about this project, at least in video form, preferably as a playable build, or optionally as part of an instructional tutorial video demonstrating some of the Unity tricks or design decisions in the project. As part of getting the project ready for this I’m likely to give another pass at Phase 3 considerations. This will be my first week thinking seriously about Phase 4, which will include figuring out whether it’s something better suited to a blog entry, video documentation, or paper.
Milestone and Playtest Discussion
-
a target feature set for each milestone (alpha on Nov 4, beta playtest on Nov 18, final playtest on Nov 25), along with a discussion of why you are targeting this particular subset of your game at each stage, and what you hope to learn by having people playtest each of these.
Although addressed earlier in this document in the Detailed Plan and Timeline sections, I’ll collect that information here for sake of overview, along with some notes about playtesting at each phase.
For Alpha Playtest on November 4: My goal here is to get the four core aspects of the game stood up and interrelating, to figure out as early as possible whether they can work together (even in simple form) or whether I need to find ways to more discretely segment the aspects I’m investigating. As a prerequisite for getting to those questions I’ll need to have the remaining adjustments to my stickman animation code done by the Friday before this playtest. As the earliest playtest this is also when I’ll be trying to figure out what elements of the gameplay are best resonating with people or confusing them, to help inform tradeoffs about which aspects I’ll pour more time into (or potentially nix or at least separate somehow) in the remaining time.
For Beta Playtest on November 18: Here I’m really aiming to get the game feeling more like it’s done, even if it at this stage it will still have a good amount of work to go. The emphasis here for me will be getting the 4 core aspects up to Target of Expectation levels, so that no matter what else happens with the project, I’ve at least given myself an honest shot at figuring out how each of these 4 work. This test will have a little aesthetic cleanup in it, but more so to try to minimize the distraction of a crude prototype than to convey substantial atmosphere. At this playtest I’ll be trying to figure out which of the 4 aspects can be productively emphasized or should be muted in the next build, as well as beginning to pay attention to the difficulty tuning.
For Final Playtest on November 25: At this stage I need the game to basically be done, which includes at least some aspects to Desired High-Bar state, along with more attention payed to the Phase 3 visual aesthetics considerations. Playtest at this point is really looking to identify rough spots in the game’s design that I’ve potentially introduced during pulling the game together since the previous phase, but also to confirm (hopefully by the absence of their repetition) whether I’ve managed to successfully address issues identified during beta playtest.
For Final Materials on December 2: Correcting for tuning or bugs spotted during Final Playtest, otherwise basically having the project handed in with as similar a condition as possible to the final playtest build since that’s the one I know has stood up to a round of testing. Any additional aesthetic polish would at this point be post handin and for my own purposes rather than as part of the class assignment, though as has been emphasized in class those qualities of the game are not really intended as an important factor in the grade anyhow.
Comments are closed.