In an earlier post, I referenced (in, what is necessitated by the nature of this blog assignment, something becoming an exercise in recursion - or perhaps redundancy or repetition) a series of articles at Gamasutra addressing the nature of "achievements" in games. I took a look at how one aspect of the referenced article examined achievement motivation and use in a pseudo-psychological paradigm (which, given my educational background, is an area of interest to me). I'd like to take another look at the third portion of this Gamasutra series (the previous post addressed the second) through the same lens, extending off of the end of my previous post's penultimate paragraph.
In that portion of my previous post, I mentioned that achievements may be used to "train" (and I use this word loosely) emergent behavior in a player of a video game. In the third portion of his feature The Cake Is Not a Lie: How to Design Effective Achievements, Lucas Blair addresses a similar idea: "Incremental and Meta-Achievements." What these are, effectively, is a practice of including "meta-wayfinding" as a game design element, or, as the author puts it, a trail of breadcrumbs. What's fascinating here - beyond the self-serving reinforcement of my own extrapolation of the topic - is the seeming lack of use of this as a teaching tool.
The author mentions that this can often be used to break large tasks down into discrete, more easily achievable subtasks -and this is true. I don't know that I would have originally thought of it like that, but it's a great way of looking at achievements or markers of progress that are repeated, only at higher increments or values (like, for example, a "kill 100 enemies/kill 200 enemies/kill 500 enemies" achievement "tree"). However, it's the other potential means of using achievements that I feel is maybe less prevalent in games: the idea of taking already-discrete tasks, awarding achievements for them, and then awarding an achievement for the completion of a grouping of them. Provided the player has a clear knowledge ahead of time - and this is important - of those tasks, this could be a great way to simply kill tutorial work. Alternatively - because there can be a very valid argument made for not wanting to award achievements for the menial sort of work that goes into early-game learning - these sort of achievement groupings could be used as a tool to gradually introduce mechanics over the course of a game or even to introduce complex, later-game mechanics without breaking the flow of the story to run a tutorial segment.
For the all the simplicity of achievements and perhaps lack of utility as a world-building tool, the author of the abovementioned article makes what I believe is a set of very good points about the potential un- or under-explored uses of achievements as tools in designing an effective game experience. I think that there's a great deal that could be explored if something like this were focused on as a more primary design element rather than the tacked-on piece that it often seems to be.
Monday, May 30, 2011
Week VIII
The last week of month two in the lab has been a slower one, compared to the flurry of activity that was last week. As mentioned a couple posts ago, the NFA project saw a small change in focus, and, as a result, a lot of the preliminary work and study has to be redressed.
Most of this week saw that put into action. The engine we're using for our project is Prepar3d, which is effectively the same engine used for Microsoft's Flight Simulator (X). We've - and by that I mean the production interns, not the development team - been using FSX as a testbed for a lot of the things we've done thus far (including the usability tests of the previous two weeks), but this week we dove into a little more of P3d, in order to test some of its specific features as they relate to the project. It has been an interesting experience, insomuch as it has afforded us the opportunity to use a much more sparse sandbox as a testing environment.
I also had a couple of opportunities to generate some pre-production documentation, which, while ordinarily would be quite prevalent, in the case of this project have been less so. It's a good exercise in rigor for me, since it lets me generate something directly relatable to my previous education.
One last thing - towards the end of the week, we had the opportunity to take a look at some of our trial junior interns and offer a couple of them the chance to work with us beyond their trial periods. It'll be nice to add a few more consistent faces to the lab, in light of the fact that we'll be having three of our full-fledged production interns leave in the next month. I know I'll look forward to working with both of the gentlemen we brought on - each one has been a notable help to both the lab as a whole and me personally in the past.
Most of this week saw that put into action. The engine we're using for our project is Prepar3d, which is effectively the same engine used for Microsoft's Flight Simulator (X). We've - and by that I mean the production interns, not the development team - been using FSX as a testbed for a lot of the things we've done thus far (including the usability tests of the previous two weeks), but this week we dove into a little more of P3d, in order to test some of its specific features as they relate to the project. It has been an interesting experience, insomuch as it has afforded us the opportunity to use a much more sparse sandbox as a testing environment.
I also had a couple of opportunities to generate some pre-production documentation, which, while ordinarily would be quite prevalent, in the case of this project have been less so. It's a good exercise in rigor for me, since it lets me generate something directly relatable to my previous education.
One last thing - towards the end of the week, we had the opportunity to take a look at some of our trial junior interns and offer a couple of them the chance to work with us beyond their trial periods. It'll be nice to add a few more consistent faces to the lab, in light of the fact that we'll be having three of our full-fledged production interns leave in the next month. I know I'll look forward to working with both of the gentlemen we brought on - each one has been a notable help to both the lab as a whole and me personally in the past.
Tuesday, May 24, 2011
The place for "1000 True Fans" in game production
Some years ago, a blog article entitled "1,000 True Fans" was published, and it immediately inspired a lot of feedback from the blogosphere. Now, this post isn't necessarily timely in that regard, but I'd like to take a look at the role that the concept of "1000 True Fans" may play in the gaming industry (specifically the "indie" portion of that).
Now, a short primer on the idea of "1000 True Fans:" the idea is that as a producer of any kind of art, it's unreasonable to expect massive popular success. It's somewhat daunting, then, as a beginning producer of any kind of art, to attempt to meet any kind of success. "1000 True Fans," then, redefines success not as wide popular appeal, but rather as having a cadre of dedicated supporters - one thousand "true fans." It's an issue of quality over quantity that is particularly relevant in the area of internet distribution, because it [the fans] represents a source or level of consistency.
Now, this is somewhat simplistic (more detail can be seen at the article, of course), and in fact, even the article isn't necessarily 100% accurate. However, the core concept is an intellectually (as well as emotionally, but that doesn't lend much credence to it) appealing one - the idea that garnering dedicated supporters is what is really necessary for success.
I think this is particularly relevant to the "indie" games production industry, because their business model is highly dependent on social and community involvement and in an arena (the internet) that doesn't lend itself to saturation of media/marketing. That said, the key for any - as the article calls them - "nurturers" of this kind of fan is to make a concerted effort to involve oneself of a deeper level than simply advertisement. Games in particular lend themselves well to this. So many discrete pieces go into a video game - concept art, individual models, sounds/music, prototypes - and many of these discrete pieces are much more easy to distribute regularly and often to an interested community, turning those with some minor interest into "true fans."
- and I think the regularity here is key: consistently reminding people that you exist and that you matter. By providing constant updates - even if they are only trivial - you continually engage a community and force them to move your game to the forefront of your mind. And after all, if they're thinking about it that often, it must be good, right? That's what I'd like to think they must tell themselves.
Now, a short primer on the idea of "1000 True Fans:" the idea is that as a producer of any kind of art, it's unreasonable to expect massive popular success. It's somewhat daunting, then, as a beginning producer of any kind of art, to attempt to meet any kind of success. "1000 True Fans," then, redefines success not as wide popular appeal, but rather as having a cadre of dedicated supporters - one thousand "true fans." It's an issue of quality over quantity that is particularly relevant in the area of internet distribution, because it [the fans] represents a source or level of consistency.
Now, this is somewhat simplistic (more detail can be seen at the article, of course), and in fact, even the article isn't necessarily 100% accurate. However, the core concept is an intellectually (as well as emotionally, but that doesn't lend much credence to it) appealing one - the idea that garnering dedicated supporters is what is really necessary for success.
I think this is particularly relevant to the "indie" games production industry, because their business model is highly dependent on social and community involvement and in an arena (the internet) that doesn't lend itself to saturation of media/marketing. That said, the key for any - as the article calls them - "nurturers" of this kind of fan is to make a concerted effort to involve oneself of a deeper level than simply advertisement. Games in particular lend themselves well to this. So many discrete pieces go into a video game - concept art, individual models, sounds/music, prototypes - and many of these discrete pieces are much more easy to distribute regularly and often to an interested community, turning those with some minor interest into "true fans."
- and I think the regularity here is key: consistently reminding people that you exist and that you matter. By providing constant updates - even if they are only trivial - you continually engage a community and force them to move your game to the forefront of your mind. And after all, if they're thinking about it that often, it must be good, right? That's what I'd like to think they must tell themselves.
Friday, May 20, 2011
Week Seven
The seventh week here in the UX lab has been a pretty busy one. Most - nay, all - of my time this week has been setting up the second version of our usability test for the NFA project. This time around, we had the chance to show it off for a few of our outside-of-school stakeholders, so we wanted to gussy it up a bit.
This gave me two goals for the week - revamp the test to take into account the feedback we received from the previous test cycle, one, and make the physical testing setup look a little more exciting, two. The first is a relatively straightforward task in its implementation, although it did require some time and testing. The second required a little more creativity - part of the goal for this was to set up a testing environment that would be a little closer to what would ultimately take place in the NFA experience. The real challenge there is creating something - something that works like a real flight simulator console might work - in a small computer lab that doesn't have any big 'ol flight simulator constructs sitting around for us to use.
Fortunately, I was able to scrounge together enough necessary material to create a slapdash pseudo-simulator cockpit (as seen below). We created a four-screen configuration that allows the pilot a panoramic forward-looking view on three screens and a below-mounted instrumentation panel for the fourth. In the center we had a joystick with throttle, and it was surrounded entirely by a makeshift cockpit shroud. It wasn't pretty, but it was functional and fit our purposes, and I think it'll be useful in the future as much as it was useful this week in administering our test.
And the test - this was Thursday. Our test was set up, as before, to examine the relationship between the JOC (radio officer) and the pilot in terms of communication, but we were able to do it in a way that created some more realistic challenges - among them were actual radio communication (versus the face-to-face communication of last week) and the introduction of other moving elements to the arena (aircraft that the pilot had to interact with). I think it went well; we were able to sort've show off what this project might look like in its implementation (and in doing so light some fires in people) at the same time as we were able to use the test to gather some useful usability data. I know that we have some plans to move forward with this, and I think that we can get some really useful front-end design information out of this as we move forward.
This gave me two goals for the week - revamp the test to take into account the feedback we received from the previous test cycle, one, and make the physical testing setup look a little more exciting, two. The first is a relatively straightforward task in its implementation, although it did require some time and testing. The second required a little more creativity - part of the goal for this was to set up a testing environment that would be a little closer to what would ultimately take place in the NFA experience. The real challenge there is creating something - something that works like a real flight simulator console might work - in a small computer lab that doesn't have any big 'ol flight simulator constructs sitting around for us to use.
Fortunately, I was able to scrounge together enough necessary material to create a slapdash pseudo-simulator cockpit (as seen below). We created a four-screen configuration that allows the pilot a panoramic forward-looking view on three screens and a below-mounted instrumentation panel for the fourth. In the center we had a joystick with throttle, and it was surrounded entirely by a makeshift cockpit shroud. It wasn't pretty, but it was functional and fit our purposes, and I think it'll be useful in the future as much as it was useful this week in administering our test.
And the test - this was Thursday. Our test was set up, as before, to examine the relationship between the JOC (radio officer) and the pilot in terms of communication, but we were able to do it in a way that created some more realistic challenges - among them were actual radio communication (versus the face-to-face communication of last week) and the introduction of other moving elements to the arena (aircraft that the pilot had to interact with). I think it went well; we were able to sort've show off what this project might look like in its implementation (and in doing so light some fires in people) at the same time as we were able to use the test to gather some useful usability data. I know that we have some plans to move forward with this, and I think that we can get some really useful front-end design information out of this as we move forward.
Monday, May 16, 2011
Achievement Unlocked! Peck button, turn on light (50G)
One of the things I tend to do - as do many who have had some educational background in psychology - is equate some aspect of psychology with whatever it is falls into my sphere of influence. This isn't entirely unwarranted, of course - psychology is the study of human behavior, and most everything involves some component of human action.
So, then, video games. A series of features over at Gamasutra goes in-depth to look at the nature and implementation of achievements, and in the second article, the author starts to look at some issues that smack of a lot of the psychology of gaming. In fact, they all relate to the psychology of play, but I'd like to focus on the portion of the article that addresses the timing of achievements, because it falls nearest to the realm of behavioral psychology.
But first, a short digression - behavioral psychology can be a dangerous topic to broach regarding humans, because it operates on a very fundamental, inhuman level and applying it to systems as complex as human thought and interaction is fairly reductionist. It works very well for explaining simple systems, like the cognition of animals (Skinner, et al.), but humans have such a large - and conflicting - set of motivations and goals that even if behavioral psychology were applicable, it would be like trying to graph a line whose path was determined by a chaotic system. That said, I believe behavioral psychology can still be used effectively to analyze single interactions one person makes with a system - just like this:
Okay, not just like that.
Anyway, to recover from my digression. In the article linked above, the author brings up the notion of adapting the timing of the conditioning, err, achievement - "When Achievement Notification Occurs" - to effectively manipulate the type of player being fed the achievement. This prompted the thought train (one that has no doubt been traveled on many times by many before me) of the notion of achievements being used as a fairly innocuous carrot-and-stick (or Skinner box pellet, to maintain the parlance). Since their advent, they've become a relatively unobtrusive means of offering notable and immediate feedback on player performance, and the idea, as the author of the "Achievements" article alludes to, that they can be used as a learning tool is a good one.
Achievements too may be able to effectively be used as a tool to promote what would otherwise be more "emergent"-type behavior. One of the ways behaviorism is used to train dogs (and here again is why I offer the caveat I do above) is to reward gradual changes in behavior to teach a complex action in parts. For example, a dog being taught to roll over may be rewarded first for sitting down, then for laying on its side, then for turning on its back, and then for finally rolling over (this is a highly simplified version of this). Without being too reductionist, I feel that this kind of reinforcement paradigm could be applied to a player using achievements.
There's really more to this subject than a simple blog post warrants, but I think it's something interesting to think about.
So, then, video games. A series of features over at Gamasutra goes in-depth to look at the nature and implementation of achievements, and in the second article, the author starts to look at some issues that smack of a lot of the psychology of gaming. In fact, they all relate to the psychology of play, but I'd like to focus on the portion of the article that addresses the timing of achievements, because it falls nearest to the realm of behavioral psychology.
But first, a short digression - behavioral psychology can be a dangerous topic to broach regarding humans, because it operates on a very fundamental, inhuman level and applying it to systems as complex as human thought and interaction is fairly reductionist. It works very well for explaining simple systems, like the cognition of animals (Skinner, et al.), but humans have such a large - and conflicting - set of motivations and goals that even if behavioral psychology were applicable, it would be like trying to graph a line whose path was determined by a chaotic system. That said, I believe behavioral psychology can still be used effectively to analyze single interactions one person makes with a system - just like this:
The Office - Pavlov's dog from Rauno Villberg on Vimeo.
Okay, not just like that.
Anyway, to recover from my digression. In the article linked above, the author brings up the notion of adapting the timing of the conditioning, err, achievement - "When Achievement Notification Occurs" - to effectively manipulate the type of player being fed the achievement. This prompted the thought train (one that has no doubt been traveled on many times by many before me) of the notion of achievements being used as a fairly innocuous carrot-and-stick (or Skinner box pellet, to maintain the parlance). Since their advent, they've become a relatively unobtrusive means of offering notable and immediate feedback on player performance, and the idea, as the author of the "Achievements" article alludes to, that they can be used as a learning tool is a good one.
Achievements too may be able to effectively be used as a tool to promote what would otherwise be more "emergent"-type behavior. One of the ways behaviorism is used to train dogs (and here again is why I offer the caveat I do above) is to reward gradual changes in behavior to teach a complex action in parts. For example, a dog being taught to roll over may be rewarded first for sitting down, then for laying on its side, then for turning on its back, and then for finally rolling over (this is a highly simplified version of this). Without being too reductionist, I feel that this kind of reinforcement paradigm could be applied to a player using achievements.
There's really more to this subject than a simple blog post warrants, but I think it's something interesting to think about.
Friday, May 13, 2011
Week, Mark VI
The sixth week has been strange. And busy. Strangely busy, even.
Early in the week, our NFA project saw a redirection, of a sort. Without going into detail, some of the players in charge changed, and the focus of the project is slightly different. What this meant for us is that much of our past work is either reduced in importance or simply unusable. This is okay by me, I think. It's a hassle, of course, but I can move on and adapt - as long as there is a direction, I don't mind being told that it's changing, as long as the resources are in place to move there. At this juncture, it looks like those resources will be in place, so I'm content enough.
This week has been primarily composed, hour-wise, of creating a usability test for the communication paradigm that is at the core of the experience, no matter what its direction is. That core is comprised of the relationship between the command and control personnel (the JOC) and the pilots. To test this, one of the other interns and I drew up a test plan to allow a pilot to fly through a short mission while following directions from and communicating with a radio control officer. We then organized the actual test using students from one of the earlier Masters' classes. I think we had a relatively successful and valuable first test; we gathered some helpful data that will benefit both the mission and education plan designers and our future iterations of the usability test. As we move into the next week, we're going to try and "shiny" up the test a little so that when some of the higher-ups from the project are in, they can see something really interesting - they'll be around for our next version of the usability test.
Early in the week, our NFA project saw a redirection, of a sort. Without going into detail, some of the players in charge changed, and the focus of the project is slightly different. What this meant for us is that much of our past work is either reduced in importance or simply unusable. This is okay by me, I think. It's a hassle, of course, but I can move on and adapt - as long as there is a direction, I don't mind being told that it's changing, as long as the resources are in place to move there. At this juncture, it looks like those resources will be in place, so I'm content enough.
This week has been primarily composed, hour-wise, of creating a usability test for the communication paradigm that is at the core of the experience, no matter what its direction is. That core is comprised of the relationship between the command and control personnel (the JOC) and the pilots. To test this, one of the other interns and I drew up a test plan to allow a pilot to fly through a short mission while following directions from and communicating with a radio control officer. We then organized the actual test using students from one of the earlier Masters' classes. I think we had a relatively successful and valuable first test; we gathered some helpful data that will benefit both the mission and education plan designers and our future iterations of the usability test. As we move into the next week, we're going to try and "shiny" up the test a little so that when some of the higher-ups from the project are in, they can see something really interesting - they'll be around for our next version of the usability test.
Sunday, May 8, 2011
Song of Time
In what seems to be a running theme, this post will likely end with an open-ended question. In sticking with the theme of this post, I'll be a little backwards and open with the question from the end: "What is serviced, from a developer standpoint, by adding stealthy hidden jokes, Easter eggs, etc. to games?"
This question is prompted by a short story that tickled my fancy from earlier this week. An intrepid audiophile noticed that, in the GDC 2011 trailer for Legend of Zelda: Skyward Sword, a reversed version of the "Zelda's Lullaby" leitmotif comprised a significant portion of the theme music. Now, I think this is a totally cool concept, but rather than waxing musical about the nifty-ness of clever use of a theme, I'll address something a little more relevant: where's the beef?
This is a trailer used at a highly-popular industry event for a series that carries both popular and historical appeal. It's probably a safe assumption that this kind of footage gets about as much attention as any kind of game-related promotional media. With all that, this is something that, even in this Internet age, takes two months to notice. If this were part of a scripted ARG, this would be an inexcusably(?) long time for the reveal of a plot point. It seems incredibly prominent for things that are traditionally hidden in the dark corners of a game (that is to say, Easter eggs). It seems placed in such a way that it is almost sure that it was designed to be found, but is that it? Is this just a clever promotional scheme? It seems counter-intuitive to design a theme track to a video game as a one-off promotional item.
I suppose, then, that the question asked at the beginning of the post would be better-phrased as this: "What is serviced, from a developer standpoint, by adding prominent Easter eggs, etc. to games?"
This is something that has served Valve well, notably with their recent Portal 2 ARG. Their use of this kind of material, however, has been serving an end - that is, a drawn-out game that inspires community and media participation. Something like this, though? I honestly can't say that it has precedent. Maybe I'm misconstruing proportions, but it seems like Nintendo's move is one made without a clear end (or an end that is simply a dead stop). It will be interesting to see, as the game's release draws closer, whether this is effectively used as a piece of continual marketing, or if it is as it seems - strangely anticlimactic.
This question is prompted by a short story that tickled my fancy from earlier this week. An intrepid audiophile noticed that, in the GDC 2011 trailer for Legend of Zelda: Skyward Sword, a reversed version of the "Zelda's Lullaby" leitmotif comprised a significant portion of the theme music. Now, I think this is a totally cool concept, but rather than waxing musical about the nifty-ness of clever use of a theme, I'll address something a little more relevant: where's the beef?
This is a trailer used at a highly-popular industry event for a series that carries both popular and historical appeal. It's probably a safe assumption that this kind of footage gets about as much attention as any kind of game-related promotional media. With all that, this is something that, even in this Internet age, takes two months to notice. If this were part of a scripted ARG, this would be an inexcusably(?) long time for the reveal of a plot point. It seems incredibly prominent for things that are traditionally hidden in the dark corners of a game (that is to say, Easter eggs). It seems placed in such a way that it is almost sure that it was designed to be found, but is that it? Is this just a clever promotional scheme? It seems counter-intuitive to design a theme track to a video game as a one-off promotional item.
I suppose, then, that the question asked at the beginning of the post would be better-phrased as this: "What is serviced, from a developer standpoint, by adding prominent Easter eggs, etc. to games?"
This is something that has served Valve well, notably with their recent Portal 2 ARG. Their use of this kind of material, however, has been serving an end - that is, a drawn-out game that inspires community and media participation. Something like this, though? I honestly can't say that it has precedent. Maybe I'm misconstruing proportions, but it seems like Nintendo's move is one made without a clear end (or an end that is simply a dead stop). It will be interesting to see, as the game's release draws closer, whether this is effectively used as a piece of continual marketing, or if it is as it seems - strangely anticlimactic.
Week 5.0
The fifth week of my internship has seen a couple interesting things: First, a delineation between a couple of the roles I'm fulfilling simultaneously, and second, a chance to really take some initiative and run things without constant oversight (not that I begrudge the oversight; it is of course critical to the very concept of an internship).
To address the first point; I've had the opportunity to work in both a design role and a production role - as has been mentioned beforehand - but this past week has seen some true compartmentalization of those roles. On the design hand, we've had a dedicated design team working on the planning for the NFA missions, and along with that come its own sundry meetings/objectives/etc. On the production hand, as in past weeks, we have had our own set of tasks and objectives; what has been notable about this week, though, has been the fact that the two roles have had their own parallel paths - they are not necessarily all managed by the same person and I have the opportunity to force myself to schedule the completion of tasks in a fashion that is not a straight line of dependencies.
The second point is one that in fact carries much over into next week (and with luck, many future weeks). As trivial as it may seem, it's enjoyable to be handed the keys to the car, even if it's just to drive into the driveway - and in that regard, I've been tasked this past week with organizing some minor events: a couple self-run meetings and a few interviews (it was enjoyable to be on the interviewer side of the table rather than the interviewee; it is an experience I suspect I should enjoy while it lasts). Regarding the latter, I was able to be the sole point of contact (for a time) for some of the new hires brought on to the team. Baby steps, but I enjoy the added responsibility.
One great thing is that with the more specific goals we're given, I can look into the next week with a clear list of objectives. There's always work to be done - to be sure! - but it is nice to be able to sit down on Monday, look at a notepad, and say, "Okay, I can get started on this."
To address the first point; I've had the opportunity to work in both a design role and a production role - as has been mentioned beforehand - but this past week has seen some true compartmentalization of those roles. On the design hand, we've had a dedicated design team working on the planning for the NFA missions, and along with that come its own sundry meetings/objectives/etc. On the production hand, as in past weeks, we have had our own set of tasks and objectives; what has been notable about this week, though, has been the fact that the two roles have had their own parallel paths - they are not necessarily all managed by the same person and I have the opportunity to force myself to schedule the completion of tasks in a fashion that is not a straight line of dependencies.
The second point is one that in fact carries much over into next week (and with luck, many future weeks). As trivial as it may seem, it's enjoyable to be handed the keys to the car, even if it's just to drive into the driveway - and in that regard, I've been tasked this past week with organizing some minor events: a couple self-run meetings and a few interviews (it was enjoyable to be on the interviewer side of the table rather than the interviewee; it is an experience I suspect I should enjoy while it lasts). Regarding the latter, I was able to be the sole point of contact (for a time) for some of the new hires brought on to the team. Baby steps, but I enjoy the added responsibility.
One great thing is that with the more specific goals we're given, I can look into the next week with a clear list of objectives. There's always work to be done - to be sure! - but it is nice to be able to sit down on Monday, look at a notepad, and say, "Okay, I can get started on this."
Subscribe to:
Posts (Atom)