Redesigning the Quest Department: A proposal

[Rats]

[Adanorcil]

Agreed on all points. Bring this to the next meeting for sure.

[arvisrend]

Kudos for the good ideas, Rats and IP.

Just a remark on 2): The focus needs to be on encouraging NPCers to make quests, not requiring them to. The latter used to be TR's modus operandi before SE, and it led to NPCing being the most unpopular job ever.

About 3): yeah, that's something we can hopefully do with our recruitment post. And by re-releasing map 4 (including existing quests) we might even solicit showcases that are usable as they are (like Rats' second one). Very nice idea to put quest designs out in the wild so that people can showcase just by implementing (which, IMHO, is the far harder part, at least when it involves dialogue).

[immortal_pigs]

When I made NPC claims back in the day there were some issues I stumbled across. I was frustrated about the lack of guidelines when going to work. To emulate Rats' problem, solution formula:

Problem
What is the difficulty of the region? And what is the fauna of the region? Can I just randomly drop Atronach's? Probably not, but there were no guidelines.

Solution
Arvisrend's thread on difficulty in HH. Why not grab a map of Morrowind and decide right now how difficulty will be spread across Morrowind. Why not pre-decide the fauna of a region and how it will be spread? Why not pre-design specific fauna packs for different regions? We could emulate Sload's Tiers formula for this by creating difficulty Tiers.

Problem
What is the population of the region? When I was detailing Sailen I had no idea how many slaves I should drop in the region. I did not know what the demographics should be. Should it be 80% dunmer, 20% foreign? Should it be 100% dunmer? I don't know.

Solution
Grab a map of Morrowind and pre-decide how the demographics will be spread per region. For example more Argonians in the Dres regions and more High Elves in the Telvannis regions.

Problem
What's the story of the region I'm populating? What's going on? Is it war-torn? Is it idyllic? Are my people poor and famined or rich and prosporous? I have no idea so I have to create guidelines for myself. In the big picture this leads to pockets of isolated NPC claims which are completely oblivious to each other and have no sense of consistency.

Solution
Why not start with story first, figure out the dynamics of a region, before opening up the claim for NPC'ing?

Problem
What are the clothing styles of my region? What are the family names of my region? What are the cultural trends of my region? I have no idea so I just randomly drop stuff and hope it makes sense. But I'd like to have guidelines.

Solution
Why not think about the clothing of a culture? Why not think about the onomasticon of a Great House or a culture or a region. An onomasticon is a list of last names. If you look in the CS you can easily organise NPCs by last name, that way you can have a consistent set of last names for Redoran NPCs for example. Why not start with a predecided set of cultural elements, items and themes that are featured in a certain NPC claim before opening it up for claiming.

[immortal_pigs]

The underlying problem is that we questers are bound by a bottom-up structure as opposed to a top-down design.

It's Exteriors First > Interiors Second > NPC Detailing Third > Quest Design Fourth > Scripting Last. The problem is that we're constrained by what we get to work with.

The way it ought to be, and the way I imagine a professional game studio would approach it, is this way:
Design Philosophy > Storytelling > World Building > World Implementing.

You start with an abstract design philosophy. The Lore Posse could help in this department by creating guidelines to what is lore-friendly. Ideas like "less is more". Threads like "Four Principles of Lore".

Next comes the storytelling. What are the stories we want to tell? What are the overarching themes of this world?

Next comes worldbuilding. What will the questlines be? Which factions will we include? How do they relate to each other? Where do they live? What are their cities? What is their geography? What kind of people live in these lands? What is their culture? What is their history?

Finally you can finish by creating a physical representation of this world with the CS. You can make the exteriors real and make the interiors based on predecided guidelines. You can start to implement the quests and create NPCs in a way that is consistent and consequent.

[Swiftoak]

^ So much this.

I have no words but to say that the post above couldn't be any closer to the truth. Our fundamental design philosophy is flawed. We need to fix this. This requires a fundamental shift of thinking, but it also requies a great deal of will and discipline to make that shift and act upon it. I have been trying to think of strategies in which we can move towards this direction, but I think movement on this would be difficult, considering the current status quo. Although I feel this is a big issue, others might not feel the same way, and shifting the way we think about this will again, require alot of discipline and willpower, and I fear we might not have that right now. One thing at a time.

[immortal_pigs]

To comment on the gameplay aspect of questing:

Morrowind is still a game which is about training skills, growing your level, accumulating shiny items, acquiring ranks in guilds, learning new spells, crafting alchemy and making bountiful amounts of cashmoney.

Because collaborative thinking is probably in order for this aspect of design I've made a document in Google drives which should be open to anyone to edit. The main purpose is to introduce more standardization and guidelines into this aspect of modding.

https://docs.google.com/document/d/1zFu ... uGgdo/edit

Or, if you prefer a more general list.

https://docs.google.com/spreadsheet/ccc ... sp=sharing

[Why]

Dropping by to say I very much agree with the points raised here. Back before I took my unannounced sabbatical, I tried to overcome this problem of design priorities by being an annoying little shit and involving myself heavily in concepting for the new regions and exteriors, but that was far from ideal - it only helped in the sense that my own ideas for the project would be taken into account, a far cry from an actual organised and collaborative creative process, and that is indeed what we need more of.

Bear with me while I continue to catch up on recent developments. I'll try to say more about more, soon.

[Sload]

TR's workflow is totally fucked right now and it sounds like just about everyone has come around to that reality. However, this also has some very negative impact on implementing major questlines that I think haven't been perceived in this thread. Even ignoring the way they are pinned down by being the last content to be produced, questlines are underwhelming for lack of preproduction. Questlines in Morrowind, though different in individual elements, all develop similar themes and arcs, creating a consistent narrative experience despite the forking path of the open world gameplay. TR's questlines are scattershot at best because there are not the built-in parallels of the original game.

Just as the world needs to be designed before production to be a good foundation for gameplay, larger quests need to be preproduced to actually be good gameplay. In my opinion, TR's present stage of development is only appropriate for the creation of short miscellaneous quests & possibly location specific questlines on which the narrative drive of the game does not reside.

I may have made a thread along these lines a few months ago.

[Gnomey]

I agree with every post in this thread.

1. I do have an idea relating to Rat's points about faction quests, though: I actually think that an approach similar to the Focused Sketch Group could work for most questlines. Basically, as a first step to making a questline, a thread is opened on the forums, probably in Lore & Quest Discussion. TR members could then brainstorm various general ideas about the questline, such as important NPCs and the overall direction of the questline, without going into too much detail. Once we have a lot of ideas to work with, that thread is locked.

At that point, the small team is organized. That team would do the actual quest design and such as described by Rats. The locked thread would only serve as a resource for ideas, much like a lot of the concepts in the FSGs will probably never be made.

The goal would be to preserve the valuable parts of public discussion, namely the brainstorming, while leaving the final design and implementation to a small team. Naturally, that approach works best if there is no hurry to finish the questline. If there is a hurry, it would be better to simply leave it to the small team, but then again it is probably not a good idea to design and implement questlines in a hurry, especially considering the importance of pre-planning as pointed out by Sload.

2. I'd certainly agree with arvisrend's post that NPCers making misc. quests should be encouraged, but not required. Generally any quest showcases incorporated into the mod would be misc. quests, and misc. quests are also well-suited for questers who don't feel they have the time and energy to work on a full faction. (Or for those times when there are no full factions to claim).

I would say that misc. quests, rather than having to meet a certain quota, can just be incorporated into the mod as they are made. While there would ideally already be a few NPCer-made misc quests in the first release, I think it is only really when (if) this project gets done that we'd need to look at the distribution of misc quests and ask whether we need more in certain areas.
In my opinion misc. quests are better suited to being made when a good idea pops up rather than creating a set number for a set location.

3. As an exterior and interior modder, I'd especially like to give a nod to immortal_pigs' posts on planning. While he was mainly addressing NPCers, a lot of those points are very applicable to interior and exterior modding. TR has already improved its claim descriptions a lot; the heightmap certainly helps. I'm not sure if the heightmap takes travel services into account, though. (I'm assuming Uld Vraech won't have Siltstriders? Is it going to have any sort of over-land transportation?)
What the heightmap isn't able to cover are questions such as what clothing is worn, any notable cultural trends or demographics (how strong is worship of the Tribunal, for instance; how traditional are the Dunmer; how rich are the rich, how poor are the poor), and, for a large part, fauna. The Map 5 heightmap included the Bloodmoon trees, for instance, but, as far as the smaller flora was concerned, I needed to reference neighbouring claims.
I didn't exactly find that a great chore, but I was worried that it could lead to inconsistencies down the line, which would make for unnecessary work and confusion. [url=http://tamriel-rebuilt.org/old_forum/viewtopic.php?t=24198]This interior claim[/url] shows the problem rather well. Houses and NPCs in the Uld Vraech region and near the Velothi Mountains should probably lean more towards warm clothing, and that modder had the foresight to ponder that question. Unless directed by the claim description, a lot of modders probably wouldn't think about the issue, and might give a Redoran house in Uld Vraech the same clothing you'd find in Ald-ruhn. The greater problem arises in the sum of those interiors, where the one house will be full of furs and wool while the next has short-sleeved vanilla clothing and skirts. That's not the sort of problem that is hard to fix, granted, but why should we need to?

Edit: d'oh, I see I'm late for a few of my points. Edited to reflect the fact.

[Theo]

So... I know I have not been very active in the quest department recently, but I have watched some inspiring youtube videos by professional game designers some time ago and though to myself: Hey! Maybe this process could work pretty well for TR as well. So I dare to brought you some ideas and suggestions for public discussion to see if they are of any value or are completely irelevant.

Also I will probably just restate what is already a common practice on many point, in this case please be patient, as I want to present a whole picture, rathen than just a chaotic bunch of propsed changes.

I believe we need more stages in the quest design/implementation process. Namely:
1) Quest planning 2) Quest Design 3) Technical design 4) Implementation + Alpha testing 5) "Blackbox" Beta-testing

with reviewers steping in before transitions from each point to the next (With the exception of the last step, obviously).

Point 3) is actually the only new step I want to introduce, but this will also affect mostly points 2 and 4 too and to a certain degree points 1 and 5.

So to explain in a detail what I mean:

1) Quest idea/synopsis is proposed, preferably by some developer familiar with NPCs and interiors in a local area/settlement. (Maybe a lead developer? Discuss...) Optimally such ideas should be proposed in batches for miscellaneous quests, to make sure quests are evenly distributed among NPCs in the area of question. Ideally a whole region should be considered.
This person provides a list of NPCs and locations that should be involved in the quest and some key elements and events that should occur. In case of faction quests a general theme of the story should also be proposed.

This so, far is a current practice, but I would like to alter it only a bit so that the synopsis should not be too detailed as it often is now and should leave a lot of place for quest designers creativity for two obvious reasons:

A) The designer should be rewarded by some creative involvement in the process for his tedious efforts.

B) Many insignificant details of the quest may prove to be unnecessary complication for the actual implementation.
It should be up to designer to finalize the quest idea to such a shape, that its implementation was not too complicated for petty reasons, which the proposer of the original idea forgot to consider or think through.

After a general discussion (does this quest fit well with the design document? Doesn't it conflict with other quests? Does it fit a blank and boring space or does it add to already well quested area? Is the idea fun and innovative and doable?), the quest design claim is created.

2) Someone claims the quest design. By the end of the design process he should provide a flowchart of the quest. I believe any developer should be able to do this, he does not even have to be strong with implementation.
A good quest design can be recognized immediately, as it will not be just a single line of chained events, but will contain some branches and choices, while also specifying what the results of this choices should be.
The need to create this chart will eliminate many half-baked and sickly quest ideas from becoming a regular quest claims.
You can check a flowchart I made for q2-16-Mis as an example, but there is no reason not to use any other form, in case such flowchart meets some basic criteria.
Later I would like to create a list of guidelines, common practices and howtos for such design and it may be stickied in relevant forum later, if this idea gets general acceptance.

During the process various versions of the flowchart can be subjected to critique mainly by quest reviewers and possibly a person interested in claiming the implementation, but basically by anybody with reasonable concerns.

This is a good place to ask questions like: What does happen if you kill XY, after speaking with AB, but before bringing item Z to CD? Is not that reward too high?
Wouldnt it be nice if at stage S a player could turn a cloak and betray AB to XY? etc.

After all concerns are addressed a finalized flowchart is turned into a technical design claim.

3) Another person claims the quest and provides technical design. This person should be already quite competent with CS implementation and scripting. The goal of the technical design is to make sure that all events occur correctly, but mainly that each journal node is accesible from and ONLY FROM preceding journal nodes.

Now at this point he could implement the quest right away, but I am still suggesting one intermediate stage, which is production of dialogue spreadsheet and script documents.
Again you can check a dialog spreadsheet i made for q2-16-Mis.
The dialogue spreadsheet does only need to contain placeholder dialogue, but it should be evident how it manages to realize the flow designed in the quest flowchart.
Someone competent with English language and lore can claim it and write the actual dialogue using this chart as an template, breathing some personality to the characters and story to the plot.

Again these documents can be reviewed very quickly by reviewers and may have several versions. Some may argue this is a duplication of the work, but I believe it is much more efficient to have a clear idea from the beginning how things will be done and for reviewers it is also good to have a clear idea what was the intended implementation and where did it go wrong.

Of course, if the technical design is buggy from the start it is easy to point this out during the design process, without someone having to continously review the process of implementation in CS.

4) After dialog and script documents are approved, the implementation is actually quite mechanical copy paste process. I believe anyone willing to do this should also be asked to playtest the quest and make sure the implementation works, making minor adjustments during on the run as needed, as there will alwyas be bugs. This should also be a person with some technical knowledge of CS, but it does not necessarily have to be the quest designer.

5) The beta-testing should now consist only in black-box testing and should be done by someone, who had absolutely no part in the whole design process. He will have no insider preconception how the quest was intended to work and will approach it from the perspective of a gamer, with his expectations how it should work.
If any bugs are found at this stage (most of the implementation bugs should be already removed in phases 3 and 4, so we are talking mainly design bugs) the quest wil have to be redesigned and remade, but this should occur only very rarely.
This beta testing can be left to the community of gamers, but having a dedicated playtesters with a good understanding of the game mechanics never harms.

So now you are probably asking? Why should we add more processes in a situation, when we are currently low on people capable of implementing quests?
I see several advantages of such multi-staged process, which I am going to list:

A) Efficient work division.
Quest design and implementation process may simply be quite a big task for one person to deal with, which may discourage many people from doing that.
By dividing the work into smaller manageable bits, we enable more people to participate.
Some people could be more than able to design the quest in a flowchart, yet somehow feel weak at dialog or scripting.
Others are willing to write scripts, but without a knowledge what will be handled by dialog they may end up doing superflous work.

B) More effective reviewing process and greater transparency of the development process.
The need for a technical design introduces a lot of new work, but makes the task significantly easier for a reviewer and for a person to implement and alpha-test the quest as they already know the intended functionality in advance.
Also it is more efficient to detect possible design flaws already in the documents, than to open the quest in CS each time and list through all the possible entries.
Also more people can participate in the reviewing, without having to wait for the file. Last but not least, many bugs and shortcomings could be detected already on the design stage and amended without having to redo anything signigicant in the CS.

C) Potential to include more people in the process and encourage them to acquire new skills.
Right now creation of quest is for many people some mystical ritual happening behind the curtain, performed only by the gifted ones.
By enabling them to observe or even participate in the process of creating technical design, we may tutor them or to encourage them to learn to create quests themselves so to speak from top to bottom.

D) Greater diversity of quests.
If each developer receives an input and set of tasks from another developer on a level above and leaves some clues for a developer on a level below, it will be reflected in a greater variety of quests.
On each stage you can influence and create certain aspects of the quests and insert some fresh perspective and creativity.