I don't know if there is an exact rule to this, but can it debated whether if it is easier to design write a quest and then program it, or program it and then write it?

What you would probably want to do is:

1. Brainstorm a crapload of quests.
2. Group the ideas by how they would be programmed.
3. Eliminate or rework anything too hard to program.
4. One at a time, start programming the different functions needed.
5. While the programmer is doing that, the writer can do the detailed writing for each quest where all necessary functions are already programmed.
6. Brainstorm again to fill in any holes, and try to combine existing functions in new ways or make minor variations on existing functions to increase gameplay diversity while keeping programming to a minimum.
7. Implement function variations and additional quests.
8. Have a playtester check each quest including proofreading any dialogue or other text seen by the player.

Quote: Original post by sunandshadow
1. Brainstorm a crapload of quests.

I would rather brainstorm about what types of quests that should be in the game...

Killing, delivering, exploring, spying... a.s.o.

Trying to make the quests themselves would be stupid to get to know how to structure the code.


Quests should be a way of letting the player to take part in a story and shouldn't be used to just give the player a reason for killing creatures, gaining experience or what not.

Gaining Experience, this is a really distorted expression in the MMO business.
Okey, you need get towards a goal, gaining a level by gaining experience, np.
The problem is that EVERY MMO gives you experience for repeatedly slaughtering the same kind of mobs. After killing about 100 mobs of this kind, you should know how to kill them by now.. The thing all new MMO makers should have in the back of their head is to eliminate all kind of continuous grinding to achieve experience. Break this trend how to base MMO's and start being innovative.

Molle, if you look at my point 2, I was using the list of specific quests to extract the list of types of quests from. I was trying to work with the fact that its human nature to find it much easier to think of a list of concrete things than a list of abstract ones. One could also substitute the brainstorming in 1 with making a list of favorite quests in other games, then insert a step to brainstorm for specific quests as 3.5.

Quote: Original post by sunandshadow
I was trying to work with the fact that its human nature to find it much easier to think of a list of concrete things than a list of abstract ones.

I said it was better to make a list of types of quests, this has nothing to do with how you come up with these items, I'm not saying you shouldn't come up with them by putting them in a concrete example, in fact I recommend it.

Wasting time and effort trying to think up as many quests as you can probably leads to that the list gets shorter than expected, most of the items are of the same type and you risk of losing the focus of what this list is for.

The focus in mind should be; we are trying to build a system, what should it support ?

Quote: Original post by sunandshadow
One could also substitute the brainstorming in 1 with making a list of favorite quests in other games...

You could, but why ? You can just as well be making a list of the types and discus about those quests, what types they are and why they were fun. Listing the quests themselves is irrelevant.
Also you should try to be innovative and not just copying from existing games.

[Edited by - Molle85 on June 15, 2008 2:48:37 PM]

The 'why' is that if someone just sits and tries to make a list of abstract types of quests, they are not going to be able to think of very many. But it is much easier to remember or research specific quests and then analyze them to see what type they are to get a more thorough list of quest types. Being innovative has to start with understanding what others have already done and then adding to it, not trying to avoid everything that has already been done.

not trying to avoid everything that has already been done, but avoiding the mistakes they've done.