Archive for September, 2008

Doin’ It and Doin’ It and Do It Again

Friday, September 26th, 2008

Back in 6th grade, I had a tae-kwon-do teacher who was from somewhere in far east Europe (I don’t remember which because 1) I didn’t ask him, and 2) I was 12, cut me some slack). His location of birth is relevant because it gave him a cool accent, which unfortunately was turned into a droning whine while I was doing training exercises. There is only so many times you can do back kicks (which I hated then and still do today because I am seriously not convinced they could every do anything more than awkwardly foot-paw someone’s thighs and not actually hurt them), especially when you are 12, shorter than everybody, and don’t relish the idea of being really tired when they put you in padding way too big for you and make you “spar” with someone, which you know is upcoming after this eternally-long exercise.
Ahem. Anyhow.
Instead of saying how many of whatever kick we’d be doing, the master would bark out “ONE MORE TIME!” in his unique accent, and my level of preadolescent irritation would rise precipitously. I wondered more than once why he couldn’t just count like the other masters, and also, why that phrase got under my skin so much more than the plain fact of having to do X number of kicks. He wasn’t any harsher than any other masters, that I can recall - just yelled “ONE MORE TIME!” instead of normal counting.
Why do I remember that as being so obnoxious? It’s not just his accent - that just made it etch into my mind more easily. It’s the plain fact of being told to do the repetition. So here’s my question - to myself, and to everyone -

When does something go from being fun to being repetitive?

A lot of criticism I hear about this or that game is that it’s “too repetitive” - which makes me wonder what the boundaries are. Certainly a game needs to have some repetition - core gameplay - or it’s a damn mess. But at what point do you expand, at what point do you constrain yourself? Certain games work okay with a single - or set - of systems, which can indeed be repetitive. Diablo II jumps to mind, but hell - what about Pac Man? World of Warcraft? What is Halo but shooting guys, and then shooting other guys? With this blurry definition… where do we draw the line?
Sure, we can say stuff crosses over when it stops being fun. But I don’t trust any eye-ball impression when someone looks at a game and says “looks repetitive.” I think you’d be bored watching me kill stuff in Diablo II, but hell, I’m having a good time. And even with open-world games like Saint’s Row, yeah you’re doing a million different things, but it’s more about the experience of being involved in it… I sometimes actually find those harder to get invested in as a viewer, because I can’t grab a narrative thread or sense of linearity… unless the player states a clear objective, I don’t know where they plan on taking things. Which is fine, but in terms of - as I said - simply eyeballing something for a sense of “that looks repetitive” (and by extension, boring) - leads me to distrust the sentiment.
Sure, I’ve played repetitive games and disliked them greatly. Halo bored me.  Breath of Fire V: Dragon Quarter was a colossal disappointment. And even my much-loved Civilization 2 becomes a bit of a shore near the more technological ages (but then I just start over again). But where’s the distinction? Is there a definition - a line in the sand - that we can draw that separates good from bad as a rule, not just on a case-by-case basis?

I aim to give this more thought - but for now, I’m putting it out there. Whatchu think, world?

Quick, Write This Down!

Thursday, September 11th, 2008

I’ve been reading a lot of it lately, so documentation is on my mind.

I don’t think anyone would argue it’s worthless in a project, but it begs the question - as I’ve worked on projects that both hardly have any and others that are immersed in it - how MUCH documentation is appropriate?  How do we even determine this?

Of course, there’s the “no duh” things like scale and type of game. You nail down the obvious ones - Characters for an RPG, Weapons for an FPS, things like that.  But at what point do you cross the line from Too Little to Too Much, when even just maintaining the things becomes a chore?  In the beginning, they’re everyone’s friend - but near the end of the project, they seem to most often get discarded.  How do you most decide what you need, what works for updating it, WHO updates it, and how to keep the evolution of the doc up to date so it’s consistently helpful?

I know this is case-by-case to the point where some might even think the discussion of such is kind of moot - but things don’t seem to improve on a case-by-case unless at least SOME attempt is made to look at them in a larger scale (at least in my view).  So.

I’m going to make the key assumption here that there is an easily-accessible location for all the documentation that extends BEYOND a simple shared drive, or perhaps even a source-control solution like Perforce, AlienBrain, SourceSafe, etc.  I’ve had personal experience with SharePoint, and although it is not my favorite tool ever, I can understand its utility, and have to admit it’s helpful to see it marked when a new document has been added, and when an existing one has been changed (and by whom).  I believe SharePoint even allows you to tag certain documents to have an email auto-sent to you when they’ve been updated, which is helpful (in certain situations - I’d say when it’s an important doc that either everyone has access to but only a few can edit, or something only a few people can access and their changes are super-important).  Obviously if a team is not communicating in person, there’s not all that much documenation can do.

So - what CAN it do, beyond a preproduction standpoint?  Obviously it can help newcomers to the team get oriented and management see where things are going, but I’d argue as well that documentation - stuff outside the specifics of department, “translated” for everyone to read - is beneficial.  I can’t understand the specifics of programmerspeak (although I should always strive to try), but having documentation that combines intent with a projected direction is valuable, and should always be valuable.

That said, as much as I like to document things “just in case,” I’ve also run into situations where files can pile up into a mess.  I’ve been in attempts to collate disparate docs into a single file (which has led to its own share of complications, I tell you what)… and though I suppose perhaps doing something like collecting major elements together into a Master “Story Doc” (for example) might not be a bad idea, it also comes with its share of issues.  If you’re on a Source Control System (and YOU SHOULD BE) only one person can tackle changes at a time - and if it includes a lot of systems that are still in flux, that could be problematic.  Second, there’s the basic fact of human nature that most of us don’t like reading long documents.  If I just want a basic character overview (that’s say, 5 pages), but it’s in a 40+ page Story doc, I might balk at such.  Clear formatting and Ctrl-Click to Follow options in a Table of Contents should be involved, but those seem more like a stopgap and should be secondary to collating things at an appropriate time.

[Crap.  I think my brain ran out of juice.  Going to get some more caffiene, pick up rant again later. In the meantime, you gab about what docs you feel are the most important for different genres, what you’d imagine should stand alone always vs. get folded together, when and why.  Probably only interesting to me, but what the hell :)]