Andor's Trail

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).

Good ideaand great post! This would make AT a lot more realistic!
But I think we should not remove the possiblity of using a queststage key because it's sometimes just magic which prevents you from moving further.

Anyways, I gonna bring this up in the project meeting.

Ian wrote: But I think we should not remove the possiblity of using a queststage key because it's sometimes just magic which prevents you from moving further.

Anyways, I gonna bring this up in the project meeting.

Thanks. I'll try to code it against the current master branch and submit a pull request asap. Hopefully this weekend.

Edit : I'm a feature freak and a conservative coder. There's no way I'll remove a feature or break retro compatibility on purpose !

Excellent suggestion! A big +1 from me on this idea!

Code is written. I am waiting for the emulator to launch to test it. However, there's a sister feature that seem necessary.

When using the "inventory remove" type of requirement (you need an amount of a given item, and it will be removed once selecting the reply or entering the key area), for it to be usefull with quest items, we need to include the "object" layers in the "replace" feature : that is, be able to replace to "key", "spawn", "mapchange" and other object layers using "replace" objects like for the graphics layers. I'll code that too before submitting a pull request.

Edit : I also added the requirement to be at an exact quest stage (no further stage ID must have been reached). Code is tested and commited to my github fork as branch "key_areas_use_requirements".

Edit 2 : Actually, to separate the features in different pull requests, I'll make another branch for the "replace object layers" feature.

Wow, sounds great! I'm really looking forward to using this new feature!

About the new features of replace: That's exactly I was thinking about when Oskar introduced the replace feature! I would be so glad if you made this happen! We could spawn monsters out of nowhere and many other things.

Man, you're awesome!

Excellent Work!!!

I've a few ideas already for some neat ways to use this set up. =)

Nice job Z! =)

Thanks guys for the warm feedback !
If you wanna try the new key requirements, you can check out my code on github.
To use it, name your key areas that way : req_type:req_id:value
Value is an int.
Req_type is one of the following :
qp : Classical quest progress with quest stage as value and quest ID as req_id
ql : same but player must not have reached a further stage
ik : invetory keep. Need value amount of req_type item in inventory. Will not be removed.
ir : inventory remove. Same but item will be removed from inventory.
iw : item worn. Player must wear value amount of req_type item
sl : skill level. Player must have reached level value of skill req_type.
km : killed monster. Player must have killed value monsters with ID req_type.
cl : consumed less. Player usage of a item with ID req_type must be less than or equals to value.
cm : consumed more. Player usage of a item with ID req_type must be more than or equals to value.
bl : consumed less. Player usage of bonemeals must be less than or equals to value. Use anything as req_type, even nothing, but two ':' must be present : "bl::30" or "bl:bonemeals:10" or "bl:blahblah:0" should all be valid).
bm : consumed less. Player usage of bonemeals must be more than or equals to value. Same comment as "bl".

Pull request was sent.
I'll get to the object replace ASAP...
Enjoy !

New Requirements types added to previous post :
- Item usage less than or more than. Player need to have used (consumed) a given item less or more than a certain amount of times.
- Special case for bonemeals, as we now have several items that qualify as bonemeals !

Edit : note that the cl & cm types are comptible with gold spent requirement ! Maybe an ill intended gambler can offer a quest to players that already spent big money, thinking he can trick us...

YES!!!!!!!

Thank you Zuk!! I cannot wait to see someone use these in quests and areas in the updates to come.

I now have a million ideas!!!!!

You are the best!!!