Replying to that and some new stuff here.
First, and apology to anyone watching this thread, or reading and hoping for more.
My eyes were too big with my stomach for this one, ie I overpromised and underdelivered in terms of providing a guide. Because... reasons.
On a longer timeline I do want a good guide to exist, and I want to help, because I think that making use of the crank should be easy. Or fun. Or straightforward. Or learnable. Or something. I guess I'm not sure.
@sgeos On one level I agree the crank is simple, but the human imagination part of the equation is the challenging part.
Imagine two classrooms of children:
To room 1, you give a powered-off Playdate to a group of children and have them come up with ideas on what to do with the crank. You don't "teach" them anything about game design, programming, etc. As their minder, you write down 100 of their ideas, and then give them marshmallows.
The room 2, you show a working Playdate and provide computers with the Pulp interface. No restraints on teaching game and tech. The kids split into groups, and with some level of adult coaching, each of them gets a game piece created. This sort of scenario happens in STEAM ed, I'm guessing.
In room 1, you'd have a bunch of really creative ideas. 100 of them would be wild ideas only a kid can have, let's say 50 are feasible. But you'd have no working software, and no direct route to working software in the classroom settings because of the uniqueness of the ideas. After class, if the teacher did develop the concepts into working prototypes, the games would likely be very laborious to "finish" because of their uniqueness.
Worth noting, for developers to whom nothing is impossible: A good developer/teacher could totally take one of the ideas to a working prototype in the classroom setting, but they'd likely do so by 1) picking a feasible idea from the bigger list, 2) editing down the idea & convincing the kid to accept a limited version, and 3) other developer coping strategies. I'm not talking about that, that's the sort of thing that would happen in room 2.
So yeah, In room 2, you'd have more practical ideas, or ones limited by solutions becoming obvious in the typical process of software development. But you'd end up with working software, and the "editing down" process of applying software development logic may end up with a piece of a game that could possibly be completed. If the kids started with 100 ideas, you'd also have a record of the room/groups editing down to what's possible in the time given.
Personally, I'm more of a room 1 type of kid. Hard to keep on task, but I can really ideate. Fences are merely things to leap from. When my ideas hit the reality of software development, things don't go well. I end up babysitting little problems and making no big progress.
This is my problem though, linked how I like to work (getting budget and working with professionals is how I work at work), perhaps it's a personal pathology. But I still think the world needs "playful" programming/prototyping environments. And I think it's a valid idea that some people would want to avoid the hard parts of programming and make a thing... the thing they wanted to make... not someone else's idea or something from a pre-baked demo.
But I do think it's ambitious (impossible) to provide a guidebook for room 1 kids, because there are so many things one can do with a rich input device like the crank.
So I'm re-evaluating the scope of this thread. And I'm open to others ideas here (and in the larger forum).
My next post I'm going to jot down a few "room 1" ideas. Though I think we may want a new space for those thoughts. Honestly, the more I think of the classroom experiment the more I actually want to do it, despite not being an educator.