Wildcard Dev Team Work & Chill, Episode 3

SHow Notes

In this enlightening episode of "Work & Chill," the spotlight shifts from the Frostburn Arena to the production room, where the magic of Wildcard is orchestrated. Hosted by Ami, the Director of Community for the Wildcard Alliance, this session features Shawn "Sketch" Ketcherside, the Director of Production for Wildcard. Sketch opens the session with an introduction, setting the stage for an in-depth exploration of what it takes to be a game producer. With many years of industry experience, he offers a wealth of knowledge that spans project management, team coordination, and much more.But this episode is not just a lecture; it's an interactive experience. Sketch takes viewers through his typical workflow, offering a rare glimpse into the day-to-day operations that keep Wildcard running smoothly. He discusses the challenges and triumphs of game production, providing insights that are both educational and engaging. To make the session even more interactive, a live Q&A segment is included, facilitated through Discord. This allows viewers to engage directly with Sketch, asking questions that range from the technical to the philosophical. Detailed timestamps are available to guide you through the various topics, making this episode a must-watch for anyone interested in the behind-the-scenes mechanics of game development. Become part of the community today: https://discord.gg/playwildcard


Hello, everybody. Hello, wild ones in the Wildcard community. My name is Ami. I'm the director of community for the Wildcard Alliance. And I am so excited that we're doing episode three of our work and chill series today. I'm joined by our producer, principal producer, I believe is the right title. 


Director of production, actually. 


Director of production. Okay. Thank you, Sketch. His name is Sean Sketch, aka Sketch. Ketcherside. Let him do an introduction of himself in just 1 second. But a couple of reminders and housekeeping before we do. We are multi streaming this show, this production on YouTube, Twitter and Discord. But as many of you know, we do have what we call the Wildfile, which is your Wildcard, essentially player profile, where you can track your event attendance and it is only tracked if you're in discord. We are also taking all the questions and answers for Sketch at the end of this presentation all through Discord. So if you want to actively participate and interact with Sketch during this, then please join us in Discord. And we cannot wait to see you there for those who are in discord. Hello and thank you for joining us. This will be recorded on your Wildfile. 


So normally with our work and chill, we kind of sit back and relax. We watch someone at work. For a producer, Sketch's job is a little bit different. He's going to go into detail on what exactly a producer does, but it's keeping everything running smoothly and keeping the game on track. So we're going to hear a bit of a presentation on what a producer is, what a producer does, and he'll take you behind the scenes to kind of show a little bit of his workflow. So bit of a different format today, but one that I'm really excited about nonetheless. So I'll let you guys stop hearing me talk. I'm going to pass it over to Sketch to introduce himself and get started. 


Hello. So first off, because of where my chair is and the camera is, when I hand gesture, I'm going to give a bit of a muppet vibe. So just be ready for that. But we'll kind of go as we go. So as AMI said, I am the director of production on the project for the game. That means a lot of things which we're going to talk about here. So let's kind of talk a little bit about that. So a little bit about me. So I've got 23 years of experience in the game industry. Wait a minute, that can't be right. That would mean I'm like, never mind, we're just going to move on past that. But in my career, I've actually worked on games of all different sizes. I've worked on small mobile games. I've even worked on Giant MMOs, which are huge and very multifaceted. 


And I've also worked in multiple fields. My first job in the industry actually was as a programmer or an engineer, but my focus was a lot on gameplay and AI. And while the job didn't exist at that time, when I got in, it was more analogous to what you call a technical designer nowadays. From there, I did a lot of stuff with the scripting systems and moved into lead scripting position. Then I moved into, like, a lead designer and director position. Then I've moved on and done writing and some narrative design stuff. And I've been a manager and for the last, probably about a decade, been a producer. So that's kind of where we're at with that. So some of the games I've worked on Star Trek elite Force Two. Blackout down. Counterstrike condition zero. On the deleted scenes section there Sin. And some of my big ones helped on The Old Republic. 


I was actually on that for seven years. Believe it or not, that was a huge amount of my career. Did some help on sort of external production on some of the stuff for the 2016 Doom, was producer on Super Lucky Stale, and of course, I'm here on Wildcard, so it's kind of a sampling. As with anybody who's been in the game industry for many years, there's a whole slew of canceled titles I have left in my wake. But, yeah, these are some of the big things that going on. All right, so let's talk a little bit about production, what this means, those kinds of things. So what is it? Strange as it is, it actually really varies. Different studios view production in different ways. They structure it in different ways, and they actually have some slightly different roles depending on where you're at. There's some commonalities, which we'll talk about, but if you look at something like EA tends to have producers and development managers who kind of split some of the role. 




Other studios, the producer kind of manages all of that stuff. So it just depends on where you're at. For myself, where I'm at here is at Wildcard. I spend a lot of time helping Dan and Paul to iterate, clarify, and really, most importantly, communicate the overall vision for the know down to our team and all the strike teams that we have, so that everyone really understands what we're trying to build and why. And then I do the reverse of that too, where I pull in from the team and I communicate back up to the senior leadership, hey, here's what's going on. Here's where we're at. Here's our status. And then work with other senior leadership groups to really come up with, like, this is our vision and this is our timeline. What is our overall plan to get there? How are we going to get all this stuff done? 


Who's going to do it? How are we going to do it? What do we need? And I try to put that together in a lightweight cohesive plan that we can then push back down to the team and be like, hey, here's how we're going to get where we're going and we can sort of move forward with that. So before I go too much further, I thought it'd be good to just kind of talk about the different phases in the game development lifecycle. So there will be some minor variations to this depending on where you're at. But generally what you're going to see is you'll start in a concept phase where you're just trying to figure out what the game actually is once you kind of have a sense of like, okay, this is the game here's, like an elevator pitch of what the game is. 


I understand at a really high level what I'm trying to do. Then you move into pre production, which is really here, you're going to look at like, what is the IP kind of stuff? Like, what kind of characters am I going to need, what kind of level structure. You start answering a lot of the questions that the concept asks, so you have a sense of how long stuff's going to take, what kinds of things you're going to need, how things get all working together. And then from pre production, you move into production, which is kind of heads down, like making the assets, making the systems that we need, making just making everything for a game, which for AAA stuff, it's a lot of work. There's a lot of assets that go in there. Once you get through the production page, you'll typically roll into an alpha, which basically means you've got pretty much all the systems there. 


You've got assets there. Some of them might be placeholder assets, but you kind of have the whole thing for like a single player game. You'd be able to play it from beginning to end. There'd be bugs, there'd be like missing textures, there'd be all sorts of issues with it, but the game itself would basically be there. You're like, you could squint and see what it's going to be. And then from Alpha, all during that alpha period, you're trying to get all the rest of that stuff in there. Then you move into beta, which is a lot more about really focused, narrow, super minute polish to make sure that you're taking everything that's good and trying to elevate it to great. And another thing we like to do here at Wildcard is like in that phase, kind of look like what is our least favorite thing about the game and what can we do to make it our favorite part of the game. 


So that's kind of where we're focusing on there. And of course a lot of bug fixing and testing and doing everything you need to do to get the game ready to release. So for other studios that might be getting things onto the storefront, like if you're going on Steam or something like that, or if you're going to go onto Xbox, like, make sure you're getting through the certification and all those things that you need to do to basically be like, okay, we're ready to go ship this game. Let other folks play it, which then hits to that release and live. So this is sort of the high level, like how in theory it goes. I have yet to see anything actually follow this exactly. What tends to happen is that the phases are way different sizes than what's depicted here. They're not all these nice little boxes. 


Some stuff takes longer, some stuff takes shorter, and they tend to leak a little bit into each other. Like, you'll be mostly done with the concept, but you'll have enough done that you want to go ahead and start pre production even though you're still working a little bit on the concept. So it just sort of tumbles into each other a little bit. And then while all the directions are kind of going, at least my screen left to right, there are times where you can get into production and realize you've got a huge issue that you didn't anticipate. And sometimes the whole game, or maybe part of the game, goes back into pre production while you try and figure some of that stuff out. So this is more of a model than what actually really happens. And so you have to be, especially as a producer, really flexible to understand where are we really at, what are we really trying to do, and how do we use these sort of these conceptual phases to help us continue to move towards our ultimate goal, which is releasing, but make sure that we get to release. 


The game is great. We feel really good about it. So this kind of rolls up on the production side that I basically help manage. The battle between scope, time, and resources. These three things basically are in a fierce, never ending battle at all times. So way to look at this is like, we could say, oh, you know what would happen to the game if we added like six more levels? I'd be like, cool, we could add six more levels. But if we're going to do that, I either need more time or I'm going to need more resources to do that. Similarly, we could look at it and as we're looking at our releases, what would happen if we tried to release this a little bit sooner? I'd be like, cool, we could release this thing sooner. But to do that, we're either going to have to cut the scope down for that release or I'm going to have to get more resources. 


And little trick in that case, it actually really needs to be the scope because a lot of times adding more resources doesn't help as much as you would think. But then again, in resources, like if we had multiple projects going on and we're like, hey, can we borrow this resource from this project to this other project. It'd be like, yeah, but do we still want to ship at this time? Do we want to reduce scope so we can maintain our ship date? So it's not like one is always the right thing. It really is super flexible and it's dynamic. What is the most important thing at any given time? Changes frequently, even within a phase, just depending on what's going on, what we're trying to do, what our goals are. And so on the production side, I have to be constantly super aware of what it is we're trying to deliver, how it fits in with the overall vision. 


And then what I do here helps me basically align to make sure we're hitting that vision and hitting it in the right way. So the sort of three P's that come out of this is prioritization process and planning. Loosely, you can translate this to the prioritization is the when. So like when are we doing all the different things that we have to do? Like what's more important than another thing? Why is it more important? Process is the how we do things. So different things need different processes. I really try and myself, the way I work, I try and keep the processes as light as I can because I want to make sure the team has the flexibility to do what they need to do and get their work done. But there always needs be some layer of process so we understand, okay, this thing is done with this amount of work. 


Now it needs to go to this person or needs to get looked at by this thing or it needs to get approved. So there needs to be some layer of process just to help us make sure we're getting everything done. But there are other places that go even heavier in process which can slow things down, but it adds a little bit of extra security. So it just kind of depends on your team, your project, like what your timelines are, which way you go. It isn't a right or wrong, it really is really dependent on what you're doing. But that seems to be the way I have found works really well with this group is to be just enough process and then the planning, that's probably for my role where I spend the most of my time and that's really focused on the who and the what. 


So that's us looking at, okay, if this is our vision and here's kind of our timeline, how do we do this, how do we say, okay, here's what we're going to try and get done in this amount of time here's who could work on it? Here's why this is important, because all this other downstream stuff, it's really a big thing. And as you can imagine in a game studio, particularly in ours, where we're so really keen into want to make sure the experience is amazing for the player. There's a lot of dynamicism there. So my planning changes frequently a lot. And that's okay because what we're doing is it's much easier to change a plan than to not have a plan. So by laying out the plan, you're like, hey, here's how we can hit this. And then we realize through play testing or something like, oh, this feature we added is like flaming hot garbage and we can't go out with we got to just change this up. 


Like, cool. So then we adjust the plans and things like that so we can make sure that's good because really for us, that player experience and that vision is so critical that in order to achieve that, we have to stay flexible on these other things to hit those goals. So more about my role. I basically focused in leadership and management. So when you look at sort of the left side, at least on my screen left side of this, I spent a lot of time cycling, as I mentioned, with Dan and Paul on the vision and the goals. So we're constantly in sync, talking about what it is we're trying to do, why we're trying to do it, feeding into each other and things like that, and really trying to establish what's the most important things to be working on right now. I then take that information and as I mentioned in the previous slide, I spend a lot of time and a lot of rework on the plans to execute on that vision and goals. 


And then the way we operate, and we've had a lot of success with this, is we break our groups up into strike teams to tackle features or initiatives or things like that we're trying to work on. So an example is if we're working on a new level, we might have a strike team for that. Or if we're working on some cool new feature in the UI, we might have a strike team for that. And so we break the group up into strike teams and then I hand sort of high level plans, which is really more about the goals, what we want the experience to be, what we're trying to get done, and the whys. And I hand that to the strike teams. And the strike teams then work to break that down into actual tasks. The minutiae of like, here's what we need to actually do in my different disciplines. 


So the engineers are like, oh, well, we're going to need to kind of work on this system. We're going to have to update this other system or we're going to have to refactor this other thing. The artists are like, oh well, if that's what you need, then we need to get this asset and this asset. Those kinds of things are where we start drilling down to what we need to actually get done and in the game to deliver on those goals and visions. So that's kind of how that part of stuff works, something to call out that's really important for us as a studio. And I'll talk a little bit about this in another slide. But related this, we view everyone as a designer. We want everyone playing. We love getting ideas from everybody, just get amazing ideas from everybody. We had a case the other day where one of our artists had just something amazing to pitch, so we want to make sure we encourage that. 


So while Dan and Paul are really working on the upper level vision, a lot of the specifics of the design can kind of come up from strike teams or just anyone in our group playing. So it's a really interesting and great dynamic to make sure that the game is fun. So the other big part of what I do probably can assess this from all of what I talk about, but it's a lot of communication and alignment. So I do spend a good part of my time making sure, hey team, do you know what we're trying to do? You know why we're trying to do it? And then, hey, senior management, here's what the team's doing, is this still what we're trying to do? Is this the right things? And then even within that, within the strike teams themselves, making sure that everyone has what they need, that no one's waiting on anything or if something's blocked, we know what to do. 


Lots and lots of communication, which when we get to talking about my tools thing, it means I spend a lot of time in slack. So I'll talk about the other thing I spend a lot of time on is making sure that we have alignment. Alignment is kind of an interesting word. You might think like, oh, cool, everyone is fully in agreement what we're going to do, that's not necessarily the case. There will be times where with anything you're going to make a decision or a decision has to get made that not everyone's going to be completely on board with. And that's okay because we'll hear out why they may not agree with that given decision or something like that. But what we want from alignment is everyone understanding, okay, I understand what the decision is, I understand why we made that decision and I understand what I need to do to support that decision. 


I may have said my piece and why I may not disagree, but I understand why we're trying to do and I am on board with helping us deliver and hit that. So that's sort of different than this idea of consensus or enrollment. But alignment is so important because that's sort of the foundation of all the communication that goes out. If we're aligned on what we're trying to do, then it empowers everyone all the way down into the strike teams to make good decisions about what they're trying to work on, why they're trying to work on it and it empowers the leadership group to inform those teams, like, hey, here's what's going on. Here's why this is super important to deliver in this particular way. So that's what alignment is really all about. All right, let's talk a little bit about how Wildcard Alliance works as a studio before I go on. 


So this group has a lot of folks I've worked with for many years and they are hands down, like my favorite people to work with in my entire career. I love this group, I love this studio, I love this culture and I love this project. I'm so excited to be here. And I think how we work, like, any place is going to have things that we can do better, but that's one of the things that we look at is, hey, how can we do better each time? And so it's just a really exciting, rate place with a great vibe. And so that how we work is a big part of why that is the way it is. So for our team in studio, we are vision led. So that coming all the way down from Paul at the top and then into Dan from the vision on the game itself, and then I'm kind of helping to cycle through all that. 


We're very player focused, as I mentioned. We want to make sure the game is fun for our players. That's our target. That's what we're making this for. We're very dynamic. So as I mentioned, we're always looking at what we need to change, what we need to improve, and just really trying to make sure that we're staying flexible, that we're always working on the most important, most valuable things to deliver on that player focused experience. One of the things I really love about how we work is we're so collaborative. We're very good at working with each other and getting opinions and thoughts and feedback and bringing that in and then working with it and using that to help make everything we do better. I get feedback on my plans. Artists get feedback on their art. Engineering does a lot of peer review stuff. So that collaborative thing just makes everything so much stronger, so much better. 


And it also really helps that communication because people really understand, oh, I know why art's doing that, because of this and this. So it's a really strong aspect of our culture. At Wildcard, we actually run really lean. We're a pretty small group ourselves and we tend to bring on folks that punch way above their weight class and are able to do a lot of great things and can wear multiple hats and just do amazing work. A lot of us have a couple of decades of experience. A lot of the group has worked together for multiple decades too, so we have a lot of connective experience and things like that, which really helps the communication flow there. And the last big thing that is really great for the studio is how respectful we are of each other. This is so important for a game studio as a whole because so much of a game is ideas and free flow of thought and things like that to make the game better. 


If you don't have this sense of respect, or the more corporate term is psychological safety, but if you don't have that, then people don't feel comfortable giving ideas, which means you're not always getting the best ideas. So your game is not going to be as good as it can be. Having this sense of respect for each other obviously just makes it a good work environment. But it makes sure that people feel empowered to throw out an idea even if it doesn't work. Like, oh, that's a great idea, it won't fit because of this. But I see what you're trying to do and I understand what you're trying to solve for that. What if we solve for this in a different way? And so it helps foster those kind of conversations. It helps foster that sort of direction. And so it's just a really great tool to make sure that we're making amazing games. 


All right, exciting times. You're going to get to see producer tools and you'll get to see why you don't just get to watch me work, because it is not super exciting from that side. But I think it'll be interesting for you all to see some of the big pieces that I actually work with here. So one of the big tools I work with is Miro. If you don't know what it is, it's sort of a collaborative whiteboard that you can make multiple whiteboards and do a lot of graphics and flowcharts and things like that, which are really right up my alley as a producer. Here's some examples from the interwebs of what a mirror board might look like. You put post-it notes on there, you can draw a lot of shapes. One of the things that's super powerful about it, and that I really like is that multiple people can be on the board at the same time, editing it in real time together. 


One of our great use cases for this is when we do our sprint retrospectives at the end of each sprint, where we get everyone together and everyone's able to throw up things like, oh, I think we could work. On this better or I really like what we did here, and it's all in real time altogether. And we're able to talk through those things that get put up there right then and there. So this sort of idea of real time editing is so great, especially being a remote studio. It allows that sort of collaboration you would get if you were in a meeting room at a whiteboard there. So it's so powerful for know. The other things it's really good for is these sort of flow diagrams or lanes of things. It just does a lot of stuff. Paul, for instance, loves using it to help do mind maps and things to help figure out when we're brainstorming things like that. 


It just does a lot for us and I'm just really happy with that tool. Overall. Another tool that I use, and I use this probably most of my day, is Slack. Slack is our primary communication vector. We're on Slack all the time, so I use it like everyone does, like 80% communication, 20% memes. So that's sometimes memes is the best way to communicate. But I use it a lot to hit those things that I talked about before, like making sure that we have alignment, making sure that we have people know what's going on. One of the great things about Slack is that it can allow for a lot of asynchronous communication, which, again, is really useful in a remote setting where for questions like, I need the answer for this, it's not that I don't need it right the second, so I can throw it up, be like, hey, when you can answer this, great. 


And I'll get the answer. Something we have noted though, coming back to earlier part of the discussion, slack is pretty terrible at getting alignment on things. So what we found for this is we'll use Slack to talk about a thing or work through something like that. But then what we ultimately do is say, okay, if we need to get an alignment on something, we need to get a group together and sorry folks, my earphones are beeping out. Anyway, so we use it to get us prep for alignment and then we actually have to meet to talk about alignment because there's so many questions, it's hard to type it all out. And it's just good to get everyone together, make sure verbally we're all on the same page with stuff. But Slack does give us a lot of tools to make sure that we can keep moving and doing a lot of work together. 


Again, right off the web, some examples of Slack. Over here on the left side, you have all the different channels. If you haven't seen Slack before, I'm sure most of you all probably have, but you've got channels for things, you've got direct messages. In our Slack, we have a lot of channels for things, but it's good because it shows we have a lot of thought in sort of subdivision of the work that we're trying to do. So each strike team has a channel, we have channels for different things. We do a pretty good job of calling temp channels out with a TMP in the front, so we know, oh, that's going to be temporary, it'll go away in a while. So it helps us sort of manage the chaos of the channels. Another tool, as most of you are already in here, is discord. Yeah, you probably know what this. 


Looks like most folks are literally sitting in it right now, but just really used to talk with our amazing community. It's such a great I love seeing folks' messages and questions and things and just our community, honestly is amazing. It really is. And I want to call out our amazing community manager and our community team for helping to foster such a great environment. I like going in there at least a couple times a day to see what's shaking. So it's just really great. And then the last big tool, which I'm going to go into a bit of a deep dive on is Jira. For us, that's sort of the big project management tool. There's a lot of different tools for this. Some studios is something like handsoft there's like even Monday. There's a lot of things that you can use. We've elected to use Jira. All of these tools are terrible in their own special way. 


So you just kind of have to pick your poison. And for us, the way we work, actually, Jira works pretty well. It has a lot of flexibility, which, given how we work in the dynamics of our environment, is really helpful for us. But downsides of Jira, its UI is not awesome and it's a little bit intimidating. So it's a little bit of a learning curve to get used to it. But once you get used to it, then the flow is pretty solid. So I'm going to go ahead and switch over real quick to actually show some Jira in action. Going to switch my screen AMI. For some reason, all of a sudden, my zoom thing to Share screen just is not on my screen now. 


Like you lost your Share screen button? 


Yeah, that whole mini bar is gone. 


Do you want to send me a link and I could share it? 


You would? I don't think you weird. 


I probably won't be able to see it. 


Yeah. This this is Jira as kind of the main view of it. I made just a quick demo project, mostly because our main project is just full of thousands of things and it would just be really hard to navigate and really show it off. So I put a few sort of representative items into this small backlog, more show how the tool actually works so that you didn't have to spend 20 minutes watching me scroll, which strangely enough, is not as exciting as that may sound. So at the top, what Jira helps us do is manage all the work that we're trying to do as a whole for the game and then all the work we're trying to do, like right now. So we look at what we're trying to do for the game as a whole. All that stuff goes into this backlog right here. 


So we just keep as new ideas come up. We just throw it in the backlog so we can be like, yeah, cool. We'll get to that at some point. Then as we get closer to our milestone and we break our work up into sprints of two week runs each, we pull stuff up that we want to work on and we break it down into a little bit more detail to understand what those tasks mean. So an example of this I have JD. Is for jiro demo sprint one. And so I pulled up a few items that we potentially would work on in this hypothetical sprint. So we might know. Add some more VFX to some bulbar atoms. Need to get the sound effects hooked up for the footsteps and make sure those are surface dependent. Do some tweaks on the turning radius for a lock. 


Migrate the new summons to the new behavior tree. Update our NAV mesh so that our AI walks where it's supposed to walk, and then just a couple of bugs. When you look down here at the backlog, there's other stuff that would be like stuff we'd want to do, but it isn't as important for this thing right now. When you look over here, you see where it says like Bolgar, Locke, or someone functionality in Arden Arena, this comes from the please, what we call epic. So in an agile development process, you have a lot of different kinds of issues and tickets, you have bugs, you have user stories, you have tasks those are somewhat interchangeable but not really. And then you have epics, which sit on top of that. An epic is like, you could in some ways think of it as a feature. Like you want to get an epic complete, but it's a big thing that might take more than one sprint, might use multiple strike teams. 


So there's going to be a lot of stuff that works into making an epic and epic. So for here what I have is I have an epic for vulgar, an epic for lock, the core summon functionality, and then the arden arena. And so in this, each of these belongs to one of these epics. So we know, okay, when all the stuff under the vulgar epic is done, that particular thing is done. For stuff that we do multiple iterations on, we still like to try and tie things off. So we might do like a v one, and then we open up a new epic for v two and then a new epic for v three as we mark them through. What that gets us is a way to be like, okay, we have finished a rev or a revision of this work and it's in game and it works. 


There's more stuff we want to do, but it's there for now. And then we'll move on to something else and figure out how we want to level that up going forward. And a little bit further over, you see the status all these are marked as to do, which I'll show a little bit more about that in a minute. And then this other column here is the story points. Let me talk you about story points. So in proper agile, you would estimate your work based on relative effort. That I'm sure works for some studios. I guarantee there are some studios that they do that and it works well for them. I've yet to have that work well for me. What tends to happen is that always gets broken down or converted into days. And there's a good reason for that. It's easier to grock the idea of days. 


And as a game, we are working the deadline. And so the easiest measure of that is how many days do we have till our deadline? So everything just sort of defaults to days. So in this case, we try and do one point equals one day. So this would be like a two day task, this would be a three day task, that sort of thing. Again, if there's any budding producers in here, this is absolutely not the way those story points are actually supposed to be. And for really real agile, but I always run sort of a hybrid approach, you have to tune it to work, what works for you. So that what works for us. Other industries, other studios, they might make it work and great for them. It's just this is what works well for us. And then the little blank icon here is just whoever's assigned to it. 


Last thing I'll do real quick to kind of show this off is I'll go into an actual task. So you click one, you can open it up here, you can open it up as its own thing. But this is where we'd add a description like what is this actually? Before we can change the assignment, change the priority. So is all the specifics. But the big important part actually is the comment train here. So as people work on it, they can add comments like, oh, here's what I did, or here's the question I have. And they can tag people like you would do in pretty much any system. And it allows us to add images. And a big thing we do, especially for bugs, is try and add video. So it's just easy to see what the actual bug is. Also means you don't have to write like a thousand words of description. 


So that's really helpful for us to understand where a bug is or where an issue is, who's working on it, what's going on. So that really is sort of jira in a nutshell. It does a lot of stuff. Like I said, it's really customizable. So you can customize the workflow for all of this stuff. You can change what issue types are. You can make new issue types. You can do a lot to make the tool work for how you work in particular, which is one of the real big reasons, the big strengths we picked it is because I like to tune things and that it gives me the ability to tune it there, depending on the team. Some teams use more of a Kanban board style, which is like, you can imagine just a board with columns like to do or started or in progress or getting arted or whatever you need. 


And we would move a thing through that. The format that you use is highly dependent on what the deliverable or what the work is. It's not one to one, but I found in my experience, on the whole, what tends to work well in terms of managing workflow is for artists. They do really well with a Kanban board because a lot of their work moves from one phase to another. Engineers tend to work really well with agile, and the designers work really well with a mix of the agile and even some time boxing. Like, hey, yeah, we want to figure this out. We don't really know what this feature is yet. Let's spend three days, we're going to dedicate three days to figuring out whatever this feature is and what makes it fun. So giving them a time box, they know how much time they can spend on it, but not trying to define what the fun is before we found it is really strong for the design. 


It keeps them empowered to do what they need to do while still keeping us on track. And so I'm going to go ahead and stop sharing this and hopefully my thing will stay up and we'll move over back to the presentation. And of course, it disappeared again. Oh, no, I found it right just 1 second. Here's it and there we go. Now we are back. So now I kind of talked through some of the tools that I used and hopefully this will wake all those folks up who suffered through that last little segment. And we'll talk about a typical day for a producer. So I have some stuff here that's more of a representative day. It strange. It is a producer doesn't actually have a typical day. We have to really adapt to whatever's going on. So it's hard for me to say, oh, this is what I would do from morning to night, but there's a few kinds of types of things I do in the morning, types of things I do in the afternoon. 


And so I kind of like flagged out a few things that are represented as the kinds of things I do, but it's going to EB and flow depending on what all is happening. But I'm more of an early bird, so pretty early, so I can make sure I have time to plan my day, get a sense of where we're at with things, make sure I know, hey, here's stuff I have to follow up on. Here's stuff I'm concerned about. Just giving me a chance to before everyone else rolls in to really know what I'm trying to achieve and accomplish that day that's going to move our project forward. I usually have a production sync with Wally, our executive producer, just so we can check in on the stuff I'm managing, the stuff that he's managing, just see where we can help each other on that stuff and what all is going on the different aspects of Wildcard as a whole. 


I usually meet with the strike teams either in Discord or I'll meet with them on Slack, or we'll do a play test or something like that. I'll work with Dan, especially right now, on doing a lot of checks on the build status. So we'll play the build and see, hey, where are we at? Where do we think were going to be? What didn't quite make them, the last check in cut off. And those things we can actually see in real time what the status of build really is, which is so critical for us to help Triage and prioritize all of that work. So we know, yeah, we thought this other thing was really important, but now that we're playing the game, we realize this other thing is really top of mind, something we got to fix right now. So it helps us keep that flexibility, make sure we're always working on the right thing. 


And then as a producer, I have a lot of meetings. A lot. So a lot of my day is in meetings. It's a function of what I do. I spend a lot of time communicating, which means I spend a lot of time in meetings. In the afternoon, I have more meetings, which not a surprise. I do what I was going to loosely call production work. So this is where I'm doing planning documents, or I'm building out processes, or I'm working on Jira workflows. Just the sort of actual work that a producer does. I'll do a lot of updates. This is where I'll go into Jira and be like, hey, where are we at with this? Or, what's going on with this? Do you need any more information on this other bug or this other task? How can I help you get your work done? That's what the updates are. 


Then a lot of communication. This really just could be like across the entire board because I'm just in Slack all day communicating. Then I do a lot of work on planning. I didn't do this morning, afternoon, because I have a sense of where we're at currently in the day. And it gives me a sense, like, okay, here's where we're at, here's where we need to be. Here's what our plan is beyond that, like, looking even further out, here's where we need to be and here's how we need to go. And as I mentioned, since we're super dynamic, it's good for me to rework the plans a good bit. So I try and just make sure I have time carved off for doing that work. And that is it. That's me. So open up for some Q a AMI yes. 


And thank you for the presentation. I loved seeing that I've worked with you every single day, and it's still eye opening to see just how many balls you have up in the air all the time that you have to juggle. It's really impressive. Okay, so I'm going to move my camera back over here so I'm not looking off screen at you guys. Got multiple monitors here, but I recorded a couple of questions throughout the presentation. I'll start with those. But for anyone in the audience right now that has questions, after hearing Sketch's presentation, drop them in the chat and we'll ask them as they come in with course priority to our wild pass holders. Thank you guys for being here. Okay, so kind of going back to near the beginning of your presentation, you mentioned that you're managing resources. I forget what the three words? 




I don't remember what scope and time. 


Thank you. But there was a question about what exactly counts as a resource. Is that just manpower? Are there other things that you're considering? 


Oh, no, actually not just manpower. That's a big component of it. But there's also things like, hey, what potential tooling could we use? Are there tools or apps that we can use that might accelerate some of this work? So those might be resources like contractors, which a little bit is manpower, but it's not like our manpower, like other contractors that we need to use or are there other partners or things like that. So it's kind of basically all of that stuff. Like anything or anyone that can help us produce is what a resource. 


Excellent. So you can get a little bit creative there. 




Awesome. Okay, so next question, kind of in the same vein a little bit, the question is, what is it that makes games so expensive to make nowadays? What drains all the resources from a project? And just a comment that's always been somewhat vague to people from the outside. 


Looking in why that is a fantastic question. So game cost is on a spectrum. You'll have smaller independent games like made by one dude in his house on Unity, that cost is probably pretty low. Then you have all the way off the other end of the scale where you're looking at something like Uncharted or Galastovis or a Call of Duty, which is a huge AAA, enormous project, which is going to cost it could literally cost hundreds of millions of dollars. And there's a lot that goes into that. The core of it, honestly, especially for those big AAA games, is the resources, the manpower. It takes a lot of people to generate the kind of content that needs to be made at the quality bart needs to be made at for these AA games. When I first got in the industry, a level designer could basically make all the interior the levels, could make the level art themselves could do all this stuff. 


The textures now it's just too much. Like one person can't do all of that. One person can't normally do all of those things to the quality level it needs to be done at anymore. So you're going to have a lot more specialists. So people that really focus in on lighting, or people that focus in on exactly on VFX or on substance designer things to get the normal maps exactly like you want. So there's a lot of specialty that goes in there to make sure that quality bar is as high as it can be. And it's really high now when you look at the power like PlayStation Five or Xbox, the Xbox Series X has there's a lot of horsepower. So you would need to drive a lot of detail and a lot of fidelity. You can work around that a little bit with some stylization. 


So that's why you'll see smaller games, more independent games, look a little bit more stylized. They're going to be a little more animated. They might be bright art is because it's much cheaper to produce that and there's a high quality bar for it. For sure your art needs to look good, but you don't need 1000 people to make a sprite. So that's a big part of that. The other component, honestly, for big AA games is a lot of that cost goes into marketing. It's a lot of cost to market a game because it's a big investment for a studio and a publisher to make something like a Call of Duty. So marketing helps the awareness of the product, but also like, hey, here's when it's coming out. Helps build that hype, gets people excited, helps drive the presales, does a lot of stuff. So there is a significant amount of cost that goes into marketing as well. 


Thanks, Sketch. Yeah, I actually was just watching a behind the scenes where it was someone like a designer, not a designer, an artist who worked on AA game. And they were looking for the tree that they had designed. That was their job was to design a tree in this game. So it sounds like a little bit what you're talking about that you really have to kind of hone in on the details. That takes a lot of people okay, so you showed that chart of kind of the phases of game development from concept all the way to release for a game like Wildcard on average or like rough estimate, how long is each stage of that game development? How long can you expect Wildcard to take? 


That is a tough thing to answer because there's so many variables. I'm not trying to sandbag it. It's difficult to judge because each game is a little different. I could probably give some really generalized numbers. But for a live service game, which Wildcard is going to be, there's a little bit of a twist on that pipeline. So you're wanting to get to try and get to alpha as quickly really as you can. Because being a live service game, and especially us being a multiplayer game, we need to put the game in the hands of folks and start getting feedback and things like that. So for a multiplayer focused game like this, you're going to try and minimize the production part as much as you can so that you can burn through that to get a solid enough representation with enough content depth and enough longevity to get into the hands of players. 


So you can really start getting feedback and tuning that loop. How much time you spend in pre production and concept varies. Concept is probably the most varied because you just don't know how long it's going to take to find something that's amazing. What tend to happen, especially in bigger studios, is if you're doing a concept, they'll have a rough amount of time they'll want to spend on what a concept might be. And so when it gets to that time, they'll evaluate and be like, does it promise that we want to keep evaluating it or do we just want to go ahead and cut bait on this one and start a new concept? So it's just varied on that and it somewhat depends on how close you are or how promising it is. Whatever concept you're coming up with and pre production, that scope will really go in or out depending on the team size. 


It's going to depend on the art style. Significantly. Again, we're going more of a really realistic, high RESA style. You're probably going to spend a lot more time in pre production because you're going to need to understand all the types of assets you're going to need. You're going to really want to have a good sense of how long those different assets take. So that's going to be a little bit of a longer time in pre production in those cases. But yeah, that's what I would say. An alpha and beta, especially in a live service game, can last a really long time as we're getting feedback and tuning and things like that. So for a live service game, again, that's why we want to get to that stage as quickly as possible so that we're not just iterating ourselves, how we think it should be. We want it in the hands of our players because that's the most important thing is are our players enjoying it, are they having fun? 


We're going to better. So that's why we try and drive to that as fast as possible. But if you look at something like Assassin's Creed or a game like that, they're probably going to spend a lot more time in the production phase to get stuff smooth out because they don't need to worry about a multiplayer competitive balance or anything like that. It's more of a single player experience. And then if you look at something like that has a really significant narrative focus, you're going to have to spend a lot of time in production because you need to make sure everything aligns with the narrative. And you're going to have to go get all the vo done and you don't want to do the vo until you have everything kind of locked because you don't have to keep going back to Vo and all that sort of thing. 


So that's when more single player games or those open world kind of games can take a little bit longer in the production phase. That was a really great you. 


Thank you. All right, so we've got another one from Monty's. Full of good questions today, wondering if there's ever been any times in your career so not necessarily a wildcard, but anytime in your career where you realized too late that you or the team had planned something that wasn't going to work out. 


Yes, infrequently too late might be a little bit of a stretch, I would say. Usually I find it later than I would like. Too late, I don't know. That's a bit harder. There's one example I don't think I can actually go into that I wish we would have addressed differently. But generally what happens is that we think we have a good idea for something and we'll get it in the game and it'll show promise. We're like, cool, we're on the right track, and we'll keep working with it and it'll keep kind of showing progress. But then some stuff will start to happen and stuff will start taking a little bit longer than we would think, or we start running into more difficulties than we would think. But the problem is it's a little bit like that frog in the boiling water where the heat gets turned up a little bit slowly. 


So you don't really know as quickly as you would like how much time you're spending and how much time you're going to spend. So in a perfect world, we would do a thing like that. We'd realize, oh, we got this in the game with what we realized. We know we're going to have to spend like another eight months to make this as good as we want it. And then we'd be like, that is too long to do this. Let's come up with a different idea. But what really happens is you'll go and you'd be like, oh, this is really close. I like where this is going. Let's spend a little bit more time, or let's do this and keep tweaking because you want it to be good. But eventually for us, what happens is you get to a point where you're going to have to ship and that really functions, the nice forcing function for us to go, is this going to make it or not? 


And then we had to cut figure how to make the game experience great, even without getting cut out and that kind of thing. So that's typically what happens more often than actually completely too late. Because I would say, honestly, if it was too late, what would more likely happen is that we would look at that and be like, well, we can't ship with it. It's a dumpster fire, so it has to get fixed. So what else could we cut scope on or switch in order to give us the time we needed to fix whatever this thing? That doesn't happen in every case. Studios get in dire straits and sometimes they just have to push. Maybe they have an unmovable deadline or something like that and that's where you'll get stuff. Or you'll see some studios that they'll release games that are really buggy or something like that. 


And it isn't at all like the devs are like, who cares? Let's just put it out. Like they guarantee you in every single one of those cases, those Devils were working as hard as possible to try and make the game as amazing as they could and there were just business realities outside of their control. So what you want to do is as soon as you realize that you might be over the barrel on something, you want to stop, you want to bring in the stakeholders you want to look at and be like, what can we do to solve this problem? And then you brainstorm and come up with a lot of different ways that you can solve it. And that's the approach I would take in those cases. 


Thank you. So we talked about throughout this kind of the various challenges of being a producer, but if you had to say what one or two of the greatest challenges are as a producer for a game studio, what would you say those are? 


Communication is probably the number one thing. It is so hard. It doesn't sound like it would be like you're just telling people stuff, but it's so hard because everyone interprets things differently and people have different mindsets and different understandings and different reference points when we talk about something. So even in a meeting where we're trying to get like alignment, two people could be talking about the same thing but walk away from that with completely different ideas of what that actually means because they're coming at it from two very different reference points. And so a lot of the communication from that will come out. When I'm talking to a person, like person A and they're telling me their perspective on it and then I'll talk to person B and I'll get their perspective on it, I'll be like guys talking about the same thing but not at all the same thing. 


And then I have to work to figure out how to reconcile that so they understand where each other is coming from and what that is, and then to pull that up into what the real thing is. We're trying. To do. So that's really difficult. So much stuff happens so frequently that it's sometimes hard to just make sure I've gotten stuff communicated out that needs to get communicated out. We move very fast, so I guarantee I miss stuff because it's just going so fast that communication is probably the single most difficult part of the job because it's difficult to do well, and it's so important. So it's a pretty witty thing. Other thing. Other than that, this is more of a personal thing for me on the production side. That's hard. It's hard for me to cut stuff. I come from a design background. At the beginning, I've done a lot of stuff which, having been in a lot of different departments in the industries, really helps me as a producer. 


But sort of that initial first thing is design. And so when we have to cut, I consciously have to take off any kind of designer hat and consciously put on a producer hat and be like, yes, I know, that's awesome, but we don't got time right now. You'll have to come in later and make that cut. And it is tough. It hurts my soul every single time and gives me a sad. But even though that happens every single time, when we get to the end, the game is always stronger for it. So I tend to hold on to that to get me through that little bit. But, yeah, you want your game to be as amazing as it can be, and if you have to make something, not be in there. So that part is a little bit tough. That's me. I've known other producers that are like, cut it all, don't eat it, got to go. 




So that's not me. I will tend to noodle on that decision. Fret about it. But like I said at the end, though, the game is always stronger because you're able to focus on so much more other stuff for that. So it's well worth it. It just stings a lot in the moment. 


Yeah. Just a testament, though, to how close all of this is to everyone's heart that it really does feel like you're giving something up when you have to cut something, even if it's necessary. Awesome. Thanks, Sketch. Okay, so next question we've got from Luke asking, what degree do you have and how did you find your way into this role from past roles, since you mentioned you didn't actually start in production. 


Oh, that is a great question. So I actually have a degree in psychology, and my minor is in radio, television, and film. And the reason is I wanted to either go into writing or I wanted to go into games when I was growing up. And when I went to college, we didn't have an SMU Guild hall or anything like that where you could just really deep dive and get a game degree. So I kind of had to make my own game degree. And the closest thing I could think of was doing that, mostly because I had already self taught myself how to program. So I kind of felt like I had that part down, so I didn't need to do as much on the CS side. And I mostly wanted to get into design, so I wanted to focus in on how do people think, what's important to there and then what do we do when we look at presentation style things for the radio, television, film part. 


So after that I got a job working at a direct marketing firm. And I was doing associate account executive kind of works, just like kind of some busy work stuff. And one of my bosses went on to different companies, so they all came down, said, hey, we're going to promote. Everybody up. So hey Sketch, you're going to be an account manager. I'm like, wait, don't do that. And they're like, Why? You will fire me? And they're like, Why? I'm like, because the client is dumb and I will tell them so. And so they're like, okay, that doesn't seem good. So what else can you do? I'm like well, I can program and they had a huge thing of a lot of work over to doing database programming and stuff like that. So I transferred down there and started doing database programming. And about two or three months into that at lunch to a grocery store. 


And I'm dressed up in the business, casual clothes and all that. And I'm leaving and I see a friend of mine that I went to college or went to high school with come in, and he's dressed in like a T shirt and the jeans. I'm like, why are you dressed like that? And I have to be dressed like this. He's like, oh, I'm working at this game studio down the road. I'm like dude. And so we talked a little bit and they were looking for another engineer. And so he talked to his folks there and they said, oh yeah, we'll talk to you. So they interviewed me. And the interview part, I did really well in. Like, they liked my passion, they liked my energy. But then they went to do the tech interview. And I'd been doing Visual Basic at the time for a lot of time. 


I hadn't touched C plus in many months. And so I completely and utterly and totally bombed that tech part of that interview. It was terrible. But the hiring manager is like, look, I really like your passion. I like your energy. Here's what we're going to do. We're going to redo this in like a month. I'm like, okay. And so for that whole month, basically, I would work 8 hours a day. And then I would come home and I would cram and study and do programming for 10 hours a day to get all of fully refreshed and everything ready to go. Came back a month later, had that tech interview, crushed it, did great, got hired. It's awesome. Then about five months into that I realized that studio was going to go under. So I started looking around, got hired on at Ritual Entertainment as a programmer there. 


That's really where I started doing a lot more tech designing kind of stuff at the time. And that's kind of how I just got in the industry. And then from an engineer or the tech designer sort of hybrid role, just moved into more design and management. What meant what got me into production is sort of a two sided thing as I was doing all those roles. I do admittedly have a bit of a type A personality, so I like to control stuff. I also have a kind of personality that I will just pick up and start doing stuff that needs to get done. And at Richell we didn't have a lot of production sports, so I was just doing it because it needed to be done. And so I just kind of had that skill set drive from the beginning. And then when I got all the way to BioWare, were working on The Old Republic. 


I was basically the lead for all of the pods. So imagine essentially like strike teams that were working on all of the level of content. So I had direct line managing like seven or eight people and then if you look at the dotted line managing, it was like close to 50. And so as we got through all that, I went to the production group and said, you realize I'm a producer, right? That's what I do now. And they looked at it like, yes, you're right. And so I basically just became a producer at that point and doubled down and that's kind of where I've stayed because it really gives me that ability to kind of touch all those different aspects that I have. I know some engineering so I could talk to them about that. I know a little bit about design, so I talk about that. 


I'm an organizational nerd, so I like to organize, so lets me do that. So that's kind of how I fell into this. I would say it's kind of an untraditional route, to be honest. I think nowadays more folks come in with a more traditional project management background. Or I see a lot come out of QA, which is a really good thing, but I actually really like the background I have because it does give me such a broad base to understand that the way games are developed across all these different disciplines. I hope that answers the question. 


I think it does. And it also shows that there are traditional and nontraditional routes into where you want to be. So for anyone who is already established in their career and thinking about making a move, that can also happen with a psychology degree. Amazing. Well, unfortunately, we're at the end of our time today. I saw the chat message about hating this time of the event. I know it would be so cool to do Q A forever. Sketch is amazing, but alas, he has to get back to communicating and organizing the troops at Wildcard. So thank you all for being here today. This was an incredible time. I learned a lot. I hope you did, too. We'll be doing more events just like this one with other members of Wildcard so you can learn all about the inner workings behind, hopefully one of your favorite Web three games. 


Sketch, did you want to say any parting words before we signed off today? 


I'm just thankful for everyone in our community and everyone that's watching here. You all are why we do this. We love getting our stuff in front of folks and seeing the joy that could bring that's so near and dear to my essence. It's like finding ways to bring fun and joy to folks. So I can't express my appreciation enough for you people, not only just looking and playing our game, but just even taking the time to join something like this. It's so meaningful. So I really appreciate it. 

We love you guys, and the community loves you, Sketch. All right, so we'll sign off for now. As a reminder, this will be recorded on your wildfile if you do have one. Speaking of Wildfile, we launched new features today, so if you haven't seen those are in the announcements. You can add an avatar profile picture now and link multiple wallets, and it's all very cool, so go try it out. Wildfiles are free to claim. So again, thank you all for taking the time, the hour out of your day here. Thanks for the great Q and A, and we will see you at the next one. See you later.

for all your update needs

Stay Locked

Get the latest news on all things wildcard, maybe even free stuff!