Chapter 21: Finishing Touches

Here we are! We now have a fully developed game, so can we get some money now? Sadly not. A successful game relies on heavy refinement; the devil is in the details! Also, don't get too hyped about earning money yet; this is your first game and there are a lot of non-development-related tasks to accomplish. It's time to discuss what can we do now with what we have achieved so far.

In this chapter, we will examine the following concepts:

• Iterating your game
• Releasing your game

Iterating your game

We are about to finish our first game iteration. We had an idea, we implemented it, and now it's time to test it. After this test, we will get feedback on the things that can be improved, so we will formulate ideas to improve them, implement them, test them, and repeat. That is iteration.

In this section, we will examine the following iteration concepts:

• Testing and feedback
• Solving feedback

Let's start by discussing how to properly test the game on people.

Testing and feedback

Apart from a strong marketing strategy, the success of your game relies on the first 10 minutes of gameplay. If you can't get the attention of the player in that time, you will certainly lose them. The first impression of your game is important. Those first 10 minutes must be flawless and sadly, our perception of the game is not relevant here. You spent several hours playing it and you know every inch of the levels and how to properly control your character, as well as all the mechanics and dynamics of your game—it is YOUR game. You love it as it is. It's a big accomplishment. Now, someone who has never played the game won't feel the same way. That's why testing is so important.

The first time you make someone play your game, you will be shocked—believe me, I've been there. You will notice that the player probably won't understand the game. They won't understand how to control the player or how to win the game and will be stuck in parts of the level that you never imagined to be difficult. There will be bugs everywhere and it will be a total mess—and that is great! That is the exact purpose of testing your game, to get valuable information or feedback. This feedback is what will make your game better if you tackle it properly.

In a testing session, there are two main sources of feedback—observation and user feedback. Observation is the act of silently looking at the person who is playing the game and seeing how they play it—which keys do they first press, what is their reaction when something happens, when do they start getting frustrated in an unexpected way (some games rely on frustration, such as Dark Souls), and generally checking that the player is getting the exact experience you expected.

The silent part of the observation is crucial. You must not talk to the player, especially not give them any hints nor help, at least not unless they are completely lost and the testing session can't progress without help—a situation that is also a form of useful feedback in itself. You must observe the player in their natural state in the same situation that they will be playing your game in their house. If not, the feedback gathered will be biased and won't be useful. When testing big games, they even carry out tests in Gesell chambers. These are rooms with a pane of glass that can be seen from one side only—like an interrogation room but less scary. This way, the player won't feel any kind of pressure about being observed:

Figure 21.1 – Gesell chamber

The second source is direct feedback, which is basically asking the tester about their impressions of the game after the session. Here, you can first let the tester tell you their experience and provide any feedback that they have, if any, and then you can start asking questions related to that feedback or other questions relating to the test. This could include questions such as how did you find the controls? Which part of the game did you find most frustrating? Which part was the most rewarding? Would you pay for this game?

Something important to consider when taking feedback from the tester is who they are. Are they a friend, a relative, or a total stranger? When testing with people close to you, it's probable that the feedback won't be useful. They will try to water down the poor parts of the game as they might think that you asked them to play the game to receive compliments, but that cannot be farther from the truth. You want real, harsh, objective feedback—that's the only way you can really improve your game.

So, unless your friends are really honest with you, try to test your game on unknown people. This could be other students in your educational institution, or at your workplace, or random people in the street. Try to go to game conventions with spaces to showcase indie games. Also, consider your target audience when testing. If your game is a casual mobile game, you shouldn't be taking it to a Doom meet-up as you will mostly receive unrelated feedback. Know your audience and look for them. Also, consider that you will probably need to test your game on at least 10 people. You will notice that maybe one person didn't like the game and the other 9 did. As in statistics, your sample must be big enough to be considered valid.

Also, even though we said that our perception doesn't count, if you apply common sense and be honest with yourself, you can get feedback from your own playtesting. But now that we have gathered feedback, what we can do with it?

Interpreting feedback

You got what you wanted—lots of information about your game. What do you do now? Well, that depends on the feedback. You have different types and different ways to solve it. The easiest feedback to tackle is errors—for example, the door didn't open when I put in the key, the enemy won't die no matter how many bullets I shot at it, and so on. To solve these, you must carry out what the player did step by step so that you can reproduce the issue. Once you reproduce it, debug your game to see the error—maybe it's caused by a null check or a misconfiguration in the scene.

Try to gather as much detail about the situation as possible, such as when the issue occurred and at what level, which gear the player had, the number of lives the player had left, or if the player was in the air or crouched down—any data that allows you to get to the exact same situation. Some bugs can be tricky and can sometimes happen in the strangest situations. You might think that strange bugs that happen 1% of the time can be ignored, but remember that if your game is successful, it will be played by hundreds, maybe thousands, of players—that 1% can really affect your player base.

Then, you have to balance the feedback. You could get feedback such as there weren't enough bullets, I had too many lives, the enemies are tough, the game is too easy, or the game is too hard. This must be considered alongside your objectives. Did you really want the player to be short on bullets or lives? Did you want the enemies to be hard to defeat? In this scenario, things that the player found difficult might be the exact experience you desired, and here is where you need to remember the target audience. Maybe the user that gave you that feedback is not who you expect to play the game (again, think of the example of Dark Souls, a game that is not for everyone). But if the player is the target audience, you might need to balance.

Balancing is when you need to tweak the game numbers, the amount of bullets, the amount of waves, the enemies, the enemies' lives, the enemies' bullets, and so on. That's why we exposed lots of properties of our scripts—so that they can be easily changed. This can be an extensive process. Getting all those numbers to work together is difficult. If you increase a property too much, another one might need to be reduced. Your game is basically a big spreadsheet of calculations. Actually, most game designers master the use of spreadsheets to do exactly this—balance the game, make calculations, and see how changing one cell changes the other—and before testing it the hard way, play the game.

In the following screenshot, you can see how we prepared our Player object to be easily configured in the Editor:

Figure 21.2 – Some of the properties that affect gameplay

You can also get some feedback such as "I don't understand why the player does what it does," "I don't understand the motives of the villains," and so on. This can be easy to underestimate, but remember that your game mechanics, aesthetics, and story (if any) must be in sync. If one of those elements fails, there is the risk of the rest of them also failing. If you have a futuristic history setting but your main weapon is a metal sword, you need to justify its existence somehow, perhaps with a story point. If your enemy wants to destroy the world but appears to be a kind person, you need to justify that somehow. These details are what make the game believable.

Finally, you have perception feedback, such as "the game didn't entertain me" or "I didn't enjoy the game." That feedback can be converted into the other feedback if you ask the right questions, but sometimes, the tester doesn't know what the problem is; the game can just feel wrong in their eyes. This, of course, is not useful by itself, but don't underestimate it. It might be a hint that you need to do further testing.

In game development, when you think you are finished with the game, you will discover that you have just started to develop it. Testing will make you realize that the game is not finished until the players are happy with the game, and that can take even more time than preparing the first version, so prepare for having to iterate the game a lot.

Big games, where the first prototype could take years, carry out testing in the early stages of their game, sometimes with fake assets to hide sensitive information that can spoil the game or make the competitors aware of their plans. Some developers even release a mini-game based on the main game, with a different story and aesthetics, just to test an idea. Also, there is the soft launch, where the game is released but to a restricted audience—maybe to a specific country that will not be your main audience and source of income—to test and iterate the game before releasing it to the rest of the world.

So, have patience. Testing is where the real development of the game starts, but after all those extensive testing sessions have ended and the game is finished, what is the next step? Release!

Releasing your game

We are here— the big moment! We have the gold build, which is the final version of the game. Do we just throw it at our target store (such as Steam, the Google Play Store, the Apple App Store, and so on)? Well…no—actually, we still have lots of work to do, work that we should have started before getting to the gold build. So, let's explore what that extra work is and in which phase it should be carried out.

In this section, we will examine the following release phases:

• Pre-release
• Release
• Post-release

Let's start by discussing the pre-release phase.

Pre-release

One thing to do before pre-release, and ideally before you start developing your game, is to decide where you are going to sell your game. Nowadays, that means choosing a digital store—selling physical copies of games is not an option for newly starting independent developers. You have several options, but for PCs, the most common place for this is Steam, a well-known platform that allows you to upload your game to the platform for the price of 100 USD. After it is reviewed, it can then be published. On iOS, the only way is using the App Store, which charges 100 USD per year for you to publish on it. Finally, on Android, you have the Play store, which allows you to publish on it for a one-off payment of 25 USD. Consoles have harder requisites, so we are not going to mention them.

After picking a digital store, if you just release your game without any preparation, your game can be easily lost in the sea of releases that happen on the same day. Nowadays, the competition is strong, and dozens of games might be released on the same day as yours, so you must highlight your game somehow. There are lots of ways of doing this, but it requires experience in digital marketing, which can be difficult. It requires skills other than regular developer ones. If you insist on doing it by yourself without hiring someone, here are some things you can do.

First, you can create a game community, such as a blog or group, where you can post information about your game regularly. This includes updates on its development, screenshots of new features, new concept art, and so on. Your job here is to capture the interest of players and keep them interested in your game even if it's not released yet, just to prepare them to buy your game as soon as it's released. Here, you need to be creative to keep their interest in the game—vary the content you post, maybe share some mini-games with your community with the opportunity to win prizes, or post questionnaires or giveaways; really, do anything that captures the attention of your audience.

Also, try to develop a community when you are not too near but not too far from the release date. That way, you won't lose the attention of the players due to long wait times and you can be honest with the expectations of your game. They will change a lot during the development and the scope is likely to be reduced from its initial design. You will need to deal with the hype, which can be dangerous.

Of course, we need people to join the community, so you must publish it somewhere. You can pay for ads, but aside from the cost and difficulty to make them relevant, there are other free ways of doing this. You might send a free copy of your game to an influencer, such as a YouTuber or an Instagrammer, so that they can play your game and give a review to their audience. This can be difficult if the influencer doesn't like the game as they will be honest, and that can be bad for you. So, you really need to be sure to give them a polished version, but not necessarily a final version. There are also paid influencers that you can approach, but again, that requires money.

You have other free options, such as going onto forums or groups and posting information about your game, but be sensible here. Don't make your post feel like cheap advertising—know where you are publishing. Some groups don't like those kinds of posts and will reject them. Try to look for places that allow that kind of self-advertising. There are groups intended just for that, so just avoid being invasive in certain communities.

Finally, another option you have is to contact a publisher, a company that specializes in doing this kind of marketing. They will allocate money for publishing and will have people that work to manage your communities, which can be a big relief. You have more time to create your game, but it also has some drawbacks. First, of course, they will get a cut of your game revenue, and depending on the publisher, this can be really high. However, you need to contrast that with the revenue you will get by doing your own marketing. Also, publishers will ask you to change your game to meet their criteria. Some ask for your game to be localized (supporting several languages) or ask for your game to support certain controllers, to have a certain way to do tutorials, and so on. Finally, consider that certain publishers are associated with certain types of games, so if you are creating an intense action game, you wouldn't publish it with a casual-games publisher. Find the right publisher for you:

Figure 21.3 – Some well-known publishers, some of which don't develop their own games, just publish them

Now that we have the foundations prepared for release, how do we release the game?

Release

Aside from all the setup and integrations your game might need to have to the selected digital store platform (which again depends on your audience), there are some things to consider when releasing it.

Some stores might have a review process, which consists of playing your game and seeing whether it meets the criteria of the store. As an example, at the time of writing this book, the Apple App Store requires every game they publish to have some kind of social sign-in option (such as Facebook, Google, and so on) and to also support Apple sign-in. They will simply not admit your game if you do not comply. Another example is PS Vita, which asks your game to support some kind of interaction with its front or rear touchpads. So, be aware early on about these requirements. They can affect the release of your game a lot if you don't take care of it.

Aside from these requirements, of course, there are other criteria to be met, such as whether there is adult or violent content. Consider a platform that supports the kind of game you have created. Some can even ask you to get ratings from the Entertainment Software Rating Board (ESRB) or similar rating boards. Another common requirement that you need to be aware of is that the game should not crash, at least not in the usual workflow of the game. Also, the game must perform well, can't have intense performance issues, and sometimes, your initial game download size can't exceed a specified maximum limit, which you can usually solve by downloading the content in the game itself (look for the Addressables Unity package for this). Again, all of these requirements vary depending on the store.

Now, even if these requirements are met, the process to check them can take time—days, weeks, or sometimes even months. So, keep this in mind when defining a release date. In big consoles where this process can take months, sometimes the developers use that time to create the famous day-1 patch, a patch that fixes bugs that won't stop the game from being released but help with the overall game experience. It's a questionable but understandable practice.

Finally, remember that the first day of the release is critical. You will be in the New Releases section of the store, and here is where you will have the most exposure. After that, all exposure will mostly rely on your marketing and sales. Some stores allow you to be featured. You can talk directly with representatives of the store and see how you can do this. If the store is interested in your game, they might feature you (or you might have to pay for that). The first day is important, so be prepared for that.

Now, the game is out and in the hands of the people. Have we finished our work? A few years ago, that might have been true, but not today. We still have the post-release work to do.

Post-release

Even if the game is released, this is not an excuse to stop testing it. You can actually get even more feedback if your game is played by thousands of people. Sadly, you can't be there to observe them, but you can automate the information-gathering process. You can do this by making your code report analytics to a server, as the Unity Analytics package does. Even if this information is not as direct as in-person testing, a massive amount of data and statistics can be gathered this way, and you can improve the game on the fly thanks to updates, something that old games couldn't do as easily as they can today. No game is released perfect, and sometimes, due to time pressures, you might need to roll out an early release, so prepare your game to be updated regularly after release. There are some cases of games that had a bad launch but were resurrected from the grave. Don't underestimate that last course of action. You have already spent too much to give up on your badly released game.

Also, if your monetization model relies on in-app purchases, which means people spend money on loot boxes or cosmetic items, you will need to have constant content updates. This will keep the players playing your game. The more they play the game, the more money will be spent on it. You might take advantage of the information you gather through analytics not only to fix your game but also to decide which content is being consumed most by your players and focus on that. You can also carry out A/B testing, which consists of releasing two versions of the update to different users and seeing which one is the most successful. This allows you to test ideas on a live game. As you can see, there is still plenty of work to do. Also, use metrics to track whether players are losing interest in your game, and if so, why—is there a difficult level? Is the game too easy? Pay attention to your player base. Ask them questions in the communities you created, or just look at the reviews—users are usually willing to tell you how they would like their favorite game to be improved.

Summary

Developing the game is just one part of the work; releasing it to be successful can be a huge task. Sometimes, it can cost more than the game itself. So, unless you are making a game for fun, if you want to make your game for a living, you will need to learn how to manage releases or hire people that are capable of helping with the pre-release, release, and post-release phases of your game, which can be a smart move.

Of course, this chapter just provides a simple introduction to this big topic, so I would recommend that you read some extra material if you want to take this part of game development seriously. A very well-explained and bite-sized source of information on this topic is the Extra Credits YouTube channel, which provides short videos to convey valuable information. Also, there is a great book called The Art of Game Design: A Book of Lenses, which provides a thorough introduction to game design.

Congratulations, you have finished part 3 of this book! You have gained the basic knowledge to start your game development career and choose some of the several roles you can do in it. I recommend you put what you've learned into practice before reading more books on this topic. Gaining information is important, but the only way to convert that information into knowledge is through experimentation. Just be sure to balance theory and practice.

In the next part of this book, we are going to explore some extra topics that might be of interest to you, starting with an introduction to extended reality applications.