Elements of Design: Technology

The last few times I've sat down to work on the game, I've been wrangling the same problem. I set my protagonists next to one another . . .

It was very gracious of them to pose for this shot.

 . . . push a couple buttons . . .

up up down down left right left right b a start

 . . . and watch as the girl drifts off the top of the level, never to be seen again.

The sense of abandonment is sobering but not exactly what was intended

Now, this is not ENTIRELY inconsistent with the behavior I'm going for, but it's still something of a problem.  If you are the sort of person who has messed with code in a game context or otherwise, you probably know about putting on your Code Gloves (like gardening gloves but smellier) and getting mussy up to your elbow in brackets and semicolons. It's fun and rewarding when you find an elegant solution to a problem, but as one concern starts to dominate your time you can begin to panic at the amount of resources you're pouring into solving a problem you never considered might exist.

One of the major differences between my esteemed co-developer and myself is that if I could magic the game and physics and behavior into existence with a nod of my head, without any of the mucking about in Javascript, I would do so. My partner wouldn't have it so; to him, the code itself is something beautiful and a lovely process, and on days when it's going right I can be impressed by our accomplishments too - but on other days, I wish I were making a board game. Whichever pole you gravitate towards - and if you're a dev, you probably bounce between them - your game is going to be supported by some kind of technology, so I want to examine some of the considerations of technology. Since I'm mainly interested in video games, I'll be talking mostly about code, but remember that your "technology" could just as easily be a board, or some cards, or a stack of books and some dice.

One of the things that's really cool about code is that it is one of the most tactile, controllable aspects of a game's design. In a medium that's really fuzzy and lacks a lot of precision or definition, this is an advantage we should cling to for dear life. Like the art, or the balance, or the story, code can be tweaked, code can bloat, code can be missing crucial elements or weighed down with unnecessary elements. The advantage is that code is more strict than the other parts of the game. If you're doing something critically wrong with your script, it won't compile, and you will know immediately; if you're doing something critically wrong with your art, it'll suck, and you probably won't know why or how to fix it for awhile. When you are rightfully kicking yourself in the head for the typo during the villain's grand speech just before the final confrontation, you will wish that the person typing your story up could be as strict as your compiler. Your code can still suffer from vagueness or lack of clarity, and can still have corner-cases you can't always see, but its representation is at least concrete and responsive.

Semicolons are the lucky ones. It's null pointers you must beware.

Technology, of course, offers a lot of limitations. You can't do better than the system you're working on or the tools you're using for implementation. For our own game, we're more limited right now by what we don't know how to do than what our computers or Unity can pull off, but think about the kinds of experiences that weren't possible until recently. Would Minecraft have been doable before it was possible to generate worlds of that magnitude? Could we have the experience of World of Warcraft before the infrastructure existed to support so many characters in the same world? Still, I'm going to assume the majority of my audience is limited not by the available technology, but by their ability to use it - in terms of time, resources, skill, etc. If I were a master of Unity and Illustrator and Blender my game would be a lot prettier, but since I'm not, we make do; maybe our game could be using more of the available technology, or using it more efficiently, but we have to work with the skills we have.

Sometimes, though, that isn't a bad thing. Part of what appealed to us about a shadow puppet-style game is that it was within our abilities. Our characters can look pretty static, and have simple animations, and still adhere to the aesthetic. It can even be charming. Similarly, though I'm certain there was no lack of skill that limited Mike Bithell to rectangular characters and platforms in Thomas Was Alone, the simplest uses of Unity suggest those kinds of shapes; starting with very basic uses of technology and using that as a stylistic theme helps direct the art of the game. Benjamin Rivers of Home imposed similar limitations on himself, to the betterment of the game. Pushing technology to its limits can produce something really wonderful if your vision is well-planned out, provided that vision isn't visibly handicapped by its execution. But when a game is visibly aware of its technology, and plays on the limitations of that technology in an elegant way, it can serve to unify the experience, as Thomas Was Alone demonstrated so successfully. If your technology doesn't get in your way, that's good; but careful understanding of it is what makes it not just an enabler of your game, but an active agent working towards whatever single purpose unites the disparate elements of your game.

Thinking about technology in this way gives us some interesting lenses for examining games. Is this game making full use of its technology? Is it handicapped by its technology? Is it playing off the strengths and limitations of that technology to achieve its purpose? Looking at technology is a way of examining our tools, and deciding whether those tools are sufficient for our vision, and whether we are using them in a way that makes our game as beautiful as it can be.