#223: Fun and Easy 2D Games with Python Transcript

00:00 Michael Kennedy: Have you tried to teach programming to beginners? Python is becoming a top choice for the language, but you still have to teach them how to work with the language and understand core concepts like loops, variables, classes, and more. It turns out video game programming, when kept simple, can be great for this. Do you need to repeat items in a scene? Well, there's a natural situation to introduce loops. How about move an item around? Maybe make a function to redraw it at a location. On this episode, you'll meet Paul Craven, who created a new 2D game engine for Python just for this purpose, called Arcade. And even if you don't teach or you're not learning Python, it's great to play with. It's really easy to make 2D platformer and side scroller games. This is Talk Python To Me, Episode 223, recorded July 25th, 2019. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm. And follow the show on Twitter via @talkpython. This episode is sponsored by Indeed and Rollbar. Please check out what they're offering during their segments. It really helps support the show. Paul, welcome to Talk Python.

01:26 Paul Craven: Hey, great to be here. Thanks for having me, Michael.

01:28 Michael Kennedy: Yeah, it's great to talk to you again. We got a chance to meet each other at the creators booth part of the PyCharm booth at PyCon. That was fun.

01:37 Paul Craven: Yeah, I enjoyed PyCon a lot.

01:39 Michael Kennedy: Yeah, so did I. I call it my geek holiday. I go, in August I'm going to go on holiday with my family. But in May I went on that holiday with my friends, my geek friends. It was great.

01:50 Paul Craven: Thankfully, well, it's the only conference I go to, and I look forward to it every year.

01:53 Michael Kennedy: Yeah, yeah, absolutely. And while we were there, you were presenting your project that ties in both to your teaching side of what you're doing at the university, but also just making gaming and Python more fun, this thing called Python Arcade. So I'm really looking forward to talk to you about that.

02:11 Paul Craven: Yeah, it's a project I'm really passionate about.

02:14 Michael Kennedy: Yeah, I could tell. So before we get to that, though, let's start with your story. How'd you get into programming and then Python?

02:19 Paul Craven: Video games, actually. Long ago, I worked with an Apple IIe. My dad had gotten one of those. And being the evil father that he was, he wasn't going to just pay for video games for me to play. So he said if I wanted to play games, I'd have to program them myself. And there's a few books out there by David Ahl, More Basic Computer Games and Basic Computer Games. And they basically just had computer games in Basic that you could type in. And I got started programming doing that. Once you had the game in there, you could start modifying it and customizing it the way you wanted. I just absolutely loved that as a way of learning to program. And that's how I introduced my college students, many of which haven't programmed at all, to try to get them hooked into programming, because it's not just me teaching them programming. If they only take one semester, it's only a limited use. But what I really want them to do is realize that programming can be fun and entertaining and a creative process that they can get into just because they plain like programming.

03:25 Michael Kennedy: Yeah, absolutely. I definitely think that that's an interesting angle to help people get more engaged. So Basic was the sort of entry point, but where'd you learn about Python?

03:34 Paul Craven: I had a student actually present it. We were teaching programming in Java, which is a terrible language to teach programming in.

03:42 Michael Kennedy: It was the main way to do it for most schools for a long time.

03:46 Paul Craven: Oh, it was a step backwards from Pascal. And that's how we were teaching it. And he gave a presentation on Python, wasn't too interested in it at first, 'cause the last thing I needed to do was learn another computer programming language. But his presentation was actually really good, and it got me thinking about how simple and incredibly straightforward you could get somebody started with programming. And then I just got the bug in my head that maybe this would actually not be a bad way of teaching programming. So we started, now it's pretty common to start teaching in Python. But when we started teaching in Python, it was not the common first language by any means.

04:20 Michael Kennedy: Yeah, absolutely. It was all about Java. When was this, what year, about?

04:24 Paul Craven: I would guess it'd be about 11, 12 years ago now.

04:27 Michael Kennedy: Yeah, okay, interesting. So Python was not nearly as popular and clearly the right choice as it is today, I guess.

04:33 Paul Craven: Yeah, no, not at all. And it took a little bit of convincing for me with the other people at the college in order to be able to do that. We started introducing it just a few weeks at first, and then eventually moved on to the entire semester. So our first semester's Python. And then once they get hooked into programming, then we hit them with Java after it's too late and they've already signed up for second semester.

04:55 Michael Kennedy: There you go, they're already committed. Well, I think that that's an interesting way to think about it, because I think that a lot of the ways that programming is taught, and I don't just mean self-taught. I mean even in universities and stuff. I think it's kind of broken. I think it's taught with an expectation of extreme delayed gratification. And I've talked about this before. But basically like we're going to teach you loops, we're going to teach you variables, we're going to teach you memory, we're going to teach you the heap, we're going to teach you pointers, we're going to teach all these things. And maybe at the end of the semester you can do something sort of interesting, maybe. But you might have to wait a couple of courses after that before you actually build something that you care about. And that just, it's crazy.

05:36 Paul Craven: It's not just delayed gratification, it's delayed explanation. Public, static, void, main, string, args, I mean, you can't explain all of that in their first lesson just to print something to the screen, right? Just type this in, and we'll explain maybe something later in the semester how it works. That's not how I want to do it. I want them to understand exactly what they're doing.

05:54 Michael Kennedy: Yeah, exactly. So I definitely like that you're starting with something that gets them to these short little wins quicker. Then you can move on to stuff where you're talking about static languages like Java or whatever when they're already understanding, okay, if I go through this, the payoff is really big, or here's how I use it, or whatever.

06:11 Paul Craven: Right, that's exactly it. It does assume that they'll like arcade games. But a lot of my students aren't as interested in spreadsheets and are a lot more interested in arcade games. So I can hook a fair percentage of them.

06:25 Michael Kennedy: When we were talking, one of the things you said that I thought was pretty interesting is much of what you have to teach for programming, there's some kind of visual aspect to it, right, like lists or data structures or loops or whatever, right? And it's one thing to just do that in a terminal app or something like that. But you can actually visualize it better, potentially, if you have this simple game platform to test, to sort of teach these more abstract concepts in.

06:53 Paul Craven: Right, a student can get really frustrated if they're supposed to get a 10 as an output and instead they get a 12 as an output. They don't really care. But if they're drawing a football field or they're drawing a unicorn or something like that on their screen, then they'll spend a fair bit of time trying to get things lined up or just right.

07:12 Michael Kennedy: Right, right, if the horn points down, that's not okay.

07:14 Paul Craven: That's not okay. For the occasional student, they do want to just sort of give up at that point. But most students really will spend a lot more time if they see that visual image and try to get it just the way they want it.

07:28 Michael Kennedy: Maybe give us some examples of the types of things that you're teaching them there with games.

07:33 Paul Craven: Well, to start off with, one of the first things we do is just create an image. And the thing I like about using Arcade for that is that you can do it without defining a function before you get to that point. So you learn about how to call a function, and even just by calling a function, I don't have to have them create classes. I don't have to have them create functions. All they have to do are simple calls. And then they can actually build on that to create an image. And then that introduces them to the coordinate system. And you can go off of that so that if they want something like a fence and they don't want to create a drawing command for each individual post in a fence, then that just naturally just leads itself to, oh, hey, wow, there's a solution for that. Let's introduce loops.

08:19 Michael Kennedy: Exactly, yeah, 'cause it's really painful to write 50 little fence objects and move them around.

08:23 Paul Craven: Exactly, and it's very iterative. And they can see the value in picking up that, hey, I need to learn about loops. Hey, oh, if I create a function, then I can create a function that'll draw a snowman. I can create a function and call that function, draw a snowman here, here, and here, rather than just repeating the code over and over again.

08:44 Michael Kennedy: Yeah, sure. I do like that, that you can start in this really simple mode. Kind of like the print hello world side of things, you don't have to have all the extra stuff, but you do have a pretty rich API, which I do you want to talk about and get into. But maybe before we really dig in to even Arcade, let's just kind of set the landscape for everybody. Not everybody is creating games, or maybe, more like me, they've messed with creating games, but it was more like 15 years ago. And they haven't really done much since then.

09:10 Paul Craven: Right.

09:11 Michael Kennedy: So what are some of the options for building games? What's the spectrum of what we could do?

09:16 Paul Craven: Well, at the low level, you've got the ability to just individually manipulate the dots, what I would call raster graphics. It's a very slow way of doing graphics, but it's the original way a lot of people have done graphics. Then there are a lot of libraries out there, or APIs for like OpenGL, which is really big, DirectX, which is, OpenGL is cross-platform, DirectX is very much Windows. And Mac now has sort of gone away from OpenGL, and they're pushing their own Metal as a way of doing graphics. So they have all these different APIs. And then basically, to make it easier to program those, there are a lot of game engines that sit on top of those. You got the Unreal, Unity, Godot. There's several game engines that do that and take care of some of the underlying work for you in those OpenGL, DirectX, Metal.

10:08 Michael Kennedy: Yeah, and a lot of times that means working in C++, right, like with Unreal or some of those other real game engines, or Unity is C#, or things like that, right?

10:16 Paul Craven: Right, Unity can be like C# or JavaScript. Godot's fairly popular. It's a lot more of a friendly type of language, but it's not Python. So yeah, there's different options out there. But all of them take a fair bit to get up and going. And I wanted something that was really easy for a beginning programmer to get working but still allow a hobbyist or a more advanced user to create some cool games in their off time.

10:45 Michael Kennedy: Right, well, so that certainly makes sense for Python. And then even maybe a simple API on top of that, right? So you're not going to drop into native OpenGL and C++ and say, we're going to teach you about data structures, 'cause that's a deep world. I spent a lot of time writing simulators and doing programming there. And it's fun, but it's not a simple place.

11:05 Paul Craven: And not necessarily friendly, either.

11:06 Michael Kennedy: No, no, not so much. So in the Python world, I had heard of PyGame. That's been around for quite a while. And I heard of PyGame Zero, which I didn't really know how that was different than PyGame until recently. What else is there? Obviously there's Arcade, as well.

11:20 Paul Craven: Yeah, Piglet, a few other ones, Cocos2d, I think. And PyGame by far is the most popular one. And I taught using it. In fact, even wrote a book on developing arcade games in PyGame. And I really like PyGame. But it has been around a very long time. So it kept a lot of backwards compatibility on Python, so it didn't use any of the new Python 3 features. And the maintenance on PyGame at the time had completely fallen off. So where I would try to make improvements and do pull requests, absolutely nobody was doing anything with that.

12:02 Michael Kennedy: Isn't that super frustrating when you're working with this project, you love the project, you put a lot of energy into it, you go so far as actually creating a pull request and submitting it. It's one thing for them to say, you know, it doesn't actually fit with our vision or we can't accept it or whatever. But if it just goes unaddressed, that is really not the best feeling.

12:20 Paul Craven: Yeah, so there was a lot of back and forth on that, trying to resurrect some of the people that were working with it. And I actually just tried to do my own development, 'cause you could always create your own branch. But PyGame was developed off of an old library called SDL, a C++ library. And that library itself was pretty old. There's an SDL2 version of the library, which I also tried working with and didn't much care for. The underpinnings of PyGame just, if you wanted to keep the backwards compatibility and update everything, it just didn't seem to me to be a really worthwhile effort, particularly when there weren't maintainers at the time. It's actually started to pick up on maintenance now, which is great. But I wanted something better. And I thought, gosh, since most of the people that I work with are starting from scratch, I could actually just start a game engine from scratch using something more modern, like OpenGL, and work off of that.

13:23 Michael Kennedy: Yeah, and you get all the benefits of high-end modern graphics cards, GPU-accelerated stuff, and all that, right?

13:30 Paul Craven: Yeah, and I taught a long time using PyGame. So I found a lot of things, and there's a lot of things about PyGame I really like. So I was able to take those ideas and move it forward, try to clean up the interface, use the new Python 3 features, do the bugs that my students always complained about, 'cause when I teach, there's always these little warts you have to sort of tell students about. And every hour you spend telling a student, oh, well, the coordinate system that you learned, well, it's different in computers, because zero, zero's in the upper left instead of the lower left. Or SetMode is, in order to open a window, you use a command called SetMode. I know why it's called SetMode, but you really don't want me to get into that. And oh, you want to make a football and rotate an ellipse? Yeah, sorry, you can't do that. You start getting over these, and you'd come up with a list of them over time. And it's just, gosh, I think I could do something better, quite frankly.

14:26 Michael Kennedy: This portion of Talk Python To Me is brought to you by Indeed Prime. Are you putting your Python skills to good use? Find your dream role with Indeed Prime and start doing more of what you love every day. Whether you're a developer, data scientist, or anything in between, one application puts you in front of hundreds of companies like PayPal and VRBO in over 90 cities. Indeed Prime showcases your experience and tech skills to match you with great fit roles that meet and exceed your salary, location, and career goals. And when you start a one-on-one conversation with one of their career coaches, you'll get resume reviews and personalized advice to help you get what you deserve. So if filling out countless job applications isn't your thing, let top tech companies apply to you. Join Indeed Prime for free at talkpython.fm/indeed. That's talkpython.fm/indeed. So you set out to do that, right?

15:22 Paul Craven: Yeah, basically I set out to do that. A lot of false starts, a lot of attempts on different back ends, and sunk a fair bit of time into figuring out how exactly I wanted to do it. So yeah, Arcade is built off of OpenGL. It also uses Piglet for doing the window management. Piglet is also a pretty good game engine. And it is not nearly as friendly as Arcade, but opens a lot more of internals. So when a programmer's more willing to dive into the internals, Piglet's not a bad option.

15:59 Michael Kennedy: Is there an escape hatch in your API to drop down to those internals, or is it like a take it or leave it?

16:05 Paul Craven: I mean, you could just import the Piglet library and start doing work in the Piglet library. I wouldn't really call it an escape hatch. They can...

16:13 Michael Kennedy: Yeah, just directly work with it.

16:14 Paul Craven: Yeah, just start working with, yeah, it's not really something separate.

16:17 Michael Kennedy: Yeah, okay.

16:18 Paul Craven: But Piglet has their own system for managing sprites, which we can talk about in a bit. I really just used them for doing OpenGL calls and windows event management.

16:28 Michael Kennedy: Okay, so there's not like a deep integration, multi-layer thing. It's more just like, take what they build and go with that.

16:34 Paul Craven: Right.

16:35 Michael Kennedy: For the few things you need.

16:36 Paul Craven: Right, and some of the, like PyGame Zero and some of the other, there have been a lot of things that have been built on top of PyGame. I kind of wanted to try to avoid some of that, because you get too many layers of abstraction, and things just get kind of weird after a while.

16:51 Michael Kennedy: Yeah, there's always that leaky abstraction.

16:53 Paul Craven: Exactly.

16:54 Michael Kennedy: That thing that should be easy to do, but it's actually really impossible to do, because something in the middle, yeah. Nice, so it sounds like another one of your focuses on building Arcade was to focus on making it Python 3 native.

17:09 Paul Craven: Right, the ability to do type hinting, just going ahead and using f-strings, quite frankly I really like the type hinting in particular, because when I get students that work in PyCharm and they have those little linters that go with it, it helps a lot of students. And it's not something, actually, I thought that would help students as much as it really has. I've gotten a lot better code once they get those hinting features that are available.

17:38 Michael Kennedy: Right, we expected a number, and you're passing a string. That's probably not okay. Something like this, yeah?

17:43 Paul Craven: Right, exactly. And it's just, I kind of started working with Python 3 to begin with, just at the beginnings of it. So I just am more used to everything that's Python 3. And thankfully that's not really such the issue that it used to be.

17:58 Michael Kennedy: Yeah, I saw some articles about Arcade and some commenters saying, oh, I can't believe you're using f-strings. This means I have to have Python 3.6. And I can't get that. How am I going to get that, you know? It's like, those are kind of going away, I think.

18:11 Paul Craven: It is a pain. I'm not going to lie.

18:15 Michael Kennedy: Well, I mean, until like a year ago, Ubuntu had 3.5, a year and a half. Not super long, right?

18:22 Paul Craven: Right.

18:23 Michael Kennedy: Even though 3.6 had been out for quite a while. It seems like Ubuntu seems to lag about, I don't know, a point version, right? It's 3.6 now, but 3.7 is out, yeah. I don't know their exact release schedule. But that, time is fixing this, right? So I definitely think Python 3 is the right place to be for this. And type hinting, it's super interesting. Do you do anything with it in terms of changing behaviors or anything like that? Or is it just there to help students be more accurate?

18:48 Paul Craven: Really it just helps students be more accurate. One of the other things I've really liked is, being in the classroom, customizing the exception messages. So as I get students that run into problems, having the exception, and certain areas I'll actually do a little bit of checking to make sure that they're actually passing in the right type of data. It slows things down if I do that too much. But where the most common mistakes are, when you run a batch of 20 to 40 kids every single semester through, using this you really get a good idea of how to make the code library better.

19:26 Michael Kennedy: Yeah, because you have a bunch of people that have no expectations of what to do correctly. So how do you help them fall into the pit of success and make the right thing the most obvious thing and whatnot, right?

19:37 Paul Craven: Right, it's one of the things I really like about, in creating a library, to iteratively be able to take people through the library and look over their shoulders while they're working on it is really valuable in improving that library. And also having it out on the internet where people that you can't see give you feedback, having both of those different types of feedback is really quite nice.

19:59 Michael Kennedy: Yeah, that's super interesting. I mean, some companies, they have usability labs for their developers. And they bring people in and then watch through mirrors and other ways at what they're doing. And in a sense, that's very, very rare for open source libraries, I would suspect. But in a sense, that's kind of what you're doing, right, just because you're teaching and walking around in the classroom, right?

20:18 Paul Craven: Exactly, and one of the big features of this particular library is a large set of examples. And over the last 12, 13 years I've been teaching video games, I got this library of different things that students have asked for. And so I created all these different code samples. And that's one of the things that helped, also, in creating the Arcade libraries. I knew all these different types of things that people wanted to do when they wanted to create 2D arcade games. And when I created the library, I needed to make sure that I supported all of those different items. And I had all that set of example code in PyGame, and then I basically had to make sure that I could do all of those same features in the Arcade library.

20:59 Michael Kennedy: That is really handy to have all those examples. So I guess we probably haven't done a great job of just defining exactly what Arcade is and its point, right? So Arcade is for building 2D platform-like or side scroller-like games with Python, right?

21:17 Paul Craven: Yeah, or top-down. But basically any type of 2D graphics, and that's what Arcade's really made to do. And it's made to do it so that people can get up and going simply and easily. It's not supposed to be a huge overhead or mentally taxing library to use.

21:34 Michael Kennedy: Yeah, could you create like a Tower Defense game?

21:36 Paul Craven: Yes, the best game that we've got, actually, that I am aware of that's been built in it is a Tower Defense game, which is pretty crazy game, actually. I wasted way more hours of playing that than I would admit to my student that wrote it, but.

21:48 Michael Kennedy: Is it online? Is it something people can check out?

21:51 Paul Craven: Yeah, actually. It's called Great Skeleton War. And there's a link to the GitHub repository on the Arcade Academy website that hosts the Arcade library.

22:02 Michael Kennedy: Okay, cool. Nice.

22:05 Paul Craven: Yeah, so, no, it creates great top-down, side scroller, animated, it is really oriented towards doing that type of work.

22:14 Michael Kennedy: Right, and it works cross-platform, obviously, with OpenGL and Python on MacOS, Windows, and Linux. Is there any option for mobile, or it's just those three at the moment?

22:23 Paul Craven: No option for mobile. Basically those are the three main platforms that are in use.

22:28 Michael Kennedy: Yeah, okay, cool. That's a totally reasonable thing, given what you're building. But I just wanted to check. So maybe give us a quick example of what the API feels like to write a super simple game. You've got a nice little example. And you even talked about how it doesn't even have to have functions or classes or anything like that.

22:49 Paul Craven: Right, if you wanted to do something really straightforward and just draw something to the screen, it's pretty darn straightforward. First off, you import the Arcade library, obviously. And then in the Arcade library is on open_window command. You just give it the dimensions of the window and a screen title. Then the next command you do is you set a background color. It has a set of colors you can choose from, or you can specify in a red, green, blue format. And the next, basically, as an outline, you've got a start_render and a finish_render command. All your drawing commands have to happen between start render and finish render.

23:27 Michael Kennedy: Does that map over to like GL swap buffer down below or something like that?

23:30 Paul Craven: Yeah, start render basically clears the screen, and then the finish render will actually swap the buffer in front.

23:36 Michael Kennedy: Okay, cool.

23:37 Paul Craven: Then you've got commands such as draw_circle, draw_circle_fill, draw_circle_outline, drawing a rectangle, drawing an arc. You can put bitmaps on the screen. All of these commands are actually slow to run. If you really wanted something high performance, you need to actually batch up these commands and then run a draw command. But to get started, you don't have to do that or really worry about that. When you get to more advanced programs, you can fill in with a batch type of program.

24:06 Michael Kennedy: Right, right, right.

24:07 Paul Craven: Basically, yeah, you just import Arcade, open a window, set a background, start_render, finish_render, plop a whole bunch of straightforward drawing commands in the middle of that, and that would be pretty darn close to a finished program, except the program would immediately end right after you did that. So the window would come up, flash on the screen, and then go away. So you do need to do an arcade.run, which will basically hold the window open on the screen until you hit the close button.

24:33 Michael Kennedy: Yeah, okay, cool.

24:34 Paul Craven: And yeah, you can draw a happy face or some sort of simple type of item in like 20 lines, 50 lines if you want to add a bunch of comments and appropriate blank space.

24:45 Michael Kennedy: Yeah, super nice. That sounds very straightforward. And like I had said, you could just put those commands straight into a .py file and then run it, right? You don't even need a function or a class or decorators or inheritance or any of that. So it's pretty approachable for people to get started with.

25:01 Paul Craven: Exactly. I usually have them create drawings like this and then move on to functions so that they learn to create functions that draw horses or pigs or whatever the heck it is they want to draw. And then they can put that into a function. And then that starts making more sense to them why they need functions. And then eventually we can start getting into classes and how to handle events.

25:26 Michael Kennedy: Yeah, I mean, this just sounds like a really fun way to get into programming. When I was taught, I was learning just basically data structures in Lisp. That was not as much, I got to tell you, it wasn't as much fun.

25:40 Paul Craven: Even if you're an experienced programmer, I prefer starting with really small, simple, straightforward programs. If I have to start with some new framework and it's going to be 50 files that are in XML and some other type of format, it's just a headache to get started and really figure out where to even begin. But if I can get started in a 20-line program, I can start iterating off of that and learn a framework a lot easier.

26:09 Michael Kennedy: I'm starting to use this term that Python is a full-spectrum language. And what I mean by that is it's really appropriate for super beginner folks, 'cause like, in this example, you don't even need functions. You don't even need to know what a function is. You just need to write these commands, and you're good. But it also has really rich concepts like classes and decorators and generators and whatnot. And it kind of grows all the way from simple programs to Instagram or whatever, right? I feel like your API kind of mirrors that a little bit, right? It has this super simple way where you can be productive with a very partial understanding of what's going on, but then you have richer types like windows, classes, and decorators and events that you could hook into and stuff.

26:52 Paul Craven: Exactly. Really what I was trying very hard with this particular package to be able to do, for somebody to get up and going easily with it and not a lot of effort but still have a lot of power if they want to take the time to do it.

27:06 Michael Kennedy: Yeah, it sounds like it's pretty good for teaching programming to people who are learning programming, but maybe even for kids. A lot of times people teach them kids. I saw some nice articles on using PyGame Zero to teach kids programming and stuff like that. What are your thoughts on that?

27:20 Paul Craven: Yeah, I think they're all good options, quite frankly. I like actually seeing a little bit of competition out in the landscape. So when I create items, I like to look at what other people are doing, Piglet, PyGame, PyGame Zero. And particularly in the whole open source type of movement, figure out, oh, is there a better way of doing this? And if there's only one solution, I think things can get kind of stagnant. So I think PyGame Zero and PyGame are still completely viable options. I mean, obviously I'm biased towards my library, 'cause who wouldn't be? But I like seeing the competition out there. And I do speed performance comparisons with my library and the other libraries and also how clean the code looks, and that's a nice way for me to make sure that this library's good, right?

28:14 Michael Kennedy: Yeah. Frame rates, what does it look like for a game on Arcade?

28:19 Paul Craven: Most of the games that people put together are usually 60 frames per second. Basically if you program it poorly, specifically if you draw items individually as opposed to lists, that's where people usually end up getting into problems, having the frame rates drop below 60. Arcade uses OpenGL, so basically as long as you load your sprites, your shapes, the items that you want into a list, I've had it be able to manage 400,000 sprites on the screen that aren't moving at the same time and still keep 60 frames per second. And I can get about 1500 to 2,000 moving sprites on the screen at the same time.

29:05 Michael Kennedy: Yeah, that's pretty awesome.

29:06 Paul Craven: Yeah, if you include collision, it takes a little bit more time. Going really into the deep on which one's faster, which one's not is really starting to get into the weeds, which I would absolutely love to do but might not be what everybody wants to do right now.

29:21 Michael Kennedy: Yeah, yeah, for sure. But maybe the main takeaway, it's pretty quick, right? You definitely get smooth frame rates and smooth behaviors and whatnot out of it these days using OpenGL.

29:32 Paul Craven: Yeah, I've got some speed comparisons comparing Arcade to PyGame, and basically when you keep adding sprites in the same list, particularly if they're not moving, with OpenGL and Arcade you can keep doing that, and it's like an order one operation to draw it. You load them to the graphics card. Once they're on the graphics card, you just tell the graphics card to draw them, and pow, they're back on the screen.

29:56 Michael Kennedy: Yeah, that's super interesting. I think that's one of the aspects of Python performance that's really interesting to think about here, because you're not actually, every time you say, here's a sprite and here are the things, I want you to draw it, it's not like Python is doing all this computation to make it happen. It's kind of just like, we've already loaded that stuff into the GPU memory. And we're just saying, hey, GPU, apply this transform to this thing over here, or this set of transforms to those things, or the whole viewport or whatever, right? It's sort of orchestrating what's happening with the scene, right, rather than it's actually drawing every little bit.

30:32 Paul Craven: Right. The graphics operations themselves are actually really quite fast. And they're pretty well offloaded for Python. So the Python does the high-level work and then offloads it onto the graphics card. And if you've done that right, then it doesn't matter quite so much what language you're working with. One of the items that I am working on right now is in actually moving the sprites and managing a large number of sprites, having them change where they are or detecting collisions between sprites. That is where you can see a bit of a speed difference. PyGame actually does pretty good with this 'cause it is not pure Python. It compiles a fair bit down to the C level. And the different objects, the sprites that you got on your screen are actually backed in a C program, so they can do native manipulation that way pretty quick. And the Arcade library doesn't do that, but I don't know if we'll end up doing that in the future. I've done a lot of experiments, and there's a fair speed improvement if you offload some of that stuff to the C level.

31:42 Michael Kennedy: Yeah, I can imagine that there's like a handful of things that would really benefit from that. Have you considered or experimented with Cython or something like that?

31:51 Paul Craven: I've thought about it. I've not had a chance to experiment with it. Goes back to the whole limited amount of time in a day, unfortunately.

31:57 Michael Kennedy: Yeah, well, it could be a cool project for one of your more advanced students, to tell them, okay, in this course, you're going to optimize this.

32:05 Paul Craven: I'd be really interested to know what it would do. I've never tried running it under Cython.

32:09 Michael Kennedy: Yeah, I mean, not the whole thing, necessarily, but just take like, do some profiling and grab the three slowest spots, or whatever, and just hit those functions with Cython, you know, for example.

32:18 Paul Craven: Right.

32:20 Michael Kennedy: This portion of Talk Python To Me is brought to you by Rollbar. Got a question for you. Have you been outsourcing your bug discovery to your users? Have you been making them send you bug reports? You know, there's two problems with that. You can't discover all the bugs this way. And some users don't bother reporting bugs at all. They just leave, sometimes forever. The best software teams practice proactive error monitoring. They detect all the errors in their production apps and services in real time and debug important errors in minutes or hours, sometimes before users even notice. Teams from companies like Twilio, Instacart, and CircleCI use Rollbar to do this. With Rollbar, you get a realtime feed of all the errors so you know exactly what's broken in production. And Rollbar automatically collects all the relevant data and metadata you need to debug the errors, so you don't have to sift through logs. If you aren't using Rollbar yet, they have a special offer for you, and it's really awesome. Sign up and install Rollbar at talkpython.fm/rollbar, and Rollbar will send you a $100 gift card to use at the Open Collective, where you can donate to any of the 900-plus projects listed under the Open Source Collective or to the Women Who Code organization. Get notified of errors in real time and make a difference in open source. Visit talkpython.fm/rollbar today. Let's talk a little bit about the API, just a little bit more before we move off of that. So on one end of the spectrum, we have open window, set background color, render, render, render, done, sort of not even a function. We talked about adding functions and classes. But maybe a more real application might create a class that derives from the Arcade.window, and then it has all these events, right, like an on draw, on key press, on mouse motion, viewport, all those kinds of things. You want to take us through how that might look?

34:07 Paul Craven: Precisely. Little more advanced, not a lot more advanced, but a little more advanced game will end up using classes. And one of the main ones is the window class, which works like a lot of classic window classes in other APIs, where you've got certain methods that you can override if you want to respond to keystrokes or button presses or window resizing. Any of that type of work can be done in your own custom window class.

34:40 Michael Kennedy: Yeah, one thing I like about that is it lets you avoid writing the event loop and dealing with all of that funkiness that maybe some of the libraries have to deal with.

34:51 Paul Craven: Yeah, that's one of the things that PyGame does that I really don't like, is that you basically have to create your own event loop, which is pretty, I don't know, 80s or 90s style anymore. And a lot of the libraries built on top of PyGame or PyGame-based try to hide that, or they create their own event loop on top of it, which, for obvious reasons, is not the best way of doing it. And there's a lot that happens in a good event loop for processing, for queuing up the events. And it's not really something that should probably be left to everyday users that don't need to dive into that.

35:32 Michael Kennedy: Yeah, so there's a pretty approachable way, but you still basically plug into the event loop, like the keyboard events and the draw events and whatnot.

35:39 Paul Craven: Exactly.

35:40 Michael Kennedy: Nice, so one of the things that I think is super tricky, so I used to work on 2D simulators with OpenGL a little bit and C++ and whatnot. And it was fun. I did that, I don't know, for a year or two, but not for a long time. But the actual job of creating the 3D thing and rendering it and doing all that is not super hard. But what is, at least to me, was super hard is, how do I get a realistic-looking thing on the screen? And in this context, this probably comes down mostly to sprites. How do I get little graphics that then represent the characters and the elements, an asteroid in an asteroid game, the little missile in a missile command or whatever, right? Having really good ones of those without a team of designers, that's a big difference between a good game and not so much a good game.

36:28 Paul Craven: Yeah, it just kind of shows you the value of good graphic artists, quite frankly. When I teach programming, though, a lot of students coming in, I'm not teaching graphic art. And I don't want them to spend a lot of time creating great graphic art, either. I typically will give, point students towards art work. A guy called Kenney, he's got a Kenney.nl website, K-E-N-N-E-Y dot N-L, and he creates a lot of open art that's freely available for use in games. And while it does have a particular style to it, it's a nice spot to start with. He's got thousands of different tiles and images that are 2D, and a nice spot for students to start with for doing graphics. And then, yeah, I kind of show them how to look up other graphics using Google Images or some other search engine and download and use. One of the things I really liked about Arcade, PyGame, it was a hassle because they would often download images, and the images would have a transparent background. But PyGame, by default, didn't support a transparent background. So you had to figure out a color that that mapped to and then tell it that this color is transparent. And there were so many headaches around that. The art was often different sized than they wanted. So maybe they wanted a 50 by 50 sprite, but the art that they downloaded was 200 by 200. And not all of them really knew how to use graphics programs to resize the art very well. And PyGame didn't do that resizing very easily. And that was such a hassle. That's also built into Arcade, to basically allow them to resize that on the fly. The transparency is built in. And it's just, the aspect of getting the art, downloading and using it, is a little bit easier for students doing it.

38:29 Michael Kennedy: Yeah, yeah, this is really cool. So the Kenney.nl stuff is really nice. I'm checking out the pixel vehicle pack, and if you wanted to create a Frogger type game, it's even got little characters with different jump stage animations on them and whatnot. It's, yeah, it's quite cool. So these come in like a big block, like one giant pixel picture of all of them. Is there a way to say, like, I want the third firetruck in this big picture full of firetrucks, or do you cut them out?

39:03 Paul Craven: Typically he also makes them available as individual images. And I found with people, it's been a lot easier for me to, rather than having them deal with the sprite sheet and try to figure out the coordinates of the sprite sheet to pull individual sprites out of that, to use the individual files.

39:20 Michael Kennedy: Sure.

39:21 Paul Craven: And that works pretty well.

39:24 Michael Kennedy: Yeah, then you load them into a sprite list, which is part of your API, right?

39:28 Paul Craven: Exactly. There's a sprite list API where basically you create the individual images that you want, you toss them into a sprite list, so you might have all the walls in a sprite list. You might have all the lava that you can't touch in a sprite list. You might have all the enemies in a sprite list. And then you can draw the sprites in one batch command. So you say, draw a wall, and pow, the walls are drawn. Basically, once they're on the graphics card, it's an order one operation. And then you can see, does the player collide with any wall? Does the player collide with any lava? Does the player collide with an enemy, those types of things. So the sprite list is pretty integral to the whole thing.

40:06 Michael Kennedy: Yeah, it definitely seems like it's pretty powerful. Super cool. Let's see, so all the stuff we talked about is really good for putting pictures on a screen, right? But there's the other part, I told you one of the things that I thought was hard about creating this type of stuff, like simulators and games and whatnot, is the pictures and the graphics, and in the 3D world the actual models, right, and understanding those. But there's also more to it. There's physics, there's collisions, there's sounds, there's editors and levels. Let's talk about some of those things. What comes in it? I know that there's some cool options for physics engines.

40:45 Paul Craven: Yeah, basically there's several levels. And as you progress, you can get more advanced. First off, there's a command just to see if one sprite collides with another sprite. That's the simplest. The second is I've got what's called a simple physics engine. And you can have one sprite, and it can have a velocity. And then you can have another list of sprites which basically act as walls that you can't move through. So it'll keep the player from moving through a wall, which is great for any sort of top-down game where you've got a player or the enemies moving around, and you don't want them moving through walls. There's a platformer one, where it adds gravity to the mix. And it works reasonably well for side-scrolling platformers. And it gives you the ability to jump. The last PyCon, I had somebody add in the ability to support double jumps and triple jumps or however many you want to select. And if you really want to go nuts, I've got example code. There's another library package called PyMunk, which adds full 2D physics to the whole thing.

41:51 Michael Kennedy: Yeah, I'm looking at it, it's pretty cool. The example has a little bike rolling into a stack of bricks, and the bricks all obviously come apart and fall down, well, like bricks would if you hit them.

42:03 Paul Craven: Yeah, it's cool. You can add springs and all sorts of things. And it is a really neat library to work with. It is not easy to get started with, particularly if you want to try to make a platformer out of 2D physics. I spent a fair bit of time with that. And I've got an example on the website, but it is not particularly easy.

42:23 Michael Kennedy: Yeah, yeah, but so I guess that's like the pro version, if you want to really make a super legit, realistic game.

42:29 Paul Craven: Yes, precisely.

42:30 Michael Kennedy: Yeah, so we talked about sprites, and that sounds like that's basically built in. Arcade is 2D only, right? There's no 3D aspect?

42:37 Paul Craven: Correct.

42:38 Michael Kennedy: Any 3D you want to have, you kind of have to simulate with your sprites or scaling or something, right?

42:44 Paul Craven: Yeah, you'd have to do like a 2.5, or isometric, even, is really kind of complex to do. And there's not really built, there's some built-in support for drawing an isometric map, but figuring out where the walls are and movement is a non-trivial problem that's not in the library right now.

43:02 Michael Kennedy: Yeah, yeah, of course. So another type of game that seems like would be pretty appropriate, so you talked about the platformers. What about side scrollers? Like, I don't really care about it, but Flappy Bird or Angry Birds or something like that?

43:16 Paul Craven: Yeah, I've had people do Angry Bird. I had people do Flappy Bird with my head. That was really weird when I got that program to grade.

43:26 Michael Kennedy: Yeah, I can imagine. Hold still, I got to take a picture of you. Why? Nevermind.

43:29 Paul Craven: They took it off the website, so, yeah. I love my job in that basically for finals, I just sit here and go through and grade students' video games. So it's a pretty cool job to get. And yeah, sometimes you're kind of surprised with what they end up coming up with. And Flappy Bird as my head was definitely one of them. But I've also had people do Minesweeper, word search games, Sudoku.

43:56 Michael Kennedy: Yeah, Minesweeper sounds fun. A mastermind would be another simple and fun one.

44:00 Paul Craven: Yeah, so they don't have to be necessarily, they're sprite-type games, but they could be more board games or puzzle games, that type of thing.

44:08 Michael Kennedy: Yeah, sure, okay. That sounds cool. Yeah, you probably don't need physics in Minesweeper. But still.

44:14 Paul Craven: No, but it is an interesting aspect, because there's a nice spot to show students recursion, 'cause a lot of students don't see where recursion is useful. And it is useful in the sweep feature of Minesweeper.

44:26 Michael Kennedy: Right, of course. Yeah, it's like a tree, sort of thing.

44:29 Paul Craven: Yeah, you basically just recursively click around where they clicked, and it works pretty well.

44:34 Michael Kennedy: Okay, nice, til you run out of spots that are empty of whatever.

44:38 Paul Craven: Bingo.

44:39 Michael Kennedy: Yup, okay, so one thing that would be really nice, and I guess let's talk about the examples first, and then I'll talk about this. So something that surprised me a little bit, I saw some of the articles that you had written, like I think the one about Asteroid Smasher, right?

44:54 Paul Craven: Mm hm.

44:55 Michael Kennedy: And on there, I saw that you can basically, once you pip install Arcade, it comes with a bunch of examples already. And I can say, like, python -m arcade.examples., pick something like Asteroid Smasher. And actually if I go to the REPL and I import arcade.examples and say help arcade.examples, there's like 30 examples in there.

45:15 Paul Craven: Actually, I think there's about 100 examples total on the examples site on the documentation. Need to sort of recount those. But anyway, to me the example, having examples to base learning off of was really important, because a lot of the feedback I get from students that are out in the workforce are saying, hey, I haven't had a chance to ever work with and read other code. That's a skill. I've written my own code, but when I get out in the workforce, most of what my job is is reading other people's code and making modifications to it.

45:52 Michael Kennedy: Right, and it's usually super complicated, 'cause it's been polished for three years.

45:57 Paul Craven: Yeah, exactly.

45:58 Michael Kennedy: And it's hard to read, right? Yeah.

46:00 Paul Craven: And this gives students a way of learning to read code. Plus, I, myself, quite frankly just learn things better by seeing examples. And there are certain people that learn better that way, rather than having things presented to them in sort of a linear format. And the examples, I've tried to come up with so many different examples so that all of the requests that I've gotten over time when people want to learn something, know how to do something, I create an example for it. And a lot of my answers to emails anymore on, like, how do you do this are just, oh, look, here's an example on exactly how to do it.

46:39 Michael Kennedy: Yeah, that's a nice way to do it.

46:41 Paul Craven: Yeah, if there's not an example, then, bang, now I got a new idea for an example.

46:45 Michael Kennedy: Yeah, so I'll just read through some of what you got when you do that help statement. So you've got Asteroid Smasher, which is basically Asteroids. It's pretty nice, a limited version of that. You've got drawing text. You've got full screen example, which is pretty nice. You've got some loops. You got a particle stress, fireworks. The fireworks one is kind of cute, bunch of stuff with sprites, moving them around, sprite CSV map, which is cool, and then rooms, and yeah, there's a lot of stuff. There's a Tetris.

47:14 Paul Craven: Yeah, the Tetris is actually one of the newer ones I've got in there. Also have some procedural generation, showing how to generate mazes a couple different ways, different rooms. Some of the other items that I've really been working on is to also support basically using a program called a Tiled Map Editor so that you can actually just design a level or a layout in a different program visually and then load it up really easily in your own program.

47:43 Michael Kennedy: Yeah, that's nice. Is that, that's working, and is that like, is that all, what is that other program people use?

47:49 Paul Craven: The Tiled Map Editor, it is a really nice program that is used actually by a lot of different languages. But it creates a TMX file and tile sets so that you can take regularly sized tiles, you can visually lay them out. There's a lot of different options that way. You can even animate tiles. And then I've gotten an older version of loading those tiles, function that does that, and we're actually creating a new, more powerful version of that. You can basically animate the tiles. It'll automatically do the animations. You can draw hit boxes around tiles. So not every tile you can just assume is a rectangle that you hit, but you might have a ramp or like a coin. You're going to have a circle for a hit box. And you can just draw that in the Tiled Map Editor. And then you can import it with just a few commands in the Arcade library.

48:50 Michael Kennedy: That is cool. Yeah, I found it at MapEditor.org. And it's a cute C++ app, open source on GitHub. It looks really nice, actually.

48:59 Paul Craven: Yeah, it's a nice alternative to, if you want to do 2D games, you could pair that with Python and Arcade and run through quite a few different levels and code that way.

49:15 Michael Kennedy: Yeah, that's interesting. And there's an example of loading the output from this thing? Which is that example?

49:21 Paul Craven: Example of loading what?

49:22 Michael Kennedy: Of loading the output from the Tiled Map Editor.

49:25 Paul Craven: Oh, right. So basically I've got one example for that, for loading for the Tiled Map Editor. And then I also did a whole presentation on basically doing that. Basically if you go to arcade.academy, at the front of that website, it's got a tutorial that leads you from just the beginning. It's a platformer tutorial, leads you just from the beginning of opening a window, adding sprites, and then eventually using the map editor to lay out the sprites. And in the next version of Arcade, it'll actually have an updated version that'll support animation, have a better support for hit boxes and other, some of the more advanced features of the Tiled Map Editor.

50:06 Michael Kennedy: That's super cool. Yeah, the one that I found was Sprite-Tiled Map, yes, that map is singular. That's really nice, 'cause like I was saying, that's one of the parts of, like, hey, I built this thing that shows stuff on the screen, and it draws these sprites. Wait, how do I create levels? How do I create graphics? All that stuff is just, it seems like it's not going to be a problem, maybe, at first. But it really is.

50:30 Paul Craven: Yeah, and if you want to do the visual layout and not program exactly where every block goes, yeah, having some sort of graphical editor, and the Tiled Map Editor's just beautiful for it. It really is. Guy's put a ton of work into it. And you do not have to do a whole lot of work to load that using the Arcade library.

50:48 Michael Kennedy: Yeah, that's really great. Definitely think that's super valuable to have. You know, one thing that I was thinking while you were talking, it probably doesn't exist. It might be cool if it were to exist. Maybe somebody out there could create it if they wanted. So we talked about the sprites over on Kenney.nl. We talked about the Tiled Map Editor. It'd be fun if there was like, some starter sort of getting started little library so you can just pip install it, and you've got like 500 sprites that you can work with and like 10 levels that are already built that you can just like, okay, I'm going to just start from this and go, like, import this level and run with it. And here are some sounds, or it's like these little building blocks for people to sort of quick start up with. Does anything like that exist?

51:37 Paul Craven: Not that I'm aware of, but that would actually be a really great idea.

51:41 Michael Kennedy: Yeah, so instead of having to start from scratch, you're kind of like, well, these are the 500 sprites. If you pip install this thing, you just have it, you know? You could go from there. That'd be cool.

51:52 Paul Craven: Yeah, it would. And then eventually, if you're into creating the art yourself, once you've got your placeholder art in there, you can get the mechanics of the game going and then just start replacing the art piece by piece.

52:03 Michael Kennedy: Yeah, 'cause it seems like the art is the last thing that you want to put your energy into, you know?

52:08 Paul Craven: Right, because until you get the basic mechanics down, you don't really know what art you need or if the art is going to match what you actually need for mechanics.

52:18 Michael Kennedy: Exactly, or even if the game idea, the way you first thought of it makes any sense, you'll play around with some little sample data and then go, oh, actually, really, that's close, but this is really what I wanted. You don't want to spend a ton of time on art for that, right, to get it up and running.

52:31 Paul Craven: Exactly.

52:32 Michael Kennedy: Anyway, that would be cool. Maybe somebody out there is inspired to create that. That'd be great.

52:38 Paul Craven: I'd love to see something like that.

52:39 Michael Kennedy: Yeah, cool. So I guess we can maybe round out our conversation here by assuming we built this beautiful game. It's a cool side scroller, whatever, Angry Birds, who knows what it is. We want to send it out to the world, put it in the Mac App store, put it in the Windows store, who knows, something like this. One of the challenges of Python is shipping your program to other people who maybe don't have Python installed or the right dependencies or things like that, right?

53:07 Paul Craven: Yeah, it is difficult. And I don't have a perfect answer for that, quite frankly. The aspect of the sound libraries and the little libraries that go with the Arcade library, it's difficult to package and get that packaging to work well. Python itself doesn't have a whole lot of great options. There's the whole Pyme project. There's PyInstaller. You've got like PyOxidizer and some other packages. I would love to see something good and straightforward for being able to package games that you've put together using Arcade. I'm not there yet where I can recommend a specific option. That's been one of the spots that I'd love to see Python as a language have some improvements on.

53:55 Michael Kennedy: I definitely see it as one of the shortcomings. It's great to see that PyOxidizer's coming along, right? This is the newest of the packaging tools. And I think it does take other libraries along with, I'm not entirely sure. It certainly takes other Python libraries, but FFmpeg, for example, does it take...

54:13 Paul Craven: Yes.

54:14 Michael Kennedy: That, right, that I'm not sure about. But I think if you could package your Python code and its dependencies as a binary, you could use the other packaging mechanisms to solve the other dependencies, right? Like in Windows, you have MSI installers that take along the other dependencies and will put them in the same directory. Or you could have your .app file in Mac. You just put it into a disk image and drag it over, right? That's basically a directory. I suspect you could make it work like that.

54:40 Paul Craven: I'd love to get to a spot where somebody who's learning to program or is more along the hobbyist side doesn't have to spend so much time trying to figure out all these different packagers. And there can just be one simple option of them to create an installer and have that run on a particular platform, because it's pretty cool to learn how to program. And then you get done with learning how to program in college or high school or whatnot, and you want to take your game and show it off to your friends. But then you can only run it on one computer.

55:15 Michael Kennedy: Yeah, exactly. It's super frustrating. I mean, my dream of the future would be something like, I go to the command line. I type python3 -m package or bundle or something and a directory, and then I get three outputs, Linux, Windows, Mac.

55:35 Paul Craven: Yes.

55:36 Michael Kennedy: And there's a .exe, there's a .app, there's a Linux binary, and that's it. It just runs.

55:43 Paul Craven: Yeah, yes, I would love to see something like that.

55:45 Michael Kennedy: We're not in that world. Maybe that's 2022. I don't know when that world exists. But I would love for it to exist. And then I think that would really make a big difference, especially on things like this.

55:56 Paul Craven: Yeah, for me, on the Arcade library, this is a big hangup. The sound support is another one that I get a lot of headaches on in trying to make sure I do support.

56:07 Michael Kennedy: Yeah, we haven't talked about sound yet. So can we have sound? How does that work?

56:11 Paul Craven: Yeah, you can have sound. It's basically, it's one that I keep trying to change. And I always end up finding somebody that has some different configuration that it doesn't work well with. Right now I'm using FFmpeg. PyGame uses AVN, which is a really old binary library that hasn't been updated in, I don't know, since like 2008 or something. I can't remember. But nobody supports it anymore. And so I tried to work with FFmpeg. But then with Windows, you need it installed somewhere. So you have to have the binary installed and downloaded. And Mac's a little bit different. With Linux, it should already be installed. So somehow you need to find it on Linux and then create a link to it. But you can't really directly create a link, 'cause then you get permissioning errors. So you have to remember where the heck that is. At any rate, sound is a headache. And it's very kludgy right now. And I'm constantly trying to fine-tune or find little exceptions where it's breaking down. But you can play MP3s and OGGs and WAV files. I generally push people to do WAV files for shorter sound effects. I would love better sound support so you could easily create a backing track of music to your game and then when the song is done, you could get a callback and queue up the next song. Stuff like that really should be a lot easier than it is. But that's one of my top headaches, that and distribution.

57:41 Michael Kennedy: Okay, well, people who have ideas, I guess they can send them along. I don't, for sound, I have no ideas. I don't know anything about sound other than I agree that it's kind of tricky.

57:50 Paul Craven: Yeah, I've looked into so many different libraries with that where people have suggested, oh, well, you should do this. And then I take a look at it, and there's always some rhyme or reason where it doesn't work particularly well. But I would love a solution for that, by any means. If anybody knows one, let me know, please.

58:06 Michael Kennedy: Well, it sounds like you have at least basic support for sound, which is pretty critical.

58:11 Paul Craven: Yes, it makes it a lot more immersive.

58:13 Michael Kennedy: Yeah, absolutely. Maybe even more so than graphics, right? There was a really interesting game on the iPad that was like this retro eight-bit game. But it had brilliant music that was so immersive. And actually, it was quite interesting. I forgot what it's called, but it was fun to play. And it was because of the music.

58:31 Paul Craven: Yeah, I agree. And I told my students the same thing. You got to get some sort of sound effects on there.

58:37 Michael Kennedy: Yeah, for sure.

58:38 Paul Craven: If you're jumping or you hit an enemy or the game over, it's just a lot better if there's a sound effect with it. Mind you, as soon as I tell students how to do sounds, there is no shortage of flatulence coming out of the speakers in the lab that day.

58:52 Michael Kennedy: Oh boy. Do you have a good place for sound effects, like the audio equivalent of Kenney.nl?

58:58 Paul Craven: Kenney.nl actually has some sound effects. So I often ship that. OpenGameArt is another website that's pretty good for finding both art and sound effects. A lot of sound effect websites ask you to download bad software to play sounds, however. So I really have to caution students, if they're going out and trying to find sound effects, that's a great way to find malware.

59:24 Michael Kennedy: Yeah, sound should never require an install.

59:27 Paul Craven: Exactly. And some sites that I used to like actually have sort of switched over to requiring some sort of install. And therefore, automatic steer clear of.

59:39 Michael Kennedy: That is super shady, that's crazy. Alright, well, I think we've pretty much covered Arcade. That sounds like a really nice project that you built, and hopefully people get a chance to check it out.

59:48 Paul Craven: All right, thank you very much for having me on.

59:50 Michael Kennedy: Absolutely, before I let you out of here, though, there's two more questions to ask. So if you're going to write some Python code, what editor do you use?

59:57 Paul Craven: Oh, great question. In order, I will typically do PyCharm first. And I really like PyCharm. Sublime would be number two for a quick editor to work with. And then Vim if I'm on any sort of Linux type of environment.

01:00:15 Michael Kennedy: Yeah, all right, sounds like a good set to me. And then notable PyPI package. I'll go ahead and throw out there pip install arcade for you. But maybe something people don't necessarily know about but a shout out, this is really great. People should know about X.

01:00:28 Paul Craven: Oh, good question. Other than standard packages, I do like Piglet, as far as building stuff off of it for graphics if you want more of the underlying items. ModernGL, if you want to write your own OpenGL code, ModernGL is really a pretty good package that's actively supported online, as well.

01:00:50 Michael Kennedy: Oh, that's interesting. I've never used that, so, yeah.

01:00:54 Paul Craven: Yeah, there's a few different OpenGL packages. Piglet's bindings I really like, and ModernGL are my two favorites.

01:01:03 Michael Kennedy: Okay, yeah, cool. So if you know the OpenGL API, this is it but in Python rather than C++.

01:01:10 Paul Craven: Right.

01:01:11 Michael Kennedy: Yeah, cool, okay. Nice, that's a good one, thanks. See, this is the purpose of this little section, 'cause we all learn about these things that we don't know. Alright, so final call to action. People are excited with Arcade. How do they get started? How do they contribute, things like that.

01:01:24 Paul Craven: There's a website, arcade.academy. It's got links if you want to download, try it out. If you want to contribute to it, which I would absolutely love, there's links on it to GitHub. And you can do pull requests. There's a Discord available, too. If you want to shoot me an email, I can get you hooked up with Discord for the development on that. If you're learning to program, there's also learn.arcade.academy that has a whole curriculum that I use for first semester programming. And yeah, that's basically how to get started.

01:02:00 Michael Kennedy: The learn.academy, that's great. It's got some, basically walks you through all the different things that you do for the course, right?

01:02:05 Paul Craven: Yeah, learn.arcade.academy.

01:02:09 Michael Kennedy: Yup, I'll put it in the show notes.

01:02:10 Paul Craven: People can click it. There we go. Alright, well, thank you so much for being here. It was great to chat with you.

01:02:16 Michael Kennedy: Yes, thank you very much.

01:02:16 Paul Craven: You bet, bye. This has been another episode of Talk Python To Me. Our guest on this episode was Paul Craven, and it's been brought to you by Indeed and Rollbar. With Indeed Prime, one application puts you in front of hundreds of companies like PayPal and VRBO in over 90 cities. Get started at talkpython.fm/indeed. Rollbar takes the pain out of errors. They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed, until users complain, of course. Track a ridiculous number of errors for free as Talk Python To Me listeners at talkpython.fm/rollbar. Want to level up your Python? If you're just getting started, try my Python Jumpstart By Building 10 Apps course. Or if you're looking for something more advanced, check out our new Async course that digs into all the different types of async programming you can do in Python. And of course if you're interested in more than one of these, be sure to check out our Everything Bundle. It's like a subscription that never expires. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.