Pulling the thread of quest rules
The spring months were not merciful on me - struggling with health issues, I could barely focus on any non-critical priorities.
Despite that, I found courage and energy to visit a workshop about quest making from narrative perspective led by John Ryan. Now when some time passed, I suspect workshop had a narrative designer's trick to it that turned me from a passive listener into an active participant without me even noticing. But that could be its own bednight story - about missing relatives and lava crabs.
This time I want to focus on theory that John presented to us, and my thoughts about it.
Main rules of a good quest are following:
After quest player should know something new
Reward for quest should be compared to complexity of challenge
Quest should have a valid explanation of why only player can do the task
Quest shouldn’t break the rules of main story line
These guidelines felt so natural and obvious to me that it made me look for the reasons why. I started to think - what if we already have quests developing in software engineering and it is every new feature?
It should not contradict core domain.
It should bring new knowledge (new functionality).
It is normally also not logical or not possible to be done with any other hero/domain.
Its implementation effort should correlate with functionality.
May it be a bit more boring than creating a line that involves lava crabs, it still follows same set of system rules.
So if i try to marry those 2 worlds, a good feature should: have a proper ROI compared to risk, enable something new, have a justification on selected path and not break existing functionality.
Im still trying to think of it even on broader spectrum, and I suspect systems thinking already formalizes this across disciplines, but I haven't got that deep yet. So.. To be continued?..
Comments
Post a Comment