[game_edu] Brenda Braithwaite's game_edu rant at GDC

[Ian Schreiber]

Out of curiosity - not that I have anything against the awesome people at Epic - 
I'm not sure I fully understand the move from Python. The only time I've ever 
used Python was with the (free, open-source) PyGame library, which enables the 
creation of actual games. Were you not using that, and if not, what exactly were 
your students doing in Python if not using it to make games? (I mean, I'm 
totally on board with the idea of having students make games, so I would 
consider any class where they *weren't* doing that to stick out like a sore 
thumb.)

As for having an app or mobile class, I can definitely see that having value -- 
Objective C, Flash, Unity... all of these are being used in the industry right 
now. That said, I've found that it's more useful to be more generic at the 
curriculum level so that you're not tied in to a particular platform or 
technology; the industry changes fast, and even though iPhone and Facebook are 
"hot" today doesn't mean they will be in four years, and it's nice to be able to 
keep the same classes and just adjust the content without having to rewrite the 
course catalog. That's my experience, anyway.

- Ian





________________________________
From: Dan <danc at narrativedesigns.com>
To: IGDA Game Education Listserv <game_edu at igda.org>
Sent: Wed, March 9, 2011 3:14:40 AM
Subject: Re: [game_edu] Brenda Braithwaite's game_edu rant at GDC

In response to the question Ian posed as to what techniques people have had
success in teaching programming to design students, I wanted to bring up the
experiences we've had in the 6 years or so of our program. Many of these
ideas have been addressed by others here; just wanted to add my experiences
to the list.

--Short answer to Ian's question--

1. Solid logic foundation
2. Progressively building on that foundation
3. Meeting the students at their level of understanding and vocabulary

--Much long answer to Ian's question.--

I've had the opportunity to work closely with the curriculum advisor for the
CIT program at our school; as a matter of fact, we are currently
re-evaluating the curriculum and the issue is what the right mix of
programming is for our curriculum has been a heavy (and surprisingly
painless) discussion of late. 

Our program is a Game Arts and Design program (BA) with a heavy emphasis on
art. Currently we offer 2 programming and 2 scripting classes. The point of
emphasis is to provide artists with the ability to communicate "across the
isle" with programmers and engineers while creating opportunities for those
with more ambition to develop their skills further. By in large, I'd say we
have been successful at this. 

Our first class is really a logic class wrapped up in a cover of game
programming. The students learn flowcharting and psuedocode, but they never
touch a compiler. We do pepper in a touch of C++ syntax (declarations for
example) simply because we feel it's easier to teach them a form that is
consistent with what they will learn their next semester.

The second class is C++. Here the students learn the language and a touch of
object oriented.
    
The scripting classes are in Python and end to focus on more robust
"programs" but with fewer rules. One reason we do scripting last is so that
we can focus the students on the more stringent and often easier to debug
code first so that they have a solid foundation of good techniques before
moving on to a more forgiving and therefore harder to troubleshoot language.

The successes in our program stem from forming a solid thought process in
computational thinking before we even expose them to having to write code.
We also use a "build-on-itself" series of exercises. For example, in the
first class they design a flowchart for a combat system with 3 choices (hit,
kick, grab.) By the time they finish the forth class, they have actually
coded it and added features modeled off of WOW's rogue's combat options with
multiple branches of selections, each with unique and semi-complex damage
calculations. An emphasis on talking to them in their own language
(explaining things visually and with common analogies instead of some of the
heavy tech-speak heard in traditional CS classes) is also a major help. 

That said, we are in the process of making some changes. We are likely to
switch scripting languages to UnrealScript as we are moving to an emphasis
of ensuring students will have created strong demos upon graduating. For the
same reason, we are considering adding an app/mobile focused class where the
emphasis is more on implementing design ideas than on coding (The plan would
be to have this as a final semester class.)

Lastly, we have recommended splitting the second class into two classes,
with object oriented being the third programming class they take. This will
allow 1) a few more weeks in Programming II for students to reinforce their
base skills, and 2) allow a bit more object oriented to be presented, but at
a slower pace. Amazingly, the request for more programming came from the Art
side of the faculty, as they came to the conclusion that the students just
did not have a strong enough demo reel/ portfolio without it.

Obviously, this is unique to our program. A design-centric program may have
different needs, and an actual CS degree would need a lot more. 

--Dan Carreker



_______________________________________________
game_edu mailing list
game_edu at igda.org
http://seven.pairlist.net/mailman/listinfo/game_edu



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/game_edu/attachments/20110309/fbed22fc/attachment.htm>