So I have ads working in my game. But where do I put them? You might think this a simple thing. Until you yourself actually start designing something that needs ads and have to find the space and time for them. So lets go through the three types of ads and discuss where I might put them.

Firstly we have the most simple of the ad types: Banner Ads. They are very simple, a bar at the bottom of the screen displaying an ad. Somewhat like a billboard on the side of the road, but in a game. The simplicity of this ad spills over into the simplicity of where I will use it. Banner ads will appear in the game modes, but not on the main menu. Putting them on the main menu feels tacky somehow, but just passively having them sit at the bottom of the screen during play feels fine. Next up is an ad type that took some thought.

The next type of ads are called interstitial ads. These ads are full screen video style ads that can be skipped, usually after X seconds, much like ads you see at the start of YouTube videos. These are a bit harder to figure out as they need a real trigger to play, and I don’t really want them getting in the way of the play. What I settled on is having them play when you go from a game mode back to the main menu. That way they don’t interrupt play (as the player was interrupting play to change things up anyway), don’t pop up an annoying amount of the time, and can still be skipped. And now for the annoying one.

The final ad type is rewarded ads. These ads are very much like interstitial ads with two big differences. Firstly, these ads can’t be skipped, they play to completion every time. Second is that, as the name suggests, after the ad plays the player is supposed to be rewarded with something. But the big question for me was always: what could I possibly reward them with?

For a while I just thought I wouldn’t use them. Not like they are required right? But then I figured out something I could “reward” the player with: the hint system. I haven’t figured out the specifics yet, but a way it may work is that you start a session and want to unlock hints. So you watch the ad and get hints unlocked. The real questions are: Does this unlock ads for all modes this session? Does it unlock X hints? Hints for X levels? I still need to figure this all out… and then program it.

What should a game designer study?
Yes.
But what experiences are beneficially to my game design?
All of them.

This was one of the more memorable conversations that took place in my game design class. Student was asking what supplemental courses to take (art, programming, animation, history, etc.). The teacher’s response could be boiled down to this: There are no experiences that can’t be useful to a game designer. So, what does that mean?

There are two main aspects to this, experiences and skills. I will start with experiences. Any experience can be used to influence game design. Perhaps a scene from a movie you watched gave you an idea for that nagging mechanic you are trying to figure out. Maybe your experience extending your running range influences how you design level up mechanics. Or you could even design an entire game to get across the sense of peace you experienced when sitting on a hill on a sunny day and got a whiff of some flowers. A designer, of almost any kind, draws on their life experiences to inform their design. So the more experiences you have, the more paints you have in your design paint kit. But where do you get the brushes to apply that paint?

That is where the skills you pick up come in. The broader your skill set the more of a game you can influence. For a very simple example a programmer with some basic art skills can make temp assets without going to an artist every time. Similarly a UI designer with some programming experience can figure out what the programming flow might look like while they are making the design. In short if you can expect what the next step in design is the better you can prepare for it and possibly save everyone’s time. Or even (as I am doing) create something completely by yourself.

What I have heard this skill distribution referred to is a T skill distribution. Meaning you have a basic understanding of everything in the pipeline, maybe even enough skill to help out on occasion. BUT that you have one or two specialties. The broad “base” of the T vs its tall central pillar. In this way, no skill you learn is wasted in the design space. Even seemingly unrelated skills can surprise you when they come up and are invaluable.

Often times, when I design something that works I have a tendency of just using that over and over again. One example of this is to copy and paste parts of working code into new code. Usually I need to change something, but it makes for an excellent starting point. But this also applies to UI design. When I find a design that works I have a tendency to try and copy paste it everywhere else. I usually have to tweak it a bit for things like space constraints, but this has the upside of a unified design.

However… as you may have surmised from the title, there is a downside to this. And that is when the old design just won’t work for what I want. Now you would think the answer is simple “Just do something different” and yes it should be that easy. But then comes the “rigidity”. You see, I like the idea of the design being “unified”, of everything looking and acting similarly. So the idea of changing a design that has worked up to this point is a hard one to accept. And I struggled with first one idea that just would not work, then another that was somehow worse. But eventually I got it through my head to “just change the layout of the design”. This gave me the room I needed and actually helped differentiate a specific part of the design so that it wasn’t confusing.

So I guess what I have to say is this: Don’t get stuck in one way of doing things. Even if it works it isn’t always the best choice.

Something I have been putting off for a while was a settings menu. I kept putting it off because “How hard can it be?” I figured it would be easy to slap together. And I was half right. The buttons and mechanics of the menu are/will be fairly easy to make. But… the ever looming questions of how to design the thing and what to include are a bit harder to answer.

Lets start with one of the simple ones: Volume Controls. Once I actually started thinking about it I was struck by a seemingly obvious question. The primary target platform for this game is mobile devices, and people tend to just use a phone’s inbuilt volume control when playing games. So… Do I really need a volume control? Or would a simple mute/unmute toggle suffice? Another question: Do I have enough distinct sound effects to warrant individual volume controls? And all these questions for one of the simpler parts of the settings menu.

One of the other problems I am having with the settings menu is another simple question: Where should you be able to access it? Seems simple and straightforward right? Que hysterical laughter of a man losing his mind. At first I was just going to put it on the main menu and be done with it. But some of these options feel like they should be accessible from the play experience (mostly the volume setting). The problem with that is this: The play scenes are already using 80-90% of the relevant screen real-estate and the remaining parts are so desperate that is might as well be 100% use already.

So where would I even put the settings? The two options I can think of are to have the play area temporarily vacate the screen to make room. And alternatively for the settings to just sit on top of everything else with a semi-transparent backdrop to make the settings stand out from the play area. And I don’t really like either option. So that brings up the question: Do I really need the settings to be accessible from the play scenes?

There is an old piece of advice I remember for writing. It goes something like this: If you aren’t ready to name a character don’t give them an actual name as a placeholder. The reason for this is that if the placeholder stands for long enough you will just attach that name to that character and never rename them, or have great difficulty doing so. You can imagine the clash that can arise in a high fantasy story with Grognar, Lethewin… and Steve. I purposely over exaggerated that example to make a point, but the point stands. But what does this have to do with game design? Everything.

But not directly. It doesn’t really matter what you name things as long as the design team knows what is going on. However, What names you put on buttons, what names you give to play modes, what text you put in descriptions, that all maters. And unless you are careful your subconscious may latch onto the “temporary” element and not want to revise it. For instance, when I put a temporary title on my game’s main menu I also put “Name WIP”. Turns out I used the placeholder name anyway… and don’t regret it, it led me to a theme I like.

But with all that said, my main point is that this can also apply to other elements. More than once I have jury rigged a solution to a programming problem and been reluctant to replace that solution with a more elegant one. Similarly, design elements can be hard to replace because of how long they have stood or how long it took to make them. (That second part is called the “Sunk cost fallacy” and deserves a deep dive of its own.)

The primary solution to this problem is to be aware of it and account for it in your thought process. If you need a temp name use something nonsensical or something like “title goes here”. If you are putting in a temporary element, first ask yourself “Do I really need this now? Or could it wait?” When jury rigging a solution perhaps take the time to just learn to do it right the first time. (deadlines might make this one tricky.) Just remember that “temporary” solutions have a tendency of becoming permeant if left alone too long.