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.

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.

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.

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.

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.


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.

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, 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.