Engagement advice on Creative computing

Question

I'm preparing a course for next year, aimed at kids from ~6-16. It's based around the concept of creative computing:

http://scratched.gse.harvard.edu/guide/index.html

I think it will be a great experience. We'll be working around Scratch, and a lot of stuff involving game development, animations, and who knows what else will come.

The real challenge I see in this course (as well as the main objective) is how to engage the kids into this world of development: The stereotypical kid in this age range is just interested in playing games with their parent's smartphone or tablet. Some of them have a PlayStation or other gaming system, but at the end, they spend a lot of hours playing modern games, which are ridiculously easy to play (don't get me wrong, some of those are great, but the majority of them don't promote any required value like endeavor or perseverance). Those kids don't know the amount of work that those games involve, and I'm a bit afraid of them getting frustrated by the fact they cannot easily make AAA games like the ones they're used to in a matter of minutes.

Has anyone experience in a similar environment, who can provide experiences and feedback? How do you engage those kids into this world that requires so much sacrifice and willing to learn?

Answer 1

Show them the cool stuff they can do with Scratch.

Don't focus on explaining that they can't make a AAA game. Focus on showing them examples of stuff that is engaging and interesting, that they can do with Scratch. Come up with a showcase of interesting programs. Make sure your assignments are engaging and interesting.

Taking a step back, I'd also recommend you give your students the benefit of the doubt. Don't come in with an attitude that assumes they only care about modern video games and smartphones. Connect your lessons with stuff they do care about. Have them draw a scene from their favorite show, or have them make a game or animation about their friends.

And taking another step back, the age range of your students is very high. A 6 year old and a 16 year old are very different. I'm not sure Scratch is the right choice for 16 year olds. Maybe try something like Game Maker or Processing? I've mentioned Processing in a bunch of my other answers, and I'd be happy to talk more about it with you if you're interested.

Answer 2

Let them start by playing games that are actually teaching them programming concepts and are mostly not AAA games. None of this uses Scratch, but it is fun and it is learning programming which is also problem solving.

Human Resource Machine
SpaceChem
TIS-100
Silicon Zeros
MHRD
Infinifactory
Great Permutator
Papers, Please
Mini Metro

or problem solving,

Portal 2
The Misadventures of P.B. Winterbottom
Crazy Machines 3
The Turning Test
Rubik's Cube
Once Upon an Algorithm: How Stories Explain Computing (book)

The key word to use when searching is puzzle and or use puzzle as a tag on Steam which is a great place to start.

Answer 3

This answer, I'm afraid, is a bit off the wall. It depends on your having a really good grasp of programming and also a bit of design. If you have that you might consider proceeding as follows. I'll assume that your student's interest is mostly in gaming, so I'll go with that. But anything of interest to your students would do.

It uses an Agile Software Development methodology, though you don't need to ever say that or even introduce its concepts explicitly. Just do it.

The first step is to work with your student group (or groups) on an overall concept for a game, even a complex one, but not too complex. You could even do a bit of storyboarding for the game. Spend a day or so doing this.

The second step is to some up with some sort of design for your concept, even if it is very rough and not well developed. It certainly doesn't need to be complete since it will morph over time anyway. You will probably need to do much/most of this yourself. Break the concept into parts.

The third step is almost all your job. You need to act as (agile) Customer to your students by taking the design and breaking it into small tasks, each of which can be done in a day or so. Write these tasks on index cards. You will need to spend a hard week-end doing this. Some of the tasks will be programming and some will be other things (creating or finding graphics, say). You don't need a complete set of cards for the whole thing. You can add and delete cards as you progress. Using index cards makes this easy.

Since the visual is a motivator, make sure that your task breakdown makes it possible to see something early on - as early as possible. This can be as simple as a background pattern, but something moving (for a game) would be better.

Now the students can actually start development. Give a pair of students a task card and have them build just that. Make sure that your pairs of students are working on tasks that seem to fit together so that the work of several pairs can be integrated. Try to switch pairs frequently so that each student gets to work with different people. They won't get stuck so much and can help one another. Learn something about Pair Programming also so you can help them do it properly.

In other words, you grow the application organically. You can change the design at any time, making it more or less complex depending on how the students are doing. The steps are small, but they add up. Use the original concept as the incentive and organizing force to keep the students engaged. Have frequent "meetings" with students to get their feedback on how to proceed. Talk about what is working and what is not.

I'm willing to expand this if comments suggest it would be useful. But the original concept for the app needs to come from your students with your guidance. I'd suggest not making it too small or trivial. They don't need to complete it to be successful personally.

Answer 4

Regarding your question:

How do you enroll those kids into this world that requires so much sacrifice and willing to learn?

You don't. You present the material and there will be one of three outcomes:

• They are not interested and probably never will be. This is the norm for almost every possible thing that students ever learn.
• They are interested in learning, but they never end up using it beyond schooling. This covers 99% of the other cases.
• They are interested and end up doing it as a career. This happens about 1% of the time for basically every possible thing that students can learn.

Schooling has two objectives: 1) produce people with broad experience, 2) produce people who can do something for a living. We need both, and cannot force students to be interested and eventually do something for a living. It is up to them. Throughout time, there have been few people doing architecture, painting, music, writing, acting, cooking, and so on. Few people do any particular thing, and there is a large and growing set of particular things that people can do.

For some reason, computing is thought to be somehow different, but it is not. Few people learned auto mechanics, or civil engineering, or aviation, or radio technology, or oodles of other extremely useful things developed in the past few hundred years. And, because it is technology, few people actually had to. That is the point of technology. It is especially true for computing.

So, teach, and let the students decide which of the three levels of interest they have, which is a decision made over the course of many years, and involving many factors, nearly all of which are outside your control.