• Advertisement

Archived

This topic is now archived and is closed to further replies.

Teaching Game Design

This topic is 5681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
Ooh...

Programs games AND has an impact on our youth. Impressive

Wish I could offer suggestions, but good luck anyway!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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."

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Right.

As I think I stated, I''m working to a time limit (2 hours if I''m lucky - you try getting 10-year-olds to sit still for any length of time ), so I can''t do much. I guess I really want to get them interested.

I see what you''re saying about it limiting their creativity. But isn''t there more of a risk, if I just let them roam free, that they''ll come back and say something like ''We want Quake, but with dinosaurs,'' rather than actually doing any real design work...

AP (the last one): you sure you''re not confusing design with implementation? I''m not going to a level where they''d have to deal with algorithms or code - it''ll be more the sort of level this forum reaches on a day when everyone feels apathetic.

chronos: I agree that they should be learning to design from scratch; however, as I said, my time limit prevents me from doing it properly. If I want to get them hooked, it needs to finish with them having completed something (which, hopefully, I can implement *gulp* so I don''t really want them coming up with too many curve balls ).

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

Share this post


Link to post
Share on other sites
Well I just finished a session of teaching game programming to high school age kids at DigiPen. (I''m 19 and a Junior, so using the term kids lightly :/ )

We tried teaching some basic programming right off the bad and noticed that our class got bored quite quickly. The trick was to keep making progress on something visible the students could see. Of course this means that your skimming over the basics at first, but that''s better then them not paying attention at all.

You also have to take into consideration that at most 1 of your students will be going into the game industry in the future. Your not neccessairly teaching to a class of people that are enthusiastic about making games, but would rather just come up with ideas for them (*cough* not that that happens here *cough*).

Instead of cloning an already popular game, we chose to make a very simple one of our own. You have to remember that the generation your teaching did not grow up with Space Invaders, Pac Man, and Galaga, but with Gran Turismo, Resident Evil, Mario 64, and other Playstation/N64/Saturn era games. We made a small game called cat and mouse where you play as a mouse trying to escape a cat that is constantly chasing you. We told them how to do the basics, and guided them step by step. We had them to do the graphics on their own and the gameplay code. Instead of spending days teaching them programming and having them each build their own engine, we had directx already handled via our IDE (FUN), and provided them with hundreds of game specific functions that did most of the dirty work. Even though all their games were pretty much the same, they looked different and seemed different to each of them. After they finished that, they were allowed to design and make a unique game for the last week of the session.

You should consider writing a very easy to use game engine and have them fill in the easy parts, and do their own graphics. Most likely they are not going to understand the programming after your session is done, so its best to let them have something they can say "they made" and give them the motivation to pursue development on their own afterwards.

This strategy worked pretty well for us. My class'' age was higher then yours, but the strategy to use is pretty similar. Don''t make the kids write the engine, just let them do the fun stuff. This is coming from a guy who thinks theres little (always exceptions) place for a "designer" with no applicable development skills :/

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

Preach on brother.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
I also agree with chronos that you need to eventually teach them how to brainstorm an original game. (snip)

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.



I don''t see the point of spending a lot of time on game design theory. They really can''t apply anything until they make a game. Maybe if the class manages to finish a game (read previous post), this could be important. Their ideas on what should be in games will not work because they are game players and not developers. They will better understand the concept part of the game after they have completed a cookie-cutter game and realize the work that goes into it. Otherwise your doomed to a class full of raised hands saying that there should be more swords in Final Fantasy, more/better cars in racing games, and even more crazier power-up ideas this side of Japan.

The parents will also think that the class is a waste of time if they come back with nothing physical to show for their work. Have them come back with a character moving across the screen and doing something when you press a button and the parents will be proud, and the kids interest may be sparked enough to continue in this wonderful industry.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
Sadly, while I agree that the best way to show them how much effort goes into a game is to get them to make some themselves, it''s not an option.
While you''re right that they didn''t grow up with games like Tetris or Pacman (and I did? gosh!), they still recognise them. Part of what makes such games ''classics'' is the fact that they still have a fairly strong fan-base. My brother, who may well be in the audience (if he has the time), still plays old games such as Pacman or Brick Bash fairly regularly. I don''t think I''ve influenced him to it much... While they might moan "aww, Pacman?" to start with, I''m pretty sure that once they sit down and try and find ways of improving it, they''ll wake up a little.

quote:
Original post by BaShildy
They really can''t apply anything until they make a game. Maybe if the class manages to finish a game (read previous post), this could be important.


Well, I''m hoping to implement the game for them. Ultimately I''m not trying to get the creation of a game as I am trying to build their skills in creative thought and analysis of games.

quote:
Their ideas on what should be in games will not work because they are game players and not developers.

WHOA! Back up there! Are you saying that developers are the only people who can design games properly? Given that those ''game players'' are our audience, surely they know what they want and can therefore ask for it?
However, yes, they do have a tendency to ask for too much. I''ll have power of veto over what goes into the ''final design,'' but many of the best ideas are both simple and easy to implement. Sure, if they want me to convert Pacman to a 3D realtime MMOG, I''ll hesitate (to say the least ), but adding things like a countdown timer or different maze layouts wouldn''t be a problem.
That''s why I''m giving them Pacman rather than a blank sheet; Pacman is a fairly simple base, so they *can''t* make it too complicated.

quote:
They will better understand the concept part of the game after they have completed a cookie-cutter game and realize the work that goes into it. Otherwise your doomed to a class full of raised hands saying that there should be more swords in Final Fantasy, more/better cars in racing games, and even more crazier power-up ideas this side of Japan.


Agreed.

quote:

The parents will also think that the class is a waste of time if they come back with nothing physical to show for their work. Have them come back with a character moving across the screen and doing something when you press a button and the parents will be proud, and the kids interest may be sparked enough to continue in this wonderful industry.


Well, no-one''s paying for the talk (I''m just trying to get people interested), so if they do waste an hour or so, it''s no biggie. I hope to send the kids away with a design document; at the very least, with ideas. I''m sure the parents won''t mind as long as their kids are having fun.

BaShildy, I have a feeling you didn''t read the rest of this thread properly I still value your input, as I do hope that some of the more enthusiastic among them will want to get involved (and perhaps work with/for me), and so will probably be teaching them some programming at some point (perhaps in my gap year).

Unless anyone has anything more to say, I thank you all for your suggestions; I''ll let everyone know how it went.

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

Share this post


Link to post
Share on other sites
Is this a class or just a one-time lecture? If its just a one-time lecture, then yeah I misunderstood.

- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
quote:
Original post by BaShildy
Is this a class or just a one-time lecture? If its just a one-time lecture, then yeah I misunderstood.


It''s a one-time lecture, with the possibility of follow-up one-time lectures. :D



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

Share this post


Link to post
Share on other sites
quote:
Their ideas on what should be in games will not work because they are game players and not developers.
--
WHOA! Back up there! Are you saying that developers are the only people who can design games properly? Given that those ''game players'' are our audience, surely they know what they want and can therefore ask for it?



Yes I am. This can be applied to the movie industry as well. Many of the audience if asked what do they want in a movie would end up being less thought out and not as enjoyable as if the people making the movie just "did their own thingTM". The audience does know some things that they want, and developers should always listen to their audience for feedback.

As a reference to the audience not understanding what they want, check out a game review site like IGN and read their forums for a few minutes. Every once in awhile some forum goer will come up with a GREAT GAME IDEA that would not make a good game. Most of these ideas suffer from ENG syndrom (Epic newbie game), and are made by people that don''t understand the process of design. I''m a big community guy, so I think developers should always listen to their criticism and use suggestions given to them. But I also believe you can not fully think through game design, until you have actually developed a game.

There is a healthy population of people on this particular forum that believe they are a fully fledged designer based on the amount of games they''ve played and "studied." I believe this is hogwash. I''ve always believed you learn best by doing, and not studying. Others believe different, and are entitled to it. That''s mainly why I''m at DigiPen instead of a 4-year university. I learn by doing, but guidance is essential for long-term growth. You can''t go down just 1 path and know everything.

I also think that game concept design is highly overrated and not very important in the quality of the game once finished. As soon as I hear someone talk about their epic vision, i start to snicker because I know that from concept to gold, that the game never fully resembles what it was in the concept stage. You stick to what is fun in your game, and you evolve the design as you figure out what works and what sucks. That''s why I believe non-artistic or non-technical designers are not that important to the team (this does not in anyway refer to writers). The real design happens through the tweaking and restructuring of the game during the development cycle, and not the 1000 page document explaining the vision at the beginning.

Documentation is by all means damned important, but its also not set in stone. It should evolve as the game does, and be up to date as much as possible. This goes for the concepts as well as the technical side. The only people who can really do the evolution part are the people who are responsible for the development of the product. Only they can tweak in real-time and see the little problems that stand out. A guy who just comes up with "designs" on paper could never have that kind of control as a designer/artist or a designer/programmer.

Oh well, reply became uber-rant. Sorry for going away from your original topic.






- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
quote:

Bashildy
Their ideas on what should be in games will not work because they are game players and not developers.

superpig
WHOA! Back up there! Are you saying that developers are the only people who can design games properly? Given that those ''game players'' are our audience, surely they know what they want and can therefore ask for it?

No, I think he''s alluding to the fact that the average game player merely says things like "I want a game with graphics like Final Fansaty XXVI, and all sorts of cool bad guys, and bombs and guns and swords and..." We''ve seen the like from beginners too many times. By "developers" (and I believe he uses the term loosely), he means people who have deconstructed games and understand the fundamental building blocks, the intrinsic challenges, the limits of current feasibility - people who know what can be done, what can and should be improved, etc.

[offtopic]
quote:
Original post by Chronos
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.

Emphasis mine. Theoretically, you could teach computer science on Babbage''s difference engine. The real point of that statement is a lament of how many young people go into computer science because they are "into computers". Computer Science has to do with computing; it''s basically applied math.

Share this post


Link to post
Share on other sites
Oluseyi: I know, I just wasn''t sure, so I thought I''d budget for both possibilities.

BaShildy: I disagree with you over the importance of the design document - as a programmer, my rule of thumb is don''t get involved in a project that has no design document.
But aside from that I know what you mean. It''s a pity, really; I guess I still hold out some hope of the developers (i.e. the ''real deal'') being able to ''coach'' the public through the process; asking them questions to get out the relevant data, and so on.
I guess I did neglect the fact that most game developers play games too of course, as discussed in the lounge, we seem to see games differently...

Right, I think we can get back on topic now.

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

Share this post


Link to post
Share on other sites
quote:
Original post by superpig
BaShildy: I disagree with you over the importance of the design document - as a programmer, my rule of thumb is don''t get involved in a project that has no design document.



No disagreement here. I also follow the same rule. I fully believe in having complete documentation before the coding starts. My point was that the game shifting away from the original "vision" is a good thing, and the documentation should stick with it. I''m against a designer who gets angry that the game is getting away from his vision, and supportive of a team who''s goal is to modify the game during development to make it as fun as possible.

quote:
Original post by superpig
But aside from that I know what you mean. It''s a pity, really; I guess I still hold out some hope of the developers (i.e. the ''real deal'') being able to ''coach'' the public through the process; asking them questions to get out the relevant data, and so on.



Again no disagreement here. When you get emails from gamers saying what your next project should be ( insert what Oluseyi said :/ ), they are useless for the most part because well as Oluseyi said:

quote:

...people who have deconstructed games and understand the fundamental building blocks, the intrinsic challenges, the limits of current feasibility - people who know what can be done, what can and should be improved, etc.



I believe you should be in constant communication with your audience, and find out what they dislike about your project, and change it if possible. If you don''t listen to them, they will go to the developer giving them what they want. And what they want is more important what you want IMHO.

quote:
Original post by superpig
I guess I did neglect the fact that most game developers play games too



Actually I''ve gotten back to playing games more regularly, schedule be damned! Last year was really rough on me, so I simply had to give up on playing games regularly. The day i stop liking games is the day I''m out of this industry


quote:
Original post by superpig
of course, as discussed in the lounge, we seem to see games differently...



I''m sorry, I don''t remember the discussion. Do you have a link? Hopefully what your refering to wasn''t during the end of my last project, in which I was exhausted and hated everything about games You gotta love the last few days before release.

quote:
Original post by superpig
Right, I think we can get back on topic now.



Oops :/



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
BaShildy,

*sigh*

Just because players with no programming experience often propose overly grand concepts for games it doesn't mean they can't be guided to go along reasonable lines. That's what the teacher is there for, don't you think? I think it's far too easy to underestimate what people can do given the proper guidance and encouragement. Remember, the idea is not "design any game you like", but rather "how might we approach a game where the player ..."

[edited by - chronos on June 30, 2002 12:50:26 AM]

Share this post


Link to post
Share on other sites
Always underestimate people. That way you wont be disappointed

Share this post


Link to post
Share on other sites
But how will they realize its overly grand until they are the ones that have to implement it. I think the overly grand concept is created because they don''t understand the implementation phase of development. That''s why I think you can''t really understand your design, until you''ve developed one before.

Obviously theres a path from player to developer, and the guy who makes outrageous requested as a player could some day make games. I just think theres no quick path from game player to epic game designer. You can''t design games 2 steps above your development skills and expect them to work and be fun. I guess I''d rather have level designers and writers helping me with content over pure designers. I''m more into the team effort thing rather then 1 man''s vision. Anyone at any level can give suggestions, and sometimes they are really good.

quote:

Just because players with no programming experience often propose overly grand concepts for games it doesn''t mean they can''t be guided to go along reasonable lines. That''s what the teacher is there for, don''t you think?


Yeah, but they need to learn it on their own as well. I just don''t believe you can go from game player to designing RPG''s/FPS''s strictly by playing games and studying them. You have to be active in the development of lesser games to be able to work on greater games. With my class we started small, and we did some great stuff in 2 weeks. We focused purely on development, and we always gave praise to students who were succeeding. They can now go onto to better games, because we helped guide them at the early levels, and they now have experience in developing small games.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
Nobody here is proposing that the kids design an RPG or any sort of "epic design". You seriously underestimate kids if you think they're incapable of coming up with some simple game mechanics. If they get too ambitious it's a simple matter of being honest with them and guiding them toward a less ambitious proposal.

[edited by - chronos on July 1, 2002 1:21:58 AM]

Share this post


Link to post
Share on other sites
Oluseyi (offtopic):

Apologies for continuing this offtopic discussion, but I'd like a chance to respond to it.

quote:
Original post by Oluseyi
Theoretically, you could teach computer science on Babbage's difference engine. The real point of that statement is a lament of how many young people go into computer science because they are "into computers". Computer Science has to do with computing; it's basically applied math.
Going into computer science because you're into computers is no worse than going into music because you like playing the electric guitar. Sure, computer science is the science of computing, but it's also the science of computers, these being computing machines. Just ask yourself what the "science of computing" would be like without the existence of non-human computing machines and you immediately notice a relationship between the need to program computers and advances in computer science. Computers depend on algorithmic problem-solving more so than humans, humans being very effective at solving many kinds of problems without the need for a mechanical, algorithmic approach.

[edited by - chronos on July 1, 2002 3:15:30 AM]

Share this post


Link to post
Share on other sites

  • Advertisement