Monday, May 27, 2013

To Walk or Not?

So now that you've learned how to animate a walk cycle using rotoscoping, let's talk about how much you'll need to do it.

Admittedly, the process can get a bit tedious, especially if you're doing 10 frames.  With a standard 4 direction view, we're talking 30 frames of animation per walking character (assuming you're just flipping your side view.)  The question then becomes: how many of your characters actually need full walk cycles?

It all depends on your game.  You might have a huge cast of characters, but none of them might ever have to move from the spot they're in.  Or, you might have several characters that follow the player, or just walk around to add a bit of atmosphere to things. 

Let's take a look at some well-known adventure games.  In Sierra's King's Quest VI, nearly every single character has a full four direction walk cycle.  Some even have diagonal views! Most of them are 6 frames, but it's still a lot of work, especially considering the majority of them aren't ever actually seen in-game.  In fact, it was like this for most Sierra games.  LucasArts games, especially the ones made in the early to mid '90s were the same. 

Two notable exceptions are Full Throttle and The Curse of Monkey Island.  In these games, only the main character has a full walk cycle.  Secondary characters who are shown walking only do so for a few frames, animated as needed.  It's especially understandable in Curse where you had traditionally hand-animated cutscenes as well as sprites, but I wonder how much of it was due to budget constraints vs creative decision.

Then you have games like Broken Sword, which were also animated with traditional cel animation, but several characters have walk cycles.  So does this mean games with more walk cycles are better?  Not necessarily, but it will surely break immersion if you are in a crowded city street and everyone is  just standing around not moving.  Worse still, if there's nobody around at all.

Sunday, May 19, 2013

Rotoscoping Tutorial Part 3: Back Walk Cycle

For the final part of the walk cycle tutorial, we will focus on the back walk cycle.  The same technique here applies to the front walk cycle, which is why I'm not doing a separate tutorial for it or including it in this one.

Like the side walk cycle, you begin by filming yourself or model walking away from and towards the camera.  In an ideal setting, you would, again, have a treadmill, thus eliminating any problems with scaling.  However, if you don't, it presents an issue: you get bigger as you get closer and smaller as you get further.

Instead of being able to keep the same rectangle size as you were with the side walk cycle, you're going to have to do a separate one for each frame.  The trick to remember is to make sure your rectangle top and bottom both fall on the very top of the head and bottoms of the feet.

As you can see in the photo above, each frame is a different size.  Not to worry, however, since the tops and bottoms are at the same point, resizing them all to the same height will correct the problem.  In this case we are sticking with 70 pixels high.  Now all your frames are the same height, but each has a different width.  To solve this problem, we find out what the width of your widest sprite is.

Here we see that backwalk1.jpg, our widest, is 38 pixels wide.  Now all we have to do is enlarge the canvas size of all the other frames to be 38, keeping the image in the center.

Now all your frames are the same size.  At this point we do a quick check to make sure everything is aligned.

And finally, just as we did with the side walk cycle, we paste the head from the standing view onto each frame and trace the rest of the sprite from there, making sure that the head stays in more or less the same spot, although with front and back walk cycles, the head bob goes about one pixel to each side rather than up and down.

Final result:

Friday, May 17, 2013

Rotoscoping Tutorial Part 2: Side Walk Cycle

For the second part of the tutorial, we will be examining how to rotoscope one direction of your walk cycle.  Probably the easiest one to do, the side walk cycle can still be tricky to get right.  Like anything else, it comes with practice, so don't feel frustrated if your results aren't perfect the first time.  I still have to do plenty of tweaking after the fact, as we will see below.

The first step is to film your model walking.  Ideally, you'll have a nice, clean studio, with a treadmill to walk upon.  Realistically, you'll probably have to do what I did and go for a walk in your back yard.  We'll start with the side view because you don't have to worry too much about resizing, like we will for the front and rear views.  Set your camera up on the tripod, keeping it about a height slightly lower than your chest, but making sure that there's plenty of space above and below the plane you'll be walking, so you stay within frame.

Once you've filmed yourself striding across camera, take your movie file and import it into a video editing program.  I use Adobe Premiere Pro CS5, but before that I was using regular old Premiere.  Find a section of your video where your model completes a full two step stride, then go back and go frame by frame, exporting the individual walk cycle frames.

In Adobe Premiere Pro, there is a handy "export frame" button right here.

 This depends on how many frames you want your walk cycle to be.  Rotoscoping will give you a smooth result, so my recommendation would be either 8 or 10 frames.  It really depends on how much animating you want to do.  For Ben Jordan I used 8, but for A Golden Wake I am using 10, so we will assume that this is the number you will be using too.  Once you select a point in your walk to start from, I suggest skipping ahead 4 frames to pick the subsequent ones.  This way, you'll have completed two steps by the time you hit 10.

Once you've got your 10 frames, it's time to open up your paint program and all of your frames.

Find the frame where the model's stride is the widest, then use the rectangle selector to crop it down.

Make sure the height of the box tops off at the top of the head and the bottom of the feet.  Next, move the box to the other frames so it maintains the same size, and continue cropping, until all 10 frames are the same size.

Now you can resize them all to sprite size and begin the tracing process.  At this point, you can always test to see that you've got a smooth animation.  Putting them all together gives me this:

As you can see it is slightly jerky, but that has more to do with the way the image was cropped, as it was more or less eyeballed.  This will be fixed for the final animation.

Next, as we did in part 1, we open up the files, but also our completed side view.  Copy the head from the side view onto the head of the walk cycle view for consistency, and also as a guide.

Now, we trace!  Every now and then, you should turn off your background layer to make sure your sprite is looking more or less proportionate.  As there is a lot of anti-aliasing happening because of the resize, it can be easy to make things a lot bulkier looking than they should be, for example the sleeves in this case.

 When you've finished tracing, erase the original image so only your sprite remains, and do any necessary cleanup of extra pixels .

Now, when you start on the next frame, paste the head in, and check to make sure it's in the exact same position as the frame you just drew.  In most versions of Photoshop, you can see this in the navigator window.

Check to make sure the head is aligned here.
 Doing this will avoid your sprite moving around jerkily in the final animation.  Continue this process for all the frames, keeping in mind that there is a head bob when people step.  Once you've finished, you should hopefully end up with something like this:

So there you have it.  Next time we'll deal with forward and backward walk cycles, which are just as easy, but involve a bit more prep work.

Thursday, May 16, 2013

Rotoscoping Tutorial Part 1: Character Design

For the first part of my rotoscoping tutorial, I will show you how to design a character, because if you're going to animate using this method, it's best to keep your character's proportions consistent.  There's nothing worse than having your character's head suddenly shrink a size just because the original sprite you drew doesn't match up with the proportions of your rotoscope model.

The first order of business is to do a bit of cosplay.  That is to say, dress up as close to how you want your character to look.  This step isn't essential, but it makes things a bit easier.  If your character is wearing a long coat, for example, it will help you convey the movement of fabric much easier if you rotoscope than if you animate it freely.  Once you've gotten into your outfit, get your camera on a tripod and take a photo of yourself in the 4 main directions, plus diagonals if you're feeling fancy.  You might want to do it in front of a blue or green screen, but that isn't totally necessary either.  I usually just do it against a backdrop that isn't excessively cluttered.

Once you've got your views, it's time to go to your paint program and resize them.  In my case, the average height of sprites is anywhere from 67-70 pixels.  This guy will be 70, so we will resize accordingly.  This will make the photos nice and pixellated, like so:

Now comes the fun part.  If you open up your individual resized views, you will see how pixellated and blocky they look.

This is where you begin the process of tracing, aka rotoscoping.  It all depends on how much detail you want in your sprite.  Sierra games would more or less import this as-is, since they were shot against a blue screen.  All they had to do then was a bit of cleanup and downgrading of palette.  For purposes of this tutorial, we are going to trace.  Pick your palette, usually about 4-5 tones per area, and get started.  With a bit of luck, you'll end up with something looking like this:

From there, it's just a matter of tracing the rest.  Keep in mind you don't have to stick to your model.  Obviously, the character can have a different hairstyle, or the color of the clothes can be different, or the skin tone can be lighter or darker.  The only problem with using yourself as a model is that it can be tough to do different body types.  Height is easily adjusted, but if you want a heavy character, making yourself wider can look a bit silly.  In cases like these, I usually do a Google image search or get someone else to pose for me.

Final result:

Next time, I'll cover animating a walk cycle for this character.

Wednesday, May 15, 2013


Adventure games are all about exploring your environment.  You point, you click, and you get a description, or a comment, or the character performs any myriad of actions (you hope.)  In good adventure games, you'll get some sort of response. In bad adventure games, that response will be "that doesn't work," or "I don't see anything special."  In terrible adventure games, you won't even be given the opportunity to get a response.

In my opinion, possibly the biggest sin committed in an adventure game is a lack of interactivity.  Let's say you enter a room that is decorated with all sorts of interesting items, but the only one you can interact with is the one you actually need to progress.  How frustrating is that?  I want to look at the oddly-shaped lamp, even if I just get some jokey description of it!

Now, to play Devil's advocate, too many hotspots can also be confusing.  This opens the door to pixel hunting, which nobody likes, and often times can be overwhelming for the player.  Like everything else, the trick is to find that proper balance.  Personally, I usually try for 10 hotspots or less per room, but I always try to have more than 4.  It all depends on your environment, of course, but often times things can be consolidated.

For instance, if you have a fantasy game with a room full of treasure, and your background drawing shows gold coins, chests, rubies, scepters, etc, it would be unfair to the player if the only available hotspot was "treasure."  On the other hand, if you made a separate hotspot for "coins," "rubies," diamonds," "scepters," and every object in the pile, it might be too much, especially if you need to take one specific item of treasure.  You'd be fine with "coins" and "trinkets," with maybe "baubles" thrown in for good measure, and in your description mention the individual bits.

I'm going to call out one game in particular which suffers from both problems I have mentioned.  Said game is Runaway: A Road Adventure.  This game is drawn in lovely high resolution with backgrounds that are jam-packed with detail.  In some backgrounds, there are entirely too many hotspots.  At other times, hotspots won't appear among the already too many until the player finds out he needs something (which is an entirely different subject.)

Then you have backgrounds like this one:

Look at all that interesting stuff!  A well, a skeleton, some weird saint on the wall, a painting, a chicken on a dresser, a stuffed owl.  I could go on all day.  Do you know how many of these items the game allows you to interact with?  Go on, guess.  Do you give up?  Ok, I'll tell you.


That's right.  This room is only used for cutscene purposes.  You walk in, the creepy lady tells you she needs something, you walk right back out.  You never once have control of the player in this room.  You have no idea how much that irritated me.  It was just one more strike of many others against this game.

In any case, take heed developers: let your player interact with your world.  Not only is it fun, but it adds to the immersion like you wouldn't believe.

Sunday, May 12, 2013

On Rotoscoping

It's no secret that adventure games made by Sierra On-Line and LucasArts were a big part of my childhood and early teenage years.  I enjoyed what both companies had to offer, but I always categorized them in my mind as Sierra = realistic and LucasArts = cartoony.  When I started making my own adventure games, I was more drawn towards emulating the Sierra style, in part because I was going for an art style based more in reality, and also because the default interface in AGS was the Sierra GUI.

I was also always more interested in Sierra's production techniques for their VGA games, namely the fact that most of the backgrounds were done as oil paintings which were later scanned in, and the character animations were largely rotoscoped.  Sierra was not the only game company to do this, of course.  The classic Out of this World/Another World and Prince of Persia are great examples of early rotoscoping animation.  However, rotoscoping was something that set Sierra apart from LucasArts, as the latter never used it in any of their games.

For those unfamiliar, rotoscoping is a technique in which a subject is filmed performing an action, and then those frames of film are traced over to create the animation.  It's best seen in Ralph Bakshi's Lord of the Rings or the work of rotoscoping pioneer with an incredibly oddly spelled first name, Eadweard Muybridge. It's a fair bit of work, but for people like me who aren't very good at animating by hand, it can be a real asset.

Obviously, the oil painting backgrounds is out of the question, as I have neither the time nor the money to spend on that many canvases, paints, and a scanner.  Besides, the "painterly look" can easily be emulated in Photoshop.  However, rotoscoping is far easier, and in my opinion, gives great results.  Is it cheating?  Maybe, but I'd rather cheat than have a crappy looking animation.

So how is it done?  The simplest way is to film yourself or someone you know performing the action.  Nowadays, this can easily be done with a digital camera, or even most smartphones.  Just make sure you have a tripod or someplace to set your recording device.  Once you've got your filmed action, you can use a video editing program like Premiere or Windows Movie Maker to export individual frames, which you can then load into your paint program, resize to the size of your sprites, and then paint over.  The only downside is that you often end up with very long animations, especially if you want them looking smooth.

I'll probably do a more in-depth/hands on tutorial in the future, as it seems to be something quite a few people are interested in.

Saturday, May 11, 2013

The Curse of Self-Improvement

Yesterday I began working on a new background.  I spent a very long time on it, even going so far as to wake up at 4am because I had the nagging feeling that a tree needed to be tweaked to look right.  After several hours, I finally reached a point where I was happy with it, and imported it into the game as a final version.

This is a relatively new feeling for me.  When I made the Ben Jordan games, my mantra was always, "fuck it, it's freeware."  Looking back, it seems that was a double-edged sword.  On the one hand, if I'd had perfectionist mode on, I probably never would have finished the series.  On the other, there is a lot of art in those games that could have been done a lot better.

However, we're always improving, be it with our art, music, writing, etc, and looking back at old work often makes us want to do it over or change things.  Sometimes, we get the chance and come out better for it.  Other times, it's better to just leave things as-is and move on to new projects.  However, what happens if, for example, midway through making your game, you discover an interesting new technique which makes your backgrounds look way better than before?  Can you afford to go back and make changes to your old work?  Will everything still be artistically consistent?

I've been learning a lot lately, not just from practice, but also from the guidance of Ben Chandler, and looking back at some of my old backgrounds for A Golden Wake, I've realized I could improve upon them quite a bit.  In some cases, I have.  In others, I've decided they're passable, but with a bit stricter attitude than before since it won't be freeware.  In any case, I think this is a fairly common issue, and an unfortunate side effect of learning and self-improvement.

It seems that this is probably one of the biggest hurdles for developers to overcome, especially in the AGS community.  I've often seen people post about how they think their art skills "aren't good enough," and so they get discouraged and never release a game.  Very few people start off as amazing artists, and if you look at backgrounds from older games or even modern ones, it's easy to find flaws and mistakes.  Nobody is perfect, and that shouldn't be a hindrance to expressing your creativity.  It's better to release a game that doesn't look great and serves as a learning experience than to get frustrated and give up.  

Tuesday, May 7, 2013

Ambition or Naïveté?

In the past, I have been asked the infamous question, "what advice would you give someone who is making their first adventure game?"  The usual answer is "start small."  It's true, overambitious design is the #1 killer of indie games.  Most people start out wanting to make the next Monkey Island or King's Quest, but once they get a fair way into it and realize how much work it actually is, especially if working solo, enthusiasm usually dwindles and the project goes into stasis or just plain dies.

Starting small is good, because it means you're more likely to get your project done.  Even if it's terrible, you'll have that feeling of accomplishment that comes with putting out a game.  Plus, you can always use it as a learning experience for your next game, which is the most valuable result of all.

All this is well and good for beginners, but what happens when you've designed and finished several games?  How do you know when you're being overambitious?  There are always personal limits and boundaries to be pushed and experimented with, but does there come a point where you have to step back and realize you've bitten off more than you can chew?

I thought about this today as I finished writing A Golden Wake.  So far I've programmed the prologue and first chapter, and most of the assets are in the game.  I began seriously putting the game together around October of last year, which as of this writing was 7 months ago.  Granted, I haven't been working on the game full time every single day, but that's still a rather lengthy development cycle, especially for 1/4 of a game. 

Chapters 2 and 3 are pretty standard stuff well within my comfort zone as far as programming and art goes, but I really went crazy with chapter 4 and am questioning how I'm going to make it work.  There will be a way, I'm sure, but there is still that nagging feeling of maybe having gone a bit too far.  Then again, if I wanted to play it safe and not do anything unknown, the development process would get stale, and the end product could just be mediocre.  Pushing myself out of my comfort zone might result in something amazing, or it could result in a disaster and I might have to find an alternate solution. 

Either way, I guess it's worth a shot.

Sunday, May 5, 2013

Quality vs Quantity

One particular issue I've always struggled with is game length.  Back when I was doing the Ben Jordan games, I would write out a very basic design document outlining the story, locations, and to a point, puzzles (spoiler alert: I made most of it up as I went.)  One thing I found was that no matter how extensive the game seemed on paper, when it came down to building it and playing through, it was always significantly shorter.

Now, one can blame this on the fact that the developer knows the game and can easily blast through it, but it's always a matter of concern.  Granted, many classic adventures can be played through fairly quickly if you know all the puzzle solutions.  In fact, a lot of the old classics more or less counted on the fact that the player would get stuck as a means of extending play time.  I've seen people speed run Day of the Tentacle in less than 20 minutes, and most of the Sierra "Quest" games can be completed in a couple of hours.

So why is this an issue?  Partly because there is a feeling of disappointment, after putting so much time and effort into something, that the result it yields is such a brief experience.  I suppose the same can be said about movies, really.  The cast and crew spend months preparing, filming, and editing, and in the end it's all distilled into a 1 1/2 to 2 hour film.  In games, though, you tend to feel it more.

On the other hand, sometimes a story can be ruined by being too long.  I know several people who complained they lost interest in Grand Theft Auto IV because the main story just kind of went on the back burner midway through.  Sometimes a story just doesn't need a bunch of subplots.  Straightforward can be good.

In any event, I managed to get through the prologue and first chapter of A Golden Wake in 20 minutes the other day.  I was a bit concerned, but then I remembered there are still 3 more chapters to program, and on paper, they're longer than the first.  If each of those takes me 20 minutes, then we're looking at a relatively decent sized end product.

If, however, the whole game takes me 20 minutes to get through, then I'm in trouble.

Saturday, May 4, 2013

How Far Is Too Far?

Player characters come in all forms.  There's the classic goodie two-shoes hero, the damaged anti-hero, the blank slate, etc.  For me, the most interesting aspect in games, and adventure games in particular, is the character development.  In a good game, your main character won't be the same person he or she was when they began their journey.  Still, the choices they make and the actions they perform define them, and sometimes, if something comes out of left field, it can ruin immersion as well as believability.

Starting off a game with a new main character is always an interesting challenge.  How much of the character's history do you reveal straight away?  Is there an air of mystery about them you want to preserve?  Will the player find it difficult to sympathize or put themselves in the role if they don't know everything about them?

Once you do get to the point where the player "knows" the character, it gives you some room to play around.  However, you must be conscious of what you've already established.  It will seem very out of place if a character who has been shown to be respectful of the law begins committing crimes out of the blue.  It all depends on the context of the story, really.

What happens, though, if your story is about someone who starts off good, but goes on a downward spiral into evil?

I have to confess I'm not a huge fan of Star Wars, and only recently saw all 6 movies (gasp!)  Although I'd heard little good said about the prequel trilogy, the aspect that interested me most about them was how they showed Anakin Skywalker's gradual corruption and transformation into Darth Vader.  Unfortunately, this wasn't handled very well, and it seemed rather abrupt, which is an easy pitfall.

If you have a protagonist who is going to go over to the non-righteous side, how far is too far? If you want to show them becoming a completely unlikeable ass, then the sky is the limit.  If, however, you want your audience to feel sympathy, or even give them a shot at redemption, you have to be more careful. 

It's a dilemma I'm currently struggling with, but I think I have a general idea of what the limits are.

Welcome to The Speakeasy.

Hello, and welcome to The Speakeasy.  I'm calling it this because it will be my place to "speak easy" about the development of my current game, "A Golden Wake," which is set in the 1920s. See what I did there?

Updates will be somewhat frequent, or as often as I remember this blog exists.  In the meantime, if you haven't heard of A Golden Wake, check out the official page at