All the World’s a Stage

April 11th, 2011

In my last entry I discussed the trials and travails of designing Princess Porphyra, my main character. The next step in my game-building adventure was to create the game-world she would inhabit. This entry will discuss some of the design considerations I’ve struggled with in getting the project off the ground, attempt to rationalize the decisions I’ve made in the context of my development resources, and finish with an in-game example of my design parameters in action.

To start off, the “game world” for my purposes is a series of static background images with additional interactive drawings on top. These overlay images, called “objects” in AGS, are usually characters or items that can move or be altered in some way, although sometimes they can be merely landscape components in the foreground that add depth to the scene by allowing the player to walk around/behind them. I’ll talk more about the use of objects in a later entry: today I want to focus just on the static background images.

Having settled on a main character sprite, the backgrounds (and objects) must be scaled accordingly (i.e. the doorways must be big enough to let her pass through, tables must come to her waist, etc.) . In order to preserve the princess’s facial features her sprite size is 20-30% larger than what I have used in my previous hobby games, and this has resulted in no end of hassle as I struggle to cram in all the necessary scene elements at that scale. No doubt I’d be grumbling equally about the need to fill extra space or not being able to show adequate detail had I chosen a smaller scale, however. There will always be trade-offs when making a decision about scale and a good designer should be able to weigh the pros-and-cons and make the best decision. Whether or not I am this good designer remains to be proven, but any decision is better than no decision at all, in that it keeps this project moving!

Scaling determined, I needed to settle on an artistic style that was within my abilities (obviously), that was pleasing to the eye and suited my main character (naturally), and that was quick and easy to execute. This last requirement might seem counter intuitive to the artistic perfectionists out there, but as the sole work-horse behind this project it was imperative that the background art not be a massive time sink for me. There is literally no end to the amount of time an artist might potentially spend on a single background, perfecting it to the nth degree. To finish the game I knew I would have to consciously resist this impulse by setting strict time limits on background drawing time in order to keep the project moving. For me, finishing an enjoyable game is a higher priority than creating an artistic opus. My drawings are not programmer art in the sense that they are meant to be disposed of when the real art is finished; rather they are intended to be added to and augmented in a second pass (as necessary) when a rough copy of the game is complete. Also, the less time I invested in an individual background the less demoralizing a redraw would be should it become necessary (as it has been… on many occasions.).

The following in-game example should demonstrate these issues in action. It is the first background I drew, so it shows how I struggled with finding a style that I could build the rest of the game around:

The early draft of the background evolves into something simpler but better.

The first draft (above) of this castle room betrays the design principles I had set out beforehand. It took far too long to execute, to the extent that were I to continue doing all the backgrounds to that level of detail it would make the entire project infeasible. What is more, the level of background detail detracted from the main character by being too busy, and the colours were not terribly complementary. As an experiment in game style, it was to large extent a failure.

The revised draft (below) is cleaner and more flattering to my character.  Critically it was (and similar backgrounds could be) drawn in a much shorter period of time, vastly increasing my productivity and making finishing my game much more likely.  Blacking out the foreground was a successful experiment in my opinion: it still gives the impression of depth to the scene, cues the player to the fact that there is no exit off the bottom of the screen, and gives an opportunity to demonstrate the state of decay that the castle has fallen into while taking very little time to implement.  I am particularly happy with how the contrast it generates makes my characters and objects stand out.

To sum up the lessons I’ve learned here, if you are struggling with a design problem then there is usually a simpler and much more elegant solution that you are overlooking. Remember the realpolitik of game-design? The harder ideas become to execute, the more easily superfluous ideas are to identify and compromise away. Simple is not the same as unsophisticated, but rather the result of artistic clarity in the face of needlessly excessive work-loads. The results can not only be more efficient to produce, but also more elegant to behold.

Upon This Rock I Build My Game

April 1st, 2011

In my last log entry you read about how I had simplified the main character’s back-story to save all kinds of time and effort and (hopefully!) make the game a better experience for players. Today’s topic is going to be much more superficial: my struggle to design how my main character would look.

Just as a great number of readers unfortunately judge a book by its cover, so too do so many players judge a game by the character art. Gorgeous backgrounds can be attractive, but they change with the setting: the main character is right in front of the player for the whole game. Not only is a distinctive and appealing main character a huge visual draw, it also sets the scale and style for all the art assets in the game, from backgrounds to interactive objects to other characters: basically the whole shebang. Central to the rest of the art and critical to generating downloads, the main character’s design forms the foundation of a game’s success.

So what should my main character, the princess, look like? I started with her characteristics: young and thoughtful, once sad but now determined to make a difference. She must be clever (this is an adventure game), and compassionate. Visually I wanted to represent the sadness of her condition (raised without family and friends in a castle that is slowly falling apart), but at the same time she couldn’t look haggard or tattered. She had to stand out, which meant using colours that would not often be repeated in the game environment. Finally I reasoned that it could only add to her appeal if she was at least somewhat attractive.

Based on these musings I began sketching. This is not often a fruitful exercise for me as I’m not terribly gifted at drawing, but it is a quick way to try out different ideas without much effort. Through chance or determination a few bits and pieces start to come together: a cape here, some boots there, a scarf, some lips. Once I have enough of these components I scan in the various character drawings and start tracing the good parts, assembling them like Dr. Frankenstein into a composite creature. The hair was a particularly hard thing for me: a lot of trial and error followed.

The shape and colour of my main character’s hair was a particular agony.  I wanted something distinctive, yet not over the top; a little frazzled to represent her years of captivity, but still dignified to represent her royal station.  The colour was very important: it had to stand out from the background and other characters, but not be outrageously out of place.  The above are only the finalists after a considerable amount of experimentation.

After much agonizing, I finally alighted upon a combination of hair-styles that made the princess look just a little dishevelled, but still dignified. Around the same time I had seized upon purple as her colour of dress: not only was it the historic colour of royalty, but also it was unlikely that I would use it often elsewhere, making her stand-out. The clincher was that I learned that ancient Greek for purple was porphyr, which made for just a perfectly unique character name: Princess Porphyra!

By this point I was very satisfied with Princess Porphyra’s face and hair, but the body seemed a little awkward, and the colours a little tired.  While she had to be cartoony in style (my artistic limit) and in proportion (the head had to be out of proportion if her facial expression was to be readable in-game), I still felt that she could be improved.

But still I wasn’t satisfied: she didn’t instantly grab the eye. I decided to consult my good friends down at the AGS forums (the game-making society I am a member of), and they offered many helpful suggestions for improving her proportions and posture. More redraws and more colour experimentation followed, until finally -finally!- it all came together:

The final sprite.  She has become less girly and waifish, while certainly remaining feminine.  The colours work better together, lending her an air of dignity that my former attempts had lacked.

At long last I felt I had a solid foundation on which to build a game: an eye-catching and unique character who could carry the weight of an epic quest upon her sturdy shoulders. Psychologically this was a huge boost, since at last I had created something tangible. The game was no longer some vague idea, but a work in progress!

The Realpolitik of Game Design

March 30th, 2011

OK, so let’s get down to the nitty-gritty details of game design.  Today I’m going to discuss what I think of as the “Realpolitik” of game design.  Realpolitik is a political term that means making decisions based on practical expedients rather than on moral or idealogical grounds.  It’s all fine and well to dream of a perfect world (or in our case, a perfect game), but these aspirations inevitably get horribly mangled when they meet with a cold and unforgiving reality.  Von Moltke might not have been trying to design a computer game when he said “no battle plan survives contact with the enemy,” but the idea is surprisingly similar.

The example I want to discuss today involves the first “chapter” of Curses & Castles, where my main character must escape a dragon-guarded castle (there will be no plot spoilers below, unless you consider the fact that the princess eventually does escape the castle to be a spoiler). The original design document called for an aged an embittered princess, prisoner for 100 years, who would become youthful again once she escaped the reach of the curse that bound her there.  I felt when I wrote this that “a second chance at life” would reinforce the theme of redemption that I was trying to convey: it would give an edgy sense of purpose to the princess’s actions, explaining her selfless obsession with redeeming her country as well.  It had meaning, it had narrative power, and it helped to explain the magical mechanism through which the princess could be redeemed if she met an untimely death during game play (so as not to have to bring the player out of the game world if they wanted to retry).

Then I sat down to actually build the game, and ended up scrapping most of what was mentioned above.  The main problem was that the “old lady” princess  effectively amounted to a second main character that would require all the standard animations (walking, climbing, picking up, talking, falling, spell-casting, etc.) to be needlessly replicated.  The escape sequence wasn’t long, just a quick segment that served to get the player hooked and get the plot rolling, so it really didn’t make sense to double my workload for such a brief amount of game play.  The 100 year prisoner also didn’t add anything to the gaming experience that a 10 year prisoner couldn’t, and I felt in retrospect that an old crone limping around probably wouldn’t make for the exciting first impression that would lure gamers on.  Also, since successful games have characters that gamers can strongly relate to, the bitterness (later redeemed) was probably a good way to turn players off.  Finally, the magical mechanism for undoing death (a magic hourglass that can slightly turn back time), while clever in that gamers wouldn’t have to leave the “game world” to retry a sequence, added further complications to an already complex plot.  As I was trying to cram an explanation of its properties into an already bloated introductory script, I realized that the gaming experience would probably be clearer, if not quite as immersing, if the magic hourglass was scrapped altogether in favour of a simple “retry” prompt.

The result of all this carnage was a leaner game.  I easily saved 100 hours of drawing and animating, and also streamlined the gaming experience in the process.  I think the game is mostly stronger for these edits, but it did leave one gaping hole: my character’s motivation.  I think I’ve mostly solved this, but there is still some rewriting to be done to shore up the remaining gaps.  Whereas the aged princess was bitter at her lot (being helplessly captive for so many years), the teenage princess would suffer from melancholy.  Just as we can marvel at how a disengaged youth can become a passionate young-adult, I feel the princess’s newfound sense of purpose will leave the player with a feeling of hope and empowerment.

The lesson here is that in reality it takes a lot of effort to actualize an idea.  Bad ideas become especially costly to the game developer as they not only suck up time to implement, but might also put off would-be players.  Even good ideas can make for bad realities: a lot of time working for little real benefit.  The harshness of reality is the best editor, in that stronger and more justifiable components of a game inevitably demand more time and resources than hollow and superfluous ones.  In order to take advantage of what reality is saying, the effective game developer must be prepared to be flexible.  Sometimes it is necessary to sacrifice parts of the project in order to save the whole thing.  Realpolitick can be a messy business, but it has one overwhelming advantage over dreamy idealism: it gets things done.