The final week of my internship went out like a lion. There were a lot of things to keep us busy - mid-week, we had a presentation to give to stakeholders in the project, and at the end of the week, we had a deliverable due.
The good news is that we didn't crunch like we did two weeks prior to get the deliverable in. The bad news is that we still did, a tiny bit - the last day before the deliverable was due turned into a very late night. However, we as a team of producers really pulled it together and managed to (or were forced to) learn a whole lot of new things to get the mission in on time. That's a win in my book!
The presentation was a different kind of challenge - we had a nice presentation put together, but it was delivered in an open-forum-style atmosphere, and it turned into a long Q&A session, which is always difficult to manage. However, the stakeholders present seemed to be generally satisfied with the proceedings, and ultimately, that's a pretty good measure of success. We definitely came away with some things to work on and some things to try out, and I think it'll be good to get those into place.
This is also, as mentioned above, my last week. After five months - which has just flown by - I'll be done with this internship. I graduate this week, and I'll hopefully be working somewhere soon. I can't say with 100% certainty where, but it should pan out in the next couple of weeks. And so, to paraphrase the great halfling poet: though five months is too short a time to write for you - this is the END. I am going now. GOODBYE!
Monday, August 29, 2011
What's old is new again
Moore's law posits that computing power effectively doubles every two years. This has had a notable effect on the video game industry which, more than probably any other entertainment medium, relies on the power of computers to work.
What this seems to have done for the game industry is provide a scenario where games change rapidly in nature due to technology. This is interesting, because we get to see a contracted version of the evolution of trends in media - in video games, design trends seem to come and go with more speed than other media industries.
This all leads me to the thought process that went through my head as I read this article earlier this week. It was a highlight of a new game done in an old style - a visually pretty "point-and-click" dungeon crawler. Originally, this type of game was the product of software limitations - it was easier to produce a large world to explore if the world only had to be rendered in a series of 2-D images. Now, the type of game seems a callback at best and antiquated at worst - not that the nature of the game should necessarily be tied to the quality of it.
It seems only natural that older genre subtypes - at least those borne of technical limitation - should fade away. But what about their persistence (or even reintroduction), as in this case? One might think that these are simply pieces of nostalgia, relevant to a few but not really marketable (and consequently not really relevant to the industry at large).
However, games like New Super Mario Bros. Wii give the lie to this assertion.
The 2-D platformer was a product of a time where adventure games (and all games, really) were limited to side-to-side and up-and-down movement instead of movement in a 3-D space, and it's a product that has fallen out of vogue in recent years. It would seem, though, that either nostalgia has a much stronger effect on the purchasing population or that an enjoyable experience is an enjoyable experience, even when technology has passed up the very nature of the game.
It could be argued, of course, that the strength of the Mario IP (or other Nintendo IPs) could be responsible for the performance of these resurgent 2-D platformers. However, there's a strong counterargument against that: contemporary 3-D Mario games (Super Mario Galaxy-ies 1 and 2) - games which hold very high critical acclaim - still sell less than the NSMBW title. And not by a small margin - they have sold less by three or four times.
Now, I wouldn't advocate for a complete return to all earlier subgenres of video games, but perhaps it's possible that the things that made some early genres of games so good - ease of use, simplicity - the things that make games accessible - these may be easily and profitably translated to a modern gaming audience that craves easy access. I think the proof is already in the pudding.
What this seems to have done for the game industry is provide a scenario where games change rapidly in nature due to technology. This is interesting, because we get to see a contracted version of the evolution of trends in media - in video games, design trends seem to come and go with more speed than other media industries.
This all leads me to the thought process that went through my head as I read this article earlier this week. It was a highlight of a new game done in an old style - a visually pretty "point-and-click" dungeon crawler. Originally, this type of game was the product of software limitations - it was easier to produce a large world to explore if the world only had to be rendered in a series of 2-D images. Now, the type of game seems a callback at best and antiquated at worst - not that the nature of the game should necessarily be tied to the quality of it.
It seems only natural that older genre subtypes - at least those borne of technical limitation - should fade away. But what about their persistence (or even reintroduction), as in this case? One might think that these are simply pieces of nostalgia, relevant to a few but not really marketable (and consequently not really relevant to the industry at large).
However, games like New Super Mario Bros. Wii give the lie to this assertion.
The 2-D platformer was a product of a time where adventure games (and all games, really) were limited to side-to-side and up-and-down movement instead of movement in a 3-D space, and it's a product that has fallen out of vogue in recent years. It would seem, though, that either nostalgia has a much stronger effect on the purchasing population or that an enjoyable experience is an enjoyable experience, even when technology has passed up the very nature of the game.
It could be argued, of course, that the strength of the Mario IP (or other Nintendo IPs) could be responsible for the performance of these resurgent 2-D platformers. However, there's a strong counterargument against that: contemporary 3-D Mario games (Super Mario Galaxy-ies 1 and 2) - games which hold very high critical acclaim - still sell less than the NSMBW title. And not by a small margin - they have sold less by three or four times.
Now, I wouldn't advocate for a complete return to all earlier subgenres of video games, but perhaps it's possible that the things that made some early genres of games so good - ease of use, simplicity - the things that make games accessible - these may be easily and profitably translated to a modern gaming audience that craves easy access. I think the proof is already in the pudding.
Monday, August 22, 2011
If fear; while not suffering; anger++; hate++
Perusing the features this past week at Gamasutra, an article stood out - a student publication that broke down the implementation of "morality" systems into games.
It's easy to criticize morality features in games, and the author puts a deft touch on analysis of the issues with the "Bioware-standard" morality system. Normally, criticism of such systems focuses on the polarization of the divergent moral choices - either you're a saint or you're a demon. That's not an undue criticism, but the author goes beyond this. He mentions that the real problem is that the game forces the player toward poles of morality by tying gameplay mechanics into the morality system. The fact that many players often make mechanically sound choices in a game over narratively sound choices drives this - the same mechanism that drives players to choose optimal stats when configuring a character (over choosing more well-rounded stats) is what is moving this.
The author then goes on to assert that the best method is to divorce the morality system from main-line gameplay; to make it ancillary to the gameplay at most, irrelevant at least. He cites Dragon Age as an example - in that series, morality choices drive small story hooks and relationships with characters around you, but overt stats and story progression are largely untouched (it's not a perfect example, of course).
I think that there's a missed opportunity, though, if these faux-morality systems were gone completely. I think the problem may be that they're supposed to be stand-ins for morality - in that regard, they come up pretty short. There may be other places, though, where they work well. For example - my first experience with this kind of angel/devil "morality" setup was in Knights of the Old Republic, a game which, at the time, seemed revolutionary for its use of bilinear (or at least parallel) narrative. The morality system there was of course the Dark/Light sides of the Force, and even though it was simplistic, it fit stylistically within the context of the game universe.
So what is a designer to do? Can a game work with something like this without saying "this is Morality?" Maybe it can - I don't know of any reason that a game couldn't run parallel systems - one, this dual-phase pseudomorality that reacts to the player's actions, and two, the gameplay-divorced social morality that reacts to players' interactions.
It's easy to criticize morality features in games, and the author puts a deft touch on analysis of the issues with the "Bioware-standard" morality system. Normally, criticism of such systems focuses on the polarization of the divergent moral choices - either you're a saint or you're a demon. That's not an undue criticism, but the author goes beyond this. He mentions that the real problem is that the game forces the player toward poles of morality by tying gameplay mechanics into the morality system. The fact that many players often make mechanically sound choices in a game over narratively sound choices drives this - the same mechanism that drives players to choose optimal stats when configuring a character (over choosing more well-rounded stats) is what is moving this.
The author then goes on to assert that the best method is to divorce the morality system from main-line gameplay; to make it ancillary to the gameplay at most, irrelevant at least. He cites Dragon Age as an example - in that series, morality choices drive small story hooks and relationships with characters around you, but overt stats and story progression are largely untouched (it's not a perfect example, of course).
I think that there's a missed opportunity, though, if these faux-morality systems were gone completely. I think the problem may be that they're supposed to be stand-ins for morality - in that regard, they come up pretty short. There may be other places, though, where they work well. For example - my first experience with this kind of angel/devil "morality" setup was in Knights of the Old Republic, a game which, at the time, seemed revolutionary for its use of bilinear (or at least parallel) narrative. The morality system there was of course the Dark/Light sides of the Force, and even though it was simplistic, it fit stylistically within the context of the game universe.
So what is a designer to do? Can a game work with something like this without saying "this is Morality?" Maybe it can - I don't know of any reason that a game couldn't run parallel systems - one, this dual-phase pseudomorality that reacts to the player's actions, and two, the gameplay-divorced social morality that reacts to players' interactions.
Week XIX
This past week was a bit of a come-down from the week prior - not in terms of enjoyment, or excitement, but in terms of time spent. And I'm definitely okay with that, as the week prior was a bit of a bear. It's also my penultimate week here as an intern!
A lot of this week was preparation for a presentation I had to give on Friday. One of our requirements (as alluded to in the week twelve post) is to present to interested students and faculty a breakdown of what we've been doing all the time in our lab. This presentation is more substantial than the month three presentation I gave, and it gave a bit of my personal post-mortem on the project (so far, given that it's not entirely done). The presentation went well enough, and I got to touch base with a couple of my classmates who had been working in parallel internships, see what they had done, etc.
As far as the project, we keep moving forward. Our target of Mission 1 was met, and now our new target is Mission 2. We've spent some time fleshing out the second mission, and even fleshed-out it is less lengthy than the first, so it should be a little easier to manage in terms of completion. Next week we have to both buckle down on mission two and prepare an executive presentation for some of our stakeholders. It should be an auspicious last week to go out on!
A lot of this week was preparation for a presentation I had to give on Friday. One of our requirements (as alluded to in the week twelve post) is to present to interested students and faculty a breakdown of what we've been doing all the time in our lab. This presentation is more substantial than the month three presentation I gave, and it gave a bit of my personal post-mortem on the project (so far, given that it's not entirely done). The presentation went well enough, and I got to touch base with a couple of my classmates who had been working in parallel internships, see what they had done, etc.
As far as the project, we keep moving forward. Our target of Mission 1 was met, and now our new target is Mission 2. We've spent some time fleshing out the second mission, and even fleshed-out it is less lengthy than the first, so it should be a little easier to manage in terms of completion. Next week we have to both buckle down on mission two and prepare an executive presentation for some of our stakeholders. It should be an auspicious last week to go out on!
Monday, August 15, 2011
The Trademark Scrolls
The best type of examples I use for myself - when I'm looking at what the stumbles and trials of production can be - are the examples I see with indie producers/developers. I like watching these because they can often be extraordinarily public, since the indies don't have much in the way of compunction about being forthright with their issues.
It is with interest, then - at least in passing - that I've watched some of the trials of Notch in his rise to indie megastar. His most recent issue has been a bit of a hassle with the legal team from Bethesda Softworks in regards to his attempt to publish a game under the title "Scrolls." Bethesda is, of course, the developer of the highly popular "Elder Scrolls" series (although they are more commonly known by their episode title, e.g. "Oblivion" or "Morrowind").
What initially appeared to me to be an uneasy case of a larger publisher wielding a heavy hand has gradually morphed into a situation that I've allowed myself to learn is a bit more complex, and more importantly, it has been a valuable lesson on how taken in planning for generating IP can be critical in terms of reducing fallout.
An obvious, but necessary, caveat - as neither an involved party or a trademark lawyer, I certainly don't have the expertise to be fully accurate in my reflections here. What I initially saw here was this: Company "A" tries to publish game with similar-sounding title to game of Company "B," although those in-the-know would easily be able to distinguish between the two. I don't know that I was quite as initially reactionary as many, since I do understand the necessity of defending a trademark in order to keep it strong.
However, what I did intuit this as was a simple unfortunate situation that would eventually be resolved by the strong arm of a legal team. What I learned later, through various blog posts on the subject, was that the issue is a hairier one - Notch actually tried to trademark the "Scrolls" name. This would be fine, and eminently logical in most cases. However, it's not difficult to see how Bethesda is rightfully concerned in this case. Several pieces of commentary on the subject correctly pointed out that, at some undisclosed time in the future, if one company that was not Bethesda were to hold the trademark to "Scrolls" within the context of "fantasy video game" that spinoffs - like "Ancient Scrolls," or "Older Scrolls," or some other similar-sounding variant to "Elder Scrolls" - would be much harder to defend against, since the second trademark holder would be simply applying a modifier to their original trademark.
It was a point-of-view I hadn't considered, and I think that's it's a relatively well-thought-out one. What I can take from this is that ultimately, this may be a hard and embarrassing lesson for Notch to learn, and that moving forward as a producer, I can take away from this an understanding that (as in many areas) in IP development, an ounce of prevention can be worth a pound of cure.
It is with interest, then - at least in passing - that I've watched some of the trials of Notch in his rise to indie megastar. His most recent issue has been a bit of a hassle with the legal team from Bethesda Softworks in regards to his attempt to publish a game under the title "Scrolls." Bethesda is, of course, the developer of the highly popular "Elder Scrolls" series (although they are more commonly known by their episode title, e.g. "Oblivion" or "Morrowind").
What initially appeared to me to be an uneasy case of a larger publisher wielding a heavy hand has gradually morphed into a situation that I've allowed myself to learn is a bit more complex, and more importantly, it has been a valuable lesson on how taken in planning for generating IP can be critical in terms of reducing fallout.
An obvious, but necessary, caveat - as neither an involved party or a trademark lawyer, I certainly don't have the expertise to be fully accurate in my reflections here. What I initially saw here was this: Company "A" tries to publish game with similar-sounding title to game of Company "B," although those in-the-know would easily be able to distinguish between the two. I don't know that I was quite as initially reactionary as many, since I do understand the necessity of defending a trademark in order to keep it strong.
However, what I did intuit this as was a simple unfortunate situation that would eventually be resolved by the strong arm of a legal team. What I learned later, through various blog posts on the subject, was that the issue is a hairier one - Notch actually tried to trademark the "Scrolls" name. This would be fine, and eminently logical in most cases. However, it's not difficult to see how Bethesda is rightfully concerned in this case. Several pieces of commentary on the subject correctly pointed out that, at some undisclosed time in the future, if one company that was not Bethesda were to hold the trademark to "Scrolls" within the context of "fantasy video game" that spinoffs - like "Ancient Scrolls," or "Older Scrolls," or some other similar-sounding variant to "Elder Scrolls" - would be much harder to defend against, since the second trademark holder would be simply applying a modifier to their original trademark.
It was a point-of-view I hadn't considered, and I think that's it's a relatively well-thought-out one. What I can take from this is that ultimately, this may be a hard and embarrassing lesson for Notch to learn, and that moving forward as a producer, I can take away from this an understanding that (as in many areas) in IP development, an ounce of prevention can be worth a pound of cure.
Week the Eighteenth
So, last week, I made mention that there was a bit of a shotgun approach in terms of addressing pieces and parts of the project, and that this week I would have to move back into the more sharply focused attention onto one objective.
And boy did I. This week was all about getting mission 1 out the door, and that is pretty much all I did. At the beginning of the week, I started with three distinct missions that were relatively disjointed. The week was, then, all about making these three missions playable as one mission. This presented a challenge because this was not technically something the game supports out-of-the-box. What this really means was that there was a lot of overhead to address to make sure that the mission came together, far more than just simply polishing and testing it.
Over the course of this week, we managed to address not only the issue of attaching the missions together, but also the issues of recording and adding dialogue, getting new scenery in, setting up working cockpits/gauges for the craft, and getting the working animated models in game. This was all in addition to actually fleshing out the functionality of the mission. It was a lot of work, but we got it done, and I feel pretty good about the end product.
The overview of the mission, then, is this: there are three phases to the mission. In the first phase (which is narrated by the Wright Brothers), the player "flies" an albatross to learn about the principles of flight and learn how to control an aircraft in Flight Simulator. At the end of that phase, there is a short cutscene in which the Wrights talk about adapting the principles of flight to their gliders, and then the game transitions to a scene of them completing their first flight. The second phase of the mission involves the player participating in a fictitious contest to fly a Wright flyer farther than the original Wright flight. After completing that, the player takes control of a later version of the Wright Flyer in an expedition the Wrights put on for a crowd. All in all, the mission takes about 20-30 minutes to play through, and I'm looking forward to seeing what our client thinks about it.
And boy did I. This week was all about getting mission 1 out the door, and that is pretty much all I did. At the beginning of the week, I started with three distinct missions that were relatively disjointed. The week was, then, all about making these three missions playable as one mission. This presented a challenge because this was not technically something the game supports out-of-the-box. What this really means was that there was a lot of overhead to address to make sure that the mission came together, far more than just simply polishing and testing it.
Over the course of this week, we managed to address not only the issue of attaching the missions together, but also the issues of recording and adding dialogue, getting new scenery in, setting up working cockpits/gauges for the craft, and getting the working animated models in game. This was all in addition to actually fleshing out the functionality of the mission. It was a lot of work, but we got it done, and I feel pretty good about the end product.
The overview of the mission, then, is this: there are three phases to the mission. In the first phase (which is narrated by the Wright Brothers), the player "flies" an albatross to learn about the principles of flight and learn how to control an aircraft in Flight Simulator. At the end of that phase, there is a short cutscene in which the Wrights talk about adapting the principles of flight to their gliders, and then the game transitions to a scene of them completing their first flight. The second phase of the mission involves the player participating in a fictitious contest to fly a Wright flyer farther than the original Wright flight. After completing that, the player takes control of a later version of the Wright Flyer in an expedition the Wrights put on for a crowd. All in all, the mission takes about 20-30 minutes to play through, and I'm looking forward to seeing what our client thinks about it.
Friday, August 5, 2011
No such thing as a free lunch (for the delicatessen?)
For the past few months, one of my daily stops on the internet has been Amazon's Android app store. I don't often spend money on phone apps, but Amazon's store has given me a second gateway into trying out new things - they have a featured item that is their "Free App of the Day."
Often, it's something that's a whole lot of fun to try. I've picked up a couple productivity suites, which are nice, and I've picked up a couple of games I wouldn't have gotten otherwise, including popular games like Plants Vs. Zombies.
From a game developer's standpoint, though, it's interesting to think about the mechanism behind this. I recently read an article, that, while fairly self-evident (and couched in only a single anecdote), did at least prompt me to lend some fresh grey matter to that mechanism. The concept is a fairly simple one - offer a good for free for a certain period of time in exchange for attention. In this case, the attention is probably pretty significant. What was interesting in the abovementioned article, though, was that the particular developer being profiled saw no real uptick in sales as a result of all that attention (they did see a drain on resources, though, because of all the customer service they now had to provide to a slew of new users).
Now making the - admittedly dangerous - assumption that this is indicative of many app authors, it's interesting to work through this logically. It seems so pat, the idea of giving away "free samples" to entice users to a product. Why doesn't it work here?
I suppose that it may be working, albeit in a different way. Obviously one would expect sales to shoot high for a day, but maintain some small fraction of that momentum moving forward. Although that is not happening here, there may be a "double peak" effect that happens - the authors will see the obvious peak at the "free day," see the expected dip in sales, but then may see a second peak as the app starts to see press. I can't verify this, of course, and the article indicates that at least in this case, nothing like this was seen.
Another potential issue here may be that the short uptick in popularity represents an opportunity given to the developers, rather than the fulfillment of a previously-taken opportunity. The expansion of the user-base now may give them an "in" into a market for expansions, DLC, and the like. In the case of the article above, it's not necessarily the case that those authors took this advantage, and that may be where the true value lies.
Or, I suppose, it could simply be a well disguised benefit for Amazon and Amazon alone. It's tough to say, of course, but the job of a distribution channel like Amazon is certainly to make as much money off of managing their third-party content, and they may simply be exploiting that to its maximum.
Often, it's something that's a whole lot of fun to try. I've picked up a couple productivity suites, which are nice, and I've picked up a couple of games I wouldn't have gotten otherwise, including popular games like Plants Vs. Zombies.
From a game developer's standpoint, though, it's interesting to think about the mechanism behind this. I recently read an article, that, while fairly self-evident (and couched in only a single anecdote), did at least prompt me to lend some fresh grey matter to that mechanism. The concept is a fairly simple one - offer a good for free for a certain period of time in exchange for attention. In this case, the attention is probably pretty significant. What was interesting in the abovementioned article, though, was that the particular developer being profiled saw no real uptick in sales as a result of all that attention (they did see a drain on resources, though, because of all the customer service they now had to provide to a slew of new users).
Now making the - admittedly dangerous - assumption that this is indicative of many app authors, it's interesting to work through this logically. It seems so pat, the idea of giving away "free samples" to entice users to a product. Why doesn't it work here?
I suppose that it may be working, albeit in a different way. Obviously one would expect sales to shoot high for a day, but maintain some small fraction of that momentum moving forward. Although that is not happening here, there may be a "double peak" effect that happens - the authors will see the obvious peak at the "free day," see the expected dip in sales, but then may see a second peak as the app starts to see press. I can't verify this, of course, and the article indicates that at least in this case, nothing like this was seen.
Another potential issue here may be that the short uptick in popularity represents an opportunity given to the developers, rather than the fulfillment of a previously-taken opportunity. The expansion of the user-base now may give them an "in" into a market for expansions, DLC, and the like. In the case of the article above, it's not necessarily the case that those authors took this advantage, and that may be where the true value lies.
Or, I suppose, it could simply be a well disguised benefit for Amazon and Amazon alone. It's tough to say, of course, but the job of a distribution channel like Amazon is certainly to make as much money off of managing their third-party content, and they may simply be exploiting that to its maximum.
Week XVII
This past week has been different. Rather than "busy with a single purpose," as has been the previous few weeks, this week has kind've been a collection of a whole slew of mini-tasks getting done in rapid progression.
The week started out with a couple days that served to wrap up the past month. Our artists spent those first couple of days working on polishing aircraft for placement in the game as well as development of a presentation to give to art staff members. Their presentation went well, and I think it was really pretty beneficial to us, as it gave us a couple areas we as producers could improve in, in terms of providing certain kinds of information.
The rest of the week, in terms of mission development, has been kind've a holding pen. While last week we did have representatives travel to meet with the client, we didn't have a chance to glean a lot from the feedback until late in the week. As a result, we got to spend a lot of this week catching up on matters of documentation and organization, which I think can benefit us a lot as we do move forward into polishing old missions and creating new ones.
Next week is going to present its own new set of challenges. I'll have to work to combine three missions into one for a deliverable at the end of the week/beginning of the next, and there'll be a lot of polish that goes into making these presentable.
The week started out with a couple days that served to wrap up the past month. Our artists spent those first couple of days working on polishing aircraft for placement in the game as well as development of a presentation to give to art staff members. Their presentation went well, and I think it was really pretty beneficial to us, as it gave us a couple areas we as producers could improve in, in terms of providing certain kinds of information.
The rest of the week, in terms of mission development, has been kind've a holding pen. While last week we did have representatives travel to meet with the client, we didn't have a chance to glean a lot from the feedback until late in the week. As a result, we got to spend a lot of this week catching up on matters of documentation and organization, which I think can benefit us a lot as we do move forward into polishing old missions and creating new ones.
Next week is going to present its own new set of challenges. I'll have to work to combine three missions into one for a deliverable at the end of the week/beginning of the next, and there'll be a lot of polish that goes into making these presentable.
Tuesday, August 2, 2011
It's a mod, mod world
This is going to be a bit of a strawman, I'll be up-front about this. I hope that it's not too disingenuous to make a short post knowing this up-front, but... well, there you are.
Anyway, one recent announcement regarding Blizzard's oncoming Diablo III has stuck in the craw of a number of PC gaming aficionados. Looking at this from a gamer's perspective, I can see the impetus for some of the ire - as a fan of both making and using mods for PC games, it's a little bothersome to see a large company who, in the past, has not done little to support modding of their games withdraw that kind of support from a new game. On the other hand, as someone not invested in the series, I don't know that I have the same visceral reaction that long-term fans of the IP do in regards to this. Maybe this gives me some objectivity, maybe it simply means that I'm not informed enough.
Regardless, there's the other viewpoint - looking at it from the view of the developer. I can see through the announcement and realize that the real reason here is that they want to push for a persistently-internet-connected account for one real reason: to verify the legitimacy of the game. There's nothing wrong with this, of course, but it's a shame that even the single-player portion of the game doesn't have the modding accessibility.
This may be a bit of a divergence from the story at hand, but I'd like to wonder what kinds of tangible benefits (or maybe intangible benefits) developers and publishers see from an established modding community. Clearly, goodwill is an easily-cited one, but goodwill as an asset is difficult to quantify, both in terms of how widespread it is and how much value is seen from its presence. Another one is trying to make a little more money off of the long tail; trying to ensure that the game has a little more "longevity" and consequently more shelf life. This is probably also a little bit overestimated. I might say that one of the greatest benefits - and this could simply be me overestimating another factor - could be that modification support simply acts as a training ground for future contributors to their company. By ensuring that these people spend a long time with their game, it ensures brand loyalty, and by ensuring that those same people know their tools really well, it ensures a compatibility with that company and a desire to work there later on.
Anyway, one recent announcement regarding Blizzard's oncoming Diablo III has stuck in the craw of a number of PC gaming aficionados. Looking at this from a gamer's perspective, I can see the impetus for some of the ire - as a fan of both making and using mods for PC games, it's a little bothersome to see a large company who, in the past, has not done little to support modding of their games withdraw that kind of support from a new game. On the other hand, as someone not invested in the series, I don't know that I have the same visceral reaction that long-term fans of the IP do in regards to this. Maybe this gives me some objectivity, maybe it simply means that I'm not informed enough.
Regardless, there's the other viewpoint - looking at it from the view of the developer. I can see through the announcement and realize that the real reason here is that they want to push for a persistently-internet-connected account for one real reason: to verify the legitimacy of the game. There's nothing wrong with this, of course, but it's a shame that even the single-player portion of the game doesn't have the modding accessibility.
This may be a bit of a divergence from the story at hand, but I'd like to wonder what kinds of tangible benefits (or maybe intangible benefits) developers and publishers see from an established modding community. Clearly, goodwill is an easily-cited one, but goodwill as an asset is difficult to quantify, both in terms of how widespread it is and how much value is seen from its presence. Another one is trying to make a little more money off of the long tail; trying to ensure that the game has a little more "longevity" and consequently more shelf life. This is probably also a little bit overestimated. I might say that one of the greatest benefits - and this could simply be me overestimating another factor - could be that modification support simply acts as a training ground for future contributors to their company. By ensuring that these people spend a long time with their game, it ensures brand loyalty, and by ensuring that those same people know their tools really well, it ensures a compatibility with that company and a desire to work there later on.
Monday, August 1, 2011
Week Sixteen
The sixteenth week of my internship was a busy one. This has been a trend over the past couple of weeks, and I don't begrudge it - it's been fun working to push out content in addition to plans. We had a lot of work done from the week prior, but of the six missions we had to deliver, only three were close to complete - the other three were either not fully started or less than halfway done.
This wasn't a huge deal, of course - the reason for a lot of the slow start was that all of the people working on the missions had to learn the tools over the course of the month, and of course this necessitated a bit of lag time. We did run in to a pretty big roadblock, though, in that the day we were putting these missions together for delivery, one of the missions appeared to only work on the computer it was designed on (it used special software for its design, and it looked like its performance was constrained by the presence of that software). I ended up having to kick out a more "proof-of-concept" build of that mission in a couple hours, rather than the whole mission. So while it did get in the way of what we wanted to deliver, it was fun working in that kind of time pressure.
And we did manage to successfully deliver our missions, which was and is our measure of success. I know that I have more refinement to do on the missions I put together, but for the past month I know I've had a lot of fun learning a new set of tools and doing some world-building and designing along with my production responsibilities.
This wasn't a huge deal, of course - the reason for a lot of the slow start was that all of the people working on the missions had to learn the tools over the course of the month, and of course this necessitated a bit of lag time. We did run in to a pretty big roadblock, though, in that the day we were putting these missions together for delivery, one of the missions appeared to only work on the computer it was designed on (it used special software for its design, and it looked like its performance was constrained by the presence of that software). I ended up having to kick out a more "proof-of-concept" build of that mission in a couple hours, rather than the whole mission. So while it did get in the way of what we wanted to deliver, it was fun working in that kind of time pressure.
And we did manage to successfully deliver our missions, which was and is our measure of success. I know that I have more refinement to do on the missions I put together, but for the past month I know I've had a lot of fun learning a new set of tools and doing some world-building and designing along with my production responsibilities.
Monday, July 25, 2011
Trickle-down: The mirroring of real economies in virtual worlds
I'd like to start this by saying how incredibly unqualified I am to discuss this on a serious analytical level; I simply find the subject fascinating. That subject is, as indicated in the title, the presence of emergent economic structures in MMOGs, and it's covered in (part, but also in) great detail at this article at Gamasutra. I'll be referencing this (or at least using it as a starting point) as I go into digressions on a topic that I feel is interesting enough that I think I may have already written about it. I'm not sure, though.
Anyway, some perspective. I don't have a lot; I'll be the first to admit that, at least in the realm of MMOs. My only real experience with them was a browser-based Java MMO (Runescape) I enjoyed in my teens, that for all its simplicity, has seemed to do pretty well for itself. I haven't found the time or inclination to sink my free time into that kind of endeavor since then, but one of the things I know I found incredibly interesting at the time (and perhaps moreso, in retrospect) was the nature of the player-driven economy. I suppose what was interesting about it was the fact that it was player-driven.
I understand that there are more robust economies out there - the article referenced above uses both EVE Online and WoW as touchstones, and given their player bases it is not hard to see why. Their sizes alone should account for substantial evolution of a social economy. However, my benchmark can only be my experience.
The article linked above was a publication on "faucets" - those inputs and outputs of the economy. One of the first points made was that in virtual worlds, inputs have no real limit to them. While certain items can be limited in availability, most base items (fish, ores, wood, etc.) are effectively unlimited, unlike the Real World. This means that (with time as effectively an unlimited resource) gold can simply come from nowhere, gold that ostensibly retains as much value as the gold that already exists - inflation is not an issue since prices remain largely fixed. This seems to work, economically speaking, because large-scale increases in resources generated usually represent increases in player base, which represents a counterbalancing drain on the resources available.
The author also makes a point about specialization being an archaism in terms of virtual worlds. I think that I might diverge at this point, but I will do so with the caveat that this may simply represent my inexperience or limited awareness of the genre. One of the tools I've seen game developers use to combat this (although I'm not sure this is necessarily viewed as a weakness versus strength issue) is by making skills interdependent and by minimizing the amount of cross-pollination seen when training one skill. For example, in my experience, mining was most effective to train and use when one simply "gave up" his ores acquired - both reducing the impact on the economy and minimizing the opportunity to cross-pollinate (with skills like smithing). It was also in the player's best interest to specialize, as the ability level required to fully use all aspects of one resource (for example mining-smithing-crafting) was prohibitive enough to make it most financially viable to do one. Or maybe I'm simply talking out of my posterior. I can't really say.
The most interesting thing about the economy I'm familiar with, though, was the presence of true limited-input, available-to-all items, and it's a thing that I don't know that the author of the article addressed. One of the things I saw in the Runescape economy was the presence of limited-release "holiday" items (like New Years' hats or Santa Claus caps), and they were truly interesting because they served as benchmarks for the value of other items. Since they were unable to be increased in number in the game (and in fact could be removed, by turning them into gold or simply dropping them and letting them fade away), they maintained a relatively even value (all things considered). When new items were introduced, you could see how prices fluctuated and changed based on their percentage of the value of a party hat, for example.
I think that a large part of this is simply me looking up with wonder saying "Wow, gee, I can't believe these things exist." It's really quite exciting and quite interesting (anthropologically? sociologically?) to see that things of this complexity can really exist when we give enough people a sandbox and some time.
Anyway, some perspective. I don't have a lot; I'll be the first to admit that, at least in the realm of MMOs. My only real experience with them was a browser-based Java MMO (Runescape) I enjoyed in my teens, that for all its simplicity, has seemed to do pretty well for itself. I haven't found the time or inclination to sink my free time into that kind of endeavor since then, but one of the things I know I found incredibly interesting at the time (and perhaps moreso, in retrospect) was the nature of the player-driven economy. I suppose what was interesting about it was the fact that it was player-driven.
I understand that there are more robust economies out there - the article referenced above uses both EVE Online and WoW as touchstones, and given their player bases it is not hard to see why. Their sizes alone should account for substantial evolution of a social economy. However, my benchmark can only be my experience.
The article linked above was a publication on "faucets" - those inputs and outputs of the economy. One of the first points made was that in virtual worlds, inputs have no real limit to them. While certain items can be limited in availability, most base items (fish, ores, wood, etc.) are effectively unlimited, unlike the Real World. This means that (with time as effectively an unlimited resource) gold can simply come from nowhere, gold that ostensibly retains as much value as the gold that already exists - inflation is not an issue since prices remain largely fixed. This seems to work, economically speaking, because large-scale increases in resources generated usually represent increases in player base, which represents a counterbalancing drain on the resources available.
The author also makes a point about specialization being an archaism in terms of virtual worlds. I think that I might diverge at this point, but I will do so with the caveat that this may simply represent my inexperience or limited awareness of the genre. One of the tools I've seen game developers use to combat this (although I'm not sure this is necessarily viewed as a weakness versus strength issue) is by making skills interdependent and by minimizing the amount of cross-pollination seen when training one skill. For example, in my experience, mining was most effective to train and use when one simply "gave up" his ores acquired - both reducing the impact on the economy and minimizing the opportunity to cross-pollinate (with skills like smithing). It was also in the player's best interest to specialize, as the ability level required to fully use all aspects of one resource (for example mining-smithing-crafting) was prohibitive enough to make it most financially viable to do one. Or maybe I'm simply talking out of my posterior. I can't really say.
The most interesting thing about the economy I'm familiar with, though, was the presence of true limited-input, available-to-all items, and it's a thing that I don't know that the author of the article addressed. One of the things I saw in the Runescape economy was the presence of limited-release "holiday" items (like New Years' hats or Santa Claus caps), and they were truly interesting because they served as benchmarks for the value of other items. Since they were unable to be increased in number in the game (and in fact could be removed, by turning them into gold or simply dropping them and letting them fade away), they maintained a relatively even value (all things considered). When new items were introduced, you could see how prices fluctuated and changed based on their percentage of the value of a party hat, for example.
I think that a large part of this is simply me looking up with wonder saying "Wow, gee, I can't believe these things exist." It's really quite exciting and quite interesting (anthropologically? sociologically?) to see that things of this complexity can really exist when we give enough people a sandbox and some time.
Week XV
Week fifteen was a notable week in that it was a high-water mark in terms of importance of deliveries. While we did have the delivery of a prototype about a month ago, this week marked the push towards a set of deliveries that was about five times as large as the single prototype. To ice that particular cake, we also had to present these to our primary stakeholders on Friday. All in all, it was a lot to cover in a compressed timeframe.
I think we managed ourselves relatively well. Despite losing a day of capacity on Tuesday, we managed to get some relatively-polished (albeit incomplete) art for the first few missions. We're up to the point where we've got some high-detail models done without textures, and just recently our artists sat down to work out their pipeline for getting assets in-game. We have one in with a limited degree of success, and hopefully by the end of next week we should have all the rest. I'm looking forward to seeing the culmination of their efforts.
We also managed to push through a few playable missions, despite the missions not being tracked for completion until this upcoming Wednesday. We were all able to sit down and brief our stakeholders on our mission design, but I think what really sold it was our ability to put a couple into their hands and let them play through. That also provided us with a valuable opportunity to hear some very direct, very specific feedback that'll let us improve on our mission designs all the more.
This upcoming week should be pretty busy, given the amount of deadlines we have coming up, but having put that high-importance presentation behind us, I think I can look forward to this next week, especially since we will be able to start seeing the effort bear some nice-looking fruit.
I think we managed ourselves relatively well. Despite losing a day of capacity on Tuesday, we managed to get some relatively-polished (albeit incomplete) art for the first few missions. We're up to the point where we've got some high-detail models done without textures, and just recently our artists sat down to work out their pipeline for getting assets in-game. We have one in with a limited degree of success, and hopefully by the end of next week we should have all the rest. I'm looking forward to seeing the culmination of their efforts.
We also managed to push through a few playable missions, despite the missions not being tracked for completion until this upcoming Wednesday. We were all able to sit down and brief our stakeholders on our mission design, but I think what really sold it was our ability to put a couple into their hands and let them play through. That also provided us with a valuable opportunity to hear some very direct, very specific feedback that'll let us improve on our mission designs all the more.
This upcoming week should be pretty busy, given the amount of deadlines we have coming up, but having put that high-importance presentation behind us, I think I can look forward to this next week, especially since we will be able to start seeing the effort bear some nice-looking fruit.
Monday, July 18, 2011
The customer is always right
It's nice to hear, every once in a while, that you're doing something right. It was happy happenstance (happynstance?), then that I stumbled on this short essay at Gamasutra this past week. In this piece, the author describes a few case studies of applying usability testing to game development and the benefits seen via those tests.
The article can be boiled down (in a similar fashion to the article I looked at last week) to essentially "usability testing is good," which is a reductionist but perhaps necessary message for the game development community. It's nice to hear that validation, then, given the past focus we've taken in the lab on usability.
It wouldn't be fair, though, to say that our testing has taken place in an environment that may be directly translatable to a real game studio, given such issues as scale and budget. One of the best pieces of information I think I can draw from this article is the template provided for adapting usability testing to an agile environment - the idea of layering UX testing onto the end of a feature and minimizing the overhead of waiting for UX testing to finish by moving on to another discrete feature in the interim.
The article is also well-served by including a number of beneficial examples, but they simply serve to underscore (rather than elaborate upon) the original point ("usability testing is good"). The second-best part of the article likely comes from the comments and not the article itself, where an astute commenter makes note of the cost-to-implement versus time relationship - the primary selling point of usability testing in the event someone balks at spending additional money up-front.
The article can be boiled down (in a similar fashion to the article I looked at last week) to essentially "usability testing is good," which is a reductionist but perhaps necessary message for the game development community. It's nice to hear that validation, then, given the past focus we've taken in the lab on usability.
It wouldn't be fair, though, to say that our testing has taken place in an environment that may be directly translatable to a real game studio, given such issues as scale and budget. One of the best pieces of information I think I can draw from this article is the template provided for adapting usability testing to an agile environment - the idea of layering UX testing onto the end of a feature and minimizing the overhead of waiting for UX testing to finish by moving on to another discrete feature in the interim.
The article is also well-served by including a number of beneficial examples, but they simply serve to underscore (rather than elaborate upon) the original point ("usability testing is good"). The second-best part of the article likely comes from the comments and not the article itself, where an astute commenter makes note of the cost-to-implement versus time relationship - the primary selling point of usability testing in the event someone balks at spending additional money up-front.
Week #14
This fourteenth week continued in much the same way as the week prior - it was busy and there were a lot of people in the lab. It is a happy amount of activity that allows the lab a chance to feel a little more alive.
One other thing that's cropped up for the master's interns in our roles as producers/designers/jacks-of-all-trades has been the development of the missions themselves. This is a fun aspect of the project to work on for me personally, since I enjoy level design, and it's a fun chance to try and work out solutions to scripting problems by way of a difficult tool. It may be a little strange, but I've always enjoyed having constraints put on means of solving a problem, as I feel that it allows me to be more creative. In this case, the constraints of the tool - its unwieldiness and limitations - let me contextually apply my creativity.
Another challenge in the roles of mission design is in turning historical events into playable game experiences. I've been working specifically with the historical (and historic) flight of the Wright Flyer. The historically-inclined might remember that this was originally more of a "proof-of-concept" than anything else, since the first flight was about forty yards in total. This doesn't make for a very exciting experience, though, and so it's fallen to me to try and suss a little more out of this than might otherwise exist. It's been fun, but we'll see what those who eventually end up using this have to say about the idea.
In sum, though, I'm really quite enjoying what I'm doing. The hybrid of management and design that I get to do hits a couple separate points on my fun-meter, and I definitely appreciate the range of experience I'm getting now.
One other thing that's cropped up for the master's interns in our roles as producers/designers/jacks-of-all-trades has been the development of the missions themselves. This is a fun aspect of the project to work on for me personally, since I enjoy level design, and it's a fun chance to try and work out solutions to scripting problems by way of a difficult tool. It may be a little strange, but I've always enjoyed having constraints put on means of solving a problem, as I feel that it allows me to be more creative. In this case, the constraints of the tool - its unwieldiness and limitations - let me contextually apply my creativity.
Another challenge in the roles of mission design is in turning historical events into playable game experiences. I've been working specifically with the historical (and historic) flight of the Wright Flyer. The historically-inclined might remember that this was originally more of a "proof-of-concept" than anything else, since the first flight was about forty yards in total. This doesn't make for a very exciting experience, though, and so it's fallen to me to try and suss a little more out of this than might otherwise exist. It's been fun, but we'll see what those who eventually end up using this have to say about the idea.
In sum, though, I'm really quite enjoying what I'm doing. The hybrid of management and design that I get to do hits a couple separate points on my fun-meter, and I definitely appreciate the range of experience I'm getting now.
Monday, July 11, 2011
So, about those TPS reports
I often like to take a look at some element of design in these posts, since design is a process near and dear to my heart. This is often to the detriment of taking a look at the elements of production, which is possibly simply a result of the fact that talking about design makes for prettier (or more exciting) copy.
Perhaps in an effort to remedy that, I'll take this time to reflect on production and its importance, as always, vis a vis an article somebody more knowledgeable than I wrote.
Data mining almost always yields interesting results - not necessarily exciting, but usually interesting. More the "meat and potatoes"-type article versus the "Maine lobster"-type article you see with other types of writing. In this case, there is a lot of digression off of some sets of data that all demonstrate the same thing: production is kind've a big deal.
Based on the data culled from several postmortems, the author of the article points out a major trend: in areas of both "what went right" and "what went wrong," the majority of issues were production-related (and in fact in the "what went wrong" category, there was a true majority - 56% - of issues related to production). What this speaks to is obviously a collective cry for competent organization and management, which is nothing necessarily new or ground-breaking, but a nice reinforcement nevertheless.
The article is more than just a dissertation on the value of production, of course. There are other common elements that pop up in this kind of mass-retrospective. It's most interesting and notable (and germane, in my case), though, to take a look at how often production shows up as a source of a surfeit of both problems and successes.
Perhaps in an effort to remedy that, I'll take this time to reflect on production and its importance, as always, vis a vis an article somebody more knowledgeable than I wrote.
Data mining almost always yields interesting results - not necessarily exciting, but usually interesting. More the "meat and potatoes"-type article versus the "Maine lobster"-type article you see with other types of writing. In this case, there is a lot of digression off of some sets of data that all demonstrate the same thing: production is kind've a big deal.
Based on the data culled from several postmortems, the author of the article points out a major trend: in areas of both "what went right" and "what went wrong," the majority of issues were production-related (and in fact in the "what went wrong" category, there was a true majority - 56% - of issues related to production). What this speaks to is obviously a collective cry for competent organization and management, which is nothing necessarily new or ground-breaking, but a nice reinforcement nevertheless.
The article is more than just a dissertation on the value of production, of course. There are other common elements that pop up in this kind of mass-retrospective. It's most interesting and notable (and germane, in my case), though, to take a look at how often production shows up as a source of a surfeit of both problems and successes.
Friday, July 1, 2011
Week the Thirteenth
Week thirteen of my internship has been a change of pace. For the past three months, we've been slowly making headway on the NFA project (with the occasional start and stop and change of direction), but this past week marked a high-water point: we got busy.
Three of the interns with whom I have been working for the past few months graduated this week, and so we brought on three new interns to replace them. We got the chance to sit down with them, bring them up to speed, and help start working on parts of the project. That part, I expected coming in this week. The part that was a little bit more of a surprise was that we brought in a little more than ten other new people on the project. The vast majority of those were art interns who'll be working on the project full-time (as their classes permit), and it's really interesting - and a notable change - to see eight artists working with us in our lab. Everything is much, much busier-feeling. We also brought in a pair of new part-time master's interns and a quartet of new part-time development interns.
To top that all off, we got another course correction in terms of project direction, and while this was a little more expected, it still feels a lot like starting a new project. It is both interesting on the one hand, because we are moving closer to the real-life realism level that I'd prefer for a project like this, and challenging on the other, because we have to set the course for a whole slew of people who may not be as self-directing as our previous team was (which is to be expected, given that we are working with substantially more students as resources this time).
All in all, I think it'll be a lot of fun - since I've had a few months of experience with the project, I do feel truly capable to lead this group. I'm glad for the continual changes in pace; they can only be a boon in the end.
Three of the interns with whom I have been working for the past few months graduated this week, and so we brought on three new interns to replace them. We got the chance to sit down with them, bring them up to speed, and help start working on parts of the project. That part, I expected coming in this week. The part that was a little bit more of a surprise was that we brought in a little more than ten other new people on the project. The vast majority of those were art interns who'll be working on the project full-time (as their classes permit), and it's really interesting - and a notable change - to see eight artists working with us in our lab. Everything is much, much busier-feeling. We also brought in a pair of new part-time master's interns and a quartet of new part-time development interns.
To top that all off, we got another course correction in terms of project direction, and while this was a little more expected, it still feels a lot like starting a new project. It is both interesting on the one hand, because we are moving closer to the real-life realism level that I'd prefer for a project like this, and challenging on the other, because we have to set the course for a whole slew of people who may not be as self-directing as our previous team was (which is to be expected, given that we are working with substantially more students as resources this time).
All in all, I think it'll be a lot of fun - since I've had a few months of experience with the project, I do feel truly capable to lead this group. I'm glad for the continual changes in pace; they can only be a boon in the end.
Monday, June 27, 2011
I have honestly no idea if this is even going to make sense
In these blog posts, I often like to digress a little about something interesting in the world of game development, and one of my more charming (infer whatever level of facetiousness you care to there) characteristics is my tendency towards my digressions being of a somewhat convoluted and long nature.
I don't know that I'm heading down an especially long trail in this blog post, but I think that a lot of the logic I'll be linking pieces together with will be tenuous at best (thus the title). I also don't know specifically where I care to end this piece, so there's also that.
Anyway, one of the big stories in the games world this week was the furor that arose from the EVE Online community concerning CCP's introduction of microtransaction items that were comparatively prohibitively expensive. I won't go into great detail, since it has been covered better and more thoroughly by many whose knowledge of the game and situation are greater than mine, but I do want to use it as a jumping-off point to talk about emergent systems in games.
The crux of the EVE community's concern seems to be how this will interact with their economy. Or maybe it isn't. That's not the point anymore, since I've successfully used this to segue into a talk about MMO economies. MMORPG economies are a thing of real interest to me - they're really fascinating, and even before I was interested in game development, I realized that these were something special: complete systems of interaction that used a game as a medium but not necessarily as a facilitator. This is a clear peak of emergent gameplay, which is something that any smart designer (and here is where I start speaking in ignorance, perhaps) should strive for.
Right? Emergent gameplay! It's the best possible investment for a developer, since it represents hours of play the end user can enjoy without any specific development on the developer's part. Right?
At least it seems that way to me, and what's interesting is to see how something so obviously emergent and so incredibly intricate as a player-built economy springs to life. My guess would be that this is a natural extension of social groups forming, and when you look at how cultures form over history, certain institutions pop up - families, governments, economies - all things tied together with some level of tacit agreement about how people will interact and work within a system. Video games see these things develop too (players are people, after all) in any situation where lots of players must interact - families become "buddy lists," or governments become "clans," etc.
What I was thinking, though, is that as one starts to look back at early societies, early societies banded together with specific goals in mind, not things so ephemeral as we see the "happier" social constructs of MMOs are (those things like families). Early groups of people banded together for survival and for extra-group acquisition of resources. Maybe this is a poor assumption, and if so, well, there it is. In any case, I don't know that games have ever done this, or that games currently can - forcing a "survival" mechanic implies some level of fear/awareness of danger, which is probably outside of what games should do, and it implies some level of solitude, which is probably beyond the scope of games right now. After all, people play social games to be social, right?
I think that there is an interesting case to be made for a survival-type game to be enjoyable: Minecraft. It's not the first of the "survival" kind, and in fact that mechanic is not even its main draw. However, I think that the flexibility of the game and the allowed creativity provides a means for the survival mechanic (one in which the player is intentionally isolated) to work well. I think that in that light, as hardware allows for more extensively-sized worlds, tossing players into that kind of situation where they are alone, but they just may encounter other players - that may lead to the rise of that untapped area of social emergent gameplay - the "cave people"-type banding together for survival and resources. I believe that it would be an exciting phenomenon for game designers and anthropologists both to see how those societies eventually formed.
I don't know that I'm heading down an especially long trail in this blog post, but I think that a lot of the logic I'll be linking pieces together with will be tenuous at best (thus the title). I also don't know specifically where I care to end this piece, so there's also that.
Anyway, one of the big stories in the games world this week was the furor that arose from the EVE Online community concerning CCP's introduction of microtransaction items that were comparatively prohibitively expensive. I won't go into great detail, since it has been covered better and more thoroughly by many whose knowledge of the game and situation are greater than mine, but I do want to use it as a jumping-off point to talk about emergent systems in games.
The crux of the EVE community's concern seems to be how this will interact with their economy. Or maybe it isn't. That's not the point anymore, since I've successfully used this to segue into a talk about MMO economies. MMORPG economies are a thing of real interest to me - they're really fascinating, and even before I was interested in game development, I realized that these were something special: complete systems of interaction that used a game as a medium but not necessarily as a facilitator. This is a clear peak of emergent gameplay, which is something that any smart designer (and here is where I start speaking in ignorance, perhaps) should strive for.
Right? Emergent gameplay! It's the best possible investment for a developer, since it represents hours of play the end user can enjoy without any specific development on the developer's part. Right?
At least it seems that way to me, and what's interesting is to see how something so obviously emergent and so incredibly intricate as a player-built economy springs to life. My guess would be that this is a natural extension of social groups forming, and when you look at how cultures form over history, certain institutions pop up - families, governments, economies - all things tied together with some level of tacit agreement about how people will interact and work within a system. Video games see these things develop too (players are people, after all) in any situation where lots of players must interact - families become "buddy lists," or governments become "clans," etc.
What I was thinking, though, is that as one starts to look back at early societies, early societies banded together with specific goals in mind, not things so ephemeral as we see the "happier" social constructs of MMOs are (those things like families). Early groups of people banded together for survival and for extra-group acquisition of resources. Maybe this is a poor assumption, and if so, well, there it is. In any case, I don't know that games have ever done this, or that games currently can - forcing a "survival" mechanic implies some level of fear/awareness of danger, which is probably outside of what games should do, and it implies some level of solitude, which is probably beyond the scope of games right now. After all, people play social games to be social, right?
I think that there is an interesting case to be made for a survival-type game to be enjoyable: Minecraft. It's not the first of the "survival" kind, and in fact that mechanic is not even its main draw. However, I think that the flexibility of the game and the allowed creativity provides a means for the survival mechanic (one in which the player is intentionally isolated) to work well. I think that in that light, as hardware allows for more extensively-sized worlds, tossing players into that kind of situation where they are alone, but they just may encounter other players - that may lead to the rise of that untapped area of social emergent gameplay - the "cave people"-type banding together for survival and resources. I believe that it would be an exciting phenomenon for game designers and anthropologists both to see how those societies eventually formed.
Week XII
This twelfth week of my internship marked the completion of my third month of the internship period and the completion of my final class in the degree here, which is - as discussed at length with my fellow interns - cause for some degree of celebration. It is, if for no other reason than this month with class has given me a sense of perspective - I know what I can do when I have a month with totally open capacity (month two) and I know what a month of reduced capacity can mean in terms of how I feel about what I'm getting done.
Looking at what actually got done this week, though, demonstrates probably an accurate microcosm of the difficulty I've had this month in managing both a class and the internship. We didn't necessarily have a lot to do on the NFA project (as it was somewhat of a slack week following the delivery of the prototype), which was good, because most of my week was taken up with presentation preparation, which is both for and not for the internship.
Given that it was the final week of a class, and given that classes often have a project that caps off the curriculum, it should be no surprise that I needed to spend time working on that. I won't digress too far into the details of that, as it is primarily unrelated to the internship, but the content of that project was tangentially focused on the NFA. I spent a lot of time working on this unfortunate, eye-rolling-ly amateurish "trailer" (which I use loosely, given its complete non-relation, content-wise) for the NFA:
I also spent more productive hours preparing my month-three brief on what it was, exactly, that I'd been spending my time on in the internship. It was enjoyable to stand up and lay out exactly what it was I've worked on and learned, and it was nice to be able to list all those things that - in fact - I did garner from my time here.
I know that I'm looking forward to the next (and final) two months of this internship, as I start to move forward with a continually-refined direction for the NFA and to move forward with some of the new interns we're bringing on.
Looking at what actually got done this week, though, demonstrates probably an accurate microcosm of the difficulty I've had this month in managing both a class and the internship. We didn't necessarily have a lot to do on the NFA project (as it was somewhat of a slack week following the delivery of the prototype), which was good, because most of my week was taken up with presentation preparation, which is both for and not for the internship.
Given that it was the final week of a class, and given that classes often have a project that caps off the curriculum, it should be no surprise that I needed to spend time working on that. I won't digress too far into the details of that, as it is primarily unrelated to the internship, but the content of that project was tangentially focused on the NFA. I spent a lot of time working on this unfortunate, eye-rolling-ly amateurish "trailer" (which I use loosely, given its complete non-relation, content-wise) for the NFA:
I also spent more productive hours preparing my month-three brief on what it was, exactly, that I'd been spending my time on in the internship. It was enjoyable to stand up and lay out exactly what it was I've worked on and learned, and it was nice to be able to list all those things that - in fact - I did garner from my time here.
I know that I'm looking forward to the next (and final) two months of this internship, as I start to move forward with a continually-refined direction for the NFA and to move forward with some of the new interns we're bringing on.
Monday, June 20, 2011
Press "?" to skip
To immediately digress from the topic not yet conceived, one of my favorite console series of games is the Final Fantasy series. Fitting easily on any "top five" video game list I could conceive would be the tenth iteration in the series, one that justified (in my mind) the purchase of a whole new console to play it on. Final Fantasy 11 came and went, as it was a MMO-aligned offering (and I don't "do those," out of some measure of fear for lack of self-control or some measure of self-control, depending on whether I feel particularly pessimistic or optimistic at any given time). Final Fantasy 12 arrived at a time in my life when I was otherwise distracted with school and knew better than to involve myself in something particularly time-consuming.
It was with anticipation, then, that I looked at Final Fantasy XIII - I knew that the series would remain enjoyable, because I know that it is in myself to enjoy the kind of "interactive storybook" these games are dually admired and admonished for being. That game lived up to its promise, for me. Others found it lacking, and it's not incredibly difficult to see why, no matter what my personal assessment of the game. The chief complaint was the feeling of participating in an over-long "tutorial" sequence wherein the player is gradually introduced to game concepts over the first several hours of the game.
This is perhaps an exaggeration of the actual in-game experience, but the core issue is one of the feeling of loss of player agency, which is a topic addressed well in Ernest Adams's "The Designer's Notebook: Eight Ways To Make a Bad Tutorial" at Gamasutra.
The gist of the article is made clear in its title - it's a list of common mistakes in implementing tutorial sections in games. The article is not necessarily corrective or constructive (and the author acknowledges that), but what it does do well is presenting a list of errors that will be familiar to anyone who feels he's sat through a poor tutorial segment. The "eight ways" are varied, but all share the core concept of making the player feel impotent (or unimportant, in the case of the "patronize/humiliate the player" error) in his play through of a game - the loss of agency.
Since little is offered in terms of corrective advice, it's hard to analyze that particular section, but what does pop up in the few times advice is offered shares a theme of maintaining positivity and offering the player choice, which should seem a natural means of increasing the feeling of agency. What is immediately apparent, though, is that most or all of these errors should be able to be spotted with just a tiny bit of naive, black-box testing.
The prevalence (at least to the degree that most of those familiar with video games will also feel familiar with these errors) of these mistakes in tutorials speaks to an issue - where's the testing? In many cases, it seems like development teams may simply undervalue the input of the true naive observer.
It was with anticipation, then, that I looked at Final Fantasy XIII - I knew that the series would remain enjoyable, because I know that it is in myself to enjoy the kind of "interactive storybook" these games are dually admired and admonished for being. That game lived up to its promise, for me. Others found it lacking, and it's not incredibly difficult to see why, no matter what my personal assessment of the game. The chief complaint was the feeling of participating in an over-long "tutorial" sequence wherein the player is gradually introduced to game concepts over the first several hours of the game.
This is perhaps an exaggeration of the actual in-game experience, but the core issue is one of the feeling of loss of player agency, which is a topic addressed well in Ernest Adams's "The Designer's Notebook: Eight Ways To Make a Bad Tutorial" at Gamasutra.
The gist of the article is made clear in its title - it's a list of common mistakes in implementing tutorial sections in games. The article is not necessarily corrective or constructive (and the author acknowledges that), but what it does do well is presenting a list of errors that will be familiar to anyone who feels he's sat through a poor tutorial segment. The "eight ways" are varied, but all share the core concept of making the player feel impotent (or unimportant, in the case of the "patronize/humiliate the player" error) in his play through of a game - the loss of agency.
Since little is offered in terms of corrective advice, it's hard to analyze that particular section, but what does pop up in the few times advice is offered shares a theme of maintaining positivity and offering the player choice, which should seem a natural means of increasing the feeling of agency. What is immediately apparent, though, is that most or all of these errors should be able to be spotted with just a tiny bit of naive, black-box testing.
The prevalence (at least to the degree that most of those familiar with video games will also feel familiar with these errors) of these mistakes in tutorials speaks to an issue - where's the testing? In many cases, it seems like development teams may simply undervalue the input of the true naive observer.
Week 1011 (because "Week 11" would just be confusing if you thought in binary)
The eleventh week of my internship has been a lot like the mythological "March" - in like a lion and out like a lamb. Because we had a prototype build due early in the week, the first couple days of the week were relatively busy, even when put up against weeks where I had full capacity. The great part about that relative business was, of course, that the build got in. We had a couple hurdles to overcome in terms of making the mission compatible with all the means the users would use to run the mission, but we sorted them out fairly quickly, giving us enough time to add a tiny bit of polish to an otherwise-scratchwork (as is to be expected for a deliverable of this nature) prototype.
Beyond that, the week was fairly sedate. I had a lot of class this week, which tended to get in the way of putting a lot of time into the lab, and so it was a good thing I front-loaded my lab work, as the last few days of the week had me offering a minimal amount of my time for our projects. But, projects. I don't get a chance to work on it often, but since we entered a short trough following our submission of the NFA build, I got the chance to work on part of a project for Torque. I've done a tiny bit of work for it before, and it was nice to revisit some of that work if for no other reason than to keep my horizons broad.
I also took a look at a new tool we've brought in for building our missions. It expands on the sparse level of tool support the base engine offers and to a degree simplifies the process of scripting out the missions. It's not all-inclusive, and it does seem like there may be some compatibility hurdles to overcome, but I think it will be a relief for our developers to at least be able to toss some kind of GUI over what was previously just a set of .xml files.
Moving in to the next couple of weeks, we'll be taking a look at how the actual missions for the NFA scenario are to play out. Hopefully this will involve some creative brainstorming sessions and some great ideas on maximizing the engine we have. We will see, I suppose.
Beyond that, the week was fairly sedate. I had a lot of class this week, which tended to get in the way of putting a lot of time into the lab, and so it was a good thing I front-loaded my lab work, as the last few days of the week had me offering a minimal amount of my time for our projects. But, projects. I don't get a chance to work on it often, but since we entered a short trough following our submission of the NFA build, I got the chance to work on part of a project for Torque. I've done a tiny bit of work for it before, and it was nice to revisit some of that work if for no other reason than to keep my horizons broad.
I also took a look at a new tool we've brought in for building our missions. It expands on the sparse level of tool support the base engine offers and to a degree simplifies the process of scripting out the missions. It's not all-inclusive, and it does seem like there may be some compatibility hurdles to overcome, but I think it will be a relief for our developers to at least be able to toss some kind of GUI over what was previously just a set of .xml files.
Moving in to the next couple of weeks, we'll be taking a look at how the actual missions for the NFA scenario are to play out. Hopefully this will involve some creative brainstorming sessions and some great ideas on maximizing the engine we have. We will see, I suppose.
Monday, June 13, 2011
A little bit for column "A," a little bit for column "B"
Game balance is a fun issue, and because I often take the lead for these blog articles from featured articles at Gamasutra, this article on "Understanding Balance in Video Games" was a fun and easy target for further breakdown.
I should explain why balance is a fun issue for me to tackle. I am, by all accounts, a neophyte in the world of game development. I have training in production, but my background is in psychology (which is as clearly related to game development as farming ability is to political aptitude). What this means is that often I can be the child peering over the balcony to see the masters in the orchestra play whenever topics of game design come up.
However, I do have some informal training in game design, and a large portion of that comes in past production of mods for arcade shooters, which is one of those genres affected so heavily by the concept of "balance." As such, I've spent a lot of man-hours working, in my own sophomoric way, at working out issues of balance. It's nice, then, to read a conversation about something in which I would feel a tiny bit more comfortable offering my voice.
Now, the article at hand is really more of a broad overview of the concept and prevalence of issues of balance, but there is an interesting point there at the end - addressing the issue of balance by looking not at the advantages of certain classes or pieces of the game, but rather by looking at their weaknesses. I think that it's certainly a useful way of introducing game balance - by using specific weaknesses the same way one would tack on special (positive) abilities to a class.
There's a larger issue of game balance, though, that I feel the article does not address. There's almost a degree of serendipity involved when a game ends up being balanced, simply because of this: the issue of duplication of testing effort. It's an often-cited figure that the entire testing effort of a game production is duplicated shortly after launch, and this presents a huge problem for balance, because for a large part, character "tiers" (or whatever title you want to tack on to it) are generated post-release from the unpredictable interactions of players with your system. Balance is a bit of a crapshoot, then, and it's with that thought that I'm almost willing to say - maybe we shouldn't worry quite as much about balance. An enjoyable game may be able to be made more by providing equal opportunity than by equal ability.
I should explain why balance is a fun issue for me to tackle. I am, by all accounts, a neophyte in the world of game development. I have training in production, but my background is in psychology (which is as clearly related to game development as farming ability is to political aptitude). What this means is that often I can be the child peering over the balcony to see the masters in the orchestra play whenever topics of game design come up.
However, I do have some informal training in game design, and a large portion of that comes in past production of mods for arcade shooters, which is one of those genres affected so heavily by the concept of "balance." As such, I've spent a lot of man-hours working, in my own sophomoric way, at working out issues of balance. It's nice, then, to read a conversation about something in which I would feel a tiny bit more comfortable offering my voice.
Now, the article at hand is really more of a broad overview of the concept and prevalence of issues of balance, but there is an interesting point there at the end - addressing the issue of balance by looking not at the advantages of certain classes or pieces of the game, but rather by looking at their weaknesses. I think that it's certainly a useful way of introducing game balance - by using specific weaknesses the same way one would tack on special (positive) abilities to a class.
There's a larger issue of game balance, though, that I feel the article does not address. There's almost a degree of serendipity involved when a game ends up being balanced, simply because of this: the issue of duplication of testing effort. It's an often-cited figure that the entire testing effort of a game production is duplicated shortly after launch, and this presents a huge problem for balance, because for a large part, character "tiers" (or whatever title you want to tack on to it) are generated post-release from the unpredictable interactions of players with your system. Balance is a bit of a crapshoot, then, and it's with that thought that I'm almost willing to say - maybe we shouldn't worry quite as much about balance. An enjoyable game may be able to be made more by providing equal opportunity than by equal ability.
Deci-Week
The tenth week of my internship is an auspicious one, if for no other reason than that it marks the half-way point of my internship. As mentioned last week, this week was a reduction in capacity; however, I still managed to find my way into the lab to work on a couple things.
The big subject this week was that we were running smack into a build deadline. This wasn't a hugely stress-inducing deadline, since we were running pretty well on schedule, but the inevitability of any deadline is a little bit of rush. I did need to stay around a little longer than normal on a couple of days, but it was relatively stress-free and rewarding to get done.
One thing that was folded into the development of our first prototype build was a large section of scratch audio for voiceovers. Since we're working with a proof-of-concept build, one of the other interns and I sat down for about an hour or so and recorded the dialogue ourselves, which is always a little bit of fun. The dialogue is slightly ridiculous, but when the real goal is just to have some sound in there, there's no problem with having a bit of fun with it.
This upcoming week promises to be similar in nature to this past week. We still have to take care of some deliverable polishing in the front half of the week, and I'm still on a pretty reduced capacity thanks to my class. I'm looking forward to pushing through this week, though, because not only will it be a good test of my flexibility, but it represents the last week I really have to focus on multiple fronts (class and internship) for the duration of my time here.
The big subject this week was that we were running smack into a build deadline. This wasn't a hugely stress-inducing deadline, since we were running pretty well on schedule, but the inevitability of any deadline is a little bit of rush. I did need to stay around a little longer than normal on a couple of days, but it was relatively stress-free and rewarding to get done.
One thing that was folded into the development of our first prototype build was a large section of scratch audio for voiceovers. Since we're working with a proof-of-concept build, one of the other interns and I sat down for about an hour or so and recorded the dialogue ourselves, which is always a little bit of fun. The dialogue is slightly ridiculous, but when the real goal is just to have some sound in there, there's no problem with having a bit of fun with it.
This upcoming week promises to be similar in nature to this past week. We still have to take care of some deliverable polishing in the front half of the week, and I'm still on a pretty reduced capacity thanks to my class. I'm looking forward to pushing through this week, though, because not only will it be a good test of my flexibility, but it represents the last week I really have to focus on multiple fronts (class and internship) for the duration of my time here.
Friday, June 3, 2011
...And on that farm he had a cow, E-L-I-T-E
This post is going to reference the incoming subscription-based service "Call of Duty: Elit3," by Activision, and to get this out of the way - despite the title, this is not simply reactionary. There are any number of complaints to make, and while I did go for the cheap and easy "milking a franchise" joke in the title, there's more to look at here.
Basically, "Elite" (for the time being, I'll eschew the leet-speak spelling) is a multiplayer management service (similar to Blizzard's Battle.net), except that it offers "premium" content for a paid subscription. Depending on your point of view - glass-half-full or glass-half-empty - this is either a way to charge for things that may have already been available free or it's a way to offer more content consistently.
There are a number of concerns that could be raised here. First of all, the obligatory "you can play free too" line is there, which has often signaled the tacit "...but you won't ever be able to play on the same level." The possibility of charging more for less is another potential concern - with the paradigm already existing that map packs for these games come out, they could still come out this way and this could just be a charge on top of a charge.
However, I think that - with the goal of being optimistic - there is a great opportunity here from a production standpoint. If the paradigm changes to one where all the new content is folded into this monthly "premium" charge (the same way MMO content is often added), it could provide for a state where it is more justifiable to keep a team working on addon content, since there would be a steady revenue stream.
Ultimately, this could be better for the end user (provided, of course, they opt-in to paying), but it is obviously an experiment. I can think of few better platforms (that is, the Call of Duty series and its massive user-base) to effectively pilot this test, though.
Basically, "Elite" (for the time being, I'll eschew the leet-speak spelling) is a multiplayer management service (similar to Blizzard's Battle.net), except that it offers "premium" content for a paid subscription. Depending on your point of view - glass-half-full or glass-half-empty - this is either a way to charge for things that may have already been available free or it's a way to offer more content consistently.
There are a number of concerns that could be raised here. First of all, the obligatory "you can play free too" line is there, which has often signaled the tacit "...but you won't ever be able to play on the same level." The possibility of charging more for less is another potential concern - with the paradigm already existing that map packs for these games come out, they could still come out this way and this could just be a charge on top of a charge.
However, I think that - with the goal of being optimistic - there is a great opportunity here from a production standpoint. If the paradigm changes to one where all the new content is folded into this monthly "premium" charge (the same way MMO content is often added), it could provide for a state where it is more justifiable to keep a team working on addon content, since there would be a steady revenue stream.
Ultimately, this could be better for the end user (provided, of course, they opt-in to paying), but it is obviously an experiment. I can think of few better platforms (that is, the Call of Duty series and its massive user-base) to effectively pilot this test, though.
Week the Ninth
This ninth week, and the beginning of my third month, has been a short one. Reduced in capacity by both the holiday at the beginning of the week and class starting this week, we had significantly less time to work.
The time that I have had the opportunity to invest has largely been used in testing components of our first deliverable and early builds of the mission for that deliverable. Some of these items were highly interesting - we spent a remarkable hour or two determining the feasibility and constraints of trying to land on a flying aircraft carrier. Suffice it to say, it's not as easy as S.H.I.E.L.D. makes it look.
We also had a couple builds of the mission that were less on the "interesting" end of the scale and more on the "oh come on now" end of the scale. We're looking at some of the inevitabilities of taking the fledgling steps in producing a piece of content - that is to say, "tricky" builds - and I certainly don't begrudge them. That being said, it is still an exercise in coordinating a large number of not-pinned-down components. Once we start to refine our testing paradigm, I'm sure it will become all the easier for it.
This month as a whole should see a sharp reduction in capacity from the past month, which is okay, but one notable challenge will be making sure that I am still able to add value to the project and benefit my team as some of the class hours get a little more daunting. It is a challenge I am looking forward to putting behind me.
The time that I have had the opportunity to invest has largely been used in testing components of our first deliverable and early builds of the mission for that deliverable. Some of these items were highly interesting - we spent a remarkable hour or two determining the feasibility and constraints of trying to land on a flying aircraft carrier. Suffice it to say, it's not as easy as S.H.I.E.L.D. makes it look.
We also had a couple builds of the mission that were less on the "interesting" end of the scale and more on the "oh come on now" end of the scale. We're looking at some of the inevitabilities of taking the fledgling steps in producing a piece of content - that is to say, "tricky" builds - and I certainly don't begrudge them. That being said, it is still an exercise in coordinating a large number of not-pinned-down components. Once we start to refine our testing paradigm, I'm sure it will become all the easier for it.
This month as a whole should see a sharp reduction in capacity from the past month, which is okay, but one notable challenge will be making sure that I am still able to add value to the project and benefit my team as some of the class hours get a little more daunting. It is a challenge I am looking forward to putting behind me.
Monday, May 30, 2011
A journey of one thousand XP begins with a single achievement
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.
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.
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."
Monday, April 25, 2011
It slips away - and all your money won't another minute buy
So the Playstation Network is down. What does this mean? Well, for most, this simply means that their online features of their console are unavailable. That's a bummer, and a major part of many games' functionality is cut out - but there are still other options, right? Grab a nice singleplayer game, like Uncharted, or Heavy Rain, or Mass Effect (2) - they're all fun with just you, the couch, and a controller. Right?
Maybe you want to sit down with something a little less ponderous. Oh! Try one of the nifty games available through the PSN store. No, of course we can't buy them now, but we bought some before. How about a nice, quick playthrough of Bionic Commando Rearmed. That's a fun game, right? It did okay, yeah?
What? You tried it and couldn't? Isn't it a single-player game? Hmm... this seems problematic.
Now, there's a lot that could be spun off of this. I won't dive into the whole piracy/DRM talk - which is a good way to approach this, but it's a horse beaten to death by those more educated and more knowledgeable than I (not to speak of the further floggings of it by the gaming public as a whole).
I think a more interesting way of looking at this is seeing why it is what it is. Frankly, it's a real bummer to need to validate a game online before starting to play it - Ubisoft tried something similar (if not more invasive) with Assassin's Creed 2, and was met with a resounding "no thank you" from its public (it later killed that particular feature on a later iteration of its Assassin's Creed series).
That said, it's actually a pretty smart way to enforce what it has in its EULA - that is, that the game is a license, and not a sale.
This is of course a tricky issue with consumers, since they are trained to believe that, for the most part, when they pop down money for something that they are then able to use on their own schedule, that they own that thing. This comes up of course when we look at things like the right of first sale and all its repercussions, but what customers really want is to believe that they have the ability to use their thing at their own leisure. And what publishers really want is to believe that they are leasing copies of their work for use, but maintaining some form of control over it anyway.
Neither one is expressly legally right, of course - as these disagreements often do, this falls into a bit of a legal gray area.
But guess what? I don't want to address that either. (I did want an excuse to throw in a reference to first sale doctrine, though, because I think it's an interesting topic on its own in relation to video games). I do wonder, though, what this sets up, as far as a future video game landscape goes.
Do video games get produced like those mentioned above were (Bionic Commando Rearmed, et al.), and when their online infrastructures disappear, so too do the games? That's a little alarmist, I know, but I think it's a valid question, even if it happens to only a small handful of games. One of the best things I think that the video game industry can do, as a fledgling art medium and/or method of expression, is to make sure that its history is preserved. In the past, the presence of a physical medium would ensure that at the least a work wasn't dependent on anything but itself to survive the test of time. In the current age, the digital realm provides its own sort of immortality, since there's nothing physical to preserve and no effective limit on copying or backing up.
Things that rely on a separate service to exist or work, though? That's a little bit of a different picture. Services can and do shut down all the time. Are we in danger of damaging a historical record in service of ensuring EULA validation? Maybe. Maybe it's worth it. Maybe not. Time will, as it always does, tell.
Maybe you want to sit down with something a little less ponderous. Oh! Try one of the nifty games available through the PSN store. No, of course we can't buy them now, but we bought some before. How about a nice, quick playthrough of Bionic Commando Rearmed. That's a fun game, right? It did okay, yeah?
What? You tried it and couldn't? Isn't it a single-player game? Hmm... this seems problematic.
Now, there's a lot that could be spun off of this. I won't dive into the whole piracy/DRM talk - which is a good way to approach this, but it's a horse beaten to death by those more educated and more knowledgeable than I (not to speak of the further floggings of it by the gaming public as a whole).
I think a more interesting way of looking at this is seeing why it is what it is. Frankly, it's a real bummer to need to validate a game online before starting to play it - Ubisoft tried something similar (if not more invasive) with Assassin's Creed 2, and was met with a resounding "no thank you" from its public (it later killed that particular feature on a later iteration of its Assassin's Creed series).
That said, it's actually a pretty smart way to enforce what it has in its EULA - that is, that the game is a license, and not a sale.
This is of course a tricky issue with consumers, since they are trained to believe that, for the most part, when they pop down money for something that they are then able to use on their own schedule, that they own that thing. This comes up of course when we look at things like the right of first sale and all its repercussions, but what customers really want is to believe that they have the ability to use their thing at their own leisure. And what publishers really want is to believe that they are leasing copies of their work for use, but maintaining some form of control over it anyway.
Neither one is expressly legally right, of course - as these disagreements often do, this falls into a bit of a legal gray area.
But guess what? I don't want to address that either. (I did want an excuse to throw in a reference to first sale doctrine, though, because I think it's an interesting topic on its own in relation to video games). I do wonder, though, what this sets up, as far as a future video game landscape goes.
Do video games get produced like those mentioned above were (Bionic Commando Rearmed, et al.), and when their online infrastructures disappear, so too do the games? That's a little alarmist, I know, but I think it's a valid question, even if it happens to only a small handful of games. One of the best things I think that the video game industry can do, as a fledgling art medium and/or method of expression, is to make sure that its history is preserved. In the past, the presence of a physical medium would ensure that at the least a work wasn't dependent on anything but itself to survive the test of time. In the current age, the digital realm provides its own sort of immortality, since there's nothing physical to preserve and no effective limit on copying or backing up.
Things that rely on a separate service to exist or work, though? That's a little bit of a different picture. Services can and do shut down all the time. Are we in danger of damaging a historical record in service of ensuring EULA validation? Maybe. Maybe it's worth it. Maybe not. Time will, as it always does, tell.
Week IV
For the most part, the general flow of this internship is pretty similar week to week. I'd love to be able to be a little more profound, but one of the necessities of a scheduled blog is that it must (perhaps often?) delve into the mundane.
One of the more interesting aspects of this week has been the move into a more "knowledge solicitation" role. I enjoy production (and design) as a general act, but the nature of the NFA project is one that piques my interest particularly. Having grown up in a military family, there's something exciting about the heavily organized nature of military procedure, especially when it involves such cool machines. In that vein, I got to spend a lot of time this week talking about the performance of these machines in a context that was relevant to what they need to do for the NFA and what they would actually have to do in their respective fields of operation. I've been advised that learning how to solicit knowledge well is a good skill to nurture, and it's one I'll be more than happy to pursue, especially when it's as fun as it is for this project.
This next week is actually our week-long Spring Break, and so I'll be working on the project minimally, if at all. I'd like to be able to nail down some design specifics if I get the chance, because I know that even if I'm not working full-time, there are still a handful of our dev team that is. I'd like to be able to support them as best as I can. I got a real break in moving forward in the design this weekend, though, and I hope that will propel me to get in some of these basics I want to do.
One of the more interesting aspects of this week has been the move into a more "knowledge solicitation" role. I enjoy production (and design) as a general act, but the nature of the NFA project is one that piques my interest particularly. Having grown up in a military family, there's something exciting about the heavily organized nature of military procedure, especially when it involves such cool machines. In that vein, I got to spend a lot of time this week talking about the performance of these machines in a context that was relevant to what they need to do for the NFA and what they would actually have to do in their respective fields of operation. I've been advised that learning how to solicit knowledge well is a good skill to nurture, and it's one I'll be more than happy to pursue, especially when it's as fun as it is for this project.
This next week is actually our week-long Spring Break, and so I'll be working on the project minimally, if at all. I'd like to be able to nail down some design specifics if I get the chance, because I know that even if I'm not working full-time, there are still a handful of our dev team that is. I'd like to be able to support them as best as I can. I got a real break in moving forward in the design this weekend, though, and I hope that will propel me to get in some of these basics I want to do.
Friday, April 15, 2011
Protracted Console Lifecycles: Sony and Microsoft do what Nintendon't
If you've been keeping your ear to the ground over the past week or so, one thing you may have picked up on are some rumblings from Nintendo. It would seem that the rumblings - which have included a drop-off in the amount of upcoming games as well as a potential price drop - have indicated a potential reveal of a new console in a short amount of time.
Now, there's a lot that could be done to hem and haw through the potential features, games, marketing strategies, and any number of other aspects of a new console announcement, but I'm more interested in how this may affect the planned life cycles of its two chief competitors' consoles.
Microsoft and Sony have both indicated that they want their consoles to live in the market for about a decade, a decade at which we are almost the half-way point. Nintendo announcing a console now, even if it were to release late next year, would still put it solidly in the "middle" of the other two consoles' lifecycle.
What does this mean for them? Previous console generations have all been fairly simultaneous (within a couple years) in terms of their change-over of hardware. This could probably go one of two ways - one, Nintendo reaps the benefits of having an uncrowded "new console market" and establishes themselves firmly in this (half?)-generation. Two, there is a protracted "Dreamcast effect," where they see a lack of adopters based on people looking to wait for the newest and best.
They may dodge the second one simply because of their stable of first-party games that always seem to act as an effective draw to their systems, but there's no guarantee. There's also the distinct possibility that this simply forces one of the other company's hand, and we see a very strange drawn-out generational turnover.
This is all to say that I think there is one thing more interesting than any hardware features or potential software applications that a new system may offer - seeing how a market reacts in a genuinely new situation.
Now, there's a lot that could be done to hem and haw through the potential features, games, marketing strategies, and any number of other aspects of a new console announcement, but I'm more interested in how this may affect the planned life cycles of its two chief competitors' consoles.
Microsoft and Sony have both indicated that they want their consoles to live in the market for about a decade, a decade at which we are almost the half-way point. Nintendo announcing a console now, even if it were to release late next year, would still put it solidly in the "middle" of the other two consoles' lifecycle.
What does this mean for them? Previous console generations have all been fairly simultaneous (within a couple years) in terms of their change-over of hardware. This could probably go one of two ways - one, Nintendo reaps the benefits of having an uncrowded "new console market" and establishes themselves firmly in this (half?)-generation. Two, there is a protracted "Dreamcast effect," where they see a lack of adopters based on people looking to wait for the newest and best.
They may dodge the second one simply because of their stable of first-party games that always seem to act as an effective draw to their systems, but there's no guarantee. There's also the distinct possibility that this simply forces one of the other company's hand, and we see a very strange drawn-out generational turnover.
This is all to say that I think there is one thing more interesting than any hardware features or potential software applications that a new system may offer - seeing how a market reacts in a genuinely new situation.
Week v.3
Week three has seen a little more of the refining of focus I know that I was hoping for in previous weeks.
This week has seen further refinement to the story design portion of the NFA project. It's been fun to get the chance to be a little bit creative, and it's been neat to see how our team's individual strengths are combining, Captain-Planet-style, to contribute to the overall story picture. You see, last week we were working on creating, individually, one-third of the six potential plot lines for the missions experience. As mentioned last week, we each (the three interns working on this specific task) created our portions in a manner that highlighted our respective backgrounds. What this led to this week was a tasking to add to each of each others' stories in the manner that we created our own: One of us is working on fleshing out character backgrounds, while another is working on character dialogue, while another is working on overall plotting. It will be neat to see how our stories are transformed by collective input.
We've also finally got some additions to the NFA team - additions that will be eventually responsible for actual content creation, instead of the overall design and documentation roles we are filling as producers. This has given us a chance to create some usable documentation with a direct design purpose, rather than more structural or conceptual documentation. Lots of this documentation will be used to determine exactly what needs to be created to prove some of the core concepts for the missions of the project, and we'll spend a lot more time refining exact details of the first mission, which is being used as a testbed for this.
As we move into next week, my hope is that we'll finally be able to nail down some of the exact specifications of this first mission - we have a limited timeframe to complete this, and I think it's possible, but we're still looking for some answers. Here's to finding them!
This week has seen further refinement to the story design portion of the NFA project. It's been fun to get the chance to be a little bit creative, and it's been neat to see how our team's individual strengths are combining, Captain-Planet-style, to contribute to the overall story picture. You see, last week we were working on creating, individually, one-third of the six potential plot lines for the missions experience. As mentioned last week, we each (the three interns working on this specific task) created our portions in a manner that highlighted our respective backgrounds. What this led to this week was a tasking to add to each of each others' stories in the manner that we created our own: One of us is working on fleshing out character backgrounds, while another is working on character dialogue, while another is working on overall plotting. It will be neat to see how our stories are transformed by collective input.
We've also finally got some additions to the NFA team - additions that will be eventually responsible for actual content creation, instead of the overall design and documentation roles we are filling as producers. This has given us a chance to create some usable documentation with a direct design purpose, rather than more structural or conceptual documentation. Lots of this documentation will be used to determine exactly what needs to be created to prove some of the core concepts for the missions of the project, and we'll spend a lot more time refining exact details of the first mission, which is being used as a testbed for this.
As we move into next week, my hope is that we'll finally be able to nail down some of the exact specifications of this first mission - we have a limited timeframe to complete this, and I think it's possible, but we're still looking for some answers. Here's to finding them!
Friday, April 8, 2011
Elevens: Or, Finally We'll All Be Able to Play Minecraft?
Minecraft, a game which should need no - or at least very little - introduction, finally has a release date. For the casual observer of video-games-goings-on, this may come as a surprise, and not because of the date itself. Rather, the surprise is due the fact that a "release" seems counter-intuitive: the game's already out, right?
Well, no, and the more familiar observer will say, "Of course not! You knew it was in alpha/beta all this time!" That is true, of course - if you've seen a single Minecraft video or screenshot, you probably noticed the Minecraft Alpha v.xxx or Minecraft Beta v.xxx up in the corner of the screen. I would say that this distinction is largely academic - yes, technically the game may fit under either of these headers (and of course there is flexibility to define things like the type of beta - open or closed - etc.), but given the developer's own approach towards updating the game:
- It's hard to really say that there's ever going to be some traditional end to the alpha/beta stages with all their hallmarks (code freeze, final RC, etc.). That is all to say that the game could probably be viewed as simply released when it became open to public use - after all, shortly afterwards, users were able to pay to play it (in alpha, no less). The concept of continual support after release - or at least bugfixes - also falls squarely into the model of game release used by many (if not all) major publishers as well.
So why is there a release date at all? I think it's a pretty savvy move to use these traditional appellations (alpha, beta, RC) in the realm of a game that clearly falls outside their conventions. Like many single-user-developed (or small-team-developed) hobby/indie games, what we really see here is an author who's invested a lot into a product and wants to keep developing it, even after he's done. Is that sustainable? Smart? I don't know - Minecraft's dev(s) seem to be doing at least all right for themselves. However, I'd bet that there's a reason why many large companies have one release date - one big "holiday" for themselves - instead of the protracted release cycle used here.
And that's why I think it's a smart move to use things like this - this otherwise-meaningless release date. It's an easy way to drive attention to your game - and it's clear that is the goal (using a memorable number (11-11-11), tying it in with other big releases (Skyrim)) - and perpetual attention can really only be a good thing for a game's sales. I think if Notch (Minecraft developer Markus Persson) is smart, he'll keep using this strategy. Instead of making updates simply patches with numbers attached, he'll release them in the style of titled, downloadable content, even if they're no different than patches - because at the end of the day, the attention is what matters.
(Minecraft "release" announcement: http://notch.tumblr.com/post/4423138657/11-11-11)
Well, no, and the more familiar observer will say, "Of course not! You knew it was in alpha/beta all this time!" That is true, of course - if you've seen a single Minecraft video or screenshot, you probably noticed the Minecraft Alpha v.xxx or Minecraft Beta v.xxx up in the corner of the screen. I would say that this distinction is largely academic - yes, technically the game may fit under either of these headers (and of course there is flexibility to define things like the type of beta - open or closed - etc.), but given the developer's own approach towards updating the game:
"It’s a bit tricky to really do a release for Minecraft as we keep updating it all the time. For one, the version we deem as the “full version” won’t be very different at all from what the game was like a week ago, and we’ll keep adding features after the release as well..."
- It's hard to really say that there's ever going to be some traditional end to the alpha/beta stages with all their hallmarks (code freeze, final RC, etc.). That is all to say that the game could probably be viewed as simply released when it became open to public use - after all, shortly afterwards, users were able to pay to play it (in alpha, no less). The concept of continual support after release - or at least bugfixes - also falls squarely into the model of game release used by many (if not all) major publishers as well.
So why is there a release date at all? I think it's a pretty savvy move to use these traditional appellations (alpha, beta, RC) in the realm of a game that clearly falls outside their conventions. Like many single-user-developed (or small-team-developed) hobby/indie games, what we really see here is an author who's invested a lot into a product and wants to keep developing it, even after he's done. Is that sustainable? Smart? I don't know - Minecraft's dev(s) seem to be doing at least all right for themselves. However, I'd bet that there's a reason why many large companies have one release date - one big "holiday" for themselves - instead of the protracted release cycle used here.
And that's why I think it's a smart move to use things like this - this otherwise-meaningless release date. It's an easy way to drive attention to your game - and it's clear that is the goal (using a memorable number (11-11-11), tying it in with other big releases (Skyrim)) - and perpetual attention can really only be a good thing for a game's sales. I think if Notch (Minecraft developer Markus Persson) is smart, he'll keep using this strategy. Instead of making updates simply patches with numbers attached, he'll release them in the style of titled, downloadable content, even if they're no different than patches - because at the end of the day, the attention is what matters.
(Minecraft "release" announcement: http://notch.tumblr.com/post/4423138657/11-11-11)
Week No. 2
The second week of my internship here started off as many "seconds" are wont to do - with less fanfare and a little more focus. Since we were still operating under the paradigm of "planning for a project that has yet to officially start," much of our day-to-day is still tied to conceptual work.
This is, all in all, not a bad thing. We've gotten to play around in the "design" sandbox, which is an arena which might otherwise go ignored in the role of "training to be an effective producer." I enjoy design; design is what got me interested in production in the first place, and it will always hold its own appeal to me.
With that in mind, it is slightly disconcerting to work on so many different pieces of the design puzzle, given the current nature of the project as more "big-picture" than "small-picture." Here are a couple of the disparate design pieces worked on:
As mentioned in the last entry, we spent some time this week working on story segments for the mission "campaign" that is at the center of the NFA experience. Knowing that, in general, all of us working on the story segment are at least somewhat creative, it was interesting to see how each of our respective educational backgrounds influenced our delivery of the story. Since we were all working on top-down slices of the story, rather than just segments, I think that we were really able to provide some useful comparative takes on scripting this thing out.
I also spent a lot of time trying to work through putting together a prototype of the first mission. It's always tough getting over the hump of learning a new set of tools, and in this case - working with the flight-simulator engine we're using - the process felt particularly arcane. Somewhere down the line, I know we're looking at some third-party tools to help craft these missions, and I only hope that I can generate something worthwhile - something edifying and useful - with the prototype I'm working on with the out-of-the-box tools before we (as production interns) move into the more organizational aspects of the project.
Here's to hoping that next week, we get to move into the "official" opening of the project, and we can focus in and create some specific goals and deliverables. I suppose we'll see!
This is, all in all, not a bad thing. We've gotten to play around in the "design" sandbox, which is an arena which might otherwise go ignored in the role of "training to be an effective producer." I enjoy design; design is what got me interested in production in the first place, and it will always hold its own appeal to me.
With that in mind, it is slightly disconcerting to work on so many different pieces of the design puzzle, given the current nature of the project as more "big-picture" than "small-picture." Here are a couple of the disparate design pieces worked on:
As mentioned in the last entry, we spent some time this week working on story segments for the mission "campaign" that is at the center of the NFA experience. Knowing that, in general, all of us working on the story segment are at least somewhat creative, it was interesting to see how each of our respective educational backgrounds influenced our delivery of the story. Since we were all working on top-down slices of the story, rather than just segments, I think that we were really able to provide some useful comparative takes on scripting this thing out.
I also spent a lot of time trying to work through putting together a prototype of the first mission. It's always tough getting over the hump of learning a new set of tools, and in this case - working with the flight-simulator engine we're using - the process felt particularly arcane. Somewhere down the line, I know we're looking at some third-party tools to help craft these missions, and I only hope that I can generate something worthwhile - something edifying and useful - with the prototype I'm working on with the out-of-the-box tools before we (as production interns) move into the more organizational aspects of the project.
Here's to hoping that next week, we get to move into the "official" opening of the project, and we can focus in and create some specific goals and deliverables. I suppose we'll see!
Thursday, March 31, 2011
What's in a Game? Would a Roselia by any other IP smell as sweet?
How much does a popular IP contribute to a game?
This past week, I was trolling through the Android Market, as I occasionally do, and I noticed an interesting looking game. "Pokemon Tower Defense" was the name of the game, and given that I enjoy several of the conceits of the Pokemon series of games - I've enjoyed several of the Game Boy games branded with that name, no matter their distance from the original series - I figured it'd be worth a try.
It was. The game concept is written in its title - it's a tower defense game with Pokemon mechanics and art grafted on. It was only an early build of the game (the author listed it as an alpha version), but it showed a lot of promise. What intrigued me the most was how well the RPG mechanics melded with the tower defense mechanics. While there are tower defense games that use leveling mechanics, there are specific attributes of the Pokemon RPGs that enhance this particular game: large number of Pokemon (units), selectable modes of attack (movelists, which upgrade with leveling), capture of enemy units (Poke balls).
I think that this is a truly marketable game concept, but the obvious problem is the use of the preexisting IP. And, as expected, the game was pulled from the Android Marketplace just a day or so ago. The author has thankfully kept updating and has hosted the game at Newgrounds, but the bottom line is that he's not ever going to be able to sell it or make any kind of money off of it.
So all this is to bring me to my above-posted question. How much does the IP being used really contribute to the appeal of the game? Research done by Samuel McClure et al. addresses this idea of brand identity being important by looking at Coke vs. Pepsi, or as it is better known, "The Pepsi Challenge." This is a blind taste-test that pits the two sodas against each other to determine which is more preferred.
Here's a short abstract of the paper (from this link):
This past week, I was trolling through the Android Market, as I occasionally do, and I noticed an interesting looking game. "Pokemon Tower Defense" was the name of the game, and given that I enjoy several of the conceits of the Pokemon series of games - I've enjoyed several of the Game Boy games branded with that name, no matter their distance from the original series - I figured it'd be worth a try.
It was. The game concept is written in its title - it's a tower defense game with Pokemon mechanics and art grafted on. It was only an early build of the game (the author listed it as an alpha version), but it showed a lot of promise. What intrigued me the most was how well the RPG mechanics melded with the tower defense mechanics. While there are tower defense games that use leveling mechanics, there are specific attributes of the Pokemon RPGs that enhance this particular game: large number of Pokemon (units), selectable modes of attack (movelists, which upgrade with leveling), capture of enemy units (Poke balls).
I think that this is a truly marketable game concept, but the obvious problem is the use of the preexisting IP. And, as expected, the game was pulled from the Android Marketplace just a day or so ago. The author has thankfully kept updating and has hosted the game at Newgrounds, but the bottom line is that he's not ever going to be able to sell it or make any kind of money off of it.
So all this is to bring me to my above-posted question. How much does the IP being used really contribute to the appeal of the game? Research done by Samuel McClure et al. addresses this idea of brand identity being important by looking at Coke vs. Pepsi, or as it is better known, "The Pepsi Challenge." This is a blind taste-test that pits the two sodas against each other to determine which is more preferred.
Here's a short abstract of the paper (from this link):
The preference for Coke versus Pepsi is not only a matter for the tongue to decide, Samuel McClure and his colleagues have found. Brain scans of people tasting the soft drinks reveal that knowing which drink they're tasting affects their preference and activates memory-related brain regions that recall cultural influences. Thus, say the researchers, they have shown neurologically how a culturally based brand image influences a behavioral choice.These choices are affected by perception, wrote the researchers, because "there are visual images and marketing messages that have insinuated themselves into the nervous systems of humans that consume the drinks."
Even though scientists have long believed that such cultural messages affect taste perception, there had been no direct neural probes to test the effect, wrote the researchers. Findings about the effects of such cultural information on the brain have important medical implications, they wrote.
"There is literally a growing crisis in obesity, type II diabetes, and all their sequelae that result directly from or are exacerbated by overconsumption of calories. It is now strongly suspected that one major culprit is sugared colas," they wrote.
Besides the health implications of studying soft drink preference, the researchers decided to use Coke and Pepsi because-- even though the two drinks are nearly identical chemically and physically--people routinely strongly favor one over the other. Thus, the two soft drinks made excellent subjects for rigorous experimental studies.
In their study, the researchers first determined the Coke versus Pepsi preference of 67 volunteer subjects, both by asking them and by subjecting them to blind taste tests. They then gave the subjects sips of one drink or the other as they scanned the subjects' brains using functional magnetic resonance imaging (fMRI). In this widely used imaging technique, harmless magnetic fields and radio signals are used to measure blood flow in regions of the brain, with such flow indicating brain activity levels. In the experiments, the sips were preceded by either "anonymous" cues of flashes of light or pictures of a Coke or Pepsi can.
The experimental design enabled the researchers to discover the specific brain regions activated when the subjects used only taste information versus when they also had brand identification. While the researchers found no influence of brand knowledge for Pepsi, they found a dramatic effect of the Coke label on behavioral preference. The brand knowledge of Coke both influenced their preference and activated brain areas including the "dorsolateral prefrontal cortex" and the hippocampus. Both of these areas are implicated in modifying behavior based on emotion and affect. In particular, wrote the researchers, their findings suggest "that the hippocampus may participate in recalling cultural information that biases preference judgments."
The researchers concluded that their findings indicate that two separate brain systems--one involving taste and one recalling cultural influence--in the prefrontal cortex interact to determine preferences.
The gist of it is that knowing what you're drinking - or playing, as the case may be - affects your perception of it. Even though I'd like to consider myself at least a little more adept at parsing out the true qualities of a game than the average gamer, it's still difficult to know how much this affects perception of the quality of a game idea like this one.
It would be interesting to see these mechanics with a different skin. Right now, I'll be content to enjoy the game as it is (and I do), but this is definitely something to shelf for a future look.
For your viewing pleasure, here's a chance to take your own look at "Pokemon Tower Defense:"
Subscribe to:
Posts (Atom)