How Games Are Actually Designed | So You Wanna Be A Game Designer? (#3)

How Games Are Actually Designed | So You Wanna Be A Game Designer? (#3)

Let us start with a story. Several years ago, I was asked to provide
some feedback on a game. I agreed. What I received was a 150-paged Game Design
Document, alongside some massive Excel spreadsheets and a bunch of level schematics. It would be impossible to process all that
information, not to mention I don’t think it would’ve been too helpful either – I
asked if I could get the latest playable version. The person said they don’t have any yet,
that they’ve spent the last 6 months working on design to make sure it is perfect before
starting implementation. Oh boy. Now, this was a very extreme manifestation
of an actually very prevalent mindset among inexperienced designers. That before implementing something, you need
to make sure it is designed as thoroughly as possible first. And it’s understandable why this mindset
exists. Because if you haven’t made a game and are
basing your opinions only on the final result, it is really easy to assume that first somebody
designed exactly what is in the game and then somebody implemented it. And if you decide to go deeper and search
for actual Game Design documentation, what you will usually find is their latest versions,
that once again show how it looks at the end of the process, but not how it actually got
to that stage. So, documentation is needed and is imperative
for game development, but it is important to understand that most of the things that
look good on paper either turn out to be not good at all, or need a lot of improvements. This is not exclusive to video games, manifestations
of this exist one way or another in pretty much all creative mediums, but it is especially
prevalent here due to the interactivity aspect. The difference between how you think something
will play and how something actually plays many times is ENORMOUS. Not to mention many other factors that can
come into play: budget, technical restrictions, timeline, realizations that something just
doesn’t fit, among other things. So the question is then, if video games are
not thoroughly pre-designed in advance, then how are they designed? Well, there are actually many ways to handle
the design of a game. It all depends on your personal style and
the culture of the company you’re working at. However, there is one thing that unifies all
successful styles of design and implementation, and that is the existence of a ‘Test & Iterate’
loop. You would like to make something playable
as fast as possible, test it out, see what needs improvement, iterate, test it out again,
and so on and on and on. This is where prototypes come in. If you have no game at all and are still in
search of the core gameplay mechanics – create either a paper prototype or something quick
in an engine like Unity, depending on what fits your purpose best, and test things out. See what needs improving or being changed,
do that, and test again. Eventually you will have something that can
become the actual core of the game. You already have a deep in progress game and
want to add a feature? Well, depending on the feature you can either
again make a paper or external prototype, or create something quick within the main
game itself – with placeholder assets, just to test things out. And iterate. And test. And iterate. And depending on what you’re trying to test,
even a session of ‘make believe’ using existing mechanics can be useful in different
contexts to test something out. And by the way, you’re not the only one
who needs to do the testing – you need to ask other people to do it and check how they
interact with the game. This is called playtests, and while officially
organized large playtests are really useful for checking out different project milestones,
there’s nothing wrong in asking somebody to approach and check what you’re working
on in particular. Even once a feature is already pretty established
and playable, these test & iterate loops never end, they just become more frequent with smaller
increments – it’s how everything eventually becomes polished. Check out the #Blocktober on Twitter for many
examples how Level Design layouts look like in early stages. This is great for getting a better understanding
of how video game development process works. If we get back to documentation for a bit
here, what this all means is that instead of putting every detail you can think of first,
you need to start from a broader higher level and then as you go through all the iterations
gradually dig deeper into lower level details. Now, there are ways to minimize the amount
of tests and iterations you might need to do in a game on any particular feature. The first obvious one is reference. Game development is a very iterative medium
and quite often mechanics take inspiration from other games. Such reference will allow you to get to the
final result sooner. Note, it doesn’t remove the need of the
‘Test & Iterate’ loop, just makes the first steps simpler. Even if you decide to make a carbon copy of
a mechanic, you might start seeing things that don’t fit in the context of your game
and therefore must be changed, or something that doesn’t interact well with other mechanics
so has to be smoothed out, and so on. There is no way to make everything work perfectly
in the first iteration. However, one other important factor is experience. As you keep making games, the results and
consequences of everything that you’re doing will be stacking up somewhere in your subconscious,
which means that in time you will have more surefire hunches regarding how something is
going to work. That said, no amount of experience will ever
remove the need of the ‘Test & Iterate’ loop. Regardless of how well thought out the theoretic
design is, you never gonna know for sure how things will work until you put it in practice. In fact, most of your professional design
career will consist of you thinking something will work, realizing that it doesn’t, and
then trying to figure out what will actually work. Rinse and repeat. Thank you all for watching. Next in this series we will dig deeper into
the notions of project vision and core pillars. Subscribe and click on the bell button to
know when it’s released. A special thank you goes to my patrons! If you’d like to join them, feel free to
support my campaign at Thank you very much.

2 thoughts on “How Games Are Actually Designed | So You Wanna Be A Game Designer? (#3)

  1. One thing that I would like to mention regarding all this is related to YouTube. There are many channels that release videos claiming to know how to 'fix' something in a certain game. The thing is, everything that I've said in this video applies to that type of content as well – they don't know for sure, and can't. More than that, most channels are also made by people unfamiliar with game development processes, and without knowledge of the context of the game's production. Which means that all this type of content must be seen as just fun theorizing – but not as some actually useful advice if you're interested in game design. In general, never stop yourself from theorizing, just learn to recognize when you're theorizing to not go into mindset full of fallacies.

    So what type of Game Design content on YouTube is actually useful then? Well, it is critiques and analysis. I.e. channels that take a look at the finished game, and analyze what works and why, and what doesn't and why. The most known example of this kind of content is probably Game Maker's Toolkit. This type of video is much more useful for your professional development than theorizing how to 'fix' something or how would you do something instead of what's in the game.

    And of course every type of content that is similar to what GDC channel provides – where developers actually share their insights, and their journey how they reached one or another particular goal in their projects.

    TLDR: Theorizing is good and fun, but don't mistake it for useful advice or something that you can put into your toolbox to try and apply later.

Leave a Reply

Your email address will not be published. Required fields are marked *