Thank you RailsClips Kickstarter Backers!

 

02:27 - Andrea Magnorsky Introduction

02:56 - “What Game Developers Know That Business Devs Can Benefit From”

08:28 - Curiosity and Motivation

09:10 - Is game development more approachable than in the past?

10:12 - Learning New Skills and Coding Practices to Write Games

15:45 - Performance and Iterations

20:45 - Making Games Inviting

23:11 - Techniques to Cope with State

24:16 - Releasing and Deadlines (Business Issues Between Developers and Management)

28:30 - Testing 

30:45 - Writing Aspects of Games (Stories, Artwork, etc.)

32:22 - Why F#?

38:44 - Pair Programming or Agile Techniques in Game Dev?

42:22 - Teaching Game Development (Game Jams)

44:39 - Onikira: Demon Killer 

Picks

[Vimeo] Carina C. Zona: Schemas for the Real World (Avdi)
Maryville, Tennessee (Avdi)
Monodraw (Jessica)
Elizabeth Naramore: Uncomfortable (Jessica)
ambient_spec (Coraline)
Cosmic Encounter (Coraline)
Ready Player One by Ernest Cline (Chuck)
Mastery by Robert Greene (Chuck)
Dixit (Andrea)
Michael Bernstein: Know Your Types (Andrea)
[Vimeo] Philip Potter: Generative testing with clojure.test.check (Andrea)

Special Guest: Andrea Magnorsky.

 

Oh wow!

[Chuckles] It is.

That is a horrifying unicorn-cat.

Hey everybody and welcome to episode 201 of the Ruby Rogues podcast. This week on our panel, we have Jessica Kerr.

Good morning.

Coraline Ada Ehmke.

Hi there.

Avdi Grimm.

Hello from Tennessee.

Yay!

I’m Charles Max Wood from DevChat.tv. Big thanks to everybody who backed my Kickstarter campaign. It funded. So, we should be getting Ruby on Rails video done here soon. We also have a special guest this week, and that is Andrea Magnorsky.

Yay, hello. Hi.

Did I destroy your name?

No, no, you said it right.

Awesome. Do you want to introduce yourself really quickly?

Sure. I’m Andrea, and I’m the cofounder for BatCat Games, a games company out of the Republic of Ireland. And I’m also a developer. I’ve been in enterprise and [not in] enterprise for a long time.

Awesome.

So Andrea…

I was just going to say, somebody named this show ‘What Game Developers Know that Business Devs Could Benefit From’.

Yeah. It wasn’t me.

No, that was me because I’m kind of fascinated by all the things like event-driven programming that games have been doing for a long time. They’ve had to worry about performance, about minimizing network bandwidth, and about really fast iterative development for longer than we have. It’s like games have problems that we’ve been able to ignore on the business side but now the business software is reaching a point where we need to stop ignoring those problems, too.

Yeah, that makes sense.

Oh, come on. I’m agile.

I think there’s a lot of innovation that’s been happening in games for a long time and that not a lot of it is very public because, well there is a certain level of secrecy in game development historically. And now, there’s a lot more indies that we’re all allowed to, well, we can do whatever we want, really. So, I guess there’s way more openness. So, there are some historical reasons why that might be not well known. I think the main thing that I kind of, I don’t know, noticeably noticed, [god], is that…

[Chuckles] Yeah, I know. It’s like, words jumbled in my brain. I don't know. The main thing for me coming from enterprise into professional game dev has been the fast iteration. And it’s crushingly fast, that you have to do. The networking, not so much because we’re working on PC single-player games. So, we don’t really do any networking events. There are different architectures I guess. Nothing like what I’ve seen in enterprise. So, I guess this is just different. I don’t know if there’s anything. I’m sure there’s something to learn. But I don’t know if there are clear, concise lessons. It’s more like I think everyone should do a few games just to think in a bit more real-time kind of way. Yeah, that’s my spiel anyway.

I’m curious, Andrea, how you got started doing games, especially coming out of the enterprise.

Boredom? [Chuckles]

Brutal honesty…

[Laughs] I’m sorry.

[Laughs] No, I…

That’s awesome.

[Laughs] It was really a combination of personal life change and just the right thing at the right time. I started playing with making little games a year before we started the company, about a year, maybe a year and a half before we started the company. And it felt really different. It was like, okay for the first time in a long time I have no idea what’s going on here. And everything I do is counterintuitive. So, I really, really enjoyed that part of it. So, when it was time to move away from where I was working, then the options were some job doing similar things to what I’d done before, some other job where I got more money where I was doing things that I’d done before, and some other job that was just boring. And then it’s like, “Hey, start your own company and make games,” which is completely crazy. And I went obviously for the completely crazy one. That made sense.

Where did that idea come from?

Well, my partner, the other founder of BatCat, Andrew and myself, we’ve kind of been talking about it, “Maybe we should do…” You know, when you start with someone and you’re there and you’re like, “Hey, wouldn’t it be great if we had [inaudible] company?” “Yeah, yeah, sure, keep dreaming,” kind of thing, maybe in the very distant future. But then at some point it turned from a crazy idea to something that could actually happen. I don’t really, it was very natural. I don’t remember really exactly the steps.

Did you start with an inspiration? Did you know what game you wanted to make when you started?

Actually, it was more like we were working on a hobby game. Actually Andrew was doing most of it and I got more curious and curious about what he was doing. And he was working on this game. And it was, “Oh, I’m just adding particles.” And I was like, “Oh, what’s this particles things?” “Oh, well you know, with shaders.” “Oh, what’s this shaders thing?” So, anything he mentioned sounded just really interesting and very real-time and cool. So, you learn things all the time. And he kept working on it. And then basically, I joined in. And we released the game on XBLIG, which is what used to be the Xbox Live Indie something. And we released it there and it actually did pretty well from a… it was a good game, ish. And we got good reviews from people. It got exciting, basically. So, it was more like a slow, organic little project that grew into something else.

When we turned into a company we released that game into PC. So, we did, we added, we made it better and we released it in PC. And then after that, we started working on the game we’re working on now. And that’s been taking a long while. So, there was no, “Bim! I know, we’ll do this!” It was more like, “Oh, okay.” It’s like everything games I think is very iterative. And you might have 50 million “Bim!” ideas and actually the one that got you started is nothing like what you got at the end.

Andrea, it sounds like you’re really driven by curiosity now. How does that contrast to what was motivating you in previous jobs?

Actually, kind of similar. For me, programming is something that I just love. I can’t imagine not doing any code, basically. And anytime I move jobs it’s because, or I change what I was doing, was because, okay, there must be a better way. It’s been kind of driven by what’s interesting to do and how can we do it better. And so, I think even though it sounds crazy, maybe it’s not that crazy, and I think you just hit on the spot as to why.

Is game development now much more approachable from a hobbyist perspective, from something you can do in your spare time, than it used to be?

Absolutely. It’s so easy right now. I think it’s never been easier. Even when we started a few years ago, three or four years ago, only a few engines were open source or they were somewhat cheap or whatever. But now, Unity which is a pretty good way to start is free. Unreal is free or you can, you don’t have to pay much. There’s a bunch of different open source engines like MonoGame and Duality. And a lot of JavaScript ones that I sadly don’t know all that well, where you can actually just play with them and then go all the way to release if that’s what you want. So, anybody that likes games can just do it with their computer. So, even some people, I heard of people coding their own games on their phones and releasing from their phones, which is kind of cool. So, totally approachable.

So, we are kind of comparing game development, business development. Have you found that you had to learn new skills or new coding practices to write games that you don’t necessarily have to have or do in business development?

You know, it’s funny. The thing that is hardest is I like writing clean code, or cleaner code. And in games, you just need to get there as soon as you can. And you’ve got to learn to take shortcuts. And that is just strange to say, but that’s what I found. It goes from [inaudible] to you should write super clean code that is always, it’s going to be there for a few years so you have to be thoughtful about the side-effects of writing this. Where in games, it just seems like it’s like, okay, get it done first. If we need it for longer, if we’re going to leave it there, we can always clean it up. So, that’s one strange skill to have to unlearn, to be clean.

The other one I thought you also need to learn loads. You need to learn math or relearn math. There is the game engine architectures are different to what we’ve seen. Probably the closest you can get to is MVC in certain aspects, when you compare to something like a component-based engine. But the constant update is a thing that it really switches your brain, or that I had to… it caught me a lot at the start. I don’t know if that makes a lot of sense to people that haven’t done game development. So, if you want, I can explain more. I don’t know.

I would love for you to explain more.

Okay. So, what you have in a game is a continuous loop. And that means that every 60 milliseconds, something will happen to your code. So, when you write code, for example you’re writing character code. And you have a character and you’re just doing some logic for it. You have to think that whatever code you wrote, it will run really quickly. And something, the loop, there is no reactive… no user will go and click on update, or add customer or whatever. The game will run on its own. It will react. It’s not reactive. It’s just real-time. It’s there, always. So, that’s from the point of view how you think about each component.

But at the same time, when you have the engine, what you have is an engine that has the big game loop. And the engine will go and update all these components that are like little bits of logic that you can put in different game objects. So, the idea is that, say you have a hundred components. Some of them might be for your game UI. Some of them might be for some characters, backgrounds. All those hundreds of components generally will update in some order. Sometimes you can control that order and sometimes you can’t. But they will all update [inaudible]. Now, 60 milliseconds, 60 milliseconds, 60 milliseconds. So yeah, that part [inaudible].

So, even if the user is not interacting with the game, the game is interacting with itself?

[Exactly]. Oh, you know that when you, say you pause the game, sometimes you see that the characters keep doing stuff. Sometimes that’s on purpose and sometimes it’s like a “feature” and I’m doing air quotes.

So, it’s a feature that actually the game developer didn’t want to go and write more code to have to pause the game, so maybe look cool, I don’t know. [Chuckles]

When I was in QA, I would always tell the developers sarcastically, “Oh, so it’s a feature.” Because they insisted it wasn’t a bug.

[Laughs] Yeah.

So, I get that.

You know, it’s a bit more to, I think… again I can only speak from my own experience. I feel like in games you get close to the metal in a lot of ways because, well okay, you have several levels of code. So, you need very performant code but also you need very high level that changes all the time kind of code. And so, the low-level code that is performant, that’s code that you need to look at very well but generally, will look ugly because it’s performant code. So, you’re trying to [multi-try] whatever you can. You’re trying to be efficient with your animation runtimes and everything like that.

Then you have an intermediate layer that is like systems that the game needs. So, it could be something like, I don’t know, a score system or something like that. And those kinds of systems, they do need to be clean. And they would kind of be enterprise-level, you can test this kind of code. I don’t want to, see, it sounds like I’m dissing enterprise where I don’t think that’s really fair. So, if we go back to games, if you’re doing something, a game system, score, health, whatever else that’s working at that level, it’s game-specific. But it needs to work really well throughout the game. You can test that. You can write really nice code. And it doesn’t need to be that performant. So, you can still improve, try to improve readability rather than performance.

And then you have a third layer of code on how the code feels and goes. And that’s scripts and gameplay. So, that’s all the game that basically, when you kick that ball, if the ball will go that way and it turns green when it touches the dragon, or something like that. So, it’s very, it changes all the time. It’s probably really messy. It’s not performant at all. Or, you don’t look at the performance of that so much. I hope that kind of makes sense. So, stop me when I stop making sense because I really don’t know.

In your talk, your F# tools that shape you talk which we’ll link in the show notes, you mentioned that you don’t worry about performance while you’re iterating in your scripts. And just now, you said you don’t try to make your scripts clean, where it sounds like by ‘enterprise’ you mean focus on readability, really clean code, as opposed to games where in your other layers you’re either worried about performance so it’s ugly or your worried about super-fast iterations, so you don’t try to make it clean.

Yeah, yeah, totally. And the weird thing is with F# where I do a lot of scripting in it, I actually find that I’ve been now iterating on trying to make that process a little bit better. And the code is turning up actually quite nice, or nicer. Initially, it was F# but it was very imperative style. But I think I got a little bit, with a little of experience, I got a little bit better at writing code I guess. And that turned the code a little bit better. And you can start writing little abstractions, like oh actually I don’t have to check 58 nodes here. I can just use a little thing here and make it read as it goes, as opposed to have to do a lot of error checking and the game will blow up. So yeah, totally what you just said.

How important is automated testing in your process, and is it even possible?

I was obsessed with this, particularly at the start of the company. I wanted to test everything. I was like, it must be possible. And it is possible to test the performance side of it sometimes. You can do some testing there. You can test the systems asset that I talked about, those three imaginary layers. This is the way I see it. I haven’t seen it anywhere else. So, you can test up to that layer. So, you can test systems and the engine a little bit.

But the scripts, you can test them but it’s just pointless, because it just changes too much and it gets in your way. So, you wind up not maintaining the tests. And also, it’s really hard to do because you’re trying to do something like pixel comparison. So, you want to go end-to-end, take a screen, shoot up the game. Say you click somewhere and then you take another screen, shoot up the game, and that is just not specific enough. It doesn’t test what you want and it’s a lot of work to get right. So, it winds up not being a good idea, at least for the games we’ve done so far.

In your talk you mentioned something about having a lot of tests, at least example tests, getting in the way of change. And that seems to be a theme of how do we make this so we can just change it super-fast and don’t make it clean because we might throw it away in a few minutes. How fast are your iterations?

Well, see at the script level we’re talking about minutes. [Chuckles] like literally, you do something, change it, change it, change it. Then you go away for a few days, maybe you come back, change it, change it, change it. Then it’s generally a burst of activity for a few weeks that it just changes all the time. And then it rests for a while. Then is generally [inaudible] times. Or, maybe you have to redo certain areas.

How do you know when it’s right?

Who makes these decisions? Do you have a product owner who comes along and says, “Oh yes, that is what it should do.”

[Laughs] We actually had, very early in the project we realized that design by committee is just not going to float. So, one of us is the decision maker for all design decisions. And basically, this person listens but doesn’t necessarily act… I’m like, “No, but you should totally do this.” It’s like, “Yeah, no. It’s not going to be a gigantic red cat, Andrea.”

We talked about cats. Just one or two. It’s good. But 50 is not okay. [Laughs] So yeah, there is a benevolent dictator there. And do you know what? Even when you’re doing your small bits, you can’t go and ask everything of course, because that would be just really boring. But even when you’re doing things, it’s very much about your own experience playing games that really comes and takes over. So, that’s why it’s so important that game developers actually play games and that they play games of the similar types of the types you’re developing right now.

I’ve been playing fighting games only basically for the last two years, just because we’re doing this. You can wind up going, “Oh, I wonder how they do it in DMC in that level four, when I don’t know, you’re floating in that broken building?” Having those kind of references in your brain and being able to talk to other people on your team about them and how they feel and how you’re going to get maybe that same feel but in a completely different context in your own game, it’s really important. So, I guess the straight answer to your question would be benevolent dictator plus you playing similar games for a while.

I have a question about the difference between, in focus, between making games and making business software. In business software there’s kind of an assumption that somebody needs this software. So, there’s a certain amount of leeway for having a crappy user experience because somebody needs it. So, they’re going to have to use it. And maybe if it’s really, really bad they’ll look for something else. But other than that, they need it so they’re going to have to deal with it. And it’s like that’s not nearly as much, that’s not a real issue with a game. Do you spend a lot of time thinking about how to make the program inviting?

Oh god, yeah. This is a saturated market. In every platform, you have this problem, particularly mobile. You have this problem of you want to play a game, go search with games with cats and you get 58 million games about cats in your mobile. And probably you [will like] none of them. So, when you add that to the question that you just asked, oh yeah. And the game is supposed to be fun, right? Try to get fun as a condition of satisfaction. Must be fun. [Chuckles] What does that mean? It’s like, oh, that kick feels amazing. And you feel super powerful. Okay. So, it’s actually really, really, really hard. And yes, that’s actually most of the work of [inaudible] and game designers. So, totally spot on.

Man, I want to add that as a requirement to my next project, or current project.

Must be fun.

You know, the things that wind up being the funnest to play, they not always are the funnest to work in. [Chuckles] This is a caveat of game development. It’s really fun and rewarding in that you’re making a game and that you have immediate feedback. But some of the problems you have are pretty tough, because you have so much state everywhere. Basically, a game is a gigantic state machine. So, your brain hurts sometimes, a lot. You’re constrained by hardware from people that you have no idea what hardware they will have. And they get very, very angry if you don’t fix their problem, even though they don’t tell you what their problem really is. So you know, just make sure that you know what you’re signing up for. But you know if you want to come and work for us for free, or I mean for cat hugs.

We will welcome you, Jessica. You can work remotely even, for cat hugs again. I can send you my cat. He can give you a hug. You send it back.

Okay.

What kind of techniques do you use to cope with all that state, from a programming perspective?

I think part of it is the game engine, because you work in components. But also, the other thing is you actually deal with a lot of state. I don’t have a great way to… there are some classes, and we work in C# and F# for the scripts. But some of the most painful things to work with, I have found good ways, ways that I’m happy with, that I look at the code and go like, “You know what? I’m happy with this.” So basically, with difficulty.

I’m always open to suggestions. And if you want to dig at some code, I can send you some, because again, you have also the pressure of time. We’ve been working on this game for about two years now and we have to release. We have a deadline. And that deadline is not going to move. And it has to be done. So, basically if it works, you can live with it, kind of. Okay, it depends a little bit. You don’t have a lot of leeway. I can’t go off and experiment on these few problems for three months. I need to solve it right now.

You know this is something that I think we don’t see as much in the business world. It depends on the company you’re working for, sure. But most of the time you’re working for a company, unless you’re in a startup that is pretty stable. And if you don’t make your deadline because the deadline is really just a made-up arbitrary date that the management came up with, sometimes they took input from people who actually know how software is made.

But where you’re out there independently building a game, if you don’t release on time, if you don’t meet the commitments on Steam or whatever system that you’re putting them out in and you fail to meet the expectations of your audience then you have real business issues. And I think a lot of times developers, they don’t understand a lot of the business constraints, and vice versa, the management doesn’t understand the development constraints. And so, you get this mismatch where you don’t really see that with the indie game developers because they know what they have to do and they generally know when they have to have it done.

Well, actually knowing, it’s kind of more of a feeling. You don’t have the, “Oh, it’s the 13th of May,” or some date like that. It’s more like, if we don’t release again in a month, we’re going to start either losing users or we won’t get any new ones.

Right.

And that pressure is absolutely real. Our game is on Early Access at the moment. And we went live on that on either the 14 or 17th of November. And every time we do an update, we get a huge bump of users. And people giving us not only money, which is great because it helps us actually finish the game, but also feedback. And they have problems and they have great suggestions. Some of the stuff we just didn’t think about. And it’s like, “Hey, why don’t you put a light here and I can see stuff,” that we thought it was really obvious that that was there, or something like that. So, I

think some of that is really good. But I actually am not sure it helps you write better software. At the same time, you innovate when you’re under pressure. You can, it’s a very strange balance to have that thing of, you have a real deadline that you can move a tiny bit. You have a range, but that range is not, “Oh, a year more.” It’s more like, “Okay, have two weeks more, tops.”

Yeah.

Or you’ll run out of money. [Chuckles]

I think the main point I was trying to make was that usually in a business setting, the people who are looking at those constraints where we’re going to lose users, et cetera, are different from the people who are making the software. And in your case, it looks like it’s the same people. You’re building the game and you’re looking at the repercussions of missing your deadline.

Yeah. Well, the things like we’re a team of, at the moment we’re five and a half people. And I say half because we have a part-time. It’s not a very short person.

Or like we killed someone and we just have half. [Chuckles] So, he helps with some user testing. But five people to run the business, make plans, design the game, build the game, [inaudible] the game. Trust me, it’s not a lot of people.

Mmhmm.

And it’s a huge game. So, I kind of think that actually gives you a lot of power, because that contact is direct. You actually have to respond to the communication from people. When something goes wrong, you get the, “Boo. This doesn’t work.” And when something goes right, also people go like, “Oh, thank you. This rocks my world.” So, there is something to be said for being there for the people. And I think most developers would greatly benefit from that experience. Not for all the time, because it is very time consuming. But I think it’s a valuable lesson as a developer to actually own up and be responsible for what you’ve done.

How do you think business-oriented software could implement a similar sort of fast user feedback loop?

Mm. Things like, then you get politics involved. See, we don’t have politics because it’s our thing. But when you get, I’m imagining someone like Citibank suddenly deciding to apply this and it scares me a lot.

You know what I mean? [Chuckles] It’s like, they would put metrics. Oh, how many customer requests did they answer? I don’t know. I don’t know how to answer your question without feeling like I’m doing something wrong, killing kitties in a river or something like that. It just feels like slightly dirty. Maybe I’m wrong. I don’t know.

I’m wondering too, in game development. Do you test your code? I don’t mean like playing the game to see if it works, but actually writing unit tests and stuff.

Oh, yeah, yeah. As I mentioned before, we do test. Sorry, we test [inaudible]. But we do unit testing and integration testing and property testing up to systems code. So, some of the performance –based code has some unit testing, some integration testing, where it’s possible and it makes sense. Some bits are just too close to the hardware to be able to replicate reliably and it needs some user testing. But at the system level, the tests are easy to write. And we have quite a few of those. I think we’re over a thousand, maybe more. And then at the scripts level we have none. We used to have some, but they stopped us. So, we just got rid of them. Because they are constantly tested and exercised by actual users.

You have property tests at the system level. You talked about those in your talk and I found it really interesting how you use FsCheck.

Mmhmm.

Can you talk about some of the invariants that you test?

Yeah, we kind of use property testing rather naively. So, some of our systems have very obvious properties, like when you increase the score, the score should go up.

But it’s really obvious. But the things like within a score system you have all these weird multipliers and it depends on a player’s points. It depends on how many points you have from, there’s rank on the fighting. And it could be that maybe you’ve done something stupid which is likely because we’re human, and you wind up decreasing your score as you play. So, what we [inaudible] is basically with that, one of the properties of the score system is score increases when you increase. And this is your maximum score. Sorry, and this is your current score. Then another one is like, the score is not negative. It’s like, you want to know that those systems do at least that bit okay, that no matter what changes you make to your ranks and whatever, that still works at it should. And it’s really easy to do with property testing, and with unit testing actually kind of hard. It will be way more setup. You wouldn’t think of all the edge cases. So, it’s kind of naïve but it’s actually caught quite a few bugs as is.

The thing that I think scares me the most if I were to write a game are the areas that I’m not really good at or don’t understand. So for example, artwork or I think I could come up with an okay story, but I don’t know if it’s an okay storyline for a game as opposed to say a short story or a novel. How do you address those?

Well actually, there is a lot of ways to. There are all these different kinds of games. So, say for example you are not very good at art. But you could do all generated art. You can do real-time art stuff. So, you could just do shaders or geometrical shapes. Then if you’re thinking about story, you can use something like Twine or Fungus. Those are tools that allow for storytelling kind of games. So, there is a plethora of tools that you can now use.

And also, it’s like the styles of games we’re seeing, it’s more and more diverse. Maybe 20 years ago, 10 years ago, there was like, oh, platformers, first-person shooters, RPGs, racing. And now there is just all these diversity of stuff. Like a friend of ours here, he made just a game about breathing. Like, not breeding like chickens. It’s like you breathe [inhales] like that. And basically, now the game has been reviewed as it helps with anxiety, because it regulates your breathing. So, I think actually your limitation, whatever your limitation you think you have, you can use them to your advantage to create an amazing experience. So, I hope that answers your question.

Mm.

Andrea, this is mostly a Ruby podcast. And I would love if you could tell our listeners something about F# and what’s interesting about it, and why we might want to learn it.

Ooh, sure. I knew this was a Ruby… actually I did do some Ruby a long time ago. And I kind of really like the language. I nearly went that way instead of going .NET. So, we might have been talking regardless, if that was an alternative reality. Anyway, why F#? See, I really like about F# that it’s a concise language. I love the type system that it has. I know that if you were coming from Ruby, why would you love it? Because I know you like [inaudible].

F# was the first functional language that I ever learned. And it really taught me functional programming in a way that wasn’t painful. It makes it easy to think about things like functional composition. And you learn pattern matching and data decomposition in a way that just makes your life easier instead of making your life harder. F# is also super accessible. You can ‘brew install’ it and it works just fine on the Mac. And it’s got a REPL so it’s super easy to just play around with. I’ve used it back in the day when F# was the only functional language I knew anything about. There were times when I got stuck on a problem and I was having trouble thinking it through in Java, I went and wrote it in F# in just a few lines because it’s super concise. And it totally flowed better that way. And then I went and translated that into about 200 lines of Java. But it passed the tests.

So, F# is a great language that’s at your fingertips. And it can help you think in new ways.

That is true. And there are three things that are kind of close to Ruby, I think. Or, I felt the same equally welcome in Ruby and in the F# community. I remember this was, I don’t know, 2008 maybe. I remember in Ireland there was a small Ruby Ireland group. And I went there and everyone was friendly and was trying to teach me stuff. I started using F# and I got a very similar welcome of, “Hey, if you have any problems, just ask.” So, there’s a great community.

The other thing that we have is that it’s an open source language. [Inaudible] started with Microsoft but it’s now owned by the community so much so that we have the F# Software Foundation. And that actually [has worked] towards the language I guess, that’s the word. Another good thing about it is because it’s on .NET, you have all the libraries you need. Okay, that’s not so Ruby-esque. But if it’s not in F#, it’s definite in C# you can do it. And yeah, everything that Jessica said totally.

And the best thing also is that we have type providers. Type providers, they’re really cool. The language itself is beautiful. But type providers is an F# 3.0 feature. And what it can do is ideally, okay, the definition is you can get types provided to you and with that you can do a bunch of stuff. But a concrete example of that is you can grab some JSON or XML, do three lines of code, and with that you get type information, i.e. for example you got a CSV file and you got it through FSharp.Data, you can get access to that information through the column name. And that column name actually has a type. If you want, you can make it be formatted in a particular way. And if you’re dealing with data that is just a really handy and beautiful feature.

Question.

Yeah?

Does that mean that in the F# REPL, like in the F# command line, you can make a web service call and get back some JSON and from that get autocomplete…

Oh yeah.

When you’re saying, what is in here?

Mmhmm. You can create an F#… probably you don’t want to do it in the REPL so you can get autocomplete. But if you’re doing it on F# script which is like one file, and if you’re doing it either in Visual Studio or Xamarin Studio… Xamarin Studio is on Mac and Linux and also available on Windows, I don’t know if it’s Linux actually. It might be [inaudible], but definitely Mac. You get Intellisense on dot. Say your CSV has, how many ponies did you have when you were a kid? So, you will be like, file <dot> how many ponies blahblah <dot> and you will get all the type information there. So, it could be four or maybe some float. How did you have 4.5 ponies, we don’t want to know. But, you know.

Awesome. So, it’s like the best of types that help you explore what you have without having to, all the overhead of creating them.

Yes, absolutely. The type [inference] on this language is beautiful. And so, you could type without actually, you could write your code without thinking too much about types. But you have the safety of types. And so, I don’t know how Ruby, the community, perceives types. So, I don’t know how to talk about it in the correct language, basically. But if we’re talking just straight types literature, we’re talking about a lot of type safety for a little bit of effort.

Types are definitely coming to Ruby in one shape or another. Matz is starting to hint about that for Ruby 3.0.

Really?

I didn’t know. That’s awesome.

The implementation details are non-existent at this point and there’s a lot of theorizing about exactly what that’s going to mean and exactly what it’s going to look like. But it is something that is definitely on his mind.

That is really cool. I think it’s slowly coming some way top plenty of the languages. Like you know that guy, Ambrose, he has Typed Clojure. And his talk was very, very interesting. Trying to bring types to dynamic languages, that could be something.

Yeah. I really like having the option of writing something dynamic in a dynamic language while stuff is changing all the time, and then going back and adding type guarantees and type explanations, the documentation that the types provide, later after it’s solidified a bit.

Yeah. That seems like the sweet spot.

Agree.

Generally, I’m a static type kind of person. But I can, I do know you move faster without them, at least at the start.

I’m curious if you do any pair programming or any of the other agile techniques when you’re doing games. Or is it very much very person working on their own piece and trying to go as fast as possible?

It depends on the task. Some things are, I know a lot more about something and some of the other guys would know really well some other part. And this is something that we have to do that combines the two. And in that case, we would probably pair. Or anything that is just really complex, we would try to pair because it’s like, maybe I’ll do it and completely forget how it works. And the code would be, it’s like, “What did you do with these matrices here? Did you really need to do this?” It might come to [inaudible].

In general, we don’t need to particularly lately, because we’re not code complete. So, we haven’t been needing to do that lately. But we’ve done it. It’s very useful. Although maybe it’s pairing in the sense that I’d like to think of pairing. It’s more of a knowledge transfer pairing than a, “Let’s work on this together,” kind of pairing that we’re doing, which I think is somewhat awkward.

That’s kind of where I was going. I was wondering if there’s a siloing problem where one person knows exactly how this part of the game works. Another person knows how this other piece of the game works. And you’re limited in your ability to make changes or make fixes to an area that’s someone else’s expertise.

I like to call it ‘stupid courage’. So, when you need to work on something that you’ve never worked before, you just go and do it and hope for the best. Or if you’re stuck, you just basically say, “Listen, I’m stuck.” That’s also the good thing about a very small team. It’s like, you go and try your best and either break everything, but the things like, because again you have the [big game], when it breaks it’s not like, “Oh surprise. It became broke three months ago.” It’s like, “Surprise the game just broke and you break it for everybody.” [Chuckles] So, you have to fix it right now. So, it’s good that you do that. But also, everybody gets affected by your, as I call it, ‘stupid bravery’. That’s a joke, by the way. I don’t call it generally stupid bravery. But I think it...

Yeah, better.

Yeah, I like the idea behind it.

Is that what Facebook calls move fast and break things?

Yeah. The good thing is that we don’t have 10 bazillion users screaming at us. [Laughs]

Yet.

We won’t push the broken game intentionally, at least.

Oh yeah, because you said in your talk something about, if you get a null in here you don’t throw an exception because we don’t throw exceptions, because that would break the game.

Yeah. Yeah, so it’s weird. The things like, I think in enterprise or something like that, or in not games, we’re used to being able to throw exceptions. You can actually say, “No, this is definitely not cool and we’re not going to do this.” Where in the game, you kind of need to keep going forward as much as you can. The only reason why you would really stop the game and break it is because you can’t render. All the other things, you should show them as errors and warnings or feeble asserts or whatever. But you generally don’t throw exceptions. This is something particular to games. And actually, if you go and check something like the MonoGame code, you’ll see a lot of assertions like this. Because you’re trying to basically make sure that the user never gets, you’re not playing Age of Empires and suddenly, “Oops. Hello. It seems like you’re not able to render the castle. I’m going to stop your game now.” Even though you didn’t even notice there was a castle. So yeah, no exceptions.

Yeah, so silent or relatively silent error-handling. That is different.

Yeah.

I have one more question, and that is you do some teaching of game development right? At game jams?

Oh, well we do game jams. And I’ve been sneaking in F# [chuckles] tutorials in every one of them lately. If I’m there, an F# tutorial is running.

What is a game jam?

So, a game jam is like a hackathon. It’s exactly like a hackathon. So, it’s like you have a start time and an end time. And in that time, you need to make a game. We give you a theme, like eternal or something like that. And then you have between eight and 12 hours to finish a game from the start.

So, start to finish a game in that time. So, yeah.

Do people work in teams?

Yeah. They can work on their own, in teams, they can choose a platform, whatever they want to do it in. And basically at the end, we reserve an hour or two and people go and play each other’s games. So, at the end it’s all kind of manic because everyone is playing each other’s games. And in one of these you learn a lot. So, they are really, really great. And they’re really fun, too.

That sounds like a lot more fun than a hackathon. I would much rather make a game in a weekend than a website. [Laughter]

Yeah.

Yeah, and also there are prizes, but they tend to be a card game or something small that you want something because it’s kind of cool. But it’s more about the prize is making it, being part of it itself. Rather than in hackathons, it tends to be like, “Oh, I’m the best. Yeah.” Where this is more of like, “Hey, we’re together and we built this cool thing. Yeah.” And everyone says yes.

Andrea, what are new developments that you’re super excited about in terms of games and game technology?

Ooh. [Chuckles] It’s funny. The thing that I’m most excited about from a technology point of view lately is the fact that you can cure Alzheimer’s. I know this is not programming related. But I’m like, how is this even possible? So, I’m slightly getting excited about biology a little bit and the fact that we can do Star Trek stuff for real. [Chuckles] I know this is not games. But I like to live as well.

That’s awesome.

My last question is how do we find the games that you’re writing?

Oh. Okay, that’s super easy. You go to Steam, the PC gaming platform.

Mmhmm.

Probably the biggest one. And you search for ‘Onikira: Demon Killer’. And then you’ll find our game. It’s there at the moment. You can go and play it. Actually a big update is coming up, probably will be there on Friday. We have it in QA or whatever that means right now. That means that we tell a bunch of friends, “Hey, go and play it. It’s on Steam in this [inaudible].” So, that’s coming, one new level, one new enemy. Or two, I don’t remember. And a bunch of bug fixes.

Very cool.

It’s sufficient to search for ‘demon killer’ by the way. However, do you need an Xbox controller? Well, you definitely need a Windows machine.

Yes.

Which is limiting for some people. Fortunately, my kids have Windows machines. And do you need an Xbox controller? Because I [inaudible].

Oh yeah, actually that’s one of the changes, that we have keyboard mappings that are the ones for… basically we went around and checked and DMC had some keyboard mappings that are standard for DMC. And so, we used those. But in this update coming on Friday-ish, you can remap the keys and you can see what the current ones are. So, you don’t need it. And to support, you can actually play the game without the controller. But now you’ll be able to see what those keys are. [Chuckles]

Oh, that’s great, because I was just smashing buttons. [Laughs]

[Chuckles] You’re like, “Ah, something happened.” But things like, with a controller, the game is particularly if you’re not used to this type of game, with a controller the game just flows better. It’s more obvious about what you want to do. And a controller, I don’t know. You can get one for, I don’t know, $30 or so? And it makes a lot of games way better. I was not a believer until I got one. And I was like, “I’m an idiot. I should have [inaudible] got a controller before.” Because it’s more fluid to certain games, you know.

What is DMC?

Sorry, it’s Devil May Cry. It’s a game that has been going on for years. DMC 1, 2, 3, and 4. And arguably, 3 or 4 are the best, if you like 3 or 4. Then after that, they decided to make it all awkward and they released ‘DmC: Devil May Cry’, which should have been DMC 5. But then everyone hated that one. [Inaudible] you know, typical saga story. But anyway, good game. It’s a really good game.

DMC, Bayonetta, are kind of classics of fighting games.

Yeah, now I’m going to have listeners emailing me telling me I’m not living right because I didn’t know what it was.

[Chuckles] No, no. Sorry. You know the way you have certain context. It’s…

Yeah, no.

I should have been…

I totally understand. I just know that some of our listeners are hardcore game people.

And others of us also had no idea what DMC meant.

That’s awesome that you have an audience that is so varied. I like that.

Yes.

Yeah. Alright. Well, let’s go ahead and do the picks. Avdi, we haven’t had you on for a while. You ready with some picks?

Sure. Let’s see. I think first off, I’m going to pick a talk that I might have picked before. I’m not sure. This is a talk that I first saw back in 2011, 2012 and it’s been kind of ongoing since then. The talk is called ‘Schemas for the Real World’. It’s by Carina Zona. And she did it originally at a GoGaRuCo that I was at. And she’s been delivering updated versions in the years since then, adding new examples and stuff.

And if you haven’t watched this talk, any of the revisions of this talk, you absolutely have to go and watch it. It is, it’s just terribly important. The subject matter is something that I’ve been reflecting on a lot lately, which is that as programmers we play a large and growing role in constructing reality for a lot of the world. And particularly the topic that she’s talking about is the schemas that we use for our data. But this really applies to just the way we model things in general, and the ideas that we include when we model things very rigidly. So, if you haven’t seen this talk, ‘Schemas for the Real World’, do yourself a favor. Go watch it right now.

I will also pick a place. I will pick Maryville, Tennessee. This is the town that we’ve moved to, as you heard in the intros as my first broadcast from Tennessee. And we moved here so that we could be in the mountains. [Inaudible] a town nearby, as long as it had a gas station and a Walmart. But I’ve been really, really thrilled to find out that the town that I live now 18 minutes away from has just a remarkable array of meat stuff, has one of the nicest coffee houses I think I’ve ever been in, and some really nice shops and craft beer markets. And there’s at least one local brewery. I’m very, very excited to be living here and I’ve only just started to explore it. So, Maryville, Tennessee is my other pick. And that’s it for me.

Awesome. Jessica, what are your picks?

I have great picks today. Okay, okay. I have the new favorite program on the Mac. It’s called Monodraw. And it’s so amazing. It’s a diagraming program, but all your diagrams are ASCII art.

[Chuckles] Oh, nice.

So, you could draw the little [inaudible]. You can connect them with the little arrows. You can put the text in them. You could fill them with smiley faces if you want. You can move them around and diagram your flow. And then cut and paste it into your commit message.

Awesome.

Or in the comments, but I don’t believe in comments. I think you should put it in your commit message, because that never lies. This has, in a couple of cases, changed the way we programmed. Because it was so easy to just draw a very simple diagram. It doesn’t let you draw complicated ones. That’s a good thing. And yeah, conveys information super-fast. I could paste it into Slack. I don’t even have to make an image. Everyone can edit it because it’s ASCII.

My second pick is a blogpost that I read this morning. It is by Elizabeth Naramore. And it’s about being uncomfortable. If you are part of an open source community or any community that you care about and you want this project to continue rather than just serve your own interests, I highly recommend the post. The basic theme is if something you say makes someone else uncomfortable, that’s not wrong but it is detrimental to your community, because any community that’s going to be bigger than you is not about you. It’s about everyone else who might be part of it. And if they feel uncomfortable, they’re not going to complain most of the time. The complaints are precious and you should appreciate those. Usually, they’re just going to go somewhere else, kind of like playing a game I guess. If you want someone to help with your open source product, it better be fun. Those are my picks.

Cool. Coraline, what are your picks?

I have a couple today. The first is a little toy project called AmbientSpec. Basically, it turns longrunning RSpec or Minitest specs into ambient music. You get sweet sounds from passing examples and very subtle gongs to indicate failing tests. You won’t hear anything unless you’re test suite runs longer than five seconds, because silence is the most pleasing sound of all. And an interesting [story] about this little gem is that there was a woman named Wendy Beth who submitted her first ever open source pull request [inaudible] for Minitest. And she actually met Ryan Davis who writes Minitest and maintains it at a conference last month. And he was able to help her with the [end] duration. And that was a great first open source experience for her that made the gem a lot nicer. So, that’s it for the first one.

The Gathering has cited Cosmic Encounter as being incredibly influential in the design of the games that he has made. So, it’s [inaudible] fun. Three to [inaudible] players, takes a couple of hours, and is really, really great gameplay.

Awesome. Alright, I’ve got a couple of picks. The first one is a book that I know has been picked on the show before but I just read it and I thought it was terrific. It’s called ‘Ready Player One’. It’s just a fun book. If you played any of those games from the 80s, it’s just a lot of fun to read.

The second book that I’m going to pick has also been picked on the show before. I have to say that I’ve been listening to it on Audible and it was a little bit hard for me to get into, just because the content seemed to be different from what I expected. But I stuck through it and I’ve really started enjoying it. It’s called ‘Mastery’. I forget who it’s by. But we’ll put the link in the show notes. And so, it talks about the different levels of mastery and the different ways that people become masters at their craft. And it is a terrific book. So yeah, I’ll pick that. I think it was picked by Katrina Owen and David Brady in the past. I think that’s all the picks I have for today. Andrea, what are your picks?

Okay. I think I’ll start with the board game. And this one is called Dixit. And I’ll add it to the show notes. And it’s basically a game where you have to, it’s about… you get a picture, like a big card that has this beautiful art. And you have to say a word that kind of… okay, the game is a little bit more complex than that. But basically, you have to say a word that explains that image. And other people have to put similar cards that say what you just said, but with different images. It’s really hard to explain but really [wonderful] to play. The rules are simple, even though I just managed to completely destroy the explanation of it. And it’s [inaudible] [the family] and anyone. It doesn’t take forever. I really love board games. But this one got me hooked into playing board games more often.

And then another one that I thought maybe you guys would enjoy is a talk by, I don’t remember his name. Mike Bernstein. It’s a talk on GoGaRuCo last year called ‘Know your Types’. And I’m going to add a link to the show notes. It’s basically a talk about types. And it’s funny because it’s also for a Ruby audience, I think. So, I really like talks by this guy. He’s very inspiring and I hope you will enjoy it, too.

So, I’d also like to add a talk by Philip Potter on property testing. He gave it last year I think at some Clojure conference. I think it might have been Clojure Conf. And I added the link there. So, I hope you enjoy that. I hope you like it as much as I did.

Sweet. Thank you.

Alright. Well, I should have asked this before. But if people want to follow you or get involved in game development, I guess those are two different resources, but do you have some recommendations for it?

To follow me, Twitter is probably your best bet. I’m @silverspoon. And when it comes to learning or doing game stuff, I think starting off by going to game jams is the best advice I can probably give you. There are game jams online, not online, all the time. Just search game jams and you shall find. [Chuckles] I don’t know. We’re going to [inaudible] which is one specific type of game jam. But there is one probably every week in different parts of the world. So, I’d say that’s my advice. Make all the games you can.

Alright, cool. Well, thanks for coming.

Thanks for the invite. I really enjoyed it.

Alright. Well, we’ll…

Yes, thank you.

We’ll wrap up the show. We’ll catch everyone next week.