The Animal Farm

October 23rd, 2010

My Love-Hate Relationship with Scripting Languages

Back when I was in college, I thought scripting languages solved all my game development problems. I could write some scripts to do everything I needed and keep my code clean. I got rapid iteration and my code was in a form other people can muck with. How awesome is that?

Of course, the situation isn’t nearly so neat and tidy. Scripts themselves are code, and keeping those clean is work unto itself. Getting proper rapid iteration working requires a fair bit of work. And letting people edit scripts who don’t have a programming background can very often explode in your face.

But that’s not where my biggest problem resides. No, my biggest problem is that most scripting systems lack sufficient debugging capabilities.

(Side note: When I talk about debugging throughout this post, I’m specifically talking about the context of using a scripting language within the larger framework of a game. The situation changes when using a scripting language as the primary development medium).

Visual Studio has made some amazing strides in the realm of debugging such that virtually every other tool - Eclipse and XCode included - is living in the stone age. Developing code is much more pleasant when I don’t have to litter code with print statements and call out to a command-line debugger. I can jump around the call stack, set break points and watch variables, setup watches for when memory changes, and easily step through the code line-by-line.

Unfortunately, when we use scripting languages in our games, we’re generally giving all that up. When something breaks down, about all we can do is get a call stack and (if you’re lucky) inspect some variables. We can’t even trace through the code to identify when things break down.

In essence, we’re taking the single greatest boon modern development environments provide (or try to provide but fail miserably in the case of XCode) and you’re throwing it out the window. We are forced to go back to caveman debugging - placing print statements all over the code to try and spot when things break. How is that a good idea?

Emergent realized this. A significant chunk of one of my co-worker’s time while I was there was spent developing an integrated Lua debugger that mimicked Visual Studio as best it could. I used it a few times, and it was refreshing to gain the advantages of scripting while avoiding the biggest pitfall.

Unfortunately, this isn’t always the case, especially with indies who don’t have the time to develop a fully featured script debugger. Integrating a full scripting solution then becomes work that generates more work for not so much gain. That’s… not good.

Scripting still has appropriate domains in the indie space. For small chunks of functionality that are modular and easy to write and require fast iteration - for instance, the spell effects in an RPG or weapon behavior for a shooter, or transitions for a UI - scripting is still invaluable. But I definitely don’t think script code should drive the bulk of a game.

This line has no context. It is not tied to the above post in any way.

October 23rd, 2010

Game Polish & Data-Driven UI

Polish is about transformation. Fades and slides and scales and subtle little motions that nobody appreciates, but everything feels off when they’re not there. If we look closely at a hobby project, a solid indie title, and a AAA professional game, we can quickly see (if we’re looking for it) just how much deviation there is in the overall aesthetic created by transformations alone.

Of course, this stuff can be a pain to develop. Anecdote: Fully 60%-65% of the code for See the Light & Word Duelist is UI code. I spent a great deal of time manipulating “widgets.” Mistakes were made. This article is mostly about the mistakes.

Don’t Just Use Linear Interpolation
From an aesthetic standpoint, linear interpolation is limiting, but it’s all a lot of programmers know. Good UIs will at minimum support easing.

What is easing? It provides a sense of ‘acceleration.’ An animation which eases in will start out slow and build up speed quickly. Conversely, an animation which eases out will start out at normal speed and then slow down before reaching its destination. These can be visualized by considering how a car moves - it gradually speeds up before reaching its target speed and gradually slows down before stopping.

You can go crazy with the ways speed changes over the course of an animation - for instance, starting out at normal speed, then speed up in the middle, then returning to normal speed before stopping. For this you may want to look into curve fitting algorithms (bezier, hermite). Multimedia artists have a better understanding of when to use these techniques, but I’m afraid I’m not much help there.

If You’re Creating Your UI in Code, You’re Doing it Wrong.
Do not be fooled by the amount of work a good UI requires even for a small game. It can easily consume you. Just laying out the screen can require an enormous amount of code, and it quickly becomes a cluttered mess. I thought See the Light - a single screen puzzle game - would not require much in the way of UI, and each time I port the game I cringe at just how wrong I was.

Just don’t do it. It’s much better to be able to lay out and specify your UI in a file. This gets rid of a lot of clutter, increases your turn-around time for small changes, and in general requires less work in the long-run. This also paves the way for potentially creating a UI layout tool (or using an already existing one) in the future if you ever want to go down that road.

Consider Specifying Transformations with Data
The current UI system I’m working on allows me to completely define animations via external data. I have a section in my UI file that looks like the following:

Animation anim_name
Slide Widget=button1 StartPos=0,0 EndPos=100,100 Time=1000
Slide Widget=button2 StartPos=100,100 EndPos=0,0 Time=1000

At any point in my code, I can trigger the animation and receive a notification when it finishes. I have some general code that is able to interpret various animations and play them back. I also have a system that allows me to chain together animations one after the other for more complicated effects.

This does wonders for my code. I can play effects without worrying about the details of the effect, and I can quickly tweak animations. Further, if ever I have an artist working with me, they can modify this file themselves instead of relying on me to make code changes for certain effects.

Good Transformations are Hard
There are a lot of moving parts involved in getting a transition to look good. A button might fly in, ease out at the end, shake a little, then snap back into its “real” target position. When it hits its final position, it could shine a little. While this is happening, other buttons might be doing their own things.

There’s a balancing act involved in getting the right amount of detail in an animation; you want things to be visually interesting without being so busy that the player can’t focus.

And I can’t help a whole lot here. Artists are much better at this kind of stuff than I am. Of course, artists have tools like Flash and After Effects which are designed specifically to facilitate rapidly creating animations. If you’re able to use those, that’s awesome (and it’s why Scaleform does so well these days).

Conclusions
I spend an awful lot of my time thinking about how to streamline game development, and solid UI development tactics account for a lot of that time. Every time I start a new project, I realize that the UI is going to be more work than I anticipated originally. It’s a tough game to play, but it can go a long, long way to making the user experience more pleasant.

When doves cry.

|