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! 

Zeitgeist 2022: The Magic of Networking

It's been a long time since I've sat down to write one of these blog posts. Funny enough, even though I've posted a bit more frequently of late, but they weren't articles I was writing specifically for this blog. This one however is very much a product of my own motivation. Funny how events like these make for such good writing motivators.

Yesterday (at the time of me writing this), I attended a little event called Zeitgeist. It's an internal event at Ubisoft Montreal where the entire studio is invited to attend a presentation of our accomplishments and what's to come in the future. It's where we get to hear big announcements and see sneak previews of what the studio is working on. Naturally, I can't talk about what we saw in that presentation, but there were certainly some things there that I was pretty excited to hear about (and others where I'm uncertain, but leaning towards cautiously optimistic).

That’s not what I want to write about, however. What really got me excited though was the social experience that came along with it.

I've been working at UbiMTL since fall of 2020, and 2021's Zeitgeist was online (which most people have told me paled in comparison to the real thing). With the lockdown rules only recently lifted and a lot of people still favouring work from home (myself included), the office is rarely all that busy. This event though… Well let's just say this is the first time I've ever really had it impressed upon me just how huge Ubisoft Montreal actually is. It was genuinely shocking to see just how many people were there for the barbecue, drinks, and concert. People from every department and project, from all kinds of backgrounds. I don’t have the exact numbers, but it was definitely in the several hundreds, if not thousands.

For someone who places as big of an importance on networking as I do, this was a treasure trove. So, allow me to give you a play-by-play of my time at the event and what I did there, and highlight the value of good networking.

Oh and to be clear, when I say networking, I mean more than just exchanging business cards. I'm talking about the whole social experience of building connections with other people. Making business contacts is networking, but making friends is also networking. In my definition, networking is about building positive relationships with people, no matter what those relationships are. The benefits to building those relationships are broad, and appreciating that is key to taking full advantage of your network.

Afternoon

At first, I spent most of the party with some of my friends. These are people I knew back when I worked at Gameloft that also happen to work at Ubisoft now (this isn’t unusual; despite its actual size, it's a surprisingly small industry). We got some food and drinks to start things off. It was a comfortable start to get myself in the social spirit. Even if there's plenty of opportunities to meet new people, it's important to maintain your existing friendships as well. After all, tried and true comrades are the ones who will do everything they can to help you when you need it most. There's also nothing for you to prove to them, so you can relax, be yourself, and have fun. Having fun is essential to living a healthy life, so don't forget to do it! You’d be surprised how many people do.

As we were together, we ran into other former associates. Most were people who also used to work at Gameloft, but that I didn't keep as closely in touch with. We shared pleasantries and also talked about what we're up to these days. It's never a bad idea to say hi to former associates (unless there's some baggage there that is best left alone; not engaging in toxic relationships is just as important as engaging in healthy ones). In this particular case, these reconnections had a bonus payoff. One of the guys I had worked with previously shared my concerns about some workflow issues that have been causing issues for our team (and me especially), and as it so happened, he's going to be moving to the team that handles that workflow. I know him to have a similar philosophy to myself when it comes to having fast and adaptable solutions through good tools, so I know that he would be a good ally to have. I shared the fact that we were having ongoing discussions with the team he was joining, and he asked that we add him to that conversation so that he can help us drive the initiative. There was no reservation about it because even though we aren't especially close, we do have a good past relationship built on trust and mutual respect. This conversation would have been much less likely if I didn't have that relationship. Me from 4 years ago just made my life today a lot easier!

After that, I spotted the creative director for Siege. I made a point to say hi and congratulate him on his part in representing our team at the presentation. Some people might call that brown nosing, but those people are being silly. Commending people for good work is a good thing to do no matter who they are. Your positivity not only makes their day a bit better, but also reflects well on you. If they happen to be higher up in the ladder, then all the better. Regardless of that, Alex Karpazis is just a really chill and smart guy. I'd want to be his friend regardless of his job, and setting aside any notion of politics, I’m really happy that he’s our new creative director for the game.

Storm

My next stop after the old friends and acquaintances was my new friends. I ran into the programmer I work most closely with these days and we shared a few drinks and chatted casually. I've been fortunate to have pretty capable teammates, and this guy is no exception. I got to learn more about him and we had a good time. We even helped each other out when the park was suddenly hit with an aggressive blast of heavy rain (he had an umbrella, and I had a free pair of hands). It should be pretty obvious why building a good relationship with the people you work with is valuable. We're close enough that we can talk openly about our work and what we can do to make each other's lives easier, and that's good for us as well as the game.

Another fun thing happened around this point in the evening. While looking for some of our other teammates, we ran into my best buddy from Gameloft (who I was with during at the start of the event), as well as another former Gameloft employee who left before I joined, but with whom I shared many mutual friends (there really are a lot of former Gameloft employees at Ubisoft; sometimes that's just how the industry goes). We ended up playing hacky sack (I absolutely suck at it, for the record) and hung out. The magical thing here is that my new work buddy and my old work buddy started chatting and seem to have built up a rapport themselves (incidentally, their relationships with me work-wise are both very similar). One of the fun things about networking is that sometimes you end up being a bridge for other people to network as well, and as far as I'm concerned that's all the better (this theme will come up again later).

Night

A little while later I ran into a few other people from the programming side. I did some commiserating with one guy over the lack of a designer on their team. I helped their team out before to pick up the slack when their old designer left, but it's clear they need a dedicated replacement. I may have inadvertently made myself a candidate during that conversation, though the one thing I could definitely offer was that as our team works on improving our structure and workflow, we will surely be able to share some of our experience to help them with theirs. Networking is not just about what I can get from others, but also what I can give to them. I want their team to succeed too, after all!

I then ran into one of the programming leads, who happens to be in charge of one of the features I'm working on (I can't say what that feature is, but I can say that people in the Siege community have been asking for it for years). He’s someone I've been getting along with quite well, and whom I respect a lot. It’s a relationship I’m more than happy to continue building on. We and a few others got into a longer chat about some interesting topics, mostly relating to narratives that challenge player perception. The original Tom Clancy Rainbow books, Spec-Ops: The Line, and the infamous “No Russian” mission were referenced, to give you an idea of where we were at subject-wise. Quick disclaimer though, none of this had to do with what's actually being worked on at the studio; we were talking about hypotheticals of what we'd like to see. Nevertheless, the conversation was both fun and informative. I learned about some of the aspirations people have for the R6 franchise, and also got to show off my designer brain (I ended up turning a controversial topic into a potentially interesting new game mode idea). I adore intellectually stimulating conversations like those. they really fire up my neurons and get me inspired. In my experience, you can get more new ideas from one engaging conversation than you can from days of sitting alone contemplating. Maybe it's just me, but there's something about the act of communication that just jogs my design mind.

As the day turned into night, I mostly cycled through the groups I had acquainted myself with, catching up with people here and there. I did get to see some interesting stuff about a really neat prototype that I didn't know existed until Zeitgeist. Turns out it's being made by a six-man team that used to help us out back when I was at Gameloft, including the very first guy I worked with there (I have a story about that which I’d like to write about one day, but today is not that day). I also got to see that same team interact with leadership on the Siege team. Yet another relationship that might bear fruit one day… Oh, there was also a concert and a bit of dancing, but once again, my feet are not good at things that are not walking and quickly traversing stairs.

I was presented with an RPG-style choice at the end of the night. My old friends were going to go to our former watering hole for drinks and casual catch-up. However, I was also invited by the programming lead to go to a karaoke party. So, do I take the safe option and unwind with the old buddies, or do I go with the group of strangers and make some new friends?

Afterparty

It was actually pretty tough for me to decide, but I ended up going with the new group. Quite simply, I won't often get opportunities to spend time with the gameplay programmers, and given my ambitions and desire to continue bridging gaps between teams, it seemed like a golden opportunity. I also low-key really like doing karaoke, even though I almost never do so publicly. Amusingly enough, my decision resulted in my old friends joining me, so win-win!

One additional anecdote I'll slip in here is that while heading down, I chatted with a game dev veteran from the studio's tool team (my programmer friend and I helped him out earlier during the heavy rainfall by sharing our umbrella, so we were somewhat acquainted). He had worked on Siege way back when it first started, and helped set up the destructible environment tech that our game is famous for. He also has worked for 27 years (I think that was the number) in the industry, including on at least a few games I played as a kid. It's crazy to think that there are people that have been working in the industry for as long as I've been alive… Oh, and when I asked him about his war stories, he hit me with one that I never expected: turns out he worked on the infamous Duke Nukem Forever! I learned some interesting things about the conditions under which that game was finally finished and released (spoiler: they were bad). I adore getting weird little knowledge nuggets like that. The game industry is full of them, if you bother to look around.

In the end, the karaoke bar was overcapacity, so we went to the adjacent pub for some drinks. I got to have some deep chats about Siege and the teams that work on it. One of my old friends (from that six-man prototype team) joined us and basically fell in love with our gameplay programming team (once more, a possibly advantageous future relationship in the making). I got to see my best friend and mentor drunker than I've ever seen him (I helped him to his Uber when the night was done; love you Chris). Then I rounded the night by having a good chat with another programming lead that I was less acquainted with. We ended up getting pretty deep into things regarding the team as well as my own aspirations. It may very well end up being a relationship that could greatly help me in the future.

Conclusion

The moral of the story is that the greatest magic of industry events (or any social gathering really) is that they bring people together. Humans are social creatures, and making games is a collaborative experience. The more we connect with each other, the more resources we have at our disposal, be it to accomplish tasks, to make new partnerships, to share knowledge, or just to have fun. Every relationship you make can have value, even if in some cases it can take years for that value to truly manifest. One of the greatest things I learned to do when I started pursuing a career in games was to learn to network, despite being very introverted and shy. It's made me a better designer, and I'd argue that it's made me a better person as well. I've learned a lot from other people, and it's from that knowledge that I've gotten to where I am today. Those same people have also helped me at many points in my life to accomplish things I simply couldn't on my own. I cherish those experiences, even the minor ones. It's for that reason that I cannot recommend enough that you go out there and socialise with people whenever you can. If more people put more effort into interacting with each other, I'm certain that the world would be a better place.

Bonus: Epilogue

There was one last fun little part to this story. So remember how my programmer friend had an umbrella during the sudden storm? Well, I also had an umbrella (because I checked the forecast that morning), but I had foolishly left it at my desk. I didn't particularly want to have to come back next week to get it, so instead I figured I'd swing by the office to grab it before going home that night.

The only thing is that by the time we had left the pub, it was around 4 in the morning. The metro that would take me home stopped hours ago, and an Uber would be pretty pricey (not to mention my phone was almost dead). However, it also just so happens that the trains in Montreal start up again at 5:30am. Therefore, what I did was enter the studio, go to my desk, and chill for an hour (I actually did a bit of work and replied to a couple LinkedIn messages from aspiring designers asking for advice). I also ended up wandering around the office and checking out all the floors and rooms. There's something special about exploring a place when no one is around. I got to check out all the cool figurines people had on their desks and see where all the other teams worked (I didn't touch anything though, just to be safe). If you ever happen to get the chance to explore an empty place in the dead of night, I recommend it (so long as it's safe of course). It's a really cool experience.

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!

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.

My Journey / Ma Piste

As I mentioned in my last blog post, I'd be writing a piece for one of my classes in the DESS en design de jeux program detailing my history and goals as a game designer. As I also mentioned, it would be in French. More likely than not, I've gone over much of this already in the past, but nonetheless, I thought I'd share it here. Fair warning, it's fairly long (it is a 3 page dissertation, after all), though given my track record really it's hardly out of the ordinary I imagine. In any case, enjoy.

Depuis que j’étais très jeune, je savais que je voulais être un créateur. À ce moment je ne connaissais pas le domaine des jeux vidéo, mais je voulais devenir un inventeur. Plus tard, ce rêve devenait "ingénieur". Cela semblait un bon choix, étant donné que mon père était ingénieur et que sa famille m'encourageait à viser une profession prestigieuse de ce genre.

Toutefois, vers le milieu de mes années au secondaire, je n’avais pas beaucoup d’amis, alors j’avais beaucoup de temps à réfléchir. À ce moment, j’avais déjà un intérêt dans les jeux vidéo, mais c’est avec ces années de solitude que je suis venu à les apprécier comme un outil pour interagir avec le monde, soit tout seul ou avec d’autres personnes en ligne. Je me trouvais particulièrement intéressé dans la dynamique des équipes dans "Call of Duty" (Modern Warfrare 1 et 2, et ensuite Black Ops). C’était justement pendant la fin de cette période, en 11e année, que j’ai révisé ma vision pour le futur. Au fur et à mesure que je trouvais les sciences et les mathématiques rigoureuses du Baccalauréat international trop sec, plus que je m'intéressais aux arts et les poursuites créatives. Toutefois mes talents artistiques ne satisfaisaient pas mes intérêts en pratique. C’est à ce point que j’ai fait ma recherche et j’ai découvert le domaine du design, et j’ai pu immédiatement reconnaitre ce domaine comme étant la fusion parfaite de la science et de l’art.

Une fois gradué du secondaire, j’ai appliqué pour le programme de design de jeux à l’UOIT et le programme de multimédia et design à l’Université Carleton et le Collège Algonquin. Le dernier fut mon premier choix, dû à la proximité de ma maison. J’ai annoncé mon choix comme étant en ingénierie (ce qui est techniquement la vérité, alors que le programme est dans le domaine du « ingénierie et design ») à ma famille par contre, afin de ne pas avoir trop de résistance à choisir un domaine moins prestigieux. Ils ont découvert la vérité éventuellement, mais trop tard pour me prévenir. À ce jour c’est encore un débat avec quelques membres de ma famille, et ils m’encouragent encore de temps en temps à retourner à l’école pour poursuivre une « vraie carrière », mais je suis de plus en plus convaincu que mon choix était le bon.

Mes convictions viennent du fait que dès la première année au programme de multimédia interactif et design (« IMD », une des branches du baccalauréat en technologie d’information « BIT »), j’ai eu un sentiment que je me trouvais dans la bonne place. Quoique je n’aie jamais été un mauvais étudiant, le design m’engageait d’une manière que d’autres domaines ne le faisaient pas. Je me suis rapidement distingué pour mon habileté d’organiser et déconstruire les systèmes, et cela est devenu ma passion.

C’est également pendant mes études à Carleton que j’ai développé formellement mes intérêts dans l’anthropologie, la sociologie, et la psychologie en faisant des études en dehors de l’école. J’étais toujours intéressé dans ces concepts, mais je ne les connaissais pas en mesure de domaines académiques. J’explorais plutôt ces sujets en observant les personnes et l’histoire. Les systèmes de politique des années 1900 ont été d’un intérêt particulier, particulièrement l’évolution du communisme en Russie. Ce que je trouvais principalement fascinant était l’évolution des idées dans la pratique quand les personnes s’introduisaient, et comment un système pouvait s’évoluer d’une manière tellement inattendue à cause de mauvaise implémentation. Durant mes dernières années à l’université, ces mêmes idées me sont revenues en grande force avec l’arrivée des gros débats socio-culturels et politiques. Mon désir d’explorer ces concepts s’est intégré dans ma passion pour le design, alors que j’aimais principalement créer des jeux qui exploraient ces idées au niveau narratif ainsi que dans les mécaniques des jeux.

Par le temps que j’ai gradué, je possédais déjà un plan général. Premièrement, j’emménagerais à Montréal, car c’est ici qui se trouve la majorité des grosses compagnies de jeux vidéo sans être trop loin de ma famille à Ottawa (également, je ne voulais pas sortir du Canada, et je voulais trouver une ville où mon bilinguisme me serait utile). Deuxièmement, je trouverais un emploi dans une des compagnies majeures, tel Ubisoft ou EA. Quoiqu’il y ait un temps que j’aurais voulu éventuellement devenir le directeur créatif dans une de ces compagnies (j’aime bien Assassins Creed, Mass Effect et Dragon Age), j’ai reconnu que même si je me distinguais, ma contribution créative serait toutefois plutôt minime avec tellement de grands projets. Alors troisièmement, une fois que j’aurais assez d’expérience et de connexions dans l’industrie de jeux (que j’estime prendrait entre 5 et 10 ans), je me déplacerais à une compagnie de taille petite ou médium, afin que je puisse mieux m’engager dans mes poursuites personnelles. En cette mesure le troisième but est assez général, car je veux demeurer flexible et être prêt à sauter sur les opportunités qui se présentent, plutôt que de les laisser passer à la recherche de l’idéal.

Trouver une place n’a pas été trop difficile, alors que je me retrouve maintenant dans une espace idéale pour moi. La deuxième étape par contre m’évite à présent. Alors que je me trouvais à un certain désavantage, ayant très peu de connexions (ou au moins des connexions utiles) dans l’industrie à Montréal. Mon portfolio également, quoiqu’il soit bien visé au design de jeux, n’est pas aussi fort que je crois qu’il pourrait l’être. Malgré mes efforts à faire le networking, mon progrès était lent, alors que je me trouvais souvent en train de tout simplement envoyer des résumés par email de la manière familière et sans avoir de réponse. Quand j’ai trouvé du travail dans l’industrie, ce fut à faire les tests utilisateurs pour les jeux de King avec Crowdsourced Testing Company. Quoique ce soit techniquement dans le bon domaine et ça me permet d’avoir de la pratique à l’analyse du design, ce travail ne me donne pas beaucoup d’accès aux opportunités d’avancement dans le design de jeux. Également, plusieurs évènements dans la famille ont fait que j’ai dû souvent retourner à Ottawa, divisant le temps que j’aurais autrement mis vers des projets et le networking.

En fonction de mes résultats, j’ai fait de la recherche pour les études de jeux plus avancés à Montréal. En effet, cette idée est venue directement de quelques commentaires au panneau de recruteurs à MIGS 2015 : ils ont noté qu’il y a une certaine préférence ou avantage pour ceux qui ont fait leurs études au Québec. Ma logique fut alors que s’ils cherchent des gradués du Québec, je deviendrais un gradué du Québec. Ça me semblait une bonne piste afin de trouver des connexions et me donner un environnement où je pourrais renforcer mes connaissances ainsi que mon portfolio. Quoique je n’aie pas trouvé de tels programmes auparavant, cette fois-ci j’ai trouvé le DESS en design de jeux, et il me semblait être exactement ce que je cherchais. Heureusement, j’ai réussi à rentrer, et alors je me trouve ici à présent.

Mon but une fois gradué du DESS est d’encore une fois faire mon essai à rentrer dans l’industrie par une des grosses compagnies (quoique je n’aie pas d’opposition à d’autres pistes s’ils se présentent). Éventuellement, j’aimerais me retrouver comme étant un designer de systèmes et narratifs qui encouragent les joueurs à considérer la société et le monde qui les entourent. J’aimerais que par l’exploration des choix complexes et les situations engageantes, ils se trouvent inspirés à transférer leurs expériences dans le monde réel afin de s’engager d’une manière plus conscient. Je veux créer des jeux qui font penser et discuter les gens, alors qu’ils désirent s’interroger du monde tout en se divertissant dans la même manière que les jeux m’ont tel impacté. En ce moment, le domaine qui m’intéresse le plus est l’idée de la compétition et la coopération, et comment ces paradigmes d’interaction entre joueurs peuvent être manipulés. C’est une idée que j’ai essayée auparavant avec mon projet final à l’IMD, mais pour lequel je ne possédais encore pas les ressources ou habiletés pour bien explorer.

Quoique je ne connaisse pas de compagnies qui explorent spécifiquement ces sujets au niveau que je cherche, Eidos est toutefois en ce moment mon choix idéal, justement à cause qu’ils explorent déjà plusieurs de ces idées. Alors que je sais que c’est toutefois une grosse compagnie, sa culture ainsi que les jeux qu’ils produisent touchent sur les concepts de société, choix, et conflit qui sont mes passions. Leur genre de jeux m’attire, alors que mon côté idéaliste espère un jour me trouver à travailler sur le prochain Deus Ex, ou sinon son successeur spirituel. Mes propres concepts de jeux sont toujours mes buts ultimes, mais je serais très satisfait si je pourrais introduire plus de mes idées dans cette série afin de pousser ses limites, de la manière que le premier Deus Ex l’a fait avec les jeux de son temps. En effet, mon premier concept de jeu (qui était auparavant un concept pour une bande dessinée) ressemble très fortement au premier Deus Ex, quoique je ne le connaisse pas à ce temps. Alors, c’est possible que mon désir vienne de vouloir « reprendre » mon concept, d’une manière à dire.

Je ne sais pas encore si mes buts sont réalistes, ou même trop simples. J’entends tellement souvent dans l’industrie les discussions de l’innovation et des idées tellement radicales que je demande si je suis conservateur. En même temps, je suis très conscient du niveau de faillite qui vient avec pousser trop loin de la réalité. Je reconnais que je suis dans la mauvaise industrie pour la stabilité, mais il y a toutefois des limites sensibles aux risques calculés. Enfin, je suis très confortable avec mes buts. Ils ne me semblent pas hors de mes habiletés, mais ne sont toutefois pas trop simples non plus. En réalité, si je peux au moins inspirer une personne à poursuivre leurs intérêts de manière productive, ou autrement améliorer la vie d’une autre personne par mes créations, je serais très satisfait.