Skopós Behind the Scenes

Alright, time to blow the metaphorical dust off the ol’ blog…

I was never especially punctual with my posts here, but over the last 5 years or so my life has gone through such drastic changes that it’s become something of an afterthought.

One of those changes is that I’ve started being active on Twitter (aka X), specifically as a way to interact with the Rainbow 6 Siege community. Slowly but surely, I’m trying to break down some of our community interaction barriers.

This past week, I made a big step in that direction with a series of threads I call Skopós Behind the Scenes (it’s not the most creative name I’ll admit).

Seeing as Twitter is terrible for archiving things, I’m also putting my tweets here for posterity. Enjoy!


Link to the final post, which compiles the other ones as well

FIRST POST

To celebrate the release of Operation Twin Shells, I’ve prepped a series of behind-the-scenes threads to give you all a glimpse into Skopós’ development, each with a different theme. Expect a new collection of fun facts and anecdotes every day for the next week! 

EARLY CONCEPT 

0/10 Welcome to Skopós Behind the Scenes: Early Concept! Here, I’ll talk about the early conception and prototyping of what would eventually become our newest operator. 

1/10 The gadget was a concept we prototyped and shelved a couple years back because it would be too time consuming to develop. Changing the release schedule to 2 new ops/yr finally gave us the time to make it a reality. 

2/10 When we first started prototyping this version, it was much simpler. Two shells, no shield, and the camera wasn’t part of the swap process. Hold gadget button to switch. One life per shell was also a thing back then, so you had to kill both shells. 

3/10 Our first design problem was how to protect the idle shell. No protection meant you'd try to hide it and that usually meant putting it somewhere useless. Another solution was a bulletproof state when idle, but that had potential exploits and was hard to justify logically.  

4/10 The reasoning for adding the shield was that if you place it smartly, the shell can still be protected, but it's not completely invulnerable if the attackers go through the trouble of dealing with it. 

5/10 We bounced back and forth on whether it should be like a deployable shield or a ballistic shield. At one point it was almost like a clash shield. We opted for deployable since it was simpler, easier to understand, and left more balancing levers open. 

6/10 Next big headache was the “5v6” problem. We'd constantly get feedback in playtests that it felt unfair to play against Skopós because one player effectively had two lives. When one shell died you just activated the other one.  

7/10 For a good while we tried to find a way to make the two-life mechanic work. The earliest solution was to give them weaker guns, but that just made the op unfun to play as on top of unfun to play against. 

8/10 After several attempts, we pulled the plug on two lives and made it so if the active shell died, that was it. This suddenly opened up room for a lot of improvements.  

9/10 Late in conception, we had a lot of back and forth on what Skopós’ identity was as an operator. We ultimately branded the op as a shallow roamer and intel character, positioned somewhere between Valk and Oryx. 

10/10 The keywords I used for Skopós’ design conceptually were Mobility and Adaptability. Their job is to quickly deliver offence or defence where you need it most. 

LOADOUT 

0/11 Welcome to Skopós Behind the Scenes: Loadout! Here, I’ll talk about Skopós’ loadout and general kit. 

1/11 Before anything since this comes up often, I wasn’t the sole shot caller on loadouts. Mathieu, our resident weapons balancing expert, helped me through making sure we developed a kit that was both fun to play and balanced for the op. 

2/11 We wanted a unique gun to balance Skopós (they were seen as a big risk at first). Initially we experimented with a concept we haven’t seen in Siege before, but we couldn’t quite get it to work the way we were hoping, so we had to scrap it for Skopós. 

3/11 At one point, I wanted an to give them an LMG (because my fantasy for the op at the time was “maximum area denial”), but later shifts brought us to an SMG or AR instead to better reflect their more roam-centric playstyle. 

4/11 By the time Kure’s identity was set, giving Skopós a sniper was already out of the question. One of the concept weapons we tested could have been close, but after that died, we didn't really consider a DMR as a good fit. Too much spawn peek potential. 

5/11 We wanted the primary to be based on a customisable platform. I specifically didn’t want another M16 (we have enough of those). Instead, I pitched some German rifles used by the Hellenic Army. Eventually that turned into a highly customized AR33. 

6/11 Given the time we put into fine tuning the balancing of Skopós’ primary, we opted to stick to just the PCX and P229 for now and see how things play out. Putting the op in players’ hands will make it easier to figure out what else we should give her, if anything. 

7/11 We came very close to giving the shells the Aruni punch. I mean, robot arms, right? But adding passives (especially ones without much cost like the punch) makes life hard for the balancing team from a resource economy side, so we opted for impacts instead.

8/11 Yes, we considered a pocket shotty too, but honestly, adding one to Skopós’ kit felt like it might be too much. You’re already spending most of prep setting up the idle shell, and Impacts seemed sufficient for roaming needs.

9/11 The idea of making the shells different (loadouts, health/speed, etc.) came up, but they were already complex, and if they were too different there was a risk that players would prefer one over the other. We would rather keep the focus on the swap as the core ability.

10/11 We thought about making Skopós a 3-health given the metallic bodies, but ultimately that went against the idea of emphasising their mobility and flanking potential. It was a case of gameplay beating out thematics. They’re lithe enough that it isn’t weird imo.

11/11 The secondary gadgets being shared may be seen as a weird choice, but we opted for the choice that served gameplay. It’s the same logic behind letting Castle get his armor panels back when another defender takes them down.

INTERACTIONS 

0/07 Welcome to Skopós Behind the Scenes: Interactions! Let's talk about interactions again, but this time, from a behind the scenes perspective.

(For context, I say “again” because I posted this thread a couple weeks prior.)

(And while I’m doing asides, this was a post that is not from my threads, but that is also relevant to the subject matter. It comes from Joshua Mills, our gameplay design director.)

1/07 The interaction list was a tough balancing act between limiting passives, doing what made sense, and not creating weird game-breaking behaviours. In most cases, I tried to follow an internal set of guidelines I set for myself: 

2/07 Be as consistent with existing rules as possible. The active shell is an operator, the idle shell is a gadget, except for direct damage. The idle shell isn’t organic, but limit that to obvious stuff, and otherwise follow rule 1. Treat the two shells as independent entities. 

3/07 We considered EMPs having other effects, like slowing the shell or acting like a flashbang, but they all kinda felt like overkill, or like we’d be breaking game conventions players are used to. A single op shouldn’t mess too hard with your understanding of the game. 

4/07 Rook was tricky. Changing Rook as part of Skopós’ dev was a no go, and the shells being able to pick up armour brought up several edge cases and confusion. In the end, our other possible solutions were confusing, so we decided it was better to cut the interaction altogether. 

5/07 We tried several different interactions with Brava, like her being able to hack the idle shell to use the camera. Her piloting an active shell was never on the table. Ultimately, Occam’s Razor won out and we went with the overheat. Other options just didn’t work. 

6/07 You may notice Oryx can dash through deployable shields (as of Y9S1), but not Skopós’. That's a call we made because of the idle shell behind it, which negates any mobility benefit the dash would give. Destroying the shield would serve no purpose other than toxicity. 

7/07 Nokk getting her buff this season and the hilarious interaction she now has with Skopós was serendipitous. We didn’t explicitly plan for those things to coincide, but I’m so happy they did. 

TECHNICAL 

0/12 Welcome to Skopós Behind the Scenes: Tech! This time, we’re getting into the technical and design challenges that came up during development. 

1/12 One of the very first hurdles we had was the tech cost of having three characters on screen in certain menus (ex. operators, operator select, post-match). This alone almost caused Skopós to be cut during prototyping! 

2/12 A surprisingly big tech issue we had to overcome was the fact that we had to spawn in an extra character. We had to add a new spawn point to every site on every map just for Skopós. Sounds simple, but that's no small task! 

3/12 Until about 2/3rds of the way into production, Skopós’ idle shell used an Osa shield as a placeholder. It was the closest thing we had for it for testing purposes. It did the job well enough. 

4/12 Having a body that is sometimes an operator and sometimes a gadget is really complicated tech-wise. While it made a lot of sense for the design, that call of mine made things very complicated for the programmers. Sorry! 

5/12 During testing, one recurring issue we had was people switching blindly without knowing what they were switching to. The idle shell camera was there as an alt mode input (like Ram/Hibana/etc.), but no one used it. We then made the camera mode part of the swap. 

6/12 That resulted in the swap slowing down (it was maybe too fast before), but also made people more interested in looking before they leaped, which proved much more effective. The “fast swap” was eventually cut because it brought a lot of complications for little gain. 

7/12 We had a lot of trouble with the swap speed. We wanted it fast for gameplay, but we had tech and animation constraints. Animating both shells swapping at the same time wasn’t viable, so it needed to be one after the other. 

8/12 Testing without the animations made the swap feel painfully long, but it became much more comfortable when stuff was actually happening on screen. It’s pretty common for actions to feel much longer when there’s no animation. 

9/12 There was a period late in development where swapping was really hard because the valid positioning was based on a deployable shield. Deployable shields need to have space on the other side to vault over it, so you can't really put it in tight spaces. 

10/12 Fortunately, the vaulting on both sides is not a restriction we needed for Skopós, so we shrank the collision box a lot. We still need to be careful about clipping and creating any weird exploits when playing around with it though. 

11/12 We tested Skopós pretty rigorously to avoid vaulting exploits. Ops that can mess with navigation always come with a lot of risks. Even so, they’re worth exploring. This is also why Osa and Azami were so hard to develop. 

12/12 Hilariously, in one of our last test sessions almost nobody noticed the HUD on the left. Someone even told us we should have something that actively tells us when the shell is in a valid swap position or not. You can see that older version in the reveal panel footage. 

REALIZATION 

0/13 Welcome to Skopós Behind the Scenes: Realization and Naming! Let’s talk about how we figured out how Skopós works in-universe. 

1/13 We tried other “teleportation” ops in the (distant) past, but realization (i.e. in-game logic) was often a blocker. This was the first time we could make something that could be considered grounded enough to really pursue. 

2/13 For those arguing that robots are too sci-fi for R6, I remind you that spec ops are usually cutting-edge tech-wise. I would argue that we’re not pushing all that far. If Boston Dynamics can do what they're doing, piloted humanoid robots hardly seem like a stretch. 

3/13 Having Kure be an integral part of the operator was important to us. We wanted to make sure you always knew you were a human pilot, not a robot. That's why her reflection is there. Reminds me of Metroid Prime tbh. 

4/13 You may notice a little box near the shells’ collar. That’s the device that prevents the shells from being disabled by EMPs when active. No way were we making an op that would be stopped dead with an impact EMP, after all. 

5/13 That’s not blood, it’s transmission fluid, which happens to look a lot like blood. We considered more metallic damage feedback, but they got confusing for players. It became hard to know if you were shooting an operator or a piece of cover. 

6/13 Sound direction was a tricky thing. It didn't make sense for the shells to scream if stunned, and we didn't want Kure to scream through them either, so we settled on a set of other mechanical sounds. Kure still speaks via the team radio though. 

7/13 Unlike Deimos, we (the gameplay side of the team) didn't know Skopós would be Kure until after prototyping was pretty much done. Granted, we knew they'd be a Greek woman, so the signs were there and we weren’t really surprised. 

8/13 Anytime we make prototypes, they use a placeholder name. Some of these are public, but many aren’t. They’re often subtle references or a simple idea of how the gadget works. Skopos’ dev name was a fictional character. I won’t say who. 

9/13 Skopós means “purpose”, but also “watcher". We wanted a name that called to her identity as someone who surveys and controls things from afar. 

10/13 In retrospect, Athena could have made sense as well as a mythological reference. Wise and vigilant warrior woman… Then again, she's also kind of overused. 

11/13 For a while, my design docs used “spear and shield” modes instead of “active and idle”. I liked the hoplite fantasy, so I was trying to sell it to the rest of the team. Eventually though, active and idle were used because it was easier to understand. 

12/13 We often called the Shells “bots” during development, but we didn’t want to use that because we didn’t want people to think of the robots as autonomous. My suggestion was “Frames”, which is a nod to a certain game I put many hours into. 

13/13 To make sure I got the pronunciation of Kure’s name right for the reveal panel, I asked my barber when I got my cut the week before. Shoutout to Dimitri! 

CLOSING AND SHOUTOUTS

0/18 Welcome to the finale of Skopós Behind the Scenes! Today I'll compile my other Behind the Scenes threads here and take a moment to give some final thoughts and shoutouts. 

1-5/18 Links to the previous threads (which you obviously don’t need here).

6/18 Naturally, no one person is solely responsible for an operator. They are the product of a whole team of dedicated developers working together. I’d like to take a moment to recognise just a few of them. 

7/18 The original idea of a double body mechanic originally came from Carlos, another Siege designer. Without his pitch, Skopós never would have been! 

8/18 Skopós would never have been possible if not for the incredible work of a lot of people, but I want to give special credit to the programmers who busted their butts to get her shipped. Rénald, @Eclipse__r6, @MaximeLarivier3, and Frankie are absolute beasts! 

9/18 Rénald in particular was the lead programmer for Skopós. I’ve never seen someone work so passionately to get the job done. He (and all the progs) deserves the utmost respect. 

10/18 Our producer Dorian and QA specialist Maxime B deserve major props for keeping the production and testing on track and me in line. There was so much to manage here, and I didn’t make it easy either! 

11/18 Thomas did fantastic work defining the narrative side of Skopós. Keep your eyes peeled, because there’s plenty more lore to come from him and the entire narrative (we call them “Universe”) team! 

12/18 @SpooksGD, Mathieu, @iSmallville, Rachel, and Seb should also be recognised for helping me on the design side of things. Their input was invaluable in helping me figure out what our vision for the operator was, and in determining how to make it all actually work. 

13/18 Speaking of design, you know the HUD that shows all the info about the shells? Hella complicated to design. The credit goes to our UX designer Rachel for sorting that out. 

14/18 This was the last operator worked on by our former Realization Director Jérémie, who you may remember from past reveal panels. His efforts ensured that we went into production with something grounded and cool. Thanks Jerem! 

15/18 There are so many more folks involved in production that deserve credit of course (please feel free to shout yourselves out if you’re reading this!), the ones I mentioned are just the ones I worked the most closely with. 

16/18 In closing, I’ve hinted for months that Skopós would be one of if not our most ambitious operator yet. I stand by that. So many complex systems working in parallel... But seeing the positive responses from you all really makes it all worth it! 

17/18 Will Skopós be adjusted in the future? We’re going to wait and see. I anticipate her needing time to find where her true place in the meta. The fact that people are concentrating on her will have a big impact on how she’s played. As things normalize, this will evolve. 

18/18 If you made it this far, congratulations! Here’s a bonus: back in uni my senior game design project was a game about a pair of robots. Not the same game by any stretch, but it’s funny that I’ve come full circle! 


KuriusHacks: CE Presentation: Game Jam Survival Guide

Once more, Kurius asked me to do a presentation for them, and I was more than happy to oblige. This time, it was about game jams, something I have quite a bit of experience with, and that I’d been meaning to write an article about for a long time.

Here’s the script of my presentation. I’ll likely have the recorded version linked sometime in the next few days or something. EDIT: Okay it took more than a few days for the video to release but here it is:

Hey everyone! I’m Justin, and today I’m going to be talking to you a bit about how to survive a game jam.

Some of you may remember me as one of the people who presented at Kurius’ previous Learnathon 21. To anyone who does, hi again! It’s honestly great to be back. Thanks to Kurius for inviting me again.

For those who don’t know, I’m a game designer at Ubisoft, currently working on Rainbow Six Siege. Before that I worked on Hyper Scape, and before that I worked in the mobile and indie games industries…

But most importantly for this talk, I’ve participated in a few Game Jams. Well, more than a few. I’ve kind of lost track of how many of them I’ve done, actually. What you see on screen isn’t even an exhaustive list! I’ve done all kinds of jams. Some turned out great, some terribly. I’ve won some jams, I’ve lost many more, and I’ve learned a lot. That’s why I can say with confidence that…

Game Jams, hackathons, or whatever you want to call them, are genuinely fantastic ways to develop your skills! The experience you gain, the friends you make, and the trials you overcome are basically like speed training for a career in games or any sort of development. Not to mention they can be a lot of fun! I honestly can’t recommend them enough, so to those of you participating, I say good on you! For those of you that aren’t, you definitely should when you get the chance.

That said, doing a game jam can be pretty intimidating, especially if it’s your first time. There’s a lot to take in, and a lot can go wrong. So with that in mind, I prepared a few tips to not only survive, but thrive in a game jam environment, from start to finish.

Before you even start the jam, there are some things worth keeping in mind. If I’m not mistaken, you’ve already started this jam, so some of these might be a little late for you, but it’s worth keeping in mind for future jams.

The single most important part of a jam is your team. It doesn’t matter what the theme is or what challenges or resources you might have if your team isn’t built properly.

There’s multiple facets to that. The first is of course your roles. Ideally, you want a team of people who can each specialise in a certain part of the work, with a bit of flexibility to help out with other parts as needed. Generally speaking, in a five or six person team, you want a distribution roughly like this:

  • 1-2 Artists

  • 1-2 Programmers

  • 1 Designer/Project Manager/Flex

  • 1 Musician/Audio Designer (optional)

Artists and programmers are easy to stack on a single team because there’s usually more than enough work to split between them without them stepping on each other’s toes. With just about everything else, one is more than enough.

Now, that isn’t to say you can’t do a game jam with a team of only designers or programmers. However, you’ll definitely have a much easier experience if you keep things balanced. Trust me, I’m speaking from experience on this one. In fact, want to see what a game jam game with no artist looks like? It looks like this.

Roles aren’t the only type of balance to consider when thinking about your team. It’s also important to consider what your goals and methodologies are. There’s no “wrong” way to do a game jam, but it’s best to figure out what everyone on the team wants out of the jam before diving into it. For example, if you’re there to participate casually and practice your coding skills, but the rest of the team is looking to aggressively compete for the top spot, you might find yourself mismatched.

Figure out your intentions early. That way you don’t end up with shattered expectations or bad blood within the team, because you never want that.

You’d be surprised at how many people come to a game jam without the equipment they’ll need to actually participate. This is of course a bigger deal if you’re physically attending a venue and not doing the jam remotely, but it can apply then as well. Make sure you have all or most of the software and hardware you’ll potentially need to do your roles in the jam. As a team, it’s also a good idea to come up with a few standard ways to communicate and share files before you start working. If nothing else, make sure you have a default way to contact each other for emergencies. You never know when you’ll need it.

A dev gym is quite simply a dedicated space to test things out and experiment. In the context of a game engine like Unity, that would be a simple scene. This is a very useful thing to have in general, but especially in a game jam since it allows you to work on things without directly modifying the game. This will be critical if multiple people are working on the project directly, integrating their assets and putting things together. As a rule, I always keep one gym per programmer at least. It can save a lot of headache in the long run, since mistakes made in a gym won’t break the rest of the game. This is also good training for working in the industry, since we use the same concept there too.

By the way, gyms aren’t exclusive to programmers. Level designers can make good use out of them. Artists can use them to test out shaders and lighting effects. Even sound designers can set up an environment to test their sound effects and music.

Point is, don’t do all your test work in the final scene. That’s a recipe for disaster.

Game jams are all about time management. A key to successfully completing a game jam is to properly distribute your time across the different tasks you need to perform. If you don’t do this, chances are you’ll find yourself scrambling to make your half-finished game work in the last hour. Usually because you wasted the first day or two thinking “ah we’ve still got plenty of time to figure things out”. You don’t. Not really, anyway.

A good way to get around that is to simply set deadlines for yourself. Once you go over that deadline, it’s time to put your pencils down, make a decision, and move on.

Now, this can be different for every team and every jam, but here are the deadlines I typically used for a classic 48 hour game jam (adjust as needed for the length of your jam):

  • Hour 5: Have a rough concept

  • Hour 8: Finalise the concept, plus have a basic main menu, gameplay scene, and game over screen

  • Hour 10: Confirm that what you’re trying to do is technically possible and have a task list

  • Hour 24: Have the basic gameplay loop and core mechanics and assets made

  • Hour 30: Have a unpolished but playable first version

  • Hour 40: Have a polished presentable version

  • Hour 46: Have a submission and presentation ready

  • Hour 47: Submit a final version

  • Hour 48: Submit any last minute fixes

These benchmarks are on the aggressive side and not a hard rule (especially for your first jam), but if you can manage to follow them then you ought to have ample comfort room to make your game as good as it can possibly be. There’s nothing wrong with spending more time on any particular step if you really need it, but it can get really easy to lose track of time while looking for the perfect idea or fiddling with the same platform for far too long. Keep the timeline in the back of your mind so that you aren’t surprised by it at the end.

Your team is all set up and you’re ready to come up with a plan. These first hours are critical, and will be a good indication of whether or not your game will be a success or not. So, how do you plan like a pro?

For those of you that aren't familiar with the concept of scope, it just means how big and complex your project is going to be. Scoping is one of the most critical parts of any project, but it's especially true for game jams. One of the biggest killers of any game jam game is having a scope that's too big. Being ambitious is good, but you need to know your limits.

So, how do you scope? The best place to start is by figuring out your MVP.

No, I don’t mean Most Valuable Player. I mean your Minimum Viable Product. This term simply means the most simple basic version of what you want to build. If you have your MVP, you have a game. It might not be a very good looking or well-performing game, but you have a game. That’s more than what some teams finish with.

Set your initial scope with that objective in mind. Break down your ideas into their simplest form that still makes some sense. How quickly can you build that? Is it realistic given the time and resources you have? If you’re not sure, the answer is probably no, so try to go for something smaller and simpler.

Of course, for some of you this is your first game jam, so you might not really know how to do this yet. That’s fine; it comes with practice. My recommendation is just to start as small as you possibly can. For example, in a lot of jams that I've done, my trick is to figure out a simple mechanic that I can build by the end of the first night. I then build that mechanic and if it works and is fun, then we've completed 80% of the jam right there. Everything after that is polish.

To give you some examples, I built the game "You Must Be This Tall to Ride" based on the physics of balancing two bodies one on top of the other. I literally slapped two blocks one on top of the other, connected them, and gave them each a set of controls. We played around with the physics and bingo. Meanwhile, To [ERROR] is [!HUMAN] as a game was just using voice recognition tech to drive a choice narrative.

Don’t just take my games as reference. In the very first jam I did, I sat next to the guys who made Starwhal. All they had for their idea was a pair of floppy characters that could rotate and stab each other in the heart. Starwhal went on to be a very successful party game. The point is, you can make a lot out of a very simple concept, so think small, and build up from there.

As important as scope is to surviving in a game jam, that doesn’t mean you can’t push your boundaries. Actually, game jams are a wonderful place to experiment with new ideas and test things you might not get a chance to try. Game jams are where I learned a lot of things I wouldn’t have learned otherwise. Dynamic sound integration, VR controls, and voice commands to name a few. So to be clear, I’m NOT saying not to experiment. But sometimes, you’ll come up with a cool idea and try it out, only to discover after several hours of hair pulling that it won’t work. It happens, and that’s why you should have a backup plan.

Home Is Where The Hoard Is was a game where you slapped slimes in VR. Simple enough idea. However, we very nearly had to scrap it because I found out early on that I didn’t have the tech necessary to use the Occulus Rift. Fortunately, we figured out a workaround a couple hours in. We were lucky. Don’t rely on being lucky. Rely on being prepared.

Plus who knows, maybe you’ll figure out a creative way to use the resources you have left over from your first idea.

It can be tempting to say that you’re going to pull all-nighters and work crazy hours to get the work done in time. I used to do it all the time. I was always the one that stayed up all night the first night setting everything up and then taking a power naps later. I would do that by sleeping a whole lot just before the jam, and then passing out for all of the next day after the jam.

I don’t recommend doing that. It would completely mess up my sleep schedule, and once I got a 9 to 5 job it didn’t work at all. Plus sometimes it would backfire and I’d just be super sleepy and inefficient for the entire second half of the jam.

Instead, I propose a simple idea: The time spent sleeping and eating ARE part of your scope, so count them in your plan. They’re as important as any other task, if not more so. Normalizing a healthy jam schedule is something we all should do, for everyone’s benefit.

Once you have a general idea of what your game is going to be, it should be pretty easy to figure out what you’ll need. That said, I’ve seen a lot of jammers just jumping directly into building their game with no real plan. Sometimes this can be fine, but I’ve also seen a lot of those same groups realise at some point in the last four hours that they completely forgot something important.

The solution is pretty simple. Make a list. Put it somewhere that the entire team can see and update as they progress. You can do this with a simple document, a project board like Trello, or even with post-its. Even better if you can label them with priorities and other info for additional tracking.

Just like it’s a good idea to have a task list, it’s a good idea to assign responsibilities in the team. For example, I used to do a lot of game jams as part of a team where I was one of two programmers. Often, we would organise ourselves so that I handled everything that was related to the menus and point scoring, while he handled things related to the controls and characters. That way, each of us could work on a backlog without stepping on each other’s toes. Likewise, our two artists on the team would usually split environment art and character art. How you divide the work can be up to your actual team, but setting these divisions helps to ensure that you don’t accidentally duplicate or forget work. Of course, if one of you finishes your side of things, then there’s nothing stopping you from picking off of the other pile.

You’ve got your idea down, you know what you need to do. Now it’s time to actually make your game! You’ve planned everything out, so surely, there’s nothing that can go wrong, right?

Wrong! The very first thing to keep in mind is that if something can go wrong in a game jam, it will. Because game jams are so short and high pressure, mistakes and oversights happen, no matter how much you prepare.

I once did a jam at a camp, and their power supply wasn’t able to handle all the computers set up at the venue, so we had a blackout. Everyone ended up running their computers on portable generators, and our team’s generator broke down several times over the course of the jam. Stuff happens. Sometimes it’s a technical issue. Sometimes it’s a personal one. There’s a lot that can go wrong in just those few hours.

Game jams are stressful. It’s important that you know that going in, and be mentally prepared to handle the unexpected. Sometimes you’ll be able to get through it with some clever solutions or sheer tenacity. Sometimes you won’t, and your team will crash and burn. That’s okay. Game jams are meant to be a learning experience, and you can learn a lot from these failures. Just keep that in mind and don’t get too worked up over it.

Basically, don’t stress. It’s only a game jam.

Speaking of stress, one of the easiest ways to avoid being stressed in the final hours of a jam is to make sure you keep your priorities in order. You wouldn’t believe how many games I’ve seen start with the optional cosmetic stuff and then leave building the actual game for the end. To me, that just seems like a great way to turn your hair white from stress.

When you’re trying to figure out what to work on next from your task list, I recommend using these questions:

  1. Do I need this for the game to function? (i.e. is this part of the MVP?)

  2. Do my teammates need this to do their work? (i.e. Am I blocking someone?)

If the answers to either of these questions is yes, then deal with that first. Doubly so if it’s both. Everything else is fluff, and can be done afterwards when you get to the polish stage.

I’ve seen a lot of game jam participants get really ambitious with how much content they want to make. I’m talking multiple big sprawling levels or a whole bunch of different features and modes.

Something to remember is that the people who will be looking at and judging your game will only be seeing it for a few minutes, and aren’t likely to play it more than once. So chances are, if you make something that has a lot of content, they aren’t going to see it, and as far as they’re concerned, if they don’t see it, it doesn’t exist, no matter how much time you put into it.

Focus your energy on making a vertical slice. That means a small, focused experience that is very deep. A single very pretty and well made level with only a couple really tight mechanics will always beat out several kinda meh levels and a bunch of buggy mechanics.

I said it just a moment ago, but it bears repeating. Game jams are very forward-facing experiences. The vast majority of the time, people aren’t really going to look at how things work behind the scenes or take the time to uncover all the content you made. They’re going to look at what they see right in front of them, interact with that for a few minutes, and then leave. Presentation will often trump substance in a jam. You can use this fact to your advantage.

Is there a volcano in the distant background of your game? Don’t bother modelling the whole thing. Just model the part that they’ll see. Or better yet, get a 2D image and slap some lighting effects on it. There’s a lot of corners you can cut when you realise just how many details people are ignoring. Pour all that extra time you save into the things that are going to be in people’s faces. Prioritise what your audience will actually see, and slap dash everything else. That is the essence of making a good game jam game. It’s what we in the business call “efficiency”.

Efficiency really is the name of the game in game jams, and one very simple and effective way to significantly boost your efficiency is templates. Consider most of the games you’ve seen, and just how many things in those games are basically slightly modified versions of the same thing.

Take for example a classic FPS soldier enemy. Now, say you add four adjustable values: health, speed, attack range, and fire rate. Even if you only had two thresholds for each, you can now make all sorts of different types of enemies. By having a base with a few tweaks, you can make a variety of things, without having to rebuild something from scratch each time. Building a couple templates can allow you to create quite a lot of variety at very little cost.

This logic can be extended to a lot of things, and even across game jams, depending on how much you’re allowed to carry over. For instance, I had built a game menu during one jam, and turned it into a template that I used to set up a whole bunch of other games. It wasn’t anything fancy, but I saved myself a solid hour of building an intro and game over page with basic menu controls. All the games you see here? Same code for the menus. That’s an hour I was able to use on things to actually make the game better.

This should probably be obvious, but unless you’re working solo, game jams are a team sport. You don’t win team sports by having everyone hide in their corners and never interacting with each other. As a team, you need to be in constant communication. Let people know what you’re working on and what you’ll need next from your teammates. Check in on what your teammates are doing so that you’re all on the same page. Ask your teammates for help and get their perspective on what you’re doing. These are all useful interactions you should be doing regularly.

Even if it isn’t directly in service of the game, just chat with each other from time to time. Social interaction builds the bond between your team, and can make your other interactions go more smoothly. Plus it’s a way to manage your stress and have fun. We are social animals, and we work best when we’re interacting with others.

A little detail that can easily be forgotten is that not all of us always use the same standards or words in our work. To give you an example, during one jam I asked one of my teammates to give me some graphical assets and sent him the dimensions I needed for them. A few hours later, I received the images, only to realise that they were severely distorted. We realised the problem pretty quickly: I had been using pixels in my measurements, but he had been using points. This meant that we had to go and revise all of his images to fit properly with our pixel-based resolution. This could have easily been avoided had we made sure we were using the same units of measurement in the first place.

Same goes for language. I’ve worked with a lot of francophones, and I can tell you that there are a lot of terms that don’t translate the way you think. One of my favourite examples is when I received a project-wide mail with this message. In this case it didn’t cause any trouble, but you can see how easily a single word can change the meaning of something.

Is a platform a flat surface you walk on, or is it the hardware you’re running the game on? When you say “running”, do you mean the game is running, or the character? Is HP a measure of your health, a brand of printer, or a delicious brown sauce? Silly as it might seem, try to keep this sort of thing in mind when you communicate with each other.

Something to add for the programmers out there is that the single most easy place to mess up on this front is with your in-game constants and variables. Always try to name your values in a way that makes them easy for everyone to read and understand, not just you. It can save a lot of headache in the long run, and is just good general practice.

In all the chaos of a game jam, it can be really easy to forget about things. That why I suggested you make a list and always stay in communication. You really don’t want surprises near the end of a jam just because everyone forgot about something.

Ideally, you might have someone on your team who is the designated project manager, looking over everyone’s work and making sure that the important tasks are being completed when they need to be. If not, then everyone has a certain responsibility to check up on the task list. Be careful not to fall into the trap of “I thought you were taking care of that”.

Save. Save. SAVE! I can’t count the number of times I’ve seen people in jams despair because they didn’t save and suddenly their computer crashed or something else happened that caused them to lose hours worth of progress. Save often. Make backup saves. Put your stuff in a shared location so that even if your computer dies, someone can download it and continue. Just… Save.

In the vast majority of game jams, there’s a bit at the end where you show your game to other people. It can be judges, fellow participants, or even the general public. Point is, you’re likely going to be showing it off. With that in mind, most jams expect you to do a little presentation, or write a blurb. Most people consider this step an afterthought and neglect it in favour of spending that time on their game. This is a mistake.

Unless you’re a pro improviser (and very very very few people are), it’s a good idea to prepare a little something ahead of time, maybe about half a day before the final deadline. Because game jams put so much emphasis on presentation, this is your opportunity to direct the audience’s attention. Highlight the best parts of your game, and hide or gloss over the broken and unfinished bits. A good presentation will do wonders for how the audience will look at and experience your game, and can make a huge difference, while requiring relatively little effort.

I’m willing to bet that when the jam is over, a lot of you out there are going to talk to your teammates about how your game could actually be really great if you put a bit more work into it and you’ll all agree that you should stay in touch and get back together to finish the job. I can also tell you that about 95% of you will never actually do that, and many of you will never talk to each other again other than to maybe wish each other happy birthday on Facebook every year. I say this from experience. That’s literally what I was doing as I wrote this.

Honestly, there are very few game jam games that are worth revisiting after the jam (there are some, just not many). The people you meet as part of a jam however… Nothing is more important in the video game industry (or any industry, for that matter) as connections, and no connection is stronger than the bond forged by going through trials together. Game jams give you a unique insight into how your teammates work and behave under pressure, and what they’re capable of when they push themselves. That knowledge is invaluable, and likewise, you can show off your skills to your teammates.

Keep track of the people you worked well with and keep their contact info on hand. You’ll never know when they’ll come up again. I’ve personally given referrals to many people I’ve done game jams with, because I know they’re the kind of people that can get the job done. Something to keep in mind.

That’s it! Well, not really. I could probably list a dozen more suggestions, but there’s only so much time and I need to focus on using it efficiently (see what I did there). Hopefully some of these tips will help you in your journey. Most likely you’ll have to learn many of them first hand. But that’s what game jams are for. So, above all, learn, and have fun. If you do that, then no matter the game you put out, every game jam will be a success.

Best of luck!

4 Natural, Healthy Strategies for Preventing Anxiety Attacks, by Sophie Letts

About a month back, I was reached out to by Sophie Letts of https://www.meditationhelp.net/ asking if she could write an article for my blog about anxiety attacks. I’ll admit, hosting someone else’s work on here was never something I really planned to do, but it is true that anxiety is a serious enough issue that warrants being talked about. I’ve seen people in the games industry suffer quite seriously from it, even going so far as to leave their jobs because of it. I’ve even felt it myself from time to time. So with that in mind, I decided why not? After all, if the content of such an article can help people, then all the more reason to share it.

I can’t take any credit for the following article other than hosting it. Sophie put in all the work researching and writing this piece. But I can at least personally attest to the power of proper breathing techniques and regular exercise as being great stress moderators.

One disclaimer I need to note is that this is not official medical advice (I’m a game designer, not a doctor). These tips can help, but if you suffer from anxiety or any similar issues, you should seek professional assistance. Mental health is as important as physical health, if not more so, and there is no shame in consulting with a psychiatrist, therapist, or doctor if you need one. Even if you don’t think you need one, it’s never a bad idea.

Anyway, that’s enough from me. On with the article:

 Photo via Unsplash

Do you ever struggle with anxiety? Perhaps you deal with anxiety attacks from time to time. Anxiety attacks are not always debilitating, but even a mild anxiety attack can set you back. In addition to playing games to help alleviate anxiety, Trichotome Design presents a few techniques you can use to prevent anxiety attacks in the future.

Learn the Signs

Learning which symptoms indicate that you’re about to experience an anxiety attack is a crucial aspect of prevention. For instance, you may notice yourself becoming more irritable and having difficulty concentrating. You may feel physically restless and have muscle tension. You might also find yourself feeling fatigued.

The symptoms of an oncoming anxiety attack will vary for everyone, so you may want to take note of your unique, individual symptoms. Sometimes, anxiety attacks can last for hours or even days, so noting how long yours typically last can also be crucial.

Start Exercising

As Psychology Today explains, exercising can help reduce anxiety. When you work out, you can tune out distractions, leave your worries behind for an hour or so, and occupy your mind with another activity. Furthermore, exercise releases endorphins, which will boost your mood. The key is exercising on a regular basis, which requires a certain level of motivation. One way to stay motivated is by listening to your favorite upbeat tunes or inspirational podcast. Invest in a quality set of headphones or earbuds -- preferably noise-canceling models -- to optimize the audio.

Wearing a fitness tracker or smartwatch when you exercise isn’t mandatory, but it can be a useful tool that helps you track your practice and keeps you safe while exercising. For example, some smartwatches have functions like electrocardiogram generation and blood oxygen sensors. By gaining a deeper understanding of your vital signs, you can figure out when you’re experiencing an anxiety attack and differentiate these symptoms from physical conditions like cardiac problems.

Create a Calm Environment

Sometimes, your environment can bring on an anxiety attack. At your workplace, for example, stress can be caused if you’re harboring resentment or dislike towards your boss, or there’s conflict with a toxic coworker.

You can’t always control your environment, but you can take steps to make your own home a calming and inviting space. Perhaps your family members have a tendency to complain, argue, or be overly critical, which can contribute to your anxiety attacks. It’s time to inject some positivity into your home by decluttering, deep cleaning, and opening up the windows to let the breeze in. Furthermore, you can even paint your walls in calming colors. If you’re in search of hues that can help reduce stress, Decorist recommends lavender, soft pinks, or blues. You might also want to purchase an essential oils diffuser if you’re interested in aromatherapy.

Practice Deep Breathing

What if you’re in public, feel an anxiety attack coming on, and can’t leave to go somewhere else and calm down? In scenarios like this, you can practice deep breathing exercises to relax and regain your composure. Verywell Mind suggests trying simply breathing from your abdomen rather than your chest.

When you’re anxious, you can follow a few simple steps to bring down your stress levels and think clearly. Inhale deeply through your nose, exhale slowly through your mouth, and continue breathing this way for a few minutes until you begin feeling better. It may feel a little bit awkward at first, but this technique is quite effective. 

Dealing with anxiety attacks can be challenging, but anxiety does not have to run your life. When you can anticipate your anxiety attacks and learn how to soothe yourself, you’ll find that eventually, it will no longer interrupt your daily routines. Everyone will experience nervousness from time to time, but you can find a way to manage your anxiety.

Learnathon 21: So You Want to Be a Game Designer

I was contacted a few months back by Kurius to do a talk for their Learnathon event. I’d be talking to students about game design. I thought it was a really cool initiative, so I asked and got the go ahead from Ubisoft (I work there now by the way; it’s been so long since my last blog update that I’ve changed studios once and projects twice).

Figuring out a topic was the hard part. After all, back when I was in high school I barely even knew what game design was before I dove right into university for it. In the end, I took my own experience as the main reference for what to talk about. This is a compilation of the basics about game design. The harsh reality that it’s as much a profession as any other job. That it’s not something you can do as a lone wolf. What kind of work a game designer is actually expected to do on a day to day basis. I took all the things I learned outside of school (besides, why would I talk about what you do learn in school; you can go to school for that) and tried to cram it all into an hour and a half, with the help of a few memes because that’s how I do. This presentation you see here was the result.

As of me writing this, I’ll be presenting in about an hour, so I’m going to try and copy down my transcript and slide images quickly so that anyone that watched the presentation can find this page right after, just in case they want to read what I said instead of listen to a recording.

As for any questions, I’ll see if I can remember to put another entry about that some other time, along with my long overdue update and various other articles I’ve been meaning to post here for the last year or so.

EDIT: Now with a video of the recording, in case you want to hear me say “euh” a lot.

Alright, so let’s say for the sake of argument that you’re interested in becoming a game designer. In that case, how might this talk help you? What’s it all about?

Well, the first thing I’m going to do is crush all your dreams, obviously! Okay, not really, but I am hoping I might dispel a few myths about game designers. I know that to a lot of people, game design seems like it could be a dream job, and it absolutely can be! But it is still a job, with work, responsibilities, and challenges.

What I’d like to do today is talk about the realities of game design as a profession, so that you can see if it really is something you’d be interested in, and if so where to go from there. This is stuff I didn’t learn from a classroom, but looking back at it now, that I wish I had known about when I first started out. Hopefully you’ll find it useful!

I’ll be covering some pretty broad topics like “What is a game designer?”, “What do we do?”, “What are all the different types of game designers?” (because yes, there’s more than one), “What is the game design process?”, and also a few things you might now know about what we do and even a few suggestions to get you on your way.

So then, before we dive right into things, you might be wondering, who even is this guy, and why should I listen to him?

Hi, my name’s Justin, and I’m a game designer. I studied Interactive Multimedia and Design at Carleton University and Algonquin College in Ottawa. It’s a course that covers a whole bunch of digital media stuff like games, web, film, animation. Later on I also did a DESS (that’s a Diploma of Advanced Studies) in Game Design at the University of Montreal.

In terms of professional experience, I’ve spent about 5 years in the indie games scene, working on a bunch of games you’ve never heard of. That’s not me trying to get hipster cred by the way. Sadly it’s because most of those projects died before they ever came out. Funny thing about indie is that for every success like Minecraft or Cuphead, there are thousands of games that don’t succeed or never even see the light of day. That logo is for Forged Interactive, which is the only indie studio I was in that got far enough to have a social media presence, and unfortunately they never actually released the title I worked on with them.

Eventually though, I broke into the big leagues of mobile games. I started off doing some testing work, mostly testing levels of King games like Candy Crush and Blossom Blast. Then I was hired full time at Gameloft, first as a technical game designer and then later on as a game economy / systems designer. I was with them for about three years, until late last year.

Now I’m at Ubisoft, working on AAA titles. I started with Hyper Scape, and now I’m on this little very obscure game called Rainbow Six Siege. So you could say between indie, mobile, and AAA, I’ve got experience in all three categories of games.

Oh, and on the side I’ve also done a ton of game jams and tabletop gaming. I didn’t get paid for those, but I like to think the experience still counts.

I hope that was enough to convince you that I might actually know what I’m talking about, at least a little bit.

Okay, let’s start with the first big question. “What is a game designer?”

Now, you might have heard or even thought of some of these lines before. I’ve certainly heard variants of all of them, sometimes even from my coworkers in the industry.

These are, of course, all wrong… Kinda. Like with everything, it’s complicated. I’ll try and break these down a bit.

First off, yes, designers do come up with ideas, but we’re far from the only person on the team that does that, and it’s far from the only thing we do. It’s a bit like saying a student is “the homework guy”. There’s a bit more to being a student than just doing homework, even if sometimes it really does feel that way.

Next, that creative director comment. You probably don’t hear it said like this, but maybe at some point you’ve thought of something like “I wanna be the next Hideo Kojima, or Sid Meyer, or Shigeru Miyamoto, and make my own franchise!” A lot of aspiring game designers think like that (I’ve done it too, to be honest). It’s a common dream to be the person that creates the next big title all on their own and to be remembered as “the Metal Gear Solid guy” or “the guy who made Super Mario”.

The reality is that while creative directors can definitely be a big influence on a game, saying it’s their creation oversimplifies things. Games are rarely a one-person project, and in reality a creative director is more like a navigator. They determine a direction of where they want the game to go, and they try to make sure that everyone works towards going in that direction. They aren’t usually the one that figures out the how, and that’s a huge part of what makes games what they are. Behind every great creative director, there’s an equally great if not greater team backing them up.

So in that case, surely that last point is true, right? That we tell everyone else what to do? Well, sadly that’s wrong too. Believe me, I’d love to be able to just decide things and have everyone follow my commands. It would make my life so much easier! But no, sooner or later a programmer or artist or director will come around and slap you with the cold hard fish of reality, and trust me, that thing can sting!

Most of the time, game design is more like a negotiation. On the one side, we need to talk to the technical people like programmers and artists to see if our idea can be made and what it’ll take to make it work. Then on the other we need to talk to producers and directors to convince them that our ideas are worth trying to make work. Unless you succeed on both fronts, you’re going to have to go back to the drawing board.

Alright then, so what actually is a game designer then?

They are a miserable little pile of solutions. Boy I hope some of you get that reference because it’s old, even by my standards!

What I mean is, at our core we game designers are problem solvers. Our job is to find or take a “problem”, figure out the best possible solution for it that everyone on the team can agree on, and then help everyone to understand, build, and promote that solution.

For the record when I say “problem”, that can cover a wide variety of things. For example, “I want a class-based competitive first person shooter that is unique from other games in this category”, “I want the movement in this game to be more fun”, or “I want a feature that will make people want to spend more money in the game” would all be “problems” that a game designer might be tasked with solving.

Another comparison I like to use to help people understand is that a game designer is kind of like an architect. They don’t decide where the building will be or what it will be used for, and they don’t build or paint it themselves. Their job is to write up the plans everyone else is going to follow, and make sure that whatever they drew isn’t going to collapse.

So you may have noticed that my definition of a game designer is really vague. There’s a lot of ways to solve a problem after all. It’s almost like calling someone an adventurer. If you’ve played an RPG or watched an anime in the last five years, you know that there’s no universal rule for what an adventurer is or what they can do. Rogues, Wizards, and Fighters can all be types of adventurers, but you’d hardly say they’re the same thing. If you’ve played these types of games, you also know that it’s usually better to pick one or two classes and stick with them, rather than dip a tiny bit into twenty different classes. The same is true for game designers.

There are many different specialisations in game design, each of which focuses on different aspects of a game. While it might be a while still before you need to pick a specialisation for yourself, it’s not a bad idea to keep them in the back of your mind as you build up your skills, as this can be a big help towards getting you that unique edge over other people looking to get into the industry. That’s because the sad truth of the matter is that generalist game designers have a much harder time getting a job, at least in the bigger studios.

I’m actually a good example of this. At first, I had a lot of trouble finding a job as a game designer. But then I made one little change and literally within a couple months I got my first job offer from Gameloft. That change was me swapping my portfolio title to from “Game Designer” to “Technical Game Designer”. The crazy thing is that I didn’t even change my skill list! I just changed the label I used to highlight things that I could do that other generalist “game designers” couldn’t. Namely, that I had some decent programming ability.

Let’s break down some of the specialisations in game design. Please bear in mind that this isn’t a complete list. It’s also not universal. A lot of studios use different names for these roles, or there’ll be hybrid roles that are a mix of these. There aren’t really any standards in the industry as far as these go. This is because the industry takes great pleasure in frustrating you and themselves. Still, it should give you a rough idea of the available specialities.

Gameplay designers are probably what most of you think of when you think of a game designer. They’re the people that come up with the rules for how a game is played. That’s stuff like win and lose conditions, the gameplay mechanics and inputs, etc. Their focus is on what’s called the “Action Phase” of the game, which is the part of a game where the action happens.

Systems designers are a slightly more obscure type of designer by comparison, but also essential to how a game works. Like gameplay designers, they also define the rules of the game, but their focus is on how everything goes together. For example, in an RPG a gameplay designer might handle combat, but a systems designer would figure out stuff like levelling, items, and how those things all link with each other. They’re kind of like “big picture” designers that look at how all the gears fit to make the engine run.

These whiteboards are actually snapshots of some of my previous work as a systems designer. Sometimes, things can look really messy before they start to make sense...

3C designers are responsible for the 3Cs. That stands for Character, Controls, and Camera. Basically, they are the ones that handle the player character and how they move and interact with the world. They don’t often get as much recognition as other designers, but their impact is critical to making a game “feel” good, which is a lot harder than it sounds. 3Cs is why parkour in Assassin’s Creed and Mirror’s Edge feel completely different, or why you’d never compare Doom and Call of Duty, even though they’re both technically FPS games.

Level designers are probably one of the other most famous types of designers. If you’ve played games, you probably know what a level is, and if you know that, you probably have a good idea of what a level designer does. They’re the ones that figure out the layout of the maps and what will be inside of them. These designers tend to be more artistic or visually-minded, and will usually work closely with the art team, but they also need a good sense of space and pacing to go along with that aesthetic.

Technical game designers are like a bridge between designers and programmers. They’re usually responsible for backend stuff like creating tools for other designers or figuring out how the game’s data is managed. Having a good understanding of either programming or database management is very useful for these types of designers. It’s also one of the easier designer roles to get as an entry-level position because it will often involve a lot of grunt work and isn’t very creative or glamorous. For example if you’ve played a game with a lot of different items with unique stats, a TGD was probably the one responsible for listing all of them out in a table. Despite its reputation, technical game designer is a very important role, and it can help you learn a lot about how games are made.

Game economy designers are the people that deal with numbers and balancing. That can include scoring, damage, health, how often you get and use resources… Anything with a number, really. If you’re a fan of resource management games or making spreadsheets, then this role might be for you! It’s a tough and sometimes tedious job, but it’s also one that’s almost always in high demand.

The GED role often gets merged with systems design (like I was at Gameloft), but in bigger studios they’ll usually be their own specialisation. Also, sometimes GEDs are instead focused on the monetisation side of things. In those cases, their responsibilities shift a bit more into subjects like when and where to try and sell you stuff and how much stuff you get for your money. In those cases, they’re the ones that handle how things like battle passes and loot boxes. I know some of you might hate them already for that, but they’re in the difficult position of making sure that the game they’re working on makes a profit. If they don’t succeed, then the game will probably get killed. They have the unenviable task of designing features that make enough money to keep the higher ups happy while also being balanced and fun, and that’s not easy to do!

Finally, we have narrative designers. Their role is a little more complex than just writing the story. Rather, they have to come up with how that story is delivered to the player and how the story will interact with the player. They are the person that brings the world of the game to life. Any writer can throw a wall of pretty text at you, but a good narrative designer will make sure that you experience the story.

If you’ve played a narrative heavy game like Undertale, Doki-Doki Literature Club, Spec Ops the Line, or Mass Effect, you know what I mean when I say that narrative design can go a lot deeper than just writing. Those are all games that make the narrative design a fundamental part of their identity.

Besides this list, there are some other roles worth mentioning within the design sphere. These aren’t game designers per se, but they do either work very closely with them, or have very similar responsibilities or job descriptions.

UI and UX designers handle how the game looks and feels. While these two roles usually end up focusing on the menus and HUDs, their job can extend through the entire game, especially for UX.

You might have heard these terms before, and very often they get used interchangeably. There is however a difference. UI (user interface) is more focused on the appearance of things. They handle things like colour, fonts, visual effects, and the like. UX (user experience) meanwhile focuses on flow and feel. They might be responsible for what menus lead to where and how things behave when you interact with them. UI is more of an art discipline, while UX is closer to design, but both usually have their own independent department in bigger studios.

Sound design is a lot like UX in that it’s a design role that is often separated from other designers. Some of you might think that a sound designer is the person that makes the music and sound effects for the game, but usually you’ll get a composer and foley artists to handle those things. A sound designer’s job is more about how and when those sounds show up in the game. In a lot of ways, their work is similar to that of an animator, since a lot of it is about defining the moments and actions that trigger certain sounds.

One example of a more creative sound design mechanic can be found in Nier Automata’s hacking minigame. The fight music seamlessly transitions between the normal version and the 8-bit version whenever you start a hack. There’s some cool tech that makes that happen, and that’s the sort of thing a sound designer might be involved in coming up with.

Lead designer is kind of a weird title. It’s not really a type of designer in and of itself, but rather an indication of seniority or authority for a designer. In other words, a lead designer is usually the designer on a team with the most experience, and will oversee the other designers to make sure their work is good or fits together with the work of other designers on the team. Depending on the project, they can be more like a manager, and sometimes, they’re more like that one person that presents the group project on behalf of the rest of the team.

Product managers (also called producers depending on the studio) are the people that handle most of the resources on the team, very much like what a producer does in the film industry. They’re the ones that make the budgets, task lists, and schedules. They figure out who the team needs to talk to to get things done, plan meetings… As you can imagine, this is very much a managerial role, but they work hand in hand with designers to push ideas and make sure that the team has everything they need to actually turn those ideas into a game. In a way, a lot of their process is very similar to how a designer works. They just think about the people and the process, instead of product.

Product owners are people a step above designers when it comes to the hierarchy of decision making for a game. You usually have several of them on a game, and it’s a title that goes on top of some other leadership role. Creative directors, lead designers, heads of departments, and in some cases even the studio head can all be product owners. They’re usually the ones that define the problem that the designer must offer solutions for, and they’ll be the judge for whether the designer is on the right track or not with their solution. They are the council that will decide your fate.

In other words, as a designer, product owners are the people you need to convince that your designs are worth actually building. This can get extra fun if you have multiple product owners that represent different interests, and you have to find something that satisfies all of them. It can become quite a game of politics!

Last but not least, technical writers. They’re the people who keep all the project’s documentation up to date, especially when the designers aren’t doing it themselves (which is often; a lot of designers hate writing their own documentation, even if they should be doing it). Usually this means they’ll have to talk to designers and programmers to get all the details on how absolutely everything works, and then write it all down somewhere so that everyone else can read and understand it. They’re the people that make user guides and instruction manuals for the devs. By the way if you’re wondering where it all gets stored, most of the big studios use internal sites that are basically like private wikis. Confluence is a pretty commonly used tool for our documentation, for example.

Technical writing involves a lot of the same responsibilities as a game designer. The only difference really is that they listen and record, but don’t present the ideas themselves. It’s a great job to start with if you want a taste of what the more technical aspects of game design, right up there with game tester. Tech writers are also usually the people who are the most knowledgeable about how a game works. Turns out when your job is to collect and explain information about a subject, you can get a pretty good grasp of that subject.

That was a lot of different roles, and they do cover a lot of different aspects of making a game, but there are some things that all game designers do have in common. If you’re interested in game design in general, there are a few things you ought to know. Here’s the most critical stuff that every designer needs to be able to do.

  • Brainstorming: You’ll have to come up with a whole lot of different ideas

  • Goal-Orientation: Having many ideas is great, but do the ideas you have actually satisfy the objectives you’re trying to achieve?

  • Extrapolation: That means fleshing out an idea. What you thought of might sound cool, but how would it work?

  • Scoping: You have to be realistic about what you can do with the time and resources you have; many games have failed simply because they were too ambitious!

  • Organisation: At some point you’re going to have to put all of your thoughts together in a way that makes sense, and that takes some serious organisational skills.

  • Documentation: As a designer you’ll spend more time in programs like Word, Excel, and Powerpoint than in the game engine

  • Reading Data: These days nearly every game has analytics, and part of a designer’s job is to read all those graphs and tables and understand what they mean, so don’t skip your statistics class

  • Explaining: All that pretty documentation won’t mean much if no one understands what you’re trying to say

  • Debating: At some point, your ideas might get challenged, and you’re going to have to convince them that they’re good

  • Taking Feedback: That said, you also need to know when to take feedback in good faith and use it to improve your ideas

  • Communication: An extension of all of that is that you’re going to be talking to people from all sorts of disciplines, and you’ll need to be able to listen and understand them, as well as be able to get your points across to them. That means learning the lingo and knowing how people think. Fundamentally, designer’s need to know how to be social, whether they like it or not.

It’s a lot of stuff, I know. Most of them are soft skills too, which means you can’t really learn them from a textbook or instructional videos. It takes a lot of practice and just a bit of intuition to get it right.

Because designers are at the center of so much of the game design process, they also kind of have to exude a certain sense of control over everything. To the outside perspective, we definitely try to at least look like we’re bastions of knowledge and certainty. In practice though? It’s kind of a mess and more often than not we’re going just a little bit insane. It’s a lot harder than it looks, you know! Be warned: game design is not a job for the faint of heart, but the satisfaction you get when you actually see your work in the hands of players genuinely makes it all worth it!

I’ve often been asked what the game design progress is like. Usually it’s by people that are looking for a step-by-step guide to making a game. If that’s what you’re looking for, I’m afraid I’ve got some bad news: there isn’t one!

Or at least, there isn’t a universal one. The design methods used change from person to person and studio to studio, and they can end up being quite different. There are tools, tricks, and methodologies out there that can certainly be very useful, and if you go to school for design you’ll learn about a lot of them, but at the end of the day it’s up to you to figure out what works best for you and your team. Sometimes team members or studios will require certain things from you, like a pitch, or a creative brief, or a game design document, but there aren’t really universal formats for these either. In these cases, what matters is that you figure out what the requirements are, and then include those thing in your submission. How you get there is pretty much up to you, or maybe your immediate supervisor. In that sense, it’s very similar to doing school projects, except you’re talking about making video games, so it’s extra cool!

That said, it would be a shame for me to not give you something, so here’s a rough outline of the overall game development process at a big studio and what a designer would be doing at each step (told through the medium of cringey memes):

Pre-Planning: The product owners give you a problem or challenge, or as it’s usually called, a mandate. Basically “hey, we want you to make a game for this audience” or, “we need you to design a feature to accomplish this goal”.

Brainstorming: Once you’ve got that mandate, you start brainstorming. This means coming up with a bunch of questions and ideas surrounding that mandate. What does the target audience like? How do other games solve this problem? How big should it be? Could we use this thing from this other feature? Wouldn’t it be cool if it also did this?

Research: Eventually, you start answering the questions from brainstorming and filtering those thoughts into something that starts resembling an actual design. This is typically when you start talking to the people that will eventually need to help you build it and try to figure out if what you’re thinking actually makes sense. Just be careful; you’re researching, not trying to sell them the idea just yet! A lot of people can misunderstand that and that’s where you can get into some messy miscommunications that can bit you in the butt later on.

Pitch: Once you’ve got all your info together, you can start being a bit more precise about what your design is and isn’t, and why it’s cool and satisfied the mandate. This is the start of the pitch phase. This is when the real documentation work starts. General word of advice here; pitches should always be short and to the point. Outside of school, nobody wants to read a report for an idea, no matter how pretty you make it.

Approval: Now you start showing the design to people as a fleshed out idea and start suggesting that this is what you could build. Some studios have formal “gates” where you have to present your ideas to the product owners, who will give feedback and decide whether or not to approve the design. In bigger studios, this can take several iterations of them giving you feedback and you having to tweak your design until they’re happy.

Prototype: Once the design is approved, you can start building a prototype, which is a barebones or mini version of the idea used to test things out. This is where you see if the idea you had actually holds up or not. If not, you might need to go all the way back to brainstorming and try again.

Iteration: From this point on, the process is usually just the team building a bunch of bigger and more detailed versions of the design, while you watch over it and make sure everything makes sense. Sometimes you’ll spot flaws later on and have to figure out corrections. All the while you’ll likely have to also give progress reports to the higher ups to make sure they still believe in what you’re doing. Sometimes you might release a prototype to the public before you reach the finished product. That’s what early access, beta builds, and test servers are. It’s the devs checking to see if the thing actually works when you put it in the hands of players.

Release: Eventually, you end up with the completed game or feature, and you can put it out! This can be a super exciting but also stressful time for the dev team, since players will always find issues you never even thought to check for. Rarely, features and games can get recalled or killed even at this stage if the problems are bad enough, but if that happens it’s a BIG problem and lots of important people start getting involved…

Post-Launch: Ideally everything goes well, you launch the design for real, and you start getting feedback. That comes in the form of reviews, comments, but also data, and I don’t just mean sales figures. These days we can learn all sorts of things, like how many times a player has done a certain action, or how long it takes players on average to reach a level. So long as we have a way to measure it, we can use it to figure out what we might need to tweak to improve it in a patch or update.

This step can be repeated as much as is necessary, until we’re happy or we’ve done all we reasonably can. These days the concept of “live service games” is pretty much the standard, so it’s not unusual for a designer to work on a single feature over multiple years.

And that’s it! You either keep making updates to the design, or you start working on a new game or feature, and the cycle begins anew!

I like crushing expectations, so here are a few other things about designers that people get wrong all the time.

“The best way to become a game designer is to-” Let me stop you right there. Back when I was a student, I spent a lot of time talking to designers and people in the industry to figure out what the best way to get in would be. You know what I found out? Literally nobody takes the same path, least of all for game design. Some people get promoted from QA (testing) departments. Some go to school for it. Some people do cool stuff like create mods or give suggestions on Twitter and get noticed. Some people just meet and talk to exactly the right people at exactly the right time. There’s no wrong answer for how to get into game design.

“All game designers have the same skills/background.” Hopefully by this point I’ve debunked this for you all. There are definitely some common elements, but one of the coolest things about game designers is that we are so different. Beyond just types of designers, every designer has their own approach to challenges that is uniquely theirs, and that’s what allows us to create so many wildly different games.

“Why didn’t they think of…” At some point or another, I’m sure all of you have thought “if they just did this one thing the game would have been so much better! Why didn’t the designers think of it?” Here’s the thing about that: we probably already did think of it, and there’s probably a reason we haven’t done it.

More often than not, if you see a good idea posted somewhere and everyone agrees that it’s a good idea, the situation inside the studio is one of the following:

  1. We also agree, and are already working on it, but we just aren’t ready to show it yet because making a game can take a lot of time, especially in AAA.

  2. We agree, but there’s some reason outside of our control that prevents us from doing it. Sometimes it’s a licensing restriction. Sometimes it’s that we just don’t have the resources or tech to support it. Sometimes it just doesn’t work with something else that we’re working on… There’s a lot of things that can block a design that the average player would never be aware of.

That isn’t to say this is always the case. Sometimes the community will come out with a cool idea that the designers didn’t think of. It’s extremely rare though.

“If that’s the case though, why don’t we just tell you about it? Things would be so much better if studios were transparent with their audiences!” This one is a little tricky, because to a big extent I personally agree. That said, there are some very valid reasons for why a studio might not want its developers talking openly to the public.

Designing games involves a lot of moving parts, and sometimes, being too open about subjects can bite us in the butt later on. That’s even more true in the case of big games with a lot of devoted fans. Talking about a feature before it’s been approved can result in false expectations. Exposing details about a partnership can hurt both the studio and the partner company, which can damage their relationship moving forward. Sometimes it’s as simple as developers just not really knowing how to talk to the public properly. Basically, there’s a lot that can go wrong if we reveal too much, so studios tend to be very careful about what we’re allowed to say. It’s why most studios these days have people or even entire departments devoted to community management and developer communications.

Honestly, not blurting all of those secrets is probably the single hardest part of my job, because there’s a lot of stuff I’d be excited to talk about! But it’s important to remember that doing so without caution can cause trouble for myself and my co-workers, and that’s the last thing I want.

Maybe, just maybe, I haven’t scared all of you off, and some of you are still genuinely interested in pursuing a career in game design. If so, great! Here’s a few tips that might help you on your way. Actually, most of these should help regardless of what part of games you’re looking to get into. If you’re interested in a more detailed list, I did write one a few years back on my blog I’ll be sure to share it somewhere for you all.

Okay, first tip: networking! The games industry is very small and very social. People move around between studios very often, so a lot of us know at least a few people in various different studios. This is especially true for designers, since we talk with a bunch of different people on any project. Word travels fast, so building a good reputation with anyone in the industry can really help to get you places. Likewise, people with bad attitudes can get blacklisted just as quickly, so don’t assume that you can act a fool at one studio without it coming back to bite you somewhere else.

Ask for guidance, not jobs! A lot of people in the games industry are really passionate about their work and will totally be willing to help you out on your way to joining us. That said, you need to come at it the right way. A lot of us get approached by people asking for a job or a recommendation. The thing is that most of us aren’t really cool with recommending someone we’ve never personally worked with. What many of us are willing to do though is give you tips on how to develop your skills further or to just give you some insight on how things in the industry actually work. Your best bet is to invite us for coffee or sit in on a chat with us at a networking party and just pick our brains. You might not get a referral, but you can get some useful knowledge and make a good impression that can help you out later.

Don’t be too picky about your opportunities! Some of you might be thinking “Mobile games? Ew!” or “I only want to work for a company that’s made a game that I personally play”. I totally get it. I admit when I started working on Siege I bragged about it like crazy, because people actually knew the game I was working on! It’s a great feeling!

But here’s the thing, in the games industry, experience is everything. Even more than education, at least as far as hiring goes. Just the fact of having worked on a game before makes you much more attractive to employers. So with that in mind, don’t worry about your first couple jobs not being exactly the kind of thing you want to work on. It’s extremely rare to get your dream job right off the bat. Instead, take the opportunities that will help you grow, and build yourself up from there. Eventually, you’ll find that ideal opportunity!

To give you an example, back when I was in school a lot of my classmates absolutely refused to work in the mobile industry because they only wanted to work in AAA. I was a little less picky, and started in mobile. Now I work on a AAA game, and most of those other people sadly never got their big break.

Broaden your horizons! The best designers are the ones that have tried a lot of different things. So play games you like. Play games you hate. Do things that aren’t video games! Read some books! Go outside! Learn some new skills! See different places! The more experiences you can draw from, the bigger your designer toolbox. The bigger your toolbox, the more potential you have as a designer.

Try, fail, learn! You might have heard this line before: “fail early, and fail often”. What they mean by that is that you’re going to end up making a lot of mistakes or coming out with things that turn out to be junk. That’s normal, and actually a really important step to being a designer! The most important part of that process is to think about those mistakes in a constructive way. Figure out why you failed. What worked and what didn’t? What can you do next time to solve those problems? The more of this you do, the better you’ll do next time. It’s not about the failure itself, but building yourself up from those failures. Really, this is just good life advice in general!

I’ll leave you with a little self indulgent quote that I feel encapsulates a lot of my experience as a game designer. “The definition of insanity is doing something over and over again and expecting different results. But what do you call it when you do something over and over again and you get different results? That’s game design!”

That’s my introduction to game design for you! I hope this was helpful to you and you learned something, besides the fact that I’m into trash memes. Thank you all for listening, and thanks for Kurius for hosting this!

Getting Hired: My Best Tips

It’s been a little over a year since I was hired at Gameloft, and since then I’ve gone from being an intern to being a full time employee and even getting an extra job title (I’m now a Technical Game Designer and a Game Economy Designer on my project). I’ve been meaning to write this article for almost as long (if not longer, truth be told), though I keep either forgetting or being otherwise too preoccupied. But, seeing as I’m just coming down from all the rambling I’ve been doing at MIGS to young folks about these very topics, this seems like a good time to finally crank this piece out.

Over the several years I’ve spent hunting for a job, I’ve had plenty of ups and downs, but most importantly I learned a lot. Aside from luck and a bit of skill, most of my success can probably be attributed to learning through iteration. With this article, I’m hoping to condense a bit of that into what I think are the most valuable and practical tricks I’ve acquired over the years. I’d like to think they’re universal enough that they can be applied not just to getting a job in game design, but pretty much any job. Hopefully, some of you reading this might learn a thing or two from my mistakes (I saved the best ones for near the end, but they aren’t the last ones so you can’t cheat).

Study Your Field

To be clear, I don’t mean go to school. Of course, school can be immensely helpful. If your field of interest does have specialised studies designed to help give you the necessary skills to get into the industry, absolutely look into that. A lot of companies will use your base level of education not just as a metric of your skill, but also as an indication that you’re actually able to put in the effort and finish something (being able to finish things is a good mark for a lot of employers, so keep that one in mind). But no, that’s not what I’m talking about when I’m referring to studying your field.

What I actually mean is you need to study the actual industry surrounding your field. Do everything in your power to learn how your field works. What are some typical business structures? Who are the big names? What does each position do? What are some common problems facing the industry and what are people trying to do to address them? These are all questions you need to ask. But more importantly, you need to ask them not from a consumer or layman’s point of view. You need to think of it the way an insider does. After all, you’re planning on becoming one.

Games are a great example of an industry where a lot of the consumers seem to think they know how the industry works. Allow me to disabuse you of that notion: most gamers have no idea how games are actually made. Certainly not from a professional business perspective. It’s not just a question of dumping a few assets into Unity and bam there you go.

Now don’t get me wrong: I’m not saying gamers are completely ignorant, nor that game developers and publishers are blameless or not deserving of scrutiny. Game devs make mistakes and poor choices quite often, and when they do something that hurts consumers they should absolutely be called out for it. What I’m saying is, the choices they make aren’t arbitrary, and they’re often far less simplistic than you might think. Like any other industry games are fraught with politics, business statistics, technical limitations, human limitations, and the unfortunate realities of, well, the real world. Working on games is a career, and not an easy one. There are many people in this industry who work very hard, even on things that might turn out to be viewed as complete trash. Often times, there are deeper reasons for that trash turning out as it did.

Figure out those reasons. Start understanding why your industry of choice works the way it does. Many industries have plenty of resources that you can dive into and research. Just doing that will immediately put you a step ahead the common schmuck who thinks they knows better than the professional despite having no experience because they’re just that smart. I can guarantee you 9 times out of 10, they’re not, and everyone in the industry can spot those people from a mile away.

Allow me to give a quick example. Do you remember Assassin’s Creed Unity? That game that was buggy to the point of being ridiculed online? A big part of why that is is because the game needed to be rebuilt from the ground up using a new engine, because the old one wasn’t able to support the co-op tech they tried adding with that installment. The engine, being new, didn’t work the same way the old one did for a lot of stuff, so a lot of things that people were used to doing had to be re-learned differently. When an entire massive crew of devs are simultaneously trying to recreate something in a new tool... Well, have you ever tried writing your name with your non-dominant hand? Yeah, it’s kinda like that, but with several thousand people trying to do it on the same piece of paper. Anyway, that’s a grossly simplified representation of what happened and there were certainly many other deeper factors at play, but it might help you understand why this would be a sore spot for a lot of the people who worked on that game. It’s not an excuse by any means, but saying that the game was bad because the team was lazy would just be insulting. I don’t recommend insulting people you want to work with.

Go Where The Pros Go And Do As The Pros Do

Ideally by this point, you know the basics of what you’d need to get into your industry, and you’re just about ready to join it yourself. Well, this is when networking becomes important. There are two big tips I can offer when it comes to networking. The first one has to do with how to find the right people to network with.

This really isn’t that hard: figure out where the industry professionals meet up, and go there. Many industries have meetups and networking socials. These are meant to be places for industry professionals to get together, make connections, share their knowledge and experience with each other, and maybe even have some fun. Often times, it’s not that hard to join in on these. Look into societies, organisations, and events meant to represent these industries and go to them (for example, video games in Montreal have La Guilde, the IGDA, MIGS, MEGA, CGX, GANG de Devs, and Alliance Numérique, just to name a few). There are resources out there for pretty much every industry, and you should in no way be shy about looking into them. Also, if there are after-parties at events, go there then try to figure out where the after-after-party is (that’s the one all the professionals go to to escape the kids looking for jobs; it’s the MUCH more interesting party).

Now that said, there is a certain code of etiquette that should be respected when it comes to going to these semi-exclusive venues. Keep in mind that when you’re at these events, you’re not there to hunt for a job. That’s what recruitment drives are for, and that’s not why these professionals are there (in fact they’re trying to avoid that). No, you’re here to make business connections, and to absorb as much knowledge as you can. See what these people talk about. You can admit to not being employed in the industry (yet/at the moment), but that shouldn’t be why you’re there. Instead, use this time to get an insider finger on the pulse of the industry. You can even relay some of your own experiences if they’re relevant to impress some people.

If you can act like you’re a professional, soon enough everyone will take it for granted that you are one, and you’d be surprised how friendly and open people can get with their fellow industry-members. This is more of an aside, but I once saw the lead designer of a major studio demonstrate the proper technique for slapping to another industry pro, using the CEO of a decent-sized development studio as his demonstration dummy (all of them were consenting and pretty drunk at the time). On another occasion I heard another big name rant about all sorts of problems that he had with the internal structure of a very big studio (and learned a lot about their corporate structure in the process).

The point is, even if you’re just schmoozing, this is a great way to make connections early that will help you later on. And in some cases, you can end up with some interesting stories (just don’t share names when it comes to the compromising stuff; that will blacklist you fast).

Getting Into The Circle

Okay, so you’re in a place with a lot of potential people to network with, but you’re shy and awkward. Unfortunately to some degree, you’re just going to have to get over that. You won’t accomplish anything huddled up in a corner pretending to stare at your phone (trust me, I’ve done it enough to know). Fortunately for you, there’s a pretty good trick I’ve used time and again to help with this.

To start, you need to just insert yourself into conversation circles. You will find this phenomenon at all major social events: a bunch of people form a little circle where they talk to each other. All you need to do is slide right on into that circle. Find a gap and occupy it, until people gradually make a bit of space for you and you become a part of the circle. It can be awkward at first, but often times someone will take the initiative and introduce themselves. If you can manage to do it, even better. Ideally, try and contribute something relevant to whatever they were discussing. This can be as simple as asking a question or agreeing with someone’s point (though it’s best if you add something in yourself too). Just make sure that whatever you’re adding to the conversation is pertinent. If you do this a few times, you’re bound to end up getting into a conversation with some reasonably outgoing person. If you can, try to remember their names and what they do and/or what you talked about (this isn’t necessary, but helps a great deal). Generally, if they shook your hand and asked your name, you’re good to go.

Now, the next time you go to an event, find one of those people you spoke with last time. Wait until they’re in a new social circle with some other people you haven’t met, then gently slide yourself in and greet the person you know. This is now the perfect opportunity for you to introduce yourself to the people they’re with (or for them to introduce you, if you’re lucky). Congratulations, you now have more people you can find in other circles next time! Rinse and repeat, and soon enough you’ll have a whole bunch of people in your network scattered about. Even if not all of them know your name, they’ll still probably recognise you and say hello when you greet them (or they’ll pretend to remember you because otherwise it’s extra awkward for everyone including them).

One thing to be careful of though, is to not get stuck in the same circle every time. The first time my classmates went to one such event (I was already a 4-year networking vet at this point), they all talked to each other in one big circle. You must not get stuck only talking to people you know. This is acceptable in short bursts (especially if other people you don’t know join your circle), but is not a sustainable strategy for effective networking. Leave your comfort circle and go talk to some strangers!

Ask for Advice, Not A Job

This is one I’ve heard several times in some form or another, but I overheard a recruiter today say it this way and it really struck a chord. You see, a lot of companies and industries use connections and referrals as one of the go-to ways to find talent. After all, if X person who’s already in the company vouches for someone, they’re probably worth hiring. This is part of why having good connections can be so valuable. In the games industry, it’s absolutely key.

However, there’s a catch to this. When you refer someone to a position, you’re putting your reputation on the line for them. This isn’t something you do with just anyone. I’ve referred several people, but they’re all people I’ve worked with and know to be capable individuals that I genuinely believe would be assets to the company. I’m definitely not going to recommend someone I barely know, let alone never worked with before. For most industry professionals, that’s the simple reality: we aren’t going to help you get the job because we don’t actually know you and whether or not you actually deserve it. This is why so many of them will deflect or ignore such requests.

Now that said, that doesn’t mean we aren’t willing to help you at all. It simply means you need to present your request differently. If you’re going to ask to meet with someone, don’t do it on the pretext of trying to get a job from them. Ask for advice or to “pick their brain” about a subject. Be mindful, listen well, and be respectful of their time. If you do that, many professionals are actually quite willing to offer advice and suggestions. They can help you improve your portfolio, give you good tracks on what to look into to improve your skills, and even just provide you with insight into what they do and how the industry works. If you ask these sorts of questions, they will often not only oblige you, but they’ll remember you later.

I’d like to think I’m a great example of this. I’m more than willing to talk your ear off about anything games industry related and offer whatever tips I can to help you get into the industry. If you’re willing to take the initiative to ask me that sort of thing, and you do so respectfully, I’ll absolutely try to take some time out of my schedule to give you whatever advice I can. Just don’t ask me for a job. If you do all that and I think you might just be the real deal, I might even let you know the next time I see an opportunity I think suits you! But I’m not going to do it just because you asked.

Clean Yourself Up

Honestly, I thought this point was obvious. In my mind it should be. I’ve heard recruiters say variations of it and I’ve kinda scoffed, since it seems so obvious. And yet...That has been proven time and again not to be the case.

If you’re going to get into an industry, you need to have a certain level of professionalism. Practice basic hygiene (I kid you not, the other day I shook hands with a man that scratched his armpits and crotch while we were talking. Needless to say I went and washed my hands thoroughly right after). Try not to dress like a homeless person that just fell out of the dumpster they were sleeping in. Don’t be rude or vulgar to people you haven’t gotten to know yet (even if that’s your normal sense of humour). Learn to form coherent sentences. Spellcheck your resume. Check your resume for errors and inconsistencies. SPELLCHECK YOUR RESUME. Don’t trash talk other companies (they talk to each other, I assure you). Don’t write your application and address it to the wrong company (that one is a common error among those that use the same letter template for every job, which is also a thing you shouldn’t do). Those are some of the big ones.

If you’ve got that covered, here are a few more. Showcase only the work you’re proud of (no one wants to see the bad stuff). Don’t focus on your negative experiences unless you’re following it up with how you learned to improve them. Keep things clear, short and concise (I know I’m not exactly doing the best job with that one, but hey, I’m not looking for a job right now). Get to the point, make it, and be done. Practice your organisational and communicative skills.

Really, there are an abundance of tips on how to present yourself when looking for a job out there. Take heed of them, because they will definitely help. A lot of potential applicants get tossed out because they didn’t take the time to do these fairly simple things. At the end of the day, it demonstrates a certain level of respect for the company you’re applying to or the people you’re communicating with. They’ll appreciate it, and be more willing to listen to you as a result.

Be The Solution

Alright, this is one of my two favourite pieces of advice, because I think it’s probably the most useful one when it comes to framing your mindset when communicating with a potential employer.

The premise for this is simple: when a company puts a job posting up, they are first and foremost looking to solve a problem. They might be lacking in skill or manpower, or just need some fresh blood… But the point is they didn’t put that job posting up out of pure whimsy. This is where you come in. Your goal, as a candidate, is to prove that you are the solution to their problem.

That might seem kind of obvious when you put it that way, but it’s something that should be built into how you interact with a company. As much as they might try to promote their “humanity” a company is first and foremost a business. They aren’t there for you. It sounds cruel, but it’s true. So when you present yourself with the mindset of being someone that deserves to be hired by them because you’re so great, that’s not really going to get you much traction. They don’t owe you anything, and they aren’t all that interested in making sacrifices for you unless they really see a value in doing so. Instead, frame yourself as “the person who will solve their problem”. Don’t even stop there. Be the person who will solve their problem better than anyone else, because you have an edge that they don’t have (see my next tip for more about that). Better yet, if you can also demonstrate your ability to solve their problems, that can go a long way towards making you stand out (of course, you need to be careful not to come off as being a cocky goober who thinks you can do their job better than them, either; there’s a balance there).

Naturally, in order to do this effectively, you need to figure out what their problem actually is. That’s where you need to read the job posting carefully and do plenty of research on the company. Figure out what exactly their problem is, then do everything you can to make yourself out to be the best solution to that problem. I firmly believe that doing that will always make you an appealing candidate.

Have an Edge

This is my other favourite piece of advice. But I’m going to contextualise it a bit before getting into the meat.

I started off in a generalist multimedia program. This meant that I knew how to design video games, code, do art, do 3D stuff, animate, do graphic design, and a whole bunch of other stuff. That’s great and all, but it didn’t actually land me a job. After a couple years with no success, I went back to school and got a specialised degree in game design. On top of that, I relabelled myself as a “technical designer”, or as I liked to say “a designer that can actually build the games he comes up with” (explaining what a technical designer actually is is an entire article unto itself). I did this because I noticed that among most of my peers, I had a much stronger code background than any of them (in part because of my prior studies, but also because I did a lot of game jams where I had to do the code because I was the only one who knew how).

Within a few months, Gameloft put up a posting for a Technical Design Intern. I looked it over and noticed that the two key things they were looking for was someone who knew the Unity engine, and knew how to program in C#. As it happened, I had both of those skills in abundance. In fact everything they listed, I had. I even had the title! So, I applied, and the rest is history.

I know for a fact that the key reason I was hired was the fact that by having a design background and technical skills, I was effectively solving two of their problems at once. And it’s not even like I didn’t have these skills before. I just needed to showcase them properly. In this case it was simply a matter of putting certain skills in the right order and making sure my title reflected the key difference I could bring to their company over other generalist designers. This was my edge (these days my edge is probably more the fact that I’m actually pretty good at numbers, and therefore can do game economy design too, but that’s a story for another day).

So, the moral of this story is that while having a broad knowledge base is excellent and extremely useful, especially if you’re not sure what it is you want to do exactly at first, once you have that you should absolutely find something that sets you apart from everyone else that has gone through the same training you have. Is there a skill you’re particularly good at, or a unique combination of skills that you have? Do you know a tool no one else does? These are all things that can be your edge.

This is why you can’t rely on school alone. School will give you access to many potential edges, but it’s up to you to pursue them, either through projects, extracurriculars, or in your spare time. It may seem like hard work, but I guarantee that the people who do it are at an extreme advantage. I mean, that is why I call it an edge.

Be Persistent

Alright, those were my two biggest ones, so I’ll wind down with some simpler stuff.

Being persistent is difficult. By the time you’re looking for a job, you’re probably already paying bills and have expenses you either can’t afford or have to work some crappy retail job to keep afloat. I spent three years in this city before finally landing something. Believe me, I get it.

But it’s exactly because of that that I can say you mustn’t lose hope. Times can be tough, but if you’ve really got the conviction, you’ll get there eventually. Just keep iterating. Learn from others’ mistakes. Learn from your own mistakes. Take every opportunity you can to hone your skills and knowledge and network. It’s not a waste of time. I may not have gotten a job through my connections, but it’s through my connections that I steadily improved my portfolio and my ability to answer difficult questions. All of my past efforts, even the failures (especially the failures) have taught me how to get better, and that eventually paid off.

For that matter, don’t be afraid to ask for help if you need it. There are resources out there for just about everything, and people with the knowledge and desire to help you find them. We’re all in this together, and one of us succeeds, we all do. So, don’t give up!

Stay Vigilant

Okay, maybe that part got a bit sappy. Let’s end on a slightly more practical note, while also tying things back neatly to the first of these points I made.

You should always try to stay vigilant, especially for opportunities. When it comes to job hunting, these can come and go in a flash. Jobs can get swept up in a matter of days or hours sometimes. This is definitely true in the games industry, where the problems that need solving often need that solution yesterday. It’s very fast paced: blink and you’ll miss it.

That is why you need to arm yourself with a good repertoire of tools to help you. LinkedIn Jobs is one that served me well. Almost all the big companies here use it, and it’s how I found my job. I set it up to give me regular notifications about postings based on the filters “video game design” and “video games montreal”. Simple enough, but it gives me no shortage of results on a regular basis. I apply for industry newsletters and keep an eye out for industry events. I keep a large number of LinkedIn connections to industry insiders who post news about the industry. I also check gaming news regularly to keep myself abreast of what’s going on in the broader industry. I might even occasionally check how some companies are doing on the stock market. These are all things you can do in your underwear at home.

And it’s not just about being aware either. Your resume and portfolio should always be up to date, so that you can send them at a moment’s notice. Keep a mental map of the broad points about every company you’re interested in, so that you can reference that knowledge if you need to write a cover letter. Keep in semi-regular touch with the people in your network. Make sure that if someone decides to look you up, you are prepared. Extra pro-tip: it’s actually much easier to regularly update stuff as it is changes rather than do large passes later. That’s something I’ve learned the hard way…

Conclusion

Alright, I think that about covers all my biggest pieces of advice when it comes to finding a job. I hope some of it might have been useful for you (or perhaps someone you know). And of course don’t forget: reading all of this is useless if you don’t act on it, so go out there and get yourselves hired already!

Bonus: Keep Busy and Your Skills Sharp

Someone pointed out that I should add this point, and they’re absolutely right (merci Jérôme). While you’re hunting for a job, don’t forget to actually practice your craft as well. Work on personal projects and go to game jams (these are fantastic for building your portfolio, developing your skills, and also for networking with other talented people who might even be able to help you later). If you’re not in games, there are often equivalent activities. Either way, participate actively in doing the thing you want to get hired for. This helps you get better and also demonstrates your dedication to the craft, which is something that reflects well on you as a professional.

Furthermore, try to find a job that is at least tangentially related to your field if you can. For example, I did a fair amount of part time work as a playtester for some noteworthy mobile titles prior to being hired (I actually still do some on the side, albeit not as often) and worked for some independent projects as well. This not only helped to pay my expenses while I searched for a full-time job, but also proved to be useful points on my resume as relevant experience. Just be wary not to depend on these too much: independent projects can often fall apart suddenly (especially if there’s no business plan or money backing it) and these sorts of jobs won’t necessarily be enough to keep a roof over your head. They are not an excuse to stop your search, but rather a mechanism to help you with your search.

Most industries have low barrier to entry jobs that they just need filled, no higher requirements necessary. This is a good chance for you to develop a rapport with the company and its employees as well in some cases (though don’t forget that the job you were hired for comes first). Through that, you can make connections, learn things from the inside, and maybe even make a good impression on someone who could help get you a job. If you’re lucky enough that the need is there and your talents have been noticed, it can definitely happen.

Bonus 2: Don’t Be Too Picky About Your First Job

This is a mistake that I’ve heard quite a few times. I was admittedly a little guilty of it too at first, though I don’t think quite as much. It’s pretty common that people say they want to go work at X big name company. In games, it’s usually a AAA studio, because they want to work on the big titles that everyone knows. While it’s not impossible to get hired by one of these studios, I’ll warn you right now that it’s not very common, certainly not when it comes to the really high value brands. The people guiding today’s big titles aren’t juniors fresh out of school; they’re usually seasoned experts with a lot of experience under their belt. Games in particular is an industry where experience and seniority will usually trump raw talent, because experience is reliable and stable, which is what you need in a big company structure to keep things running smoothly. So don’t be heartbroken if they don’t ask you to have a key role in the next big project. That will come eventually, after you’ve paid your dues.

And that doesn’t just go for specific titles or companies either. In Montreal at least, it’s very common for people to say they don’t want to go into mobile gaming. I was one of them at first. But truth be told, there can often be a lot of fluidity when it comes to industries with sub-categories, especially if the fundamental skills are shared across them. Game developers in mobile, indie, and AAA all bounce frequently from one category to the other, because the tools and skills involved are largely the same. So don’t think you’ll necessarily get pigeonholed into a category just because you took a job. That only becomes a problem if you present yourself that way. Take the opportunities you can find, and build from there. A perfect opportunity isn’t going to just show up, so don’t pass up on other chances waiting for one.

20 Tips for Becoming a Better DM: Lessons Learned at the Table

Tabletop Roleplaying is something many people know about, but only a few have truly dived into. Today there are thousands of games like Dungeons and Dragons where players take on the roles of heroes and go forth on adventures with the help of dice and stat sheets, all the while being guided by the all-powerful DM, or Dungeon Master. And yet, only recently has this type of game started growing into the mainstream consciousness.

As of my writing this, I have been playing Pathfinder for a little under 3 years. It’s not my first experience with tabletop roleplaying (I played Dark Heresy in University), but it is my deepest one. Admittedly on a relative scale 3 years of gaming is not very long, but my formation has been dense and accelerated. I’ve played in many games and even finished a few of them. But most significantly, I’ve been running a campaign myself (Hell’s Rebels, a Paizo adventure path) since September of 2015.

Even before that campaign, I had wanted to try my hand at DMing. I am, after all, a game designer, and what’s a DM if not the embodiment of a live action game designer? Hell’s Rebels was the first pre-made campaign that really caught my eye, as it featured themes and mechanics that seemed very much in line with my own style. And so, with wide eyes full of excitement I invited a bunch of my friends to join and set forth on my first adventure in DMing.

With modesty, I consider myself to be a fairly decent game designer, though I will wholeheartedly admit I still have a great deal to learn. I am, to be sure, still a junior. But my game has proven to be an intense crash course. My trial by fire was rough to start with, and I made many blunders that looking back on I should have seen coming. I’ve now just concluded the third book (of 6 in the entire adventure) and I’m still learning things with each session. The experience has had its ups and downs, with plenty of fun and fights. But this time as a DM has helped me immensely in learning to become a better designer.

It is for this reason that I’m writing this, a compilation of the key lessons I’ve learned on my adventure. I find that writing gives me a chance to reflect and properly formulate my lessons. At the same time, it is my hope that anyone reading this might learn from my experience. So, without further ado, let’s get right into it.

 

Tip 1: Know your inner DM

Sun Tzu has some solid wisdom, so I'll paraphrase from him: in war (as in all things), there are three things you need to know to win every time: yourself, your enemy, and the battlefield. My first three tips correspond to these three things.

You as a DM are a crucial part of the game. You need to know what kind of DM you are and by extension what the players will be dealing with. Are you merciful or cruel? Are you by the book or off the cuff? Do you focus on theatrics or mechanics? What are you willing to put up with and what’s a no-go? Take some time to soul search and answer these questions to define your DMing style. Figure out your strengths and weaknesses. It will help you figure out what your campaigns will look like. Telling your players how you're going to run things allows them to figure out if you're running the kind of game they want to play, and what mindset they should be approaching the game with. If the players know their DM, it means they can cooperate with them to make the game go smoothly.

I’ve done an inventory of my own DMing style. My strength is organisation. I'm really good at setting up documents and tools for my players. I like to focus on intrigue and narratives over combat. I like making NPCs that I voice act and give distinctive personalities. I like using music and other tools to set dramatic tones. I don't tend to kill players, but I'll definitely have consequences for poor choices. I prefer interesting but suboptimal characters to optimised stat blocks. I'm generous with items and flexible with game rules of it can make for a more interesting story. I use a lot of DM fudge (DM fudge just means rules improvisation or result altering; I really like the term), but will generally try to stay within a loose script. My theming usually bounces between comical or psychological horror/tragedy. I could go on, but I think I've made my point.

This advice isn’t just applicable in tabletop either. The Art of War has been used in business classes for decades, if not centuries. This quote in particular strikes me as the kind that is truly universal. There are very few times when it is not valuable to know yourself. In knowing your skills, limits, room for growth, and failing points, you can not only better navigate the various challenges, but you can also uncover ways to better yourself as you go. It doesn’t matter if you’re a DM, a game designer, or anything else.

Tip 2: Know your players

Not that your players are enemies (nor should you treat them like ones; I'll get back to that), but they are the ones you're challenging. Having a group of players that doesn't mesh well with you, your campaign, or each other will almost always break a game, or at least make it pretty lame. When you set up a game, make sure the players well be well suited to it. Or if you're making a campaign for an existing group, make the campaign fit them. Don't take on players that won't mesh with your DMing style. Make sure you know the optimal number of players for your game (in most cases it's 4-5, but there are exceptions), and stay within those bounds. Make sure you don't select players that won't get along. Avoid all these mistakes, and it will save you a lot of headaches in the long run.

I made several of these mistakes with my first campaign. I invited people from my various social groups, and it's obvious not all of them get along. I also have 6 players, which means everything takes much longer. I've managed to mitigate these problems with time, but it's obvious that these choices have made for a much tougher campaign for me to run and rougher for the players. By comparison, I play in a small group with two others and we all work well together. Our synergy is incredible, and the game is much smoother as a result.

Considering user-experience is not unique to tabletop RPGs. Video Games and most product-based industries hail the almighty user, and with good reason. As the target audience of what you’re making, it is imperative that what you make is tailored to their needs and/or wants. This is imperative for designers. That said, it is true of any interaction. The more you know about who you’re communicating with, the better you can respond to them to come to a beneficial arrangement. This is fundamental logic in theory, but it is all too often forgotten in practice.

Tip 3: Know your game, and be passionate about it

The DM and the players are important, but equally important is the campaign itself. It is the third leg of the stool; without one, the other two fall apart. You as a DM are the supreme master of the game world, and you should have the knowledge to back that up. It's important that you have a deep understanding of both the mechanics and lore you'll be using. These are your tools, and without them it's the blind leading the blind, and that doesn't end well. Even if you’re really good at improvisation, if you don’t have a solid foundation you risk going all over the place. The moment a player steps off the beaten path, and trust me they will, you're going to have to tell them what they find, or at least provide a good reason for why that doesn't work. It will also help you determine how to best advise your players when it comes to making choices that complement the setting.

Related to this, if you're interested in running a campaign that is in the process of being written/released I also suggest waiting until it is fully released before doing so. This saves you the risk of accidental contradictions. I made the mistake of starting the campaign before all the books came out, and so I lacked knowledge about some world aspects that would have helped greatly. One specific example comes with my friend having picked a character race that played a role later in the campaign (and had a settlement nearby), but because the race and their settlement weren't outlined, I couldn't propose ways in which the player might integrate them into his own story. As a result, his character lacks in the way of tangible motivations that could have really helped with immersion. But it's a lesson I retain for the future.

Now, knowing the setting and mechanics is all fine and good, but that's not enough. You need to be passionate about it. After all if you don't care, why should your players? There are hundreds if not thousands of game systems, worlds, and campaigns out there, and if you're ambitious you can make your own. There's no excuse for you to run something you aren't fascinated by. And if the one you picked has bits you don't like, remember that you're the DM. You can change them. Replace or alter NPCs, places, rules… You are allowed to do all these things and more to make something you're as eager to have your players explore as they should be to explore it.

I specifically picked my campaign because I was very interested in its basic premise and setting. When I started my lore knowledge was okay but as we continued I did a lot of research. Now when it comes to the city of Kintargo and its surrounding areas I could tell you just about anything. I also threw in many new characters and flavour for existing ones to give it more life, and it meant players cared much more about them than they might have otherwise. It was important that the players feel invested in the world, so I made a point to invest in it myself. I think that is my one biggest success with my campaign.

Tip 4: Leave no rules ambiguous

It's a fairly common for rules to be debated during a game. Either someone doesn't like the way a certain thing works, or someone's actively abusing a linguistic loophole, or the rules are ambiguous or contradictory. As the DM it's your job to be the final word on these things. Whether you want to listen to a player's argument and bend the rules or decree that that is not how that thing works no matter how much the player might want to empty the ocean by putting it in their bag of holding, the choice is up to you. But you do need to make sure you set that rule and set it definitely so that players know what goes and what doesn't. Players squabbling over mechanics take precious time away from playing the actual game. Of course some of these only come up circumstantially and can't be predicted, but for those ones just use your absolute authority as DM to sort them out as they appear.

I've seen this quite a few times, both in my game and others, and no example is more prevalent as the alignment system. Would torturing a cultist to get crucial information about an imminent plot cause a good-aligned inquisitor to fall from grace? Is violent murder evil, neutral, or good if the ones getting murdered were tyrants and bigots? What do lawful, neutral, and chaotic even mean? This debate can get quite heated, and since my game in particular was oriented towards CG freedom fighters combating a tyrannical authority, I knew I had to plug that hole before it came up. After all, one man’s freedom fighter is another man’s terrorist, and I didn’t want my group falling into the trap of thinking that any actions would be justified as “good” just because the villains were evil.

In my case, I laid out Good vs Evil as pertaining to the wellbeing of the local citizens, and Lawful vs Chaotic as being a focus on the written law (Lawful), the spirit of the law (Neutral), and the results (Chaotic) when defining Good and Evil. I also decreed that my judgements on any alignment shifts were allowed one appeal, but only one, and that my decisions were final. All things considered it has worked reasonably well. Admittedly my party does have plenty of moments of dubious morality (the quote “does all this blood count as difficult terrain” comes to mind), but I think through the NPCs and the party itself getting more comfortable with the setting, alignment in particular has gone from being a problem to a narrative factor. It was nonetheless a rough patch in my game that I’ll be more careful with in the future.

Tip 5: Set boundaries for your game

Where my last tip was about boundaries in the rules, here I’m referring to boundaries in the sense of scope of the setting. Too often it can be easy to think “I'll just give my players a rich world and let them find their adventure”. It's a nice thought, and if you're really prepared for it a sandbox can work fairly well. But most campaigns have a storyline or plot of some kind, and the moment there's a trail you need to make sure your players stay on it (with reasonable room for deviation, of course). A lot of this is done at the start of the campaign. Players need to know what type of game they're in, both in and out of the meta. Their characters should relate to the story, and the player should be in the right frame of mind. Otherwise you end up with absurdities where characters have no reason to follow your story's rules and suddenly you're left with all your key NPCs murdered by the “heroes” or players cracking jokes and refusing to take your horror scenario seriously. Certainly you don't want to railroad your players entirely, but they should be aware of what are and aren't good ways of approaching your game.

My players generally struggled with their roles in my campaign at first. I didn't have a full picture of the setting (I naively started once the first book of the adventure came out, not knowing what would come further down the line), and so understanding of the plot was somewhat rough. It meant that my players didn't go for the “fight for the good of the city” aspect the game narrative eventually tried to push, instead taking the “fight to kill the bad guy” approach. It meant the party of would be freedom fighters for justice and liberty were more akin to morally dubious assassins. The campaign assumed players would try using nonlethal tactics, but I hadn't given them much of a reason to even consider them.

I managed to pull this back a bit as time went on through NPC interactions and not so subtle hints that they might want to stop murdering everyone and start being a bit more “heroic” in temperament. Some of that did also involve me privately taking players aside to clear it up, which fortunately worked reasonably well. Next time though, I would definitely be very upfront about what your true objective and motivations are. For instance, the next game I'm planning is a horror game. As such, I'll definitely have to be adamant about not having the comical tangents common to the prior campaign.

Tip 6: Have a session zero

So much of what I've noted so far, and a lot of what will come for that matter, can be handled by simply having a session zero. A session zero is essentially a scheduled session in which the players build their characters together. It gives the players a chance to interact and come up with synergies and dynamics together. It's not called a “party” for nothing, after all. Even if they come from different backgrounds, the characters and players should be able to work with each other. It also gives you a chance to observe, clarify, and offer hints and suggestions at how to prepare for your game. Too many DMs will skip this step, and it's a pity. You can avoid so many major early pitfalls with it.

I had a session 0 for my game, but most of it was actually spent explaining basic rules of character creation to my players who didn't know the system well. Some players simply weren't there for it and I helped them with their characters separately. It meant that the rag tag bunch of freedom fighters were very rag tag. Character concepts clashed, and not in the good “this adds flavour to the party dynamic” sort of way. Characters had wildly different motivations that at times conflicted and lead to characters leaving the party to go on their own. A lot of the issues I had to work out over the course of the first dozen sessions or so could have probably been avoided had it been for a session 0.

Tip 7: Keep a rulebook handy

In the event that you don't know your game’s rules and mechanics by heart (and even if you do), it pays immensely to have an easy to pick up reference for yourself and your players. If you're in person, keep at least one copy (but preferably multiple) of the rulebook on hand. If online, keep a tab or window with them at the ready. This little thing can save you a lot of time. Players don't have to ask you for everything, you don't have to remember all those edge cases and special rules, and rule debates can be solved quickly.

That said, sometimes the rules can be a little much, and in those events I wholeheartedly support making your rules up on the fly. Personally, I like to balance both quite precariously. Since my game is conducted online, I always have a link open to the online Pathfinder guide so that I can quickly look up rules and details when I need it. However I keep an unwritten rule in mind: if looking up the rule is taking long enough that the pace starts feeling like it will be broken, then I’ll give up on looking it up and make up something that makes reasonable sense. Usually my biggest hint regarding the pace is that player’s will start talking about subjects outside of what is currently going on in the game. One other thing that can help is to have certain pertinent rule pages bookmarked or open already when they become relevant. I like to keep links to them attached to relevant tokens or notes so that I can quickly access them as needed.

Tip 8: Keep notes for yourself

If the rulebook covers you for mechanics, your notes should cover the roleplay. Even if the campaign comes from a premade book, it's always good write things out yourself. Your notes should be naturally easier for you to read, and you can include details the source might not have. I keep dialogue scripts, scene descriptions, instructions on what songs and actions to do certain moments, and other details in here, and I have to say since I started using them I've found it immensely helpful. It’s very similar to a design document for a game or a screenplay for a film: these will allow you to prepare scenes in advance so that you can play them out faster and easier while in the game.

Needless to say these ones are just for you, so no player peeking. But of course you can always provide a codex of sorts for their benefit that you fill with info as they go. I started making these after a game where I played as the knowledge bot and had trouble remembering all the NPC names. Fortunately once my DM added a journal it made my life (and the DM's) much easier.

Tip 9: Use secret modifiers

Often times, there are situations where the dice just don't do what you want them to do, and it messes up the game. Say you keep getting critical hits on one party member, and end up killing them early on without giving them a chance to fight back. Say the party keeps failing the check to open a door that's necessary to continue to the next area, with no real alternative path. Here's the thing, you're the DM. You hold absolute power, and therefore bend the dice to your whims. Don't show your players your dice, and it you must, wait until after you've decided they have a result you deem acceptable. Consider adding modifiers based on the situation, even if the rules don't strictly call for it. If someone contests you, remind them that you have the right invoke DM fudge (or fiat, or whatever term you want to use for making stuff up; you're the DM after all).

I am a big supporter of DM fudge, in case it wasn't obvious. I use it often. Not so often that I completely take away the chance of the game, but particularly for situations where one result is significantly more interesting than the other. If the players are trying to get past a door and simply can't get a decent role, I decrease the difficulty so that they do. If an enemy can't for the life of them pose any threat to the players because of poor roles, I change them. If a player really should be able to pass a certain check but the mechanical likelihood of it working is minute, I give them a bonus that accounts for their background.

In many tabletop systems fudge is the simplest way to balance a situation. No system is perfect, and DM fudge is what allows the DM to carry out their job of converting the theoretical rules of the game into practical enjoyment for the players. If that means twisting the rules to suit your needs, so be it. In fact this sort of emergent design is perhaps one of the greatest strengths of tabletop RPGs compared to other types of games, because these things can be done both easily and discretely. In truth I don't always tell them that this is what I'm doing, but in many cases they don't need to know.

Tip 10: Give your scenes flavour

This one is perhaps a bit more subjective, since it applies more to narrative focused games, but nonetheless the application of narrative flavour can do wonders for a game's tone and feel. A well placed voice accent, dramatic reveal, or impromptu description of a scene will help to immerse your players in a way that raw dice rolls never will. You don't have to be an actor either; there are loads of ways to do it. Get some background music, use different tokens, make physical letters or objects as handouts, and encourage your players to get certain mechanical boons for roleplaying. Some systems have the last part baked in already.

Personally, I use several of these techniques. Bosses get special boss music, and I try to decorate my scenes when I can. Anytime a critical roll or particularly special event occurs, I try to narrate it (usually to comical effect). I write session summaries that include pertinent gifs and quips. I give every NPC a unique voice and accent. I write scripts for much of my dialogue. The last one is a bit tricky since players rarely follow your dialogue expectations perfectly, but I solve that but keeping it vague and including branching responses. I can tell you from experience that these things make my campaigns so much better. My players have come to know these characters and will even joke about them outside of the game. Some group favorites are Neddus, THE MOST HEROIC, BRAVE, AND LOUD PALADIN IN ALL THE LAND, AND ALSO NOT THE SMARTEST, Setrona, the sassiest and crudest little Irish tavern owner you ever did see, and the stern Octavio, who in Setrona's words “has that polearm o’ his shoved so far up his arse I figure his sharp tongue's just the blade stickin’ out his mouth”. I was pretty proud of myself for that line.

Tip 11: Have a plan, and be prepared for it to derail

One of the big advantages tabletop RPGs have that other games often don't is the flexibility to alter the game on the fly based on how the players interact with the world. A DM is a person, and this means they can be more interactive than any other game system. That said, foolish is the DM that thinks they can improvise the whole thing and actually produce a decent story and progression. I'm not saying it can't be done, but let's be honest: it's never going to be as good as a well-planned scenario.

However, the only thing as certain as the value of a plan of that your players are going to break it. That's just a reality of design: users will always find ways to subvert your expectations. So, don't make a plan with the assumption that your players will follow every little step you give them. They'll jump to conclusions, they'll try things you didn't account for, and they’ll ignore hints. Sometimes it's not even the players, but the dice or some other factor you didn't prepare for. Say your players just really can't hit one particular enemy or don't have a key item they were supposed to get. At one point or another, it will happen, and in those moments, you need to be able to handle it. There are a couple ways to do that, and realistically you should use both of them.

The first is to make sure your plan has contingencies. When I'm writing my session plans, I always include little notes for “what if” situations. I try to include simple details like how the buildings are constructed, basic personality traits for minor NPCs, and the like. I also have standardised values for dice roll difficulties. For example, players must pass 15 on their check to do a basic thing, 20 for a challenging thing, 30 for a very difficult thing (these should be adjusted to match what your players can get on average). Conventions like that are useful for when I quickly need to come up with a check, which leads me to my second solution.

Improvisation skills are your friend. When the plan and backup fail, you need to know how to respond. Knowing your lore is a big part of that (see Tip 3), but some of it is purely on you. I tend to practice a lot on my own scenarios. I'll think about how NPCs would respond to an event and kind of blather it to myself. I’ll consider their comments of shock and confusion, how they'd give advice, and other considerations. I use the same technique on the mechanics side. I think of the feasibility of more outlandish ways to act, and how I'd run them. Some of is intuitive, but thinking on your feet is a skill that can be learned. Take up improv if you can. Or barring that play in games and practice your logic from the other side (how would you deal with your party). And if you don't know whether to let something slide or not, you can always use your dice. Sometimes when a player asks me if something would work and I'm not entirely sure, I'll to a dice or flip a coin to see if I'll allow it. This works pretty decently more often than not.

Tip 12: Check up on your players (and their sheets)

As a DM, checking up on your players is crucial for two reasons. The first is for feedback, the second is to make sure your players are actually up to speed.

There's a general lack of appreciation for feedback in the design world. That's a mistake you as a DM must not make. Talk to your players regularly. Observe them constantly. Find out what they like and don't like about your game. What would they like to see? What are their goals with their character? Do they understand what you're trying to do with the campaign? Get as much feedback as you can, and use it to make your game better. And a quick note: don't just go by the stuff your players tell you either. Actions can tell a great deal more. You need to be observant. Notice when players repeatedly make the same mistakes or regularly avoid or pursue certain aspects of your game. These behaviours can be telltale signs of how to adjust your game to make it more enjoyable.

Then there's the matter of sheet checking. While players should be keeping their sheets up to date, I can tell you from experience they often won't, or they will but not give them to you. While in some cases it's fine to leave it be, in doing so you leave yourself open to some problems. Sad as it is, some players will exploit your lack of oversight to do things which can ultimately be a detriment to the game and their fellow players. Other times they'll make mistakes or forget things. I had one player give themselves a powerful ability they shouldn't have for another four levels because they didn't notice the prerequisite, while another hadn't given himself feats or skill points for the last three levels because he was still learning the system and didn't know what to add on his sheet. It's these kinds of things that can easily be fixed by having your players give you regular sheet updates.

I make sure to demand sheets before any major encounters. Not only does it let me check for these sorts of issues, but it also gives me data on their strengths and weaknesses that I can use to enhance encounters. One rule I plan on using in the future to ensure compliance for games where these details are important is this: “As far as I'm concerned, the last sheet you gave me is the one you have. If you have an item or ability but it's not on that sheet, you don't have it.”

Tip 13: A DM’s words are powerful; use them wisely

There is a reason you are called the Dungeon MASTER. You hold the keys to the game. You know everything there is to know about the game (or have the power to make it up). You are effectively the god of this realm. Don't let that get to your head, but appreciate it. Like they say, with great power comes great responsibility.

Your words can make or break a situation, so you need to act like it. Be prepared to offer advice of a player needs it, and to stay quiet if they need a lesson. The players should care about what you have to say, but at the same time they cannot rely on it alone. Definitely don't tell them what to do (except for very special situations), but instead give them choices (“you could do X or Y”, “do you want to do this thing”, etc.), and occasionally mention likely consequences (“you could do X, but NPC might not be happy”). In drastic situations where a “total party kill” action is about to be undertaken, you also have access to perhaps the most powerful phrase a DM can utter: “Are you sure you want to do that?” Use that one carefully, because it should bring a party to an immediate halt.

It can be pretty intimidating too, I understand, to hold all that influence. There's a trick I use for that. Often times, I'll give NPCs a great deal of wisdom. They'll have plenty of advice on how to deal with various situations. But they will only offer this advice if the players ask for it, or are evidently stuck. As such, I can restrict my advice to “you have people you can ask”. It takes some of the pressure off of me and means I can even toss in the occasional misdirection (after all, an NPC might not know what the DM knows). NPCs are almost universally better guides than the DM, but the DM’s voice is a tool like any other, to be used when you want your players to take what you say as an absolute.

Tip 14: Player agency is an essential thing; handle with caution

By player agency, I mean a player’s ability to control the actions and choices of their character. In any game, agency is critical, but especially so in an RPG. Those characters represent the players. They are yours to manipulate, attack, support, influence… But not control. The moment you take away the player’s control, they aren't playing the game. At best they're listening to your story. There are few things less fun in a tabletop RPG than not being able to do anything in a given situation, be it because you took over or they are in a situation where none of their actions work.

That said, taking away agency from the player isn't completely “verboten”. In fact, it can be an excellent way to instill fear or very threatening situations. Players naturally won't want to lose agency, and when it happens it can be devastating. I think the tensest situation I've ever been in involved one of our party members getting hit with a magic jar spell and getting possessed by a powerful creature. It was scary as hell, but quite fun.

And there's more ways to take advantage of agency as well beyond simply taking it away. Making it work in ways they don't expect (think of how you might adapt something like the Psycho Mantis fight from Metal Gear Solid into tabletop format), mismatching what the player knows and what is happening (a cursed item that does the opposite of what the player thinks it should, for example), giving players different information, messing with basic mechanics… There are some creative things you can do by playing with player agency. To toss an example in, I have one encounter that involves an enemy disguising itself as another player to cause confusion. In Roll20, I do this by making a second character token for that person. The player in question doesn't know which one of the tokens is actually his, and I don't tell the other players either. In fact I don't even tell them the impostor's there. That's for them to notice, hopefully before it's too late.

Tip 15: Give meaning to character deaths

Some systems, campaigns, and even DMs boast about being player killers. I am of the opinion that that is generally dumb, at least in the context of a roleplaying game. Systems that work around the concept of frequent death can work (the game Paranoia uses this to good effect), but what's important to recognise in most RPGs is that players will usually put a fair bit of personal investment in creating and developing their characters. There are exceptions of course, but I'm talking about in general. Death in a system like D&D or Pathfinder doesn't come with an easy respawn until fairly high levels. You need to come up with a new character idea, build that character from the ground up, and even then they might lack the investment of the previous character. It can also be a pretty huge bummer for some people who have long term plans for their character.

Now, having said all that, I'm not against PC deaths outright. What I'm saying is that it's a big deal. It can be an extremely potent narrative tool if you want it to be. But in order for you to make it so, you have to make the death significant, both in cause and effect. There are few things I hate in a game as much as a “save or die”. For those that aren’t familiar, this is the concept of a situation where the player must roll a dice and the life of their character is decided almost entirely on the outcome, with very little the player can do about it. Make sure your players stand a fighting chance, and that if they're dying, it's because of their own poor tactical choices or dangerous risks. You may be the cause of death, but the player must first enable you to do it.

And furthermore, when a PC death does happen, be sure to give them a suitably dramatic send-off. Tip 10 is particularly relevant in these sorts of situations. Let the player have their character go out a blaze of glory. Make it like one of those scenes where a main character gets offed in spectacular fashion. Make a show of it. The more weight you as a DM put on the death, the more importance you are placing on the character's life. It's a good way to further your player's investment in the game universe. The party should feel like they just lost a comrade in arms in a fierce battle, not like Jimmy rolled a 1 so now he has to make a new sheet.

Tip 16: Know what your players are comfortable dealing with

You know what I said about knowing your players? I know it was 14 tips ago, but hopefully the lesson stuck. That lesson goes doubly so for sensitive subjects. Players play games to have fun and enjoy themselves. Things that pull them out of the game by making them uncomfortable just aren't cool. Take note of phobias, touchy subjects, and the like. As abused as they might be in some cases, there's nothing wrong with content warnings either.

Really, this rule just boils down to “don't be an inconsiderate jerk”. If one of your players recently put down their dog and is feeling depressed about it, maybe don't send a pack of zombie dogs after them. If your party isn't into ultra-dark humour, try keeping it to a minimum (or better yet don’t have it at all). Like most things that tread along the edges of depravity, consent, be it explicitly stated or implicit, is important. When it comes to questionable content, some people won't mind if you shove it down their throats, and that's great. But don't do it without getting permission first. Really, not shoving things down people’s throats without their consent is just good practice in general.

Tip 17: Yes it's their story, but you're still the one telling it

At times, the job of a DM might seem selfless, but if that's the case then you probably aren't doing it right. The DM, while they aren't a player character, is still a player in the grand scheme of things. To borrow a term from business, they're a stakeholder, just like the ones “playing” the game. As such, it's critical that the DM also enjoys themselves while running the game.

Well known game writer and DM Matthew Colville once said that the way to determine whether or not a DM has fun depends on whether or not their players have fun. I'd go a bit further than that. Yes, a DM’s enjoyment of the game should be predicated on the enjoyment of their players, but likewise the players’ enjoyment will rely heavily on the enjoyment of the DM. That might sound convoluted so I'll try to simplify: player and DM enjoyment are and should be a symbiotic relationship. One cannot exist without the other, and if either is missing then the game will inevitably fall apart. This is why while many guides about being a good DM talk about improving the experience for players, it's important not to neglect the DM's experience.

This ties in quite heavily with Tip 3. After all, if you aren't passionate about the game, crafting the story within it will seem tedious, and that will rub off on your players. Quite simply put, you won't be a good DM if you aren't enjoying the story you're telling.

Fortunately as of yet I haven't found a situation in my game where I've lost interest in the story. I'd like to think that's a big reason for why my game has continued successfully for as long as it has. However I've certainly seen it with others. There are many times that I've seen a DM lose sight of their campaign's vision, and as a result the game rapidly withered and died. Playing in games where the DM seems to view it as a core just isn't fun, and as a player I wouldn't want to stay in such a game.

Tip 18: Steal good ideas from others

To steal an often misattributed quote, “Good artists copy; great artists steal”. It's an idea that any artist or designer should keep close to heart. After all, it is also said that everything has already been done. So, by extension, anything new is just a really cleverly crafted combination of previously had ideas melded together.

This is particularly true for storytellers. The human experience only has so many divergent paths, including in fantasy. After all even if it is fantasy it should be relatable to your real life human players. There is a great deal of material in the human database, and many great ideas that haven't been fully exploited. Taking these good ideas and making them your own is just being efficient.

That being said, note the wording of my last sentence. “Making them your own” is important. This is the difference between “borrowing” and “stealing” (and by extension the difference between a good artist and a great one, if you follow the opening quote). While taking something cool from somewhere else and transposing it into your adventure is fine, it's even better if you can identify what about that thing made it cool, and rebuild it as a part of your game.

Allow me to offer an example. Though be advised, this is the part where I spoil a rather significant part of the Hell's Rebels adventure path, so if your intention is to play in it I strongly recommend skipping the rest of this section.

Recently, my players attended a masquerade ball being hosted by the villain of the campaign. The players knew this event would be a trap, but didn't know what sort of trap it would be. The trap in question, as laid out in the book, is that at the end of the night the villain locks the doors and has his minions slaughter everyone in attendance while disguised as good-aligned creatures so that he can blame it on the heroes.

However, this plan has some plot holes. If the villain doesn't intend to have anyone survive, why bother with the disguises? If that's a fallback in case anyone survives, then why would he make a long winded speech to the crowd just before the massacre begins calling them “necessary sacrifices”? His attempt at plausible deniability is notably flawed in this regard. Additionally, the villain was supposed to have a bodyguard who would appear only if the party didn't kill them earlier. My party did, so the villain was down a minion, and my group is strong enough that losing that powerful foe would make the fight much too easy.

Fortunately, while going through a forum for DMs of this adventure, I came across a few ideas. For the minion, someone had proposed an alternative that I ultimately used in my game. By this point, the players had thwarted the villain multiple times. The idea was that his bodyguard at the masquerade was his former bodyguard that had failed him in the first book, and was subsequently tortured and upgraded to be threatening to the now much stronger players. Since that one was dead in my game she could not reappear. However, this other DM had pointed out that there was nothing stopping the villain from doing the same thing to any of his other minions that had failed him, and it just so happened there was a foe my players had deceived, rather than fought. For her failure she was turned into the new tortured bodyguard, and served the role very well.

The events leading to the massacre was another proposed alternative I took from that forum. Since the players had done so well to thwart the villain before, it was unlikely that he could kill all 300 people at the masquerade without anyone escaping. Since the villain was in fact a clever strategist, this other DM suggested that the villain conduct a final ceremony that would get interrupted by someone disguised as a player or ally character, so that the lure of the players being the ones responsible seemed more plausible.

I took this idea, but I also fashioned it to suit my group even better. Up until this point, my players had developed a reputation for foiling the villain, but also for using fairly violent means to do so. Many of the villain's subordinates were killed quite brutally. One character in particular, a former slave turned assassin, was known for his violence against those that had wronged him. And so my solution was this: during the final ceremony, certain members of the audience would be brought on stage as winners of the masquerade’s “best mask competition”. Among them was the leader of the noble house most loyal to the villain, who incidentally was the former owner of the slave character, and someone disguised as that same character. During the ceremony, the one disguised as a player leapt at and killed the noble, and was subsequently put down by the villain, but not before claiming his kill in the name of the player characters’ organisation. This served as the panicked pretext under which the massacre began.

The beauty of this solution was twofold. On the one hand, it used the party's own reputation against them. Because they were known for brutally assassinating those loyal to the villain, it seemed perfectly plausible that such an attack would take place, so even if people did escape the massacre (which was likely given the sheer numbers), they might still believe the players to be responsible. On the other hand, because the players were not all together at the time of the ceremony, some of them also believed, briefly at least, that their ally and fellow player had just committed the act, leading to confusion among the party that rendered the whole event that much more chaotic (I made sure with the player beforehand of course that he would be okay with the temporary ire until things were cleared up). The end result was that a scene that otherwise would have made the villain seem foolish now appeared as a much more devious plan that played to the party's faults to give them a greater challenge and a more visceral experience.

Tip 19: Play in games

Technically speaking, there is no rule that a DM has to have ever been a player of the game they’re running. All they really need is a decent understanding of the rules and a campaign to run. That said, it should come as no surprise that playing in games can be immensely useful for any DM. It is by playing in other games that you can see how the game feels from the player’s perspective, but also how other DMs run their games. These offer excellent opportunities to learn by observing others. Countless times I’ve taken good ideas from other DMs I’ve played under, or learned from mistakes they’ve made in their games. By seeing experiences I as a player enjoyed, it gave me a better idea of what to offer my own players. Being on the other side of the DM wall can offer a great deal of perspective, which leads me to my last piece of advice…

Tip 20: Have a life

Tabletop games are immensely fun, and offer a massive array of experiences and opportunities to learn and engage with others. That said, it is only one of many mediums through which you can experience the world. Vast as it might be, it can become possible to get too wrapped up in it, and for it to suffocate your creativity. To refer a little to Tip 18, many of the greatest artists, particularly in the realms of fantasy and science fiction, drew inspiration from other mediums. Isaac Asimov uses his knowledge as a scientist to enhance his stories. Frank Herbert drew heavily from Arabic culture and religion in Dune. George R.R. Martin has an affinity for the history of the European Middle Ages. There’s an entire Wikipedia page covering J. R. R. Tolkien’s influences.

What’s important to recognise is that all of these renowned writers that so often have influenced the domain of tabletop RPGs took inspiration from other sources. To be a good DM, you must be a good storyteller. To be a good storyteller, you must know good stories. And to know good stories, you must look to the world and all it has to offer. Better yet is to live out stories of your own. Go outside, meet different people, and see interesting things. By cultivating experiences first hand, you can draw from them something much more personal than anything you could conceive through pure imagination alone. In fact, I would dare to say that raw imagination is unusable. It can morph and bend things into wonderful shapes, but it needs raw materials to work. These materials come from the outside world.

It would be all too easy for me to shut myself in my room and spend my entire time doing tabletop games. Perhaps if I had, I would have much more experience under my belt than just one game. But I know with absolute certainty that if I were to have sacrificed my life to make and run games, they would be nowhere near as good as what I can produce now. Taking experience from all over the place is what allows me to craft the best work I can, and continuing to have experiences that push my boundaries will only make me a better DM and designer with time. That, quite possibly, is the single most important piece of advice I can offer.

Conclusion

And with that, I’ve reached the end of my lessons so far. As you might have noticed, some are much more practical, others more abstract. But one thing I hope you’ve observed is that all of them, in one way or another, apply not only to tabletop roleplaying games. In truth, any piece of advice I’ve offered here can be just as valid in just about any other domain, be it video games, business, relationships, or anything else. You may need to tweak the terminology a bit of course, but it’s all there. That is something I’ve taken great pleasure in observing in my life: that everything is connected. There are through-lines, universal truths. Systems will often remain consistent from one place to another, and there are a great many transferrable skills that aren’t always known by the same names. To truly recognise this fact, I think, is a key step in being a more complete individual. I won’t be so grandiose as to say it’s the path to enlightenment or anything like that, but I wouldn’t discount the notion.

In conclusion, allow me to offer one final piece of parting wisdom from someone who no doubt has a great deal yet to learn: to be a great DM is to truly understand people. A great DM can touch the hearts and minds of their players and open them to a world of experiences they could only dream of. There is great potential in this role, far more than what might be recognised. I think anyone who has truly been a DM can recognise that. I ask that you hold onto that, and cherish it. Being able to touch others in such a way is an incredible thing, and I really do believe it can bring us together and better us as people. I know that might seem rather lofty for a game, but sometimes the greatest things do come in the strangest of packages. This is, after all, why I chose to pursue the path of a game designer.