[game_edu] Brenda Braithwaite's game_edu rant at GDC

[Dan]

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