[Most] games are awful for about 80 percent of the process—there’s no fun in the game until the very end.

David “Dr. Doak” Doak, excerpt From GoldenEye 007 by Alyse Knorr

I recently read Goldeneye 007, a terrific book covering the making of that classic game, and came across the above quote. I could not help but strongly agree with this observation, as I’ve seen it first hand countless times. Whether it’s making a game, or writing music, drawing art, or any creative activity, it always seems like the first 80% of the project is a slog. It feels like working on something that seems like utter crap and somehow refuses to come together, until the very end. It happens regardless of the type of project, the length, or even how challenging it is.

So it was very heartening to learn how ubiquitous this problem is. Apart from knowing and accepting that most creative work will feel like crap, what other things can we take away?

Things will suck, until they don’t

Even my most successful projects did not break this first-80%-is-crap rule. When making Dunkman for Ludum Dare, about half way through the jam, I posted this progress update:

This project had a very successful process - from the start I had a clear vision of what the game would be about: a silly send-up/homage to shonen sports anime. The game mechanics were simple so I could focus on polish: story, art, effects. But truth be told, until all the pieces were together, I was not sure if it would work, if the stylistic elements would overcome and elevate the simplistic gameplay. But they did come together - the upbeat music, anime speed lines, silly elbow IK animation, the chunibyo dialogue, all made for a ridiculously compelling narrative, like you were playing an anime protagonist.

So if you are a creator in that first 80% of the process, and everything seems to suck and it feels hopeless, take heart! Chances are you haven’t reached the last mile where things come together, like magic.

Finish Strong

When a project is near completion, things are coming together rapidly. The bang-for-buck of putting in work at the end is very high, given that the groundwork has already been put in place. This is where many make the mistake of racing to the finish line: they quickly put the missing pieces together, fix as many issues as they can, and ship the project as soon as possible. But so much value is being added during this last 20%, it often pays big to take your time adding polish and final touches, and you may reap unexpected rewards.

Goldeneye 007 was a cultural phenomenon because of its multiplayer, giving it incredible replayability and contributed massively to its success. And yet, “…GoldenEye’s multiplayer mode almost never got made.” On account of the project being a year behind schedule, Nintendo forbid working on a multiplayer mode, but the dev team, who were given incredible autonomy, did so anyway, furiously hacking it together in just 6 weeks. The rest is history - Goldeneye 007’s multiplayer was so good it overshadowed the already great single player campaign, and the game became one of the top-selling N64 games, revolutionising console FPS games.

On the other hand, I worked on a jam game, Lasso Lassie, which turned out much less well than I had hoped. The process of making the game itself went extremely well. I spent a week researching music and made a pretty cool western-themed chiptune track. I had a clear vision for the game from the get-go, choosing to remake the criminally underrated early NES game Field Combat. I made a solid plan and budget for all the dev tasks, such as implementing the gameplay, enemy logic, spawning waves, and finished on time having implemented everything I planned for. And yet the game just wasn’t that fun.

In retrospect I believe I neglected to spend time fine tuning the gameplay. I had falsely assumed that since I was recreating an already fun game, all I had to do was tick all the checkboxes, put the game together, and it would just work. But things like game feel or “fun” can often be fickle and elusive. Sometimes the difference between a fun game and a boring one is a 20% difference in player speed, or slightly increased enemy density, or a clever level layout, who knows. You really have to sit down and play around with the game, tinker with it until it is just right.

So here’s the take-away: if you have a deadline, or are planning out the phases of your project, don’t keep adding features up to the end. Plan for a feature freeze, and leave ample time at the end for playtesting and polish. It will often pay off in spades. Personally, for jams I leave as much as a third of the time available for polish at the end, and it has worked out extremely well for me.

Finish Your Projects

This is very old and evergreen advice for amateur creators: stop starting new projects and finish more of them. The temptation to abandon your current project and start over is strong, especially when you are in the first 80%. All the sweet ideas you have for new projects will feel infinitely sexier than your current project, which sucks more than ever, even though when you started it it probably seemed like the coolest idea out of them all.

Well now that you know, that’s more reason to stop the foolish cycle of abandoning old projects, starting over, only to abandon them mid-way again. If you start over, the new project will become the next awful project and you are back where you started. But if you persevere with the current project, when you finally reach that last 20% things will be awesome. Not to mention all the benefits of finishing - having good projects to show off, proving that you can deliver, gaining crucial experience in those finishing steps.

This is why I strongly advocate doing game jams. The tight schedule encourages people to finish games, limitations like secret themes encourage creativity, and feedback from fellow creators helps us learn what it takes to make a successful game project. Finishing games in such a short time puts you through that first 80% quickly, making it easy to power through and reap the fruits of that last 20%.

Non-creators will suck at providing early feedback, and that’s OK

When working on our craft - often a lonely endeavour - it’s tempting to seek out approval for our work from friends and family, to share progress or something cool we just made. But the response is rarely positive or helpful, since this rough work is from that first 80% when everything is awful, but this has little to do with skill or artistry. If even creators have trouble seeing past the expected roughness of early work, how can we expect non-creators to do better?

In most cases we should accept that feedback from lay people is not that useful. But what if we really do want to share something, if we’re proud of something we’ve done, how do we help them see it in the same light? My advice is to show finished work. Show stuff that has already made it past the first 80%, and has been polished and put together. This doesn’t mean you have to put in lots of work before being able to show it off, it could be something small, but packaged well. This could be:

• An art study
• Music loops
• A small, completed gameplay prototype or demo

In fact, being good at sharing work, even to non-creators, is a great skill to have and hone. Getting good at creating and sharing little bits of finished work comes in really handy if you want to market your work, build a following, or put together a portfolio.

Getting better at judging early work

What if you’re working on a big project, going on for months (or years 😰), how do you judge how the project is going? The simple answer is to practice and gain experience. A master will be able to look at a piece of work, at any stage of progress, see past the whole and into the components that make it up, and judge the quality of craftsmanship. Drawing from their years of experience, they can tell whether the project shows promise, or if it is fundamentally flawed. But this answer isn’t useful for the rest of us. Is there anything we can do besides, without the benefit of being an expert? Here are my tips:

Make vertical slices, then iterate

A vertical slice is a usable, completed yet very small part of the project. If you’re making an action game, it could be having the player character run around and perform one interaction, with one win and one lose condition. If you’re making music, it could be one looping bar (say the chorus) with full instrumentation. If you’re making a video or animation, it could be one fully developed scene, with sound and special effects.

The point of doing this is to get all the components together as quickly as possible, to see how they work together. By front loading this, you get to that last 20% part sooner, and reap the benefits. Once this vertical slice is done, it’s easier to iteratively expand upon it, which can be done very flexibly, without compromising the feel or the vision of the project, since it’s already put together.

One of the worst game jams I’ve done failed because we didn’t do this. I was on a new and inexperienced team, who did not know how to work well together. We scoped out the project and assigned separate tasks to everybody - art, music, level design, gameplay - hoping that we can just put it all together at the end. Unfortunately this is where things failed miserably. Not only were there technical issues integrating everyone’s work, it turns out everyone had a different idea of what the game would be, so that the work we did separately did not fit together, and lots of adjustments and cutting had to be done. For example, our 3D artist made really awesome character models and animations, but because the gameplay wasn’t ready, almost all that work had to be left out of the game.

These days one of my mantras for game jams is to get a runnable prototype up as quick as possible - preferably in the first day. Get everyone working off this prototype, so they can independently add to it. Audio guys can add partial music and SFX in to get the mixing right. Gameplay designers can get the game feel right at the start, and add things like levels and enemies that fit with the game feel. Artists can gradually replace placeholder art and see how everything looks in game and not just in their concept art. This way even a large team can work towards a cohesive vision.

This example schedule for a 7-day jam from 7 Tips to 7-Day Game Jams gives similar advice: core game mechanics done at 1/3rd, feature complete at 2/3rd, and the last 1/3rd for testing and polish.

Finish More Projects

When you’re in the first 80%, good and bad projects will both seem awful. How can you get better at telling? By finishing more projects! Only by finishing will you get a complete retrospective on what went well and what didn’t, and you’ll get better at what makes or breaks a project. But if you abandon projects half-way, then there’s no way to be sure.

One example: things often go wrong during a project, but they are not always fatal. Sometimes they can be worked around at the end. How can you tell? By sticking with the project until the end, and trying to overcome earlier mistakes. Another example is that projects can often fail because of a feature kept in, rather than a feature left out. A troubled feature can suck up development resources and jeopardise the project itself, but you won’t know this unless you let the project take its course.

When making PepperTown, an RPG-style idle game where characters auto-battle enemies and you buy upgrades for them, I had no experience making idle games, so I wasn’t sure what features would be key vs nice-to-have. I thought that, being RPG themed, I would need at least some sort of interesting combat mechanics, such as magic spells, or at least different types of enemies, but it turns out that was unnecessary. The final game just has characters battling one type of enemy - a slime monster - and with basic attacks, bashing each other repeatedly. But what makes idle games such as this is the visceral sensations of hearing the hit sounds and the coins trickling in, and the satisfaction of waiting and buying upgrades and sensing them affect the game. Thus I learned more about a new genre of game and what makes it work.

To make better games, I’m a big believer in the value of learning the fundamentals, even if they aren’t directly related to game dev. You can elevate your game dev skills using the principles of design and art. Go beyond the amateurish, to something that is professional and powerful.

Take animation, which is more than a century old. My go-to bible is The Animator’s Survival Kit, an absolute classic by an award-winning veteran. When people ask for quick tips, I also recommend Disney’s 12 Principles of Animation. Even though these guides were written before computer animation became ubiquitous, their principles apply regardless of the tools you use.

I often see people making games, putting a lot of love and effort into it, but the animation is lifeless and basic. If only they applied some basic animation principles, this could look so much better! Well, now I’d like to show how to do this, using a basic, side-scrolling platformer character example.

Let’s take a basic, pixel-art side scrolling character. This is Ticcy, the mascot for the TIC-80 fantasy console:

Giving Ticcy a basic walk and run animation might look something like this:

…and Ticcy has a hat, just because

And this is fine, to be honest. But let’s apply some of the animation principles, and see how much this can change.

Squash and Stretch

If something is accelerating, it should stretch out in that direction. If slowing down, it should squash. This helps highlight the motion and give objects a sense of weight as they move. Here we apply squash and stretch to Ticcy’s jump:

It’s cartoony when applied to something that should be rigid, but it highlights the jumping movement. And it’s dead-simple to apply - scale the character in the direction of the movement.

One thing to note, for realism, it is important to preserve the volume of the object. When we stretch Ticcy vertically, we also squash horizontally, so the total area of the sprite stays the same.

Anticipation

Also known as antic, this is the addition of an anticipatory action before a big action, so the action feels even bigger and impactful. A common example is a character winding back before taking a swing with a weapon. Here we apply an antic by making Ticcy do a squat before jumping:

The squat is very basic as we are just using a squash, but we could make it look better by animating frames for it. It makes the jump seem bigger by making it feel effortful.

Antics are hard to use on player characters because it slows down the animation. They are great for enemies though, letting the player read their actions, so it’s a key technique.

Staging

Staging is the idea of setting up the stage, or scene, to better focus the most important action. An exaggerated example is speed stripes, common in anime, which focuses the action on the character.

This is not something we can easily control in games, but there’s still a lot we can do. We can use environment art, shadows, and use camera follow techniques, to put the player character in clear focus. We apply this principle by adding an attractive background, making Ticcy stand out:

We’ve also added a ground layer, so Ticcy is no longer floating in a void.

Follow Through and Overlapping Action

Objects in the real world have inertia. When they start or stop moving, parts of that object will lag behind or continue along the previous trajectory. Think about hair or clothes on a moving character, which will flutter and bob around independent of the character. This makes things look more realistic or lively when exaggerated. Here we apply by making the hat move separately, following physical laws:

By adding a hat that is precariously bouncing up and down as Ticcy moves, it adds to the comical character.

Slow In and Slow Out

Objects in the real world don’t start and stop moving on a dime; it takes time to accelerate and stop. So when an object starts moving, it should slowly speed up, and so on. We can use this principle to show the weight of the object - the more we apply this principle, the heavier the object will seem. An object with no acceleration time will seem weightless. Here we apply by having Ticcy’s run start at a slow pace, and gradually speed up:

This example is exaggerated, but when applied to games, the effect is keenly felt.

Arc

When objects in the real world move, they do so in a well-defined arc following the laws of physics. Something flying through the air will follow a ballistic arc due to inertia and gravity. When objects don’t move in such a natural arc, it will feel out of place. Humans are great at spotting such discrepancies. We are trained to do so to perform challenging tasks like catching a ball, but this is subconscious.

Animators need to be aware of such motion arcs, but in game dev it is often the opposite case: it is easy to produce natural arcs in games. Take the platformer jump arc for example. One of the simplest ways to implement a jump is to add a y-velocity to the character, and apply gravity. This naturally creates parabolic arcs. But let’s step back and consider how we can be more intentional about jump physics. What kind of jump arc should we go for? How should it look, and feel? What is appropriate for the kind of game being made?

Take Mario for example. The games have non-trivial jump physics. You can jump higher the longer you hold the jump button. You have limited air control, and the falling speed also feels a bit floaty. Even different games within the Mario series have subtly different jump arcs:

This is totally something you can and should control in your games. You can design a unique jump arc to achieve a specific game feel. We may create a non-natural arc, but intentionally, and for a specific effect:

Instead of the basic parabolic arc, we make Ticcy reach the top of the arc faster, hold a bit, before falling down rapidly. This creates a squared-out arc, and it seems like Ticcy’s cartoonishly trying to stay in midair. The antic and squash effects we added earlier enhances the effect. This has gameplay effects too; you could imagine this makes it easier to jump over obstacles, for example.

Secondary Action

This is where we add actions to the character, in addition to the main one (like running/jumping). For example, a character talking or making facial expressions as they are moving about. This adds to the personality of the characters, and makes them seem more alive. They are no longer dumb automata that can only do one thing at a time, or what the player controls them to do.

We see this a lot in games already. Consider run-and-guns, where - as the name says - characters can shoot while running around. This requires animating the upper and lower bodies separately, so it’s a familiar technique for game devs. I would encourage adding more secondary actions, to make characters even more alive. Here we apply this principle by adding a blink animation, and also a mouth open facial expression when Ticcy is in the air:

This example is incredibly subtle, and you may not even notice it if it wasn’t pointed out. But it definitely adds to Ticcy’s character. You might consider adding things like idle animations, which are great for giving lots of personality.

Timing

Timing refers to how many frames an animation should have, to make it seem faster or slower. Slower moving objects, especially when reacting to forces, will seem heavier. This is something that game devs don’t have to worry about, since computers handle timing for us. There is however one thing that game devs often neglect, but is incredibly powerful for animation: easing.

Easing refers to functions that change the rate at which a property changes. We can apply it to motion among many other things. In the context of motion, most games just use a constant motion, or simple acceleration. But we can go so much further than that, to achieve cool effects, like make things look bouncy, wobbly, or feel floaty or aggressive. One simple way we apply it here is to add an elastic skew animation when Ticcy suddenly stops:

I mentioned earlier that objects starting and stopping on a dime is unrealistic. Here with an elastic easing function, we can stop Ticcy on a dime, but give the illusion of inertia. The body bends forward, before snapping back and forth. It’s a cheap way to make something that should be unnatural feel natural, as well as add more character to Ticcy. Perhaps Ticcy is made of rubber?

Exaggeration

In animation and games, we have the luxury of making things unrealistic and larger than life. We can exaggerate motion and go big for emphasis and effect. You’ve seen this in particularly comical animations from Warner Bros or Japanese anime. Think of eyebrows popping outside the face, comically enlarged body parts and so on. Here we do just that, by giving Ticcy a really big, disproportionate thumbs-up gesture:

This is a great way to give characters big personality and highlight their actions. In game dev it is a technique that is underutilised. 3D animators avoid it because it’s hard to deform models. 2D animators also avoid it as it can be expensive to apply. But because it makes characters so memorable, it’s definitely something you should consider, as animators Johnathan Kim (Skullgirls) and Paul Robertson (TMNT: Shredder’s Revenge) write in this great article.

Appeal

Appeal is a hard principle to describe; some say it’s analogous to charisma in an actor. We make protagonists likeable by giving them symmetrical features. Or we make villains terrifying with sharp, harsh angles. Beyond how a character looks, appeal can also apply to the way they move.

Ticcy’s character design is already very appealing. It has simple features and a very enlarged face that is almost the size of the body. This reads cute and pleasant, exactly how making games on the TIC-80 should feel. Can we take it even further?

Final Thoughts

I hope these techniques have inspired you to spice up your game characters. Every demo shown here is available in this interactive page: https://cxong.github.io/tic-80-examples/character-animation

Let’s see your cool animations!

Once upon a time I made a few 3D games, but these days I make exclusively 2D games. This includes both games that take place in a 2D space, and the artwork is made using 2D techniques. I believe it is easier to make a good 2D game than a 3D one, both in terms of playability and looking great.

While 3D definitely has its advantages - there’s nothing quite like the immersion of a first-person perspective, and 3D models can be infinitely oriented - overall I prefer 2D much more. Here are my reasons:

Easy to Understand

Hard to believe there was actually a 3-D Bomberman (right), released one year later

With the notable exception of VR, most games are played on a 2D screen, so it is natural to present games in a 2D plane. Humans have thousands of years of experience mapping things onto 2D surfaces; most maps are drawn on a flat surface (and it’s also why most maps of the world lie).

Even outside maps, humans often think of spaces in 2D terms, as we still live in mostly 2D spaces. Our towns, cities, roads, are all 2D. There are some 3D spaces - shopping centres for example - but they are a pain to navigate, since moving vertically is much more difficult than along a flat surface. In a sense we are a living organism that inhabits 2D spaces (and seldom layered on top of each other), unlike marine life for instance, which could be said to truly live in 3D.

Because of this deep cultural and evolutionary experience, 2D is easier to understand, easier to navigate, and easier to play in.

No Lighting / Shading

3D almost always requires a shading model and lighting sources. With some exceptions, such as wireframe rendering, you need a shading model to see the different surface normals. Therefore the most basic 3D scene requires lights and surface materials in addition to models.

Not so for 2D scenes. Even some of the most complex 2D scenes can be boiled down to 2D sprites placed around the scene and drawn in a certain order. The sprites can be painterly, pixel art, or any kind of style, and they will look just as good as the artist can make them. This gives artists maximum control, with little in between the artists’ pen and the screen.

This doesn’t mean that one doesn’t need to think about lighting however. Making a 2D scene look great requires thinking about the principles of lighting, and the art team still needs to decide how the scene will be lit, but this is manifested in terms of how to draw the sprites.

https://www.pokecommunity.com/showpost.php?p=8884279&postcount=37

But this is where artists can use their training in visual art to make the scene really pop, and furthermore the flexibility of 2D art allows them to achieve styles that are non-realistic yet highly stylised.

Cheaper Art

3D art has a higher quality floor. Barring super abstract art (such as Unity capsules), a basic 3D character typically needs hundreds of triangles, rigged with a skeleton and animated, and skinned with some materials. It also needs to meet some minimum quality criteria such as the feet meeting and not sliding on the ground while walking/running, and looking good from multiple camera angles.

http://ithare.com/graphics-for-games-101-asset-pipeline/

By contrast, the simplest 2D art is ridiculously cheap. A cheap run cycle could be 3-4 sprites. And although 2D art doesn’t scale nearly as well as 3D, remember that if the game is played in a 2D world, it doesn’t need so many orientations, so for most games, the art budget remains cheap.

No Camera

There is so much work involved in getting a 3D camera right that it can fill a book. The position of the camera, field-of-view, what the camera is attached to, who the camera follows… get any of these wrong and you can make the player disoriented and even motion sick. Early 3D games ran into all sorts of pitfalls with cameras, such as having things block the camera’s view of the player, or randomly zoom in and out to avoid such things blocking the view. Sometimes the camera might end up in an unexpected location and see unintended things, like parts of the level not modelled, or that the player shouldn’t be able to see.

Compared to 3D cameras, 2D cameras are much simpler, if it needs a camera at all. While there is a lot more to 2D cameras than most people realise, it is a lot simpler to set up, and a lot harder to get wrong. Even the simplest follow camera often does the trick.

Hybrid Approaches

It may seem like I’ve been dunking on 3D all this time, but I have great respect for it and acknowledge there are many places where it makes more sense than 2D. What’s more interesting though is how we can mix 2D and 3D techniques to achieve unique effects.

2.5D

Over the years people have used the “2.5D” term to mean different things - some variation of not-quite-2D-or-3D - but I’m referring to a game that is played in 2D, but contains 3D art. For example, using 3D models in a 2D game, or by adding depth and parallax to something that is still essentially a 2D game.

This technique has been used many times before. The overhead GTA games had 3D buildings to give a sense of scale. Since the early 90’s, fighting games have experimented with adding depth to the stages, using techniques like parallax scrolling and sometimes true 3D, even as the game is still played on a 2D plane.

It is a powerful technique but care must be taken so that the 2D and 3D elements don’t clash. Sometimes weird tricks are required to get the 3D part working well too.

Sprite Lighting

One big advantage with 3D is that with a lighting and shading model, you can show dynamic lighting effects, which really gives a sense of depth and solidity to the scene. Without lighting, 2D environments can feel static and flat.

But if you consider 2D sprites as flat textures, there’s no reason why you can’t use texture maps and shaders on them as well.

These techniques are getting incredibly popular, and the results look fantastic. You can use lighting to add atmosphere, do environmental storytelling, or add depth that is otherwise very hard to do in 2D.

Games like Graveyard Keeper use sophisticated lighting systems with pixel art

Unfortunately these neat effects don’t come cheap - they can multiply your art budget, and may require special tools. Dynamic lighting should also be used with caution, as they can ruin a carefully-crafted look that you may have aimed for with a well-designed palette.

2D Skeletal Animation

Animation is one of the most expensive parts of a 2D art pipeline. Things like increasing framerate or adding the number of directions can easily double your precious art budget. But this is only because traditional 2D animation is done frame by frame. Nowadays animation extensively uses tweening - getting the computer to draw the in-between frames given parameters like start and end point of motion.

This is easy for simple animation, such as motion, rotation and scaling, but characters are much harder because of all the different body parts and poses. To do this properly you would need to rig the characters: add bones, attach body parts to those bones and animate the skeleton. This is a technique common in 3D animation, but there’s nothing inherently 3D about it. You could use the same technique for 2D.

There are specialised software for 2D skeletal animation like Spine, but you could easily use a 3D modelling software like blender and either import the characters into your 2D game, or pre-render to a spritesheet, making it even easier to use. Dead Cells used this technique to great effect.

There are downsides though, as rigging represents a higher up-front cost, and unless you spend a lot of effort, there’s something lifeless about typical 2D skeletal animation - perhaps due to their overuse in cheap mobile games? Well-executed frame-by-frame animation gives you more artistic freedom. Still, there is a niche for 2D skeletal animation, and worth trying out.