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 at 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.
Hey, great to be here.
Thanks for having me, Michael.
Yeah, it's great to talk to you again.
We got a chance to meet each other at the creator's booth part of the PyCharm booth at PyCon.
That was fun.
Yeah, I enjoy PyCon a lot.
Yeah, so did I.
I call it my geek holiday.
In August, I'm going to go on holiday with my family, but in May, I went on the holiday with my friends and my geek friends.
It was great.
Thankfully, it's the only conference I go to, and I look forward to it every year.
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 talking to you about that.
Yeah, it's a project I'm really passionate about.
Yeah, I can tell.
So before we get to that, though, let's start with your story.
How did you get into programming and then Python?
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 All, 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.
And once you had the game in there, you could start modifying it and customizing it the way you wanted.
I just absolutely love that as a way of learning to program.
And that's how I introduce 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.
Yeah, absolutely.
I definitely think that that's an interesting angle to help people get more engaged.
So that's basic was the sort of entry point.
But where do you learn about Python?
I had a student actually present it.
We were teaching programming in Java, which is a terrible language to teach programming in.
It was the main way to do it for most schools for a long time.
Oh, it was a step backwards from like Pascal.
And that's how we were teaching it.
And he gave a presentation on Python.
Wasn't too interested in it at first because 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 that 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.
Yeah, absolutely.
It was all about Java.
When was this?
What time?
What year?
About?
I would guess it'd be about 11, 12 years ago now.
Yeah.
Okay.
Interesting.
So Python was not nearly as popular and clearly the right choice as it is today, I guess.
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.
And we started introducing it, you know, just a few weeks at first and then, you know, eventually moved on to the entire semester.
So our first semester is 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.
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 like self-taught, I mean like even in like universities and stuff, I think it's kind of broken.
I think it's taught with an expectation of extreme delayed gratification.
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 you all these things.
So 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's just, it's crazy.
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 sometime 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.
Yeah, exactly.
So I definitely like that you're starting with something that gets them to like 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 like, okay, if I go through this, the payoff is really big or here's how I'll use it or whatever.
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.
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 like 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.
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 like 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.
Right, right.
If the horn points down, that's not okay.
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.
Maybe give us some examples of the types of things that you're teaching them there with games.
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 leads itself to, oh, hey, wow, there's a solution for that.
Let's introduce loops.
Exactly.
Yeah, because it's really painful to write 50 little fence objects and move them around.
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 then and call that function to draw a snowman here, here, and here, rather than just repeating the code over and over again.
Yeah, sure.
I do like that you can start in this really simple mode, kind of like the print of the world side of things.
You don't have to have all the extra stuff, but you do have a pretty rich API, which do you want to talk about and get into.
But maybe before we really dig into even to arcade, let's just kind of set the landscape for everybody.
You know, not everybody is creating games or maybe more like me.
They've messed with like creating games, but it was like 15 years ago and they haven't really done much since then.
Right.
So what are some of the options for building games?
You know, what's the spectrum of what we could do?
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.
Yeah.
And a lot of times that means working like in C++, right?
Like with Unreal or some of those other real game engines or Unity is C# or things like that, right?
Right.
Unity can do 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 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, you know, off time.
Right. Well, so that makes certainly makes sense for Python and then like even maybe a simple API on top of that.
Right. So, you know, you're not going to drop into like native OpenGL and C++ and say, we're going to teach you about data structures because like 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.
Not necessarily friendly either.
No, no, no, not so much.
So in the Python world, I had heard of Pygame.
That's been around for quite a while.
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.
Yeah, Piglet, a few other ones, Coco's or 2D, 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.
Isn't that super frustrating when you're like working with this project, you love the project, you put a lot of energy into it.
You go so far as like 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, like that is really not the best feeling.
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 try to do my own development because 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 SDL 2 version of the library, which I also tried working with and didn't much care for.
The underpinnings on 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.
Yeah.
And you get all the benefits of like high end modern graphics cards, graphics, GPU accelerated stuff and all that.
Right.
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.
Because when I teach, there's always these little warts you have to sort of tell the students about.
And every hour you spend telling a student, oh, well, that coordinate system that you learned,
well, it's different in computers because zero zero is in the upper left instead of the lower left.
Or set mode is in order to open a window, you use a command called set mode.
I know it's called set mode, but you really don't want me to get into that.
And, oh, you want to make a football and rotating ellipse?
Yeah, sorry, you can't do that.
You start getting over these and you come up with a list of them over time.
And it's just, gosh, I think I could do something better, quite frankly.
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?
Yeah, basically I set out to do that.
A lot of false starts, a lot of attempts on different backends.
And so I got a fair bit of time into figuring out exactly how 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 the internals.
So when a programmer is more willing to dive into the internals, Piglet's not a bad option.
Is there like an escape hatch in your API to like drop down to those internals?
Or is it like take it or leave it?
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.
Yeah, just directly work it.
Yeah, just start working with...
Yeah, it's not really something separate.
Yeah, okay.
The Piglet has their own system for managing sprites, which we can talk about in a bit.
I really just use them for doing OpenGL calls and Windows event management.
Okay, so there's not like a deep integration, like multi-layer thing.
It's more just like, just take what they built and go with that.
Right.
For the few things you need.
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.
Yeah, there's always that leaky abstraction or...
Exactly.
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 like Python 3 native.
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.
Right.
We expected a number and you're passing a string.
That's probably not okay.
Something like this.
Yeah.
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.
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.
It is a pain.
I'm not going to make a lot.
And well, I mean, until like a year ago, Ubuntu had 3.5 a year and a half.
Not super long.
Right.
Like that's.
Right.
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.
Like it's 3.6 now, but 3.7 is out.
Yeah.
I don't know their exact release schedule, but you know, 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 like changing behaviors or anything?
Like that?
Or is it just there to help students be more accurate?
Really just help 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.
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 like make the most, the right
thing, the most obvious thing and whatnot.
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 and improving that library.
And the 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.
Yeah.
That's super interesting.
I mean, some companies, they have like usability labs for their developers and they bring people
in and then like watch through mirrors and other ways of what they're doing.
And in a sense, like that's, 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?
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 with video games.
I got this library of different things that students have asked for.
And so I create all these different code samples and make sure.
And that's one of the things that helped also in creating the arcade libraries.
I had, I knew all these different types of things that people wanted to do and they wanted
to create 2D arcade games.
And 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.
That is really handy to have all those examples.
So I guess, you know, we probably haven't done a great job of just like defining exactly
what arcade is and its point, right?
So it's arcade is for building 2D platform-like or side-scroller-like games with Python, right?
Yeah, or top-down.
But basically any type of 2D graphics.
And that's what arcade is 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.
Yeah.
Could you create like a tower defense game?
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 a pretty crazy game actually.
I've wasted way more hours of playing that than I would admit to my student that wrote it.
Is it online?
Is it something people can check out?
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.
Yeah, nice.
Yeah.
So no, it creates great top-down, side-scroller, animated.
It is really oriented towards doing that type of work.
And it works on cross-platform, obviously, with OpenGL and Python on Mac, OS, Windows, and Linux.
Is there any option for mobile or it's just a three at the moment?
No option for mobile.
Basically, those are the three main platforms that are in use.
Yeah.
Okay, cool.
I mean, that's a totally reasonable thing, given what you're building, but I just want to check.
So maybe give us a quick example of what the API feels like to write like a super simple
game.
You've got like a nice little example.
And you even talked about how it doesn't even have to have functions or classes or anything
like that.
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 an 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.
Does that map over to like GL swap buffer down below or something like that?
Yeah.
Start render basically clears the screen and then the finish render will actually swap the
buffer in front.
Okay, cool.
Then you've got commands such as draw a circle, draw a circle, fill, draw a circle outline,
draw in 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 the batch type of program.
Right, right, right.
Basically, yeah, you just import arcade, open a window, set a background, start render,
finish render, pop 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.
Yeah, okay, cool.
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 in appropriate blank space.
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.
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 that 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.
Yeah.
I mean, this just sounds like a really fun way to get into programming.
You know, when I was taught, I was like learning just basically data structures in Lisp.
Yeah.
And that was not as much fun.
I got to tell you, it wasn't as much fun.
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.
I'm starting to use this term that Python is a full spectrum language.
And what I mean by that is like, it's really appropriate for super beginner folks.
Cause like this example, you don't even need functions.
Like you don't even need to know what a function is.
You just need to like 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 like simple programs to Instagram or whatever.
Right.
I feel like your API kind of mirrors that a little bit, right?
Like 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 can
hook into and stuff.
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.
Yeah.
It sounds like it's pretty good for teaching programming to people who are learning programming,
but maybe even for like kids.
I mean, 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?
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 because like, 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 is good, right?
Yeah.
Frame rates?
Like, what does it look like for a game on arcade?
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 1,500 to 2,000 moving sprites on the screen at the same time.
Yeah, that's pretty awesome.
Yeah.
If you include collision, it takes a little bit more time.
So 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.
Yeah, yeah, for sure.
But it's maybe the main takeaway is it's pretty quick, right?
You definitely get like smooth frame rates and smooth behaviors and whatnot out of it these days
using OpenGL.
Yeah, I've got some speed comparisons comparing arcade to Pi game.
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 screen.
Yeah, that's super interesting.
And 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 the set of
transforms to those things or the whole viewport or whatever, right?
Like it's sort of orchestrating what's happening with the scene, right?
Rather than it's actually like drawing every little bit.
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 because it is not pure Python.
Python, it compiles a fair bit down to the C level and the different objects, the sprites
that you've got on your screen are actually backed in the 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.
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?
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.
Yeah, well, it could be a cool project for one of your more advanced students to tell them
like, okay, in this course, you're going to optimize this.
I'd be really interested to know what it would do.
I've never tried running it under Cython.
Yeah, I mean, not the whole thing necessarily, but just take like, you know, do some profiling
and grab like the three slowest spots or whatever and just hit those functions with Cython, you
know, for example.
Right.
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 real-time 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 like 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 like how that might look?
Precisely. A 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.
Yeah. One thing I like about that is it lets you avoid like writing the event loop and dealing with
all of that funkiness that maybe some of the libraries have to deal with.
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 that build 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, it's 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.
Yeah.
So you still basically plug into the event loop, like the keyboard events and the draw events and whatnot.
Exactly.
Nice. So one of the things that I think is super tricky. So, you know, I used to work on 3D simulators at the 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 like, 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, you know, an asteroid in an asteroid game, a little missile in like a missile command or, you know, whatever, right?
Having really good ones of those without a team of designers, like that's like a big difference between a good game and not so much a good game.
Yeah. It just kind of shows you the value of good graphic artists, quite frankly.
Yeah.
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 artwork. A guy called Kenny, he's got a Kenny.nl website, K-E-N-N-E-Y.nl.
And he creates a lot of open art that's freely available for use in games. And while it doesn't 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 like Google images or some other search engine and download and use.
One of the things I really liked about Arcade, Pi Game, it was a hassle because they would often download images and the images would have a transparent background.
But Pi Game, 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.
Yeah.
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 Pi Game 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 that.
Yeah, this is really cool. So like the Kenny and Elf stuff is really nice.
Like I'm checking out the Pixel Vehicle Pack. And if you wanted to create like a like a Frogger type game, it's even got little like characters with jumping different jump stage animations on them and whatnot.
Yeah, it's quite cool. So these come in as like a big block, like one giant pixel picture of all of them.
Is there a way to say like, I want the third fire truck in this big picture full of fire trucks? Or do you cut them out?
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 a 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.
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 a player collide with any lava? Does a player collide with an enemy? Those types of things. So the sprite list is pretty integral to the whole thing.
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 3D world, like 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 like editors and levels. Like, let's talk about some of those things. What comes in it? I know that there's some cool options for physics engines.
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 as 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.
Yeah.
And if you really want to go nuts, I've got example code. There's another library package called PyMonk, which adds full 2D physics to the whole thing.
I'm looking at it. It's pretty cool. Like the example has a little bike rolling into like a stack of bricks and the bricks all like, you know, obviously come apart and fall down like, well, like bricks would if you hit them.
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.
It's I spent a fair bit of time on that. I've got an example on the website, but it is not particularly easy.
Yeah. Yeah. But I guess that's like the pro version if you want to like really make a super legit realistic game.
Yes, precisely.
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.
Correct.
Any 3D you want to have, like you kind of have to simulate with like your sprites or scaling or something, right?
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.
Yeah, yeah, of course. So another type of game that seems like would be pretty appropriate. So you talked about the platformers. What about like side scrollers? Like I don't really care about it, but Flappy Bird or Angry Birds or something like that.
Yeah, I've had people do Angry Birds. I have people do Flappy Bird with my head. That was really weird when I got that program to grade.
I can imagine. Hold still, I got to take a picture of you. Why? Never mind.
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 pretty cool job to get. And yeah, sometimes you're kind of surprised with what they end up coming up with.
And Flappy Bird with my head was definitely one of them. But I've also had people do Minesweeper, Word Search Games, Sudoku.
Yeah, Minesweeper sounds fun. A Mastermind would be another simple and fun one.
Yeah, so they don't have to be necessarily what I consider sprite type games, but they could be more board games or puzzle games, that type of thing.
Yeah, sure. Okay, that sounds cool. Yeah, you probably don't need physics in Minesweeper, but still.
No, but it is an interesting aspect because it's a nice spot to show students recursion because a lot of students don't see where recursion is useful. And it is useful in the sweep feature of Minesweeper.
Right, of course. Yeah, it's like a tree sort of thing.
Yeah, you basically just recursively click around where they clicked and it works pretty well.
Okay, nice. So you run out of spots that are empty or whatever.
You can go.
Yeah, 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 you had written, like I think the one about Asteroid Smasher, right?
Mm-hmm.
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.
Actually, I think there's about 100 examples total on the example site on the documentation.
I 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 other and read other code.
That's a skill.
I've written my own code.
But when I get on the workforce, most of what my job is, is reading other people's code and making modifications to it.
Right.
And it's usually super complicated because it's been polished for three years.
Yeah, exactly.
And it's hard to read, right?
Yeah.
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.
Yeah.
That's a nice way to do it.
Yeah.
If there's not an example, then bang, now I got a new idea for an example.
Yeah.
So I'll just read through some of what you got when you do that help statement.
So you've got like 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've got like a particle stress.
Fireworks.
The fireworks one is kind of cute.
Bunch of stuff with Sprite.
Moving them around.
Sprite CSV map, which is cool.
And then rooms.
And yeah, there's a lot of stuff in there.
There's a Tetris.
Yeah.
The Tetris is actually one of the newer ones that 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 the 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.
Yeah, that's nice.
Is that that's working?
And is that like, is that all?
What is that other program people use?
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 as a lot of different options that way.
You can even animate tiles.
And then I've got 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 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.
That is cool.
Yeah, I found it at mapeditor.org.
And it's a cute C++ app on open source on GitHub.
And yeah, it looks really nice, actually.
Yeah, it's a nice alternative to if you want to do 2D games, you could pair that with a, you
know, with Python and arcade and run through quite a few different levels and code that way.
Yeah, that's interesting.
And there's an example of loading the output from this thing.
Which is that example?
Example of loading what?
Of loading the output from the Tiled Map Editor.
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.
It leads you just from the beginning of opening the 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 hitboxes, and other, some of the more advanced features of the Tiled
Map Editor.
That's super cool.
Yeah, the one that I found was Sprite Tiled Maps.
Yes, that map, singular.
That's it.
That's really nice.
Because like I was saying, like, 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?
Like, all that stuff is just, you know, it seems like it's not going to be a problem maybe
at first, but it really is.
Yeah.
And if you want to do the visual layout and not program exactly where every block goes,
having some sort of graphical editor, and the Tiled Map Editor is just beautiful for it.
It really is.
The guys 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.
Yeah, that's really great.
Definitely think that's super valuable to have.
You know, one thing that I was thinking while you're 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 kinney.nl.
We talked about the Tiled Map Editor.
It would be fun if there was, like, some starter, sort of getting started, like, a little library.
So you can just pip install it, and you've got, you know, 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, you know, like, import this level and run with it.
And you hear some sounds or, like, these little building blocks for people to, like, sort of quick start up with them.
Does anything like that exist?
Not that I am aware of, but that would actually be a really great idea.
Yeah.
So instead of having to, like, start from scratch, you know, you're kind of like, well, these are, like, the 500 sprites.
If you pip install this thing, you just have it, you know, and you could go from there.
That'd be cool.
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, like, piece by piece.
Yeah, because it seems like the art is, like, the last thing that you want to put your energy into, you know?
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.
Exactly.
Or even if the game idea, the way you first thought of it makes any sense.
Like, if you could play around with, like, some little sample data and they go, oh, actually, really, that's close.
But this is really what I wanted.
Like, you don't want to spend a ton of time on art for that, right, to get it up and running.
Exactly.
Anyway, that would be cool.
Maybe somebody out there is inspired to create that.
That'd be great.
I'd love to see something like that.
Yeah, cool.
So I guess we can maybe round out our conversation here by, like, assuming we've built this beautiful game.
It's like 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?
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 PyB 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.
Or 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.
I definitely see it as one of the shortcomings.
It's great to see the PyOxidizer is coming along, right?
This is the newest of the packaging tools.
And I think it does take other libraries along with it.
I'm not entirely sure.
It certainly takes, like, the other Python libraries.
But, like, FFmpeg, for example.
Does it take, you know, 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, like, your .app file on Mac.
You know, you just put it into a disk image and, like, drag it over, right?
Like, that's basically a directory.
I suspect you could make it work like that.
I'd love to get to a spot where somebody who's learning to program or is more on 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 for 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.
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 Python 3-m package or bundle or something in a directory.
And then I get three outputs.
Linux, Windows, Mac.
Yes.
And there's a .exe.
There's a .app.
And there's a Linux binary.
And that's it.
It just runs.
Yes.
I would love to see something like that.
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, you know, I think that would really make a big difference, especially on things like this.
Yeah.
For me on the Arcade Library, this is a big hang up.
The sound support is another one that I get a lot of headaches on and trying to make sure I do support.
Yeah.
We haven't talked about sound yet.
So can we have sound?
How does that work?
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 AVbin, which is like 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 because then you get permissioning errors.
You have to remember where the heck that is.
At any rate, sound is a headache.
And it's very, 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 to port.
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.
Okay.
Well, people 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.
Yeah, I've had, I've looked into so many different libraries with that where people have suggested, oh, well, you should do this.
And, you know, 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.
Well, it sounds like you have at least basic support for sound, which is pretty critical.
Yes.
It makes it a lot more immersive.
Yeah, absolutely.
Maybe even more so than graphics, right?
Like there was a really interesting game on the iPad that was like this retro 8-bit game.
But it had brilliant music that was so immersive.
And actually, it was quite, quite interesting.
I forgot what it's called, but it was, it was fun to play.
And it was because of the music.
Yeah, I agree.
And I told my students the same thing.
It's, you got to get some sort of sound effects on there.
Yeah, for sure.
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 labs that day.
Oh boy.
Do you have a good place for sound effects?
Like the audio equivalent of Kenny.nl?
Kenny.nl actually has some sound effects.
So I often ship that.
Open Game Art 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.
Yeah.
Sound should never require an install.
Exactly.
And some sites that I used to like actually have sort of switched over to requiring some sort of install and therefore automatic.
Like steer clear of.
That is super shady.
That's crazy.
Yeah.
All right.
Well, I think we pretty much covered Arcade.
That sounds like a really nice project that you built and hopefully people get a chance to check it out.
All right.
Thank you very much for having me on.
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?
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.
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 like maybe something people don't necessarily know about, but you're like, well, this is really great.
People should know about X.
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, Modern GL, if you want to write your own OpenGL code,
Modern GL is a really pretty good package that's actively supported online as well.
Oh, that's interesting.
I've never used that.
So, yeah.
Yeah.
There's like a few different OpenGL packages.
Piglet's bindings I really like and Modern GL are my two favorites.
Okay.
Yeah.
Cool.
So, if you know the OpenGL API, like this is it, but in Python rather than C++.
Right.
Yeah.
Cool.
Okay.
Nice.
That's a good one.
Thanks.
See, this is the purpose of this little section because we all learn about these things that
we don't know.
All right.
So, final call to action.
People are excited with Arcade.
How do they get started?
How do they contribute?
Things like that.
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 the 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.
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?
Yeah.
Learn.arcade.academy.
Yep.
I'll put it in the show notes.
People can click it.
There we go.
All right.
Well, thank you so much for being here.
It's great to chat with you.
Yes.
Thank you very much.
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
slash 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.
I'll see you next time.
Thank you.