Literacy, Game Development & Documentation

Ombwah's picture

I like to start my blogs off with a loud statement, here's today's:

People that do not read the text in video games, as a practice, ought to be barred from games development.

A doozy that one? I think not, and here's why.

1. A person, any person, that is intellectually capable of reading (i.e. isn't victim to some degenerative brain malady or crippling learning disability), and yet stridently brays "I don't like to read." should be disdained out of hand; This statement implies some difficulty in parsing the language, and if they are American, it's likely the only language they know. A person with such a tentative mastery of their given, single, language is not professional material in my opinion, and shouldn't be rewarded with a game development position of a sort that requires writing or reading text. This aside, let's move on to how this pertains to my title.

2. Watching a movie with the sound off does not convey the whole of the movie, likewise paging through even a childrens' picture book by Dr. Seuss without reading the text will give you an incomplete understanding of the tale. I have an example handy. Just a day or so ago, my middle daughter (she's 7) wanted to watch a sub-titled recording of Hiyao Miyazaki's Nausicaa. She reads well, but the subs flit by a little faster on average than she was able to parse. She was confused and some of her comments let a little glimmer of what I'm saying here shine through. In this example, a small glider flies out of the sun to destroy a group of immense flying gun-ships, but just the visuals alone were not enough to convey the tableau. I contend that they never, ever, are. Do you think that would have been different for her had she pressed the firing stud on the little glider's guns herself? I don't, I think it would still be lost on her why they were firing at all, or who the target's were or even that they were war-machines. The fighting capabilities of these dreadnoughts are not explored on the screen, only referenced in the dialogue, the text. The movie itself begins with a synopsis of recent history, much like the Star Wars movies, that spells out how the story takes place on our Earth, long after this age. This also, is covered here in text and taken as granted afterward, If you watch the film without that knowledge, without reading that intro panel, you lose that knowledge and with it, at least half of the significance of the film's message. How does that affect the impact of the story? The impact of the experience as a whole? This applies to video games as well, not reading the text on screen is deliberately blindfolding ones self. It is ignoring a necessary element of the experience. Could you work a crossword without the clues, would you bother to try? Do you navigate the highways without parsing the signage, do you think it wise to?

How about assembling a model without the instruction sheet? Does that sound like wise practice? The same principles, I think, apply to this concept, and this is the root of my doozy statement in bold at the head of this entry. Consider.

We accept that people don't read the text in their chosen avenue of entertainment because they find it troublesome, cumbersome, or awkward. We must then also assume that they find parsing their language the same set of adjectives, else why would the first be true? Accepting this, we look to a standard practice in the games industry (and, verily in many industries) the writing and keeping of documents.

Because many games are 'made of whole cloth' i.e. don't exist in any form before their inception, it is common that there be written a series of documents, or one large document, that outline the vision and implementation of the game as it grows. This document or library serves to keep the vision coherent and, most importantly, provide a store of all known hard data about the project so that anyone ignorant can reference the document (or library) for a store of knowledge relevant to their question(s) and hopefully come to a conclusion that falls in line with the intent of the project. As a high-level interpretation, that is all that the docs are for, though we in development know that the veracity and usefulness of the docs is almost always a contentious question. In the past few years, and over many projects, I have seen and heard statements regarding game design documentation like "I don't have time to keep up the docs..."; "they aren't ever accurate, so we have never read them" and "the six month old version of that document that I have says..."; These are the most common of many.

If a given individual is averse to parsing their language (as discussed above) what implication does that have for a situation where the only unity of vision for their work available comes of regular and focused reading?

Documents, the very roadmap by which all should be navigating, are apparently held in such disdain by a particular cross-section of devlopment that often they become a sort of 'soft reference' not referenced by any department before a 'fix' or patch is made. This leads to engineering making changes at the eleventh hour that absolutely break the intent of the functionality being 'fixed', or art assets that in no way represent the item needed. Often then there is then a row about how group A or department C failed the other on a given project when all departments would have some concordance had they given their roadmap a little more credence. I have watched artists create assets not knowing whether the object was a friend or enemy to the player, or how it would behave when placed in engine, or with which tools it would be placed. This information was, in all of these cases, available, but the extra effort of reading the documentation, or going back to read the pertinent section of documentation was considered too much to ask. Further, no effort is ever made to interpret the wealth of data included in these documents to make the correct decision from a professional knowledge rather than from specific direction, in almost all cases the conclusion that could have been reached by a little professional knowledge and a little time in referencing the document is postponed until someone can say definitively. And that affects your project in undeniably adverse fashion.

Artists should be familiar with not only the potential visual mileu in which their assets will be placed, but also with some idea of how the asset will be used, and what effect is intended. Likewise Engineers should be familiar with what the systems they are honing affect in the engine at run-time, how these settings will change game-play, and whether that is in line with the intents of the design.

Last, documents are not concrete and steel, they are the fluid record of a dynamic project. You can't have skimmed them the day of hire and think that you are done with them. As has been pointed out in other blogs, the rules of game development change in situ, and with them the documents. It should be the developers individual onus whether Artist, Engineer or Designer to check the revision logs and make sure they are still in step with the current vision of the project-as-whole, and this takes reading. How can this be expected from someone that publicly and regularly states aloud that they choose not to read the text portion of their favorite challenges, that states that they like to play story games and ignore the bulk of the story? I find this confusing.

Many games require no text, Tetris, Qix, non-objective puzzler or action games that require no context for the activity presented do not need any words to set-up the tableau or indicate the next task necessary. Though the more complex these challenges become the sooner you need some simple and universal mode by which to imply the next rule or step. Often, because of the known disdain for text messages, these simpler games use small images and icons to convey the intent to those that won't read.

In our business, the challenge is to collaboratively create a great experience in a limited time-frame, with limited resources; I haven't yet met the UI designer that can come up with an icon for that, have you?

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Snipehunter's picture

I blame art!

I have a million examples of exactly the scenarios you're discussing. I won't go into them, but they almost always end with the non-reader saying, "I Blame [some department that I am not a part of]" Engineers blame designers (and make fun of artists), artists blame engineers (and designers), designers blame artists (and engineers) and the producer/project manager blames the leads for not providing enough direction. Of the group, the project manager tends to be the only one who is "right" -- but even that could be colored by the fact that your producer or project manager doesn't read, either.

It's an interesting topic for me, because project management is a big part of what I do. Even if the recalcitrant developer doesn't read the docs, I am still responsible for ensuring that the design vision in maintained. Depending on the scope of the project, this can be next to impossible if all parties are not familiar with the current documentation. So then, I often ask myself, "Is this my fault?" On the one hand I have to say, "yes." -- As designers our job is to conceive of and convey the game's design vision. However, our toolset is words and imagery (the documentation)... So on the other hand, I feel like developers aren't giving me the required effort if they don't stay up to date on those documents.

For the record, I agree with you. I think that if you don't or won't read the documentation, you shouldn't be developing games. At the same time I think that, as a designer, if you're relying solely on the documentation to convey your vision, you're part of that same problem. (the other side of the coin, as it were)

So how do you fix the problem? How do you get people to read the docs, instead of relying solely on you personally, without sacrificing your responsibility to maintain and ensure the game's design vision? I don't think the industry as a whole has an answer, yet.

For me, and I'm a little loathe to admit it, the solution is that I make you feel bad. I'll tell you to your face that not reading the docs means you're not doing your job. When you ask a question that has been answered in the documentation, I'll still give you the answer, but I'll also give you the docs with notes about how they've been available this whole time. It sounds horrible, but I'm not at all mean about it, so it's not nearly as bad as it might sound. It's constructive, in fact -- in that it creates a larger atmosphere of personal responsibility. You can't hide behind, "Well I didn't read that in the docs" on a project I manage, which means you have to take the responsibility for the delay to production in asking for something you already had, if nothing else.

Of course, I also work as hard as I can to encourage the developers I manage to understand the vision of the game intrinsically so that they can solve their own problems (with or without the documentation). I do this by explaining every line of reasoning behind every request or task I set forth for someone and by discussing the "feel" and the "existential intent" of the game, level, or asset with the people involved. For some developers, it empowers them and you see work at a level of quality you couldn't get otherwise, but for others is scares them - and they require greater direction than before because they second guess their every action.

Interestingly enough, I find the line between this approach empowering or scaring developers parallels the line between designers that flaunt game rules as needed to attain a certain "feel" and designers who adhere to templates and rules nearly religiously.

Maybe that's because you can't effectively go "off-rule" without having the intrinsic understanding of the game's intent you can only get from reading the docs and comprehending the game at the top-level. Or, maybe it's simply that going "off-rule" is a wholly creative act that requires a higher degree of understanding of the language to accomplish -- an understanding you can't get if you refuse to read.

- Snipehunter

Curious on thoughts about..

reading the docs only when needed to. Example, starting up some where you read to start getting aquainted, and you can only take so much after a while. Then you slack off from the reading until you need to read up on something that pertains to what your actually doing or need to achieve.

Lets also not mix up reading with the writing. Some one can be just as creative making up new crap with out having to read. If your working with an established IP, its probably way more important to read up, especially when "needed".

Personal opinion is that which I do and asked about up here. Im working with an established IP, read up when I started on main stuff got aquainted, then slowed it down, and only read when needed. Ive been promoted, and praised for my "design" work thus far. So how can we justify it as a requirement of anyone who is to be a developer? I think its more then likely in reality a case by case thing.

Snipehunter's picture

Right - I think we're on the same page

To me, that's an example of staying on top of the documentation. Once you've read them all, you only need to read what has changed, right? I think the thought that everyone would re-read every single document regularly - while a good idea - is unrealistic. That doesn't preclude people from keeping up to date with the documentation, however. A developer should be referred to the portions of the documentation that are relevant when she starts a related task, which seemed to be exactly what you were suggesting.

As for not needing to read to create, Wolfen? I think we'll have to agree to disagree on that one. Let me take one jab for humor's sake and point to the difference between the renaissance and the dark ages and the corresponding literacy rates in both periods. Sticking out tongue People who can and do read make more complex creations than people who don't, or won't. Though you can easily take it too far, complex creations are more interesting than simple ones, as a general rule.

- Snipehunter

Teehee- I like these blogs.

Valid point on the needing to read to create. But you cant discount that people are just naturaly creative (yes, you had to read at some point to be able to learn about certain things and starting putting those things into other things). But an interesting point an archeoligist made about humans, one of the fine, and wonderful things that makes us us. Our brain, is an infinite toolkit. With out reading alone, we still "created" many things. Eye-wink

I think what really should be considered is something more broad. "Observation". Observe, and learn. I guess in all reality, its just the idea of knowledge is power. Reading just happens to be in this day and age, the best form to gain most knowledge. Have I dug to deep? =D

Ombwah's picture

Observation is close to target...

I make the extreme statement at the intro to make people react and read the long-assed diatribe I wrote.

Really though, the core of what I was saying is this:
A developer with a complete understanding of the goals of their project is 100% more likely to be able to do their job well. If that takes one complete run-through of the documentation, then follow-ups to keep up, then that's what it takes for that individual. If you need more refresher than that, than it should be expected of you to fulfill that. I suppose you can choose to not read them and glean all of your knowledge from your fellows, and that would be acceptable to me, but it doesn't seem to work in practice too well.

The goal for me with that concept, is that with the precious edification that I hope to provide them, no one would waste a week asking the designers for specific details pertaining to the creation of a common world object whose perameters are defined by it's intended use. The very use would indicate all necessary conditions for the creation of the object, which would be set in the documents. Further, the director and leads within the art department would be familiar with the intended function and could field questions from their team without forwarding them to Design.

Likewise, changes to systems by engineering, 'minor art tweaks' and the like, polish tasks undertaken by these departments when Design is working forward or fixing bugs, could be completed or at least well started without as much potential for mishap, and without a constant oversight or prodding from another department. A complete understanding of 'your part' of the job would be useful, and if everyone were familiar with the intent and goals of the project (as they could become, having read an entire Design and Plan at least once) they could more effectively fulfill the intent of their position rather than the strict function of their position. This would cut on production time, cost and stress.

I digress a little here, but I think that each discipline should understand what the goals of the team are, and should work toward the team goal rather than a personalized schedule that gets their part done. It is my contention that, in many ways, getting your part done requires that there be no more work done on that asset or function before I can implement it over in design.

To come full circle, a developer that doesn't like to read will always feel bad about or frustrated by reading the documentation, and reading and maintaining the documents is paramount in video game development. Why then, is it such a common and accepted phrase in our professional culture to say "I don't read the text in games."

How is that different from a Hollywood studio hiring the director that regularly states in professional company that they only watch films with the audio off?

Can we say Subtitles?

LOL J/K.

True true. I think what Im getting at is many people attain information in different ways. At ND, im not sure what happened with me. For some reason most all information I read up on vanished out of my head. I think the editor was totally whacked out and was more of a programmers editor then a developers.

I dont read text in games a lot of the time when im just "playing". I will easily admit, when testing your own game... this is a bad bad thing. But when it comes to just general play, I dont think it applies. I think you should just be straight up saying, developers read your damn docs that every one has made. =\

This is a good topic though. =D