Reply to thread

Message: <blockquote data-quote="Emberashh" data-source="post: 9199089" data-attributes="member: 7040941">This isn't a shortcoming of the methodology. Its a shortcoming of the fact that I deliberately chose not to model this in the example I gave. Keep in mind the point of these machination diagrams is to abstract gameplay so we can directly examine whats happening. Thats why for example when we look at Pac-Man, its more useful to look at this:[ATTACH=full]331995[/ATTACH]To examine what the gameplay is generally doing. In this case, this models the overall goal of Pac-Man and what players do. This isn't Pac-Man though. This is Pac-Man:[ATTACH=full]331996[/ATTACH]And in fact this diagram, if it was a full replication of Pac-Man would actually be replicated 256 times in sequence, representing the 256 levels in Pac Man that individually change the parameters of the basic gameplay. (Ie less/more dots, different power up times, etc)An RPG is naturally a lot more complex than Pac-Man is. If one wants to fix an issue with Pac Man, trying to do so on a Macro scale wouldn't really work. After all, trying to fix or adjust all the different parts of that diagram simultaneously and carrying it through all 256 stages, while also playtesting, just isn't an efficient design method. Instead, its better to zoom in to the micro scale and adjust there, as those changes can then be individually applied and tested for a desired effect. Then it becomes relatively easy to carry through the change throughout the rest of the game. So when it comes to RPGs what you are hung up on is trying to design in the macro. Thats why the terminology Baker uses is obtuse and why nobody is actually getting any sort of design method out of this. After all, no one has actually shown up and demonstrated what I asked pemerton to do. If this works, one should be able to cleanly and concisely lay out the methodology and demonstrate its use. Zoomed in. The abstraction of gameplay serves to provide clarity for the gameplay itself, so that it is readily observable and malleable. Being able to go in and make micro-scale tweaks is the ideal, as those are more practical than trying to wrap one's head around an esoteric macro level problem. For example, rather than losing the plot trying to make sense of the Position stuff in the OP, we can look at the Fiction as a "game state". This State changes as Actions are engaged, and the new State that results may or may not influence the available Actions. In an Improv game, the initial game state is established by Method X. Method X can be a lot of things. In theater it relies on suggestions from an audience interacting with the players interpretations. In a solo RPG, it relies on suggestions from Oracles and/or GM Emulators interacting with the Players interpretations. In a Trad RPG, it relies on the GM directly establishing a State of their choice, that the Players then interact with with little to no independent player interpretation, though collaborative interpretation is often included. In AW, the GM and Players establish the initial State collaboratively, though theres options for other mixes, including one that mirrors Trad play. From here, the Players through whatever means ("The Conversation" as PBTA games use) then interact with the Game State, and are permitted effectively unlimited Actions. There is no strict limit on what can be done mechanically. (To Do It, Do It)Some Actions, however, Trigger a feedback response. What counts as a trigger is typically established alongside the initial game state, and the game rules itself typically establish many of these. (Moves being the most common in PBTA. Yes,And et al are simpler forms of it; prescriptive abilities and certain rules in trad games a more complex version)The feedback then gets resolved, and integrates with the previous game state to form a new one. This then repeats until the game is considered over.  Broke down this way, it should be really apparent why I keep saying what we're talking about is an improv game.</blockquote>

Verification