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. |
