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...
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!
I'm very interested in this project, because I have a student researching what good options there are for Python Game Dev at the CS1 level. We used Arcade[1] this past Fall, and things didn't go very well (I'm not sold on Pyglet, and there was a lot of small "What??" issues with Arcade's design itself). Pygame Zero is a very appealing choice, but suffers from its design around global state - which is something I spend most of the semester railing against. The authors gave me a good explanation for why[2], but it still is a deal-breaker for an introductory-level university course for CS majors.
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 :)
After the students fight with global state in their first significant programming projects, they'll welcome exit strategies (even radical ones, like immutable data structures) in the following courses instead of ignoring premature preaching in introductory courses.
Hi, thanks for your response and your passion for CS Ed! I like talking about it too, and I want to preface any conversation we have with my appreciation that we both care about this important subject. Text doesn't always do a good job of conveying sentiment on its own :)
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.
Thanks for the kind words. I don't mean to pose any of this as an affront to your experience or expertise.
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.
OK, so I'm genuinely confused about what your objection to global state is. You mention issues with assignment, and so on - those are issues with Python `globals` and variables in the global namespace, not issues with global state per se. A lot of Python programs use global variables in the form of imports, so I don't see anything wrong here. (Pygame Zero's implicit imports could be a point of objection - but it'd be very easy to hack a small wrapper to force students to import the names they need instead).
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`.
> However, a major concern I have for this architecture from a pedagogical perspective is it's reliance on the global namespace.
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.
There is no difference between OS level global state and framework level global state. Students and teacher are free to create clean abstractions on top of any global state. Why are we tolerable to OS boundary and not tolerable to in-process API boundary?
The objection is because of testing, debugging, and getting compiler/autograder feedback.
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.
> Code written in one part of the program can cause issues hundreds of lines later even though they are seemingly unrelated.
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.
Indeed, we do talk more about good contracts with the Turtle alphabet than we do about global state. But it's a small part of the conversation.
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.
>but that's distinct from the overall windowing system, graphics state, etc. which would be stored in `World`.
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.
In the context of a simple game, global state is good design. (Maybe less so in Python than in some other languages, because Python’s variable scoping is a bit odd.) This applies even in a commercial setting.
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.
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 : - )
There was/is Kevy for Python game dev, focused a lot on touch and mobile, dunno if it is well maintained but it seemed to have a nicer architecture/API, maybe it's what you need.
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 .
There isn't that much boilerplate with pygame (I've taught middleschool students pygame in the past); I'm not sure if it makes sense to move things into a framework, and have a lot of configuration by convention, when the goal is education.
The goal isn't education in how to make games or use a particular library. The goal is education in coding, and games are just the hook to maintain interest. Pygame Zero hides the bits we don't care about so they don't distract from the bits we do. Middleschool students might cope with full Pygame, but when you're teaching 8-year-olds who can't type quickly, getting a sprite on the screen without any boilerplate is an advantage in maintaining their attention.
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.
How so? Unless you plan to have multiple windows, of different resolutions (exceedingly rare in a video game), then WIDTH and HEIGHT simply are pieces of global state. Whether you like it or not, global state exists, and if you need access to it in many places, then passing it up and down the call stack becomes an exercise in pointless book-keeping.
I don't think there is much downside in starting with the good stuff (placing and moving pixels). You can, and will eventually expose more of the cruft as needed. But if you lose a students on day 1 because you spending the day configuring instead of creating, you may never get it back.
Possibly you've made it worse: defining the wrong magic variable will pass silently, as I argue in https://news.ycombinator.com/item?id=22156525, while misspelling the name of display.set_mode will give you a traceback that tells you where the problem is. Of course most people didn't get into programming because they got excited about reading error messages...
Actually pygame zero warns you if it detects that you have mispelled. For example of you use width, it will suggest that you use WIDTH. If you write onmousedown instead of on_mouse_down() it will also catch that and warn you.
You can just give the student an already existing example. Then there is no time wasted in configuring etc. Just tell him, leave this cruft aside (put a comment in the code to make it simpler), and only touch this function, and that function. This is not really too hard. And when the student becomes more curious, at some point, he might want to try to understand parts of the cruft.
the problem with teaching programming is bigger than boiler plate code to be honest. but what the author is doing is really appreciated!
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.
While I can certainly appreciate a desire to get down in the nuts and bolts of a programming problem, and really understand what you're doing, I don't think that's required to spark the joy of learning in a new student. No, for video games in particular, what seems to work most consistently is rapid iteration. How fast can the student go from idea in their head to their character doing that behavior on screen? That core loop is fascinating to a youngster, who immediately begins to piece together how Mario might run and jump, or a race car might move along a track, almost entirely on their own.
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.
Can this target mobile platforms, eg. Android or iOS? Otherwise it's a non starter, the kind of games a beginer could easily make mostly only make sense as mobile games...
but the benefits of the extra code are rather more immediate than those of public static void main: you can control whether your window is fullscreen or not, what size it is, when the screen updates, and how long the program runs before exiting.
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?
(The talk was for a Spanish-speaking audience; "imagen" is Spanish for "image", and "pantalla" for "screen".) So that's what you're saving yourself when you say
But I don't have a lot of experience teaching kids to code, so maybe my intuitions about what makes things harder and what makes them easier are not well-founded. I'd be interested to hear other people's experiences of the kinds of errors beginners make and what kinds of interface design work best for them.
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()
However, I'd argue that this interface is somewhat less error-prone than PyGame's; a common error I've had when starting new PyGame programs is forgetting to call pygame.display.flip(), which has the delightful symptom that whatever I've drawn just doesn't appear on the screen. By using a context manager, the Yeso Python binding avoids that error. As the comments point out, you can reduce yv.py to the following six lines of code if you depend on CPython's prompt finalization to flip buffers:
#!/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()
Yeso is still in its early stages, and I might change this interface a little bit, but I don't see why things need to be any more complicated than this for simple GUI programs. And my intuition is that making the interface less explicit makes it worse, for experienced programmers.
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.
in my experience, pygame zero works well with 10 - 14 year kids.
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".
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()
- 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!)
In the example code for pygame you give, what happens if there is a single typo? It doesn't work either and you probably get an incomprehensible stack trace.
There is no benefit to teh extra code because that extra code is magic gibberish. It's an incantation that somehow makes things work.
From my point of view, an incomprehensible stack trace is a big improvement over silently failing to work, because then you learn to comprehend the stack trace and you can fix the error. This is one of the central design principles of Python, rooted in experience with teaching beginners to program in the ABC teaching language.
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)
Although an IDE may make that easier, and of course you don't start out knowing that.
What is your experience teaching beginners to program? What tools did you have them use, and what did they have the most difficulty with?
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.
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).
Do you have any links for the implications for commercial use? If I released a game made with PyGame, what's the gamble? I've seen examples of people using it commercially [0].
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.
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.
So there are numerous deployments of "successful" games using PyGame, and no court cases by the creators/maintainers of PyGame towards those game developers? I'll take my chances.
I don't see what PyGame's motivation would be to open such cases.
I have also been working on a similiar but 3d library: https://github.com/electronstudio/richlib