next »

[Paul Eres]

week 2: get them to decide what kind of game they are going to try to make, have them write some type of plan for the type of game that they are going for

The way you say 'kind of game' and 'type of game' makes me think you'd end up encouraging development based on genre expectations, which might result in an abundance of clones at the end rather than the kind of experimental interesting stuff I like to see...

no i didn't mean genre in specific, just having them get a vision of the game in their head, and some type of design doc or at least an outline of what the game will entail

that said i do think making a clone of a game that someone likes is a great way to learn how to program: your first game is *supposed* to suck and be derivative, that's how you learn to make good games, by making bad games first. so if it's just a mario clone or a tetris clone or a minecraft clone that isn't as good as mario or tetris or minecraft, more power to them. you can't really expect a 14 year old to be revolutionary with their first game that they're making to learn how to make games

basically i think a bunch of experimental games are a good goal for a meetup or convention for experienced game developers, or for something like ludum dare, but not a good goal for beginners who want to learn how to make games. you need to learn the conventions before you can break them intelligently. e.g. if you can't code a shmup how can you code an anti-shmup art game like ceramic shooter electronic poem?

[Falmil]

Well, I am sure you could get them to make some more structured documentation for their plan as part of their coursework. You could also make each devblog require certain elements in terms of what they did, how it went well or not, and what they plan to do next.

In terms of topics to teach, I would definitely think you need to cover general programming and game programming concepts and fundamentals. HTML and CSS is a good start, but many people hit a wall when they encounter scripting for the first time, and I am sure you would not want them dead in the water. Some very short exercises, possibly something like implementing a module you've removed for a nearly finished game, would also be good to ensure they are understanding topics while still giving them plenty of time to work on their own projects.

[cystem glitch]

I dig everything in P's post except the only working on one project the whole twelve weeks thing. I think having them do 2-4 small games / prototypes in the first half of the program and then one bigger project in the second half would be better

[C.D Buckmaster]

I would also recommend having a collection of relevant tutorials online (like "how to create levels" for example) so they can learn to implement the features they want if they go ahead of the class, as there are always some.

[xrabohrok]

In my experience of trying to teach younger folk (14-19 year olds), the process of teaching something like this is a two front battle.  On one end, you got to convey that making a video game is nothing like playing one, and the ones that are in the realm of possibility are not MW3 caliber. On the other front, you need to figure out how to get something very technical and very creative conveyed to people who really have no idea what they are doing. 

Typically, the overall process is in phases, regardless of what is being done at the moment:

phase 1:  Everyone decides they want to make an FPS.  You illustrate why this will probably not happen.

phase 2: Everyone, save one or two brave souls, decide that they are going to stay on creative side of things, since it is "easier".  The "creative" people then immediately get into an argument about what they are making precisely, when they figure out that programmers are a finite resource.

phase 3: A good majority of the people decide to make a game with running and shooting and boobs.  This actually is a sign of progress, run with it.  When they say the character "jumps" ask them "how high?". 

...point is: be patient.  Keep the very technical bits away from them as long as possible, I'd recommend game-maker or mod something you've already got.  I liked to start with how graphics wind up with the computer, and slowly encroach into programming.  Don't force anything on anyone, especially if your group is comprised of a random selection of kids.  You will have to do a lot of the legwork at first, but when you manage to tease that first one into implementing that first enemy or weapon or whatever, that will keep you coming back.

And like paul said, get some sort of plan out of them, it helps in the longer run.   

The million dollar question that continues to bedevil me is how to get them to give it a shot on their own time...

[Droqen]

Whoa, jeez, don't even give them the option of being on the 'easy' 'creative' side. Why would you? D:

[Paul Eres]

I dig everything in P's post except the only working on one project the whole twelve weeks thing. I think having them do 2-4 small games / prototypes in the first half of the program and then one bigger project in the second half would be better

that could work too, but at the beginning stages i think it'd be impossible for someone just learning to program to make a game or even a prototype in that short of a period. even 3 months is a pretty short time for making a game, even if you work on it full time (and they are probably taking other classes besides yours). you don't want to overwhelm them with too much work

instead you could do weekly additions to their games, like one week focus on adding sound effects, another week focus on adding animation, another week focus on level design, another week focus on bug-fixing, etc., that'd give them some short-term goals

[anonymous]

Some things I liked:

instead you could do weekly additions to their games, like one week focus on adding sound effects, another week focus on adding animation, another week focus on level design, another week focus on bug-fixing, etc., that'd give them some short-term goals

I would also recommend having a collection of relevant tutorials online (like "how to create levels" for example) so they can learn to implement the features they want if they go ahead of the class, as there are always some.

that said i do think making a clone of a game that someone likes is a great way to learn how to program: your first game is *supposed* to suck and be derivative, that's how you learn to make good games, by making bad games first. so if it's just a mario clone or a tetris clone or a minecraft clone that isn't as good as mario or tetris or minecraft, more power to them. you can't really expect a 14 year old to be revolutionary with their first game that they're making to learn how to make game

week 1: introduce the different free engines that are available and encourage them to try them out and decide on one. after they've decided on one, tell them to read that engine's manual, immediately, all the way through, preferably twice. i would not force a particular engine (like GM or whatever), since different people work best with different tools

week 2: get them to decide what kind of game they are going to try to make, have them write some type of plan for the type of game that they are going for, and then start working on it; get at least something moving on the screen, and tell them to work on the game every day and to keep a public devlog. they can work in small groups if they want, or alone, either is fine (but if they are in a group, make sure that there's no 'one person does all the work' stuff, every individual would have to keep a devlog, not just a group devlog)

weeks 3-11: help them out with their games if they are having trouble, read their devlogs and make sure they are making progress, but otherwise leave them alone. meanwhile talk about various topics, at random, related to games; the history of games, famous game developers, pixel art techniques, how to playtest games, etc., there's a huge number of topics that are worth discussing, most of which have been discussed in these forums and in any other game development forums; introducing them to that type of conversation would be helpful

week 12: each of them shows their project to the rest of the class and lets them play it, and we talk about each others' projects. the end

Basically I liked most everything that you said Paul.  Weeks focused on specific areas of the game.  I will probably use Game Maker as I know it best and think I could teach it best.  In the off hours give them assignments and ask them to keep devlogs, keeping a collection of tutorials they could learn from.

@everyone thank you for your input - I'll see what it is like to teach game design.  I think I could get away without delving into the technical too much, deal with it as it arises, as I recall for me it's something I just picked up when I was faced with challenges in programming - but I will see how it goes.

I'll keep you posted.  I'm hoping to roster a class of 5-10 for the middle of next month.

[joshg]

I've used Alice in a high school Info Tech class and it's very accessible and gets basic programming concepts across.  However it's not going to produce anything close to a decent game as its built-in timeline and interaction models are pretty limited.

I am really, really curious if anyone's taught game dev to teenagers using StencylWorks yet as it looks really promising to me.  It has an accessible programming model similar to Alice, it has good asset management and a (somewhat limited) library of assets to start with, and it focuses on 2D (quicker and easier to work with than 3D dev).  However I haven't gone much farther than tutorial game templates on it myself.

[Derek]

I think Game Maker is a good tool to teach with, since it's fairly intuitive and also gives you a good idea about how a basic game engine is put together. Plus there are a lot of cool examples of finished Game Maker games to look at.

Take a look at my GM tutorials, because 1. they're geared toward non-programmers, 2. I try to use fun examples, and 3. they're aimed at teaching basic programming concepts alongside GML.

My experience from taking these types of classes is that there will be essentially two groups of varying motivation. Plan on letting the more motivated group move ahead on their own, encourage them to rely on GML over drag n' drop, and point them towards the resources they'll need to finish their games.

If possible, set up a web page where your students can show off their games at the end of the class!

[Absurdist]

I taught a very simple game development class to elementary schoolers (3rd-5th grade) last summer. It turned out that the kids weren't really ready for programming, so after a brief "hello world" lesson I moved on to teaching the specifics of making adventure games. I used SilverCreator (www.silvercreator.net); the visual nature of card-based systems was definitely helpful.

"What's the first thing you see when you start a game?" "Menus!" "Ok, here's a menu card." *teaches how to make buttons* "Now you click this, and the game starts. Uh oh, the stick man is under attack! What can he do?" This really helped such young kids conceptualize what can be a very convoluted process.

I put some of the games up here: http://arcadeoftheabsurd.com/waterside/home.html

[anonymous]

I'm going to take a card from the half semester I spent at Community College learning Computer Science.  In terms of class structure:

The teacher would give a lesson on various parts of a visual basic.  We'd learn two-three things during the lesson.  After everyone was told to download the same program, which was just say a calculator, with buttons that did nothing.  The rest of the class was spent by ourselves trying to make the calculator work like a calculator using the things we learned in the lesson and prior.

[peanutbuttershoes]

It would be cool to get some simple games from around here and get them to play them. Cactus games or anything kinda simple but fun would be a good way to help them get it in their brains the capabilities of game maker. Without crushing their spirit with generic TETRIS or PACMAN clones.

Maybe even using a GM game and trying to get them to reverse engineer it would be helpful to get them thinking logically and codey.

Although, I'm going to just say that I'm sure some kids just won't dig it, especially the logic side of it. And that'll be fine. All brains are not the same.

I dunno. Just a few thoughts. Take from that what you like.

[anonymous]

I dunno.  Just a few thoughts. Take from that what you like.

Haha yeah.  I'm sure in the end of this, I'll have quite the combination of tricks and lesson styles, it's going to be nice to flip through this for ideas if something in class just wasn't working right.  Though I'll have to set this on the burner for this month, taking my sweet but slow time to NY.  So yeah thank you everyone for the tips!  Always appreciated, keep them coming!

[14113]

I've so far been through 3 different levels of "formal" programming teaching, once at middle school level (?) when I was 14/15, being taught javascript and html, once at high school level (?), aged 16/17/18 and once at University level.

The main problem that I found with all the courses is that they found no way to teach creativity, and the overall picture while coding. Every course taught just the basic structure of the language, with no real links between each section of it, for example, one of my friends hadn't realised you could put a loop WITHIN a function. I realise that this could be hard, that there is no way of teaching every possible interaction between the fundamentals, but it's still something that needs to be addressed.

I would like to propose a new way of teaching programming: Example.
At the start of the term/course, give all of your students a set of example programs (incredibly well commented of course), of varying difficulty levels, and encompassing as much of the basics of the language as you can. Then, as you go through lessons, teach from the examples. Say you were talking about loops, or if statements, find examples of the structure from some of the programs (maybe 2-3 examples) and show what the structure is being used to do. This way, it teaches the kids how structures (like loops) are used as a TOOL, instead of being the means to an end. This way, I think, students would think more about the bigger picture than what each specific part of the code does, and end up being better programmers.

Of course, that's just to do with programming, not the overall game dev, but that's my 2c