More flexible "key" type areas.
Posted: Fri Sep 20, 2013 11:38 am
Hi,
This post is intended for map & quest makers, as well as people familiar with the AT java code.
Looking at the code, I believe we missed some opportunities to reuse code AND enhance game engine possibilities at the same time.
The first one is about the "key" area type in the maps.
The TMX parser uses the area name in the form "quest_name:quest_stage" to prevent access to players that have not reached this quest's stage.
The conversations use a somewhat similar feature to prevent access to some replies, but these restrictions can be made on item possession (removed afterwards, or not), worn item, skill level, monster killed as well as quest progress.
Why not reuse this "Requirement" class from the conversation package to represent the "key" area requirement ?
I see two ways to do it :
- Make "Requirement" a top-level item in the content editor, and reference it by ID in the replies conditions (simple script should be able to retro-fit the existing ones).
- Extend the area name syntax to cover all sorts of possible Requirements : (for example : "ir:item_key:1" for item possession with removal requirement, 1 being the quantity required and removed). All would use two colons ":" in the text, to keep the current 1-colon format for quest requirement (retro-compatibility), but advocate the use of "q:questname:stage" for upcoming maps. <-- Favorite. Less impacts, less work for content creators.
Moreover, in the code, move "Requirement" class from conversation package to model package, and give it two public methods :
public boolean canFulfillRequirement(Player p) : checks if player matches the requirement.
public void requirementFulfilled(Player p) : apply post effects (only item removal for now, but who knows).
The engine could then use these methods anywhere a requirement check is needed (ConversationController.canSelectReply() & MapController.canEnterKeyArea() so far).
This post is intended for map & quest makers, as well as people familiar with the AT java code.
Looking at the code, I believe we missed some opportunities to reuse code AND enhance game engine possibilities at the same time.
The first one is about the "key" area type in the maps.
The TMX parser uses the area name in the form "quest_name:quest_stage" to prevent access to players that have not reached this quest's stage.
The conversations use a somewhat similar feature to prevent access to some replies, but these restrictions can be made on item possession (removed afterwards, or not), worn item, skill level, monster killed as well as quest progress.
Why not reuse this "Requirement" class from the conversation package to represent the "key" area requirement ?
I see two ways to do it :
- Make "Requirement" a top-level item in the content editor, and reference it by ID in the replies conditions (simple script should be able to retro-fit the existing ones).
- Extend the area name syntax to cover all sorts of possible Requirements : (for example : "ir:item_key:1" for item possession with removal requirement, 1 being the quantity required and removed). All would use two colons ":" in the text, to keep the current 1-colon format for quest requirement (retro-compatibility), but advocate the use of "q:questname:stage" for upcoming maps. <-- Favorite. Less impacts, less work for content creators.
Moreover, in the code, move "Requirement" class from conversation package to model package, and give it two public methods :
public boolean canFulfillRequirement(Player p) : checks if player matches the requirement.
public void requirementFulfilled(Player p) : apply post effects (only item removal for now, but who knows).
The engine could then use these methods anywhere a requirement check is needed (ConversationController.canSelectReply() & MapController.canEnterKeyArea() so far).