Help, teaching 12-13 year olds to code

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

I tried to teach my students OOP in the beginning but I am not sure how good of an idea it is without proper context. It may be a case of the cart leading the horse...

I tend to think OOP is overused and not fully understood by many software engineers/developers. That is not to say OOP is a bad concept or that it does not have good applications, but it is not a panacea.

I think given limited time my main priorities are to instil the concepts of variables (and the relation to algebra, which I consider important), program flow control (if statements, for loops, etc), rudimentary data structures (arrays, vectors, dictionaries/hash tables, ect), and file i/o. For 2D game programming I tend to stress mouse/keyboard input, screen coordinates, and vectors in 2D (I even try to work in some basic trig/Pythagorean theorem/use the Pythagorean theorem to derive the distance formula).

For me Game Maker worked well to teach basic OOP because every thing "was" an object. They were using OOP without having to really get into the full details of what it was.

I think it might be worth keeping in mind that the sheer amount of material you could cover is much larger than the amount of material you can cover in the time period. Also that such concepts are instilled typically in four years of schooling and if you have to build up the math, your looking at more like eight... If you are trying to condense that into a camp you must pick your battles!

I like the idea of Warcraft 3, but that involves money to buy enough copies of the game. Some parents might object to their kids playing such a game (you would be surprised), and it may get their hopes up a bit in terms of wanting to do 3D for everything. Why go to 2D when they were "just" using 3D? It may be a good idea to work in such things at the end of a course, but I am a bit dubious as to putting it at the beginning. Also in my experience the less you have to install on a school computer system the better. I can tell you right now that the school WILL object to putting a "game" on the computers, and good luck trying to get the kids to STOP playing it and do the more "boring" stuff. Also the computers I dealt with had the hardware acceleration disabled (or... they never had it to begin with), so I have a large amount of doubt that warcraft 3 would even run..

If I was going to do anything 3D, I might chose to incorporate Alice (or Storytelling Alice) because it would add some balance to the course. There have been groups using it with good results for motivating middle school girls to learn computer science. I do have to hesitate because I do not want to say certain things are for "boys" and others are for "girls" (which is generally a dangerous notion and one that should be avoided), but even so adding such concepts may appeal to students who prefer storytelling.

-

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).

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).
[/quote]
Did you even bother to read the rest of what I wrote? If you are going to quote me, quote the whole thought not just the section that you want to harp on. What I was suggesting was to let them write code without OOP until it becomes unmanageable for them. Then give them the extra tools as a solution.

Are you saying that there are no other benefits? Like code that documents itself? Or avoiding copy-pasting to implement similar but subtle differences in logic? How about code that can actually be tested in bits and pieces (components) rather than the whole damn thing at the same time?

Take care! OOP is dangerous since it is actually a concept for lazy programmers without a future oriented view. It is not realistic. In most cases reusability, the most important criteria in software development, is messed up. So after a somehow logical design, the code is misused often to suit to reusability, which brakes the OOP paradigms. Interfaces are important, OOP not. I programmed C++ and C a long time ago. Now Java. I never use inheritance in big commercial projects, and had success with this. After several years of programming and 5 years of studies, I realized that some people introduced OOP and nobody really asked, if this makes sense. The answer is, it is not reasonable!

[quote name='alvaro' timestamp='1346725535' post='4976278']

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).

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).
[/quote]
Did you even bother to read the rest of what I wrote? If you are going to quote me, quote the whole thought not just the section that you want to harp on. What I was suggesting was to let them write code without OOP until it becomes unmanageable for them. Then give them the extra tools as a solution.[/quote]

I did read all that. It's a good plan, but the emphasis on inheritance is misguided, in my opinion. I was only arguing about that part, so I only quoted that part. I think it's easier to follow the argument when following that style of quoting.

Are you saying that there are no other benefits?[/quote]

Yeah, pretty much.

Like code that documents itself?[/quote]

Code that documents itself is a good thing, but unrelated to inheritance. You can write clean self-documenting code without inheritance. I do it all the time.

Or avoiding copy-pasting to implement similar but subtle differences in logic?[/quote]

I am unaware of how inheritance helps with that. Extracting common functionality into its own function, particularly when you can give that function a good name, is extremely useful and should be emphasized to beginners. In the case of member data, more often than not the correct relationship is "HAS A", not "IS A", and you should simply have a member of the type that implements the common functionality, not inherit from it. Using inheritance as the default is a problem.

How about code that can actually be tested in bits and pieces (components) rather than the whole damn thing at the same time?[/quote]

I saw a Google tech talk once that advocated using polymorphism instead of using `if' statements in most cases, with enormous emphasis on testability. It sounds like an interesting concept, but I have never seen it put to practice.

If that's what you had in mind, you have a point. But this is not the way most people use inheritance, and it's unclear to me if this style of coding is appropriate for beginners.

There are many other things that are more important to learn. I would put the emphasis on defining clean interfaces between parts of the code and giving things good names. Beginners tend to think of code as something that a machine will read, but I think they should think about it also as something that a human will read, and they should make the human's life as easy as possible.

and then moving on to gdi+ game development

This is a hideous idea... GDI/GDI+ isn't designed for that kind of use. It's really designed for use with Win32 within a paint message not to be used at the kind of rate you'd expect to be drawing a game at.

If you're using C# and running XNA on a PC is out of the question can you not find a cheap Xbox and run their games on that?

On an unrelated note the best programming book I've ever read is actually "The C Programming Language" written by Ritchie and Kernighan. ANSI C is a very, very small language and the book covers them in a brilliant way. Particularly the language's enforcement of having variables declared at the top of the scope. If what alvaro says is true about the kids being able to handle the abstract thinking I see now problem with teaching them the more basic constructs at them before teaching OOP.

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).

That is a terriible terrible idea,
[/quote]

I have to second this.
As a kid I got started with BASIC.
The cool thing about basic is that you don't even need functions.

Your average 12 year old does not understand:
1. If statements
2. Functions
3. Loops
4. Variable Typing
4a. Variable declaration
5. Splitting code into different modules etc...
...

BASIC did not require any of these concepts to generate a cool result.
As a kid, easy success is a great motivator.

Since basic does not really exist anymore (Visual basic is more like C# / Java),
I am thinking one might think of toying around with java-script as a first language.
It does not require any of the above (you can even use undeclared variables in global scope).
It might actually be useful for the kids later.

Little by little you can add the more complicated concepts listed above.

The downside is And there are no easy input functions such as getch() or scanf(), and the javascript canvas is as complicated as any GDI library.


But I don't know any language with a graphics library as simple as basic:
SCREEN 13
COLOR RED
DRAW "r5 d5 l5 u5"

Regarding OOP specifically:
It is not a "Holy" concept.
As someone who learnt to program before good C++ compilers were available for home development, you can do a-lot without OOP,
Teaching it as the only way of programming is major mistake universities make today.
It causes programmers to believe that over-designing is a goal in itself.

[quote name='alvaro' timestamp='1346774276' post='4976454']

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).

That is a terriible terrible idea,
[/quote]

I have to second this.
As a kid I got started with BASIC.
The cool thing about basic is that you don't even need functions.

Your average 12 year old does not understand:
1. If statements
2. Functions
3. Loops
4. Variable Typing
4a. Variable declaration
5. Splitting code into different modules etc...
...

BASIC did not require any of these concepts to generate a cool result.
As a kid, easy success is a great motivator.

Since basic does not really exist anymore (Visual basic is more like C# / Java),
I am thinking one might think of toying around with java-script as a first language.
It does not require any of the above (you can even use undeclared variables in global scope).
It might actually be useful for the kids later.

Little by little you can add the more complicated concepts listed above.

The downside is And there are no easy input functions such as getch() or scanf(), and the javascript canvas is as complicated as any GDI library.


But I don't know any language with a graphics library as simple as basic:
SCREEN 13
COLOR RED
DRAW "r5 d5 l5 u5"

Regarding OOP specifically:
It is not a "Holy" concept.
As someone who learnt to program before good C++ compilers were available for home development, you can do a-lot without OOP,
Teaching it as the only way of programming is major mistake universities make today.
It causes programmers to believe that over-designing is a goal in itself.
[/quote]
A lot of what you just said makes me cringe...though I have already tried to make my point and I will move on.

However...BASIC is not quite dead. Blitz3D uses a bastardized form of BASIC. Unfortunately the license costs $60 and it requires DirectX (version 7 I think). I did not mention it before since the person who was starting the thread does not have the resources (money and decent video cards) to leverage it. I bought a license a few years back and developed a simple game on it. It is great for learning the fundamentals of working in 3d graphics and some people have made some really cool stuff with it. I stopped using it because the code became very difficult to extend and maintain. If you want to try it or any of their other products, see here:

http://www.blitzbasic.com/

Basic is useless, that is bad choice :-(

You could always use FreeBasic, as it has its own gas backend (mingw suite), and gcc backend (gcc)
it's very easy to get started, has all the "BASIC" commands, all the C commands, CRT, and whatever else you may wish for (such as threading)
but, i would not teach my kid basic.. it's too far from the "accepted" standard of C
if i were to start over, i'd choose C in a heartbeat.. or hybrid C/C++

frankly, i would vote for the guy who suggested python / pygame