Pygame Zero: Creating games without boilerplate
pygame-zero.readthedocs.io
pygame-zero.readthedocs.io
I have also been working on a similiar but 3d library: https://github.com/electronstudio/richlib
one thought: after having read your introduction for the teachers, i wonder why you did not "sort it" the other way round: first the hands on and the tutorials and then the theory...
for our coderdojo we went for a "cards" approach:
https://github.com/CoderDojoZH/resources/tree/master/cards-p...
we suggest the kids to first do the pong game in scratch (we have a booklet with step by step instructions) and then use the set of cards (in order) to do the same. we try to avoid that they just copy the snippets line by line, without thinking at what they are doing...
i will now give them a link to your book when they want to learn about python!
At this point, we're leaning towards making our own library to satisfy our purposes. We're still looking at other options though - hey, if you have one, feel free to suggest it :)
It's not branded as an actual game framework, but it's based on OpenGL ES and that's pretty much what it is - I mean, even their first tutorial is a mini game https://kivy.org/doc/stable/tutorials/pong.html .
In terms of global state, I don't see much of a distinction between Pygame Zero's globals and a god-singleton like `World`. Both feature large amounts of implicit state, just off by one layer of indirection. For the vast majority of games, it wouldn't make sense to have more than one `World`. You might want more than one game scene/level/etc. but that's distinct from the overall windowing system, graphics state, etc. which would be stored in `World`.
Their concerns are not specific to pygame. They are trying to teach their students to not have global state and are afraid that using pygame in its current form would undermine those teachings.
That'd be pretty odd naming, usually 'World' would own all your game objects and scene, but have no relation to the windowing system or swap chain.
Regardless though, I wouldn't make the windowing system or swap chain or d3dcontext global either, I mean all of that is literally designed to be wrapped into some object. (Well, the window requires some trickery, but it's still prettier than a global handle in the end.) There's really no reason for a game to have actually global state, even if most games are only going to need one window.
Obviously, global data is powerful and allows us to do a lot. I let my students define top-level functions and use them globally throughout their programs, and as you say the import mechanism also gives us useful constants and functions to be used anywhere. We talk about how great global constants are for this reason.
The problem is mutation. When you have global mutable state, it becomes difficult to reason about the program. Code written in one part of the program can cause issues hundreds of lines later even though they are seemingly unrelated. You can no longer easily write simple unit tests to confirm that your program works as intended. Global mutable state also frustrates my attempts to use program analysis to give enhanced autograded feedback.
As a concrete example early in the course, we use the Turtle library to define a bunch of functions to write letters, and then they use those functions to write out their names. Difficulty ensues when I ask them to swap definitions and reuse the functions. One kind of issue they encounter is the Turtle library's reliance on global state, which makes it difficult to reason about where the cursor should be after you call a function.
You are thinking about the World example, but what about when they make a list of Coin objects? With global state, they start encountering very mysterious bugs related to the shared coin instances. When its all contained within the World object being passed around, we can write more coherent unit tests to debug this kind of trouble. In a class of 150, it's helpful to give them mechanisms like that.
How does this change when functions accept big singletons like "World"? At some point you'd have to break it down into smaller objects - at which point you may as well introduce proper OO factoring and design.
I do see the point though - global state is easy to mutate by accident in a function that should otherwise not need to mutate global state (say, a function like "def apply_gravity(cur_velocity)" should not be able to accidentally change the gravitational constant or the object position).
The example with the Turtle library is an interesting one, but I'd argue the problem is that the function contracts are not fully defined, rather than a problem with global state. A function needs to clearly specify what state it expects and what state it will produce - whether that state is in the ether (global) or whether the state is explicitly provided as a big object. For example, a function to draw a letter might logically be expected to place the cursor at the right edge of the current character (facing right, say), so that another function can advance the x-position for the next character. If it's contractually specified then there shouldn't be an issue.
The `World` (which is based on the concept from Racket's Universe library) does indeed get broken down into smaller objects. We talk about how to do that too. The idea is to lead this naturally into more OO stuff next semester, but we talk for a while about how we can use dictionaries to structure data at least.
the same goal as pygame zero but with a very different approach.
and no WIDTH and HEIGHT variables...
https://github.com/CoderDojoZH/resources/blob/master/cards-p...
i really liked it, but i don't consider it a mature product i would use "in production".
because of our approach, we can't really adopt it until it's natively supported by a "package" like mu-editor or thonny
my conclusion was:
as a "senior" programmer, who grew up with procedural programming, i'm still "scared" about relying on annotations and async programming.
but, for kids coming from scratch and without much other experiences, i'm not sure that it will be a big stumbling stone.
they will simply "learn" it in a different way: at the beginning, programming is (mostly) black magic anyway : - )
it might be even easier for them to use play, than relying on the magic update() and draw() functions...
(and, no, i don't think it makes a big difference to call those function from a main loop like in pygame or having them implicit like in pygame zero)
probably, the biggest issue would be that the founding blocks of play do not match what the kids will learn in most python tutorials and books (they probably won't find any reference to async or annotations in most programming books for kids or even for beginners!)
all in all: i like play and i think it could be a good match if the focus is more on computer science topics...
in our case, the focus is on the kids having a good time on sunday afternoons and getting them to learn to be an (active) actor in front of their computer, not just a (passive) consumer. we are not too picky about the concepts : - )
You can introduce subject as another execution environment like OS and keep globals-free "clean" code. Actually it's a great lesson.
Also you can give mind-bending article[1] as alternative study material.
[1] https://blog.cleancoder.com/uncle-bob/2015/07/01/TheLittleSi...
The insane stuff we teach in CS1 is why so many students choose other majors.
Sell your students on the magic of computers. Don't teach them arcane rules and formalisms. They'll learn that later, once they've been hooked.
Teaching ahead of the curve is a great way to confuse and bore the hell out of your students. This is why I hate intro CS education so much.
It sounds like you are hypothesizing that my students have a motivation problem and proposing that I use an intervention of "Selling students on the magic of computers". Based on survey data collected during my past few semesters, I do not believe that my students are disinterested in the subject. This is true at the beginning and end of my course - I cannot claim that my assignments and course design (some of which is particularly oriented towards making the students interested in CS) has a big impact here, but I do not think they are being hurt by that aspect of the course design. There are potentially motivational issues related to self-efficacy, community interaction/isolation, and help-seeking behavior. However, I don't think your proposed intervention would solve those problems.
Instead, I disagree that my CS1 here at the University of Delaware is not the place to discuss the topic of avoiding global mutable state. My curriculum has several learning objectives explicitly oriented around these topics (largely agreed by my colleagues) and I have several projects that I think can authentically justify their importance (particularly with regards to testing and getting enhanced compiler support). I have many anecdotal supports from friends in industry and my own experiences teaching upper division courses that students struggle with issues that can be solved by avoiding global mutable state where possible. Personally, Therefore, since CS1 is not an agreed upon well-defined subject, I think I am perfectly justified including it in my learning objectives, alongside many other important topics and objectives.
If you have demonstrable evidence relevant to my teaching context that teaching global state early could impact areas where my students have other known issues (either motivational or cognitive), then I'd be very happy to read up on those. However, for now, I am doubtful that teaching global state is a serious issue.
I was a "CS1" TA my throughout my entire undergraduate career (modulus my first semester), so this is something I have direct knowledge and frustration about.
One of the courses I oversaw comprised of mostly non-CS engineering majors, but the curriculum was the same as the CS-track students. These students were forced to learn in Java, force fed the dogma of object oriented design (cats and cows and animals that moo), and tested on arcane Java-specific errata that had little to do with getting core concepts across and actually being able to express thoughts and ideas in code.
People will naturally discover how to organize their code. They'll either read about it or find out in code review. I think a better time to broach this subject is in a "software engineering principles" or equivalent course.
It's the same rationale that general chemistry "CHEM1" is not the place to talk about iterative solutions for non-ideal gasses, molecular orbital theory, LCAO, chemical activity, or any of that organic business. You're introducing too much information too early on and without context. You wouldn't teach students dynamic programming or ER diagrams in CS1. The students barely know how to handle the basics and you're already telling them how to anticipate and solve complex future-them problems.
Give them Python and let them have fun. If they produce a dozen nested if statements and improper for loops, so be it. At least they're learning to express themselves. If and when you see your students hit the "global state is bad" problem in lab, then turn it into a 1:1 teaching moment. It'll have way more impact, and it won't distract them from the core foundational concepts.
I do a lot of interviewing and hiring now, and I see so many fresh-out-of-college grads that simply do not have the ability to analyze a problem and structure their thoughts in code. They might be able to pass a university exam, but they haven't spent enough time using programming concepts on their own time to let them sink in and become muscle memory.
I think the biggest discriminator for success is that good students spend their free time programming on hobby projects of interest. And the only way you engender a desire to do that is to get the students interested in programming in their spare time outside of the context of homework and projects. Make programming fun and relevant; make it something they can use to do fun self-directed projects. Such students will excel, and the only thing you have to change is their interest level and attitude.
"I want a CS degree and career" is quite different from "I want to write my own game or app or website". And I can tell when I interview candidates which ones spent more time actually programming.
If the objective is to teach the benefits of avoiding global state, it may be more effective to pick a project type for which that is a correct design choice.
There is no logical reasoning why those two variables are globals, and what other globals might have special behavior.
If you need magic variables, you haven't actually fixed the boilerplate problem.
Another advantage of Pygame Zero is that the author was involved in the creation of Mu, and so Mu comes with Pygame Zero pre-installed. Having to install Pygame via pip would be a challenge for many kids.
Anyway, Pygame Zero includes all of Pygame so you're free to introduce as much of it as you like.
i feel like the abstraction is leaky though. why the person you are shielding from the boiler plate has to write on_mouse_down, on_mouse_up, clock.schedule_unique?!
the problem with teaching programming is that people are given user interfaces that hide the fact that you "actually make your computer or phone do stuff". at least that's what i think the bigger issue is.
back then when i discovered i could make the computer do things, i'd spent hours in the QBasic online manual, discovering new things i can show people.
To that end, there's a certain value in declaring that, "You know what, PyGame Zero's event loop is probably fine. Let it sweat the details, and we'll worry about writing the character.jump() function next." Another framework I love that works this way is Love2D, which targets Lua but has a similar approach:
Sure it's not suitable for any project of decent complexity, but there's a reason we keep reaching for it during Ludum Dares, and any time we want to rapidly prototype an idea. It takes the least amount of effort of any tool I know to go from concept to prototype, and get the idea in playtesters hands so we know if it's worth doing properly. Getting to do that in Python sounds awesome, so kudos all around; this is neat stuff.
https://lk-games.itch.io/citizen-of-nowhere
This game is made using love2d
https://news.ycombinator.com/item?id=11633278
The docs are a mess though.
#!/usr/bin/python
from pygame import *
pantalla = display.set_mode((0, 0), FULLSCREEN)
draw.rect(pantalla, 128, (50, 100, 200, 400))
display.flip()
time.delay(2000)
print("hello, world")
When I see things like this,
> Your alien should now be appearing on screen! By passing the string 'alien' to the Actor class, it automatically loads the sprite,
I shudder. (That's in https://pygame-zero.readthedocs.io/en/stable/introduction.ht...) When you write a program and it doesn't load your sprite, how do you figure out why not? Maybe you called your sprite file images/alien.PNG or Images/alien.png or images/alien.jpeg or ./alien.png, and Pygame Zero doesn't happen to look in those places? I think you're going to have to resort to either trying things at random or using strace. Similarly, how hard is it to debug Pygame Zero displaying your window at the wrong size if you write HIEGHT = 300 instead of HEIGHT = 300?
In that talk I did eventually get around to drawing sprites, but it wasn't until one of the later examples, https://github.com/kragen/pyconar-talk/blob/master/reloj.py. The relevant code is
imagen = image.load('trashcan_empty.png')
...
pantalla.blit(imagen, (xx, yy))
alien = Actor('alien')
alien.pos = 100, 56
...
alien.draw()
With Yeso, things are slightly more complicated than with PyGame; https://gitlab.com/kragen/bubbleos/blob/master/yeso/yv.py similarly opens a window and displays a PNG in it:
import sys
import yeso
if __name__ == '__main__':
image = yeso.read_png(sys.argv[1])
if image:
with yeso.Window(sys.argv[1], image.size) as w:
with w.frame() as f:
f.copy(image)
while True:
w.wait()
#!/usr/bin/python
import yeso, sys
_, n = sys.argv
p = yeso.read_png(n)
w = yeso.Window(n, p.size)
w.frame().copy(p)
while True: w.wait()
Proce55ing and Arduino offer at least some evidence that at least the setup()/draw()/mousemove() scaffolding is a significant help to beginners; they can get a moving object on the screen or a flashing LED before they have to know what a loop is, and the default behavior you have in Python or C of closing the window (for GUI programs) or restarting the firmware (for embedded programs) is not a good default.
There is no benefit to teh extra code because that extra code is magic gibberish. It's an incantation that somehow makes things work.
The extra code is not actually magic gibberish, although it does appear that way at first. In Python you can comment out individual lines and observe the effect, change the parameters, or type
>>> from pygame import *
>>> help(display.flip)
What is your experience teaching beginners to program? What tools did you have them use, and what did they have the most difficulty with?
i run a coderdojo and we have developed a system of cards that helps the kids creating a pong game with pygame zero.
in two hours of our weekly meeting, they manage to
- install the mu editor,
- create the game window
- download an image from the internet,
- put it in their game
- move the image around with the arrow keys
mostly by themselves.
loading the image is indeed one of the big issues they often face. but i'm convinced that it will often be an issue anyway: kids need some mentoring there.
(really, you cannot rely on the fact that they will be typing the file name correctly or that they will put the image in a specific directory, with the right extension).
this having been said, writing a full pong is much harder as in scratch. they do need some real mentoring for the further steps.
concerning your suggestion with yeso: for our setup, providing an image through the command line is probably not an improvement.
most of our kids are using windows or mac and we avoid forcing them to use the terminal during their first steps of "creating a game with real programming".
managing files is hard...
What are the cards you mention?
Are you saying that writing a full Pong in Pygame Zero is much harder than in Scratch? I'm not sure what you mean by "harder as in scratch".
I was pretty impressed with the Pong game in 5'30" in https://www.youtube.com/watch?v=KoWqdEACyLI when I first watched it, but I suspect it might be pretty intimidating for a total newcomer.
And, yeah, I wasn't suggesting that you should pass filenames on the command line to simplify debugging. It's just that that program is an image viewer, not a game, so taking the filename on the command line is what it does. If you hardcode the filename and rely on CPython's prompt finalization, you can reduce the program to four lines, which is less even than PyGame:
#!/usr/bin/python
from yeso import *
w = Window('hello, world', (406, 220))
w.frame().copy(read_png('admu_shell.png'))
while True: w.wait()
- harder as in scratch? it's about this scratch and this game: https://scratch.mit.edu/studios/644508/
- a pong in 5'30"... of course, but his real tutorial is 3 hours : - ) ... and that pong game does much more than what our kids can achieve...
- our kids debugging skills are often very limited (both in skills and patience)... correctly matching the filename and the actor is a good example for learning the debugging but it's often already too much: they just want to see it work!)
A somewhat related video that your docs reminded me of, "Bret Victor - Inventing on Principle" [], which I think is a really interesting take on inventing and learning. Perhaps some useful thoughts for your principles section.
The sphinx docs look great. Also, the logo! Not to mention, the translations:
- https://pygame-zero.readthedocs.io/zh_CN/latest/
- https://pygame-zero.readthedocs.io/ja/latest/
- https://pygame-zero.readthedocs.io/sk/latest/
One reason of why I wouldn't use it yet: LGPL.
This is the issue pygame had when I tried it. The license made it very difficult to incorporate and use in practice, and I ended up playing with kivy instead (https://github.com/kivy/kivy). The reasons why:
1. Writing anything commercial would be a gamble. I've wrote at length on why this license isn't meant for scripting languages, but even if it's a compiled language, SDL moved away from LGPL here: https://youtu.be/MeMPCSqQ-34?t=430.
2. LGPL and scripting languages just don't work from an open source perspective. It's not copy-paste and vendorize friendly. Functions can't be copied a la carte. I'd rather write something from scratch than link an LGPL library in one of my MIT licensed projects. I'm just not willing to open downstream users to the risk. What ends up happening is 5/10 years on, someone ends up writing a new MIT/BSD library to get around a viral one (e.g. GCC -> Clang/LLVM).
[0] https://www.reddit.com/r/gamedev/comments/16d5ak/is_pygame_o...
LGPL in scripting languages is a gray area. There are no previous legal cases to cite. Python projects have transferred away from LGPL due to its ambiguity. Example dating back to 2004: https://twistedmatrix.com/pipermail/twisted-python/2004-May/...
Namely around the language of what creates a derivative / combined work:
LGPL was intended for languages that use header files, like C and C++. So, if a project was ever accused of creating a combined work, they'd be on the hook to defend the the case, whether or not a combined work is created. In v2, the license even shifts the question onto licensee/licensor: "The threshold for this to be true is not precisely defined by law."
In licenses such as BSD/MIT/ISC/etc. these issues do not arise, and a breeze through top python projects show reciprocal contributions and access to source are commonplace without viral clauses in licenses.
I write about LGPL/python at length before here (2013): https://github.com/ScottDuckworth/python-anyvcs/issues/32#is... and (2016) https://github.com/PyGithub/PyGithub/issues/468#issuecomment...
For gaming, it's even more relevant, because if the deployment is to steam or a mobile phone (like what kivy does with https://github.com/kivy/python-for-android), that could easily be interpreted as a combined work. They're not like C/C++ application linking to .so / shared libraries.
I don't see what PyGame's motivation would be to open such cases.