three beards devlog

As our resident artist, Luke is in charge of both producing our assets and also is taking the lead on designing the look of the game. 

As mentioned in a previous post, this means creating assets for every action a character does in left/right (Unity can automatically mirror them, so you don’t need to make both), forward and backward. Often there’s a two-thirds or diagonal movement too.

For this, Luke is working in trusty old Photoshop. It’s a tool most digital artists will be very familiar with.

For the sake of experimentation, he’s also done some hand-painted work but it’s a lot more process-intensive and takes more time.

The idea is to create sprites that can be used in multiple settings and different ways. Take, for instance, these hands.

Rather than individually making each frame of an animation – each movement of a whole character – it’s much more effective to create each part of an animation separately. These version of this hand can be used in a range of different actions and cutscenes as often as we need to. And we might also be able to use them for multiple characters.

In Photoshop, the layers need to be ordered correctly and it’s probably worth noting the details of the colour palette. It’s also important to take notice of the size of the artwork you’re creating and ensure consistency. If you cobble together one character and they’re twice the size of another it makes scaling them an additional and unnecessary bother. Likewise, if your up/down walk cycles are sized differently to your left/right ones, it involves a lot more tweaking to fix it up later.

Once the artwork is completed in Photoshop (or wherever) it’s a static item that’s ready to be imported into Unity, probably as something like a .png file or something that maintains a transparent background. But that’s just step one.

Now we’ve decided to use After Effects to produce the animations, we’re back to a place we started. Namely, importing a great deal of frames of animation into Unity.

One thing about animation is that if there are fewer than 10 or 12 frames each second, the animation starts to look a bit jumpy. Lets say our walk-cycle is 2 seconds long. That’s 24 individual images we need to upload into Unity. Around each of those individual sprites will be a certain amount of blank space, which still impacts on file size. Not the most efficient for time and space.

But there are a few sprite packers out there. A sprite packer takes each of those individual images and places them all on a single sheet as closely together as possible. Overall, it minimises the amount of unnecessary blankness, which boosts performance.

The first packer we tried was Shoebox. It’s free and has a really simple UI. And when it works, it works well. But for us that was only about half of the time. Another was Sprite Sheet Packer, another free piece of software but again not something we found to be as reliable as we’d hoped. In the end, Texture Packer by Code Web seems to be the best bet. On its own, it’ll cost nearly $70, though you get better value if you bundle it with their other software. Despite the cost, this is probably the direction we’ll go. It exports directly into Unity (and a lot of other engines), adjust pixel formats and scale, and you can also place pivot points before even putting it into Unity.

And once it’s in, Unity can separate out each of the frames without thinking twice.

We’ve been talking about a few additional features we want to play around with – if not in this game, then maybe in future projects. Matt has put together a few thoughts on some features he loves:

Since Matt and I aren’t from a visual arts background, we’ve had to learn a bit about the process.

Luke linked us to a useful series on Youtube by Alan Becker on the 12 Principles of Animation, and another video by the same guy specifically on the mechanics of a walk cycle. I’m not going to explain the process of animating something like a walk cycle here – I wouldn’t pretend to be an expert.

But not all animation in a game is about the characters. Luke has been thinking about bringing in small amounts of frame-by-frame animation into the backgrounds to add some life and movement – we already talked about doing that with keyframe animation for things like clouds passing and stuff, but frame-based animation gives us more ability to really give the world a nice rich feeling I think.

Here are a couple of simple examples of the kind of thing we’re talking about: http://www.rebeccamock.com/index.php?/ongoing/the-walrus/
http://www.rebeccamock.com/index.php?/ongoing/nothing-to-do-in-this-heat/

Anyway, so Luke put together this little gif test to show some frame-by-frame animation integrated into our game. It’d be pretty easy to add this sorta stuff in as long as we don’t get too carried away. A little bit goes a long way I think, and we can still have keyframe animated stuff to take care of the easier stuff.

We’ve been plodding along with shaping the look and feel of the game.

Compare these early sketches with our concepts for the map scene:

But while this is ongoing, one thing has been pretty clear to us for a while – producing animations is going to take a bit of work. In a game like this there’s usually a walk cycle for moving left/right (mirrored of each other) toward the screen and away from it. There’s often diagonal angles too. So each action a sprite makes needs to happen in each of these directions. In short, there’s going to be a lot of work on Luke’s shoulders. To lighten the load, Matt and I are going to try our hand at supporting the animation process.

There’s a bunch of steps to take into account in the process:

1. producing the assets themselves
2. packing them into a sprite sheet for smaller file sizes and better manageability
3. rigging the sprites, making them something we can easily manipulate
4. adding 2D dynamic lighting effects.

It’s a bit more complicated than that of course, but for the sake of brevity lets just leave it there. For any one of these aspects there’s a host of programs out there. Here’s a few:

It might take us a little while to settle on the software that works for us. If we have any insights we’ll be sure to share them. But to start off with we’re going to try Puppet2D. The price is good and it seems to do the things we need it for. Stay tuned.

We have the structure in place now, with the game mechanics basically working (some tweaks needed). The next thing to do is populate the game with text, and really develop the visuals.

Making the words

I spent a bit of time writing out each line of description that will happen when someone looks at or uses an object. It’s not the most exciting aspect of writing for a game, but it’s necessary. We’re keeping interactions straightforward, which simplifies things.

Writing dialogue is trickier. The first challenge I had was how to represent it, and the next was getting my head around branching dialogue structures. I considered using Twine to quickly represent and explore branching dialogue. I know of a few other indie game designers who use it, like Tim Hengeveld. It’s a simple tool designed for building interactive, non-linear stories. So it’s great for building dialogue trees, changing them, seeing how they flow.

As this blog series teaches, writing effective, believable branching dialogue that really supports the narrative of the game is a challenge:

Branching dialogue trees are clumsy, difficult to write and unrealistic. I’m one of the Players who loves them. I’m a writer who loves them. Because they’re the best we’ve got.

In this game our dialogue needs are pretty simple. But fortunately Adventure Creator has a nifty tool for branching dialogue that visually logical – much like Twine. It’ll help a lot once things get a little more complex.

Making the look

Now the initial concept work has been done, we can focus in on really developing the look and feel of the game. Luke came up with some more cartoon-like characters than the original sketches and Matt and I agreed they had a lot more life and reflected the style we really wanted.

It does mean that the walk-cycles and so on will need to be re-done, but that was always going to be the case. As for the backgrounds and objects, we’ve been pretty happy with how they’ve been shaping up. But there’s still elements we need to think about, like lighting and mood.

One project we think looks really cool is the upcoming indie game Jenny LeClue. Obviously the game style and look is different, but they lighting and mood in this game looks really effectively done using Unity 2D, After Effects, Photoshop and a few other tools. It’s a great inspiration; with some research and experimentation we’re aiming to get a pretty similar quality.

We have a build!

We’re a bit blown away by how quickly a first pass came together. Matt worked on it pretty hard. Got everything imported, moving around, all interactions ready, inventory items, puzzles and yeah the engine ready to go with all the placeholders. All the basic structures in place over a weekend, with only solid assets, descriptions, dialogue and sound to be plugged in.

OK so we’re still pretty far from the end. But as complete noobs to using Unity and game design in general we weren’t really sure how long it would take to all come together. It’s one of the key reasons we’re doing this game at all. So if you’re new to this too, take heart! With some persistence it can all come together fairly quickly.

There were some technical issues working across PC and Mac, even though we made builds for both platforms. And using Dropbox as container for all our work didn’t help, either. But with a bit of testing and experimenting, we had everything up and running pretty quickly.

But this only confirms something we already had strong suspicions about. The majority of time making this game will come down to developing assets – and since we only have one person with an illustration background and no-one coming from a specifically animation background, we’re going to need to share the load a bit. And we’re going to need a solid work plan.

One of the first things we set out to do was decide between using Adventure Creator plugged into Unity or to use Adventure Game Studio (AGS). We’ve played a few indie point-and-clicks and so we know there are great games out there that have been built with AGS and in Unity. But since we’re just starting out with this, we wanted to test our options and go with the one that worked best for us.

Step one was having assets to actually use. We’ll talk in more detail about them later, but now we have a few rough backgrounds, walk cycles, and objects, we’ve been keen to get in there and actually start building.

ADVENTURE CREATOR in UNITY

For the uninitiated, Unity can look pretty overwhelming. Designed for 3D games, it has a level of complexity that we didn’t really feel was necessary. Which is why Adventure Creator (AC) is so useful. Available for $70, AC is a great way to ‘block out’ a lot of the unnecessary aspects to Unity when making a 2D point-and-click and really focus in on the game mechanics of that genre (AC also comes with 2.5D and 3D options, and can be used for 1st person and other types of games, but we picked it for its 2D). With the power and complexity of Unity sitting behind AC, there’s still the opportunity to branch out once it’s a less intimidating working environment.

It comes with a range of features. Some highlights include an intuitive user interface for designing dialogue trees and avoiding coding, a ready-built (but easily changed) GUI for quick testing, fully resourced tutorial package, and it’s ticketed as working with multiple platforms (so far we only tested with PC and Mac).

ADVENTURE GAME STUDIO:

AGS is a great tool too. One bonus: it’s free. It also has a really active community, and it can be learnt quickly because the layout and design is pretty straightforward (if not especially flashy). Even the occasional dips into light coding aren’t at all intimidating even for someone who might otherwise be considered illiterate when it comes to programming languages. In just a few hours I had a playable game to test with.

We immediately came across a problem: Luke had been designing his assets based on a resolution of 1920×1080 because we want the project to have a refined, contemporary look that could then be scaled down if needed. AGS’s highest res settings are 1024×768. So the quality of the assets wasn’t being carried across (and their sizing on the screen wasn’t working well either). It makes sense that AGS should have those limits; it’s a tool designed to make games that replicate the look and feel of the classic LucasArts and Sierra games. It even comes with a Sierra GUI pre-built into it. But we consider those games as inspirations; we don’t want to actually replicate them.

Another issue with AGS is that it’s PC-only, which was an issue since we’ve been working across PC and Mac.

THE VERDICT:

We’ve opted to go with AC and Unity. It’s complexity also means a whole range of other tools will be available to us once we start fine-tuning – especially when it comes to animations. We want to be able to create a polished game for multiple platforms. AGS might be a tool for future projects, but for now we’re sticking with AC.

You’d be forgiven for not noticing this, given the project we’re working on, but we’re big believers in story-driven games. 3 Beards isn’t exactly going to be converted to an HBO series or win a Man-Booker. It’s intended as a test run. But the projects we’re already excited about working on after this one have (we hope) engaging stories and characters underpinning them.

Not all gamers care much for story, preferring aspects of gameplay to come first and using a story to string missions together. But I think this divide, gameplay vs. story, is a false one.

Point-and-click games have a history of being story-driven. I’ve mentioned Grim Fandango already in an earlier post so it might not surprise you to know that we’re pretty big fans of some of Tim Schafer’s work. The Secrets of Monkey Island, for instance, was among some of our first gaming experiences (it was also the first game Schafer worked on). And the classics that came out of LucasArts, like The Dig and Full Throttle are definitely still influences on us.

In an interview he did back in 2003, promoting Psychonauts, Schafer said:

You have to provide the character with motivation and you have to provide the player with motivation. Because the character will care about things that the player will not necessarily care about.

We hope to strike a balance between those two motivations in our future projects and build a connection between the player and the character. That means making gameplay work well with story, and vice versa.

As a writer, I’m probably a bit biased. But it seems to me that a well thought-out story is a stronger position to start from than gameplay. That’s because gameplay goes through changes and phases with developments in technology and player platforms. The ones that are remembered are usually the ones identified with some new feature or some dramatic shift in design.

But even while, for instance, point-and-click games might be out of fashion now among mainstream gamers (though they seem to be doing pretty well as indie games) it’s the characters and the stories from the classics that stay with us and inspire us.

Since the last post a fair bit has gone into building on the rough ideas:

Before building real assets we want to decide on the look and feel of the game. One of the most basic elements to start with is the three individual scenes; the cave, the ravine and the road. It’s been worth taking to look at every idea in each cell and discuss what we like and don’t like.

Some of the more cinematic shots are tempting because they’d give the game a unique feel. But at the end of the day we also want the angles not to be too intrusive on the player’s experience and high-drama shots probably won’t actually suit the mood of this game.

We’ll most likely combine some of these ideas. For instance, we liked the look of the tree in Ravine’s 9th cell but wanted a broader view like in some of the others. We also thought it would be cool to bring in some of the other angles during gameplay to highlight specific moments. For instance, when the character finishes the final puzzle, maybe the point of view can switch to the opposite side of the ravine.

Pretty soon after looking at these, Luke raised a good point:

Looking over those roughs I realised they don’t really connect, so we could possibly have a 4th screen that connects them. I figured we’d have the cave/shed entrance on that screen, so there’s still something they have to do there (break the lock). Otherwise it could be a map screen?

We all agreed – map screen was a great idea. It’ll give us the chance to experiment with some mechanics. And so we have this:

In case you think developing the mood of the game is all about the backgrounds, it isn’t. Matt’s been pretty excited to experiment with some sound design and has already developed a clip for the cave.