From Indie to Fable & Back Again: 30 Years of "Wisdom"

[Music] It is now 120. Yes, I shall begin. So, this is from Indie to Fable and back. 30 years of wisdom. You'll note the inverted commas. As Ramy said yesterday, all advice is bad advice. And I'm sure this will be no different. Uh my name is Dean Carter. I'm the managing director of Fluttermind LLC. Uh at Fluttermind, imaginatively. Uh, and I've had the genuine pleasure of being in this industry professionally for 33 years. I've been writing games since I was 14 years old. Uh, that was back in 1984 for those who can't be bothered to do the maths, which I quite understand. It is after lunch after all. So, without further ado, um, before I start, I need to mention a basic housekeeping thing. So, please turn off your mobile phone ringers. Don't stand up and have loud have loud conversations. Don't throw things. Um, and please fill in the online review form thing so the people who run this know not to book me again next year.

That'd be very much appreciated. So, 33 years. What have I done with that time? Justify your existence. Um, I created a game called Druid on the Commodore 64, which did relatively well, which is kind of second from top left. Uh, I was part of the core team on the original Dungeon Keeper, which is sort of top right. There's some very old people in this audience. Uh, I started the Fable franchise with my brother Simon and Ian Love It, who are both down there. If you want to throw things at them, it's fine. That is allowed. Uh, I wrote Incaboto, which is game bottom middle, uh, which did really well and, um, I loved making it. And my current project is a game called Warden Cliff, which is bottom right over there with the weird bunny thing. Uh, you'll see the bunny theme revisited several times during this. So, I've worked in companies of all scales, tiny, solo, bedroom 80s, indie things, you know, those nerdy pictures you see from that period of time. Um, and all the way up through AAA to kind of EA,

uh, and Microsoft. Uh, and so I've kind of seen it all several times in one form or another. Um, but before I go on, I'd actually like to ask the audience a few questions so I get to know you all a little better. Uh, how many people here have released a game professionally? How many people have released a game here unprofessionally? Yeah, it's a more difficult one to ask. Yeah, I'm I'm both. Um, how many of you would self-define as artists? Okay, the stoned well-dressed ones, right? How many of you would define yourselves as coders? People who tap away at key. A lot of you. Good lord. Yeah, you're the you're the pale, precise ones, right? And how many of you are solo developers? People who don't let anybody else into your life because you're complete control freaks. Yeah. Okay. Yeah. They're the lonely, haunted looking ones. I feel your pain. Um that's me nowadays. Okay. Thank you for that. This talk isn't like a lot of other talks. It's not how to make lots

of money. It's not a survivor bias the opera or whatever else somebody's doing down the road. Uh it's just a collection of weird stuff I've learned along the way that I kind of wish I'd known a little bit earlier and would have made my life a little bit easier. Uh, so with that, let's take a look at the first thing I learned. So, start as you mean to go on. That's what I say. Uh, my first game, Rockman, made $7,500 for two weeks of work. Yay. 1985. I worked out that I could make 26 games a year, which was $195,000 or kaching $438,077 in today's money. Good lord. See, my takeaway really should have been I was a complete idiot because even in the 80s, making games profit profitably was nearly impossible. I really should read these sentences and then write them. Um, even the best 80s developers

only got 12 to 14% royalties for a finished game. That is literally you'd end up with a situation like this. Hello, Mr. Publisher. I've got a game. Have you finished it? Yes, I'll have that then. I'll give you 12%. Thank you. And that was it. That was your relationship. You had no control over covers. Absolutely nothing. It was very, very hard to make money. And so that's why a lot of people of my age who come from my background kind of went stuff this and went did something more profitable instead. Everything is cyclic and I know a lot of developers here are struggling again to make money. It's nothing new. But this time you've got a larger audience. You've got more distribution channels and you have decades of development to learn from. Decades of mistakes I have made and people like me you can avoid making them. So again I should have practiced the order of that a bit better too. So, moving on from that, this is one of the things I really should have learned a bit quicker. This started with my very very first game again, Rockman. Um,

which when I was developing it looked like this. Now, you'll notice a couple of things. The artists there are kind of crossing their arms and biting their lips and kind of going, "His light sources are coming from all sorts of different directions. He clearly has a very poor grasp of shadow and form." The more keen amongst you will notice it's in black and white. And this was on a ZX Spectrum which wasn't black and white. So why was it black and white? Because I was poor and my family were poor and my development machine was literally a ZedX Spectrum and a black and white television set. Now the problem here is I forgot that a majority of my audience were not poor people like me with a black and white TV set. So when they got to play the game, it looked like this. I'm now going to use a quote from a review. hideishly garish graphics. I was 15. It hurt. But the takeaway here really should have been, players see things completely

differently to you as a developer. Your development environment is not representative of the final experience the player's going to have. A black and white TV was not representative of my players final hardware. And while nobody here is developing in black and white, unless for artistic reasons, it's important to remember that I did not hear anything. It is important to remember players perceive things completely differently to you. Your players are not hunched over a copy of Unity with gray borders surrounding a tiny screen. Your players are not looking for bugs. Your players have not seen the same scenarios 50 times over that day alone. If you forget that, it can lead to complexity and difficulty creep. So, watch out. And then there's the real world to take into consideration. Your real players lounge on a sofa or relax near their PC, probably with a beer. Real players don't pay attention or understand that crucial information is crucial. Real players go on holiday and need to remember what

they were doing when they return. Real players take a break because they need the toilet after all that beer. And if you haven't tested your mobile game on the toilet, you're in trouble because that's what real players do. That if you're developing mobile, that is just think of that for a moment. It's kind of troubling, isn't it? And finally, the most humbling thing of all is real players don't care about your game as much as you do. That's just the way the world is. It's fine. Fundamentally, players live inside their own brains and not yours. Your players aren't living your life, experiencing things through your senses. Some of your players don't speak English as a first language. Some aren't straight white guys. Shakara. But most of all, stuff that's absolutely obvious to you will seem utterly bizarre and alien to somebody who does not live in your own head. So when you are designing, design for players minds, not yours. Because every single time you decide some group

of players isn't worth worrying about or caring about, you pretty much guarantee they don't care about you or your game. A lot of people are going to disagree with me on this one, so I'm going to start off with some quotes to make me sound more authoritative. My personal favorite specialization is for insects. Robert Heinland. I've decided he speaks that way because he was kind of a dick in a lot of the rest of his life. Second one from Valve. An expert who is too narrow has difficulty collaborating. That's from Valve. So there. Yeah. But when they're referring to T-shaped individuals, they're talking about people who have a breadth of experience in their lives and also a very narrow tight laser beam focus of expertise in some small thing. So, in the early days, in the early days, in the 80s, I was making type

faces. I was doing my own art. I coded engines, sound effects, music. I dealt directly with a SID chip. I wrote an assembler, all those fun things. Even during my time at Bullfrog in the '9s, I was coding user interfaces one day and then a shadow renderer for the engine the next day. And that's not because I'm special or magic. It's just because that's what everybody did at the time. That's how companies didn't spend all of their money in two weeks. They got everybody to do everything all the time. And so you ended up with teams that were made up of multi-skilled weirdos. I'm sure this seems very familiar to solo devs in the audience. Incidentally, indie teams are getting bigger and production values are rising. So you might be thinking it's wiser to specialize. But people tend to forget something here. And that is developing a broad skill set isn't just for you. Large teams require collaboration and clear communication beyond anything else. Being a generalist doesn't just

help you get more work done with fewer people. It helps you learn how different disciplines think, their vocabulary, their workflow, their pain. Knowledge breathes respect for others and that helps everybody you work with. It stops you making assumptions about how difficult a task is. It stops you saying just, "Can you just make the main character run 10% faster?" But that'll break the engine. Oh, just do it. Can you just make all the reds a bit brighter in all art? There's 42 gigs worth of textures. Every time you say just, you suggest you know that a task is easy. It might not be. And if you don't know that, you should shut up. Learning more about others areas of work makes you less of an ass to work with. So, there's a good reason. I also personally believe that in ignorance is an energy. So use it. Those of you who put up your hands saying you are coders or artists or whatever else. I know I didn't mention designers. That's I I love you too. Worry not. Don't forget the most of all you are

human. You were designed to adapt. You can do pretty much anything if you put your mind to it. If you're sitting there saying, "I can't do art or maths or coding or whatever else." I said all those things at one point in my career and I was wrong every single time because I'm an idiot. As I said earlier, at various points, I was convinced I would never learn how to do 3D vector mass from scratch. I would never learn about music theory and production or color theory as you saw in Rockman earlier. Not a good start. In each case, I was wrong. So, be a human. Learn a skill outside your area of specialty. This is my challenge to you today. If you're a programmer, learn to make a 3D model and get it in game. It's a pain in the ass. If you're an artist, learn how to code something in Lure. Free engines like Love 2D exist. They're fantastic and very easy to use. So have a go. You're a human. Learn music theory. Learn Islamic design techniques. Learn film making, theater, learn anything and everything. Think of yourself as an artist or coder last. Be a human first because that's

what you are and that's the most valuable thing about you. I'm not dropping a mic. I'm having a drink. Rapid team growth is dangerous. I love this quote primarily because it uses pizza as a metric, which is just fantastic. It indicates that he's trying to at least be, you know, a little bit my people. So, yes, that's Verogles from Amazon. If your team can eat more than two pizzas, it's too large. I've given him that voice. Not it's not quite the same one as I used in their mind. So where does this come from? Um early on in Fable's development at Big Blue Box, there were just three of us, me and those two guys sitting down there. Communication was really, really easy. And we were living off savings and a bank loan. And it was kind of weird and stressful and unstable, but still kind of fun. Team and team morale and

cohesion were pretty darn high. We we didn't really think about those things as an issue. And then we got a deal. The team grew bigger, got a larger office, started to fill it with new people, and everything was okay up until we hit around 12 people. And that's when the rumor mill suddenly developed. We'd have people coming up to us and saying, "I don't know if you know, but half the team is saying this game is going to be canned in two weeks. Is that true?" And we'd go, "No." And where the hell did that come from? And the answer is that's just what happens when you start to grow teams because what happens is you can't have everybody in every meeting at the same time with a large team. It's just not going to work. And so what happens is you end up with pockets and clicks of people going into different meetings and gaps in knowledge develop and people fill it. They either make up their own crap or they misinterpret something they've halfheard they don't think they're supposed to have heard and things start to break down a little bit. And we thought we were unique. We thought this was just us being really really rubbish. But it turns out that this is really really common and there

are really good reasons for it which I'm going to go into. Primarily communication paths do not grow linearly with team size. So as I said with a small team you just have a couple of people sitting around. Can you do thing? Yes, I can do thing. There you go. Team communication 101 sorted. We're experts at this. It's not quite the same as it grows. There's actually an equation for this as well. So, a guy called Fred Brooks who wrote a book called the myth my mythical man month which is quite a mouthful and I think everybody is told to read when they first start KSY or they did when I was growing up a very long time ago. Um decide that this equation here tells you how many communication lines there are for any team of any size as long as you can figure out what n is i.e. You can count the people in York team and what you end up with is doink that two people, one line of communication all the way up to eight people, 28 communications. Every one of those lines represents a potential

up represents a potential for somebody to misinterpret something that's said by somebody else and to get things horribly wrong to, for example, make a cave piece 400 m long rather than 40 m long. People have seen Spinal Tap. Yay. Yeah, Stonehenge. It happens. And uh this is this is why producers exist. That's what they're there for. They're people who don't seem very valuable when you have a company right in the very beginning. You're kind of going, "Well, I'm doing art. I'm making stuff. It goes in the game. And I'm doing coding. It goes in the game. I'm doing design. I'm telling you what to do." No, you're not. Oh, all right then. And then you have producers. And the producers, every producers, God, just gonna come and rearrange the fridge magnets on the front of our fridge again. But they're the people who stop that riotous array of lines becoming a horrific spiderweb that bogs you down and kills your game. That was far more dramatic than I intended to be. It's just bad. But anyway, there's also something called

the Ringleman effect. Larger groups lead to less motivation, coordination, and productivity. I've decided this guy's very posh for no good reason. He shouldn't be posh because he's actually from 1913 and he's a French agricultural engineer. But yeah, he discovered this that basically as his team sizes grew, everything turned to crap. U that's the technical way of referring to it. So why why decreased motivation? Well, in a larger group, it's hard to feel that your work counts. You start to feel like a cog in a machine. And if you kind of go, you know what? I'm feeling knackered. It's Friday. I'm not sure anybody's going to care if I spend one more hour doing this. That's just the way it is. Why decrease coordination? Well, I showed you the spiderweb of lines earlier. In a larger group, the communication pathways have exploded. Again, this is why we need producers. So, what are the suggested solutions? It's okay saying there's this problem. So, what do we do to fix it? Okay, I urge you not to look at Maximleian Ringleman's research on this

because it's kind of horrible. Um, his fixes basically involve you turning your company into a version of the Hunger Games. Um, I'm not quite sure why, but things like increase surveillance. I told you he's posh. Create internal competition. Have them at each other's throats. That doesn't seem good. This is a room full of indie developers. We don't want to do that. So there is one suggestion though out of all that research which does seem to work and we applied it in varying degrees as we went on and it does seem to work and that's simply increase identifiability in a larger team. It's important to assure everybody knows the meaning of each person's contribution. People want to feel useful and needed. They want to know what their role is and why they're useful and that not that they're not just another cog in the machine. In Bullfrog, Big Blue Box and Lion Head, this involved making sure we took time to talk to everyone all the time. Uh we'd also have Friday meetings. people could show off what they were doing. And giving people an opportunity to show off is great, but most of all, think before growing your team.

Think really hard about whether it's the right time, whether you have the right support in place, and most of all, be nice to produces. This one's a weird one. It'll take a while to explain. Let that one sink in. So, excellence has a cost. On Fable, I once asked an animator for a digging animation. Simple request. What I got back was a Pixar quality 12-second animation of a tired farm laborer resting on his shovel, wiping his brow, pushing the spade into the earth, levering up a chunk of turf, and suffering from acute back back pain. It was It was beautiful. It was beautiful. It was It was characterful. It was It was art. It was useless because this is the player's dig animation. The player's going to see that thing a hundred times or more in the game. It wasn't just too long. It was also far too

specific. I had to ask for the animation to be made more bland, duller. Just think how counterintuitive that sounds from you. Just hello. I'm really sorry the can you can you just like make it really it's like I know that all the bank like can you just weird but that's what's necessary if you have really good people they take pride in their craft pride in work leads to excellence and usually quite memorable assets but this level of excellence isn't always a good thing because blandness helps disguise repetition. There usually isn't enough manpower to make every single asset in your game one use. And if you're reusing assets, specificity is really bad because people's brains are designed to spot patterns in both visuals and audio. Players notice NPCs talking about having taken an arrow to the knee for the 500th time. Players notice the same boulder engraved with Eldrich runes strewn

around the same environment a hundred times. They kind of go, "hm, there it is again." Players notice these patterns, these specifics, and consider the game a little bit worse each time they see them. Slightly worse than a game with blunder assets. So, when you're asking for content to be made, communicate the context of your assets. Be really clear about how how often they will be seen or heard, tell content creators how specific it needs to be. And in a lot of cases, you'll find your assets need to be bland, and anything else will actively make your game worse. And you might find that your content creators thank you for not wasting their time. So before we move on to the next subject, this is a quick diagram showing the continuum of game types as defined by me right now that there are no others. That's it. Don't bother reading anything else. Not quite true, but just for the moment, let's pretend. So we get mechanical at one end like Tetris, chess

where just the rules and the configurations of things um are everything all the way up to purely experiential things like proteus where just being in the world is the thing and some people are very denigrating towards those sorts of things but they're a thing they have their worth. They have their place. So that's the precursor to prototypes can be misleading. If your game is experiential, it's actually really difficult to make a prototype. With mechanics driven games, a janky prototype is fine. As long as it lets you test the mechanics and rules, it's useful. With an experiential game, it's all about look and feel. And that means that a janky prototype really isn't helpful in the slightest. Because if simply being in your world is the majority of your game's appeal, you can't really test that until the experience is close to 100% there. Because until that point, it's not the world you want people to be wandering around. You can't test a roller coaster, for example, by sitting somebody on one of these chairs and making whooing

noises at them. It doesn't work. In experiential games, sometimes so-called polish is the game. So that is not the sentence I wrote originally. I actually originally wrote a much much ruddder one which I'm going to paraphrase here. Fable was a lurching joyless horrific experience until the last couple of months. If you weren't there, you do not know it was horrible. Thank you very much to those who didn't go. It was afterwards, too. Um, that's much appreciated. Despite having lots of game mechanics in it, Fable was very much an experiential game. The music, the mood, the the charm we were going for, these things really defined Fable, not the raw mechanics and rules and resources, not the things you can prototype relatively easily. During development, we actually threw away at least one entire combat system. With what I know now, I suspect that 90% of

the reason we threw it away is simply that it wasn't polished. It wasn't finished. We didn't have finished sound effects, weapon trails, hit particles, and it's really hard to evaluate something like combat without all those things. Nevertheless, here are the lessons I learned from that whole fable experience and how it applies to prototyping. There's a weird effect in music production where the louder track is played, the better the listener thinks the sound quality is. Exactly the same track. Just turn the volume to 11. They go, "That's awesome, man. What have you done?" I've turned it to 11. That's it. Quality judgments can be distorted by unrelated factors. Ugly prototypes can lead to weird cognitive distortions that utterly undermine their value. For experiential games, a bland prototype is often better than an ugly one. If you don't have representative graphics, prototype without graphics. Use plain boxes and spheres instead. If you have to keep the prototype completely separate from the rest of the things in the game so you can judge it in isolation. Most importantly, define the prototype success criteria so you reject for the

right reasons. Before you start, make sure you know, are you prototyping something experiential? What is the scope of your prototype? Have you defined success? If success even isn't even achievable at this point, be especially careful and possibly think again about doing a prototype. Worst thing about experiential games, incidentally, is that you might have to rely on faith for considerably longer than is comfortable. But that's okay. That's what experiential games are like. Art style is more important than you think. I'm sure artists here going, "Well, I think art style is quite important actually, so I doubt it's more important than I think." Okay, be be nice. They will also say things like, "An art style is something you discover once you've learned to draw properly. You hack, which is also fair. Just we we talk about this afterwards. That's okay if only if you're going to really make art your specialty. I'm not an artist. I cannot draw. Okay, I state

that now openly, cleanly, plainly. I cannot draw. But I made that for my wife a couple of years ago. I used a 2D vector package. It's a really, really simple image. It's that without colors and gradients. It is just that and no more. You can see how simple it is. Because I'm not an artist, I used a strong style to intro introduce very strong limitations. And limitations made it easier to come up with variations quickly, which allowed me to curate rather than create. And yes, I chose two very similar sounding words, which isn't good. Choosing the right style also does something magical. Style has the fact you can't draw. Uh, this is my current project, Warden Cliff. As I said, I'm not an artist. I really can't draw. I can't model in 3D either, but still. I chose a style that restricted the complexity of my scenes which allowed me to curate rather than create. There's also something else. And

successful games often have a very, very strong visual style. My brother and I did a little test quite regularly called the 1-in test, which isn't as rude as it sounds. Um, it's pretty simple. I'm going to show you a bunch of screenshot sections, no main characters, anything. I want you to shout out what you think the games are quickly. Boink. Awesome. Cross your road. Right on. Monument Valley. Isn't that amazing? You just recognize those games out of thousands you know of with minimal information. The takeaway here should be style is marketing. Ultimately, a unique visual style tells players there might be something unique about your game. And having players believe your game is unique is half the battle. That's my final point. I'm not even going to talk about it. It's an amazing book. Go by. It's not mine. Slide is going. Three, two, one. Bang. Streamline your process. What does your iteration cost? No, really. Um, do

you know how much time you waste on iterations? The little gaps between making a change and evaluating it. That's the bit I'm trying to get you to think about. Uh, if you do think you recognize that, be honest. This was the very first editor I'd used. It's a piece of graph paper which I used during sport at school. Yes, I was that nerd. Uh I was under the impression that it took me 10 minutes to make a level. But in truth, of course, iterating like that, hand coding it and then typing in data tables in basic is idiotic. And so therefore, I never iterated. And I just did not want to write an editor. I was stupid and the game suffered. And while I'm not quite that stupid anymore, even with Warden Cliff now, I find myself walking to the same place time and time again in order to test out a ritual. And part of my brain is resisting writing the tools allowing me to make my job easier. And I was trying to think about why this happens. And I realized that I wasn't convinced it was real work. I couldn't take it off on a spreadsheet and go, "That's it. That's something new in the game. Players will

see because the players weren't seeing it. I didn't see it as real." But it was real. It's a form of self-sabotage. So resist it. Here's some closing thoughts because I'm rapidly running out of time and I didn't speak anywhere near as quickly as I planned to, believe it or not. Don't let technology detail your game's core promise. Uh, we did that on Dungeon Keeper. We had a very, very slow AI update, and Simon and I actually completely wrecked the game by trying to make it so you didn't build very much in Dungeon Keeper because it took a second to update the map. Each time that happens, we oh well, we'll roll the tech. Don't do that. Rethink the tech first. Static screenshots have to look good, too. No one pixel lines. I learned that one from Spellrazer. Single pixel lines shimmer horribly. And spell spellraer looks really great moving, but dear God, it looks dreadful in stills. So, don't do that either. David Lynch. David Lynch said, "People only see donuts, not holes." By which he meant, nobody knows what you cut out. So, when you find yourself cutting things to get a game out on time or to

finish up a speech very quickly, um, don't worry about the things that people don't ever get to see. unless you told them about them for some years. And finally, don't panic if your current game sucks. Fix it. Making games is all about making bad games. Being a successful designer means you need to be comfortable with your game sucking. And of course, discovering the steps to improve it. If your game is bad right now, that's okay. Don't beat yourself up. The chances are that you're only partway through the journey. And that rather hurriedly is it. Thank you very much for your time. [Applause]