Shipping Kills Studios: A Study of Indie Team Dynamics

[Music] Christmas is always one hi everyone morning welcome to day two I hope you weren't all drinking too much first day GDC parties or is a thing right hi my name is Danny and I am literally from the other side of the world that's thirty-six hours of travel every year for GDC good fun I'm from South Africa I run a studio they're called qcf design and I'm also part of a thing called make games SA which is our South African game development community we're busy starting an industry body and we're doing all sorts of cool things there we've gone from I think it was like 25 people employed in the games industry into Africa five years ago to 250 so we're doing pretty well in 2011 a prototype called desktop dungeons did that and won an idea for Ward and might change the future of my company forever which is pretty cool desktop dungeons

actually ended up finally releasing on Steam in 2013 and made its way to Android and iOS last year but that's not what this talk is about unless you really want to buy my game in which case feel free and also talking this talk is about shipping games or at least the impact that shipping games has on indie developers like us it seems that everybody has some sort of horror story about shipping some things I mean I know that desktop dungeons could colloquially be described as having an aftermath and chatting to Indies for advice about what was happening to us once we finished shipping made me realize there's a lot to talk about here and I think it's really important as Indies we get a better handle on this stuff because pay shipping games is a pretty large part of what we want to do you know if shipping is the worst thing in the world your studio is not going to survive very long so in the interest of science I or mented my sort of like off-the-cuff chatting to people like hey I'm feeling down what do I do with developers and

that is banded 18 interviews with developers sort of like really formal things recorded them and everything ranging an experience from like zero game ship to tens of game shifts so kind of the whole gamut I also chatter to a few publishers to try and get their angle on these things and after that I turned the interviews into a series of questions that I loved another thirty further further forty five developers to get their thoughts on the things that the interviews had highlighted as important areas and now this can be a pretty loaded topic like if everybody has a terrifying story about shipping their game chances are they feel quite strongly about it and there are some pretty hectic memories so the whole point of this was to isolate learning from those events as opposed to like make them identifiable so I tend to talk in the immediate person and I only show graphs when they can be fully anonymized and I'm not providing any information that was given to me in

confidence because I trust and respect the people who told me things that they probably shouldn't have told me so time for some background for the context of this talk shipping a game is mostly from the indie perspective I'm not talking about the triple-a a kind of pump and dump cycle that's a completely different thing it's terrible and hopefully it makes more Indies also shipping is a nice problem to have one of the reasons we probably don't talk about that this much is because in the industry 90% of games don't ship and they don't ship for a whole host of reasons and sorting out those problems upfront it's probably a really really good focus point but if we want longevity if we want to avoid what people are talking about next door we need to get better at shipping and one of the things that came out of this is that shipping is a relatively long process so as a starting point I said cool shipping is when the game is first released to the public

so when payers can first download your game or converse buy your game as a finished product and it ends when in-house development ceases so that includes porting and bug fixing and everything at some point every has a stage where they can say I'm putting this game to bed it's done maybe they revisited every once in a while but usually it's done and shipping tends to very an impact quite hugely depending on the experience levels of the team working on it so if you've shipped a lot of games before probably your next ship is not going to be terrible and shipping isn't uploading a game to a store and kind of just hoping and that happens a lot like I know in South Africa that's kind of the major issues that we have that's literally just putting something out there and yeah shipping is the point at which business intersects most strongly with game development so if you're not thinking about business and the business impacts of your actions you're not shipping again and shipping isn't early

access I know I'm going to get questions about this later but early access is a preamble to shipping yes some of the things you're doing are putting the game in front of people and now you're dealing with their responses and you have to deal with tech support you have to handle a whole bunch of issues but that you're still in this creative development mode you're not really like focusing very much on the business angle of things and early access often tends to suffer when you focus on polishing your game players tend not to like that because you're not giving them this drip feed of new content all the time you're just making that content look slightly better and the menus have less bugs and stuff like that that's not really fun and even if you do early access you're still going to do some kind of full launch later that is the point of shipping in a project like that so shipping is the process it starts well before release day you start thinking how about how you make this game ready to release instead of what you can add

and what new cool things you can change and how you can make this better or whatever you're literally just like what is the product we can put out there and often this is the point at which development stops being fun for a lot of Indies because you know faces feature cuts on joyful like maybe they are but generally they're not the game once the game gets the players that's sort of just the tip of the iceberg so shipping continues off their release now you have commitments you've got to keep this game going you have players that have paid you money for what you've been putting out there and also shipping seems to be difficult for everybody or at least difficult to the developers I spoke to these are them are all level responses in the questionnaire for both a team and individual perspective on your morale at the start of a project halfway through two months before shipping date of shipping two months officer and then like putting the project to bed

there's a definite downward trend that I mean it's difficult to compare a six-month game project to a five-year project so we had relative cycles there's a definite downward trend and morale although being in a team does seem to have a stabilizing influence seeing is individual more all tended to be more negative than the perceived enthusiasm of the teams that people were part of so people who are having really negative experiences said their teams were more positive than they were so team sin tended to lift people up and also sometimes you would have people put like wildly varying levels of morale at different times in the project and their teams were always a lot more stable apparently the thing about shipping is that no team survives even if being in the team helped and the same people stick together their roles will have changed drastically because shipping is a different thing and this is the pot that kills Studios either you embrace these changes that your team is going to have to go through and you survive or you

don't so the reasons teams change is because a team is going to have to suddenly start performing really different tasks to what they've been doing for most of the cycle of development before please draw us on a hurry double a our show the rest of experience levels from the questionnaire in the skill categories that we identified by the interviews so we have programming you know the classic programming content development game design testing and QA project management in human resources community management PR and marketing business development and tech support I don't think it's a surprise that there's a serious skewing towards the front of that list you know most of us are developers we focus on the development side but and this is even more obvious in teams that have never shipped a game before you know the numbers of answers where people said they had absolutely no experience and the bottom half they're kind of interesting and a little bit

scary and the thing the skills that have the least experience in the SKA are the ones that are already really necessary once normal development stops once you stop kind of building your content then you have to focus on your PR on marketing and your business development and your tech support and if a team hasn't recognized that these responsibilities are going to change as the project sort of moved towards the shipping conclusion that's going to cause a lot of problems one of the things that happens is that development becomes support so you know hands up everyone that loves bug hunts yeah okay you're all going to be super popular later so just everybody sitting around them remember who did that you have customers now and you owe them a fully functioning product otherwise you know deep refunds and everybody dies you have

to keep that going if you don't support your game suffers in sales your reputation goes down your visibility goes down obviously that's a terrible thing so support which is programming tasks into this bug finding and killing mode from the fun development mode and not just for a little while like it goes into that mode for the rest of the lifetime of that game and testing is really really difficult to keep up so in interviews everybody mentioned the importance of testing every change you make need to be tested absolutely exhaustively before you can release a patch otherwise all you're doing is making more testing work for yourself and more patching work for yourself and yeah you think you've tested before once you release a game testing is a completely different procedure and there's a major difference between experienced and neuter shipping teams like you could tell instantly who had done what based on how they approach testing and this isn't like saying

experienced teams have less bugs sometimes they have more it's literally just that experienced teams have a very very very different approach to testing than inexperienced team and you support means talking to pretty horrible people like you're generally speaking to the angriest players in your player base which is not the best thing in the world design starts becoming public relations and in a way design becomes basically apologizing for things you're no longer solving interesting problems you're not designing the huge fun things that the game is built around and in fact you can pretty much never change those again you're stuck with them so you end up justifying the old solutions that you came up with sometimes that's through you know support emails where you try and explain stuff to people or literally through band-aids in code or in your design or in your UI things that like you need to

support the decision you made in the past and maybe you have a better idea now but changing it is probably going to impact the game in a much larger way than you would like to this is a bit like thousands of the worst customer emails ever all the memes where people like make it green change that it's not good fun and copywriting versus kind of like design documentation management is just not the same it's a completely different skill and you have to produce a lot of PR emails and marketing copy and basically that's just finding 15,000 different ways to say the same thing as opposed to finding ways to communicate about development stuff to the rest of your team and marketing uses immediacy so you're never going to be a new game again gret care about URL of a lot less so once your game comes out yay press attention once your game is out for a long time try getting more press attention and everything is work to create that press attention like you have to come up with new stories you have to come up with new

ways to try and get people interested it's tricky and the launch spike makes all your other kind of like long-term marketing look kind of bad the very necessary marketing work you do need to do feels less and less effective because you're comparing your spikes to your baseline you know unless you're perfectly perfectionist and this is where the actual skill of marketing comes in up until this point you can get away with regular development updates and you know pretending to be a marketing campaign but here this point is where marketing stops being a side effects of other works and it becomes a job all on its own that's a different set of skills and obviously this causes problems as the demands on a team change and people start doing jobs they're not used to or may not even understand 90% of the time obviously things go wrong so caveat briefly here if your game flops you probably don't have to deal with the things I'm about to explain but you have a completely different set of problems

like yay one of the biggest things people complained about with the feeling of a lack of creativity creative coders and designers often chase against the boringness of support tasks and support can just feel really stagnant people want to work on the next the next game or new prototypes or the next thing whatever it is and it's difficult to abandon something especially once you've shipped it in it's earning income for your team and burnout often just adds up very few people know how to deal with burnout effectively if you can't super hard before launch obviously that makes everything worse the pressure that you built up doesn't get a chance to abate in constructive ways everybody's still kind of angry at each other and the pressure of making a ship date can often sweep issues under the rug so like teams kind of just tend to ignore things that have gone wrong hoping that like once we ship will fix it it'll be fine we'll go away and hot tub and everybody will love each other again and those things do come

back to bite you later and post-launch depression definitely exists I wish you could see some of the comments we got about this some people are lucky and they don't experience it personally but when you're looking at it from a studio perspective and you have more than one person in your team it's definitely real and you just release something that carries expectations those expectations are sometimes different and often they're not met and the resulting low after development can be pretty depressing especially if you're not actually in a lull and you're scrambling to do things that you didn't know how to do before their addition to what you did while you were working on the game and finally there are people chances are if your job involves staring at the screen all day you might not be a people person and support often means really really angry people and dealing with that is never that much fun you know we used to have a saying love and tolerate the out of people and that is often tricky

and people write things about you and your work reviews and opinions can definitely impact team we're all and everybody's reading them even if they say they're not you know it's like I'll just ignore what's going on sneakily off to read it see what people say and they never say nice things or when they do you never notice and all of these stuff kind of snowball and hit small teams much harder if your team was built to do development work it'll have development skills and when shipping happens and your skill needs change as they do it'll have to scramble to meet the needs if you don't hire new people this is like super harsh and let people to man their amperage means if something breaks you have less options for people to go away on holiday to recoup to do anything different because somebody has to be there in case things hit the fan and when you do start a new game working on it will never be the same as previously when you didn't have something to support so now any new game you make has

some kind of thing in the background that always needs your attention you basically have a baby and it needs its diaper is changed and needs to be taken to school and it needs to have sleepovers with its friends and all sorts of things like that that is the weirdest analogy for bundling I've ever thought of yeah but the biggest issue with all of this is that people expect things to be very very different when they ship a game so shipping is kind of this like inflection point in the studio's lifetime and it definitely is but not for the reasons that people think the reason skill changes are so damaging is because the skill change is unexpected and people were like literally hoping for this massive amount of relief this is a graph of the most common expectations that respondents had about shipping their games people who'd never ship the game before on the left and multi shippers on the right by the time a game ships teens really are carrying a lot of assumptions about what shipping means often it's pretty chaotic and there's a big skewing towards people wanting to be done with a

project after they ship you can see that in the number of people who are talking about moving on to new projects the sense of closure was a really big one and also a freedom to leave or start over or join a new team those are all about getting out of the current situation so it's kind of like a certain level of unhappiness with what's currently going on and the fact that community management and tech support isn't like at 100% is really weird like who doesn't expect to do tech support when they should be game and if you do yeah so experienced developers ship games easier and here's what those I study do to mitigate the issues that I just talked about they seriously engage in hardcore expectation management I know that sounds like marketing speak and it kind of is but expectation management is the thing just being aware of what shipping entails and being realistic about that makes life a lot easier you don't get blindsided by the

same problems there are new problems but they're kind of less big if they're not on top of the other ones as well and they track perceptions of success this is the thing that I think really kind of took me a while to understand is that different people in your team have different goals they have different ideas of success and those change massively per person some people are going to be like I want the ought to be absolutely amazing other people care about making sure that your players are super happy other people only care about like finances or review scores or whatever and it's totally cool to track all of those but as somebody running a studio or somebody as part of a team you need to kind of be aware of what other people care about as success in your team and you need to make sure that you as a team define your own success so that you can look back after your shift your game or while you're shipping your game and say hey we're hitting this success factor we're hitting this we're doing this we can remind ourselves because everybody always expects their game to do better

than it does no matter how well it does everybody always expects it to do better as long as you have those milestones and those ideas of this is what success means to us you can remind yourself and that keeps people a lot more grounded and keeps people a lot happier and they also plan for what happens after they ship their game and they plan realistically like I said before a lot of people assume that hey I'm going to ship my game and we'll be able to like hang out as friends again and life will be good and we'll be happy and we know sunflowers roses and pineapples I don't know where the pineapples get from cool but experienced developers don't see shipping is this big cliff where so does everything stopped and they're like ah relief they plan ahead so they plan is though they're going to need to ship again and again and again they want to ship more than one game so they need to keep that tanning going they also tend to have some pretty good systems around support and testing a good support

ticketing system will lower your load or the impact of any kind of support loads immensely and a good system will a team members work together to fix issues and tag each other and those of the things Miz loads the systems out there I'm not going to do a laundry list of the things you should use just try them see which ones work for your team and they make life a lot easier and again testing and how testing was handled across teams was a major differentiator in levels of team morale and happiness and how well people felt they were doing with their next games as well teams with Lang shipping had super robust testing and QA internally externally paid it didn't matter and these are pretty small nd teams the due paid external QA but they tested for bugs and issues all the time teams have had a hard time shipping we're blindsided by testing all the time and they only set up things towards the end of like a long process of shipping

when they were already annoyed and they are already tired and they already felt like this shouldn't be a thing that they're actually doing and you know business is important this is where the business part of the games industry gets the most real for your studio so you have to know where the money if any if you make some is going and how if you don't know how people are going to get money how your investors are going to get paid what your bonus cycles are everything if you don't have that lined up and before you actually start money you know start making money negotiations when dollars hit the fan are going to be absolutely terrible and you really need proper contracts you contract give you the security of knowing what everybody's job is what people's responsibilities are you have to know those upfront that's what contracts allow you to do if you if you're not sure whose job it is to like make sure the servers are running mm-hmm if you don't know who's responsible for

all your tech support and responsible for the marketing that's going to be a problem and also if you kind of have to be aware that now that you're thinking in a business mode of your game things might well go wrong and this is the time when that's most likely to happen due to all the other stresses we had or we mentioned and the things that might go wrong in the way that the team might be thinking about stuff this is when hit the fan and it's a time of really really huge change so make sure that if things do change you're not just going to shut down and die and everybody's going to hate each other and I don't know how obvious this is but other people on companies are suddenly going to do they're done just to earn money from you and that means everything from like g2a spam emails and you know the streamer is asking for thousands of keys to people literally just trying to like scam you and get you into weird bundles and whatever sometimes these things are fair and they're a good opportunity sometimes they're completely

unfair and they're terrible opportunities you've got to be prepared to be able to handle that don't just take every opportunity that you see don't just be like yeah we're going to bundle right now it's going to be the best idea chances are it's not gonna solve whatever problem is preventing your game from succeeding experienced developers tend to think in terms of teams mostly because teams can do so much more than people on their own even solo developers often have people that they're working with they have contractors they have acquaintances that often you know rock up and help them out and they feed them or whatever it whatever their agreement is we had very very few respondents who only had like lied to me working on my game I'm some kind of crazy superstar and teams are an exponential multiplier on the amount of work that goes into a game and the amount of the the outcome the effort has so make sure that the team that just made this cool thing this game that you're thinking about shipping or that you're near to shipping now make sure that that team can still survive and ship another thing because chances are you're pretty good at working

together now sometimes that means you need to sort of take a backseat from the individual perspective and think of things as a team instead of just like I'm annoyed about this and also everyone interviewed mentioned how team communication was really really important and it was really interesting hearing how different developers were talking about their teams and talking about how their team interaction worked and this isn't just like from the perspective of friendliness but from a trust perspective a team that trust each other can critique each other and they will always work better together and don't let things build up handle your problems early as soon as they appear a lot of times especially while you're like crunching or you're chipping and things are bad you let these things build up and kind of sweep them under the rug like I said before that's going to come back and bite you later on and if these things are recurring consider making pretty large changes to your team

or to the team structure itself to make sure that they don't keep coming back you know if you've taken steps to try and solve something and the real reason is something else don't assume that doing the same thing again is going to have an impact and these can be difficult conversations but everybody said they will always be way more difficult if you need them later they don't get easier if you leave people alone and sometimes you need to be aware that your team is going to grow in fact all the time you need to be aware that your team is going to grow you're going to be working with different people you're going to be working with contact people in terms of distribution people in terms of marketing etc so your team is going to get larger how you communicate and how you handle that is a pretty good indicator of shipping success teams that were ok with with embracing more people and we're welcoming to those people were much more likely to succeed and to stay around after their game finished so what lessons can we take from this sort of

stuff that I've been talking about in terms of what can we do explicitly to make shipping easier for all of our studios I hope you've noticed that I talked about skills a lot in this talk and mostly that's because the skills that people require to ship a game are very very different to what development needs generally are so you can get away with building a game with none of these skills for ages that's cool but when the skills win when you start shipping and you need these skills you have to find them or hire them or build them inside your team whatever you need to do you need to start thinking about cool we need people that can handle PR we need people that can handle HR and deal with the burn on factor that shipping is an entirely different job and that needs a different team and perspective on these things is everything I mean there are detail-oriented programmers out there the people with their hand up earlier who don't want to necessarily be working

on gameplay code they're great at handling bugs and you can sort of think of it as people who would rather race cars or people who would tune them up there's a big difference in perspective between those things and those people see cars completely different things but we're like to look at the car okay that perspective is really important if you can find somebody who has a different perspective on the sorts of skills and the problems that your team is having life is better and it's your job to get these two kinds of programmers and by extension be two kinds of people working on everything you know HR etc to play together well I mean that's why this is a team sport there are people out there that who will positively love every sort of interaction that your team seems to hate and if your team hates something it's actually an opportunity to do something crazy well it's an opportunity to succeed because chances are if you hate it other people going to hate it too and therefore their games not going to do very well or you can do something better than their game isn't doing and finding

the right skills or the person is or the right person for a specific job like that is often this rocket fuel motivation that takes your team to another level of building stuff instead of being super drained by the active shipping that can energize everyone and yeah you kind of have to allow people to change as you go through a long development cycle people's needs are going to change people's approaches to what they enjoy or what they dislike you're going to change sometimes people will say like yeah sure I'll try this task I'll try like being the tech support person or being a bug ninja maybe they don't like it that's okay maybe there needs to change so much that they no longer want to be in part of the project and they need that's okay too these things happen and business again like I said is what shipping is all about generally people who had a business perspective really enjoyed shipping often this is where publishers were most useful to indie Studios

because they provided a business development angle and and do your publishers live to ship and from a business perspective your studio is a garden so it puts out what you plant in it the people who've shipped 20 plus games talk about projects in very different ways to people who've never shipped the game before the super shippers they're positive and yeah they're nervous and they're anxious about success and they're worried about what their game might earn but they believe in what they're doing and they can tell you exactly why what they're doing is a good idea realistically and they will talk about things you have never thought of and you know again crunch is bad crunch is bad ok many people I spoke to you've missed their own launch parties you because they were developing until like the final moment

of release and then carrying on after that terrifying and while crunching is probably inevitable if you're not a very experienced team it means you fail that management just crunch is bad don't do it and there's very little to commend crunch most people said it was way better to push back their release date and release much later than to crunch for months to hit something that they thought was crazy important crunch changes perspectives from producing quality to producing output and that's a bad thing you're never going to ship something when you're just trying to produce output burnout when coupled with crunch is even worse so one of the tricks is to manage developer burnout upfront some studios had multiple teams and obviously workers with different kind of skill loadouts think of different characters and RPG and they would cycle people on and off of their project because of it others would mandate time off after shipping everyone I spoke to literally

everyone gave at least two weeks of paid leave after a game shipped at different times most did more and you don't want to kind of force people to come back to work it's much better to wait until people are literally going crazy because they haven't built something in like a few weeks then to try and force everybody to sit down and like yeah come up with the next prototype come on do it and so the next thing is to think in terms of the long-term we also know the questions about where people got mentorship from and the sorts of questions they asked and there was an interesting skew towards the business angle the people approach mentors for at least in the experience studios the inexperience tutors were all like how do I program what does hot work and that that was a bit telling so experience doesn't need to be yours like there's this is a

conference covered in huge amounts of experience go and ask people who have shift games if you're worried about like oh my project is X long I don't know if it's going to work I'm not sure how we're going to survive everybody hates everyone else now how do we deal with this what do people here have dealt with the same problem and they'll be able to tell you so there's personal solutions and in terms of the long-term publishers are a really good solution if you can't necessarily hire people to take over the skill burden of shipping games publishers live for that like interviewing a publisher and interviewing game developer and talking about shipping was like I wasn't talking about the same thing the one person I was talking about being ill for three months and the other person I was talking about cake it was just like oh and where developers are like hah I really I like being able to do the stuff that I was doing before publishers are like shipping is right we need more ideas to ship this thing come on pretty interesting but again with publishers

make sure they're always providing value to your team and value to your game you don't want to just sign with a publisher because you're hoping like yeah they're not going to hate this as much as we are chances are if they don't find something to love if they don't find a way to add value it's not going to be worth it for you and budget for time after you ship make sure that you're not like you know hey where's ship this game and then immediately we'll go on to the next work-for-hire project and we'll hope that we make enough revenue share while this is happening and then life will be great you're going to need it I mean if you're broke how will you support the studio that's the question you need to be able to answer how will you start and find another client if you've been pushing really hard for three weeks or pushing really hard for five years to finish your game deal flow is tricky what do you do if the game doesn't know where is your income coming from these are all questions you need to have and shipping is never going to be a magic bullet to solve those problems like oh yeah we'll put this game out there and everybody will make a million money no just like five people in the history of

ever that that's happened to and think of your plans is like being at least a year long so try to plan for these like under six months plan a year plan and maybe an eighteen month plan if you can they don't have to be super detailed you know being asked so what's the next game it is often the most annoying question that you'll get that's like they've made up and you know when you're talking to press that like what are you doing next and that's alright but if you don't have an answer it kind of means you don't have a plan so if you have a little bit of a plan answering that's really easy and it doesn't have to be super accurate just you know hey yeah we're going to do this next or we're spending this meant this long prototyping but be careful of putting the burden of running your studio on prototypes so when you do prototype have goals how many prototypes you can do how long is each prototype we lost how long is the entire prototyping session going to last what new skills do you want to learn who do you want to try in different

positions on the team what new people do you want to bring in and try on the prototypes goals for prototyping are crazy important and that requires a longer term plan prototyping on its own is never going to solve any of your issues and then the most important thing is to look back and learn and you need to reevaluate when every time you finish a game or every time you get a game to the point where your gifts working yeah every time you get a game to the point where you're thinking about shipping it look back and go okay what could we do better we do this differently what problems could we solve you know if your PR was bad on your previous game do something about it if you crunched and everyone hates them each other avoid it next time figure out your management problems the reality is that even if you've shipped a lot of games before and this surprised me every developer I spoke to always had things that they wanted to learn from about their previous game they're like oh we

should fit in this didn't work and we shouldn't and this didn't work and then previously we tried this thing in blah and one of the things reasons for that is that the market conditions change when business hits your game when you start trying to make money off of this thing you're never going to be shipping the same game that you were or shipping into the same environment that you started building your game in so your predictions are going to be wrong you kind of need to learn how to deal with that and that's a skill you've got to practice that and if you're already reasonably good at dealing with the problems you have lost ship then now the new problems are going to be much smaller and they're going to feel much less overwhelming so and there's just one more small thing before I wrap up and we can do questions and this is pretty universal doesn't it together being in the same space constantly while trying to ship a game is a multiplier

for every single stress I've mentioned in every single problem that developers have it creates an environment in British crunch is much much easier to get into because you never really stop working and it offers few outlets for the relaxation necessary for people to kind of turn off work and calm down and go do other things you might all love each other and be the best of friends and have the best time but the teams that live together had the hardest time and you know hey this is not necessarily a cause and effect thing it might be the teams that live together for budgetary reasons also had the worst approaches to management etcetera etcetera but even teams that were living together because it was convenient or because they thought it was the best way that they could make games still had a bad time so questions and yeah feel free to ask us about early access if you need [Music]

I also really wish that I could take all the interviews that I did and make them podcast but that would violate everybody's privacy there is a huge amount of learning in those things so you know I strongly recommend that if you have questions about the business of running a studio or what it's like to deal with the problems you're currently having reach out to a developer that you think has already solved those chances are they'll respond you know so I I feel like everybody has kind of an assumption about what the term crunch means and I never hear a formal definition would you mind describing your definition Wow okay I'm being asked for a formal definition of crunch um in the questionnaire I asked people what flavor of crunch they've experienced mostly because a definition of crunch is a tricky thing I think a lot of people use time at work

you notice or anything above whatever your kind of current work environment standard hours are and other people use amount of time taken from other activities which is what I personally prefer so if your taking time from family time that's much if your taking time as a team you know in this difference between mandated crunch where it's like your producers on everybody's ass and saying like you have to be in the next time in the office or everybody's fired versus people choosing to crunch on their own because they feel they have a goal or they're like oh I'm slightly behind on this thing I'm going to work on this a little bit harder it's the things you're taking time from that you meant much different most often don't notice a lot of people only start thinking about crunches crunch when they're taking time away from sleep but there are things that you're taking things away from before that point so yeah so thank you I just want to just say excellent talk it's been one of my

favorite so far curious to know either your personal opinion or the opinions of the people you've interviewed in regards to answering support emails specifically in terms of honesty like how honest if you recommend being I've seen it go both ways I've seen people be like oh thanks like I really feel like I understand like what you're going through is developer more and I've also seen a backfire where somebody's been like oh you're not fixing the netcode you're abandoning the community I don't want anything to do with you I'm going to scream as loud as possible about it okay um so general strategies for responding to support emails I think those change according to the team and according to the skill sets you have if you have somebody that's good at writing on your team then you can afford to be a little bit more responsive if you have somebody that's really good at community management they know how to talk to your players and they're an established voice

because the things where people like often listen and really respond well is when they're being responded to by somebody that they expect to respond to them so there's a way that the studio communicates or there's a way that X tech support person communicates with people this can vary I mean if you're funny or you think you're funny and you have like a cool response I mean we have this massively sarcastic forum email when people ask us when something's coming out on the phone and we're like this is the worst forever and this is you just search replace for xxxxX for whatever phone they've mentioned like this one is terrible it's the worst everything is bad we hate it and then it goes in this weird tirade about like movies in the 80s and then it comes back and it's really stupid but people love it and they love it because that's sort of how we communicate in the game already and therefore that makes sense generally if you're unsure ask someone an awesome one outside of your team and these are things that you can build strategies for so you know as robotic as it sounds have

a flowchart like is Steve here yes Steve should answer the mail you know is Steve not here no are we currently angry yet send the email to Steve you know like build processes for this sort of stuff and it differs according to your team hey Danny you emphasize testing a lot in your talk and you know like and you mentioned that you know regardless of the size of your team you know like like experience teams tend to like have like whether it's Paige you a or the internal QA like a very robust QA process and I was wondering if you could give more details about like Oh what worked for certain teams or like if you saw any patterns that emerge um they're different teams had okay so the question is if there were patterns in QA responses because I was talking about it a lot and how teams tended to test it wasn't so much the teams had specific ways of testing that were common to

everybody some teams had days of the week where no new development happened and they all need to test it other teams had internal QA people that were constantly testing so like they were always a couple of builds behind and if a build was not okayed for release by this person it didn't go out okay and obviously that person was plugged into their bug finding and bug system and all the rest of it testing is often and an interaction between how good your bug notation is and how many cheat keys you have in your game for your developers so if you have really really good bug notation and your your bug system is like has no repetition and everything is like assigned to the correct person and whatever that's great step one step two if that person when they're fixing the bug is using chi-chi's that players are not necessarily going to use then you

often have issues where that bug is masters fixed and it's not actually properly tested so having that kind of like semi pedantic angle to making sure your testing is as close to what players are going to do in your game as possible that's really important and then there's also kind of like an approach to testing that relies on marking systems is dirty so if you have a very compartmentalized game okay you change your collision detection a little bit that makes everything pretty dirty because you know if you have an endless-runner collision detection interacts with everything in the game but if you change an animation system then that doesn't really mark everything else as dirty so you don't need to retest everything you only need to test those animations and kind of what they look like to the player because they're not going to suddenly makes your scores change they're not going to make players clip through walls unless your animation system is really weird so if you make a roguelike every time you make a tiny change or a procedural game every time you make a tiny change everything is marked as dirty and you have to retest

the entire thing from scratch so don't do those game they're bad awesome thank you hey Danny I'm just wondering if in interviews or experience any of your advice would be different when dealing specifically with contractors people who aren't necessarily planning on sticking with the team after project is done you know you're in production and you're you can't really support like full-time whatever so you're bring out a bunch people who in their minds that is the games done I'm leaving yeah it says any different like to you so it reads them differently I know there there's some interesting approaches here a lot of people recommend in terms of like dealing with shipping focusing on kind of a more Hollywood bubble which is all contractors and bringing in people from very specific things if you're bringing in contractors often what happens is they leave when the game is done and unless you're really prescient and you're aware that the skill needs of your game are going to change you don't have them for tech support right so tech support falls on a different person which is fine if that person is okay with it if that person is you and all of

these skill changes suddenly end up falling on you because you're running a team and all your contractors are gone that's going to be terrible there are a lot of stories where people were telling me things like that they're like yeah everybody left when the game was done I'm like well did you hire them for when the game was finished or did you hire them just to finish the game and people like I never thought about that part and also why not hire contractors to help you with shipping hire a contractor that's really good at community management you know they should pay for themselves hire a contractor that's really good at bug finding they should pay for themselves so if you're only contracting people your contracting loadout doesn't go away after you ship it just changes so you might need more people and maybe you only need them part-time but focus on getting people to do the job and the skills that shipping needs hi

how early in the development process are you thinking about testing hmm how early should you test well well planning for testing - okay I kind of think relatively early I'm a big proponent of like fast prototyping so fast prototyping is essentially undirected testing really early in a project cycle it's not like oh hey we've built the entire game design document and then thing and whatever and waterfall model and everybody starts it's once you understand your game and you understand what you're offering your players and the things you want your players to feel and the goals the pairs are going to have while they're playing the game and you have like methods to evaluate your general gameplay that's when you should start building a testing system or a testing methodology and the earlier you build that in the less of a imposition it's going to feel on the

people that have to implement it who may never have thought about implementing something like this before so if you if you suddenly only start focusing about testing after your game ship and you have just released patch number five in day two of your game being on Steam and everybody is really angry with you because now the same bug that was fixed previously is back but it's worth you know people are going to be upset with your testing methodology if you have a robust testing methodology from super early on in development that's great you know if you have a system that allows you to automate some of your testing because you've been building that into your game continuously that's going to save a huge amount of time so I would say start as early as you have some kind of metric cool thanks hi this is sort of a question about the end like you've been supporting a game for two years and now you're going to really stop to any

resources to that and move on and it's been two years and really we're done with it um did you get any feedback from people about like how to handle the emails like why don't you pass your game in six months well we're done with that now and we've moved on like any ideas about how to handle that like end of the relationship yeah so how to handle when a game is done and you're no longer necessarily working on it actively again that depends on the team and it depends on the game you need to be making these decisions from a business perspective so if the cost of time of putting in more time into this game is not going to return probably a bad idea probably a better things you could be doing with that time essentially if the only reason you're no longer working on this game is because everybody's really angry with it and like you're super annoyed then chances are maybe there are not better things you could be doing with your time and you're just kind of feeling the impacts of some kind of burnout or some kind of other problem to

do with skill mismanagement so I would say that it depends on what kind of amount of work is required and those are always business decisions sometimes you'll get like and you know somebody coming to you in a year's time or whatever and they're like hey you know a year off you stopped patching a game that I caught we want to localize this game into Swahili it would be a great idea and none of you know where people speak Swahili do you yeah yeah you fail they want to localize the game into like a weird language like Swahili or whatever and you're like well it's going to take me half a minute to you know change the localization text file because I have one of those yeah cool let's do it and then you re-release because of that basically if supporting the game is damaging to your company don't do it and if your communication around that is the thing that you're not sure about are some you know there's lots of people that

handle PR there's lots of people that I mean if you go to any kind of like VC or startup environment there are people who will tell you oh yeah don't say that to be bored and say that people don't elect people your communication should be in the same style and I think is Indies we're generally pretty open with our audiences so if you just say hey look we got to work on other games often the easiest way to tell people you're no longer supporting a thing is good oh yeah sorry we're not doing this anymore here's the screenshot of what we're currently doing you know and you give them a link to a prototype or whatever it is and you kind of deflect people to the new part of your forum where they can interact with the current game that you're building and like at that point people are usually pretty happy because then I go you're doing something new well that's cool yeah rad nobody asked about early access yes brilliant that means my wording change worked I think

we're pretty much done so if you'd like to head out please remember to fill out your evaluations and thank you very much for coming I hope every single one of you shifts again [Applause] [Music]