Teaching Game Design

Started by
29 comments, last by superpig 21 years, 10 months ago
I''m giving a talk to a group of students (ages 8-13) about ''game design.'' I''m thinking about what to go over with them; ultimately it has to include something hands-on, because that''s more "fun." My current plan is to gather a couple of Pacman clones, and then demonstrate each of them and look at similarities and differences. Then, get the kids to try and come up with their own improvements to Pacman. (I figure that''s easier than trying to get them to design a game from scratch; also, there''s a possibility I could actually implement their design that way ) I don''t know if anyone here has done anything like this, but does anyone have any suggestions, tips, or advice of any sort? Thanks in advance... Superpig - saving pigs from untimely fates - sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Advertisement
Ooh...

Programs games AND has an impact on our youth. Impressive

Wish I could offer suggestions, but good luck anyway!
It's not what you're taught, it's what you learn.
I''ve often thought about taking a teaching position. However, there would be a greater demand for my math skills in the public system than my computer skills.

My thoughts have often leaned towards doing a mock up company department. I would teach programming, but at those ages you might personnally want to set them up as a different department (like game and level design).

Network some computers together and try to teach them to comunicate using an intranet. Have them primarily coordinate through the PC although they would have meetings and brainstorming sessions.

Have them play Quake Team Arena for team building skills.

Some thoughts...

-James
Wasn''t he giving a talk on Game Design and not Game Programming?
Both are a totally different ballpark.

If your teaching them design then teach them all the basic concepts of designing a game; try to explain things such as designing for a target audience, types of genres, brainstorming ideas of almost anything, working in groups to come up with ideas, accepting feedback from each other about good and bad ideas they have, and also the most important part of design; if its not fun at the beggining of the design then dont go any further with it..

If its programming then well, for ages 8-13 the best you could do is teach them some basic things.. plus at those ages do you think Quake would be allowed in a school situation?

quote:Original post by Anonymous Poster
Wasn''t he giving a talk on Game Design and not Game Programming?
Both are a totally different ballpark.


quote:Original post by James
I would teach programming, but at those ages you might personnally want to set them up as a different department (like game and level design).


-James

"It is easier to get forgiveness that it is to get permission."
Game design is much more important than programming.
quote:Original post by Mr Saturn
Game design is much more important than programming.

More correctly, design is much more important than programming. And while we''re at it, computer science has very little to do with computers.

Anyway, superpig:
Tell them about the importance of a basic premise, objective and path to a goal. Since it is a game, there needs to be some form of action or activity to progress along the path (you can save the non-linearity talk for some other time) - from whacking bad guys to talking to people to sniff out clues. Don''t worry about demographic data or focus; just get the kids to come up with a simple idea (perhaps based on one of their cartoons - that should provide ample story and logical actions) and a way to finish the game.
Thanks for the replies:

quote:One of the APs said:
If your teaching them design then teach them all the basic concepts of designing a game; try to explain things such as designing for a target audience, types of genres, brainstorming ideas of almost anything, working in groups to come up with ideas, accepting feedback from each other about good and bad ideas they have, and also the most important part of design; if its not fun at the beggining of the design then dont go any further with it..


Mmmhm. I was definitely going to try and put them in groups; the only problem being that kids of that age tend to be a tad immature and as such it would have to be carefully controlled. Otherwise it''ll just turn into ''my paradigm''s better than yours!''

What do people think about the idea of getting them to improve on an existing game? An arcade game (in this case, Pacman) doesn''t have many of the same ideas as other games (such as linearity or plot), so I won''t need to teach them as much; and given that we''re talking about the age group which probably plays more games than all the other groups put together, they''ll probably have some inspiration at least.

Programming: I did give a programming talk to (what I expect will be) the same group of kids about a year ago. Most of them attended as a way of getting out of prep (supervised in-school homework), but a couple of them have been experimenting with VC++ Introductory, and conversing with me via email about how to do things.
I think to properly understand programming, you need a good understanding of how the machine itself works. These kids don''t have that. I could give them a crash course (the session can only last 1-2 hours) but it would probably do more harm than good.
Of course, I will teach them that you don''t need to be a programmer to make games. Soundman, artist, modeller, and so on...

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Superpig,

Cloning games is perhaps not the best way to teach game design. Have you thought about suggesting an original yet simple concept for them to build upon instead of having them extend Pacman? They might learn better that way, being less constrained by their expectations. You could do that and still use Pacman and other games as examples.

quote:Original post by Oluseyi
And while we''re at it, computer science has very little to do with computers.


Computer science has very little to do with particular brands of computers, but consider how Donald Knuth''s insistence on using MIX/MMIX in his Art of Computer Programming books has much to do with the idea that computer science as the study of algorithms is not at all independent of the concept of a computer machine.
Although I agree that cloning games is no way to learn how to design and build games, the notion of improving on the game does settle well in my stomach. Here''s why:

Cloning a game simply requires memorizing algorithms and sometimes not even that (code plagarism?). However, for them to build upon the existing infrastructure, they have to understand the underlying foundation before they can improve upon it. (That sentence has two redundacies. Sorry, but I hate when I make a mistake and when I''m inefficient.)

I also agree with chronos that you need to eventually teach them how to brainstorm an original game. Gameplay. I wonder who in the idsoftware realm came up with the idea of Teams and objectives. (I know it wasn''t John, he''s stated he hates objective gameplay).

Try having them anaylize more than one type of game. First person, third person, puzzles, action, roleplay, etc... Then have them ''tear down'' and rebuild your pac-man games. Try and have them reinvent the game with a unique perspective. Doesn''t even have to be pac-man when they are finished.

These ideas, gentlemen, do not reflect the opinions of this broadcasting station. Any characters in this post are purely fictional and any similarities to those living or dead are purely coincidental.

This topic is closed to new replies.

Advertisement