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
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
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
(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
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
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
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!
