The summary of the previous two articles I wrote on the decision pattern goes as follows:
If you hide the concequences of the players actions from immediate view, the player won't be tempted to choose both actions via savepoints and savegames. But, if he chooses to reload based upon alusions made post-decision, and these alusions differ, he will be able to verify that his choice likely matters - just not right now.
If you do not allude, show the concequences immediately, and the concequences are shallow, allowing the player to try both will break the game - the player will no longer feel he has any influence, and he cannot consider his choices, former and future, actual gameplay, but will rather consider them out of his hands, and he will cease trying to influence it.
So: When implementing decisions, in a game that allows reloading, these rules apply:
- Always allude to concequences both before and after the player makes a decision.
- The closer to the action you show the concequences, the larger and more impactful the concequences must be.
The second bit also makes sense conversely; if we presume that a decision is supposed to have a big impact on a story, and the full effects of it are something the player might be unhappy with, he should not be "punished" with having to do-over very much.
The psychology here would say that the player should be conditioned to choosing his actions with great care, and that punishment would be effective; but if he regrets a decision enough to discard his current thread and wants to do it over, he is _already_ as into the story as you could want. He cares about the story and the characters. You're not only punishing him for making the wrong decision, but also for caring. The whole reloading thing should be avoided when possible, as a concequence. As such, the player should generally not experience concequences to his actions that there's a high probability he would regret. And if you must take tis route, make a do-over easy.
A couple of examples are in order: in Ultima X you encounter a deathly ill orphaned girl, and you're offered the choice of wether or not to euthanize her. No matter what you choose, the games villain taunts you - either over the fact that you now have the blood of an 8 years old girl on your hands, or that you left one to a slow, grueling and cruel death over the next couple of hours.
Nomatter what the player chooses, the adverse reaction, the long taunting session, and the guilt will likely make him try the other option if he cares about the story and his influence. When he finds out that negative concequences are unavoidable, and that he has only been presented with wrong choices, at the very least he will be glad that he can do over easily. But even then, he is still getting punished for caring about the game world by having to use a lousy interface to explore the concequences; all because some developer somewhere thought it would be a good idea to punish the player with concequences he will be likely to reject nomatter what decision he makes.
In the end, I played through the above sequence 4 times - one euthanizing her, one saving her, and one euthanizing her, then after spending 15 minutes on gamefaqs before I concluded that my first decision was what I really wanted to do, I euthanized her _again_.
- The player must generally not experience concequences he will regret.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them
Or, all in one place, the decision pattern in summary:
When implementing a decision, follow these guidelines:
- Always allude to concequences both before and after the player makes a decision. Make the post-decision allusions differ depending on choice made. Exceptions can be made if, and only if, you can be certain that the player won't reject the concequences in favor of a do-over.
- The closer to the action you show the concequences of it, the larger and more impactful the concequences must be. Long stretches are therefore cheaper to make and implement with the same impact. You can even allude to something that never happens if it's the exception rather than the rule.
- For big concequences, the player must not recieve punishment for attempting to figure out all possible outcomes. You would punish him for caring.
- The player must generally not experience concequences he will regret to such a degree that he would be willing to go through anything more than a quick and painless do-over to rectify it.
- Do-overs should happen out of caring for the world, not out of frustration with the concequences.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them. There must always be a "right" choice, so to speak.
søndag den 30. november 2008
lørdag den 22. november 2008
Storyline concept
I need to dump this concept somewhere:
As a method for international star travel, in an age where human science has conquered star faring propulsion technologies but not the human lifespan, nor the ability to store a computerized mind more powerfull than a cat in anything smaller than the volume of an elephant, humans develop a mechanized shell with the ability to grow a humanoid host.
Designed as a cyborg, the shell is 2 stories tall, with a life support chamber within that can grow and support a human being. If the human is ever killed, dies of old age, or leaves the shell, or is terminated, a new one can be grown to serve as host based on a storage bank of zygote clones with identical DNA to the former host. The shell nurtures and raises the human within the chamber, utilizing hormonal growth regulations, optimized sleep cycle regulation, and databanks containing interactive virtual reality recordings that allows the human to be raised, and eventually come to understand it's position, based on the lifes of the previous hosts.
Any space travel accross long distances means the death, rebirth, and re-raising of the host upon closing to the destination, effectively leaving the shell as a whole immortal, but always alone, and suffering from varying degrees of amnesia depending upon it's development.
I'm not quite sure what this concept means, but I thought it was cool when I came up with it....
As a method for international star travel, in an age where human science has conquered star faring propulsion technologies but not the human lifespan, nor the ability to store a computerized mind more powerfull than a cat in anything smaller than the volume of an elephant, humans develop a mechanized shell with the ability to grow a humanoid host.
Designed as a cyborg, the shell is 2 stories tall, with a life support chamber within that can grow and support a human being. If the human is ever killed, dies of old age, or leaves the shell, or is terminated, a new one can be grown to serve as host based on a storage bank of zygote clones with identical DNA to the former host. The shell nurtures and raises the human within the chamber, utilizing hormonal growth regulations, optimized sleep cycle regulation, and databanks containing interactive virtual reality recordings that allows the human to be raised, and eventually come to understand it's position, based on the lifes of the previous hosts.
Any space travel accross long distances means the death, rebirth, and re-raising of the host upon closing to the destination, effectively leaving the shell as a whole immortal, but always alone, and suffering from varying degrees of amnesia depending upon it's development.
I'm not quite sure what this concept means, but I thought it was cool when I came up with it....
The decision pattern, some refinements
In my last post, I described the decision pattern as something pertaining to the rest of the play-experience within the game. That's a pretty loose definition, so I'll try to narrow it down a little further: The concequences of the decision should influence either the main plot or a diverse number of distinct and unrelated subplots, such that it is different from making a different decision.
Implementing decisions is one of the greatest ways to give the player the impression that his performance matters, if he is able to recognize that his decisions actually make a difference. In other words, if the player does not realize that judgment is being passed on him, he will not modify his manner of playing, and thinking, accordingly, and his experience will arguably be more shallow.
This is perhaps one of the most problematic aspects of the decision pattern; since a lot of games do not pass permanent judgement, and chooses not to have significant concequences for many decisions, a game which utilizes the decision pattern will necessarily need to make the player understand that that it utilizes it. That is to say, one can safely assume that the player, at the onset, suspects the game is very linear, and that he will suspect any choices implemented of being unimportant.
I can be quite difficult to dispell this suspicion, and perhaps calls for a special "tutorial" section to help the player understand the dynamics of the game.
It's actually worthy of note that once the player has become convinced that judgement will be passed on him, his manner of thinking will be henceforth modified. So, theoretically, you could have very intricate manners of passing judgement in the beginning of the game, and then later introduce choices whereupon the same judgement will always fall, without the player realizing it if the judgement is a reasonable response to all choices.
This utility is exceptionally conniving and very powerful as long as the player is fooled, since you can make the player think he's being responded to without actually being responded to. In other words, you get the same effect that non linear storytelling offers without actually having to make it particularly non linear.
There is a huge problem with this approach however: The player may be inclined to reload the game at an earlier point and try again if he is unhappy with an outcome. If he realizes that you're not actually judging him anymore, he will likely immediately modify his behavior and be inherently suspicious of the implementation of decisions again, a suspicion that may not go away as easily a second time around; fool me once, shame on you, fool me twice, shame on me, and all that.
The trick is to make the player see that there is an immediate difference; there has to be a distinction which is deep enough that the player thinks it may matter in the long run, even after playing through the same 5 minutes of game to try out deffirent choices. If the player can tell that it doesn't even matter immediately afterwards, the choice won't matter much to him because it doesn't matter much to the game.
A good idea is to implement distinct rewards and punishments for different choices in the immediate term, since at the very least, that will make the player care out of greed. But additionally, it's important to have a large amount of long threads; this is to instill in the player that not only is there an immediate difference, but there may well be long term differences as well. In fact, foreshadowing can be a powerful tool in this regard. If a character openly tells the player that he hates the player in one branch, and not in another, then the player will expect that there may be concequences to being hated. There doesn't have to consistently be concequences, as long as the concequences pop up later often enough that the player starts trying to act based on the idea that there may be concequences.
Once the player is in that mindset, doing a conversation where a character decides to now hate the player, that conversation will have an impact. It doesn't actually matter wether or not the player always or never have a future confrontation about something or other; all that matters is that if the player does have a confrontation, it gets tied to the conversation where the character admitted (or didn't admit) to hating the player, such that the player is able to tie the idea of judgement to his earlier action.
If the confrontation and the conversation are spaced far enough apart, the player won't be inclined to reload to check the difference; he may speculate that, if he didn't make the character hate him, the character'd been more confrontational, perhaps the character would have brought a lot of goons along with him; or, if he did make the character hate the player, then he may speculate that the confrontation wasn't inevitable. Either way, it's possible to do a tangible feeling of judgement without actually doing a lot of work to implement that judgement.
On a second playthrough, such things will be revealed to the player, but if you've actually made a game that is good enough to warrant two playthroughs, that's good enough, so you should just take that and be glad. At that point, you can live with the player deciding not to play anymore; he'll still, undoubtedly, recommend the game far and wide.
Implementing decisions is one of the greatest ways to give the player the impression that his performance matters, if he is able to recognize that his decisions actually make a difference. In other words, if the player does not realize that judgment is being passed on him, he will not modify his manner of playing, and thinking, accordingly, and his experience will arguably be more shallow.
This is perhaps one of the most problematic aspects of the decision pattern; since a lot of games do not pass permanent judgement, and chooses not to have significant concequences for many decisions, a game which utilizes the decision pattern will necessarily need to make the player understand that that it utilizes it. That is to say, one can safely assume that the player, at the onset, suspects the game is very linear, and that he will suspect any choices implemented of being unimportant.
I can be quite difficult to dispell this suspicion, and perhaps calls for a special "tutorial" section to help the player understand the dynamics of the game.
It's actually worthy of note that once the player has become convinced that judgement will be passed on him, his manner of thinking will be henceforth modified. So, theoretically, you could have very intricate manners of passing judgement in the beginning of the game, and then later introduce choices whereupon the same judgement will always fall, without the player realizing it if the judgement is a reasonable response to all choices.
This utility is exceptionally conniving and very powerful as long as the player is fooled, since you can make the player think he's being responded to without actually being responded to. In other words, you get the same effect that non linear storytelling offers without actually having to make it particularly non linear.
There is a huge problem with this approach however: The player may be inclined to reload the game at an earlier point and try again if he is unhappy with an outcome. If he realizes that you're not actually judging him anymore, he will likely immediately modify his behavior and be inherently suspicious of the implementation of decisions again, a suspicion that may not go away as easily a second time around; fool me once, shame on you, fool me twice, shame on me, and all that.
The trick is to make the player see that there is an immediate difference; there has to be a distinction which is deep enough that the player thinks it may matter in the long run, even after playing through the same 5 minutes of game to try out deffirent choices. If the player can tell that it doesn't even matter immediately afterwards, the choice won't matter much to him because it doesn't matter much to the game.
A good idea is to implement distinct rewards and punishments for different choices in the immediate term, since at the very least, that will make the player care out of greed. But additionally, it's important to have a large amount of long threads; this is to instill in the player that not only is there an immediate difference, but there may well be long term differences as well. In fact, foreshadowing can be a powerful tool in this regard. If a character openly tells the player that he hates the player in one branch, and not in another, then the player will expect that there may be concequences to being hated. There doesn't have to consistently be concequences, as long as the concequences pop up later often enough that the player starts trying to act based on the idea that there may be concequences.
Once the player is in that mindset, doing a conversation where a character decides to now hate the player, that conversation will have an impact. It doesn't actually matter wether or not the player always or never have a future confrontation about something or other; all that matters is that if the player does have a confrontation, it gets tied to the conversation where the character admitted (or didn't admit) to hating the player, such that the player is able to tie the idea of judgement to his earlier action.
If the confrontation and the conversation are spaced far enough apart, the player won't be inclined to reload to check the difference; he may speculate that, if he didn't make the character hate him, the character'd been more confrontational, perhaps the character would have brought a lot of goons along with him; or, if he did make the character hate the player, then he may speculate that the confrontation wasn't inevitable. Either way, it's possible to do a tangible feeling of judgement without actually doing a lot of work to implement that judgement.
On a second playthrough, such things will be revealed to the player, but if you've actually made a game that is good enough to warrant two playthroughs, that's good enough, so you should just take that and be glad. At that point, you can live with the player deciding not to play anymore; he'll still, undoubtedly, recommend the game far and wide.
fredag den 21. november 2008
The decision pattern
One of the things that a fair amount of interesting games do is provide you with a meaningful choice you can't go back on that will affect the entirety of the rest of the game.
I'd like to talk a little bit about the concequences of this type of design, and what it entails.
The choice is often placed either at the beginning or at the end, and only rarely in the middle. It makes "sense" to place it in the end because a 2branched choice placed 3 hours before the end only necessitates about 6 hours of gameplay, of which 3 are the price of the choice.
A choice placed at the begining, on the other hand, is arguably either very expensive to design, or it doesn't diversify the experience afterwards as much from the other options - only few games will place a choice before the player 40 hours before the game ends, and effectively pay 40 additional hours of gameplay time as the price.
Various strategies are can be used to lessen the price. Some go so far as to rely on the player forgiving the lack of concequences of most choices because it would be too time consuming to implement. It's a completely viable strategy, since players expectations are measured by their perception of viability and quality. If they find that implementing proper concequences would have been detrimental, they may be willing to accept the compromise because they cannot think of a better one.
Applying the decision pattern, then, is a question of weighing returns. A lot of older games provide much more detailed responsiveness to choices than many state of the art modern ones. The newer games gamble that gamers are very forgiving; since the demographic of gamers has changed over the past decades, it may well be a sound gamble. All the same, I do not feel that blindly submitting to it is the optimum choice.
A good example of the application of the decision pattern is the choice of wether or not you save Paul Denton in Deus Ex. A bad example is wether or not to be bad or good at the end of Deus Ex, if not for the fact that the choice was placed right at the very end.
I'll go into the intricasies of the decision pattern in a later post, and narrow down how to apply it correctly.
I'd like to talk a little bit about the concequences of this type of design, and what it entails.
The choice is often placed either at the beginning or at the end, and only rarely in the middle. It makes "sense" to place it in the end because a 2branched choice placed 3 hours before the end only necessitates about 6 hours of gameplay, of which 3 are the price of the choice.
A choice placed at the begining, on the other hand, is arguably either very expensive to design, or it doesn't diversify the experience afterwards as much from the other options - only few games will place a choice before the player 40 hours before the game ends, and effectively pay 40 additional hours of gameplay time as the price.
Various strategies are can be used to lessen the price. Some go so far as to rely on the player forgiving the lack of concequences of most choices because it would be too time consuming to implement. It's a completely viable strategy, since players expectations are measured by their perception of viability and quality. If they find that implementing proper concequences would have been detrimental, they may be willing to accept the compromise because they cannot think of a better one.
Applying the decision pattern, then, is a question of weighing returns. A lot of older games provide much more detailed responsiveness to choices than many state of the art modern ones. The newer games gamble that gamers are very forgiving; since the demographic of gamers has changed over the past decades, it may well be a sound gamble. All the same, I do not feel that blindly submitting to it is the optimum choice.
A good example of the application of the decision pattern is the choice of wether or not you save Paul Denton in Deus Ex. A bad example is wether or not to be bad or good at the end of Deus Ex, if not for the fact that the choice was placed right at the very end.
I'll go into the intricasies of the decision pattern in a later post, and narrow down how to apply it correctly.
mandag den 17. november 2008
From patterns to rules: The McGuffin Pattern
I wrote earlier about what I called the McGuffin Pattern.
The basic idea was that if you drive your quest with a McGuffin, like a unique stateless item, the player will be able to figure out the solution to the quest at it's onset. The player doesn't, as a concequence, have to solve a problem; he simply has to provide a specific, choiceless solution. Now, this can work if you want to imply that the player must do a very specific job within very specific parameters. But the player won't own the solution, he will be following orders. If you want the player to commit, you must make him own his choices, and therefore his solutions. At the very least, it must be this way in the general case. The McGuffin pattern hinders that.
Within gaming, the McGuffin pattern is without a question an anti-pattern, so it should not be followed. It should be known, because it should be avoided. And what's more, it doesn't simply concern McGuffins - it can be characters or fairly abstract concepts too, that provide the player with the solution at the onset, and on the other hand, McGuffins can be constructed to avoid the McGuffin pattern. Yes, that makes it sound like I just coined a misnomer, and I kinda sorta did, but I didn't because the pattern emerges through the brainless use of McGuffins 99% of the time. The generalization simply says: If you abstracted the McGuffin out of the equation somehow, while keeping the solution within the definition of the quest, you didn't solve anything at all, dummy.
Now, as a quick interlude: I like rules. Rules partition everything into right and wrong, that which follows rules and that which doesn't. Any good pattern can be made precise and easily applicable through the use of rules. So, what rule can be taken away from this?
Baseline rule of it is: Do not present the player with unfulfilled solutions. Present him with problems.
The fine print should add: And perhaps hints, but never reveal to him the number of possible solutions to the quest at the onset. He needs to figure out the solution. If you want to optimize the players experience so open quests don't confuse him, be certain to inform the player of his progression through 2nd person narrative; but even then, only log what he has done and discovered in a clean cut, unambiguous fashion. And here's the cigar: try to always make hints ambiguous in their certainty: Make them suggestions rather than plans.
The McGuffin can almost always be avoided, if desired. Say the quest is to look for the holy grail. Firstly, try to make the grail an ambiguous item. Now generally, there can be no more than one holy grail, but that's because the holy grail doesn't have a purpose. Suppose it did have a purpose; suppose it gave eternal life if you drink from it. Then, what the player ostensibly needs is to be searching for is something that gives eternal life.
At times, you cannot make the item itself ambiguous though; perhaps it's a holy grail without a purpose, perhaps it's a smoking gun. But the maxim holds: if the item is unambiguous, it's location, or it's validity, must be ambiguous at the onset. The player must make a choice on how to make the solution less ambiguous. Perhaps it turns out that there is no imposter, that the location is obvious, or that the task can really only be completed in one way. But narrowing this down should be a process, and not revealed through the initiating dialogue. Hitman is perhaps the most excellent example; there's typically a myriad of puzzles built into each level, and many have multiple solutions. But there is only 1 goal. The player owns the hit, however, because he owns the process; he was presented with a problem, rather than a solution.
To reiterate the first rule of non-linear narratives :
- Do not present the player with unfulfilled solutions. Present him with problems.
The basic idea was that if you drive your quest with a McGuffin, like a unique stateless item, the player will be able to figure out the solution to the quest at it's onset. The player doesn't, as a concequence, have to solve a problem; he simply has to provide a specific, choiceless solution. Now, this can work if you want to imply that the player must do a very specific job within very specific parameters. But the player won't own the solution, he will be following orders. If you want the player to commit, you must make him own his choices, and therefore his solutions. At the very least, it must be this way in the general case. The McGuffin pattern hinders that.
Within gaming, the McGuffin pattern is without a question an anti-pattern, so it should not be followed. It should be known, because it should be avoided. And what's more, it doesn't simply concern McGuffins - it can be characters or fairly abstract concepts too, that provide the player with the solution at the onset, and on the other hand, McGuffins can be constructed to avoid the McGuffin pattern. Yes, that makes it sound like I just coined a misnomer, and I kinda sorta did, but I didn't because the pattern emerges through the brainless use of McGuffins 99% of the time. The generalization simply says: If you abstracted the McGuffin out of the equation somehow, while keeping the solution within the definition of the quest, you didn't solve anything at all, dummy.
Now, as a quick interlude: I like rules. Rules partition everything into right and wrong, that which follows rules and that which doesn't. Any good pattern can be made precise and easily applicable through the use of rules. So, what rule can be taken away from this?
Baseline rule of it is: Do not present the player with unfulfilled solutions. Present him with problems.
The fine print should add: And perhaps hints, but never reveal to him the number of possible solutions to the quest at the onset. He needs to figure out the solution. If you want to optimize the players experience so open quests don't confuse him, be certain to inform the player of his progression through 2nd person narrative; but even then, only log what he has done and discovered in a clean cut, unambiguous fashion. And here's the cigar: try to always make hints ambiguous in their certainty: Make them suggestions rather than plans.
The McGuffin can almost always be avoided, if desired. Say the quest is to look for the holy grail. Firstly, try to make the grail an ambiguous item. Now generally, there can be no more than one holy grail, but that's because the holy grail doesn't have a purpose. Suppose it did have a purpose; suppose it gave eternal life if you drink from it. Then, what the player ostensibly needs is to be searching for is something that gives eternal life.
At times, you cannot make the item itself ambiguous though; perhaps it's a holy grail without a purpose, perhaps it's a smoking gun. But the maxim holds: if the item is unambiguous, it's location, or it's validity, must be ambiguous at the onset. The player must make a choice on how to make the solution less ambiguous. Perhaps it turns out that there is no imposter, that the location is obvious, or that the task can really only be completed in one way. But narrowing this down should be a process, and not revealed through the initiating dialogue. Hitman is perhaps the most excellent example; there's typically a myriad of puzzles built into each level, and many have multiple solutions. But there is only 1 goal. The player owns the hit, however, because he owns the process; he was presented with a problem, rather than a solution.
To reiterate the first rule of non-linear narratives :
- Do not present the player with unfulfilled solutions. Present him with problems.
torsdag den 13. november 2008
The McGuffin Pattern
http://en.wikipedia.org/wiki/Mcguffin
I'm going to go out on a limb here and define my own terminology for some patterns I believe are occouring within non linear narratives. Terms are useless in the broader context; noone will ever come to know and use mine, to be sure. But I had to put some sort of memorable title for this, and various other patterns that are emergent within non linear narratives so my own terms will have to do untill I find a more official theory that agrees with my own.
And really, that might sound exceptionally lazy, but within non linear litterary theory, very little context is available. Indeed, the best topology I have come upon is from 95 and has 10 hits on google for most of the terms it defines. And even that is very basic; it simply defines names with meaningful etymology for some of the most basic constructs within this area. I'm speaking of Espen Arseths essay called something to the effect of "a topology of "....and I forget the rest. It's in my bookcase, and if you google arseth I'm sure you'll come upon it...eventually.
At any rate, the McGuffin Pattern. What am I on about?
In books and novels, a McGuffin is a unique item that is intrinsically linked to the plot in some manner; in fact, the whole point is that it's linked to the plot, and has been since it's conception. It's such a fundamental piece, by definition, that the plot designer invented it to help him rationalize something he wanted to do. For example, it is the holy grail of the arthurian legend, or the ring in the lord of the rings.
In computer games, it is an item that allows the game designer to fashion his quest in a manner that makes sense to him. To follow the McGuffin pattern in game design, though, is to make major parts of the game play experience linear. Within non linear narrative theory, then, it imposes a linear narrative on an experience that is, at a lower level, non linear. Many will see it as a necessary evil, probably, and I tend to agree if you're ok with imposing a linear narrative on a non-linear experience. If that somehow makes more sense than the alternative, then it's obviously the sensible thing to do.
But let me step back a bit and explain why the application of a mcguffin makes the game experience linear:
Fallout 1 and 2 are both driven by the search for specific items at the outset, or so it seems. In fallout it's the waterchip, in fallout 2 it's the garden of eden creation kit. But these are, in fact, not McGuffins. At least, the waterchip isn't; what you're really searching for is a clean, permanent source of water for the vault because the waterchip broke. And in fact, there are more than one solution to this - you can aquire a waterchip from a number of sources (though that number is not sufficiently high, in my oppinion) - and you can, similarly, get water merchants to bring water to the vault.
To be a McGuffin, it would have to be a unique item. Had it been a unique item, the game would necessitate that you do certain specific actions on any given playthrough.
In this fashion, the McGuffin pattern necessitates that the player commit to certain very specific actions, and a very specific narrative, whenever he accepts any sort of task that involves a McGuffin.
So essentially, the McGuffin Pattern is an anti-pattern - when utilized within RPG's and similar games, you lock down the narrative, and this is the kicker: You do so, because you, as a writer, want to do something specific with the narrative. You take away the players liberty because you feel you have something better than liberty of narrative to offer him.
Now it may be that you do, but you have to realize that you make the player into a passive observer rather than an active participant.
So how do you avoid that? Don't use unique items. And try not to make characters the goals of quests. Ideally? Present the player with open ended problems rather than solutions that need to be filled in.
I'm going to go out on a limb here and define my own terminology for some patterns I believe are occouring within non linear narratives. Terms are useless in the broader context; noone will ever come to know and use mine, to be sure. But I had to put some sort of memorable title for this, and various other patterns that are emergent within non linear narratives so my own terms will have to do untill I find a more official theory that agrees with my own.
And really, that might sound exceptionally lazy, but within non linear litterary theory, very little context is available. Indeed, the best topology I have come upon is from 95 and has 10 hits on google for most of the terms it defines. And even that is very basic; it simply defines names with meaningful etymology for some of the most basic constructs within this area. I'm speaking of Espen Arseths essay called something to the effect of "a topology of "....and I forget the rest. It's in my bookcase, and if you google arseth I'm sure you'll come upon it...eventually.
At any rate, the McGuffin Pattern. What am I on about?
In books and novels, a McGuffin is a unique item that is intrinsically linked to the plot in some manner; in fact, the whole point is that it's linked to the plot, and has been since it's conception. It's such a fundamental piece, by definition, that the plot designer invented it to help him rationalize something he wanted to do. For example, it is the holy grail of the arthurian legend, or the ring in the lord of the rings.
In computer games, it is an item that allows the game designer to fashion his quest in a manner that makes sense to him. To follow the McGuffin pattern in game design, though, is to make major parts of the game play experience linear. Within non linear narrative theory, then, it imposes a linear narrative on an experience that is, at a lower level, non linear. Many will see it as a necessary evil, probably, and I tend to agree if you're ok with imposing a linear narrative on a non-linear experience. If that somehow makes more sense than the alternative, then it's obviously the sensible thing to do.
But let me step back a bit and explain why the application of a mcguffin makes the game experience linear:
Fallout 1 and 2 are both driven by the search for specific items at the outset, or so it seems. In fallout it's the waterchip, in fallout 2 it's the garden of eden creation kit. But these are, in fact, not McGuffins. At least, the waterchip isn't; what you're really searching for is a clean, permanent source of water for the vault because the waterchip broke. And in fact, there are more than one solution to this - you can aquire a waterchip from a number of sources (though that number is not sufficiently high, in my oppinion) - and you can, similarly, get water merchants to bring water to the vault.
To be a McGuffin, it would have to be a unique item. Had it been a unique item, the game would necessitate that you do certain specific actions on any given playthrough.
In this fashion, the McGuffin pattern necessitates that the player commit to certain very specific actions, and a very specific narrative, whenever he accepts any sort of task that involves a McGuffin.
So essentially, the McGuffin Pattern is an anti-pattern - when utilized within RPG's and similar games, you lock down the narrative, and this is the kicker: You do so, because you, as a writer, want to do something specific with the narrative. You take away the players liberty because you feel you have something better than liberty of narrative to offer him.
Now it may be that you do, but you have to realize that you make the player into a passive observer rather than an active participant.
So how do you avoid that? Don't use unique items. And try not to make characters the goals of quests. Ideally? Present the player with open ended problems rather than solutions that need to be filled in.
tirsdag den 11. november 2008
Why writing and programming are fundamentally different
A lot of people spend time writing stuff on their computers. What and how they write depends almost entirely upon what their goal is first, and their personal manner of going about things second.
Take this blog. My goal is mainly to express various essays that are bubbling and steaming in my head and are just begging to become a little more concrete, and a little less elusive. Perhaps help me cut the crap from the cake with a little bit of written analysis afterwards. My goal is not, on the other hand, to explicitly to argue why I believe all my presumptions to be true.
Since my readership is likely to be exceptionally limited, I'm fully expecting it'll only be me, it seems like I would per default agree with my own presumptions if they're worth agreeing with.
As such, you'll see a focus on presenting an idea in a manner which seems to be sorta correct to me at the time of writing, but also which does not get lost in too many trivialities; and one which does not make being right a more important property than being written.
So various writers write for various reasons; programmers want to be absolutely precise, and absolutely correct. Of course, that is not enough, but those two are preconditions for writing working programs.
Writing political arguments is different; there, the goal is to be convincing. Being precise is not important, but always being right, at least in the eyes and ears of your followers, is very important. It is no suprise, then, that programmers aren't terribly interested in popular politics - the lack of finesse and precision, in favour of vague omnicorrectness, can be particularly jarring when you're used to dealing with absolutes and total precision. To a certain degree, this makes perfect sense - it is very hard to get someone to like you if they don't agree with you on things you purport to be of the utmost importance.
Writers who focus on a whole lot more than being right. Certainly, what they write must make sense, but they attempt to invoke much more varied responses than agreement or disagreement. As such, they employ language for a completely different reason than that of programmers - who are attempting to achieve something very specific. And different from politicians - who are attempting to be correct while saying something you agree with.
All because a writers goal is completely different. Certainly, the goal may be fairly specific, so it is akin to what a programmer does - but the writer does not have the option of being entirely precise. And certainly, he wants the reader to accept what he writes rather than reject it - but then, the writer does not need to prove that it is right, just that it isn't wrong granted fair suspension of disbelief.
Any writer who does not realize that making factual arguments, or attempting precision or correctness is not the focus of the discipline is, as such, doomed to fail. It's supposed to be about the story, stupid.
Take this blog. My goal is mainly to express various essays that are bubbling and steaming in my head and are just begging to become a little more concrete, and a little less elusive. Perhaps help me cut the crap from the cake with a little bit of written analysis afterwards. My goal is not, on the other hand, to explicitly to argue why I believe all my presumptions to be true.
Since my readership is likely to be exceptionally limited, I'm fully expecting it'll only be me, it seems like I would per default agree with my own presumptions if they're worth agreeing with.
As such, you'll see a focus on presenting an idea in a manner which seems to be sorta correct to me at the time of writing, but also which does not get lost in too many trivialities; and one which does not make being right a more important property than being written.
So various writers write for various reasons; programmers want to be absolutely precise, and absolutely correct. Of course, that is not enough, but those two are preconditions for writing working programs.
Writing political arguments is different; there, the goal is to be convincing. Being precise is not important, but always being right, at least in the eyes and ears of your followers, is very important. It is no suprise, then, that programmers aren't terribly interested in popular politics - the lack of finesse and precision, in favour of vague omnicorrectness, can be particularly jarring when you're used to dealing with absolutes and total precision. To a certain degree, this makes perfect sense - it is very hard to get someone to like you if they don't agree with you on things you purport to be of the utmost importance.
Writers who focus on a whole lot more than being right. Certainly, what they write must make sense, but they attempt to invoke much more varied responses than agreement or disagreement. As such, they employ language for a completely different reason than that of programmers - who are attempting to achieve something very specific. And different from politicians - who are attempting to be correct while saying something you agree with.
All because a writers goal is completely different. Certainly, the goal may be fairly specific, so it is akin to what a programmer does - but the writer does not have the option of being entirely precise. And certainly, he wants the reader to accept what he writes rather than reject it - but then, the writer does not need to prove that it is right, just that it isn't wrong granted fair suspension of disbelief.
Any writer who does not realize that making factual arguments, or attempting precision or correctness is not the focus of the discipline is, as such, doomed to fail. It's supposed to be about the story, stupid.
Abonner på:
Opslag (Atom)