My Thirteen Rules of Game Design

People frequently ask me „Tomek, how do you create such innovative gameplays?”. Well, not really, but I wish they were. So, to establish my game designer cred I wrote down my thirteen rules of game design.

  1. The choices made by the player are the atoms of the gameplay. There is no gameplay without choices. The goal of game design is to make these choices interesting.
  2. The choices must have consequences, either in the game or in the player’s mind, otherwise they are meaningless.
  3. The more unpredictable the consequences are, the harder the game becomes. There is a sweet spot to that.
  4. There are ways to make the consequences more unpredictable, like time constraints, AI, randomness, deterministic chaos, hidden information.
  5. Gameplay can also be viewed as possibilities offered to the player constrained by limitations.
  6. Possibilities are player’s actions and consequences of said actions.
  7. The game is made deep by a large number of possibilities available to the player.
  8. The large number of possibilities can be created either through many actions, or through many possible consequences of different ways of performing an action.
  9. The latter way creates the elusive „easy to learn, difficult to master” gameplay.
  10. Limitations are what creates the choices by forcing the player to choose one possibility over the other.
  11. Limitations should not be arbitrary. It is the best to disguise limitations as opportunity costs or as adverse consequences of actions. That way you do not reduce the depth of the gameplay too much.
  12. The most useful conjunction in the game design is „but”.
  13. Avoid the pitfall of scale. Designing Skinner’s boxes and auxiliary features can blind you to the fact that you do not have a solid core gameplay.

I have found or invented those rules as tools for my own, personal use. As such they are not supposed to limit the designer, because why should I limit myself? They are more like helpful prescriptions for various problems that arise during the design and prototyping process. They are especially useful when I feel something is wrong about the game, but I do not instinctively know what. The rules both allow me to ask questions that reveal the hidden problems and provide solutions to them.

In the following weeks I will explain all the rules and their applications in details, so stay tuned!

The Underground Guild – First Screenshot and The Challenge of Making It Fun

Today is a grand day, for it is the day I will show you the first screenshot from The Underground Guild.TheUndergroundGuild

Behold, the Hero, the rats and the tile based dungeon. Oh, also the rat hole. The game has been in development for three weeks and it is already playable. I will not reveal anything about the gameplay just yet, but if you think this looks suspiciously like a „bring me ten rat tails” quest, there is something to it. But I promise to make it fun. Speaking of „making it fun”…

The game is currently in a state I call „functional but not fun”. This is a stage in the prototyping process, when you have already put in some of the basic mechanics and you can see them working, and you can see that right now they are not very fun. It is a stage I find particularly difficult and disheartening and I have abandoned many projects at this stage. This happens because, when I am prototyping innovative gameplay mechanics,  at some point I have to decide whether this prototype is fun enough to guarantee spending next few months or years working on it, or should I move on to the next idea. And right now the game is not fun at all, and it makes me constantly wonder, whether this is because there are still not enough features implemented, or is it because the whole idea was bad to begin with, or maybe the game just needs some better level design, or maybe a few animations and sounds would do the trick.

Right now I have identified a few simple mechanics I can implement over the next week that I hope will introduce some fun to this game, so wish me luck!

10 Tips for Moonlighting Developers

As you may or may not know, I have a full time job developing games at QLOC and at the same time I try to develop indie games on the side. This is hard and seeing how much reaction my recent tweet on the subject received, I am not alone in this predicament. Let me clarify, 20 hours of work on a side project done in a week is a good week and I do not do this every single week. It has always been and still is very difficult for me to be motivated and persistent about my side projects, but I feel over the years I have got a bit better. I have learned that motivation and persistence is not about having some legendary willpower. It is rather about finding a set of tricks that work for you. For this reason allow me to share a few tips and tricks I have learned so far.

Tip #1 – There is no one tip to rule them all

The only 100% guaranteed rule about motivation is that there are no 100% guaranteed rules. Everybody’s psychic works differently and everybody has slightly different circumstances, so if some tip worked for one or even many people, it does not mean it will necessarily work for you. Even worse, a tip might work for you right now but will stop working when your circumstances change. The only thing you can do is search for various tips and tricks and try them out, until you find a set that suits you well. This applies to tips on this list as well, you should treat it as a good starting point on your journey rather then a complete solution to your problems

Tip #2 – Keep a detailed TODO list

Since you will be frequently working for short bursts of time, keep a detailed TODO list of stuff that needs to be done for you to finish the project. The list should be detailed enough that when you sit down to work, you will not need to waste time remembering what exactly you were supposed to do, you will just check your list and do it. This might not sound like much, but it actually is a huge time saver. Additionally, thanks to the list, you do not need to overburden your memory by remembering things that need to be done. When you notice that a certain piece of code might be a problem in certain circumstances, just add a task to the list about checking that thing later and keep working on your current task. As a bonus, crossing out a task on the list feels awesome. The list does not have to be super high tech – I usually use a piece of paper or Google Task lists and this is quite enough.

Tip #3 – Break down your tasks as much as you can

This is an extension of the TODO list idea that comes from the „Getting Things Done” methodology. Break down your current big task into many small ones that can be completed in 10 minutes or less each. This makes working in short bursts even easier, but most importantly it makes the huge task look less daunting, which will help you with motivation. Breaking the task down can be done in two ways. One is divide and conquer, this is the classical top-down method where you split the task into several smaller tasks, then split those tasks into even smaller and so on till you arrive at the desired size. The other way is chip away – this is a good method when you are unfamiliar with the task at hand, so you cannot predict how it can be split, but you can think of a few small things that certainly will have to be done before the big task is done – start working on these small things. You will gradually reduce the size of the big task, but also gain domain specific knowledge, that maybe, at some point, will allow you to split what remained of the task in a top down manner.

Tip #4 – Work in the morning

This one came as a surprise to me, I have been using it so far for just two weeks, but it works great. The logic behind this trick is pretty simple. Getting yourself to work in the evenings can be horrible – you have just worked for 8 hours and you need to wind down, not work more. So go to bed, then wake up a bit earlier and work in the morning, before you go to work. I know this may be very counterintuitive – I am a night owl myself and for my whole life I always preferred staying up late to waking early – but this totally works. When well rested not only do I find it easier to motivate myself but also I am better at what I do. I frequently find myself working both in the morning and in the evening, since the morning work session makes me so enthusiastic about the project that I jump back to it right after I come back from work.

Tip #5 – No zero days

This is something I have picked up on a bodybuilding forum. It is all about taking on this attitude: it is OK if today you have worked for an hour, it is OK if you have worked for 30 minutes, it is still OK if you have worked for just a minute. It is not OK if you have not worked at all. Try to have some work done every day. This way working on your project becomes a habit and what is perhaps more important, the details of your project stay fresh in your head. Note that I have learned that this rule has a dangerous downside – when you break the streak of working days, the feeling of guilt about it somehow makes the break even longer then it was necessary. Therefore if you have very irregular working days, this particular rule might not work for you.

Tip #6 – Plan your weeks

Working on your game every day is not always possible. Perhaps you have some other hobbies or obligations that you need to fulfill, or perhaps you need to split your attention to take care of things like marketing your game. This might make you feel like you are constantly jumping between tasks, always feeling like you are neglecting something that needs to be done. If it is so – make a rough plan of your week. Plan one thing you want to do on each weekday’s evening and one or two things to do on Saturday and Sunday. That way you can balance out how much time you will spend on various task and you will stop wasting time and energy wondering what you should be doing now or feeling guilty about neglecting your responsibilities.

Tip #7 – Keep the code runnable

This one comes from the agile development methodologies. Try your best to always keep the code runnable. If you do not, you can fall into the trap of having an unrunnable code that you do not want to work on, because making it runnable again is too much work. For that reason, in particular, always keep your refactorings local and simple and always opt for doing something with several smaller refactorings rather than one big. Big refactorings have derailed many professional projects, you cannot afford such risk.

Tip #8 – Optimize your workflow

This one is based a bit on the kaizen philosophy of management. Always look for ways to simplify and speed up your workflow. If something annoys you, look for a way to fix it. For example, when programming I usually need Unity 3D editor, MonoDevelop, Unity documentation in my browser and a file explorer window to handle the source control. So I have made a .bat file on my desktop that fires up all of these with one double click, saving me some start up time when starting to work. Similarly, when I notice that some piece of code has become cumbersome, I take time to refactor it into a more usable form. While such steps might not always pay off by saving your time, they will pay off by making it easier and more pleasant to work on your project, increasing the likelihood that you will want to work on it.

Tip #9 – Try yerba mate

If you still need to work at night and need caffeinated beverages to stay awake, try yerba mate instead of coffee. It tastes horrible, but at least for me it has a pleasant effect of not making me nervous and distracted, like the coffee does. Just be careful because it is really strong and can easily keep you awake for several hours longer than you would like to, if you drink too much of it.

Tip #10 – Some things can only be learned by failing

There are things in life for which there are no tutorials. You cannot learn them step by step. Perhaps because the steps cannot be separated, perhaps because no one really knows the steps. You just have to try to do them and fail, then try and fail again, and again, and keep doing that until at some point you will stop failing. This is something that can be learned from sports, unfortunately we programmers tend to avoid sports. But it can also be learned from multiplayer games. No matter how much you read about LoL, no matter how much you train with the bots, in your first match with actual people you will suck. You will also suck in the second and third match and so on until after a few days you will be a somewhat decent player. For me it seems that developing games is quite similar, only instead of days the process may take months or even years. So even if you fail on your current project, do not despair. It is not that you cannot be a game developer, it is just that you have not yet learned how to handle a project of such scale. Treat this failure as another step along the way and try again. Maybe try doing something smaller. Most important of all – keep trying.

The Underground Guild

This is an informal announcement of my new project The Underground Guild. The Underground Guild is a tactical game with a twist, set in a comic fantasy setting, with stick figure art style inspired by The Order of the Stick webcomic. Right now the game is in an early prototyping phase and I hope to have playable builds available by late 2014. Updates about the game’s development will be posted on this blog.

Since I am still prototyping the game’s exact mechanics it is a bit too early to talk in details about the gameplay or the twist, but the general style I am aiming for is a lighthearted tactical game with bite sized missions that, while tactically challenging, can be typically finished in 10 to 20 minutes. That way the players will be able to replay the missions to try out different tactics without wasting much time and will not get stressed out about possibly failing a mission. I plan for the game to be somewhat non-linear with player being able to choose which missions he does or does not want to do depending on his strength and weaknesses, but that depends on how complicated the level design turns out to be.

This week I have been focusing on doing some art research, particularly on capturing the OOTS stick figure style. I will of course change the style a bit, so that I am not a total copycat of Richard Burlew, but right now I have created a female protagonist very much in OOTS style, just to see how well it works with the gameplay and the engine. What do you think?

Lead character for The Underground Guild

When 48h game jams are not enough

It’s high time to write something about my personal efforts that I hope will be of some use to other aspiring indie developers. What I am going to write today is probably not rocket science, but it’s still something I wish someone told me earlier: When you have a day job, going beyond weekend game jams is difficult and, in particular, 7 day jams are not a very good way to go about it. Let me tell you how I came to these conclusions.

First a bit about my background. I am a professional programmer, I’ve worked and I am working on AAA games. I am not doing indie games to „get into industry”, I am doing them to realize my own creative ideas. So far I have „published” two weekend game jam games – My Little Robo (currently not working due to broken compatibility between cocos2d-x versions) and Rainbow Rangers. I have also made a third that I have not published (because it turned out to be quite poor).

Some time ago I’ve decided that although I still do not feel confident enough to tackle some sort of full scale production, with such experience I could try doing something bigger than a 48h jam. What seemed like a pretty logical next step was a one week long project – there are some occasional 7 day jams and the „one game a week” challenge received recently many praises from quite knowledgeable indie developers. Above all, 7 days seemed like just the right amount of time to make such a slightly more ambitious project.

With that thought in mind I picked an idea – a chess based roguelike – fired up Unity and started working. After a week I failed, I admit, mostly due to overstretching myself, but I learned one important thing I would like to share: with a full time day job, a 7 day project is barely any different from a 48h game jam in terms of scale. So, if your goal, like mine, is to work on something bigger than that, such a project turns out to be a rather bad way to do it.

Why? Let’s start by analyzing how much development time there is in a 48h jam. A weekend to make a game may sound like madness, but actually it is a lot of time. I’ll tell you what’s my schedule during the Ludum Dare. On Friday I do the shopping and cook myself enough food for two days, tell my wife and family I will be busy for the whole weekend, prepare my computer and go to bed at 8 PM. At 4 AM of my local time the theme is announced and I wake up well rested and ready to work. I work till midnight, go to sleep and the next day I wake up at 8 AM and work till 4 AM submission deadline. Of course on Monday I have to take a day off at my day job, since I am too exhausted to even drive to the office, but this way I can easily put about forty hours of work into the game – an equivalent of a full working week. Does not seem like such a madness now, does it?

Now there are two problems when scaling this model up to a 7 day project. First of all, there is not that much free time during the rest of the week. Assuming the best possible conditions, if I work for 5 evenings on workdays and do a weekend crunch after that, this adds up to about 5*3 hours + 40 hours = 55 hours of work. But, second of all, those 40 hours on weekend are „borrowed time” – borrowed by arranging the rest of the week in a way that gives me as much time as possible during the weekend. And the more I scale this up, the more of that borrowed time I have to give back. For example the Friday preparations before weekend crunch mean I cannot work on Friday – one evening is out. Also, I can neglect my wife for one weekend, but not for a whole week – another evening is out. And I will probably need to do some shopping during the week – minus one hour. So the total goes down to about 48 hours.

And this is still working on borrowed time, since I am doing an intense crunch during the weekend. I can do this once, but if I were to do a „one game per week” challenge I could not keep taking Mondays off for a whole month or more. I would have to reduce my weekend workload from 40 hours to at best 2 * 12 hours for this to be somewhat sustainable. So the total for the week goes down to 32 hours.

So what does all this tell us? A 7 day project – if you have a day job – gives you merely 20% more work time than a weekend game jam. 20% means you can polish the game more, or add one extra feature, or think about it more, or work with less intensity, but 20% does not mean you can do a project of a larger scale.

A „one game per week” challenge means you will in fact be working on projects at least 20% smaller than a weekend jam. There is no denying such a challenge might be good if you want to quickly gain experience, or build up your portfolio, but if you want to try your hand at bigger projects – no.

What is a working game developer to do, then? I don’t have any proven answers. The obvious one would be „if one week is not enough, try two weeks”, but I tried the obvious answer previously and you know the results. So I am going to do something a bit different – an „80 hours game challenge”. I will create a work time meter that I will run whenever I will be doing some work on the project and keep working, whenever I have free time, until I have clocked in 80 hours on it. It might take a month, it might take two, it does not matter. I think this approach has two advantages. First, it guarantees the time scale of the project will be significantly longer than that of a weekend game jam. Second, it will give me a better understanding of how actually does my calendar time translate to working time, which I think will be an important knowledge when I will scale my projects even further.

I will let you know about the project’s progress on this blog.

Rainbow Rangers postmortem

The results of Bacon Game Jam are up, so it’s time for a quick summary of what went well, what not so well with Rainbow Rangers.

The good:

  • I’m quite glad about the level of polish, at least code wise; it was the first time I did a game with a large isometric map in Cocos2d-x, the movement controller turned out really nice, a few sprites and tiles I’ve made by hand were also usable;
  • The gameplay I came up with is quite original and non-violent and this for a game made in 48h is an achievement;
  • Some people got the idea behind the gameplay and liked it, as you can see on the result page;
  • I did not crunch myself into the ground making the game;

The bad:

  • Overall most people probably did not quite like the gameplay. I suppose this might be due to nonstandard gameplay and lack of good instructions. I planned to make a short video tutorial and it is a pitty I did not follow through with that plan;
  • The game ended up in 47th place in the jam. That’s right in the middle and I really hoped for a better position. Most likely this was due to the previous point;
  • I did not manage to make any sounds for the game. I traded the time to make sounds for time to polish the code;
  • Some guy actually got a bit offended by the game and gave it really poor scores; that’s sad because I did not mean to offend anyone and it probably cost me a few places in the final ranking;
  • There was some bug with spawning enemies that slipped under my radar and sometimes made the game impossible to finish;

Conclusions:

  • I should practice making video tutorials, since this might be an easy method of explaining nonstandard gameplays to players;
  • Be careful when approaching sensitive subjects, especially in a small competitions where even one bad vote is costly;
  • Put a few of the routines developed for this jam into a public framework, so that I can reuse them in later jams. This should give me time to make the sounds next time around.

Rainbow Rangers – Bacon Game Jam #6 entry

Rainbow Rangers is a game about a group of masked gay superheroes defending a gay club from homophobes by kissing in public. Yes, you read that right. If you are wondering what was the theme of the Bacon Game Jam, it was „rainbows”. What’s the connection? Well, obviously rainbow is a symbol of the LGBT movement, rangers wear rainbow colored shirts and the club is called „The Rainbow”. Pretty loose connection, but when I got the idea of making a game about a group of masked, colorful, gay superheroes, preferably drawn in the yaoi manga style, I just could not resist the temptation of making it happen. The yaoi thing did not happen and the game is a bit unpolished, as it usually is with game jam entries, but once you grasp the rules it is quite fun. Remember to read the instructions on the start screen. I should probably make a tutorial video for it some day. You can download game’s sources (usable under GPL 3.0) here.

My Little Robo – Ludum Dare #26 entry

I took part in Ludum Dare #26 game making compo. It is a contest in which you have to make a game, on your own, in 48 hours, using provided theme. Theme this time was „minimalism” and my entry was My Little Robo – a physics puzzle exploring the gameplay effects of  using minimalistic movement controls. Many people think it is somewhat similar to QWOP. Here you can play the game and here is the entry page for Ludum Dare.