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)