Mud area quest / goal conversion update.

With 9 of these now on live, 7 ready to come live and about 20 more in progress I figured it was time for an update. The goal system itself has been very well received, it solved a common question of “well, there’s so many options, what do I do next?”. Once the area themselves are done, it also opens up the potential to develop real mud-wide and long term quests.

In many ways, these are harder than converting everything to Lua was. The conversion to Lua had a very well defined outcome for each prog that was converted – it should do the same as it did in ROM mobprogs with the exception being some of those issues that were fixed by additional options in Lua.

The goals system requires a deep understanding of the level in question then deciding how best to lay out the tasks. Once that is done, you have to figure out the ways people might break the tasks then once testers get at it, each area has a few crazy day of lots of posts/fixes to be made. More on this can be seen at the original “conversion to goals” walkthrough.

Some enhancements are still needed to the goal interface itself, but for the most part the addition of the help files for each area that has a goal is answering most of the questions people have – other than how to solve the quests themselves that is.

While reviewing the areas converted so far, we’ve found some common mistakes on style and created a list for other area converters to watch out for. While these are about the goal conversion, they can easily apply to any kind of area design in general. Posting them to the blog will make them more accessible to people while they work on the area conversions:

1. Paths to solving?:

In general, dont make finding a goal itself be a big puzzle. Within an area the clues can be obscure (see ft2), but they MUST be there, somewhere. Don’t assume the player knows Aardwolf and will automatically try things such as ‘listen’ that an experienced player would. This is why the lower level call of heroes etc say “blah blah blah. Perhaps you should listen to him?”

If a task requires a player to figure out how to do something, don’t make them also play a game of “guess the syntax”. If I have to feed a dragon to get to the next step, don’t make “feed the elf to the dragon” or some other obscure syntax be the only thing that works. I would be able to give the food, or just type “feed dragon”. If you have a “push button” trigger, make “press button” work too. It takes 10 extra seconds.

2. Hanging Items/Tasks:

You might have one task that gives an item and the next task assumes the player must have the item. This may not be true, items can be lost in all kinds of ways and while saying “Dont lose it!” is useful advice, it doesn’t help if someone now has a goal that is uncompletable, ever.

There has to be a way around this. If you want to make it so that not having the item means they have to start over, fine. If you want to make it harder to get the item a second time, fine. But it needs to be possible. If items are being used to mark some event, remember you can also use taskflags.

Sometimes players need to figure out the correct mob to give an item to. For example, in the first version of Siren’s Oasis resort, you had to find the right contestant, but giving the quest item to the wrong one meant they just kept it. Not a big deal if the mob can just be killed to get it back, but nokill mobs or mobs much bigger than the general level of the area will need to have a give trigger for ‘all’ that returns the item.

3. Say Vs Sayto:

By far the most common error is sending messages intended for the character triggering a script to the entire room. This is probably because it was widespread in old mobprogs, but they should be cleaned up as we work through the area for lua. For example:

say("Well done "..ch.name.."!")

Anyone else in the room would see this. When a say is directed at the player, use:

sayto(ch,"Well done "..ch.name..!")

The same problem occurs a lot with emote. Instead of using:

emote(" thanks you for your help!")

Which everyone in the room would see, use:

echoat(ch,"$n thanks you for your help!",LP_CAPS)

4. Visibility:

Make sure that mobs opening goals have all detects and are nomove. In most cases they should also be nodamage/nokill. You may also need to make mobs that give/close tasks also have detects. You do not have to make these nokill, but consider the flow of your quest overall and how a mob being killed might affect it.

In lower level quests in particular, checking if a mob is alive in the game somewhere (mobexists) and giving a different message to the player may be necessary.

5. Bottable Items:

The counter to #3. Watch out for situations where items can be repeatedly gotten over and over very easily, particularly if they have any value for sale to a store etc. If an item has value only as part of an AQ, you might want to consider putting an appropriately long timer on it using:

obj.timer = 3600 — seconds, this would be an hour.

6. General cosmetics:

A number of scripts had to be cleared up where there were echos over 80 characters that don’t wrap nicely in a client that autowraps. If you have 3 lines 100 characters long each, they’re going to look ugly: 80 char line,
then a 20 char line, then an 80 char line, etc.

Put spaces in the output where it makes sense and unless it really breaks the look of the area, combine multiple says/saytos into a single one.

With the academy, a lot of the time spent on it was probably in this, but it really does make an important overall difference.

Likewise, if a mob’s script talks about waiting a while before doing something (example … a few minutes later the king returns with…), put a pause in there.

7. Flooding Inventory / Abusing nokill mobs:

Giving/receiving items play a huge role in AQs. If the mob is questable, killable and part of an receive/give prog, then the received item should be purged/destroyed when prog fires. If the mob is nokill, then its inventory shouldnt be floodable. It also should not be used as a storage such that one can give it items, log out and log in alt to steal it back from the mob.

Those are the most common issues so far. Avoid these and if your quest works at all, it will probably have a pretty easy ride through testing. None of these are overly complex, but combined really make a difference to the overall feel of an area quest.