Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="kenada" data-source="post: 9244654" data-attributes="member: 70468">As I noted in <a href="https://www.enworld.org/threads/a-neotrad-ttrpg-design-manifesto.701957/post-9243590" target="_blank">post #400</a>, I’ve been using MDA and DDE interchangeably because DDE positions itself as a reformulation of MDA, but there are things DDE includes beyond what MDA does. As I indicated in <a href="https://www.enworld.org/threads/a-neotrad-ttrpg-design-manifesto.701957/page-27#post-9240017" target="_blank">post #266</a>, I like DDE more than MDA as far as these frameworks go. I’ve been trying to signal that by shifting my language away from mechanics and aesthetics to design and experiences.What you are describing are processes for changing the game state — algorithms. Given a game state S (consisting of these boxes full of physical things at the table and clouds full of fictional ideas in the minds of the participants), perform these activities to create game state S′, which may involve manipulating things in the boxes or devising new ideas in the clouds (using imagination, naturally). Those seeds you propose are data. They would set an initial state S₀, which the players would then change via application of the processes of play.DDE expands design to include blueprints (of the setting, its rules, characters, etc) and interface, but I don’t thinks those are strictly necessary to capture this aspect of tabletop RPG play. It just feels more natural to call them design rather than mechanics, especially in non-digital games like tabletop RPGs where “mechanics” already has a particular connotation that does not match with how the MDA framework is using it.I misunderstood and thought you were talking about something else. See above for my attempted reconciliation.</blockquote>

Verification