Story and Plot Design - Revision history

Petike: /* See also */ update

2019-12-03T02:08:34Z

Petike: /* Further Discussion of Narrative Design */ update

2019-02-20T08:34:16Z

Further Discussion of Narrative Design: update

← Older revision		Revision as of 08:34, 20 February 2019
Line 316:		Line 316:

	'''[http://forums.thedarkmod.com/topic/16923-story-plot-and-narrative-design-discussion-thread/ Story, Plot and Narrative Design Discussion Thread]''' - To seek further advice and discussion on plotting, story and narrative, you can also visit this discussion thread. It's open to all, at any time, always. Whenever one has "writer's block" while designing a mission's narrative and how it'll fit into gameplay, he/she should feel free to visit the discussion.		'''[http://forums.thedarkmod.com/topic/16923-story-plot-and-narrative-design-discussion-thread/ Story, Plot and Narrative Design Discussion Thread]''' - To seek further advice and discussion on plotting, story and narrative, you can also visit this discussion thread. It's open to all, at any time, always. Whenever one has "writer's block" while designing a mission's narrative and how it'll fit into gameplay, he/she should feel free to visit the discussion.

			== See also ==

			*[https://www.youtube.com/watch?v=6m-yq4hH81Y New Mapper Workshop Tutorials: Planning an FM (concept, limits, layout, etc.)]
			*[[Fan Mission Design Discussions Archive]]
			*[[Mission Design Tips]]
			*[[Historical resources]]

	{{tutorial-editing}}		{{tutorial-editing}}

	[[Category:Narrative]]		[[Category:Narrative]]

Petike: adding a new category

2018-05-15T14:06:11Z

adding a new category

← Older revision		Revision as of 14:06, 15 May 2018
Line 318:		Line 318:

	{{tutorial-editing}}		{{tutorial-editing}}

			[[Category:Narrative]]

Petike: /* Further Discussion of Narrative Design */ reworked the link and description a bit

2018-04-18T11:19:45Z

Further Discussion of Narrative Design: reworked the link and description a bit

← Older revision		Revision as of 11:19, 18 April 2018
Line 315:		Line 315:
	''(addition by Petike)''		''(addition by Petike)''

	~~To seek further advice and discussion on plotting, story and narrative, you can also visit~~ [http://forums.thedarkmod.com/topic/16923-story-plot-and-narrative-design-discussion-thread/ this discussion thread].		'''[http://forums.thedarkmod.com/topic/16923-story-plot-and-narrative-design-discussion-thread/ Story, Plot and Narrative Design Discussion Thread]''' - To seek further advice and discussion on plotting, story and narrative, you can also visit this discussion thread. It's open to all, at any time, always. Whenever one has "writer's block" while designing a mission's narrative and how it'll fit into gameplay, he/she should feel free to visit the discussion.

	{{tutorial-editing}}		{{tutorial-editing}}

Petike: /* Common Problems and Things to Avoid in Plotting */ added an entry about the discussion thread

2015-02-07T14:03:18Z

Common Problems and Things to Avoid in Plotting: added an entry about the discussion thread

← Older revision		Revision as of 14:03, 7 February 2015
Line 310:		Line 310:

	-		-

			== Further Discussion of Narrative Design ==

			''(addition by Petike)''

			To seek further advice and discussion on plotting, story and narrative, you can also visit [http://forums.thedarkmod.com/topic/16923-story-plot-and-narrative-design-discussion-thread/ this discussion thread].

	{{tutorial-editing}}		{{tutorial-editing}}

Grayman at 22:21, 13 September 2012

2012-09-13T22:21:14Z

← Older revision		Revision as of 22:21, 13 September 2012
Line 3:		Line 3:
	Dark Mod FMs, like the long tradition of Thief FMs before them (which we should all take notes from), allow for a much bigger role for story and plot than other first person genres, and most players expect a good story to come as part of their experience playing FMs. It's not really sufficient anymore to build a mission first and try to throw together some plot or story to fit it without putting a little thought into what makes for good storytelling in an FM first, and ideally designing the mission's architecture, objectives, gameplay, AI pathing, plot, and story all as a coherent whole from the beginning. One story that inspires me is that, as is well known, Terry Pratchett (the famous fantasy writer) was a long-time player of our FMs and would often post questions and comments (like all of us), and he said that our FMs were among the best story-telling going on in all video gamedom! High praise from a master, and something we should all strive to live up to!		Dark Mod FMs, like the long tradition of Thief FMs before them (which we should all take notes from), allow for a much bigger role for story and plot than other first person genres, and most players expect a good story to come as part of their experience playing FMs. It's not really sufficient anymore to build a mission first and try to throw together some plot or story to fit it without putting a little thought into what makes for good storytelling in an FM first, and ideally designing the mission's architecture, objectives, gameplay, AI pathing, plot, and story all as a coherent whole from the beginning. One story that inspires me is that, as is well known, Terry Pratchett (the famous fantasy writer) was a long-time player of our FMs and would often post questions and comments (like all of us), and he said that our FMs were among the best story-telling going on in all video gamedom! High praise from a master, and something we should all strive to live up to!

	The purpose of wiki entry is to give a mapper some good methods and things to think about when working out the story and plot-progression of their FM. It's about the mechanical side of how to construct a plot that works in terms of gameplay to tell a story, as opposed to giving story ideas per se. It will walk through a number of ideas mappers can think about when plotting their FMs, although of course since storytelling is a creative thought process, there is no universally "right" way to design a good story and plot. But hopefully some of these ideas can inspire your own thoughts on the issue.		The purpose of this wiki entry is to give a mapper some good methods and things to think about when working out the story and plot-progression of their FM. It's about the mechanical side of how to construct a plot that works in terms of gameplay to tell a story, as opposed to giving story ideas per se. It will walk through a number of ideas mappers can think about when plotting their FMs, although of course since storytelling is a creative thought process, there is no universally "right" way to design a good story and plot. But hopefully some of these ideas can inspire your own thoughts on the issue.

	It is worth saying at the outset that some mappers may have the perception that storytelling is some magic thing, and they may shy away from "artificial devices" because they seem too mechanical or manipulative or transparent to actually work. But I think that not only are "artificial" plot devices okay, they are usually essential for carrying a good plot. I think of it like the mechanical steps for turning an empty wall brush into an interesting facade, like adding windows, good borderwork, and texture variety. It may all seem mechanical while you're doing it, but when a player goes through it, the story comes alive. Also note that players are already predisposed, even eager, to go where the author takes them, as long as it's not too hammy or heavy handed and clumsy. But not using techniques to take them somewhere at all can leave your FM stale.		It is worth saying at the outset that some mappers may have the perception that storytelling is some magic thing, and they may shy away from "artificial devices" because they seem too mechanical or manipulative or transparent to actually work. But I think that not only are "artificial" plot devices okay, they are usually essential for carrying a good plot. I think of it like the mechanical steps for turning an empty wall brush into an interesting facade, like adding windows, good borderwork, and texture variety. It may all seem mechanical while you're doing it, but when a player goes through it, the story comes alive. Also note that players are already predisposed, even eager, to go where the author takes them, as long as it's not too hammy or heavy handed and clumsy. But not using techniques to take them somewhere at all can leave your FM stale.

Demagogue: /* Problems vs. Puzzles */

2012-08-28T10:05:26Z

Problems vs. Puzzles

← Older revision		Revision as of 10:05, 28 August 2012
Line 162:		Line 162:
	The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.		The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.

	The general lesson for mappers here is just try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind or perform your ritual. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.		The general lesson for mappers here is just try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind or perform your ritual. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea that opens up the story, or some challenging jumps you might expect in the real world (without needing an entire elaborate jumping-puzzle area), but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.

	== Creating a Story Arc: Beginnings, Middles, and Ends ==		== Creating a Story Arc: Beginnings, Middles, and Ends ==

Demagogue: /* Problems vs. Puzzles */

2012-08-28T10:03:31Z

Problems vs. Puzzles

← Older revision		Revision as of 10:03, 28 August 2012
Line 162:		Line 162:
	The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.		The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.

	The general lesson for mappers here is just try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.		The general lesson for mappers here is just try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind or perform your ritual. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.

	== Creating a Story Arc: Beginnings, Middles, and Ends ==		== Creating a Story Arc: Beginnings, Middles, and Ends ==

Demagogue: /* Problems vs. Puzzles */

2012-08-28T10:02:59Z

Problems vs. Puzzles

← Older revision		Revision as of 10:02, 28 August 2012
Line 162:		Line 162:
	The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.		The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.

	The general lesson for mappers ~~to make~~ here is just, try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.		The general lesson for mappers here is just try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.

	== Creating a Story Arc: Beginnings, Middles, and Ends ==		== Creating a Story Arc: Beginnings, Middles, and Ends ==

Demagogue: /* Problems vs. Puzzles */

2012-08-28T10:02:33Z

Problems vs. Puzzles

← Older revision		Revision as of 10:02, 28 August 2012
Line 162:		Line 162:
	The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.		The general idea is that puzzles are largely about the author coming up with something clever to pass an obstacle, and she wants the player to read her mind or perform her elaborate ritual (something like a big jumping puzzle), which doesn't leave much for the player to do except try to figure out the one answer the author is looking for or do the thing like the author wants. A "problem" is some practical barrier like AI or a physical obstacle, with practical ways in world simulation to get around it, the more the better (tempting the AI to move, finding other paths around the obstacle, with different costs & benefits to each method). The mapper would do well to have at least two ways to make progress past most problems, but even better is when it's left as part of world simulation, where the player can do many things in the world to make progress, whatever they can think of. The good AI & world-simulation of TDM leaves lots of room open for this kind of thing, and it's something we're all familiar with playing many FMs.

	The general lesson for mappers to make here is just, try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time.		The general lesson for mappers to make here is just, try to think about obstacles in the gameplay from the player's perspective, what might be fun for them to engage with and feel accomplished doing, rather than about something clever you (the author) thought of and you want the player to read your mind. Try to think of problems with multiple solutions before puzzles with one solution. Let your gameplay empower the player. You can save your cleverness for good readables and conversations. Like all "rules" there can be exceptions though, if you have an awesome puzzle idea, but this lesson comes from long experience of many people making and playing a lot of storytelling games over a very long time. Of course there's a whole sub-genre of "puzzle FMs" where they are intended to be all puzzles -- which is great, I like them -- but they don't usually mix very well with good storytelling.

	== Creating a Story Arc: Beginnings, Middles, and Ends ==		== Creating a Story Arc: Beginnings, Middles, and Ends ==

← Older revision		Revision as of 02:08, 3 December 2019
Line 320:		Line 320:

	*[https://www.youtube.com/watch?v=6m-yq4hH81Y New Mapper Workshop Tutorials: Planning an FM (concept, limits, layout, etc.)]		*[https://www.youtube.com/watch?v=6m-yq4hH81Y New Mapper Workshop Tutorials: Planning an FM (concept, limits, layout, etc.)]
			*[https://web.archive.org/web/20150506194420/http://www222.pair.com/sjohn/blueroom/plots.htm The Big List of RPG Plots, by S. John Ross] (archived article)
	*[[Fan Mission Design Discussions Archive]]		*[[Fan Mission Design Discussions Archive]]
	*[[Mission Design Tips]]		*[[Mission Design Tips]]