here he is!
lørdag den 9. oktober 2010
lørdag den 28. august 2010
Are both of these women the same?
This is slightly ridiculous to put on this blog, just as my character design was, but since I'm currently just using it as a place to dump images that have some type of meaning to me
Left picture is Morrigan for biowares upcomming dlc for dragon age. Right picture is some woman from the trailer for dragon age 2. Now, initially, I was convinced the woman on the right wasn't morrigan, untill I saw the piece of pre-rendered art on the left. Now I'm no longer sure - add 15 years to the woman on the right, and I could see her turning into the one on the left.
Why does this matter? It doesn't, really....it's just a part of me speculating what the latest dlc, and what dragon age 2, will have as their focal point....I can't shake the feeling that dragon age: origins is really the origin story of the so-called "god-baby" that this morrigan person and the protagonist can have together.
Left picture is Morrigan for biowares upcomming dlc for dragon age. Right picture is some woman from the trailer for dragon age 2. Now, initially, I was convinced the woman on the right wasn't morrigan, untill I saw the piece of pre-rendered art on the left. Now I'm no longer sure - add 15 years to the woman on the right, and I could see her turning into the one on the left.Why does this matter? It doesn't, really....it's just a part of me speculating what the latest dlc, and what dragon age 2, will have as their focal point....I can't shake the feeling that dragon age: origins is really the origin story of the so-called "god-baby" that this morrigan person and the protagonist can have together.
fredag den 20. august 2010
lørdag den 24. juli 2010
a small character concept I been working on
mandag den 28. december 2009
Handling player state
A players state is the data describing the value of all the variables pertaining to things which might happen in the game.
If that sounds like "blabla", it's because I was extra careful to word it unambiguosly, but it's probably failing utterly to communicate the basics of what I mean to describe.
So, let me give you an example: the players charactersheet in dungeons and dragons is part of the players state. Abstractly speaking, values which the player has not had a chance of influencing yet are also part of the player state; the lack of a level 20 ability on a level 10 character sheet can technically be thought of as part of the player state, because it is implied by the player state.
Now, as you can imagine, there's one heck of a lot of variables in the player state in a computer game: the player characters XYZ coordinates in the 3d space he inhabits, for example, are part of it.
All of these variables, together, form a cartesian product. A cartesian product is something usually used in math, but the short story is, it's a function, it's sometimes useful, and while it's definite, it's usually not finite, and it's not usually something you can picture in your head unless you're rather brilliant.
I bring it up, because understanding how to handle player state, as a game designer, inevitably ties in to handling the cartesian product: the cartesian product of the player state variables is the collection of all the possible permutations of all the variables.
If the variables were strength and agility, and those variables went from 1 to 3 each, the collection of permutations would be:
(str=1 agi=1,str=1 agi=2,str=1 agi=3,
str=2 agi=1,str=2 agi=2,str=2 agi=3,
str=3 agi=1,str=3 agi=2,str=3 agi=3)
Here, I've seperated each permutation with a comma.
That is, in other words, the cartesian product, and you can hopefully see what I mean when I say it is this product you need to keep in mind when designing a game...going by the above example, if the player only gets to level his stats twice, with a free choice between agility and strength, if you want to cover all your bases in a quest, you need to deal with both players who are 2str2agi, 3str1agi, and 1str3agi...since that's the possible player states at that time, supposing the player is forced to use level up points.
As you can see, all of these are present in the cartesian product above...the cartesian product, in other words, is the source of possibilities the player can expose the designer to, though it almost always contains permutations that couldn't happen at a specific point in a game.
Games are, by their nature, fun because they make manipulating the player state difficult. Handling player state, then, becomes a question of designing fun difficulties for the player. Thinking of the game designers job in this manner makes it seem ever-so-slightly sadistic, but regardless of what it seems like, it is what it is: You're out to stop the player from getting what he wants, to make him fight for it, and to (hopefully) make him beat you whilst he retains the illusion that you wanted to win too Which you didn't. But shh, lets keep quiet about that.
There's more to it than simply designing fun roadblocks though; you want the player to feel as though you are not limiting him, but rather, that he is limiting himself. For instance! the classic jump puzzle, while not very fun, makes the player limit where he walks because you punish him if he does do something else. Think of a room you as a player must walk across. If the state possible within the room is simply the entirety of the room floor, the room is boring. Clearly, where the player is able to walk has been limited by the designer. Put a chasm in the middle of the room, though, and have the player jump over the chasm or be forced to restart at the start of the room, and suddenly, both the player and you limit the player; see, the player limits himself by wishing to avoid the chasm. It doesn't really matter that you designed both obstacles; it doesn't matter if the chasm is a very small challenge to overcome...because it accomplishes the most important thing: the player is suddenly thinking in terms of what he wants to do, and what he wants to not do; not in terms of what you want him not to do.
Since we, as game designers, are forced to make sure our players don't do certain things (walk through our walls for example...he must stay on the path, as it were), it serves us well to try and design the fashion in which the player can change the player state in such a way that he inhibits himself, and thinks in terms of what he does and does not want to do. This, we do by making sure the player can be punished, if only ever so slightly, by being careless.
And that's really it; we should focus on making the hard edges in the player state soft, whereever possible...so instead of being constrained on a huge balchony, the player is on a huge balchony and part of the railing has come off so the player could possibly fall over, if he was careless.
This probably sounds...like a weird hypothesis, but I believe that this type of design is part of the reason Batman: Archam Asylum feels exceptionally free and open, in spite of being quite linear, and oftentimes quite constrained. The fact that you have choice, even if it's sometimes useless and clearly bad choice, it keeps the player making up his mind out the limits of the world, keeps him thinking...and that's really enough to make the player forget about the game designer and his artificial boundaries...
If that sounds like "blabla", it's because I was extra careful to word it unambiguosly, but it's probably failing utterly to communicate the basics of what I mean to describe.
So, let me give you an example: the players charactersheet in dungeons and dragons is part of the players state. Abstractly speaking, values which the player has not had a chance of influencing yet are also part of the player state; the lack of a level 20 ability on a level 10 character sheet can technically be thought of as part of the player state, because it is implied by the player state.
Now, as you can imagine, there's one heck of a lot of variables in the player state in a computer game: the player characters XYZ coordinates in the 3d space he inhabits, for example, are part of it.
All of these variables, together, form a cartesian product. A cartesian product is something usually used in math, but the short story is, it's a function, it's sometimes useful, and while it's definite, it's usually not finite, and it's not usually something you can picture in your head unless you're rather brilliant.
I bring it up, because understanding how to handle player state, as a game designer, inevitably ties in to handling the cartesian product: the cartesian product of the player state variables is the collection of all the possible permutations of all the variables.
If the variables were strength and agility, and those variables went from 1 to 3 each, the collection of permutations would be:
(str=1 agi=1,str=1 agi=2,str=1 agi=3,
str=2 agi=1,str=2 agi=2,str=2 agi=3,
str=3 agi=1,str=3 agi=2,str=3 agi=3)
Here, I've seperated each permutation with a comma.
That is, in other words, the cartesian product, and you can hopefully see what I mean when I say it is this product you need to keep in mind when designing a game...going by the above example, if the player only gets to level his stats twice, with a free choice between agility and strength, if you want to cover all your bases in a quest, you need to deal with both players who are 2str2agi, 3str1agi, and 1str3agi...since that's the possible player states at that time, supposing the player is forced to use level up points.
As you can see, all of these are present in the cartesian product above...the cartesian product, in other words, is the source of possibilities the player can expose the designer to, though it almost always contains permutations that couldn't happen at a specific point in a game.
Games are, by their nature, fun because they make manipulating the player state difficult. Handling player state, then, becomes a question of designing fun difficulties for the player. Thinking of the game designers job in this manner makes it seem ever-so-slightly sadistic, but regardless of what it seems like, it is what it is: You're out to stop the player from getting what he wants, to make him fight for it, and to (hopefully) make him beat you whilst he retains the illusion that you wanted to win too Which you didn't. But shh, lets keep quiet about that.
There's more to it than simply designing fun roadblocks though; you want the player to feel as though you are not limiting him, but rather, that he is limiting himself. For instance! the classic jump puzzle, while not very fun, makes the player limit where he walks because you punish him if he does do something else. Think of a room you as a player must walk across. If the state possible within the room is simply the entirety of the room floor, the room is boring. Clearly, where the player is able to walk has been limited by the designer. Put a chasm in the middle of the room, though, and have the player jump over the chasm or be forced to restart at the start of the room, and suddenly, both the player and you limit the player; see, the player limits himself by wishing to avoid the chasm. It doesn't really matter that you designed both obstacles; it doesn't matter if the chasm is a very small challenge to overcome...because it accomplishes the most important thing: the player is suddenly thinking in terms of what he wants to do, and what he wants to not do; not in terms of what you want him not to do.
Since we, as game designers, are forced to make sure our players don't do certain things (walk through our walls for example...he must stay on the path, as it were), it serves us well to try and design the fashion in which the player can change the player state in such a way that he inhibits himself, and thinks in terms of what he does and does not want to do. This, we do by making sure the player can be punished, if only ever so slightly, by being careless.
And that's really it; we should focus on making the hard edges in the player state soft, whereever possible...so instead of being constrained on a huge balchony, the player is on a huge balchony and part of the railing has come off so the player could possibly fall over, if he was careless.
This probably sounds...like a weird hypothesis, but I believe that this type of design is part of the reason Batman: Archam Asylum feels exceptionally free and open, in spite of being quite linear, and oftentimes quite constrained. The fact that you have choice, even if it's sometimes useless and clearly bad choice, it keeps the player making up his mind out the limits of the world, keeps him thinking...and that's really enough to make the player forget about the game designer and his artificial boundaries...
lørdag den 26. december 2009
Ancestry as a game element
The idea of bloodlines and ancestry - that one person is, merely because they were born from certain parents, important and carries within them a particular destiny is perhaps at the very root of elitism.
For that reason, I'd like to make the case that genetic (inherited) memory and will is an excellent concept for an interactive narrative.
Genetic memory can take many shapes and forms, but it's irremovably tied to ancestry - and your mum & pop. A person with person with a bloodline with genetic memory is, as a result, tied to his mom and dad. It could be further manipulated, such that only certain genders receive the full extent of the gift, as well as the ability to allow their children to inherit memory...these genders would not necessarily be set in stone, they could be alternating, or use some type of pattern, but the long and short of it is, a discussion of entitlement and strength can be brought into the narrative.
Genetic memory - which might be muscle memory, memory of crafts or meditative techniques, as well as memory of what has happened to every person in your bloodline coming before you - could be used as an excuse for attributing the players character with extraordinary abilities, and perhaps even the ability to converse with or be possed by his ancestors at his will or theirs.
It opens up many possibilities, but unlike so many, many stories, this one can be kept groomed - the Dollhouse TV series is doing something similar, but it's had a very difficult time getting going because it attempts high internal consistency, buffy the vampire slayer does it a bit, but only as a minor subplot, assasins creed does it, but doesn't use it for anything other than a starting point - and it's one of those "one magic thing" that people will accept in a narrative, yet it remains very specific.
When I say, one magic thing, it's because most stories only have one thing out of the ordinary - a focal concept. For example, if we were considering a world where everybody posses genetic memory, it wouldn't be "one magic thing" - it would merely be part of the setting. But take bumblebee in the transformers movie - it becomes sams car. We, as receivers, come to understand that we follow sam precisely because he is, through coincidence, fated to receive bumblebee. If it had come to someone else, the story would've been about them instead, not about sam.
Sam, however, cannot win the lottery the same day as he gets bumblebee, which would be another thing so unlikely that it would qualify as "the one magic thing". See, as unlikely as it is that a giant spacerobot becomes your car, it's part of the plot and the setting that it _must_ happen to _someone_ - the movie merely chooses to focus on the person it happens to.
But noone gets to be on the receiving end of two huge coincidences within the context of the same story - it's almost unheard of.
The thing about genetic memory is that it's not general, it's specific - it's not "magic", for example. If it had been magic...sure, our protagonist could have both magic and genetic memory if those things were tied together, being part of the same ability, but then, our protagonist would be much less predictable. Magic can do lots of things that the receivers of the story won't be able to predict; not so with genetic memory. It's nice and tight, but at the same time, presents a large amount of solutions.
So not only can it be used as the basis of a major narrative due to the relationships between characters the ability inherently projects and explains, it can also be used because it makes for interesting adventure and problem solving!
Now, notice that I say interactive narrative - I think this type of thing fits with narrative that allows choice particularly well, because ancestral preconceptions necessarily try to take choice away, and having a player deal with that seems like it could be almost existensial.
For that reason, I'd like to make the case that genetic (inherited) memory and will is an excellent concept for an interactive narrative.
Genetic memory can take many shapes and forms, but it's irremovably tied to ancestry - and your mum & pop. A person with person with a bloodline with genetic memory is, as a result, tied to his mom and dad. It could be further manipulated, such that only certain genders receive the full extent of the gift, as well as the ability to allow their children to inherit memory...these genders would not necessarily be set in stone, they could be alternating, or use some type of pattern, but the long and short of it is, a discussion of entitlement and strength can be brought into the narrative.
Genetic memory - which might be muscle memory, memory of crafts or meditative techniques, as well as memory of what has happened to every person in your bloodline coming before you - could be used as an excuse for attributing the players character with extraordinary abilities, and perhaps even the ability to converse with or be possed by his ancestors at his will or theirs.
It opens up many possibilities, but unlike so many, many stories, this one can be kept groomed - the Dollhouse TV series is doing something similar, but it's had a very difficult time getting going because it attempts high internal consistency, buffy the vampire slayer does it a bit, but only as a minor subplot, assasins creed does it, but doesn't use it for anything other than a starting point - and it's one of those "one magic thing" that people will accept in a narrative, yet it remains very specific.
When I say, one magic thing, it's because most stories only have one thing out of the ordinary - a focal concept. For example, if we were considering a world where everybody posses genetic memory, it wouldn't be "one magic thing" - it would merely be part of the setting. But take bumblebee in the transformers movie - it becomes sams car. We, as receivers, come to understand that we follow sam precisely because he is, through coincidence, fated to receive bumblebee. If it had come to someone else, the story would've been about them instead, not about sam.
Sam, however, cannot win the lottery the same day as he gets bumblebee, which would be another thing so unlikely that it would qualify as "the one magic thing". See, as unlikely as it is that a giant spacerobot becomes your car, it's part of the plot and the setting that it _must_ happen to _someone_ - the movie merely chooses to focus on the person it happens to.
But noone gets to be on the receiving end of two huge coincidences within the context of the same story - it's almost unheard of.
The thing about genetic memory is that it's not general, it's specific - it's not "magic", for example. If it had been magic...sure, our protagonist could have both magic and genetic memory if those things were tied together, being part of the same ability, but then, our protagonist would be much less predictable. Magic can do lots of things that the receivers of the story won't be able to predict; not so with genetic memory. It's nice and tight, but at the same time, presents a large amount of solutions.
So not only can it be used as the basis of a major narrative due to the relationships between characters the ability inherently projects and explains, it can also be used because it makes for interesting adventure and problem solving!
Now, notice that I say interactive narrative - I think this type of thing fits with narrative that allows choice particularly well, because ancestral preconceptions necessarily try to take choice away, and having a player deal with that seems like it could be almost existensial.
Progress on the conversation editor
Since I started working with off topic productions as the primary use case for the conversation editor project, much has happened with my plans.
As it turns out, the ideal tool has not been to handle persistence from within the context of the program itself, but rather, to merely load and save to file and have another program handle the persistence...it scales back the responsibility of the storyline editor considerably, but it also means that the writers will be stuck with generalized persistence management tools rather than custom tailored ones - at least for now.
We currently rely on an svn server to manage this - and in the future, if I do solve this problem with a custom tool, I will likely rely on the svn protocol. It works excellently with xml serialization, which is what we use now and what we'll be using going forward. There's an odd, but completely bearable, workflow currently tied to working with the program which is, currently, called Fabula.
The current Alpha version is done, but major refactoring has already commenced...the early focus has been on being able to model threaded conversations, which has been a success, but it's a far cry from what I eventually want to do. I'm afraid one of the things we will want is an emulator, which I will have to program after the next batch of minor changes has been implemented and refactoring is done. Fortunately, the theory behind everything is sound, and what I've used to program with is not likely to deprecate anytime soon...the only worry I could possibly have is that microsoft will deprecate WPF entirely, but that doesn't seem like it'll happen within 8-10 years.
As it turns out, the ideal tool has not been to handle persistence from within the context of the program itself, but rather, to merely load and save to file and have another program handle the persistence...it scales back the responsibility of the storyline editor considerably, but it also means that the writers will be stuck with generalized persistence management tools rather than custom tailored ones - at least for now.
We currently rely on an svn server to manage this - and in the future, if I do solve this problem with a custom tool, I will likely rely on the svn protocol. It works excellently with xml serialization, which is what we use now and what we'll be using going forward. There's an odd, but completely bearable, workflow currently tied to working with the program which is, currently, called Fabula.
The current Alpha version is done, but major refactoring has already commenced...the early focus has been on being able to model threaded conversations, which has been a success, but it's a far cry from what I eventually want to do. I'm afraid one of the things we will want is an emulator, which I will have to program after the next batch of minor changes has been implemented and refactoring is done. Fortunately, the theory behind everything is sound, and what I've used to program with is not likely to deprecate anytime soon...the only worry I could possibly have is that microsoft will deprecate WPF entirely, but that doesn't seem like it'll happen within 8-10 years.
Abonner på:
Opslag (Atom)