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

VIDEO TRANSCRIPT

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 patreon.com/farlands. Thank you very much.