I am back to thinking about suitable narrative structures for CRPG games.
My current breakdown is something along the lines of:
* Linear narrative - Essentially there is one start and one ending, there may be more or less variability in the middle. (Think Max Payne )
* Broom narrative - Similar to the above but with the addition of a number of different endings. (Stalker is an example )
* Serial missions - One mission at a time usually with a strong theme. Can do branching but very expensive to develop whole mission modules that may not be played through.
* Mission Loom - From a single start point the rest of the game is composed of many small missions that overlap and weave together. Good for pickup games or for the OC gamer who wants to "complete" everything in the walkthroughs.
* Mission Loom with main thread(s) - One or more primary missions are presented to try to tie all the mini-missions together into a common theme? (Think Fallout 1,2,3 etc)
These are essentially all fragile systems that have modular segments that join together to create the narrative context for the play activities. They are fragile for a number of reasons, the first being that they have no capacity to be resilient to any errors in the chain. If one module fails ( for whatever reason) it conceptually leaves a gap. Even if the player somehow crosses the gap and gets back into the game, they have experienced the cognitive dissonance of having to "exit" the flow of the game to deal with the broken game engine/level script/ whatever bug. Obviously this is undesirable.
The second issue of fragility is to do with the Users perceptions of whats going on. Its fine to be able to tune a level until most users get it most of the time, but for complex storytelling that involves any subtlety ( which the debate is still open as to how many people would actually buy a game with too much subtle storytelling...stuff but anyway) there is no way to gauge if the user is following the storyline at a level they want or care about. (I use care to represent their level of engagement in the storyline rather than just their engagement in the game activities which can be a different kind of bear tickling)
So, to recap, the player can loose interest, loose the thread or fail to engage with it enough to differentiate the meta story from the game activities. (Not see the forest for the trees... so to speak)
The other sort of fragility I was thinking about is the temporal aspect. How to deal with the amount of playtime that the player wants to commit vs the time required to get through the narrative. Can the player commit more time if they enjoy the story or does the story have to fit the amount of time the player wants to commit? Both of these scenarios have ugly issues associated. Players are getting a little tired of "sticky" games that demand attention. (This whole issue has been soured by the MMORPGs and their subscription models.)
So players want a quality experience not a skinner box. Something that enriches their life rather than sucks it dry.
This is a similar issue to the one faced by television serials. Keep a narrative arc or make each episode self contained. Keep them wanting more or give them what they want? The eternal dilemma for media producers.
I have been reading an interesting post by someone about working inside a bounded time frame that has some interesting dimensions for writing. These ideas have mixed with an analysis I recently read of the "Robert Jordan - Wheel of Time" fiction series. One point of view is about how forcing us to work within a clearly bounded time frame helps sharpen everything you are doing while on the other hand, the book series was criticized because it wandered at times without boundary and so the quality suffered.
The point being that forcing a scenario or a narrative into a fixed time frame may be no bad thing. Especially a reasonably short one. Cinematic scripts are usually 120 pages which forces them to keep it tight (conceptually. Lets not argue about all the exceptions to this rule that exist.)
So how would that be applicable to game narratives, assuming game narratives are even well enough defined to be called such a thing.
If we are looking at a simple linear narrative, its easy to apply a fixed time to the narrative. It just keeps on ticking no matter what the player does. This forces the player to get with the program and stay with it. In effect punishing them pretty severely for making any mistakes or wandering around exploring.
Pick this up later.
Monday, November 8, 2010
Wednesday, November 3, 2010
Swapping keyboards is complicated
http://www.sense-lang.org/typing/games/balloon.php?key=EN
My current favorite typing tutor. I have swapped to a Kinesis Freestyle keyboard and its been a bit of an adaption curve. This site provides some useful exercises to help get me back up to speed.
I started by moving the whole keyboard to the ideal 30 degree split but found it too much too soon and put it back together. I have since been progressively moving the angle and adapting slowly. I am still not a fan of the key layout. I appreciate the loss of the numeric keypad but I have some kind of brain failure with the backspace and delete keys. I constantly seem to be getting them backward. Mainly because the delete key is approximately where I expect the backspace key to be which works the reverse of my intuitive expectation, then when I realize the mistake, I have to consciously think about the solution and it gets very messy. Suffice to say its working itself out but breaking long habits is challenging without the regular practice of a keyboard trainer.
The other irritating thing is the keys on the left hand side of the keyboard. They are essentially useless. They are sort of shortcut keys to reduce RSI but need to be completely learned. My biggest problem is I keep trying to feel for the lower left ctrl key which used to be the left most bottom key, but now its not. I keep hitting the shortcut key for context menus instead. Like I said, irritating but not life ending.
I have also been using the Evoluent upright mouse for a while. I would say that my adaption to it has been less useful. I still habitually try to hold it from the top down. And I find my coordination and precision is pretty crap when I do hold it the right way. Rather than driving from the wrist, I find I end up moving from the elbow which is much less precise. Probably from lack of practice. Still its a whole new set of muscles and nerves to train so it would be good to get some mouse training games happening.
I happened to do some timed testing tasks with it the other day and my coordination was a bit slower than usual and it made me feel like I was fighting the mouse rather than it being an intuitive extension of my hand.
Blah. I am still not game to try the Kinesis advantage keyboard. I'm worried that if I adapt to that I will get even less capable with all the normal keyboards I use every day. As a Tech I need to be able to work on any of the computers in the place and not being able to drive the keyboards I find would be a big disadvantage. I'm still wondering if I can maintain two similar sets of competency without making a mess of both (as usually happens for me)
My current favorite typing tutor. I have swapped to a Kinesis Freestyle keyboard and its been a bit of an adaption curve. This site provides some useful exercises to help get me back up to speed.
I started by moving the whole keyboard to the ideal 30 degree split but found it too much too soon and put it back together. I have since been progressively moving the angle and adapting slowly. I am still not a fan of the key layout. I appreciate the loss of the numeric keypad but I have some kind of brain failure with the backspace and delete keys. I constantly seem to be getting them backward. Mainly because the delete key is approximately where I expect the backspace key to be which works the reverse of my intuitive expectation, then when I realize the mistake, I have to consciously think about the solution and it gets very messy. Suffice to say its working itself out but breaking long habits is challenging without the regular practice of a keyboard trainer.
The other irritating thing is the keys on the left hand side of the keyboard. They are essentially useless. They are sort of shortcut keys to reduce RSI but need to be completely learned. My biggest problem is I keep trying to feel for the lower left ctrl key which used to be the left most bottom key, but now its not. I keep hitting the shortcut key for context menus instead. Like I said, irritating but not life ending.
I have also been using the Evoluent upright mouse for a while. I would say that my adaption to it has been less useful. I still habitually try to hold it from the top down. And I find my coordination and precision is pretty crap when I do hold it the right way. Rather than driving from the wrist, I find I end up moving from the elbow which is much less precise. Probably from lack of practice. Still its a whole new set of muscles and nerves to train so it would be good to get some mouse training games happening.
I happened to do some timed testing tasks with it the other day and my coordination was a bit slower than usual and it made me feel like I was fighting the mouse rather than it being an intuitive extension of my hand.
Blah. I am still not game to try the Kinesis advantage keyboard. I'm worried that if I adapt to that I will get even less capable with all the normal keyboards I use every day. As a Tech I need to be able to work on any of the computers in the place and not being able to drive the keyboards I find would be a big disadvantage. I'm still wondering if I can maintain two similar sets of competency without making a mess of both (as usually happens for me)
Labels:
Tech Support
VOIP SDK for Telemedicine app
http://blog.phono.com/2010/10/25/behind-the-phone/
This looks like a useful product for some of the telemedicine projects that are floating around. It uses SIP for brokering so I can pretend like I know something about it from my past research. Good to see someone making it more accessible. Version 2 will be very interesting.
This looks like a useful product for some of the telemedicine projects that are floating around. It uses SIP for brokering so I can pretend like I know something about it from my past research. Good to see someone making it more accessible. Version 2 will be very interesting.
Labels:
Frameworks,
Programming,
Telemedicine
Brain Science and Brain Training
http://www.cambridgebrainsciences.com/
Need to keep track of this as a brilliant set of samples. Kinda irritating because I have had to hack up a bunch of these tests for various experiments in the labs. These ones are much prettier than mine which suggests I need to get back to some flash at some point. Probably just before it all dies from HTML5... figures.
Need to keep track of this as a brilliant set of samples. Kinda irritating because I have had to hack up a bunch of these tests for various experiments in the labs. These ones are much prettier than mine which suggests I need to get back to some flash at some point. Probably just before it all dies from HTML5... figures.
Labels:
Games,
Research Resources
Fastflow Parallel Programming framework
http://calvados.di.unipi.it/dokuwiki/doku.php?id=ffnamespace:about
This looks very interesting. When I suddenly come across a bottle of "free Time" I might just have a drink and a think...
This looks very interesting. When I suddenly come across a bottle of "free Time" I might just have a drink and a think...
Labels:
Frameworks,
Programming,
todo
Clang and LLVM for C++ refactoring
http://clang.llvm.org/
Thank the Assembler, I don't have to do it myself. Not that I'm delusional enough to think that I could have, rather that I could see the need but there appeared to be no solution other than me doing it (somehow) myself.
Finally, I can start to dream of getting some re-factoring tools working for C++ and after that we can talk about high level transformation of code... better static analysis.... design extraction.... whooot! Well a boy can dream can't he?
Thank the Assembler, I don't have to do it myself. Not that I'm delusional enough to think that I could have, rather that I could see the need but there appeared to be no solution other than me doing it (somehow) myself.
Finally, I can start to dream of getting some re-factoring tools working for C++ and after that we can talk about high level transformation of code... better static analysis.... design extraction.... whooot! Well a boy can dream can't he?
Labels:
Programming Tools
Monday, November 1, 2010
Philosophy of hacking
Found an interesting post on Lifehacker
http://lifehacker.com/5672997/the-benefits-of-disobedience-why-we-hack
It wraps a philosophical context around the activity of hacking and the mindset. I doubt that many hackers have ever conceptualized their motivations in such a way but the piece does have a certain resonance. I certainly have never felt that disobedience was my motivation. Usually it was just my frugal farmboy upbringing that motivated me to fix whats broken and extend the life of anything that is useful. Growing up my reality was that if I couldn't fix it or make it, I didn't have it.
But back to the article. I can see the association that the author is making, and I think it has merit. Mainly because I can't really think of a good argument against it, but I am still wary of suggesting this argument captures the general motivation of most or all "hackers".
The argument gets a little shaky when you drill down into the semantics. "Disobedience" semantically is not really the over arching motivation for most hacking projects, I would suggest that in the way the author was using the term, its more a means to an end. In that a hacker has to "disobey" the rules not to do what they are doing, but they are doing it for "X" reason. "X" may be anything from fixing a bug, to adding features, to working out how something works to trying to impress someone and get lucky ... whatever. Disobedience is simply a means to an end.
The interesting implication that the author did not make was that the willingness and the ability to be disobedient are essential to successful hacking. The idea of not being afraid to "void your warranty" and not being afraid of "bricking it". This is essentially risk taking behavior in another form along with a degree of confidence combined with technical experience that leads one to suspect that something is possible.
To extrapolate this train of though, its possible to suggest that the environment of warranties and license agreements and all manner of other "rules" sets that impede the fairly natural instinct of "taking it apart to see what makes it tick" is an environment that habituates curious people to ignore these rules and thus be less worried about them in other aspects of their lives. Life is just more straight forward when you ignore most of these unenforceable rules ("Thou shalt not mod thy game console") and threats ( "void your warranty") and get on and hack your device/software/web service/file format etc into whatever shape you currently need.
I would also suggest that hacking is an emergent phenomenon in any complex structure. Once a system gets sufficiently complex, opportunities emerge for something else to find more direct ways to exploit resources within that system. This may not be to completely break the system, rather just to subvert parts. Look at all the parasites inside ant and bee colonies. These genomes have accidentally found strategies to hack an otherwise all encompassing system with no "legal" opportunities. The result being that they make out like bandits.
Alternately, look at any large organisation and consider all the "proper channels" and the way people naturally find ways to get their jobs done even when parts of the system are malfunctioning ( bad manager, poor communications, horrible enterprise software etc) people find ways around things and the more they get used to going around the obstacles, the less they "follow" correct procedure in other issues. Eventually they habitually look for the most straight forward way to achieve the ends and the system re-aligns or sections are discarded.
Hacking is all around us. Every day I see people who have no idea what's inside a computer or what to do with a hex editor hacking away at corporate systems. They use telephones to talk to other parts of the organisation and avoid sending emails through "proper channels" or they feed systems information and data that they know will be accepted, even though its technically wrong, just to avoid having to deal with broken enterprise software systems. They talk their way around problems and obstacles to get things done. These are not the idealized "geeks" taking apart technology and making things in their bedrooms but its still hacking systems to get results that are otherwise not possible. Are these people "disobedient"? In a way, certainly. Is their motivation "disobedience"? I think not. In many cases its very much the urge to keep the system working and to fit in and not be the "exception" that forces them to hack the system.
This leads to an interesting question. Will they continue to hack the system when the need is no longer there. Does this "breed" disobedience or will these people return to being rule abiding citizens once the enterprise software is fixed or the passive aggressive supervisor has been fired? Is "hacking" simply a case of people "finding the path of least resistance"?
I think there are some people who, having had to learn the skills and techniques of hacking their particular problem will never forget these skills. The question is if they will ever again be in an opportunity to need to employ them. For other people, I would guess that the discomfort threshold required to have to hack a system is sufficiently high that they will probably never go back to it, once the itch is scratched. Because, at the end of the day, Hacking is hard, risky and often involves swimming against the flow in many ways. This can include threats to comfort, safety and security ( loose a job, legal action, fines, social stigma etc) so these put pressure on some pretty basic motivations. Which means that generally the motivation to hack is dampened by many of the rules that the "system" has been constructed from, otherwise it would not be a system in the first place.
Ok, enough D&M.
http://lifehacker.com/5672997/the-benefits-of-disobedience-why-we-hack
It wraps a philosophical context around the activity of hacking and the mindset. I doubt that many hackers have ever conceptualized their motivations in such a way but the piece does have a certain resonance. I certainly have never felt that disobedience was my motivation. Usually it was just my frugal farmboy upbringing that motivated me to fix whats broken and extend the life of anything that is useful. Growing up my reality was that if I couldn't fix it or make it, I didn't have it.
But back to the article. I can see the association that the author is making, and I think it has merit. Mainly because I can't really think of a good argument against it, but I am still wary of suggesting this argument captures the general motivation of most or all "hackers".
The argument gets a little shaky when you drill down into the semantics. "Disobedience" semantically is not really the over arching motivation for most hacking projects, I would suggest that in the way the author was using the term, its more a means to an end. In that a hacker has to "disobey" the rules not to do what they are doing, but they are doing it for "X" reason. "X" may be anything from fixing a bug, to adding features, to working out how something works to trying to impress someone and get lucky ... whatever. Disobedience is simply a means to an end.
The interesting implication that the author did not make was that the willingness and the ability to be disobedient are essential to successful hacking. The idea of not being afraid to "void your warranty" and not being afraid of "bricking it". This is essentially risk taking behavior in another form along with a degree of confidence combined with technical experience that leads one to suspect that something is possible.
To extrapolate this train of though, its possible to suggest that the environment of warranties and license agreements and all manner of other "rules" sets that impede the fairly natural instinct of "taking it apart to see what makes it tick" is an environment that habituates curious people to ignore these rules and thus be less worried about them in other aspects of their lives. Life is just more straight forward when you ignore most of these unenforceable rules ("Thou shalt not mod thy game console") and threats ( "void your warranty") and get on and hack your device/software/web service/file format etc into whatever shape you currently need.
I would also suggest that hacking is an emergent phenomenon in any complex structure. Once a system gets sufficiently complex, opportunities emerge for something else to find more direct ways to exploit resources within that system. This may not be to completely break the system, rather just to subvert parts. Look at all the parasites inside ant and bee colonies. These genomes have accidentally found strategies to hack an otherwise all encompassing system with no "legal" opportunities. The result being that they make out like bandits.
Alternately, look at any large organisation and consider all the "proper channels" and the way people naturally find ways to get their jobs done even when parts of the system are malfunctioning ( bad manager, poor communications, horrible enterprise software etc) people find ways around things and the more they get used to going around the obstacles, the less they "follow" correct procedure in other issues. Eventually they habitually look for the most straight forward way to achieve the ends and the system re-aligns or sections are discarded.
Hacking is all around us. Every day I see people who have no idea what's inside a computer or what to do with a hex editor hacking away at corporate systems. They use telephones to talk to other parts of the organisation and avoid sending emails through "proper channels" or they feed systems information and data that they know will be accepted, even though its technically wrong, just to avoid having to deal with broken enterprise software systems. They talk their way around problems and obstacles to get things done. These are not the idealized "geeks" taking apart technology and making things in their bedrooms but its still hacking systems to get results that are otherwise not possible. Are these people "disobedient"? In a way, certainly. Is their motivation "disobedience"? I think not. In many cases its very much the urge to keep the system working and to fit in and not be the "exception" that forces them to hack the system.
This leads to an interesting question. Will they continue to hack the system when the need is no longer there. Does this "breed" disobedience or will these people return to being rule abiding citizens once the enterprise software is fixed or the passive aggressive supervisor has been fired? Is "hacking" simply a case of people "finding the path of least resistance"?
I think there are some people who, having had to learn the skills and techniques of hacking their particular problem will never forget these skills. The question is if they will ever again be in an opportunity to need to employ them. For other people, I would guess that the discomfort threshold required to have to hack a system is sufficiently high that they will probably never go back to it, once the itch is scratched. Because, at the end of the day, Hacking is hard, risky and often involves swimming against the flow in many ways. This can include threats to comfort, safety and security ( loose a job, legal action, fines, social stigma etc) so these put pressure on some pretty basic motivations. Which means that generally the motivation to hack is dampened by many of the rules that the "system" has been constructed from, otherwise it would not be a system in the first place.
Ok, enough D&M.
Labels:
Hardware Hacking,
Philosophy,
Rant
Subscribe to:
Comments (Atom)