Jump to content
  • Advertisement
Sign in to follow this  
sunandshadow

Course In Game Design

This topic is 4718 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

Survey time again! ;) An internet cafe/gaming club near me wants to start offering a class in game design to highschool students. I want to design the curriculum and teach the class. Note that this class is only about the design phase: from idea to concept to design doc, script, concept art, and storyboard. So, what subjects would you like to see covered in a class like this? (Have a look at my game design textbook in progress to see the topics I'm currently planning to include.)

Share this post


Link to post
Share on other sites
Advertisement
50 views and no replies? Did I phrase the question wrong or something? Too vague? I would have thought people would have lots of opinions about what someone needs to learn to become a designer.

Share this post


Link to post
Share on other sites
Its a difficult subject, Design Documents as far as i've seen aren't very common to the public eye, and are difficult to make even for people in the industry. I do suggest if your going with a textbook class to improve the sections involving programming and/or technical limitations of hardware, since thats the area their most likely to be weakest in. You also have to keep in mind how long the course is going to be, and to see if the material you have can be covered in that time.

The approach i think i would take would be supplying them with examples of finished Design Documents(with their creators consent of course), like the one Alexokita recently put up. Then go about telling them some of the pitfalls of failed design documents (like the pure artist document, with no gameplay/technical details/unrealistic goals, or the programmers document with to much code information), there was a book or article on Gamasutra about that somewhere. Then have them take on specific roles (Your the artist, your the programmer, your the writer, etc) and have them come up with an idea and work together to create a design document, their progress/work being nudged/overviewed by their teacher.

I can't tell if i'm putting my foot up my arse or not, but thats my .02.

[Edited by - Gyrthok on June 21, 2005 3:00:13 AM]

Share this post


Link to post
Share on other sites
Hi, Sunny;

Having lectured this topic at college level for 4 years now, I've got some ideas of what works and what doesn't.

In general, very abstract concepts slide over them: they don't have enough experience to relate them to the games they play. If you mention something like risk/reward, you need to draw parallells back to things like "If there's a powerful weapon sitting at a very exposed location, you're forcing a choice.. risk to gain reward".

Small mini-game design are A Good Thing. We'd usually have 3 hours straight once a week, which allowed us to run a small game design competition. We'd divide the class into groups (4-5 people per group, usually keeping the same groups between sessions). We'd then give them a very constrained case, aimed at stress-testing a specific aspect of design (for example, 'design a ninja fighting card-game with minimum 5 units, using rock-paper-scissors as core mechanics', aimed at teaching them about cyclic balancing).

The first hour they design and build the game (make a physical components.. helps in visualization for many students). Second hour is for playing internally in the group, play-balancing/modifications. Third (half)hour is for rotating the groups around. One team-member remains behind to explain to the new group how their game works, and play one or two rounds with them.

Overall, the students seem to get a tremendous amount out of this type activities (more than, say, playing a game in class, watching videos, or listening to us talk). It also helps hammer in perhaps most important aspect of game-design:

Design. Test. Improve. Rinse, and retry.

Allan

Share this post


Link to post
Share on other sites
Thank you Odin, it's nice to hear from someone who has actually taught the subject. :) I'm interested to hear that you have your students working in groups - I was thinking of doing that too, for ease of management and because it's more similar to being in an actual design team. I was thinking that I should use the first class period to go over the concept of genres then ask the students what genre of game they are interested in making and pair them up that way.

The goal of the class is that the students will have created a large portion of a design document by the end, so I have to design my exercise around designing pieces of a larger game rather than small independent games, but I don't think that should be too difficult to do as long as the class isn't too large - if there are only about 6 groups I could customize the assignment for each group.

Share this post


Link to post
Share on other sites
I´ve worked as a designer for a bit over four years now and I´m not sure if you´re not putting the cart in front of the horse with your approach.
Design is a lot about experience and background knowledge, and while you can teach them basic design concepts they will not have either - especially since given the location and age group you´ll be teaching the exact same people that are being rejected by game development companies on a daily basis (young, enthusiastic, gamer, a thousand good ideas, no idea how to implement them, no real skills).

I still don´t think that design is a separate career choice you plan and train for, for that it requires too much of the basics. I´d rather you hammer some programming and art knowledge into them until they´re green in the face. Then, if they can at least do their own java games and draw semi-decent scribbles of whatever you tell them, then they can start learning about design. (imo) ;)

For your course I´d focus as much as possible on the practical aspects. They´re at an age where those of them who have potential are already going to be making games, or trying to. Teach them about planning a project, coming up with asset lists, effort estimations, task schedules, how to cut your feature pile, how to effectively evaluate the limitations of the team and project scope... simply: tell them in how many ways a game project can go wrong. They´ll have more than enough creativity, and there will be a few good ideas there. But at the moment their next step isn´t designing a great game, but MAKING a game. Any game.

Share this post


Link to post
Share on other sites
In a course in game design what you teach depends entirely on what you want the student to get out of the course.

I'd begin by explaining about the 3 different kinds of game designers.

1-The Artist - The artist has an idea, concept, or message that they want to express and is wants to design a game to portray this idea. Characters, Stories, and worlds all come easily to the artist.

2-The Mechanic - The mechanic has a feature whether technical, or gameplay wise for a game and tries to build a game around that feature.

3-The Analyst - The analyst identifies a market and needs and wants of that market and then designs a game for that market.

Perhaps in a later session you could talk about after the design document and the different roles that the lead designer may move to after the design is complete, which include:
Project Manager
Lead Programmer
Lead Artist
Business Analyst
Depending on the size of the team the designer may take on one or more of those roles.

I have to agree with Odin’s approach through of having the students design small games during each class would most likely be far more beneficial then having them work on the same design each class. If you want to do that then you can always assign it home work. But a lecture followed be mini design session to demonstrate what they just learned seems like a more effective teaching strategy.


Also I took a quick glance at your game design text book and it doesn't seem to have much on game design. A third of it is on story, and another third is on concept art. Where are the sections on develop the gameplay features, ensuring your gameplay is homogenous and not heterogeneous, developing solid gameplay mechanics, and how to work with in the limitations of your target platform and resources?

I’ve got an old design doc online you can see it at Chaos Factor It is very different from the one you have. Mine is part artist and part mechanic in terms of design, while yours is mainly artist in my opinion. Incidentally out of curiosity do you actual work from the design document you’ve shown? Because I personally found it difficult to read, and extract information from.

Good luck with your course.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hase
Teach them about planning a project, coming up with asset lists, effort estimations, task schedules, how to cut your feature pile, how to effectively evaluate the limitations of the team and project scope... simply: tell them in how many ways a game project can go wrong. They´ll have more than enough creativity, and there will be a few good ideas there. But at the moment their next step isn´t designing a great game, but MAKING a game. Any game.


I'd second that; around 40% of our module is focused around production issues like scheduling, budgeting, realities of the games industry, and documentation writing for different aspects of development.

The first two semesters I taught this module I tried doing the same thing as you're proposing (work towards a larger design doc). In the end I dropped it; a couple of reasons:

- Because each group has a different design, not every project lends itself to teaching a design concept (pong's not the ideal vehicle for teaching level-design)

- Competition is good (the students enjoy competing with each other for best mini-game each session)

- Completeness and testing (#1 newbie mistake is lack of follow-through. By forcing them to build a paper prototype, revise it and play it, you're also forcing them to go through the entire cycle, rather than be stuck at the "I wish/I want" cherry-picking stage)


Note, I also do ask each group to finish a complete game-design at the end of the module. I've got the luxury of giving coursework, though, which you might not ;)

Allan

Share this post


Link to post
Share on other sites
Quote:
Original post by sunandshadow
So, what subjects would you like to see covered in a class like this?


I could bombard you [grin], but it's probably better to ask: By the end of the class, what should the students be able to do?

ODIN's experience sounds very similar to the MDA Framework workshop I got to attend at GDC. Marc LeBlanc and the others put the class together with the philosophy that you can learn more about video games by working to capture their aesthetics with chits, dice and cards than you could with hours of programming.

Having said that, Hase leaves me torn. This *IS* the age to set them straight about their "I Wanna Be Like Mike" NBA aspiration equivalents. I think some overview of the industry, what designers do, what they get paid, and their chances for being one are a must. I'd spin it positively by urging them to get collaborative experience. If you can, PLEASE try to steer them away from the lone wolf ethos. I've encountered too many coworkers and aspiring developers who were so assured of their own vision that they couldn't see how much alike everything else it was.

(...meh, better quit while this is still short)

EDIT: Darn it, I can't find this year's GDC coverage, but if you can find it s&s I posted about MDA in the Game Design section.

Share this post


Link to post
Share on other sites
Well, the idea is that there are two sequential classes - a design one, where a game design document is created, and a development one, where programming and modelling etc. are covered. I'm only looking at the first one. There may also be a separate concept art class or scriptwriting class. So those are the content restrictions I have to work within. Other than that, everyone's comments are giving me a lot of interesting things to think about so far! :) I definitely agree that I need to do more on game mechanics, I'll probably work on that next.

Technogoth - Yes we do actually work from that design doc. Actually, I haven't had anyone complain about its readability before, what do you find problematic about it? As for getting info out, well, we're still at the putting info in stage, I'll probably reorganize the whole thing when we start getting into production.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!