I'm against parsing the requirements like this. I think it feels like more of a hack to prefix them with an abbreviation and then encoding the content in the sting like we do. I actually think the *current* way if using e.g. ```quest:10``` also is a hack, if that's any comfort, @Zukero :)

For us coders, it's a really easy way, and we can probably either figure out or remember what the abbreviations mean, and the way that we encode a whole requirement into a string like this. For the content creators, it's however really important that it's easy, and most of all easy to understand.

Other ways of representing requirements that would be more explicit:
* Use a whole conversation phrase id as both indicator for what phrase to display , and to evaluate whether the key area can be entered or not. This could be done by running the conversation using the headless script runner ( 5136a7cab03b7a57a8f1fca973dc3da7cf40c0e5 ) until it either hits a conversation (=key area cannot be entered), or it exits the conversation (=key area can be entered).
* Change key area name in the TMX file to contain the phrase id to be displayed, instead of it being in the ```phraseID``` property. Add property ```requireType``` in Tiled to the key area to indicate which type of requirement this area is (could probably reuse the definitions in ```RequirementType```), and add properties to indicate the ```requireID``` and ```value```.