Game design is a young art. With any art, there are some very basic fundamentals that must be thought about before you can explore. We will go through ways in which developers like to capture their thoughts in a “document.” Then, we will start with a micro-lecture on how each decision should be deliberately as granular as possible. Then, we will build on those decisions with iteration. Finally, we will go through an explanation of concepting. Let’s get started with a discussion of design documents.

Game design document

There was a time where our team had some downtime between our development sprints in which we wanted to all jump on board with a new tool. Our project management was using the Atlassian stack (Jira, Confluence, etc.), but we wanted to see what would be better, so we looked through several different software. This included Hack N’ Plan, Trello, Notion, and several other tools. We used all these tools to see which ones would end up getting used after our break. In the end, we found out we liked Jira for the project management and tasking, but for everything else we stuck with Miro. Miro ended up being our concepting boards and design/workflow brainstorming tool. This happened organically through other tools just not being used by the majority of the team.

No matter how small it seems your game is going to be, there will be some sort of documentation that will need to take place. There are strong organizational reasons behind making a document, but the strongest reason is that when we put something down on paper or draw it out in a collaborative space, we tend to take time to more seriously consider its merits. This pause is sometimes referred to as heuristic design. This can be done alone or in collaboration.

Some designers wish to draw up a beautifully written, well-outlined document in a word processor or an online collaboration tool. This gives a neat outline and the ability to write each detail exactly. When the scope of the game is going to be larger, this works out well. The writers tend to be technical writers and well-versed in the art of documenting processes. The approach is to have a single source of truth for any part of the game that anyone can refer to while developing, but to go to this extent may not be the best method for you or your team.

Another option for game design documents is done through collaborative brainstorming software. This allows users to work together to make flowcharts, draw, and outline in a creative manner. This manner is the direct opposite of the curated form of the aforementioned written document approach, but serves a different need. The creative form tends to be more intimate and art-focused. Some pre-concept art sketches are done, flowcharts are drawn up quickly to draw out questions about the gameplay elements, and ideas can be swiftly drawn upon and tossed away or kept. This way of designing wouldn’t work well for a large-scale team as there is no real organization of sorts. New members would have a hard time onboarding in these situations.

Figure 2.1: Example of a flowchart

Neither of these options is the magic pill to make a game design document, but rest assured, your team needs to have some sort of document to keep your ideas written down. Ideas are fleeting on the mind and some of the best ideas slip into the ether if they aren’t written down to keep. Experiment with your team to find the option that best suits them. There is a saying in design groups: “The best tool is the tool your team will actually use”.

We’ve gone over quite a few options for game design documents and shown that they have pros and cons. Even though there isn’t a perfect way right off the bat, a great starting point would be to start with a more visual and collaborative approach. If you are together, this could be a dry erase board with sticky notes. The dry erase board allows for non-permanent thoughts, while the sticky notes would be tasks that need completing. Place them on the left side for “need to be completed,” and move them to the right side when they are complete.

I recommend you spend some time over in our GitHub repo created for this book. I’ve added a GDD images folder in there for you to take a look at a large scale of examples to see what we’ll work through in the next set of chapters.

https://github.com/PacktPublishing/Unity-3D-Game-Development

Now that we have started documenting our game design, we need to take our thoughts and make deliberate choices with them to make them concrete.

Deliberate decisions

Although this part of the chapter may be slightly shorter than others, take this section to heart: being a designer means building an immersive world that makes sense, even when it doesn’t make sense. The player subconsciously makes observations at an alarming rate. The more that the player can see non-congruent pieces to the puzzle that is the game environment or character, the more immersion is broken. The best way to fix any immersion-breaking issue is deliberate decisions.

To give a very simple explanation of this, take the example of door handles. You’ve seen them your whole life and used them intuitively. In fact, when you have to deal with a poorly designed door handle is when your actual, real-life immersion breaking happens. If you have ever grabbed a handle to a door and tried to pull inward, only to find out the door was designed to be pushed, you’ve encountered this issue. If the door was designed to only be allowed to move in one direction, the correct design for an exit is a flat panel where the door handle would be. This immediately implies “push.”

Every level, mesh, texture, concept, and feeling needs to be deliberately thought about with an attempt to implement. Only after you have a strong reason to place something in a certain way without giving in to clichés is when you then can explore other unique aspects to build something truly unique.

The project you will be making and playing with in this book has undergone prolonged and deliberate thought. To emphasize this, in each section, you will see a set of questions that are answered in as much detail as needed in a concise manner.

Iterative production

Game development has an interesting need for immersion to be at the forefront of play. To get this immersion as complete as we can get it, the development team needs to continuously ask whether the direction it is going in works well. Very often, the game that you began developing is not what you will ultimately end up with. This cycle is called an iterative design or production.

There are a multitude of patterns you can use when you undertake iterative design. The approach that will be described here is not the only definitive approach to completing a design, but it is a good starting point from where your team can branch off as it sees fit.

Iteration needs to happen often and early for a game to grow in terms of how easy it is to understand. There is a concept called MVP, or Minimum Viable Product, where game developers make the minimum amount of gameplay elements required to give the game to testers. This should take very little time and the feedback is invaluable. When you hand this off to the testers, there will be feedback that you and your team could not have seen as you are very close to the product. Make sure to listen to the feedback carefully with an open mind as their experience could be common among your players. We’re working toward a deliberately designed experience for as many players as possible. This feedback forces you and your team to iterate on the design, and possibly cut or add game mechanics, to respond to the main testing feedback.

Figure 2.2 a, b: Examples of iterations in level design

After having iterations resolve major holes in your design, you then move into a vertical slice (which will be covered in the Vertical slice section of this chapter) of the game. This should be an iteration where you are comfortable with the basics of the movement and primary game mechanics. Your team will want to make a full game loop from start to finish with a single level that houses a win and lose condition. Then, you guessed it, test again, but this time with new testers that have never seen this game. Ask similar questions and some new ones that have surfaced during internal playtesting.

The loop for development should seem repetitive, and it is:

1. Think and test
2. Create and test
3. Update and test

Then, continue this approach until you are at number of iterations until it’s a shippable product. The most important portion of each step is the testing. Make sure to take feedback from testing as strong indications of where improvement is required. We will begin this cycle with conceptualization.

Concepting

You need to make a game and you have a group ready to go. You are comfortable with deliberately making granular decisions and know the iterative process. Now you need to get a concept started.

The first step to getting a project going is to explore what emotion you and your team want your players to experience. With our art form being so young and malleable, we can pursue this emotion any way we like. This is the power of the game developer. Once you know what emotions you are focused on as regards the experience players will have, start thinking about how you can create it as a gameplay experience.

If the emotion is fear, you could have the player deal with spaces that are dark, with just a flashlight as their primary defense tool. This may lead you to explore sound design as your development focus since vision will not be the primary experience tool.

If the emotion is grieving, then you may work through a narrative focus, where you play a child who has lost a family member and the players work through a narrative-driven gameplay in a dream world. This pushes storytelling and pacing, with a tight understanding of color theory as well as the stages of grief through a child’s perspective.

We could go on for a while regarding concepts as there is an infinite number of scenarios. Choose what your primary goal is and then work toward it. After this, you may want to put some of these ideas to paper to get an idea of what the feelings of the immersion will be, from an artistic viewpoint. This could potentially be silhouettes of character concepts. It could also be architectural designs.

It could also be a collection of pictures you’ve saved that gave you a feeling of the emotion you want to evoke that you can draw ideas from.

Figure 2.3 a, b, c: Concepts used in project

Either way, the prominent action is to get the ideas started visually. After you have some art panels drawn up and you have a visual idea of how this may be built, we then make a Unity project.

You’ve put together a concept that you want to develop, and now we need to get Unity and create a project. To do this, we need to get the Unity Hub and then choose a version, followed by a template to start with.

Unity Hub

Unity Hub is a small application that holds all of the projects in a centralized location so all of your projects are easily accessible as well as the versions of Unity you have installed. To acquire Unity Hub, you need to go to unity.com and create a UnityID. After you create an account, click the blue button named Get Started. Follow the prompts that best make sense for your needs and operating system. Download and install Unity Hub and let’s get creating!

Choosing a version

Unity runs multiple versions at once. There are Alpha, Beta, Official, and LTS releases.

Alpha versions have experimental features that may not be fully complete or production-ready and are not recommended for builds as there may be features causing build-breaking bugs. Studios and enthusiasts may use this for testing mechanics, engine features, or packages. They are generally one release ahead of official releases. Beta is similar to Alpha versions; however, they are experimental versions of the most current official release. Official releases are stable current releases. LTS means Long-Term Support. These are the final releases of a version with minor hotfixes if bugs are found.

An easy way to see the versions is through the Unity Hub. An example of what this may look like can be seen in Figure 2.4:

Figure 2.4: Example list of Unity versions

LTS releases are recommended for a production application. If your team is experimenting or looking to prototype with new features, it would only be possible in prerelease versions. After choosing a version for your project to be built in, you need to choose a template from Unity’s options as you make a new project.

This book, however, is version independent. If you’ve bought this book after 2022, the book is still as relevant as it can be. The screenshots may have slight UI changes, but the foundations still remain intact.

Choosing a template

Unity presents you with a few template choices when you press the New button on the projects tab. This gives you the options of 2D, 3D, Universal Rendering Pipeline (URP), and High-Definition Rendering Pipeline (HDRP). There are large rendering differences as well as some functionality that might be interesting to you and your team to work with. These differences between these templates, arose when the Scriptable Rendering Pipeline (SRP) came to life!

Scriptable rendering pipeline

Rendering and computer graphics are a detailed subject that you could get a PhD in, so we will scratch the surface of what is possible through a rendering pipeline. The top level of the pipeline entails three tasks: Culling, Rendering, and Post-Processing. In each of these categories, many tasks are taking place in certain orders and to certain degrees of accuracy. The primary function of all of this is to optimize the view to the end user for a high frame rate as well as maintain the art style that is required for the experience you are wanting for the user.

With the advent of the SRP, these templates split into three main categories: Built-in, Universal, and High Definition. To get an idea of these three templates, let’s break them out into their respective groups and dive in a little bit further. For our project, we will be using Universal Rendering as we will be utilizing several features inside this rendering pipeline.

Built-In Rendering

This is an older pipeline that doesn’t use scriptable pipelines. There are a great many applications for the built-in renderer. Both of the 2D and 3D templates run Built-In Rendering systems. This is also the standard for which most of the assets in the asset store were built before the SRP came out. You can think of “Built-in” as the base experience in Unity. There are several reasons why you may not want to use the Built-In Renderer. If you are looking to use volumetric lighting, GPU particles, or ray tracing you would want to look into the scriptable render pipelines below.

Universal Rendering

The Universal Rendering pipeline is aptly named as it has the most features available with a scriptable rendering pipeline available. If you are looking to make a 2D game, this is the best option to choose as it has built-in, pixel-perfect rendering, 2D lights, and 2D shadows. For the 3D option, this is also a fantastic choice. There are two graphs available to both URP and HDRP, which are ShaderGraph and VFXGraph. ShaderGraph is a visual shader creation tool that allows for complex shaders to be written visually. VFXGraph’s primary function is to be a particle system focused on GPU particles, allowing you to create millions of particles on screen at the same time for stunning visuals.

We would like to use GPU-based particles, in our project which VFXGraph is responsible for handling, as well as show the use of ShaderGraph. With these requirements, we chose to work within URP as our rendering pipeline.

If you are looking for more of a physically accurate rendering system with ray tracing and volumetric clouds, then HDRP is what you are looking for.

High-Definition Rendering

This rendering pipeline has one major purpose: to give the best-looking output while remaining as optimized as possible. Whether to use HDRP or not is a widely discussed topic. There are several main reasons why HDRP would be the option for you. This is if you are looking for a physical-based sky with cloud layers, volumetric clouds, multiple directional lights, highly customizable shadow options, and ray tracing to include raytraced reflections, volumetrics, and multiple high-level shader outputs. There are many other high-level rendering options that HDRP only can provide. These concepts are deep topics in the computer graphics world and we implore you to look them up to see the beautiful work of what real-time rendering is becoming.

Now that you have a project, you can start putting together the assets that will create the game. In this book, we have worked through how we are going to build this game out so that way, we can section off each major chunk into chapters. Prototyping can happen in a multitude of ways. We can’t go over every way in which every studio will prototype as each business has its own manner of creation. We will talk about major progression patterns that are common within the industry as a whole. Breaking down the life cycle of any task that is built upon iteration, there needs to be a cycle to pull out the impurities. This is commonly regarded as analyze, design, implement, and test, and then iterate again until complete. The prototyping phase goes through all of these steps as well. Take a look at them all and work through each portion that makes sense to you or the group building your game.

Wireframing or paper creation

In this form of prototyping, the creator breaks the video game down into phases in a physical or digital system to go through each game loop or experience the player will feel throughout your game. Sometimes, this could be creating a paper board game to run through the rules. Sometimes, this may involve digitally drawing game wireframes through the user interface to intuition for the gameplay experience.

Grayboxing

This name is what you think it means! A bunch of untextured shapes, generally gray boxes, that line out your environment to ensure that the storytelling of the environment through its silhouette can be defined. This version of prototyping is particularly useful if you need a very direct camera angle you need to display, and do not have assets to set up the environment. This can also be useful in the development of concept art as you can push the composition to the concept artists for quicker turnarounds.

Figure 2.5 a, b: Greyboxing examples in project

From Figure 2.5 above, you can see how a concept artist could take these and draw over them to get a rendered concept in order to provide more design ideas for the space, even if this means changing the environment, since this was a quick mock-up of the space to get things started.

These can provide enough detail to start working on a proof of concept, which we go over next.

Proof of Concept (PoC)

The naming is fairly accurate. This is where you are getting very specific about your testing. Maybe you need to tune a camera to get a very specific feel for the gameplay. This might take several iterations in itself and multiple people taking a crack at it if you have a team.

Figure 2.6 a, b: An example of iterating on a game asset

Figures 2.6 a and b above show the iteration of some architecture. We started with a simple archway that had a feeling of fantasy just to start. After we put it in the level, we had more time to think about the styling and add more appealing parts to the archway. This is a helpful concept to understand that your assets can be perfect in the beginning. To get to an MVP, you have to start somewhere and work toward greatness!

Minimum Viable Product (MVP)

This is as the name implies: a pared-down version of the game. In a platformer, there must be jumping. Perhaps you have swinging as your game demands that as a mechanic, this will not get cut no matter how much funding you have? You do not need polished art assets or even animations. The purpose of an MVP is to demonstrate the gameplay’s features are within an acceptable range to ensure that anything built on top has the foundation of the MVP’s mechanics working properly.

Vertical slice

Sometimes you have a good idea of the art direction, the primary mechanics, and narrative, but need to gather some feedback or possibly funding. A vertical slice is when you take a very thin slice of the game and polish it to generate hype and a sense of the end product. Demos are a similar concept to a vertical slice. This is more complex than the MVP as there is a level of polish to the art, animations, mechanics, lighting, and so on that MVPs aren’t expected to have, which can take a significant amount of time as well as an understanding of the final product, which may not have been available when the MVP was made.

This style of prototyping is the best use case for our project needs within this book. We are developing a small portion of the game to get a strong understanding of what the entire game could be. This is our best option.

While making prototypes, your game may need to go through all of these to get to proper gameplay that feels good to play. You may also not need all of them. This varies greatly within each development group.

Within this chapter, we went over some deep topics—game design, what options to choose for your first project, and prototyping fundamentals. We went over how you and your team could collaborate in a Word document or a more visual flowchart to bring your game together. The idea here is to make the design’s ideas a reality. Once you’ve done this, you should dig into your first Unity project, choosing which template to work with and utilizing effects that follow the setting of your game concept, such as GPU particles. Finally, we covered prototyping to get your project started and get a sense of whether it conveys the experience to the user that you want it to convey.

In the next chapter, we will begin to look at programming, helping you to bring all your game ideas to life.