Screenshake - A Short Essay on Polish

<= Back

Out of all the topics under the umbrella of game development I had ever heard about when I first started dabbling around in this stuff, the idea of "polishing" a game always left me the most confused. I used to publish demos of my games on forums when I was in my pre-teen years, and I would always get lots of feedback advising me to polish my game. What does that mean? I'll try to answer that question in this article.

Polish is difficult to define. It will mean something different for every game. However, I like to think of it as that magical stuff that turns a good game into a great one. It is that stuff that prevents players from being forcibly ejected from the experience the game is meant to deliver. It can also mean different things for the various components of your game. To a programmer, polish might mean an improvement in the performance of the game's code, or maybe the removal of bugs that don't break the game, but still might remove players from the experience. To an artist, polish might mean adding more details to the environment, improving lighting, or bumping things up to a higher resolution. To an audio engineer, polish might mean making things are nicely in-balance, so that no sound is too quiet or loud enough to blow out your speakers.

For my current project (which is still unnamed thus far), polish means improving the overall impact of your actions in the game. This month's game is a turn-based RPG. Most of the actual gameplay consists of reading text and making decisions by selecting items from a menu. Polish, for this project, is the sort of thing that will make all that reading and menu-jockeying fun. I spent a lot of time this week focusing on how to make the impact of an enemy's attack really make the player feel like they were taking damage. Here's what it used to look like when the player took damage from an enemy attack:

It works. It shows you the information you need to know. It indicates which enemy is attacking you, tells you how much damage was dealt, and updates the UI in the upper-left to reflect the change in game state. However, it's not terribly fun to look at. Here's how this same scenario looks after I've polished it up a bit:

The screen flashes red, indicating that the player is somehow in danger. The screen also shakes, drawing more attention to the severity of the event. Finally, some red text floats down from the UI in the upper left, making the change of game state even more apparent and easily accesible. Now, all of a sudden, it's fun to get hit by an enemy in battle. It's not just a change in numbers. You can almost feel the impact of the hit. That's what polish is all about to me: just making the experience more believable, more impactful, and more fun.

When Should I Start Polishing?

Another question I've always struggled with is when the appropriate time to start polishing your game is. My answer at my current level of experience: do it as late as you possibly can, but as soon as you need to. I know that's sort of a non-answer, so allow me to flesh it out a little. First of all, I should mention that the answer has to be a little general and vague, because every project is different. I believe the answer depends on what you're really trying to do with your game.

You can definitely start to polish a game too early. I think that if your game isn't functional and fun to play even when all of the graphics are nothing but lines and dots, then you need to resolve that problem before you start polishing the game. You can also start to polish too late, when your game is just about scheduled for release and there are still placeholder assets and bugs that break the immersion into the experience.

I decided to start polishing this game about a week ago simply because of what it is: a game demo. It's a demo for the battle system of a game I want to potentially continue working on in the future. I want the demo to really sell the battle system as a fun experience. If you read my article from last week, you'll know that I finished the battle system. It functions as it should, and it's pretty engaging when you're up against a tough enemy. That's all I really want the demo to do, so I realized it was time to start polishing the experience: adding some more believability, adding better graphics (yes, those question marks will be gone by next week's article), and adding some crunchy sound effects and music.

If I had started polishing this game before the battle system was working properly, I might have had a broken down mess of an experience that looked pretty, which is worthless. However, if I hadn't started polishing when I did, I might have reached the end of the month (and the release of the demo) with a game that still uses question marks instead of cool-looking enemy battle portraits.

Conclusion

Ultimately, polish is mysterious. It's something that means something vastly different for each game, but it's also essential. If that teaches me anything, it teaches me that the only way I'll master the art of polish is by making lots of games and gaining lots of experience. Thankfully, I seem to be on the right track with all of that. Thanks for taking the time to read this article. I'll be back next week with a demo of this month's game, and you'll finally get to see that creepy artwork I've been going on about...

...

I promise it'll be there!

<= Back