Teaching LÖVE

[IndieLöver]

Hi,

I'm going to teach a group of 11-15 years old youngsters to program a small game in LÖVE. This happens during a 3-day summer camp, and there will be about 6-hours of teaching per day, the kids will spend rest of the camp swimming, eating grill-food and doing other summer camp-ish stuff. I have a a 4-year experience in LÖVE (though sadly I've always been too ambitious to *finish* anything). I'm doing the teaching with a friend who has a lot of experience with LUA, but he isn't that familiar with LÖVE.

I haven't actually teached anything to anyone before, and I'm quite nervious. Do you have any tips for me and my friend? I have a pretty clear idea of what I'm doing, but all help and ideas will be much appreciated. Things like what sort of a project would be the optimal one for their first game, while being simple enough for a beginner, but yet still enough rewarding that everyone will be happy with the experience they got (Pong-clone doesn't sound all that satisfying, does it?) are still a bit up in the air.

Thanx,
Indielöver

[Robin]

Cool! I'm not sure what kind of project would fit, but it would be something that is "playable" in some way as soon as possible. It'll be more fun for them, and easier for you to keep their attention, if they have experienced the reward for making a game as soon as possible.

[bobbyjones]

I would say a pong clone but actually fun maybe design a pong game that is simple but gives a twist on the core mechanics. This is good because it shows that creativity is as important as skill or what's so ever.

[micha]

For game ideas, have a look at the tutorial series by Tom Francis. It is in GameMaker, not LÖVE, but it might be useful as inspiration. He is doing a top-down shooter, I think.

[T-Bone]

I think it's important to let the kids themselves contribute ideas, rather than you deciding everything beforehand. Of course, if they want to make an MMO, you'll have to explain how that's out of scope, but you get the idea. Kids have a lot of creativity, use that! It'll help them not losing interest.

Also, I want to say that this sounds phenomenal and I wish I went to something like this as a kid.

[davisdude]

I think that you should make something that is easy, but fun to play and watch, this way the kids can show it to their friends/parents and impress them, giving them motivation to continue.
This is a good video if you do want to do something like pong, while still making it exciting.
https://www.youtube.com/watch?v=Fy0aCDmgnxg

[kikito]

I think it's important to let the kids themselves contribute ideas, rather than you deciding everything beforehand. Of course, if they want to make an MMO, you'll have to explain how that's out of scope, but you get the idea. Kids have a lot of creativity, use that! It'll help them not losing interest.

Also, I want to say that this sounds phenomenal and I wish I went to something like this as a kid.

I agree with T-Bone here. You need to give them "a structure" so they advance, but make sure to foster their creativity, or they will lose interest.

Example: teach them how to make a game which produces a sound when spacebar is pressed. Then a different sound when another key is pressed (so you introduce "if - else"). A third one (and you introduce "if-else-if-else"). That's the structure.

Now, give them a bunch of sounds (maybe in a shared folder, maybe in a website so they can download them). And tell them to choose whatever sounds they want and bind them to whatever keys they want. Once they have done so, they can make noise together (so you have a "make noise multiplayer game thing!"). That's the creative part.

The same with images - make an example with how to use them, and them give them a bunch of images so they can experiment.

Oh, also, when sharing stuff with kids, make sure that the folders are read-only. There's always the nasty little twat who tries to delete all the sounds and ruin the fun for everyone.

Another important thing to take into account is handling stuck students, and how that relates with time. Some of the kids will make a mistake when typing, get a nil error and get stuck. It's ok to try to help them out, but you could run out of time if you fix all the syntax problems everyone has. It would also not be fun for the rest of the students to wait for you (they have little patience). Estimate how much time you want to spend on each exercise, "unstucking" included. If you run out of time, have working versions of the code available, so they can download it and "keep up" with everyone else.

[IndieLöver]

Thanks everyone!

There's also the question of libraries: Would it be better to give them some libraries to work with (for collisions and/or camera perhaps) or should we teach them simple ways to do everything by themselves? What do you think?

[Fenrir]

I would recommend simple ways to do it themself to better understand how things work under the hood.

[qubodup]

(I did not expect this post to become *that* long... I hope it's somewhat readable )

Hello, this sounds exciting! I hope you and the kids have fun!

I'm currently in the middle of organizing a workshop http://espws.de/ to be executed at multiple locations.

Core principles are:
- Copy code from paper (inspired by https://www.youtube.com/watch?v=rch1FWJVNiE ) I consider this extremely important becuse they are used to handling paper and even when you're super at managing windows, their screens aren't huge enough to allow reading (while being able to look at the whole page) and writing at the same time. Additional philosophical comment: projectors suck, paper is personal.
- Don't touch their keyboard. In case that wasn't obvious to you (or other coaches) already: http://opentechschool.github.io/slides/ ... ll#donts_1 (inspired by teaching relatives to remember how to resize photos, print documents or importing photos from cameras)
- There is no internet (on one hand you can't rely on internet to work, no matter what anybody says, on the other hand I recently found that less motivated or tired kids might just start playing games, which is poison to the group).
- Modding. Aka "How REAL gamedevs learn to code™" (joke) aka "probieren geht über studieren" ("The proof of the pudding is in the eating." - what kind of translation is that?...). But yeah, abandon the dream of letting them develop their own idea if they don't have experience yet and instead give them the task to copy one project and then personalize/modify it afterwards.
- Put it on Android. My assumption is that the motivation from seeing your hard work run on a smartphone or tablet at the end of the workshop will have a more satisfying (and long-term effective) result than having had a smoother learning curve. Otherwise we would most likely be using Scratch.

So far we had 3 workshops, I participated in one of them:

We encouraged the participants to draw images to replace the ones we provided upfront. All prefered to draw on paper (we photographed it). It was a bit time-costy to color correct, resize and sometimes remove backgrounds, during the workshop and in the future I probably would not do it there but take the photos home and edit them there in preparation for the next day. Same with sounds (some participants liked the idea of recording sounds - mewos, barking and such - and when the others watched, they got interested as well).

At the other workshop, participants used paint.exe instead of drawing on paper.

Here are some of the images produced by participants so far:
https://twitter.com/ESPWS/status/606163558213292032

How many participants and how many teachers/coaches will be at your workshop? We had 4, 6 and 8 participants, so far with a rate of 1 coach per 2 participants.

At your event, will there be a speaker and participants are supposed to follow until all are done or the speaker continues or will participants progress at own pace with coaches moving between participants to assist where needed? As far as I know the teams talked 3 minutes at most at the beginning and proceeded to the latter mode quickly. At least that's what we did when I was there.

The speech content was: coaches basically just introducing themselves, showing the games that will be re-created and modified and explaining what the next step will be (use notepad++, which you can find in folder x to open the empty main.lua which you can find in folder y and copy the text from the piece of paper we gave to you but you don't have to copy the lines which start with two minus signs, those are comments).

We first provide printed, commented code, a somewhat simpler version than http://codepad.org/vM0RhKnq (which ends up being similar to https://play.google.com/store/apps/deta ... bodup.meow ) but with comments (not sure if comments are useful to students but they are useful for coaches to be able to help with it for sure). Participants are told to open an empty main.lua in a folder with a number of graphics and sounds to chose from* and write down the code.

*We don't tell them to chose and pick art/sounds at the beginning. If they discover it on their own: great, but distracting them from copying the code and hopefully understanding parts of it, by saying that they can use "any graphic you want and any sound you want and you could download something and you could record something and draw something" seems like a bad idea to me. When they're done with copying the first game - why not.

Once they are done with the first copy, we give them extended versions, for example the first version has only one sound and image, the second one has multiple and switches between them. There are multiple steps, the last one being making the game scalable (sometimes we skip it though).

The next step after finishing copying the last or second-to-last version of project 1 is to either modify that project or start copying another one. We have a selection of two others: one music looper and one catch game (which has vector math which is ugly and rather hard for 11-13 year olds I'd say). I'm working on a simpler type of the same game with only vertical/horizontal movement: https://streak.club/p/6142/minimal-lve- ... by-qubodup

The whole project is based on experience gathered at a workshop which I part-organized and co-executed last year: http://www.berlinminijam.de/2014/11/gam ... -kids.html

I have no experience with collision/camera libraries, so I prepared material in a way so that all functions have to be copied. We use distance and vector normalization and scaling but I plan to remove the vector norm/scaling for sake of simplicity. The material also ignores dt for the sake of simplicity.

The workshop goal is not to teach as much as possible (because we have two or three days). But to allow them to achieve as much as possible, so that they would have more confidence in the field and a higher probability of proceeding learning game programming using whatever methods they happen to run across (attending related events, noticing math as being relevant to gamedev, make changes to their game, etc).

By the way, here are some problems we have had so far:
- (major) Many kids are inexperienced at typing. This means that they write slower and get tired quicker than I wish for.
- (medium) I'm not sure about the quality of our printed code. I had to spend quite some time to have it look acceptable. Unfortunately, colored prints are extremely expensive. I'm using Latex: http://superuser.com/questions/601198/# ... 881_601412
- (minor) On one computer, Notepad++ seems to have forgotten the shortcut we taught it to run the project ( https://www.youtube.com/watch?v=oO83p7arA6w ). I didn't have the code readily avaialble and instead of wasting time researching how to set it up, I taught the participant to drag and drop the folder onto the love.exe file.
- (minor) We haven't had an opportunity to explain or even teach the process of porting to Android. I'm not sure yet that it's at all feasible with very young beginners. The main problem being that I don't understand much of the process and just know which commands to run.

Our experience with 10-14 year olds so far is that they get quite tired after 3-4 hours and progress becomes much slower.
I noticed that the ability to write function names and less faulty syntax highly increased between day 1 and 3 which was a great moment when I realized it.

Do you plan to port the games to android during the workshop?