Some years ago I interviewed for a job as an artificial intelligence programmer working on the latest title in a well-known RPG franchise. During my tour of the studio, the producer showed me the latest build of the game. The engine was fairly far along and there was at least some content - a world with buildings, liberally populated with character models. But lacking any AI, the characters simply stood around, unanimated, like so many statues. It would have been my job to add the AI to drive animations on the models, and then game systems governing their interactions with the players. In the end, I chose to go with a different company, mainly for real-life practical reasons. But the image of those static characters, and the opportunity to breathe life into that frozen tableau, was very tempting. It was difficult to turn down that job! (They also had crab cakes in the cafeteria at lunch… very difficult to turn down that job.)
That particular road-not-taken was an example of what I’ll call “gameplay integration”. Gameplay integration involves taking different pieces contributed from different areas of the team - art, design, and perhaps other engineers - and putting them together to create gameplay. These programming tasks typically include a generous dose of artifical intelligence work, plus input processing/player control and often some user interface work. It’s essentially where the end result, the player experience, is born. For me, it is one of the most enjoyable aspects of game programming. Our Thinglefin project has ample opportunity for this kind of work, and a recent task made me recognize two distinct pleasures that it can bring.
The task: implement a behavior where a creature chases after a toy. I wasn’t given very much direction beyond “let’s have the creature chase a toy”. But no problem, that just gave me a chance to do a little “on the spot” design - the first pleasure of gameplay integration.
Here’s a little programmer secret: though there may be someone on the team with the title “designer” who writes design documents and so forth, the programmer is really the ultimate designer. No matter what it says in the design document, it’s the implementation that drives actual player experience. Of course, completely ignoring the designer’s input is not a great idea, but no design specification can be complete in every detail. Inevitably, the programmer will make some decisions about how to do things, if perhaps only at a very fine-grained level.
But given our small team, the roles are a bit more blurry, and in this case, I ended up doing most of the feature design. First I had to decide how to start the behavior. I thought it would be cool to have the creature’s attention attracted when the player shakes the toy with the mouse. After a wee bit of research into gesture recognition, I had that done.
Next, artificial intelligence: making the creature chase after the toy. This was more than an exercise in constructing an efficient pathfinding algorithm; to make it fun and interesting, the creature’s behavior had to convey excitement and playfulness. So, I looked through our animations and thought about ways to put them together in meaningful sequences. This is the kind of process that distinguishes “on the spot design” from more traditional, um, ”designer design”: instead of coming up with a list of animations up front and putting them on an artist’s list, I had to take what was already there and figure out how they could be used creatively.
Inspiration can be found by repurposing what is already there, too. An animation called “fidget1″ had the creature twisting its head to the side. That looked to me like the creature might be looking for something, so I decided to add an interaction where the player can hide the toy behind the creature’s back. The creature responds by entering a search mode that is kicked off by that “fidget1″ animation.
Between this spot design work, experimentation, and building up some artifical intelligence infrastructure, this took me a few days to complete. Shortly after I put the final result up on our internal test page, I experienced the second pleasure of gameplay integration: the team reaction. Documentary evidence from our chat logs:
[15:00] rejemy: Oh my god that is so awesome
[15:00] rejemy: Wooo!
[15:00] rejemy: ![]()
[15:00] thingleryan: what, the chasing?
[15:00] rejemy: Yes!
[15:01] rejemy: All the animations working in tandem at last to create a character
[15:01] rejemy: It's awesome
[15:01] rejemy: It's ALIVE
A little while later, a friend of mine who has a young child told me something that reminded me of this experience. He had been away for just a week or so but was marvelling at how different his child seemed when he got back - bigger vocabulary, longer sentences, falling less while walking. When he remarked on this to his wife, she said it just seemed like another ordinary week to her - being with the kid all the time, she took much less notice of her progress.
Working on the chase behavior was a bit like that for me. For a few days I had my head down working on it, seeing incremental progress, throwing out things that didn’t work quite right, tweaking distance and time parameters. It was easy to lose track of exactly how far it had come. For Jeremy seeing it all at once, the impact was more dramatic, and seeing it from his point of view helped me to appreciate anew just how far the “child” had come. A nice feeling.


Congratulations, Ryan! It sounds as if it’s all working smoothly. I know the feeling of incremental progress that you are describing. One gets absorbed in the work and forgets how far the project has come in just a few days. Keep it up!
Great story! I’ve had exactly that experience a few times in my career…
But I think the most rewarding is when things are not incremental, but just click into place (e.g. once you’ve fixed the last bug, or put in an important rule for the behavior to emerge). Then it’s you that does the running around and shouting like a child
alexjc
[…] Two Pleasures of Gameplay Integration, thinglefin.com […]