Dev Update #5 – Releasing a Game is like playing the Lottery

The above statement might be bold, but I am going with it. Let me explain why.

Even with the best production values, you can hit bad luck and your game simply doesn’t perform well. At the same time, a game that plays more like a bug than a game gets featured in every magazine. Just look at the goat simulator. One could argue that it is the novelty factor that makes the difference. And while that is true to some extent, I am sure there are plenty of games with unique and novel gameplay out there that no one has ever heard of. Why are they not equally successful?

An angry man yells that the game "Sliced Bread 2014" is vile, despicable, racist and kills puppies. The text below him reads: "If People Hate Your Game Enough, They Will Do The Marketing For You".

You can get lucky and your game hits a nerve, or caters to a niche that happens to be ‘in’ right now. Maybe a journalist has an empty space to fill in a magazine and your game falls into his hands at the right moment in time. Maybe your game happens to come out when some other unpredictable but thematically matching major news event hits and acts like free marketing for your game. Or someone will randomly feel provoked by your game and start a big controversy about it (again, free marketing).

Neither of these events can be predicted or planned. There simply is a random element in the process that cannot be denied. That doesn’t mean there is nothing you can do about it.

Releasing a Game is like playing the Lottery… but you are allowed to improve your odds!
There is a random element in the process of releasing a game. But how big that random element is, is another matter entirely! You certainly can improve your odds in several ways. Disclaimer: This is not a complete list in any way, this is not an article about marketing strategy.

  1. Be as bug free as possible
    This one is self-explanatory I hope. Nothing wil turn people away from your game faster than bugs. Bigger studios have their own Quality Assurance departments, that do nothing but test a game for bugs all day long.
  2. Have high production values
    This one is more complicated, as it essentially has two levels. In the basic level this means your game should be complete and tested. I don’t mean tested for bugs, but for gameplay. Is your game fun? Does everything make sense? Are all features in? Is the UI easy to use? This type of testing is best done with people that have never played your game before, and this is called “Focus Testing”.
    On the second level high production values means high quality in everything else in your game, most prominently graphics and sound. High Quality doesn’t necessarily always translate to expensive. For example say your game has a sound effect with scratches and compression artifacts playing every time your click a button. It will annoy the heck out of people. Essentially, file off the rough edges if you can, and make your game more polished.
  3. Put some money into marketing
    It’s no secret that marketing is important. I listed it as number 3 on this list, but that is more ideology than truth. In reality, this one might be even more important than the other two. Everybody knows, even if a game is bad, it can still make a fortune with the right marketing. I heard rumors that publishers actually have internal guidelines to tell them when it makes more sense to pump the money into marketing for a mediocre game, rather than use the money on development and trying to make the game better. I have no idea whether there is any truth to that, but from a business standpoint, it would make a lot of sense. It’s the bottom line that counts.

Why does this matter to Game Tower?
These concepts should be applied to my virtual game studio as well. I mentioned in an earlier post that I strongly dislike the idea of the player choosing game genre and type, because it is such a poor way to predict a game’s actual success on the market. Even if it wasn’t, Game Tower is supposed to be about the management aspect of game production, not about designing games. So I needed another way to determine how successful a released game would be.

I chose to copy reality and actually made it a game of chance! Not a lottery, but a slot machine to be exact. At game release, the player will play a one-armed bandit with three categories: Reviews, Bugs and Pirating

A slot machine with three barrels. One for reviews, one for bugs and one for pirated game copies.

Note: This image is just a mockup graphic!

The game is a normal one-armed bandit slot machine. All three drums will roll and the player can hit a button to make them stop individually. Depending on what symbol the drum stopped at, your game will receive a bonus or a penalty. If you manage to get a heart in the review category for example, the reviewers will love your game more than usual and this will boost your game’s sales.

To really stick close to reality, the odds can be improved in my little virtual world as well. The thing about the slot machine is that the player can build floors, such as Focus Testing and Quality Assurance, that change how many hearts or skulls are on each of the drums of the machine. Releasing a game that is unfinished will increase the number of skulls on the Bugs drum. On the other hand, running a game through QA will add another heart on it.

Slot Machine from the game Super Mario Brothers 3. You could win extra lives and powerups by playing.

What I especially like about this solution is the fact that the user will trigger the slot machine himself. Technically, with some skill and good timing, that could improve his odds further. Do you remember this mini game from Mario Bros 3? With the right timing, you could get extra items. Timing is important for a game release too, after all 🙂 (OK, I might be stretching this analogy a bit thin at this point.)

Johnny Depp in a pirate costume explains that he is, in fact, a pirate. If there was ever any doubt.

I am not sure how much pirating would really influence the revenue. A game has to be somewhat successful to be pirated in the first place. DRM methods have proven mostly ineffective, and the question of how many people would actually buy the game if they couldn’t pirate it, will probably never be answered. At this point, it is just a number to factor into the revenue of the game. I needed a third category however and excessive pirating can definitely hurt sales. Instead of DRM the player can increase his chances here by building a Community Management floor. This floor will increase player’s loyalty – and also scout the warez and torrent boards for pirated copies.

Dialog Screen showing the end result of the game release lottery. The results were great reviews and only a few bugs, but the game was pirated too often. The end result gives a bonus of 0% to the sales of the game.

If you paid attention, you’ll have noticed that the three categories for the one-armed bandit are not a direct match to the list I created in the first half of this article. I found that I couldn’t really fit the marketing into a game of chance. Marketing – to the point where one can actually influence it – is rather linear. The more money you spend on it, the more your game will sell.

And even that will be available. Players can build a marketing floor and have it work on a game. This will directly increase the maximum amount of money it can make. But it won’t influence the lottery at game release.

My game design document is done now. Before I finally allow myself to begin with the implementation, I want to do a balancing pass on my game design on paper. Or in a spreadsheet, to be exact. But more on that in my next post.

Dev Update #4 – Creating Really Awful Pictures, aka C.R.A.P. (aka Coder Art)

My kind has long had a reputation for creating so-called ‘Coder Art’. This term describes all kinds of art, from 2D to 3D that has been created by coders themselves, instead of a real artist. And the result is art that can generally be placed within a spectrum ranging from small to high degrees of shittyness. This is just an observation of the average, of course. Some coders are capable of creating truly beautiful art for their games and music right along with it. So there are a few exceptions to this rule…
…unfortunately, I am not one of them.

If you're blind and reading this, imagine a picture drawn by a blind person. That's what this crappy graphic looks like.

Someone told me that looking at this gives them eye cancer.

With the Game Design Document nearly finished I have started adding little mockup graphics to it, showing what I think the UI (User Interface) should look like. A picture says more than a thousands words they say. I don’t know whether it really always says more, but it definitely says it faster. Why describe how an image on the screen should look like, when you can simply show a picture?

The UI is part of the GamePlay
I will not go as far as saying that creating mockup graphics of the UI is important for every type of game. In fact, I don’t remember seeing a single game design document for any of the AAA First Person Shooters I worked on that included any kind of mockup graphics for the UI. And that makes sense. These games had their gameplay tightly focussed within the 3D world (the 3D part is irrelevant, the same can apply to 2D). Instead of the UI there would need to be drawings of the in-game scenes and scenarios. And there were. These are called Concept Arts, and they were usually created by real artists that know what they are doing.

Mobile Game like this one however, are a different matter. In this game, essentially, the entire UI is the gameplay. All you really do is click buttons and scroll through menus and dialogs. So it would make sense to create little previews of it. Obviously these are not the final in-game graphics. A mockup graphic just conveys the general idea, content and layout. They work almost like a concept artwork.
Just much less pretty.A dialog window with a few buttons, labels and images. All important information is there, but it looks like a 3 year old could do a better job.

Personally, I wish I could skip this step. I really have to force myself to do this, because producing any kind of art – even the infamous bad ‘coder art’ my kind is known for – is a painful task for me. But there are two distinct benefits to doing it anyway:

Benefit #1 – Increase the odds in your favour
As painful as the creation process of these graphics may be – once I finally get started with the actual game, I won’t have to worry about layout and graphics, because I have mockups to guide me. This means less unpleasant tasks that interrupt the flow and need doing before being able to continue with the fun stuff (making the game). Every time you have to stop the fun to do something not fun, your game is at risk of being shelved forever. Because we are human and most of us like to procrastinate on things that we don’t like doing. Especially in our free time.

This is one more step that will help me not lose momentum during the game development and increase the odds that the game will actually get finished.

Benefit #2 – Actually design the UI
There is another benefit of going the extra step to create mockup graphics. Instead of making it up on the fly as you go along, you spend some time thinking about what your various dialog boxes, menus and buttons really should show.

For one this means considering how much screen space you really have available. You will notice this as you try arranging your little graphics in Photoshop and run out of space for button #36. And as a result, you will start throwing out or combining information that isn’t really needed. You will automatically streamline and de-clutter your UI without even noticing it.

Secondly, and this is more important than the de-cluttering, you will spend actual time thinking your UI through. There will actually be a design to your UI. Which button would open what menu? Would it be nice to have this in a separate dialog? How many clicks does it take to do XYZ? Hint: The answer to that last one better be low.

You don’t even have to be great at interface design (common sense is a very good place to start). It should be obvious that any UI that had any time and thought at all put into its design will automatically trump a bunch of random buttons that you throw in during the implementation to tie together your individual features.

I mentioned that for this type of game, the UI is part of the gameplay. So just like the rest of the gameplay, it deserves to be taken seriously and you should put some time and effort into designing it.

Example: A Game Tower Department
Here is a practical example of the above. I needed some way to distinguish different departments from one another. Coloring the background walls of the floors is one way, but I knew that wouldn’t be enough. I also want to avoid using text everywhere, which aside from being boring, incidentally also takes up more of my precious screen space. So each department will have it’s own icon, which is used in all the menus. And to streamline the UI, clicking on the icon will bring up the floor’s upgrade menu.

A painting of a room, with a single desk, a computer and a programmer in front of it. The labels next to him show the game that he is currently working on.My Game Design Document is nearly done. I fleshed out a level system for the player, worked out all the different department floors, nailed down the details of the upgrade system, the build system, the menu structure and even made a list with some ideas for achievements.

Can’t wait until that day I get to open up Unity and finally get going.

Dev Update #3 – Creating a Rewarding Upgrade System through visibility

To me the upgrade system in Tiny Tower never felt like an important part of the game. I never directly noticed any immediate effect of an upgraded floor, and worse, I never even knew exactly what I would get with the next upgrade level. So eventually I stopped upgrading my floors altogether. The upgrade system simply isn’t very rewarding. This has to be different in the design of my game. If I upgrade something, I want know what I will get in return. And I want to want it.

A roleplaying woman lovingly caressing her vest which gives her +5 to Dexterity.

My Checklist
There are several things a good upgrade system needs to master. Many of them come down to visibility in one way or another:

1. The player should know what an upgrade will bring him.
Regardless of the game, if the player is asked to spend whatever resource is required to upgrade a building or character or whatever, he needs to know what he will get in return. Without this information, no one can make an informed decision on whether the upgrade is worth the cost. And don’t be vague. Did you ever play a game with an upgrade description that simply read “will increase your attack speed”? Yes? Me too. It sucks. No one likes to buy a cat in a bag, not even with virtual money. So be as precise and as transparent as possible with the upgrades.

2. The upgrade should make a noticeable difference. 
Otherwise, why upgrade in the first place? If a game let’s you increase your character’s stats each level, but you barely notice any difference, then what’s the point? Eventually you will stop upgrading altogether. And that is bad for your game. Those games that rely on a virtual currency and in-app purchases will have lost one opportunity to make it attractive to the player to spend money on the game. And all other games will have lost a part of their game design.
If on the other hand an upgrade gives the player something that helps him get further in the game, or quicker, or both, you have a winner. Give the player something he really wants, and he will want to upgrade further. It’s delayed gratification all over again. If a player needs to save up those resources, upgrade points or ingame currency to be able to finally afford the upgrade, it should feel sweet. Don’t skip out on the gratification part.

3. The upgrade should be visible.
If you did upgrade your character, building, floor or whatever, it should be visually changed as well. Whether you display a number of colored points at the side of an icon or exchange the entire model doesn’t even matter, as long as it is noticeable in one single, quick glance. There are two reasons for this. The first is plain convenience. You don’t want to go into a menu to find out whether your building is level 2 or level 5. The second reason is to create the desire to upgrade more and further. Which will mean play the game longer, or potentially buy more ingame currency.
I mentioned my theory that I believe there is a perfectionist hidden in all of us in an earlier post. If two of your buildings have 5 stars on their side, but the third only shows measly two stars, most of us can’t help it. We want to bring that third building up to level 5 as well. Maybe it is just latent OCD. But if it can create fun gameplay, use it!

4. The upgrade should have a meaningful cost.
When I say ‘cost’ I don’t mean money. I am talking about whatever resource your upgrade system uses. It could be as simple as giving out points to increase character stats at each level up. The important aspect is that you knows what the upgrade is worth. Worth is not the same as cost. In my example, each increase of the ‘strength’ attribute will cost one point, but how much that is worth depends entirely on how many points the player gets when leveling up. If you only get a single point, it will be worth much more than if you had gotten 15. You know you cannot get another point until you manage to level up again. So when designing an upgrade system, you will also need to keep in mind how many of the resources required for upgrading your players will have available. Of course, if your one point increase in ‘strength’ then has no noticeable impact on the game, the worth diminishes. All of this will lead you directly to balancing, and I think that deserves an article all on its own. Just keep this in the back of your mind for now.

A picture of a cup of coffee. The stats next to it read: "Coffee, +5% work speed"

The Upgrade System in Game Tower
I designed the upgrade system in Game Tower with all of those aspects in mind. When the design document is done I will run some actual numbers through a balancing pass and see if they make sense. And I will blog about it, too. Here is my upgrade system checklist:

1. When upgrading a department, the panel right below the button will explain what the upgrade will give you. And not just a vague description either, it will show an exact number.

2. The upgrades will be meaningful, by making the department work faster by 5-10%. This will work well with the real-time mechanic I mentioned in my last post. Each upgrade also adds a work queue slot to the department so that it can work on more games. They will add a convenience factor that should be very noticeable. (more details below)

3. Each department will show it’s upgrade state directly in the main view. I’ve limited the upgrades to a maximum of three, and each one will be represented by a star on the wall. The work queue slots are also directly visible in the main view, as another indication of the upgrade level.

4. To limit the player from buying upgrades to early, making the game too easy and therefore no more fun – each released game will give the player an upgrade token to upgrade floors. This should regulate the amount of upgrades over time. The more games are released the more floors can be upgraded. So as upgrades become more important in the later game, the player will also have more upgrade tokens available.

Work Queues
After deciding to adopt pseudo-real-time for my game in an attempt to focus on the management gameplay, I also want to offer elements that make it easier to keep all floors busy and keep that efficiency meter up.

I am going to add a work queue to each floor, and the department will work on the games in it in order. That should make it easier to queue games and not have departments run out of work while I am not in the game. Having these queue slots right from the start would make the game too easy – or worse, too confusing. So instead each upgrade will unlock one queue slot.

On step further
While I was working on that upgrade system, I had another idea. Why not have special floors that are a kind of an upgrade all in themselves? For example if I build a Break Room in my game studio tower, maybe all other departments will work 5% faster. That would go together nicely with the real-time principle I think. I have couple of these ‘special bonus’ floors already in mind.

GamerGate isn’t evil, and feminism isn’t bitchy.

Are all gamers evil because of the harassment of Zoe Quinn? Ugh, surely no one actually believes that?

I refuse to believe it.
I am a female gamer and I refuse to believe that this group of ‘misogynstic male gamers‘, as they’ve been called, is actually all that big of a group.

Every male gamer and every fellow male game developer I have met so far was absolutely nice. I also worked at a AAA game developer for a very long time and found that my skills were what was important, and my gender not so much (ok, mostly). Of course, I worked with human beings, not trolls.

A man with a megaphone proclaims that they all think that women belong into the kitchen. And in bikinis. There a guys behind him saying that they actually disagree - but they don't have megaphones.

But, as always, those that scream the loudest are mistaken to speak for the whole group. Gamers are not evil.

By the way: The same is true for feminism. Zoe Quinn and Anita Sarkeesian do not automatically represent all women that are interested in a little more gender equality. I can’t count the times those names have been flung in my face when I so much as mention that maybe not all is always fair and right with the world of men and women.
Stop it. Please.
My opinions are my own. (And I haven’t even seen Anita’s videos.)

GamerGate isn’t evil, and feminism isn’t bitchy.

Dev Update #2 – Making Players Wait – Using Pseudo-Real-Time in Games

The game design document for Game Tower is coming along wonderfully, 25 pages and counting. So far I am sticking to my goal to not write a single line of code before it is finished. It takes quite some discipline, but I know it will pay off.

There is another principle from a popular game that I want to adopt: Pseudo-Real-Time. A few years ago I played a lot of Mafia Wars and I really liked the real-time idea. If you don’t know the game, it basically means that when you go on a mission that takes 15 minutes to complete, you would not be able to do any other missions in the game for the next real-life 15 minutes. You could close the game and go have a coffee.

A woman checks her alarm, which reminds her to check in on her game.This principle makes Mafia Wars a perfect game to play ‘in between’, whenever you have a few minutes to check in. It made me come back to the game again and again to manage my mafia empire. Tiny Tower does something similar when building new floors and stocking products. Even in Kapi Hospital it can take your virtual doctors hours to treat a patient with a difficult disease. And during that time there is usually very little for you to do inside the game.

Don’t make players wait
Doing things in real-time inside a game seems counter-intuitive at first glance. Essentially it means making the player wait for the game. And who would want to make their players wait? Players get upset when the loading screen takes to long, and for good reason. Waiting is not fun.

For most games using real-time would indeed be a really bad design decision. Imagine playing Call of Duty and as soon as you get deployed to a mission in Afghanistan, the game would make you wait for the duration of an international flight before it let’s you continue to play?

So why were Mafia Wars and Tiny Tower such great hits? Because in these games the passing of time is part of the gameplay itself.

Indulging Perfectionism
If your floors in Tiny Tower are running out of stock in the middle of the night you cannot restock them until you wake up the next morning. That is wasted time. And people hate wasting time. You don’t want you floors to be idle and do nothing. So you stock up on the faster, smaller products during the day and check in again right before you go to sleep, to start the stocking of the large and time consuming product.

If time becomes a gameplay element, it forces you to plan your steps. Make the most out of your time. It encourages you to be efficient. And being efficient is fun. My personal theory is that it caters to the perfectionist hiding inside all of us.

The idea isn’t new, either. The first game I personally remember to incorporate real-time passing as a gameplay element were those pesky Tamagotchi pets. Does anyone remember Tamagotchis?

Pseudo-Real-Time in Game Tower
I want to use the passing of time in my game as well. My idea is that the different floors in the tower all work in pseudo-real-time. That way it would really feel like I am managing my game studio departments, by telling them which game to work on and also making sure they don’t run out of work.

I wonder if it would be interesting to have an actual display inside the game, telling the player how efficient all his floors are working at the moment.

Of course, in real life a game might take months to develop or even years (again, been there, done that, went there again, repeat). In this game I am targeting the development times to be somewhere from 45 minutes to 3 days, depending on the level.
Like I said, Pseudo-Real-Time.

Dev Update #1 – Why a Game Design Document is important

Trying to be a wise game developer, I started with the game design document for Game Tower before writing the first line of code. This is a crucial part of game development and not having one is one of the reasons why so many developers fail to finish their game projects. And here is why.

Of course my fingers are itching to get started with the real thing, and I am aching to see something other on-screen than black letters on a white background. But I know better than that. I vow to do this right. I will not even create a new project folder in Unity before the design document is complete.

Woman sitting at a laptop, vowing that this time, she'll do everything right.

I don’t want to fall into the trap of starting to implement a game before it is all fleshed out. That is how games get abandoned after the initial tech test is implemented. Writing a game design document means working out your game start to finish on paper first.

Don’t start creating a prototype right away!
Having to go back to design the meat for the bones of a game after you created a working prototype is not as much fun, and it can feel like a step backwards. So, as a result, many projects get postponed indefinitely at this point. This is how you end up with a folder full of tech demos and unfinished game projects. Been there, done that, and went there again a hundred times during High School. With the design written all out beforehand, you make it as easy as possible for yourself to keep going after that initial push.

I look at it as delayed gratification. Do the necessary but cumbersome leg work first, then enjoy the fun parts of actually implementing your game. There is a saying in Germany that describes this concept perfectly: “Erst die Arbeit, dann das Vergnügen.” – There is an English one with the same meaning: “Business before pleasure.”

There is always the risk I might lose interest halfway through a project. A game design document can protect me from wasting my time like that in the first place. It takes time to complete it – I mean really complete it, not just write a few lines and ‘add the rest later’. After I have finished it, the initial hype and excitement about the project will have worn off. If I still like a game idea after that time and work is done, then I know I will have the stamina to finish the complete game.

In larger teams a GDD (Game Design Document) is a must anyway. It’s the best way to communicate a design to all members of the team, and serves as a reference when questions come up. It can also come in handy when you need something to point to in an argument: “But you told me you wanted the gravity gun to work that way!” – “But that’s not how I meant it!”
Yes, arguments like that happen in real-life game studios. It’s always better to have a GDD.

Two ingame characters are racing. The faster one is jumping instead of running. The one behind is complaining about it.

A design document makes you think about all those little details of your game that go beyond the basic gameplay idea. So you want your character to be able to jump? Ok, but how high, exactly? Will he be able to jump higher when the button is held down? What about a double jump? Can you still change his direction while he is in the air? Will jumping be faster than running? Can you shoot while jumping? And what if your character is in the middle of reloading and the player presses the jump button?

If you are a coder, you know how important it is to know these things beforehand when starting to design the code that makes the character jump. (And if you are a wise coder working in a larger team, you also know better than to trust the GDD and you will implement the system to be as flexible as possible anyway – to be prepared for that day the designer will invariably change his mind.)

As you write, you will notice the little holes or flaws in your design.  You get a chance to fix them before you start with the code design. It is much easier to change a paragraph on a page in the design document than to rewrite an entire game system because it no longer works with your current design. Since this is a one-woman show, too many major rewrites would be even more detrimental. I don’t want to waste my time if I can prevent it.

Even in a one-woman project like mine a GDD is important. I am now on page 14 of the GDD for Game Tower. Like I said, I had this on my mind for a while and it all just flows out now.

The first major design decision I put into writing was that the player will not directly choose the genre or type of game that the virtual game studio will create. I want the main focus to be on the management aspect. Instead the game designs are created by game designers that work in the Tower. The player can look at their designs and either decide to trash them, or develop the game in his studio.

Writing this down forced me to think about how the game designs my little virtual designers create should look like. There is no need for a genre or topic. Yes, that’s right, nothing but a title and an icon. Since the success of a game cannot be predicted by those factors anyway, anything else just seems like useless information. Instead, the game design will have information relevant to managing its production: The amount of work that is required from various departments to finish the game and it’s projected revenue.

My idea is that the player can build different department floors into the tower that can perform the individual work. Then he can assign the game to the appropriate floor. This works the same as the patients in Kapi Hospital, in case anyone has played that. It’s a browser game in which you manage your own hospital. You have to build specialized treatment rooms to treat the various illnesses of your patients. If you don’t have the right rooms for all of them, you can still release the patient, but he will only pay you for the things you actually cured.

This will be possible in Game Tower as well.
If you release your game before all the work is done, it will not make you a lot of money. But you can do it.

Game Tower – Yet Another Mobile Game

Clearly I have too much free time on my hands, so I have picked up a new side project, and decided to start creating a little mobile game in which the player manages their own game studio. I have been wanting to do this one for a long time.
A woman browsing the app store, thinking "Clearly there aren't enough games yet."
Remember the game Game Dev Tycoon? It was very nice, but I never liked that the player is asked to pseudo-design the games that are developed in his studio. You can pick a genre, topic and platform from a list. The game then evaluates the choices and how well they fit together to determine how successful the game would be. Pick an odd combination and your game will flop. This feels pretty far away from real life, where those games and movies that break the conventions or mix an unusual combination of genres together can be the most successful of them all.

I want a game that focuses more on the management aspect. I want to build departments and hire workers and so on. Tiny Tower is another game I love and that let’s me do that, but for me it was missing the component where the tower actually produces something. Yes, yes, the floors all actually do stock and sell products, I know. But I felt very detached from those products.

Basically, in my little game project, I want to bring the two games together, Tiny Tower meets Game Dev Tycoon. So I think a fitting development working title will be: Game Tower 🙂

On this blog I will post updates during the entire process of development.
(Unfortunately, GameTower was already taken on WordPress, so I went with GameDevTower instead)