Help, teaching 12-13 year olds to code

Started by
29 comments, last by albert666 11 years, 7 months ago
I have no idea of the number but I am running a small club next week and I would like help with ideas teach them, I thought teaching the lua first for something called t-engine 4 (google it) was a good idea for the first 2 terms ( til christmas) and after that teaching them c# for a term (7 weeks) and then moving on to gdi+ game development from a book called "visual c# game programming for teens" by Jonathan s harbor. I have been programming around 2 years on and off.

Do you think this is a good idea? Or if not, can you suggest a good alternative

I have a friend and he has done java for around a year

Thank you for your time
Advertisement
Personally I find python easier than lua although maybe you should consider going even easier with scratch instead. There was some "ruby for kids" thing I saw about awhile ago too. Lua I dunno why I just didn't like it. C# might be too difficult, its not really a beginners friendly language and at the age of 12 they will want to see results, they can get those results much quicker in scratch while being introduced to programming concepts. Then after christmas python or something.

T4 seems simple enough to an adult but I don't think a child will like it much, scratch I have personally seen the results from 8 year olds and they enjoy it far more before then moving onto other languages.
These arent stupid kids though, they are the top 20% of intellect in the country and I am proud to say I one of them with them. And the reason I said lua was because of t engine which believe me is good
Someone correct me if I am wrong...I was under the impression that GDI+ was *intended* for graphics in windows controls. Sure, it can be used for games but why do that when XNA is handy (provided you are using c#)?

Maybe I'm stating the obvious but if I was teaching kids my first priority would be to get them to understand the concept of OOP (mainly inheritance). I know that may be quite a leap for children...but if they they do not understand OOP first then they will never be able to fully leverage a game engine (or modify it to suit the particular kind of game they want). My approach for getting them to learn OOP would be to have them write a simple game without it...then start having them add bits and pieces of extra functionality until the code becomes unmanageable for them. Then present inheritance as a solution. Then they will have an obvious and painful reason to learn and understand OOP concepts.

I hope some of that helps...
The reason we cannot use xna is because the computers at school have 16mb integrated graphics that I believe has directx 7 so xna is out of the question unfortunatley
I thought a 6 month programming and game dev class to a few kids all in that same age group. I used Python though, since it's the language that is closest to English and is assumed the easiest language to learn. It was a pretty fun class, by the end of it each student had made there own (simple) 2D game in Python using the Pygame library. I also covered some basics of pixel art for a 8-bit art style, so that on the days they didn't feel like programming, they could work on the artwork for their game. They liked that because every bit of code and art was all theirs, so the each game was completely unique.

I spent the first 2 months teaching them Python. I found that this was the most boring part of the class to them since you weren't doing anything visual. So in attempt to make the class more fun, we made a lot of text adventures. Started off mostly with just a bunch of if/else statements, then added in some more complex stuff, and I thought them some basic OOP.

After teaching them Python for a couple months, I felt I was loosing their interest a little bit (they are 12-13 years old and typing isn't the funnest thing to them). So we steered a little bit away from programming and I thought them a lot about pixel art and game design. Which got them absolutely pumped to make their own game. They immediately started planning their games and working on the art. I was pretty clear on them being as fun and creative as they wanted, but also gave them a decent understanding of what was actually possible in the time-frame we had. We did a 'Design' phase of the class where we just planned and drew a lot of pixel art for just under a month.

We then spent the last 3 months just working on our games every class day. I only taught the class Monday-Wednesday-Friday, which is probably why they didn't get bored of doing the same thing each day. I made sure to HELP them answer any questions they had. I didn't just give them all the answers on how to do everything, but helped them teach themselves.

There was a lot of collaboration too. The first half of class was spent as a class talking about new concepts they wanted to add to their games (collision detection, tiled maps, etc), then I would teach them one or two ways to do what they wanted, explaining the 'hows' and 'whys' in ways that made sense to them. Then the second half of the class I just walked around the class room talking to each student as an individual, and helped them by answering any questions and giving them ideas on how to implement their own ideas.

There where definitely days when none of them wanted to work, so on those days I would go to YouTube and we'd find some game dev videos by other people showing off what they have done and their idea, this was great because it sort of 're-motivated' the kids and sparked some new ideas. I also showed them a lot of completely finished and polished 2D games to give them some more inspiration and ideas and let them play these games (if they wanted, which most of them did) for the last 30 minutes of each Friday class.

It was definitely a fun class to teach even though it had a few difficult days, but the kids loved it. They all finished their own 2D game by the end of the class, some better than others, but all of them totally unique. One kid made a platformer, and another made a pac-man clone (with much more basic AI), and the others had games in between.

Some things the kids really liked about the class:
-They got to make their very own game, no rules (within school policies), no limits. Each game was completely custom and all of them where different.
-They drew all of their own art for the game. Which just made it that much more unique.
-I didn't have any 'tests' or 'quizzes', I just gave them a pass or fail grade depending on if they where actually working and trying to complete the class (all of them passed).
-The last 30 minutes of each Friday class was 'game time', where I let them play some 2D games (kept it 2D to keep it relevant to the class).
-How I HELPED them solve their problems, instead of just give them all the answers.
-They really liked that for the second half of the class, they worked on their own stuff instead of me lecturing the whole time.
-I never actually gave them a 'lecture', it was always more of a discussion. I found that going to rants about say, tiled maps, just confused and bored them to death. So I discussed with them things they wanted to implement and ideas on how to implement them, with the exception of the basics (such as collision detection, movement, etc).

Some things they didn't like:
-Some days they didn't feel like programming at all. I found that having them work on art instead on those days helped a lot. But there where some days they didn't want to do art either, that's when I pulled at the game dev videos on Youtube of other people projects, and I showed them a lot of my projects too. This kept them motivated and interested.
-For the first few months when I was teaching them Python, there wasn't anything visual, text adventures where the best thing I could think of, but they are 12-13. Words can only be so interesting to them. Just make sure you have a few pizza and game parties. That really helped them to have more fun and it made them like me as a teacher a lot more.

I had a small class of only 6 students, so that made the 1 on 1 time with them possible, if your class is much bigger than that, you probably won't be able to do that. Or you won't be able to talk to each one every day. But I really think the 1 on 1 time really helped them open up and get their own personal ideas into the game. I found that when I was more talking to the whole class, all of their games where looking similar, but when you talk with each one, you help them to add their own ideas to it. Just some advice anyway. I really enjoyed teaching the class, and for the most part, so did all of the kids.

For that age group, I definitely recommend using Python/Pygame though.
Great, I know very basic python/pygame. That story has really inspired me. Thank you, that is going in my permenant notes
I worked with middle school students for three years as part of my undergraduate research. We taught them game programming and I went down similar lines of thought. Let me try to share some of what I learned with my groups.

1. I found that C# and XNA was very overwhelming to that age group. The problem was not necessarily the concepts but the mere typing. While kids might be good at texting, they had trouble with typing at a decent rate. Also they had trouble locating punctuation and other "special" keys. This lead to frustration and caused kids that were not as good at typing to become discouraged. It is possible that the demographics and area involved (I did the work in Texas) might play a factor, but it is something to keep in mind. Also please note that I am not trying to generalize. I am sure there are kids in that age group that are perfectly capable of typing at high speeds, but this was my general observation among three groups. A few were able to keep up, but more were struggling.

We also provided the students with laptops that they could take home. This helped work around the problems involved with school computer labs.

2. I switched to Game Maker and had great results with that program. Game Maker provided a nice visual jump start, kept the student interest, and provided the GML language for students that wished to go further with their creations. Every group was able to produce a fairly nice game at the end of the camp in Game Maker. We stressed the math and science aspects as well as working together in a team. We encouraged the students to design, plan, and decide the game content together as a group and then do a presentation at the end of the course in front of an audience of their parents/peers.

3. We augmented the Game Maker with art at some camps, but we had real success with adding Lego Mindstorms. Some students really liked the hands on approach of the legos much more than programming games. Also building and programming robots helped with their game programming as well.

The thing you need to realize is that kids at that age are a bit of a mixed bag. Some of the kids are going to be very into the course and they will blow you away, while others for various reasons will be less interested. One thing I did note was that if some kids got disinterested it was very easy for them to cause even the focused students to also become less interested. I think the way to minimize this is to provide enough different roles and activities to allow every student an opportunity to use their talents and to contribute to the project.

Some other things to note:

1. I said we provided students with laptops. This was both a good and a bad idea. Some students lost their laptops, broke their laptops, their parents used their laptops, etc. It may be a good idea to not let the students take home such technology until AFTER the camp is over.

2. It is important to convey (as previously mentioned) what is possible in the time frame. Some students wanted to create 3D games and other complex things. Try not to immediately dismiss their ideas but take the time to explain to them WHY the idea would take a long time. It is a good opportunity to have them appreciate the amount of work that goes into their favorite games.

3. I found that using a very impromptu teaching method yielded the best results. I would let the students guide the direction of the course based on what they wanted to see. I tried to develop a lesson plan that left plenty of time for deviations and questions. Don't try to be too rigid in your teaching and be capable of adapting quickly if required. For instance one day the entire computer lab was down and so we used the opportunity to talk about storyboarding, and concept art. I had paper and other art supplies available at all times. I had a seperate laptop so I could also show how to solve particular questions.
Maybe I'm stating the obvious but if I was teaching kids my first priority would be to get them to understand the concept of OOP (mainly inheritance).[/quote]
That is a terriible terrible idea, and probably the reason why so many beginners tend to create complex class hierarchies even in the most trivial situations, and even though it doesn't buy them anything. Inheritance should be used about as often as function pointers are used in C programming, and for about the same purpose (multiple dispatch).

About the original question, I just want to say that 13-year-olds are perfectly capable of abstract thought and most of them probably don't need things watered down. Teach them real programming, and the choice of programmin language(s) is not all that important.
I suspect most of the members of this forum (me included) picked up programming when they were around that age.

In my opinion, you should not water down concepts like OOP to "suit their level". as alvaro said, if you're going to teach them OOP, teach them the right way of doing things.

I reccomend starting with a game such as warctaft 3, whose minimum requirements are very low. have them play thegame for ~3-4 days so that they grasp the game mechanics, then introduce them to the editor. the Warcraft 3 editor is *very powerful* and allows one to modify almost every aspect of the game. show them how triggers are written and how every entity is the game is present as a different object. you can subtly point them towards OOP concepts if you plan it right. Also, once they are familiar with the trigger system, you can show them the underlying scripting language called JASS.

This IMHO is the best method because
1) there's a nice looking editor which lets you place objects, modify values etc without taking too much pain
2) it lets you teach them about scriipting, triggers, as well as various math concepts taht ypu'll have to use (vectors, measuring angles in radians to name a few).

I wish you the best of luck :)

a WIP 2d game engine: https://code.google.com/p/modulusengine/

English is not my first language, so do feel free to correct me :)

This topic is closed to new replies.

Advertisement