NOW LIVE! Today's the day you meet your new best friend. You don’t have to leave Wolfy behind... In 'Pets & Sidekicks' your companions level up with you!

Reply to thread

Message: <blockquote data-quote="kenada" data-source="post: 9239286" data-attributes="member: 70468">I’ve rearranged things a bit because these seem related, but I think we are too. I view game design as fundamentally about engineering. You are creating something with a purpose (for play). There are a lot of ideas about how to do that well (and to understand how well you are doing it), which I think is where your interests lie, but once you sit down to make something, it’s all about applying those ideas to make something fun.When I see a design manifesto, I see it in that context. It reads like it’s going to be a document or methodology that will prescribe a particular approach to making games. Per the particular exchange I was having with [USER=6690965]@Pedantic[/USER] in <a href="https://www.enworld.org/threads/a-neotrad-ttrpg-design-manifesto.701957/post-9237629" target="_blank">post #189</a>, we were discussing the idea of its providing a set of questions to help you understand which design to use. I have two issues with that:<ol> <li data-xf-list-type="ol">It feels like coming at the problem backwards. We want the GM to have this amount of authority or the players to have that, or we want to use this kind of resolution process. You should already know what you are designing by the time you get there. It’s like devising a bunch of dice mechanics and then trying to figure out what RPG you just made.</li> <li data-xf-list-type="ol">It feels rigid. My litmus test is anything that would have told me to design something other than what I am doing is wrong, and I fear it would do that. “Neotrad” is often associated with OC play, so if the questions are biased around that, one may get pointed in the wrong direction. The mechanics incorporated in the manifesto are actually broadly applicable.</li> </ol>What about tabletop RPGs makes them incompatible with the framework proposed in the <a href="https://www.cs.northwestern.edu/~hunicke/MDA.pdf" target="_blank">MDA paper</a>? You’re not going to get the exact same sort of discourse, but that’s not really the point.Works perfectly fine. I’ve been on projects that had to work cross-functionally with teams that had other responsibilities, their own processes and schedules. We delivered. You identify that dependency, and you work with it the best you can. One of the important aspects of agile is communication. You are constantly communicating, which helps you understand where things are and when a blocker risks causing problems.There’s a lot of agile-industrial complex BS out there. They want to sell you on consultants or tools or silver bullets, and it’s almost all garbage. The actual <a href="http://agilemanifesto.org" target="_blank">agile manifesto</a> is pretty succinct, and it works, but you need to believe in it and embody it. I really enjoyed <a href="https://richardsheridan.com/books/joy-inc" target="_blank">Joy Inc by Rich Sheridan</a> because it talks about agile in practice using actual teams as his consultancy and how they worked effectively.That comes down to the specifics of the model. As I noted, I haven’t actually devised dynamics and aesthetics models for my homebrew system. It’s something this thread has got me considering, but I haven’t done it. I think you’d need to define what is meant about an emergent story and how that would be “measured”. My intuition is it won’t look like a traditional narrative, but I don’t think you can get that without curation.An emergent story might be the product of taking a sequence of events and recounting it in a more traditional structure. Maybe something like a <a href="https://www.enworld.org/threads/games-as-story-machines.699578/" target="_blank">story machine</a>. If people could see fit to do replays or tales like <a href="https://dwarffortresswiki.org/index.php/Bloodline:Boatmurdered" target="_blank">Dwarf Fortress</a>, I’d call that a major success. That’s not truly needed. If they just recount to each other the various fun things that happened like they’re talking about some other story, that’s enough success.The easiest way to answer that question is to try it and see how it goes. The purpose of creating dynamics and aesthetics models is to have a way to evaluate how your design worked. Maybe using technology works great, or maybe it’s horrible, or maybe it’s neutral. No amount of thinking about it beats just going out and doing it.The clouds are the fiction. The boxes are mechanics. If imagination is a mechanic, it would be a box not in the clouds.I have a few answers for that.The first is (and one people may not like): don’t do that. The fun police aren’t going to confiscate your dice, but the game is intended to be played as written. Otherwise, all you’ve got is 2d6+mods in a fantasy milieu, which is nothing exciting. There are plenty of games out there, and people should play those that do what they want.In a more practical sense, I’d like to include a commentary explaining the hows and whys of why things are designed the way they are. If you want to hack the system, that should help give you an understanding when making changes. In the text itself, I want to address certain points that can result in potential misplays.Once you’ve settled on what you want to create, you have to respect the scope of what you are creating. Other ways of playing or other aesthetics are out of scope, so they should not be a factor. If you don’t respect that, then you put your project at risk. It would also make me question why even have a process at that point.</blockquote>

Verification