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.
Monday, July 25, 2011
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.
Subscribe to:
Posts (Atom)