Guest Blog: The Art of the Small

When opportunities arise, it is important that we make the most of them. In this article I want to look at the small opportunities; the events and funding pots that give studios a bit of breathing room to try something new. It is all too easy to think of these chances as the right moment to execute a master-plan; to start working on the passion project that will make you into a superstar. While I'd never say to anyone it’s not worth working on that dream game, it would be wrong to not pass on the advice I've gained from where I have gone for the passion project, as well as from the times I haven't.

Before I get into the how of the small, I want to talk about the why of the small. I'm going to talk about two examples where I think this ideology applies, the small grants (<£5k) and game jams. Both opportunities give you a chance to create something new; to take a step back from ongoing projects to realise an idea that’s been at the back of your mind. It is surprisingly easy take that opportunity for granted and try to fill it with the first thing that comes to mind. An example of this would be using a small grant to make the proof of concept for a huge RPG from scratch; with crafting, vehicles, an engaging story, and dynamic characters who develop over time, when you suddenly find two months in that all the money has been spent.

One of the universal truths of games development is nothing is as small as you think it is. If you take a small aspect of a bigger project, estimate how long you think it will take, and added some padding time for unexpected issues, if you doubled the time in your head you might then be close to how long it will take. In contrast, these opportunities give you a fantastic space within which to create something focused. Imagine having a new empty room suddenly appear in your house. A lot of people dream of implementing a minimalist style within their home, but their rooms are already full of belongings and furniture. You could fill the new room with the unsorted belongings from the rest of the house, or you could take advantage of the space to implement your minimalist dream. This is the idea behind the art of the small; to make the best use of the time afforded to you by a small opportunity by creating something focused and polished that showcases your ability to create a complete entity as opposed to your ability to build something wide instead of deep. 

Looking at an event like Develop Game Jam (which you can sign up for this year here: https://www.eventbrite.co.uk/e/develop-game-jam-2018-tickets-46545765638), you can see it as just an opportunity to make something new, but I think that undermines a very key aspect of the jam, the competition itself. Game jams present a very compact form of the project bidding process. From a given brief (the theme), groups build a game (the prototype/pitch/spec) which they then take to the judges (the client/brief setter) to have their game judged. At the end one team walks away with the prize (the project/funding). If you responded to a brief with a large amount of documentation without a lot of substance, you'd be unlikely to win. However, if you were to respond with something targeted at answering the questions of the brief in a concise manner, you'd have a much better chance of securing the bid.

It is time to look at ways of implement the small in a project. Every idea can be reduced to modules and components, the parts which make up the whole. Even passion projects are equal to the sum of their parts. For me, the art of the small is about focusing on developing one part (module/element/mechanic) to a high level of detail/completion, and then building the rest of the game around it, only implementing subsequent components based on necessity and how easy it is to then polish the game.

The first game we made with a grant was a huge pirate RPG. At the time, we thought we were building something small; a proof of concept containing a basic version of each mechanic in our game. Ultimately, while what we were was technically impressive, it was always doomed to clunking mess. The reason it was doomed is, although we were implementing only the initial forms of the features, we unable to leave enough time to make sure that those features worked well with each other, or to remove the bugs in the rest of the game. The result was that some people who played our game were put off when the camera froze, or the menu broke, or when the game crashed. Looking back, if we'd taken just one feature (the sailing, the crafting, the boss fights) and spent all our time making that aspect as polished and bug-free as possible, we would've made a much better and more accessible game that would have been more universally enjoyed.

For me, executing a small project comes down to three key elements: the brief, the mechanic, and the polish. In the next three sections I’ll examine each in turn and breakdown how they can be implemented in the game.

It is vital that the brief is adhered to. There's no point making something great if it's not what the judges/funders want. Note I said what they want, not what they say they want. This is all about research and planning. What are the actual judging criteria? What are the judges personally interested in? What's the context of the project? For example, if it's a game jam then fun is probably key, whereas for a prototyping fund the vision and a solid base game matters more.

After coming up with an idea that fits the brief, I usually focus on a singular core mechanic that realises my idea in a simple, clear-cut way. For example, if I concluded the judges wanted something fast paced, but almost finished, and my idea was to create a kind of free running game across a city to get home from work before dark, one of the simplest, clear-cut ways I could do this is to make a 2D grappling game where the player swings across cranes or high buildings to get across the map. In this instance, if I'd gone for 3D I'd enter issues of generating the city/buildings, creating the 3D obstacles, animating a 3D character etc, but this way I get my idea across while minimising the impact on the scope of the project.

Finally, but probably most importantly, the polish is key. A small, broken mess is still a broken mess, but with less features. Polish in this context loosely translates as the removal of edges. By an edge, I mean something sharp and pointy that would stick in a player and diminish their experience. If you're making something small, it's surprisingly straightforward to achieve a high level of polish without a tremendous amount of effort. I see polish as being the sum of three elements: limiting scope, thorough debugging and adding juice.

I've already talked about scope; keeping your game to essentials only. Feature creep and working out-of-scope are killers when it comes to polish. You can address the issue of scope from the outset by only adding features to your game that actually matter to the brief. Do you need a menu? Does that AI need to react dynamically? Do you need a save game system? If you don't, don't include it. It adds more opportunities for the game to break down and more components that you need to debug and juice later.

With regards to debugging, in this instance we're talking about the removal of as many bugs that effect moment-to-moment game-play as possible. You want a player to be totally engrossed in your game. Nothing is worse for a player than feeling at one with a game to get stuck in a wall, or be instantly killed by a random object, or for the whole game to chug and break down. By removing bugs, you give the player the best opportunity to stay totally immersed within your game space, which means when they finish they will want more (assuming you've made something engaging!)

Finally, the juice of your game is the small decorative and aesthetic elements that bring the still aspects to life. There are a lot of great videos about how to juice your game (see above), but the easiest way to think about it is to imagine the most engrossing game you can and imagine what would happen if you stopped still on a single screen. Would you be viewing a static image, or would things be happening? Is the text still, or is animated? What’s happening in the background? How is sound and light used to impose a mood? Very few games have nothing happening at any moment, and those that do use it as a contrast to moments where things are happening. Aspects such a colours, sounds, animations, and moving objects all add to the juice of a game. These are the elements which bring the otherwise static world of your game to life and drawer the player in. 

Just like the art of minimalism, the art of the small requires dedication to implement. I've highlighted every aspect that I've learnt and practiced over many game jams, funding opportunities, and personal prototyping, but it's still very easy for me to fall off the tightrope and build something wide instead of deep. Ultimately, this advice should help you keep your development in check if you're trying to build something small. Every time you want to build a new feature, think about whether you need it? If so, how do you keep it from breaking what you've already implemented? Finally, how do you make it worthy of your game i.e. how do you add the juice? Using these questions as guides, you'll be well on your way to implementing the art of the small in your next project.

Adam Boyne is co-founder at BetaJester and will be speaking at Develop:Brighton on Thursday 12 July. Find out more about his session here.