Rapid Prototyping Secrets for Better Games, with Bernard François

Jordan: 00:00

Welcome to Playmakers, hosted by Jordan Blackman. On each episode, Jordan dives into conversations with the leaders and legends of the video game industry to bring you actionable insights that can help you make better games, grow your game company, or have a more successful game industry career. This week, Jordan interviews Bernard Francois of Preview Labs, a prototyping expert who has built prototypes for Google, Disney, Amazon, Unity, and many more. If you make games, then this episode is an absolute cannot miss.

Hey, what's up everyone? Welcome back to PlayMakers. I'm excited to share this episode with you. We've got a really valuable and interesting discussion with a guest who has deep experience helping companies build effective prototypes.

Before I introduce him, I wanted to say something about the man who introduced me at the top of the episode. Here's a secret about him: he's not a real person. It was a synthetic voice. Kind of creepy, right? Well, as you may have already guessed, it's about to go full on Inception up in here because my voice, the one you are hearing right now, is actually a synthetic version of the real Jordan. Crazy, huh? So don't believe everything you hear out there.

With that said, why don't I pass the mic to the real Jordan?

Thanks, Fake Jordan. That was pretty good. You did a pretty good job of sounding like me. Not bad, but it's not the real thing, and I'm not ready to be replaced yet. What I am ready to do is to have a really good episode here, and I'm excited to tell you a little bit more about today's episode.

Before I tell you about our guest for this episode, I want to remind you that you can find all our episodes at playmakerspodcast.com. That's also where you can find the links to subscribe on iTunes or Android or CastBox or however you listen to your podcasts. You'll be able to find a way to subscribe there. More importantly, you'll be able to find the backlog of all the episodes and all the interviews. We've been building quite a library of amazing interviews with incredible guests, and you can find all of it at PlayMakersPodcast.com. That's also where you can find the show notes for every episode, including this one, with all the key links that we talk about on the show. I'm going to be putting more and more transcripts up. So you may see transcripts if you go there now, or if you wait a few weeks, you'll start to see the show transcripts trickling into the website. Check it out, let me know what you think. You can hit me up anytime at jordan@brightblack.co—to let me know what you think of the show. I'm just, I'm just spitting rhymes apparently, but you know what? This isn’t about my incredible flow. This is about the interview that we've got today. I’m super excited to tell you about this.

So, the guest that I have for you is someone that I had the opportunity to interact with while working on a, what is in my opinion, a super cool, super innovative project. We were talking to him about doing some prototypes, and the questions that he asked us were so good. He immediately zeroed in on how we could make the prototype clearer and more useful. Then, he brought to the table some incredible ideas on how to add the right parameters to make the prototype really dynamic so that we could explore some of the things we were interested in exploring. And I thought, Wow. This, this guy really knows prototyping. And, you know, I'm a big believer in prototyping. I know how important it is for making great, fun, innovative games in a reasonable amount of time. So I thought, We definitely have to have him on the show, on PlayMakers, so that he can share his knowledge and help more people make better prototypes. I asked him, and he said yes.

Now, this gentleman actually runs a company called Preview Labs, which is 100 percent dedicated to making prototypes for studios. They have made prototypes for companies like Amazon, for Unity, for Disney Imagineering, for Google R&D, and many more. We dive into a lot of very interesting topics in this episode. We talk about how to set up a prototype that will be effective. What kind of art should you have in a prototype? What's the difference between a prototype and an MVP and a vertical slice and gray boxing? What are the common mistakes that people make when prototyping? How do you know when to stop prototyping? When are you done with the process? It's just a very rich, actionable, useful conversation for people who are making games, especially if you're making innovative ones. I really encourage you to listen to this episode. Ladies and gentlemen, I present the interview with Bernard Francois.

Bernard, welcome to PlayMakers.

Bernard 4:54

Thank you very much. Thanks for having me.

Jordan 4:56

Great to have you here. We met because I was talking with you on a project where we were potentially going to do some prototyping together. And you really showed me your expertise on developing prototypes. How did you become the prototype guy?

Bernard 5:11

Yeah, it started 10 years ago when I also started the company. And before that, I worked in the games industry as well as a programmer, and I would say it’s two things that came together. The first one was, as an individual working in the games industry programming, I noticed that I really enjoyed the beginning of the projects much more thoroughly than the rest. Because in the beginning, you have certain technical challenges, you have gameplay challenges, so the game basically still needs to be figured out as you're building it.

And then, more in the middle of the development process, it’s like, okay, now you know what you’re going to put in. You have to put in all these features and make sure all the content works. And at the end, it’s just bug fixing and bug fixing. And I said, okay, the beginning is that’s where I feel that more of my capacity was being utilized, having an interesting game design, as well as being a programmer by trade.

f the Global Game Jam back in: 2009

Jordan 6:19

You want to do game jams full time?

Bernard 6:21

Yeah, exactly. And, of course, I thought, "Can I just be jamming and only work on weekends or something?" No, that's not how it's going to work. So yeah, it needs to somehow, you need to make money. And of course, the first thought might be, "Oh, I'll just come up with some things, I'll just make prototypes or game jam games and try to sell them." But I quickly thought that, yeah, this probably wouldn’t work. It would really be more of a tailor-made or made-to-order kind of service. That’s how I came up with the idea of Preview Labs—to deliver rapid prototyping as a service.

Jordan 6:53

And did you check in with anyone, like, "Hey, I’m thinking about offering prototypes as a service, would you want that?" Or did you just go for it?

Bernard 7:00

al Connect in Hamburg back in: 2010

So, really big with Bejeweled and such, and they were really interested. And then there were people from Gamehouse that said, "Yeah, maybe not for one prototype, but how about 15?" And it was like, wow, this is crazy! And okay, we then, based on that, we ended up deciding, "Okay, let’s officially incorporate the company." Unfortunately, I didn’t know too much about sales, so I was just waiting to get an email from PopCap or from Gamehouse. I wasn’t diligently following up on things at the time because I didn’t know—I never thought about it—that it would be needed. But yeah, this is basically what gave me the additional, I would say, confidence to start the company and take it off the ground.

Jordan 8:15

So when you actually started making these prototypes, did it feel like the game jam, the infinite game jam that you were originally inspired by?

Bernard 8:23

In the beginning, very much so, because it was just me by myself. So, of course, you have to find clients. And then, once you find a project, you can work on it. And that’s what I was doing, and it felt like a game jam because, yeah, I would, of course, be super excited. It’s your first projects, you work really long days, also. And that was really nice, really like a game jam. But of course, after a while, if you start a company, you need to keep the business going, you need to find clients and such.

So yeah, it became a focus as well to make sure we can find the right clients. And, of course, if you start a company, at some point, yeah, you have to do a lot of other things as well. So I would say that maybe distracted a little bit from the pure game jam feelings, but for our programmers, it’s definitely the case. There’s, of course, an important difference—you can define the scope more in advance if it’s for a prototype, while for a game jam game, it can be totally flexible. You can totally change it. It doesn’t matter, as long as you end up with something really cool to show.

Jordan 9:24

More improvisational.

Bernard 9:25

Yes, exactly.

Jordan 9:27

So as you start to get your first clients and you’re doing these prototypes, whether it’s with your first client or your second or your third, presumably you got better at prototyping because you learned how to do it more effectively for your clients and more effectively for yourselves. What are some of those lessons you learned along the way?

Bernard 9:44

Yeah. One of the things we learned as we were prototyping for our first clients, I would say, is first of all, understanding the vision of the concept that you're going for is really important. Like, how do you envision the game as people would play it? So like, why would people even want to play it? What are some of the unique selling points? Those questions are really crucial to ask yourself before you start prototyping. So, even though prototyping is a faster way of developing something, because yeah, you're not taking the burden of the entire scope of a game, it doesn’t need to be a full-blown game experience.

Still, it is important to take some time and think about how you envision the game. What is important? Why are people going to play it? And, of course, if you're doing that with another party or even internally—let’s say you're working in a larger game development studio and somebody has an idea—it’s important to really take the time to understand the other person's vision. That’s really crucial because from there, it’s all about reducing the scope to a more limited set of features. And how exactly to do that reduction in scope—you can only really do it the right way if you understand what the intention of the game is or what the ultimate goal is. And of course, in many cases, you can also just reduce it to the core mechanics.

Jordan: 10:59

So to make sure I understand that, it’s like a lot of people might have an idea that is more about a mood or, "Oh, it’s like Baldur’s Gate, but with vampires," or, "We want to do this new kind of thing that’s never been done." But when you’re asking them, "Okay, but what do players see on the screen and what interactions do they have?" they have to go back and clarify those questions.

Bernard: 11:21

Yes, and also, let's say the example—let's say it's like Baldur's Gate, but with vampires. Then are you going to take all of the elements of Baldur's Gate and all of the elements of vampire lore? Maybe not. Maybe there's something specific there. Maybe if you take too many features and you just jam them all together, maybe it's going to be more like a Frankenstein kind of combination of different things. It's not because you have multiple things that are cool that the sum of the two together is cool. So, you need to think about it and see, "Okay, what are the features that you really want to explore?"

And one of the key lessons is also try it simple first. Sometimes you can find something really simple that actually works really well. And if you make it too complicated or too convoluted, it's just more complicated to fix, or it doesn't necessarily work. If you can get away with something simple, it's, in many cases, a really good solution. And there's no harm in trying something simple first—you can only save time.

Jordan: 12:21

When we were talking about doing a project together, I sensed some of this. Now, looking back on that conversation, I see how you were asking questions to both answer those questions about what's going to be on the screen, what are the interactions, and also looking for ways to boil it down to the fewest component parts.

Bernard: 12:38

Yeah, especially if you're using a prototype, for example, for a pitch. Like, if somebody has five minutes to look at it, all you can do is maybe convey one, two, or maybe three things that you want that person to remember. And that's really important. And then if you think of it that way—even if you're not doing an investor pitch—but let's say you can show it to somebody for five minutes, what do they need to remember about your game? That's a good question to ask yourself when you're defining the features for a prototype.

Jordan: 13:05

That's really interesting, the difference between a prototype that's for proving something to the team and a prototype that's for a pitch or for getting funding or internal funding. Does your team do both of those kinds of prototypes?

Bernard: 13:21

Yes, correct.

Jordan: 13:23

And how do you approach them differently? Like, how do you see that distinction play out?

Bernard: 13:27

I would say the one for the internal team—let’s say, not pitching, but among game designers or game developers—is a subset of what you would do for a pitch. Because if you're pitching internally, you would say, okay, maybe you want to verify the gameplay. If you're pitching, you probably also want to verify the gameplay, but, of course, because it’s a pitch, you want to present the gameplay. But if you present the gameplay without verifying it first, you might present something and say, "Here’s a game that doesn’t work." So that's not a good idea for a pitch. If you're pitching, you want to improve it already.

And if you're doing it internally, you also—first of all, of course—you want to figure out if it's worth pitching. So that's another question, of course, but it’s the same question as, "Is it worth playing?" or "Is it worth the development?" And I guess if the first answer is yes, then you can move on and say, "Okay, let's now think about what do we need for a successful pitch?"

And then questions I typically ask—or you could ask yourself—are, "Who is going to review this?" "Who are you pitching to?" "What is their experience?" Maybe, "What are they going to compare it with?" And of course, it depends on the whole process of pitching. It can happen that, for internal pitching at larger game developers, they will compare different concepts that they built internally in order to see which one is better. As long as all the prototypes are more or less at a similar level, it becomes relatively easy to compare them.

Of course, if you're only showing one prototype and it's not very finished, and somebody who has no idea about prototyping specifically needs to compare it to what they know about games that look really fancy and beautiful—and then you come there with your little prototype—you have to make sure to frame that a bit. One thing, when we’re talking about maybe polishing a prototype or making it look prettier, is you have to be really careful. Because if you actually polish it and make it look pretty, then people are going to easily think, "Oh, this is the final quality of the artwork that you're going to deliver."

So you have to be really careful that you're not just, "Oh, let's do a half-assed kind of job, make it look a bit pretty." If you do that, it’s very dangerous—some people might actually take that for the actual final quality of graphics. In many cases, what we like to recommend is just keep the graphics super simple—don’t make it ugly, just stylized, simple—and then have a pitch deck or something to show the quality of the artwork that you're able to produce in order to make that combination. So you don’t have to take it all the way to a vertical slice.

Jordan: 16:00

Yeah, that makes sense. Have you heard of the uncanny valley? They make these characters that are a little bit too close to being real, and then it creeps people out. It's almost like there's an uncanny valley for these prototypes where if they go too far, they start to get evaluated versus a real product, and you don't want to be there.

Bernard: 16:17

Exactly. The expectations just become too high, and then, yeah, you take it one step in that direction, and then people want to go all the way. And that’s, indeed, exactly—it’s very similar to the Uncanny Valley.

Jordan: 16:28

What are some of the mistakes that you see developers making, either when they come to you or after they've tried to do some prototyping on their own, that we can help people avoid in their prototype development?

Bernard: 16:39

Yeah, one very common one—I guess you could call it feature creep—but for a prototype, people get too excited about it. You get carried away because you’re developing something new, and it's really cool. You think, "Oh, this is amazing," or maybe you see certain things that can be improved. And because the process itself is fun, you just want to keep improving it and adding more and more things. The danger there is that you're not necessarily open to other alternative ideas.

One situation that actually happened with an early client of ours is that we did a brainstorm and came up with four different concepts. We ended up prototyping three of them, but the first one we got really excited about—both ourselves and the client. They said, "Oh, this is really cool, let’s see how we can build upon this." We tried some different variations, and then we said, "Okay, let’s now move on to the next idea from the brainstorm." And then we noticed that, okay, this next idea is actually way better than the first.

We kind of wasted our time. We did three iterations on that first concept, and then the second concept, we did one iteration, and it was actually more fun than after three iterations of the other concept. Sometimes I compare it to photography: if you take pictures, you can always improve them in Photoshop or with filters or whatnot. But in many cases, if you have a picture that's already great from the beginning, then you can only make it even better. But if you have a picture and you need to start fixing it—maybe removing some undesired elements—it’s just going to be a whole lot of work, and maybe the result isn't even going to be so good. I would very much say it's the same with prototyping. Don’t get carried away too soon; make sure you have some different ideas that you can consider so you can compare.

Jordan: 18:21

I think that is such a great tip—to make sure that you go through everything quickly to find what's hot before you start iterating on any one specific thing. 'Cause you don't even know where the heat is yet.

Bernard: 18:32

Yes, don't settle down too quickly.

Jordan: 18:34

Super smart.

Bernard: 18:35

And there is one very simple way to mitigate feature creep: write down your scope. It doesn't need to be a huge document or anything, but at least make a list of the features that you're going to include in the prototype. And then just stick to that. Don't take it any further. And if you have ideas—and you probably will be inspired and have a lot of ideas and extra features, or maybe a feature that you could remove and replace with something else—just write it down and keep it for later. Table it and go to the next concept.

It's pretty much like the scientific method. It's a scientific experiment, so to speak. You define your experiment, carry it out, and then you decide what you're going to do next. So there's a clear decision moment, and that's because it's an iterative process. So you do one iteration, try to define what you're going to do in that iteration, and once you finish it, you can stop and think about what you're going to do next. Maybe that means doing a first iteration on a totally different concept.

Jordan: 19:33

I like that. And I like that metaphor of it being like the scientific method. Something that I've had some success with in prototyping is putting forth questions to be answered, like we want to know something specific, and everything we're doing in this prototype is to answer this question. So once we've answered that question, then we need a new question. Otherwise, that prototype is done.

Bernard: 19:53

I agree. This is a great idea. This is about how to get from the total vision of the project—how you envision the game being in the market, how it will be played—to the set of features for the prototype. And indeed, those questions can be really useful when guiding yourself in terms of figuring out which features to put in. Also, if you're considering, "Oh, should we add this to the prototype?" then you just go back to your question and say, "Is this going to help me answer the question or not?" And if it's not, then you don't have to do it.

Jordan: 20:21

Nice. Okay. Any other common pitfalls or mistakes that you want to cover?

Bernard: 20:26

Let me just see... There's a topic about vertical slices versus prototypes. I would say a common pitfall is that people think a vertical slice is exactly like a prototype—that you can quickly make a vertical slice just like you can quickly make a prototype.

I would say the answer there is no, you cannot quickly make a vertical slice. A vertical slice is basically a kind of prototype, but it's more like a demo. You can play the game and see all its aspects with the final graphics, but only for a few minutes—maybe 10 minutes, or one level of a really big game.

Jordan: 21:04

For those of you who don't know, if you were to take something like a gumball and make a vertical slice, you could open it up and see all the layers inside. So that's the idea of a vertical slice of the game. It should have all the different layers of that game. It's not the same as a prototype.

Bernard: 21:19

Yes, exactly. And it requires a lot of development because you basically need all the systems in place, or at least all the systems that are going to be visible during that amount of gameplay. The content might be limited, but you still have to have everything set up to be able to produce that content.

Jordan: 21:37

It's one of those words that people probably use without really thinking through what they mean by it. One of my pet peeves is the term "MVP," for very similar reasons to why "vertical slice" is problematic. MVP is also a very challenging word for people to use.

Bernard: 21:54

Yeah, with an MVP, really, it's literally a "minimum viable product." That's a hypothesis in terms of, "This is the minimum version of my product that could be commercially viable." And that means it is already a product. It is a possible approach where you build a product and make it really simple. And for certain software-as-a-service concepts, it's really useful because you have to figure out what people want. Or maybe for online games, it's a possibility, but it's not the same as a prototype. It's a different idea. You would prototype before making a vertical slice. You would prototype before a minimum viable product.

And maybe another term, now that we're doing this round of putting things in boxes, speaking about boxes, is "gray boxing." So that's also something people talk about, or a "gray box prototype." That’s a term I sometimes hear, and it basically refers to the art style. Gray boxing itself is a way of using gray boxes to put together a level or something. And so people sometimes think, "Okay, everything has to be gray," but that's not necessarily the case.

I would definitely say: use some color in your prototypes. One of the key aspects when prototyping is to make sure that the players of the prototype, even if it's just yourself, understand what's going on in the game or under the hood. Anything that's happening, you want to communicate that. Sometimes, you can do very simple things, like just changing the color of something. For example, we did a prototype for mobile where we had a simple environment with some palm trees quickly put together in Unity. The characters were all kind of domino pieces, but they had different images on them so you could tell them apart.

And then we just used, for example, the vertex colors, changing the color of those domino pieces to show what they were doing. Instead of having a whole animation of starting a certain attack, like casting a spell, we would just interpolate the color of that domino piece from the team color, for example, blue, to white. At the end, it's 100 percent white, and then it flashes back to blue. That’s the moment the attack is fired. That way, people could know how long they’re preparing for the attack, and they could do a counterattack in that time. So those are very simple things. In an actual game, you'd need a whole bunch of artwork—someone picking up their heavy battle hammer and starting to swing. But all we do is just change the color.

Jordan: 24:29

The point is, even though it's not a gray box, it's now a red or a white box, you're still gray boxing because you're taking the simplest way of conveying the mechanic, just using rudimentary forms. In this case, it’s a color.

Bernard: 24:40

But sometimes the term "gray boxing" can really make people think that it needs to look gray and dull. What I'm trying to say is that, indeed, you have to look for the best way of representing whatever it is. Like we had images on those domino pieces, even though they were boxes. We had different images that showed, okay, this is a priest kind of character with a cross, and this is a ranger with a leaf, so a natural element in it.

Jordan: 25:03

You also said something in there—sorry, I don't mean to interrupt—but you said something that I thought was really relevant to our previous conversation about the difference between prototyping just for internal purposes and a pitch. When you talked about those palm trees, I think when you have a prototype that you want to show to someone external, one of the things you want to communicate is that your team can create charm, or can create a feel, or is tuned into the vibe. It's not so much about, "Oh, this is the final artwork," but it's that we care about this, and we're able to communicate visually or mechanically. Adding some of those little things to a prototype can be really good. It’s not that it's a final-looking palm tree; it just communicates that you guys are going to do something cool. You know what I mean?

Bernard: 25:48

Yeah, it’s just, it’s pretty murky territory in terms of—you have to be very careful that people don’t take your palm tree for, "This is going to be what palm trees look like in the final game," or, "This is the limited level of the graphical quality." But yeah, I do think it's maybe even more about making sure that everything fits together. If you're doing a pitch, you're selling something. The story needs to make sense. You don’t want to show gameplay that totally does not fit the theme, for example. So, if you can, yeah, it definitely cannot hurt to have some connection between the two, even though the graphics could be more stylized.

So, that’s when I get back to gray boxing. The reason why I don’t like the term is that it sounds dull, as I mentioned. But basically, the way I feel graphics for a prototype should be—ideally, they are just stylized and simple, but still pleasing. It’s not eye candy. It’s not, "Hey, I’m going to throw sand in your eyes, and you’re going to think this game is amazing because it looks super pretty." But the opposite is true as well—you can’t have it where someone feels really bad about it, like, "Oh, I have to puke after playing this game because it looks so ugly." You need to find some middle ground.

So, the term I like to use is "functional graphics," basically. Stylized and functional as opposed to gray boxing. It’s really more about the function. I don’t care if it’s gray or green, or if it’s maybe a 3D model that you downloaded somewhere, or maybe it’s something you made, or maybe it's based on a drawing or a Google image search.

Jordan: 27:27

You don’t have to be ugly to be simple and quick. I’m thinking of like the notebooks of Leonardo da Vinci. He wasn’t intending for anyone to even see that stuff, and we consider it art because of how beautiful he made those simple things.

Bernard: 27:39

Yeah.

Jordan: 27:40

Okay. And anything else you want to cover there, Bernard?

Bernard: 27:43

Yeah, maybe one thing I would say is if you want to do something that is still pleasing and functional, just be consistent. I think consistency is really key. So if you're consistently simple in your graphics, it’s probably going to be fine. You don’t want to have some things that are really one type of style and a different style elsewhere. Just make it a bit consistent. Even if you have a simple UI with some text, make sure that text on the screen is aligned nicely. Even though it’s a simple font or whatever, just make it a little bit consistent. Especially for pitches, that's going to go a long way with the minimum amount of effort.

Jordan: 28:24

Yep, totally. It’s like dressing well for a pitch, right? It’s important how you dress or how you've done your fonts or these little things. It shouldn’t—it's just part of producing great work. So, how do you know when it’s time to stop prototyping? Like, not just a single prototype, we sort of addressed that—you do a question-and-answer format—but when is it time to put prototyping aside and move forward into other parts of pre-production?

Bernard: 28:52

Yes, this is a very good question. And first of all, the question already implies that you understand that there is a moment that you have to stop. Sometimes that’s not always—

Jordan: 29:04

You’re doing an infinite game jam, but the rest of us—

Bernard: 29:06

Yeah, yeah, no, but yeah, of course if you ask me, when are you going to stop prototyping? Never. Yeah, of course I got the question, and within the development of one project, you probably want to ship a game sometime if you're a game developer. But it does imply that you need to stop, and some people believe that you can prototype and keep prototyping and keep iterating until you have a product.

Yes, it's possible, but it's painful. It's a painful process because if you're prototyping, you want to be able to throw out some code, add something else, change it. So it's not like you're developing something by design, where you know, "Oh yeah, this is what we need. We're going to do really proper software architecture and see how we're going to lay out our classes and everything in order to have a solid and easy-to-maintain and debug code base." And this is everything but the case when you're prototyping. So indeed, you definitely have to stop at some point. You don't want it to drag on too long.

Jordan: 29:53

Yeah.

Bernard: 29:53

So that's also one of the things—like prototyping, you think, "Okay, I can do everything quick and dirty." Yes, to some extent, if you're doing first iterations, do it as dirty as you like so you can compare and then throw away whatever you don't need and go for the concept that you see potential in. But yes, some throwing out of code and rewriting can be useful even during prototyping. But yes, at some point, you have to stop.

And I would say it depends on your comfort level a bit. Some people are very risk-averse, some people are okay to take a bit of risk. It also depends on the budget—sometimes you cannot be as thorough as you may want to be; you also have to deliver a game at some point. But I would say when we're just talking specifically about the aspect of risk aversion, you basically prototype until you feel that you've sufficiently covered all the creative risks in terms of maybe the gameplay not working. Like, basically when you're prototyping, you can figure it out while iterating.

Sometimes you think of a feature that's almost 100 percent certain it will be an improvement to the concept. And maybe some people might feel, "Oh yes, I want to try this out," but you don't have to, because if you're sure that it's going to improve the concept and you don't need to try anything else, then you don't have to implement it. Just write it down. And at some point, you're going to run out of things to prototype. You don't need to keep going. You can. And you have to feel, "Okay, now I have a concept where I feel confident that this is going to feel good. I've seen the core working. It feels really great. I now have a lot of ideas on things that I can do to make it even better." Now, you can start production.

Jordan: 31:51

Got it. Yeah, that makes sense. One thing I'm curious about is that, on one hand, we want these prototypes. We don't want to make them perfect. We're not going to focus on making all the classes right. On the other hand, there's a certain amount of flexibility in these prototypes that can be really useful, right? Setting up some variables to play with to get the most out of these creative questions. So how do you approach that? Okay, we want to do it rough and ready, but we also want to make sure that it has the flexibility to serve as a good prototype and make sure we discover the most we can with that prototype.

Bernard: 32:24

Yeah, so these are things you can do with a prototype that you wouldn't do if it wasn't a prototype. For example, if you're thinking about multiple ways of doing a certain mechanic, let's say there are different ways of jumping. You can implement them all and then just make it a variable so you can switch between them and try them out.

What we do is we have a kind of tuning system that we use for all of our prototypes for our clients. It’s a menu, and they can tune it while the game is running. They can see, "I'm going to turn off this feature, I'm going to turn on that feature, I'm going to choose this or that variation."

Jordan: 33:03

And that's in Unity, or is that across multiple engines?

Bernard: 33:06

At first, it’s in Unity, but it has a web backend, so we've used it for an Unreal prototype as well. Even if you build it in one engine, you could just run it in that engine. And in our case, it synchronizes with a server, and even an Unreal prototype can use those tuning features.

Jordan: 33:21

And are there any variables that you find are the most important for developers who might be doing this on their own?

Bernard: 33:26

Yeah, I would say once you have the system to expose these variables and to play around with them quickly, everybody can do it, especially if you're a developer on your own. You can just do it in Unity. You can expose a lot of variables and just play around with them and maybe keep it in one place so you know where everything is, so you can do it more consciously. But yeah, I would say any variable that has an impact on the gameplay or is like an important impact.

And one thing that came to mind as you were asking the question, in quite a few prototypes, we had cases where people are going to have a certain type of level design in their game maps, but there could be different ways of playing the game. Maybe there’s a slow way with more obstacles or puzzles, or there’s a very fast-paced way, where you can imagine that the level design would be radically different.

Maybe objects are spread out much further on the screen, and the character speed is tuned to be much higher, versus when objects are closer on the screen, and the character is slower. Maybe you want to try these things out. If you were making your levels by hand, it would be hard, because if you tune the character speed a bit faster, the level might not work anymore.

So one of the things we like to do in early prototypes, like in the first or second iteration, is to have some simple random generation of levels based on parameters. Then we can also play with the parameters of the character, avatar, or the player. We can play with the parameters of maybe enemies in the game, or whatever it is. This works for puzzle games, anything where you have a certain amount of levels and this kind of game feel that can be different.

Jordan: 35:11

So I just want to make sure I understand. What you're saying is, what a lot of people might intuitively do is they set some parameters around the character and the movement, let’s say, but they’re going to make the level by hand. And that’s going to create a problem because as they adjust the character parameters, the level is no longer going to make sense.

So what you do and what you’ve learned to do is to have the level be generated by parameters as well, so that you can adjust them as you adjust the character and keep the whole thing making sense together.

Bernard: 35:39

Yes, exactly. And everybody knows that in most games, randomly generated levels aren’t going to be as good. And we accept that. It’s really more about figuring out what this game is going to be like. Is it going to be faster? Is it going to be slower? Is it going to be a certain way or the opposite? It depends on the parameters by which you can generate your level, which depends on what the game is about.

Jordan: 36:09

That’s great. That’s such a great tip. Is there anything else that you want to make sure we cover that you feel like people should know about how to prototype effectively that we haven’t gotten into yet?

Bernard: 36:18

Yes, one thing. A common mistake or pitfall I hear about is people wanting to develop a prototype, and they will approach us and say, “Hey, we already have all the art. Here’s the art. Now, do the programming.” That’s really a bit of a missed opportunity. Maybe they had artists who were on the bench or something, and they had to do something with their time.

But normally, you don’t want to be creating all of your artwork before you do any programming, because you don’t know what it’s going to look like on the screen, for example. Maybe the camera’s perspective could be different—the optimal one could be different than what you imagined. Maybe you have art for a certain feature that isn’t going to work. Then, if the feature doesn’t work, you don’t need the art anymore. So it is much easier to keep it really simple. Don’t spend time creating custom art in the beginning. Just try out the gameplay, and then you can come up with the art as you go, if it’s even needed for the prototype.

Jordan: 37:14

What was that term you had? Functional design? Is that what you called it?

Bernard: 37:17

I would say, yeah, functional art.

Jordan: 37:19

Functional art. So if they’re doing the art in advance, they’re basically—Functional graphics. It’s the opposite of functional graphics. It’s graphics without any function.

Bernard: 37:27

Yeah, exactly. You can do so much work, and then it turns out it wasn’t necessary. And that’s the whole thing that can happen if you don’t prototype at all. You just start developing a game. That means you do a lot of artwork, also a lot of programming and thought that goes into what is the best way of structuring your code.

And then by the time all the moving pieces come together and you can actually try it out, you notice that this game actually sucks. That’s the problem. Then you’ve lost so much time, and indeed, keep everything as simple as possible. It’s really about limiting the scope of the entire vision, your entire idea to something very essential. And that usually means limiting all the artwork to functional art, if you will.

Jordan: 38:08

I love that. And it’s obviously hard for designers to do that. And that’s why it’s useful because you’re having to do the challenging work of paring your ideas down to something quickly achievable. That’s great. So, to close out, I’d love to know if you were going to start your own podcast, and it wasn’t going to have anything to do with video games, what would it be about?

Bernard: 38:30

Oh, that’s really interesting. One of the things that I think is pretty interesting, even though I don’t spend much time reading about it or anything, is the notion of social entrepreneurship, where people are trying to solve problems that are not necessarily driven by the desire to generate a lot of profit. I think that’s pretty interesting.

For example, how can we use capitalism in order to fight climate change? Basically, things like that. Those are, I think, pretty interesting. It could be interesting—I think I would learn a lot if I talked to, like you do, with people, but then specifically about people tackling these hard problems.

Jordan: 39:08

I can see the appeal because these are things that they’re almost forces that feel like they’re going against each other. So there’s all this interesting kind of friction to learn about and see how it can be reworked to work together.

Bernard: 39:24

Yeah, it’s like hacking in terms of, I’m going to take these components and create something new out of it, something unexpected. It feels like it could be very creative, and it is. And this is the thing where people are doing social entrepreneurship—there’s a whole fair trade and organic agriculture movement, things like this, that have really grown in the last decades. And even though the ways of doing, for example, organic agriculture, it’s not about “let’s do something as cheap as possible and sell it for as high as possible.” Although, maybe you could argue that could be the case in some situations. But yeah, that’s what I think is interesting: how can we use the system that we already have, that we live in, in order to achieve change?

Jordan: 40:12

And I think it also really says a lot about you because I think it’s almost another, it’s almost another way of doing a game jam. You’re jamming with some different elements there, but it’s still that infinite game jam that Bernard loves.

Bernard: 40:23

Yeah, that makes sense.

Jordan: 40:24

Thanks for coming on. This has been great.

Bernard: 40:26

Yeah, it was awesome. Thank you so much for inviting me. I really appreciate it. We had a lot of fun, as I mentioned in the beginning, and sometimes, yeah, this was a really good in-depth interview, specifically with game industry insiders among each other. So I love it.

Jordan: 40:41

All right, let’s do it again. What’s up, my fellow playmakers? You have made it to the secret, super special, end of the episode club. Congratulations. Now, you know, this club we have, it’s open to anyone, but we do encourage you to subscribe to the show. It’s not required, but it is highly encouraged, as it will help you attend club meetings, which happen at the end of episodes of the show. And what I want to do is I want to bring you guys a little something extra whenever I can. I want to give you something cool, something useful, something fun, and something that’s just for us, kind of at the end of the show, where, let’s face it, you know, not everybody makes it to the end of the show, and that’s okay.

But for those of you who do, you know, you, you get special, you get special attention. You also get cars driving around outside, but that’s okay, you know, because we’re, we’re friends and friends let each other have some issues with the audio occasionally. So what I wanted to bring you for this meeting of the club is an extra thought that Bernard gave me after we formally ended the interview.

So I’m going to go ahead and play a clip where Bernard, first of all, thanks me and tells me how awesome it was, which, you know, I like to hear. And then he also shares some extra knowledge about the technical side of prototyping that I think you’ll enjoy. So let’s, let me play that for you right now.

Bernard: 42:21

Thank you so much, Jordan. I really had a lot of fun. As I said, it’s really cool to have somebody ask the in-depth questions about why prototyping and really, yeah, it doesn’t happen so much that I get interviewed by somebody that is actually also really into games and all those decisions that go into making a game.

Jordan: 42:40

It was fun to do it and it’s fun to learn from you and I really think, I really hope and think the audience will get something out of this. I appreciate it. I appreciate you coming on and helping the audience make better games. That’s what it’s all about.

Bernard: 42:52

Yeah. That sounds really good. I think there’s only one more thing that I didn’t really cover that while I was scrubbing on a piece of paper, you can decide what you add and to get to the right length. One part that we didn’t talk about yet was when it comes to deciding which features to put in, we talked about the questions that you have in terms of, yeah, what is the player going to want to play or gameplay-related questions that can guide you, but there can also be technical questions.

Jordan: 43:19

Like that multi-threaded thing.

Bernard: 43:20

Yeah, or there can be like, maybe, maybe there’s a certain thing that you’re not even sure if it’s going to be possible. So it’s not always about the gameplay. Sometimes it’s about, can we do this really cool technical thing? And then you can have a totally different type of prototype, where you just focus on something highly technical.

Like we did, for example, a prototype where we wanted to create a rowing experience as part of—laundrying? Rowing. Roaming? Rowing, like you’re rowing. Rowing, okay. And you have an oar and you’re, and the idea was to, yeah, to make it, to see how we could make it feel. So we did a first iteration where we kept it really simple, like we said, okay, let’s detect if you’re using your oar to paddle a little bit to the left.

Then we’re gonna go forward a bit to the right. If you paddled on the right of your boat, we’re gonna go forward and to the left. But that didn’t really feel quite good for several reasons and then we just ended up simulating a bit more. So it became a bit more of a physics simulation. So I would say a much more highly technical simulation prototype, but it sounds really good. So sometimes it’s really just about a certain technical aspect. Like how are we going to make rowing physics feel good in VR, for example? And of course, that’s also one of these questions in terms of, yeah. So you can have these technical questions that can inform your decisions, and then you can go really deep into a technical aspect to just figure it out, without focusing on the rest of the game.

Jordan: 44:44

To me, what you just described sounded like a design question fundamentally that then there was a strong technical component to discovering the solution.

Bernard: 44:55

Yes, that's true. And of course, I would say anytime you're doing something technically hard or something technically challenging, there also must be a reason, I think, why you're doing it. And sometimes, but sometimes that's the reason by itself. If you say, okay, if you have this technology, it's never seen before, it would be so cool. And then you have to try to figure it out. Like, how is that going to be possible? Yeah. And then, and that's the impression. Then, how are we going to deliver this really cool experience, technical miracle?

Jordan: 45:24

Good. That's a, yeah, that's a good add. I will, so on every episode I have, I often have a secret section at the end for like people who make it to the end of the show, this will be, this'll be the one for this.

Bernard: 45:37

Awesome. So, shout out to everybody still listening.

Jordan: 45:42

Yeah. These are the hardcore folks. Yes. You rule. Awesome. All right. Cool. Anything else?

Bernard: 45:47

No, that's it. This is great. Let's stay in touch. And obviously there, I'm sure we'll find a way to collaborate at some point.

Jordan: 45:54

That would be awesome.

Bernard: 45:55

Cool, man.

Jordan: 45:56

Okay. Thank you so much. Catch you later.

Bernard: 45:59

Thank you so much.

Jordan: 45:59

All right, my friends, that is it for this episode of Playmakers. Thanks for listening. Thanks for being a part of the community. Thanks for your reviews. Thanks for your subscriptions. Thanks for your support. It means, it means a lot. And if there's anything I can do for you, you can reach out at jordan@brightblack.co. Until the next episode, keep playmaking or something like that.