[game_edu] Brenda Braithwaite's game_edu rant at GDC

[Dan]

I think there are a couple of things in play here. One is the art-oriented
focus of the program and, while we have success in the building of a
foundation of programming for the students, it's not always second-nature to
them, It basically becomes a breadth vs depth question. Still, the final
project for the second quarter of scripting is the building of a game in
PyGames and the students enjoy this. While most of the work I've seen come
out of this class are 2D app-like games (mouse in a maze, breakout clones,
platformers) , and often not completely original, they do exposes the
students to project management and working through design concepts, but.

 

.there is a concerned that the 3d-art students are presenting are lacking a
WOW factor and their Python projects often aren't portfolios pieces. The
plan is to expand the time the students have to work on their 3D
environments and characters with UDK seeming to be a better showcase for
those. 

 

I also think that it's a familiarity issue with some of the instructors.
Once the students leave the python class, none of their remaining classes
have instructors familiar with Python, and therefore the artists would be on
their own when implementing a Python script into any of their work going
forward. Ironically, Python was originally chosen since it's supported in
Maya, but the instructors for scripting haven't been familiar enough with
modeling software, and the modeling teachers haven't been familiar enough
with scripting, for either one to take advantage of that. 

 

All that said, I'm not all that familiar with the scripting in UDK. Has
anyone used both that and Pygames? What approaches to teaching seem more
suitable for each of them? Would the fact that the audience is made up of
artists make a difference in those approaches?  

 

In regards to app class, I'm of a similar mind, Ian. There's some pressure
to make sure the students have a mobile app by the time they graduate (I'm
pushing for expanding it to mobile or console since both Unity and XNA take
C# scripting) but that's far from a bad thing. As long as we get that done,
it's looking like we might have quite a bit of freedom in determining what
the exact points of emphasize are.  

 

--dan

 

  _____  

From: Ian Schreiber [mailto:ai864 at yahoo.com] 
Sent: Wednesday, March 09, 2011 8:10 AM
To: IGDA Game Education Listserv
Subject: Re: [game_edu] Brenda Braithwaite's game_edu rant at GDC

 

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/20110310/bb67c62c/attachment.html>