Sometimes in design you can’t just jump in and see what works. And for me, that is a bit hard. When people are standing around deciding the “best” way to do something, arguing the merits without seeing the result, I will often just go and do the thing. That way we have something tangible to compare, change, and discuss rather than abstracts. So finding something where that approach is… counterproductive, is a bit like hitting my head on a low beam: startling, annoying, and gets my attention.

So if I can’t just jump in and mess with things, what do I need to do instead? Simply put: I need to make a “prototype”. By which I mean, I need to make a rough draft of what I want the final product to look like. And that leads to three possible ways of doing it.

First is the option I use most often, make a mock up in program. For my game projects that would mean either making a new scene or rearranging an existing scene in Unity. The big advantage is that this is like putting paint on canvas, if it works no further work is needed. The two big downsides are that it can take a lot of time and suffers a lot from “good enough” syndrome, where you have it in place so it is “good enough”.

Next up is to make a mock up outside of the development software. My first instinct would be to make a Power Point “presentation”. This would mostly be an artistic representation of the final product, sometimes with screenshots of the game itself. Upsides are that it is fairly easy to edit a “completed” idea and doing repetitive images is as simple as copy/paste. Downsides are that, again, it can take a while to get things in the positions you want them. And once you have invested that much effort you might say “good enough”.

Finally is the solution I was resistant to trying, but now embrace: paper prototyping. Simply put it is drawing out the ideas on paper. Even if it is just prototyping a part of the UI design, it is so much faster and cheaper to test things in paper. That is the primary advantage of paper prototyping: the speed of being able to try things. So long as you can put aside the idea of needing the prototype to “look good” and simply accept it as “functional” it works wonders. But on the downside, if you need to wow someone with the looks… this isn’t going to do it. But that isn’t the point anyway. The point of paper prototyping is to get lots of ideas out rapidly. Then you can see what works and what doesn’t.

To loop everything back to the start, and my method of “just try it and see if it works”. I think I have come around on the idea of paper prototyping actually fitting that idea. It isn’t just debating ideas, but seeing how they could work. And doing it much faster than most other methods.

So I got some feedback from my playtest build. Several bits of feedback where simple bug fixes or graphical mistakes that were easily fixed. But there was one big bit of feedback I didn’t expect: people didn’t know what to do with the game.

Now I had kind of seen this coming. Several times I started making a tutorial level, only to abandon it as the design left the tutorial behind. I figured if I needed it I would get back to it when I was sure of the rest of the design. Well… turns out I need something.

So a simple plan formed: basically make a slideshow explaining the mechanics of the game. Each game mode would have its own collection of images to describe how that mode functioned, and the player could advance through them at their own pace whenever they want. No forced tutorial or “Now you do the thing” hand holding. Know what your doing? Get straight to the puzzles. Want to figure it out yourself? Go for it. Need a hand figuring out the new mechanics? I got you covered. Completely lost? Simple explanation just a click/tap away.

When I was first making my tutorials I was doing “all the things”. Slowly introducing concepts and elements so as to not overwhelm. Showing patterns in the puzzle without going “Here: see this!” But in all that I forgot one of the first design principles I was ever taught: K.I.S.S. Keep It Simple Stupid. And that is what the new design is: simple and too the point.

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.