Different people have different approaches in designing a game. Some designers like to start with the characters' design or storyline, and only after that, they will decide what type of gameplay is suitable for it. On the other hand, some designers like to start with the gameplay instead. There is no absolute rule on how to start designing a game; it's entirely dependent on what inspires you in the first place: Did a good story suddenly pop up in your mind? Were you inspired by a game you loved to play during childhood? Or were you inspired through silly conversations with your best friends? Write down your initial ideas; who knows, it could become the next popular game one day.

For me, I like to start by choosing the game genre and designing the gameplay right before anything else. I find that it's quite important to design a gameplay early on so that it can be tested repeatedly and to check whether the gameplay is fun or not. Otherwise, all the time we spent on writing a good storyline might be wasted if only to find out the gameplay simply doesn't work the way we had imagined. You can try to experiment on different approaches and see which method suits you more.

One mistake made by most of the newbie game developers is neglecting the importance of a game design document (GDD). A GDD is usually a collaborative effort within a development team to organize ideas and help convey the designer's vision to the rest of the team. It also helps to make sure that everyone is working together at the same page, avoiding assumptions, and conflicting workflows.

Besides this, GDD is also very helpful for solo developers. It allows you to see the bigger picture of your game and easily spot any major flaws in the game design. Other than this, you can also look at the list of every aspect of the game and decide what needs to get done based on its priority.

Most of the time, a common office suite, such as Microsoft Office, OpenOffice, or LibreOffice, is sufficient for creating the GDD. If you're in a team, however, it's best to use an editor that has the capability of real-time collaboration between team members. I personally find Google Documents very useful for this purpose, especially during brainstorming sessions where every team member can contribute their ideas and let others to see them during discussion. Try to pick the most suited tool for you and your team.

Picking a game genre early on is also very important. It gives you a sense of direction, and it lays down the foundation for you to further improve and innovate. There are many different types of game genres, such as first person shooter, role-playing, real-time strategy, adventure, action, and puzzle.

Alternatively, you may also invent your own genre if you are the type of person who likes to try out new ideas and always think out of the box. Although this may sound overly ambitious, but this is actually doable, as game genres are being invented all the time. However, following this path requires a ton of prototyping to prove that your idea is workable and fun as you're trying to create something that no one has even seen before.

If you have no idea which genre to pick at the moment, you might want to look at the statistics of the best-selling video game genres, and hopefully it will give you some inspiration:

It's important to decide on the genre early before you start working on the game. Basically, switching game genres during development means starting all over again from scratch.

Gameplay is something that connects players' actions with the purpose of the game and its main challenges. Gameplay will define what the player can or cannot do in the game, as well as conditions that allow the player to progress through the game. Gameplay design involves a wide range of designing aspects, such as a level design, gameplay balancing, player behavior prediction, and choices planning. All of this can be incorporated into something called game mechanics.

Game mechanics are constructs of rules that make up the gameplay of a game. It determines what actions the player can take, how the actions interact with the game states, and how other game entities respond to the player's actions. Gameplay defines what a game is to the player, whereas game mechanics are the parts that define the gameplay itself. In other words, gameplay is nothing more than a set of game mechanics. Oftentimes, gamers are popularizing famous games for its game mechanics. For example, Gears of War was famous for its cover mechanic when it first released in 2006. Prince of Persia blew peoples' minds away when first showing two of its famous mechanics—the parkour mechanic as well as the time manipulation mechanic. Angry Birds would not have been downloaded by two billion times across the globe if it didn't feature the slingshot mechanic!

We can split a set of game mechanics into two main categories: core mechanics and sub-mechanics. Core mechanics are the most important mechanics in your game. You cannot simply change your game's core mechanics because it will break the nature and essence of your game. For example, take away the shooting mechanic from Counter Strike, and the game would simply become something else, but something other than Counter Strike. It will not make any sense at all to play Counter Strike without a shooting mechanic. Sub-mechanics, however, can be taken away without breaking the game. Again, we use Counter Strike as an example, but this time, we will take away just the jumping mechanic. Now the players can no longer jump, but that doesn't make Counter Strike a different game; it's still a first person shooter, you can still make the headshots. It's important to determine what are the core mechanics of your game early on, but not so important for sub-mechanics. You can add in sub-mechanics later on during the production stage because, as previously mentioned, it won't break the game. A strong and solid core mechanics will ensure the success of your game, so focus on it first before anything else. After this, you can try to experiment on different sub-mechanics to enhance the gaming experience.

In short, proper planning will ensure that the gameplay is balanced, unpredictable, and makes sense to the player. Even an experienced game designer can hardly design a perfect gameplay in one shot. It takes a ton of testing and iterations in order to get the gameplay to feel right and fun to play with. The formula is simple: test, test, and more tests!

A level is the venue where a player interacts with the gameplay elements. It can also be called as a map or stage. As a level designer, you're responsible for designing the layout of the levels to comply with the purposes of your gameplay: Does this level carry missions? Is this level for multiplayer purposes? Roughly how long do you expect the user to play this level? You need to ask yourself all sorts of questions before you start designing your level.

One important aspect of level design is flow control. Game level with good flow control can direct a player toward the goal of the level and prevent idling or moments of unintentional confusion from occurring in game. You need to be clear about the intent and purpose of the particular level and then by using the elements within the level, such as lighting, props, and items. You can subconsciously lead the player toward the goal. You will learn more about this later when we design the environment.

Let's have a look at the sample level I designed for this book. Players must search for the key in order to open the gate and fight the final boss. While exploring the environment, player will occasionally encounter monsters and involve in intensive battles. There are also some items aligned randomly across the path for the player to pick up, restore health, and help progress the game. Here's an image showing a simple level with simple gameplay in mind to demonstrate what a map layout looks like:

Rapid prototyping is a good way to quickly test out your game idea and see if it works the way you want. Sometimes, a game idea might sound good only on paper, but it just doesn't work out like how you'd imagine it to be. The last thing you want is to only realize that you have been working on a bad idea in the middle of the development phase. Rapid prototyping not only saves you from this situation, but also allows you to think out of the box and freely experiment on all kinds of random ideas. If the idea works, then it is great; if it doesn't work, just scrap it and try the other ideas.

When you rapidly prototype your game, you should stop worrying about the graphics and just focus on the gameplay mechanics alone. The character could be just a cube, a sphere, or anything simple. The level could be just a plane or with more cubes on it acting as obstacles. You also shouldn't worry about the storyline at this stage because you might be scrapping the idea minutes later.

Unity Game Engine, the game development tool that we will be using in this book, is built for rapid prototyping in mind. It's extremely easy to just throw in some primitive shapes, applying some scripts to the shapes, and you are good to go. You can instantly start playtesting your ideas without much effort spent on setting up the game engine. In addition, you can download sample game assets from the Unity Asset Store, including 3D models, animations, and even sample scripts to kick-start your prototyping process.

Besides this, there are also plenty of plugins available at the Unity Asset Store, which provide extra tools for you to rapidly construct a demo level or create game mechanics without the need of writing any code. All-and-all, Unity Game Engine makes rapid prototyping even more rapid with the features mentioned previously. You will only be learning how to use Unity in later chapters.