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.

ZDSkills Interview

Last week I got asked if I would do an interview with ZDSkills about being a game designer. At this point, I’ve certainly talked about game design quite a bit, though it’s been a while since I’ve really done it from a personal perspective. This interview gave me a chance to self reflect a bit, so it was a fun experience!

You can see the interview on their site, but for posterity I’ll put my answers here as well:

Tell us a little bit about yourself. What do you do and how did you become a Game Designer

Hi, I’m Justin, and I’m a game designer at Ubisoft Montreal, currently working on Rainbow Six Siege!

As a game designer, my main job is to act as the conceptual anchor for my team. That means not just coming up with ideas for new features in the game and fleshing out how those features would work, but also being the bridge between the various disciplines involved with making games. That means a lot of communication. On one hand, I have to talk to programmers, artists, and other technical people to make sure that the ideas I come up with are realistic, and figure out how they’d it into our game. On the other, I have to talk to directors, producers, and external resources to convince them that my ideas are worth putting time and effort into. I have to sell all of them on the fantasy of my ideas, and then keep everyone on track for building them.

Oh, and sometimes I also have to make flowcharts or fill a whole bunch of spreadsheets with data tables. When I started this career, I didn’t expect that most of my job would be in Excel and PowerPoint, but they really are some of the biggest tools of the trade.

As for how I became a game designer, I specifically took a path towards it as soon as I got out of high school. I studied at Carleton University and Algonquin College in Interactive Multimedia and Design, moved to Montreal to get closer to the games industry, went back to school for game design at the University of Montreal, and after several years of working on small indie titles, I landed an internship at Gameloft as a Technical Game Designer, and game design has been in my job title ever since. Basically, I just persisted aggressively until I got through the door. Once you’re in, you’re pretty much set.

Can you give us a brief look into what inspired you when you were young? Did family or friends influence your decision to get into games or was this something you became interested in on your own?

For me it was very much a personal thing. Most of my family wanted me to become a doctor, lawyer, and/or engineer. Luckily Carleton calls it the “Faculty of Engineering and Design”, so that’s how I slipped it past them.

I always knew that I wanted to be a game designer, even since before I knew that game design was a profession. My family has a background in law, diplomacy, and engineering, so subjects of how systems and people interact with each other and themselves have always interested me. When I was a kid, I framed this as wanting to be an inventor.

I had always liked video games, but it’s really in high school that I fell in love with them and their potential for exploring new worlds and ideas in a way that other forms of media simply couldn’t. When I saw just how it could bring people together through shared experiences, I knew that that was something I wanted to be a part of. I’ve been chasing that dream ever since.

 

Do you think your education in product and industrial design has helped when designing games or may be given you a different perspective when approaching unique challenges?

One of the most critical things about being a game designer is being able to wear many hats. Because I interact with people from all sorts of different technical and experiential backgrounds, I need to be able to communicate with them, and that means understanding their perspectives.

In a sense, I was very fortunate with my upbringing and education. My schooling in high school put an emphasis on STEM, while all my hobbies were more artsy. My first university studies covered design in a very broad sense, so I got to touch a lot of different types of design: web, product, film, animation, and of course games to name a few. Working co-ops in more technical places gave me a much better understanding of just how many considerations go into creating something, no matter what that thing is. There’s a whole lot of moving parts that all interact with each other, and as a designer, it’s your job to see the big picture of what those parts are and how they’re all connected. That applies as much to the game itself as it does to how the game is produced.

The sense of perspective you need as a designer is something that can only be enhanced by having as broad a range of experiences as possible, and I’d say my past experiences helped me a lot with developing that perspective.

 

I remember a few professors that genuinely helped me improve and was wondering if you have any mentors or people from your past that helped inspire you and how?

I’ve been lucky enough to have some good profs and mentors. Back in high school I had Madame Robineau and Monsieur Deschenes that encouraged my passions and gave me the resources to pursue them. In university, I had professors like Doctor Arya, Monsieur Sormany, Mr. Keon, Monsieur Nataf, and Monsieur Cauchon that all were all too happy to give me some much-needed foresight into what the games industry is actually like and what sort of things I needed to develop to make a career of it myself. Then once I got into the industry, I was fortunate enough to work under Chris Budgen. He’s been my boss and mentor for almost 5 years across two studios and three titles and has helped me not just by sharing his experience and expertise, but by being supportive of my growth as a designer. I’m incredibly grateful to all of them, because without that support, I wouldn’t be where I am today. Everyone should be so lucky as to have people like that as they pursue their future.

That said, beyond just a few mentors, one of the things that really helped me in my early career and that probably set me apart from a lot of fledgling designers was all the time I spent with professionals in the industry. I went to a lot of industry events and chatted up people from all sorts of disciplines (which was not easy; I’m very introverted). Every single one of them had their own interesting stories and experiences from their time in the industry, and that really helped to paint a picture of what making games is really like and what challenges I’d have to deal with. A lot of people come into the video game industry with an idealised or otherwise distorted impression of how it works. Getting that dose of reality early on really helped me connect with the people I now work with, and made things much smoother for me overall. That may sound depressing, but it’s actually quite the opposite. I actually like the sausage better now that I know how it’s made, because I can appreciate all the things that go into making it work.

What or who inspires you today? Are you a member of any art communities? Any favorite hashtags you check on a daily basis?

I try to keep to that spirit of drawing from many influences, so I’d have a hard time telling you any one thing that inspires me. I spend a lot of my time consuming media of all kinds: games, movies, TV, books, anime, manga, streamers, Youtube, and a whole lot of art, just to name a few.

That said, something that I’ve really gotten more and more into over the last decade is tabletop gaming. TTRPGs have been a way for me to channel a lot of my creative energy. I write character journals, I sketch characters and maps, I come up with encounters and mechanics… A lot of my free time goes into building worlds and stories for that hobby of mine. As a result, I’ve also been collecting a lot of cool character art as inspiration. Right now, I’d say that’s what’s been inspiring me the most.

 

What’s your favorite aspect of creating a Game Designer? (*I assumed this was meant to say “being a game designer”)

At the end of a day, I’m someone who really likes both the technical and the creative. I get as much of a thrill from a good story or beautiful art as I do from a neatly formatted spreadsheet or an elegant gameplay loop. What I love about game design is that it lets me indulge in all of those things at once. The human experience is incredibly diverse and multifaceted, and I think design as a profession is a reflection of that. Blending the imaginative with the practical means I don’t have to limit myself to one or the other, and I wouldn’t have it any other way.

 

Please tell us your five short tips for creating Level Design?

  1. Be consistent with the narrative. Levels in games are a key part of the narrative, and I’m not just talking about the written story. The gameplay, plot, and environment all need to feed into each other to produce the game’s narrative, and when these things don’t harmonise with themselves or each other, it can be really jarring. The layout and appearance of a level should reflect what feelings the player ought to be experiencing. For example, if the player is supposed to feel a sense of freedom and power in a certain moment, don’t put them in a tight claustrophobic environment.

  2. Tie everything together. Something that is always really cool in games is when you realise just how every part of the level is interconnected in a way that makes sense. There’s a special satisfaction in unlocking a shortcut and finally understanding what that locked door you saw earlier was leading to, or finally getting to the big tower you saw in the distance at the start of a level. People like that feeling when the individual puzzle pieces come together, so try to build that feeling into your level design. If you need some inspiration, the original Dark Souls is a fantastic example of this (and there are hundreds of video essays about it).

  3. Don’t have too much clutter. A common rule in design is that simple is best. Attention to detail is nice of course, but too much detail can cause the player to get distracted. Put the most attention of the things the player ought to be paying attention to the most, and don’t lose the forest for the trees.

  4. Give your levels variety. Everyone’s played a game or seen a show where everything feels samey. Repetitive level design can really drag a game down, so avoid copy-pasting chunks of your level. That doesn’t just apply to looks either. Mix up how linear or open-ended your levels are, or the scale of the level, or even verticality. Doom 2016 is a masterclass on creating varied level design while keeping to a consistent overall theme.

  5. Consider multiple angles of approach. If there’s one thing I’ve learned as a game designer, it’s that players will always find ways to surprise you with how they approach a problem. Some people try to limit this and force players into certain behaviours, but my suggestion is to embrace it. Players love when they try something crazy and it ends up working, so reward that feeling through your level design. Give them reasons to explore and make your situations work with that, rather than forcing them into a single “correct” path.

Thank you!

It’s been my pleasure!

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!

An Update Long Overdue

It has been quite some time since I last posted here, hasn't it? A little over half a year, in fact. Truth be told, I've wanted to post here long before now, but despite having an abundance of things to write about, none of them really gave me enough motivation to do so. Not to mention in the last two months, my life has been so hectic that this is the first weekend I've actually been able to just sit down and rest. But I digress.

A lot has happened since the last time I made a blog post on this site: I've participated in four game jams (for one of which we won the best game award), I graduated from university (again), I made a great deal of progress on several of my personal projects, and perhaps most importantly, I got my first job in the industry. Though there are a great many things I could say about all of these things, the last one is the one I really want to talk about. After all, this blog is by and large about my professional development, and what bigger thing is there than my first position in my desired career?

Granted, it's only a 6 month internship, but being placed as a technical game designer at a major studio (Gameloft, if you're wondering) is certainly a huge step for me. It's quite potentially that foot in the door that I needed. Either I make myself invaluable enough to them that they choose to keep me on after my contract is done, or I have a very nice addition to my CV. And that's not even accounting for the connections and experience I gain along the way.

Experience. That word has perhaps been at the core of all of my challenges so far. As someone just getting into the industry, there's a fairly major issue with the fact that almost every single posting you can find requires some form of experience. You need work experience to have your application recognised, if even looked at at all (I know many recruiters deny this, but I've yet to see evidence to convince me otherwise). And even if you choose to go the networking route, that requires a certain level of social experience (in other words, useful contacts). On top of that you need the luck to be in the right place at the right time, and have exactly what they're looking for. Of course, all of this makes a certain degree of sense; a company has needs, and they can't just hire a complete unknown in the hopes that they'll turn out to be good. That's a huge risk. On that front, I had the good fortune of being at exactly at the right place at the right time and having both social and skills experience I could leverage to get in. After all as I've said before, I know I have the abilities needed to be a good designer. I just need people to know it.

And that's where my new challenge lies. I've gotten into a company, at least for a few months. I've been assigned to a project. A new one at that, with a much smaller team meaning I get to have much more input than I might otherwise have had. It's intimidating, but at the same time, it's exactly the kind of opportunity I should be hoping for. But there is a snag there. I can only prove myself if I get the chance to demonstrate my skill, and in order to do that, I have to get people to listen to me.

You see, even though I've gotten in, I have no authority, seniority, or rapport with the people I work with. In other words, I have no experience. Not in this context. As a technical designer, my job more or less is to figure out the structure of a given task, and then tell the programmers what tools or features I need to execute that structure. The problem lies in the fact that even though I can easily define a system, I have to get the programmers to go along with it. This is the part that is difficult. As of the present moment, I don't think the programmers on the team fully understand just what my role is. Truth be told, I'm not entirely sure I do myself. What I do know is that on at least two occasions, I've noticed early on that an existing system I've been asked to work on was flawed and pointed out the thing that we needed, was subsequently told by a programmer that this was not the way things were built, and a week later found out that the programmer was told by someone higher up to essentially do the same thing I suggested a week earlier.

Now don't misunderstand. This isn't me complaining about my coworkers or even stroking my own ego for ultimately being right. At the time there were very valid reasons for building things the way they were built and not accepting my proposals. After all in these instances what I was proposing were akin to massive overhauls of how the existing systems worked. And I am a junior with no real authority after all. What would I know of how their systems worked? These guys not only have technical knowledge that I don't, but experience with the engine that allows them to know that certain solutions I might have taken as obvious choices to be impractical and unstable. These are fair criticisms that can be levied against me and my proposals, and I have no real defense against them. In fact, I can think of a lot of young boiterous designers who might come in and say everything is wrong and needs to be redone, when in fact they have no idea what they're talking about. There's yet to be any evidence that I'm not one of them (I mean, I know I'm not, but I do have something of a bias on the subject so its not like they can take my word for it). In the end however, the fact of the matter is that time was wasted, either by me or the programmers, on trying to force a system that didn't meet our needs to work. It's an inefficiency that has lost a modest amount of time and energy, and it's a problem I know can be fixed. After all, I've done it quite a few times before.

Something important to point out here is that I'm not entirely ignorant of how programming works. In all of the aforementioned game jams I participated in, I was the lead programmer. Part of what helped us get so far in those jams was the simple fact that being both a designer and a programmer, I could future proof and structure my code in a way that made it easy to build on as time went on. I could define the scope from both the perspectives of what we needed to make a functional game and what I could program in the time we had. But in the context of a larger company, there are way more things you have to consider. There isn't only one programmer, or one system. Sometimes the code defines the structure, and all the designers supply is the stats for it to parse. Sometimes even when both of things are working together, there's an element from another department that throws a wrench in the mix. I'd love to give more concrete examples, but I fear doing so pushes the edges of what I can say with my contract, and the last thing I want to do is jeopardise that.

Naturally, it would be easier if I had the authority to simply say "do it like so" and have everyone follow my authority. But of course, that's not how things work, at least not here. All of the problems I mentioned are natural in a team environment. One can expect toes to be stepped on, and for communication to lapse here and there. But these downsides are worth it for the wealth of benefits that having a dynamic team grants. It allows individual parts of the whole to be self sufficient and solve their own problems, in a way that's much more creatively liberating and efficient than it would be with a single dictatorial entity. The difficulty I see is when the communication between these parts is limited, and one side can see a problem than another can't or won't, either because they have a blind spot from their perspective or there are other implications that the other side might not even be aware of. How do I broach that gap to point out issues so that they can be resolved without being dismissed? Is it simply a matter of seniority? Is it a question of how I approach the subject? Or perhaps it's about whom I approach it to? Maybe it's just power politics? These are matters I still need to work on.

In the remaining month (almost exactly. The 26th of December is when I'm slated to have my first day of vacation, not including Christmas day and the weekend prior), things are going to be very hectic for me. A major deadline is looming and though the issues I've pointed out have by and large been resolved, it doesn't stop the fact that I'll have my work cut out for me rearranging things in light of these new structures. Somewhere in between that, I'm going to have to try my best to seek out an answer for that challenge of mine. If I do figure out what the magic recipe is, I'll be sure to let you know. Until then, I'm open to suggestions.

P.S. It isn't lost on me that the subjects of my recent game jams and how I got the position might also be a compelling subjects to discuss. I certainly have a fair bit to say on them. But that's probably best saved for future posts.

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

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

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

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

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

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

 

Tip 1: Know your inner DM

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

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

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

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

Tip 2: Know your players

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

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

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

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

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

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

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

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

Tip 4: Leave no rules ambiguous

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

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

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

Tip 5: Set boundaries for your game

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

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

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

Tip 6: Have a session zero

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

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

Tip 7: Keep a rulebook handy

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

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

Tip 8: Keep notes for yourself

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

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

Tip 9: Use secret modifiers

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

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

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

Tip 10: Give your scenes flavour

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tip 15: Give meaning to character deaths

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

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

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

Tip 16: Know what your players are comfortable dealing with

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

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

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

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

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

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

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

Tip 18: Steal good ideas from others

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

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

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

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

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

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

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

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

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

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

Tip 19: Play in games

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

Tip 20: Have a life

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

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

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

Conclusion

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

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

 

Homestuck's Conclusion and Or8Weaver's Evolution

On the 13th of April of this year, Homestuck concluded after 7 long years of being one of the longest and most popular webcomics out there. It's easy enough to look up this monolith of an internet cultural icon, so I won't go into detail about it. Instead, this is about my relationship with it.

I was a fan of MSPaintAdventures and Andrew Hussie's works since quite a long time back. Before even the Problem Sleuth days. However, it's with Homestuck that I actually started getting into the fandom. In fact it could be argued that Homestuck is what brought me into the world of fandoms to begin with (I wouldn't really count my time in the Playstation or Ratchet and Clank forums as such). It started with the old Skaianet Imageboard, then I began roleplaying with Trollmegle. Later I moved over to DeviantArt and the Pesterchum application for art and roleplay respectively. I had a lot of fun with the Homestuck fandom. I learned a great deal about internet culture, the very concept of roleplaying (which in turn helped me with my writing and character design skills), and it pushed me to draw and create various things. It's also what prompted my exploration into the concept of crossovers, which until then I didn't really know to be a thing. And the fact that all of these stemmed from one fundamental source was awe inspiring to me. That something so mundane as a cleverly written comic could fuel such a microcosm was baffling.

Then of course, there were all the friends I made from it. Between friends I made through RPs and art collaborations, I actually amassed a fairly high number of online pals. I still keep in touch with some of them, though most I've since lost contact with. However one person in particular I still keep close with, as our interests shifted over to include video games and other hobbies. But alongside those other hobbies, there was always our collaborative RP project: Or8Weaver.

Now, Or8Weaver has been going on for over four years (since the 16th of December 2011), and is still going strong. In fact I'm literally writing it in another window as I type this. Or8 has served as a testing ground for a lot of concepts for me, both in terms of mechanics and narratives. However, despite how much it's deviated from the original source, the fact that Or8 is a derivative fanwork has always loomed over it. Evidently, there's not a whole lot I can do with it in any practical sense that wouldn't breach copyright. This is something that up until recently I was never particularly bothered by. After all, Or8 itself is more of a personal thing. But then there was FateWeaver, the game I had been converting the setting to be used in. And as I've gotten deeper into my plans for that game, this particular issue has come to the forefront of my thoughts.

Just a few days before the end of Homestuck, I had one of those thoughts one gets as they're laying in bed trying to sleep. It was an idea about how to convert the hemospectrum aspect of troll society into its own unique system using the seven deadly sins as bases (admittedly, I might have an anime I watched recently to thank for seeding that particular thought). Over the following few days, I fiddled a bit more with the concept, and though it's still a good ways from completion, I get the feeling that I can very feasibly proceed with converting the entirety of the Or8 setting to remove any references to Homestuck. Most of the content was already of my own creation, with only some nomenclature and core elements coming from the original material, so in truth it's actually not all that much work for me.

All that to say, though it won't change anything for now, I've begun an alteration to Or8Weaver that will allow me to convert a fan project into something of its own. Really it already was at this point. I just needed that little extra push to change the label. In time, as I continue to make the modifications to the Fate system and the Or8 setting, my hope is that some time in the future, I might soon have a full tabletop setting of my very own. It's a project I'm very much looking forward to developing further. And while I have Homestuck to thank for being the catalyst that brought about its conception, there's a sense of great accomplishment in knowing that with Homestuck's conclusion, Or8 will be reborn and live on.

I've gotten a bit rambly, so I'll leave you with this sketch I doodled recently. It's a rendition of my Pathfinder version of Astrea Maryam (who is an important character in Or8). Not much else to be said there, other than playing a spellcaster has proven much more fun that I thought it would be, and that I've thoroughly enjoyed playing her in all her renditions.

DMing A Tabletop Game: First Book Post-Mortem

As of the time I'm writing this, I fairly recently completed running "In Hell's Bright Shadow", the first book of the "Hell's Rebels" campaign for the Pathfidner Roleplaying system. This is a retrospective on my involvement with tabletop, my views on the game itself, and how it's helped me better understand game design.

Tabletop

My experience with tabletop RPGs is fairly limited. I started with Warhammer 40K's Dark Heresy back in University back when some of my friends were in a small group. It took some getting used to (it didn't help that I knew next to nothing about the 40K universe at the time), but the experience itself was great and I got some fantastic stories out of it (the butter story, the sacred oil tale, and the self-destroying boss are some of my personal favourites).

Come August 2014, I tried getting back in touch with an old friend of mine from high school, and got invited into a Pathfinder game (Mummy's Mask) that he was running through a site called Roll20. We got to the end of the 2nd book before our party was wiped out, but it definitely made firm my interest in the game. After that, I researched and dabbled with some other systems (5e and Fate primarily), though most of my gaming has been with Pathfinder. According to Roll20, I've clocked just over 700 hours of time in-game. I've played in about 10 games (though only 6 of them got past the first couple sessions).

Pathfinder

The System

As I mentioned, Pathfinder has been my primary game system. I had the good fortune of having friends that knew the rules fairly well, because I can safely say that many of the rules for that game are rather opaque. It's generally said that between Pathfinder and D&D 5e, Pathfinder has significantly more content, but also a great deal more bloat in numbers and systems.

Overall, Pathfinder is a great system, and if you have someone willing to guide you, it's a fantastic way to start playing tabletop. It's built on the D&D core, so a lot of its ideas are very classic fantasy and therefore easy to recognise. I've used Hero Lab (another great tool) to make the character creation process easier to deal with. And gradually I've been stepping out of my comfort zone to explore more technically challenging aspects of the game. Notably, I recently started playing my first prepared caster (an arcanist), which is a big leap considering I don't usually play magic users (rogues are more my style).

All that said, as I've played more of the game, some of its flaws are becoming more readily apparent. Combat manoeuvres are something that bother me, since they are implemented in a way that makes them generally much less advantageous compared to just using a standard attack. They require a great number of feats to be usable, and even then they use an additional set of rules that mean the table more often than not has to stop and pull out the rulebook when they occur. Grappling is apparently better than it was in 3.5e, but still requires a flowchart to understand. I remember the first session I ran, one player tried to play a weapon sundering-based character, but the system made this very obtuse and generally less effective than just hitting the guy instead. Considering how cool these sorts of actions are, it strikes me as sad that performing them is so much more difficult.

Another gripe is the feat taxes in general. I played a rogue my first time, and because I invested a lot of time in my character, I really didn't want to let her die. Ranged fighting therefore seemed like the way to go. But it took ages just to make that bow useful. Same with weapon finesse. There are many other "feat taxes" that have been brought to my attention since. Fortunately, most of my DMs have simply used this solution, and it's worked out. Many of my other gripes, such as the limitations on actions, alignment, and the lack of balance for certain classes (notably the rogue and summoner) have been addressed in the Unchained rulebook. Nonetheless, it's a topic I could easily spend an entire day rambling about, so I'll move on.

The Setting

As for Pahfinder's setting, after the first couple games I made a concerted effort to explore the wikis and learn the lore. I was very pleased to find that there was an impressive database of information. There is a lot of good work that has been put into Golarion. The setting is rich and interesting, even if some of the parallels are a bit obvious (Vudra, you mean Fantasy India; Kelesh =Arabia, Osirion = Egypt, and so on). The writers have done a good job of providing ample setting information with which to run the adventure paths, while still having a system that is general enough to not rely on the setting entirely. Plenty of the games I've played are homebrews that do a good job of replacing the setting.

One aspect in particular I've taken an interest in is religion. Pathfinder has an established pantheon with major deities, minor ones, demigods, and everything in between. Lately I've been having a lot of fun reading about them and seeing how the story accounts for the existence of actual gods. In fact, one of my latest projects has been to go through the major pantheon and create "iconic worshiper" characters that represent their assigned core deity's aspects. It's proven to be an excellent character development exercise, and it's led me to produce some rather interesting personalities that also serve as functional characters. Incidentally, expect those to appear on this site some time in the near future.

Hell's Rebels

Hell's Rebels is Pathfinder's first "Chaotic Good" aligned game. It sets players as revolutionaries in the cultural city of Kintargo against the oppressive devil-worshiping Thrune government, that due to an ongoing invasion is getting all the more vicious and totalitarian. I like to simplify it for my players as "you are the French resistance in occupied Paris". The campaign starts off primarily as an intrigue and base building game, then eventually escalates to a full on rebellion and combat. However it's easily the least combat-oriented campaign that I know of.

Prior to this Hell's Rebels being released, I had wondered about DMing a game. However at the time there were no campaigns that really struck me as ones I'd particularly want to run. My greatest interests were political intrigue and an emphasis on tactics and strategy that would not necessarily be combat-oriented. I had actually started developing my own campaign using the Fate system and my Or8Weaver setting with those ideas in mind. However, when I learned of Hell's Rebels, needless to say I jumped on it.

Having now run the first book and read the others, I can say it is definitely my favourite campaign by far out of those I've seen. However it does still have plenty of flaws. There are some instances where the game outright states that there is a right way to go about certain things, and sometimes it conflicts with itself in terms of whether it wants players to be non-combative or not. The game clearly has the idea of allowing for different tactical decisions, but at times it feels as though the system itself doesn't make it particularly viable.

The Game

The Rules

Now, I started my game with a lot of preparation, and with story heavily in mind. I looked into and implemented several variant rules and extras with the intention of making combat smoother and easier (variant action economy and the feat tax fix being the main ones). I gave everyone a custom item that would level up with them as they progressed, the idea being that they would act as a kind of indicator of story progress (I also didn't use XP, for reasons that will be apparent soon). I also tried very hard to ensure that everyone's character fit the campaign and the setting. Because at least two of the people who planned on joining were completely new to Pathfinder, I wrote documents to simplify many rules and aspects of the game, like classes and religions.

All in all, I spent a great deal of time on that prep, but I was careful not to overdo it. I know the rule that players will inevitably mess with your expectations, after all. Most of what I did after that was emergent: I added characters based on quips or funny events that occurred. Eventually, I started writing scripts for dialogue and streamlined the information in the book (because sometimes I had to spend a solid few minutes flipping through pages to find out a small piece of information for a particular room).

The Players

I was prudent about people I didn't know mucking up the game for the others (since I had certainly seen it in the past), so I stuck to people I knew. Most were people I played with previously and people I knew outside of the game. A couple were friends I had who were interested in trying the game for the first time. I was fortunate in that three (later four) of my players knew the rules well, much better than me in fact, so I could rely on them to explain how something worked when need be.

Admittedly, the party did not mesh particularly well initially. Some of them had very different play philosophies, and it resulted in characters and players clashing. Fortunately that has since calmed down for the most part, and as they've gotten used to each other and I've discussed things with them personally it's been largely smoothed over. However it is always a concern.

There was one last factor to mention that I think in hindsight was a mistake on my part: I recruited six players. I learned a bit too late that four players is what Hell's Rebels was built for, and I now understand why some DMs don't allow for more than that. Juggling encounter difficulties to reflect that has been a constant challenge.

Most of the party came in from the upper side of the map and used nonlethal attacks. Hagger took the other route and asked if pools of blood could be considered difficult terrain.

My Experience

Technically speaking, Hell's Rebels is the second game I've been the DM for. Last summer, I briefly ran my Or8 game with a couple friends to test it out and see how I enjoyed DMing in general. It turns out I absolutely loved it, and now that I've gone through a whole book, I can safely say that I genuinely enjoy DMing even more than playing. I suppose that is as good a testament as any for why I want to become a game designer.

I should probably preface that as far as DMs go, I'm extremely lenient. My philosophy is that, at least for this particular game, the characters were more important as figures within a story than as statblocks with which to solve problems. Some dungeon runner games seemed to put more of an emphasis on making optimised characters largely for the purpose of surviving. I didn't want that to be what happened, so I was much more willing to let players twist the rules a bit in order to make adjustments that fit the characters. As a result, I allowed for some rather broken characters (I let someone play a Synthesist Summoner; that should more than explain how lenient I was to anyone familiar with Pathfinder).

As a result of giving the players several boons and allowing for six of them, I found that encounters were rather trivial at first. It led to the first few sessions having a lot of back and forth as I adjusted the difficulty of enemies to account for the team. It's something I still haven't mastered, though I've definitely gotten better at regulating encounters to match the players.

As for how the players have been addressing the game, I'd say it's been bumpy. From the start, players have on a few occasions clashed. I've had players nearly sabotage the efforts of other team members, or kill characters the rest of the group planned on sparing. The term "murder hobos" has come up. However, initially a lot of this had to do with the fact that I did not make the consequences of these actions very clear. It occurred to me that while the book does state that in most cases killing enemies is a bad thing, Pathfinder does conform to the standard game rules of "enemies are things you kill for XP". And even then, some characters, bosses in particular, are stated to fight to the death, and have no details about how to deal with them if they are simply knocked out or captured instead. It's a lack of internal consistency (or at the very least a loophole) within the narrative of the books that I've had to navigate.

One thing this had led to is a lot of improvisation on my part. I've gotten into the habit of claiming to "invoke DM-fudge" in order to simplify rules. Given the way I run my game (which involves actively encouraging less traditional means of dealing with problems and using tactics and the environment), I fudge a great deal. Often times when discussing the game with my players, I'll mention some aspects that I've altered, and they find themselves agreeing that they preferred this method for the most part (usually because it's in they're favour, if I'm to be fair).

What I've Learned

The main takeaway that I have from this game is just the extent to which players subvert expectations. Not only in terms of the players versus the game itself, but also relative to each other. Team dynamics are often complex and illogical, and when they are presented with a loose set of rules, it can often lead to chaos.

I find myself bouncing between giving players more agency and less. In the first book of this campaign, there are a multitude of missions that can be completed in any order. However, I found myself having to limit this, since I couldn't fully craft each encounter for them to all be ready from the start. Were I to redo this game, perhaps I could, but given my player's feedback, it seemed like something more linear would have been preferred. In fact, since I've started scripting scenes and sequences, players seem much more willing to go along with my story and at least attempt to follow what they believe to be the ideal path. I think it largely had to do with the fact that no one wants to "lead" the party and make decisions about how to proceed for all of them.

Now, I don't know if I could say it's convinced me that linear narratives are better. I am still more inclined towards giving players choice when I can, and hard railroading still strikes me as bad practice. However some of these factors may be circumstantial to this campaign (after all, the game itself seems to suggest a correct or ideal path), so I've tried to consider what my experience means in context. What I've determined is that while choice is generally beneficial for players since it gives them agency, it has to be very clearly outlined, and the consequences have to be evident from the very beginning. Moreover, this is rendered even more important than usual the more players you have working together.

Those statements are of course self-evident when stated out loud, but it's amazing how often their forgotten or not fully appreciated. I'm guilty of that myself. But with this game, I'm getting better at learning how to recognise good and bad game gameplay decisions of that kind.

Another important lesson is the importance of balancing challenges for the player. Between balancing the player's equipment and levels, as well as the enemies they face, I've created many instances of "enemy AI" that I built to challenge the players without being unfair. I got into the habit of rolling enemy dice manually rather than in roll20, so that I can decide when to adjust the numbers (mainly to avoid the enemy getting a nat20 on a character and killing them off on a fluke). It's made me appreciate the significance of randomisation in games.

I play Warframe at a high tier so I'm acutely familiar with farming and "RNG". There's obviously a balance between giving players moments of gratification at achieving an unlikely success and presenting frustrating lack of success due to consequences they can't control. Evidently giving players perfect odds of success can lack engagement, but make it too hard and it's just annoying. So I've taken to putting much more of an emphasis on "circumstantial modifiers" as a way of balancing that out. Things like small bonuses for using an environmental factor, or planning ahead, or even simply based on how well the party is doing. I could easily see that as translating to "enemies do less damage when a player loses most of their health in a single attack" in some games. Honestly, it's a concept I think many games would benefit from.

Evidently, all of that is part of a game designer's normal job. It's a balance that needs to be found and struck, and it's unique to every game (and never quite perfect). What Pathfinder so far has been teaching me is how to do it on the spot. It's sharpening my instincts and in the process showing me the kind of designer I am. I understand my biases, my habits, where I need to reinforce my skills and where my desires as a designer can conflict with a player. For those reasons, I consider this experience invaluable (and very fun, for that matter), and look forward to continuing on with it as part of my journey to become as great a designer as I can be.

A Note On Fate

I mentioned it briefly, but I feel like I should mention it a bit more. Fate is quite simply my favourite tabletop system I've ever encountered. It's significantly more free-form than many other games, and allows for the sort of gameplay experiences you simply don't find in a more rigid system like Pathfinder. It does so by stripping down a lot of the numerical complexity and putting an emphasis on player and DM generated content.

Evidently its greatest drawback is that it requires a lot of creativity on the part of the DM and the players. The rules are vague, so people have to resort to just saying what they want to do, and the DM determining what sort of roll that translates to. It's also heavily skewed against players who want a more structured system. That said, for a designer like me, It's ideal, because it's pretty much all fudge. The core is so basic that from there, anything can be crafted by the DM, and the sorts of dynamic adjustments I was mentioning before are a matter of course. I think that in the one instance that I tested out DMing a Fate game, it taught me a great deal about how players act when given very little guidance. It results in something that's a lot more organic and fluid, and by observing those trends, it becomes much easier to build more sophisticated mechanics, rather than constructing a whole lot to begin with and watching it crumble when players break expectations with what they want to do.

Honestly, I would strongly recommend trying many different types of systems out. Each has their own unique traits that make them a very different experience. It's easy to think of all tabletop RPGs as being fundamentally the same, and to a degree it's somewhat true. But the slightest nuances in how each system is approached makes a huge difference, and understanding the implications of these decisions is a very compelling thing for any designer.

My Design Strengths and Weaknesses

Since I was in high school, I've always been told it's important to be able to answer the questions "what are your strengths and weaknesses" during an interview. While that certainly is true, I'd go one step further and say that it is always worthwhile to know where your abilities lie and don't lie, as well as those of your team. To paraphrase Sun Tzu. knowing yourself is one half of the key to victory, and it's the one that's easiest to do on your own.

I like to think I know myself pretty well, and considering this is the one place dedicated to me speaking about myself, it seems natural to talk about my strengths and weaknesses as a designer (and in general). If anyone reading is a potential employer, then this is a chance to save you the trouble of asking these questions. Now then, without further ado:

Strengths

Organisation

This is perhaps the one that is the most commonly known about me. I am an extremely organised individual, or at least I aspire to be. Sorting things into systems and structures comes naturally to me. I like to build things up in an orderly manner. Schedules and documentation are things that I actually enjoy doing (ask anyone that knows me about my reputation with documentation), because they give me consistent systems to work within. One of my favourite pastimes is finding ways to make systems more efficient, and information more accessible.

This does have an influence on my design preferences as well. I tend towards clean ordered systems, more akin to sleek science fiction rather than grunge and the like. Cleanliness and precision definitely do more for me than chaos or the grotesque. That's not to say I'm incapable of dealing with disorder, but in my mind even the most chaotic thing has an underlying structure to it, even if it isn't readily apparent. I hold this view because of my next strength...

Perspective

I spend a lot of time observing. Not just in the literal looking at things definition, but in the sense of considering a subject and its various connections. I had a great deal of alone time during my younger years, and I spent a lot of it thinking about something, then trying to figure out the underlying components of that thing. Physics is my favourite science simply because it involves the most fundamental building blocks of the universe, ergo it is the base upon which all connections are built. Mechanics are incredibly cool to me because it gives us a glimpse at how a set of parts can create something greater than its sum through their interactions.

As a designer, seeing how art, code, and interaction can come together into a fully crafted experience is something I really like to contemplate. It's a large part of why design appealed so much to me in the first place. It's also part of why I find code quite easy to read, as it is simply a network of cause and effect systems. It particularly helps when it's well structured and transparent code for that matter, because then my organisation skills can further supplement that ability.

More recently, I've taken a particular liking in applying my perspective to social spheres of inquiry. Why do people behave a certain way in certain contexts? Why do social structures form so consistently across history and geography? What are the cause and effect mechanisms that drive society? Contrary to what a lot of people say, I like to think that society has a lot of inherent order within it, through its most fundamental building blocks. Figuring out the nature of those building blocks is something I actively pursue.

As should be evident by now, the implications of how things are interconnected is something I love pondering about. Those ideas are something I would like to play around with more in my games. As a designer, I really want to place people in situations that force them to reevaluate their assumptions of a game and/or make them consider the underlying structures that form the world. If I can get just one person to think about the inter-connectivity of the universe as I have, I will have achieved my dream.

Working Within Boundaries

Part of that inter-connectivity I just mentioned is understanding limitations, and how despite the presence of a boundary, there are immense possibilities for creativity within it. I actually quite like working within boundaries. Perhaps that's my orderly nature speaking, but they strike me as an excellent way to push towards getting the most out of what you have. Depth will always trump breadth in my opinion when it comes to the subject of making something good. I'll almost always choose quality over quantity.

Something that may have become apparent through my artwork is that I do a lot of crossovers. In fact, I adore taking things from one context, and finding ways to adapt it to another. Figuring out what "X subject would look like in Y context" is something I do for fun. So when I'm tasked with adapting something to fit new different boundaries, I can honestly say that I consider it an enjoyable challenge.

Likewise, this strength applies to most real world work contexts. After all, in an industry like games, even the highest ranking designer has limits being imposed on their vision, be it from above or below. Fortunately, that's something I'm prepared to deal with. I've proven in the past that if I'm given a task but with some limits imposed, such as figuring out how to make a game while keeping to a subject or buzz word (game jams being a perfect example), I have very little trouble coming up with ideas. In fact, the more restricted I am, the better I am at fleshing something out of it (the flip side of this will come up again in the weaknesses section). Part of my ability to work through limits comes from this next strength...

Versatility

Though I specialise in video game design (namely character and system/mechanics design), I was trained as a generalist, and I consider myself competent enough to do well in art (concept, graphics, sound effects, 3D modelling, animation), programming, testing, and just about every other task involved in a game. Heck, I can even do some half decent voice acting if I really try. I do have all the skills to make an entire game on my own.

I know the tendency of a lot of large companies is to shun generalists, and to a degree that does make sense to me. After all in a big company, people aren't jumping between different positions. Better to have someone in a dedicated position that focuses specifically on the tasks they will actually be performing. But when it comes to designers my logic is this: a designer, by virtue of their position as the one that must bring together all the individual elements of a game into a holistic experience, should have a good understanding of every aspect involved in making a game. They may not be as deeply entrenched in these other tasks, but I think it's important that they be able to understand them well enough to know the technical boundaries they can push towards through their design. Otherwise you end up pissing people off by building unrealistic designs (and trust me, I know a thing or two about non-technical individuals attempting to drive design).

Though I may not excel at many of these secondary tasks, I'm not a slouch either. Part of why I did so well in my program is that I was fairly quick to adapt to wildly different contexts. With a couple exceptions, my grades were almost universally in the 80%+ range, and that's across wildly different subjects (and even if you don't believe in grades, it's hard to argue that someone who gets such results on a consistent basis isn't doing something right). What's more, I'm perfectly comfortable making those jumps. In my senior project, I would switch hats multiple times everyday without blinking. I had to, and thankfully I was good at it, or we never would have gotten as far as we did (I'm speaking with complete humility here).

Communication

Speaking of speaking, communication is another thing I consider myself to be particularly good at. Part of wearing many different hats is that it forces you to see things from different perspectives (I guess the hats all have goggles? Steampunk hats, perhaps?). During different times, I've had to communicate to teammates, friends, enemies, professionals, laymen, developers, artists, testers, clients... You name it.

One of my first jobs was with QNX as a technical writer for the Blackberry 10 Native SDK. Something I learned quickly about technical writing is that you need to be able to simultaneously understand complex technical material and developer jargon as well as simplify it so that complete laymen could understand what you're talking about. This leads to two things: one is that technical writers are easily the best at working with the tools they write about (even better than the developers that write them, since they only have to understand the intricacies of their specific elements, without understanding how they relate to everything else; take that specialists), and two is that they will spend most of their day going back and forth between techno-babble and simple explanations (and the rest of the time digging into code documentation that hasn't actually been written, because they're the ones that have to write it). It's an extreme exercise in communication skills.

Thinking back on it, I'm very thankful to have had that job, because it taught me a lot about how different groups of people communicate. I remember one instance where a developer would never answer more than one question at a time, and would only ever answer in "yes" or "no". Generally speaking, I found that programmers are a lot more linear and direct in their communication. Contrast that with the subjective analysis artists require, the filtered diplomatically-minded talk of marketers, and the unabashed emotive speech of many gamers. Designers have to interact with pretty much all of them at one point or another. I like to think I'm pretty good at doing so, mostly because I can understand each of these groups, and see where they're coming from. After all, not only do I have my skills in perspective, but I've been right there with them in the past.

One last thing about my skills in communication that I think is worth noting is my patience. I consider myself an extremely patient person, and most people I know agree with me. I've also developed a reputation for being fairly easy to get along with (if nothing else, I don't make many enemies), as well as for being quite trustworthy. It's a set of personality traits I've often used to help others through tough times, but it's also helped me greatly when it comes to this last strength...

Stress

I work well under stress. In fact, I tend to excel while under stress. I like to joke that I'm always busy, but the truth is, I am because I set myself up to be. I'm at my best when I have a lot to do, because the rush of accomplishment I get from doing it fuels me ever further. I even set up my recreational activities as tasks, because it pushes me to relax more effectively (I realise that probably doesn't make sense to some people, but I challenge you to find anyone who doesn't feel more satisfied than they would normally be when they have a tangible checkbox they can cross at the end of a task, even if that task is just "watch a movie").

While I can't always sustain it indefinitely (especially if say, an unexpected event puts me well behind schedule), I can handle very heavy workloads without too much trouble and am able to sustain long hours for extended periods of time. I know my own stress limits very well, and I've organised my life in a way to be able to handle unforeseen circumstances without too much trouble. No matter how hectic my life gets, I'm usually able to make time for new things and still find ways to balance it out. Snapping under pressure isn't something I do. And given the field I'm going into, I think that alone is an extremely valuable asset.

Weaknesses

Stagnation

And now I show the other side of the stress coin. While I do work well under stress, when the opposite is true, I tend to wilt. I energise myself through deadlines and clear tasks to accomplish, so a lack of those things is as detrimental to me as an engine without fuel. 

I call myself a "creature of momentum". So long as I'm going, it's very hard to stop me. However, when I am forced to stop (or never started in the first place), it can be hard to get me going. I can genuinely say that I'm at my worst when I have nothing to do. Without a clear task to motivate me, my energy levels decrease rapidly. I'm the kind of person that has no trouble getting up really early in the morning when there's a good reason to do so, but without one I'm just as likely to wake up in the mid-afternoon.

My solution for this over the years has been fairly simple: always keep busy. Even when I don't have a job and I've taken care of my chores, I keep a large list of things on my to-do list. My watch lists are huge, as are my reading, writing, drawing, and other lists. So long as I keep myself preoccupied in a way that seems meaningful, I can sustain my energy levels.

However, there are times when this isn't enough. If, say, I've been forced to do a task I see as completely useless (like say something that involves sitting around doing nothing for long periods of time) without having the means to do something in the meantime, I'll have a hard time motivating myself. Repetitive menial tasks can suffice, but not if they involve a lot of waiting (for example 3D modelling is fine, but rendering will get me restless if I don't have a book or something to do while I wait). Another great example is when I'm stuck waiting on someone else to deliver. I'll touch on this later, but few things annoy me as much as being completely gated by someone else and having nothing else to do.

Blank Slates

As I mentioned my strength when working within boundaries and building from existing premises, the reverse is also true to some degree. I am admittedly someone who doesn't like working from a completely blank slate. If you were to ask me to come up with something while providing no restrictions, I might have trouble dealing with overchoice. I'll usually come up with something eventually, but it will take me longer than it might for someone else. It will certainly take me much longer than if I were given a restriction at the beginning of the exercise.

I attribute this weakness mainly as a by-product of my perspective. In my mind, nothing stands completely independently; it's always connected to something. That, accompanied with my tendency towards order, predispose me against spontaneity or true randomness.

I have a few ways that I work around this particular weakness. The first is to use my view of connections to my advantage by creating simulated randomness. Thanks to that strength, I'm able to leap from one connection to the next fairly fast. It's almost like doing a Wikipedia run from one entry to a seemingly completely unrelated entry simply by clinking the links within the articles. I usually use this in conjunction with the context I'm working in to set up the restrictions from which I can build. For example, if I'm playing a game like Quiplash (where you are asked questions and prompted to give answers that other players will vote on), the first thing I will do is try to read the room: what sort of sense of humour would these people have, and what pop culture references are they likely to be familiar with? From the basic premise of these questions, I can filter my thoughts sufficiently to come up with an answer.

My other primary way of dealing with this weakness is to come up with answers ahead of time. Some questions come up often enough that I have default selections. That's not unusual. But in the cases of things that are more nebulous, what I do is keep track of a list of potential items, from which I filter. A good example of this is how I coordinate with my friends on the ever-challenging "what do you want to do" question. I have a list of video games, a list of collaborative writing projects, and a list of other activities. All of them I've mentally tagged with factors which might make them more appealing or less appealing depending on the circumstances. The person is inclined to write something and I'm not feeling too energetic? I'll check through my list and find a possible subject that requires minimal concentration (usually this is associated with the characters involved, which makes it easy for me to filter them). I have lists for basically everything, so it's not hard for me to come up with answers to many questions that would otherwise require random responses. I've done what I can to plan for as many contingencies as possible.

I will say though that this weakness does manifest in another way that is a little harder to avoid. When it comes to development, I have a notable dislike of setting up a new project. This is partially an issue of momentum and my general dislike of the somewhat esoteric project setup requirements in a lot of development software (Visual Studio comes to mind). Fortunately, this isn't something that comes up too often for me as a designer (it only really applies for programming tasks), but it is still an annoyance. My usual solution for that is generally to just take an already set-up project, adapt it for my needs, and build off that.

Trust/Reliance

This is perhaps my biggest weakness, since it's the one that is most likely to actually come into play in actual work situations, and it's one of the ones that is a lot harder for me to find simple workarounds for. That is why I've left it at the end. That weakness? I have a hard time relying on others.

I consider myself to be extremely independent. It's a value I put a lot of emphasis on and it's something of a defining characteristic for me. I expect independence and high levels of competence from myself, and I wish to see it from the people I work with (and people in general). Seeing sloppy or ineffective work bothers me, especially if I am in a position to do it better. More often than not, if I'm not convinced the person working on the task can do a better job of it than me, I'll have a strong urge to correct it myself (I'd be lying if I said there weren't any projects on this site I want to go back and correct).

Now, in an ideal world this wouldn't be a problem, because everyone I would be working with would be competent. I would never receive a model with misaligned vertices, or files that were incorrectly formatted, or text that wasn't run through a spellcheck. In school this can be unavoidable: sometimes you're just stuck with the group you have. In a work environment, consistent incompetence will usually get you fired (unless you're in the public sector, zing! I kid... Mostly), but it's not something that can be banked on. In reality, there will always be situations like this.

As might be apparent, I've been burned several times in the past. I've often ended up in group projects with people who don't or cannot pull their weight. I definitely have a few horror stories. The worst situations are ones where the lead programmer would misreport (or not report at all) their progress and leave us without a working prototype by our presentation deadline. More often than not, I've found myself taking leadership and editorial roles for this reason. The moment it becomes clear that someone cannot deliver, I'll usually take it upon myself to redistribute tasks to other more reliable team members or sometimes to myself. I've made it a habit of requesting submissions well before the due date so that I can curb these situations.

Then again, they do still show up. Sometimes, despite all my requests for communication, I don't get a response. It's something that can genuinely frustrate me, and it can permanently sour my perception of someone's competence. In fact, I would go so far as to say that seriously gating me on a task without keeping me informed on the matter is one of the easiest ways to get on my bad side, because not only does it slow the project, it personally wastes my time (at least if I was given a forewarning I can find a way to solve or work around the delay). I do have a lot of patience, but this will drain it rapidly. This issue isn't exclusive to a few bad apples either. It's happened with people I previously considered to have excellent credentials.

As a result of these situations, it's become very difficult for me to simply entrust someone with an important task, especially if it is a key component of the work. Furthermore in some cases where I take the initiative to do the work myself, I have upset others. This is especially true if pride or "doing things by the book" are involved; these aren't usually things I prioritise over the bottom line. That said, I have gotten better at dealing with such sensitivities over time.

Fortunately, my trust hasn't completely eroded; I can still view people as innocent until proven guilty (or competent until proven otherwise, as it were). If someone has proven themselves to be dependable and consistently capable, I'll have little problem leaving it to them. Additionally, with time I have gotten better at dealing with many of the other scenarios I mentioned, particularly ones where the problem lies not in outright incompetence, but in a misalignment of skills.

One such example was in a fairly recent project: one team member who had previously been very reliable suddenly encountered a great deal of trouble with certain tasks. As it turns out, while he was a very fast worker when it came to simple executions, he was much more prone to giving up when he encountered technical challenges. My initial solution was to teach him to perform basic troubleshooting, but the problem persisted. Fortunately there was a large number of simple but tedious tasks that needed to be done, and he completed them in a much shorter time frame as a result of his talents.

In cases like that, where I might previously have simply left that team member to complete the initially assigned task and overwritten his work later, I've learned to become better at identifying alternate ways of optimising the project workflow. As I've learned to notice people's individual strengths and weaknesses, I have become more at ease with trusting people with tasks I've found them to be well suited to. It's a skill I fully intend to develop further, so that the frustrations I've encountered in the past won't come back to irk me. I'm not all the way there yet admittedly, but steady as she goes.

Conclusion

And so, there are my primary strengths and weaknesses, at least as I see them. With time they might change, but to tell the truth, I think they are in large part born of my core personality traits. I'd like to think that it's a good distribution, and it allows me to work well in my selected field. I've gotten myself this far, and I know that I've improved in many ways over time. Hopefully, with the right experience, that trend will continue.

To anyone who read this, I hope you found it interesting, and that it helps you understand me just a little bit better. Rest assured I'll be writing quite a bit more about myself here soon enough.