[game_edu] Reasons TO (not) teach game dev

[pawlicki at cs.rochester.edu]

I should really clarify what I'm saying. My point is that for
the greater part the environment doesn't really matter at all.
The conceptual knowledge is independent of the SDK used.

If that is true then one might as well just teach "programming"
(or "media studies", or other foundational topic) rather than "game
 development". Game development might properly be considered a
subset or application area of these other areas.

I'm contrasting two groups of Freshmen that I have this term.
One group is in the standard intro programming course using
vanilla Eclipse/Java/Swing. I give them some simple games as
project assignment - like "concentration", or "tetris" - but
it's not a "game" course. The other group is in the "game"
course using VS/C#/XNA. Both courses are advertised as
open to students with no previous programming experience.

The group in the second course, the "game" course are doing
more sophisticated games (modding the platformer - using sprite
based graphics), but they seem to be having less fun. They also
seem less able to experiment outside the assignment. The students
doing the less complex projects seem to be more intimate with the
details of the system, so they can tinker more. It is true that
this is largely an expectation thing.


My original point was that there is a set of foundational
algorithmic and computational concepts that the students
need to learn that are common to both courses.

This observation tends to reinforce my techno-centric jingosim that
"yes, games are fundamentally programming after all" (the same way
that NASCAR  racing is fundamentally about car technology, and NFL
Football is about human physical conditioning technology). The
centric thesis in this view is that the cultural impact of computer
games is an outgrowth of and expression of human fascination and
intimacy with the technology. (a.k.a "The medium IS the message."
 - it is just about the technology and the cool things we can do
with it.) I do realize that this is not a mainstream view these days.

Lastly, we do live in a day where computer games are now big business.
Like movies, we have "hollywood blockbusters" which are big ticket
projects, have cultural significance, but pretty much follow
established scripts. (I love Skyrim, but gosh - it's a lot like WOW).
However, the barrier to entry has dropped. Hollywood and the big
game studios put out quality products that are enjoyable.
However, I believe that small ticket
indy  producers of both games and movies can have a significant
cultural impact precisely because they have the freedom to experiment
and innovate outside the profit driven big studio model.

Ted



> I think much of the apparent difficulty in teaching game development comes

> from uncalibrated expectations on the part of both the student and the

> teacher. To briefly oversimplify (because I'm going somewhere else with

> this), students come in expecting to be able to make Portal 2 (or

> equivalent) and teachers come in expecting to ramp their students up to

> working with the Source SDK (or equivalent). The teachers can try to

> convince the students that, oh, you won't be able to make Portal 2 without

> a lot more money, friends, and experience, but if the teachers are holding

> out the Source SDK as the end-of-the-year target for familiarity, the

> message will be undermined.

>

> In the history of game development, it's my understanding that the bulk of

> culturally-impacting games that were made by small teams or individuals

> without lifetimes of experience were actually Not built with modern

> frameworks. This, no doubt, is partially a product of historical

> circumstances, but it's what we've got to learn from. Because of this

> realization, I have a lecture I give in the game engines class at UC Santa

> Cruz that explicitly lays out a wide spectrum of platforms that people

> have

> built games on in the past. (Slides:

> http://www.slideshare.net/rndmcnlly/bmoslfgemwa-spectrum-of-game-engine-architectures)

> The intent is to convey that "game engine" gets used to refer to a lot of

> different things, and that struggling with a major framework is neither

> necessary nor sufficient game development experience to produce

> culturally-impacting games (especially when you are just starting out,

> small time).

>

> In the context of a larger spectrum of things that you might build a game

> from/with, the canonical Pong-in-XNA assignment is historical novelty.

> Gaining fluency with tools designed for engineering at a vastly different

> scale in the context of a one-quarter class is a uniquely modern

> challenge.

> Early (individual, gamedev-inexperienced) videogame creators worked with

> inherently simpler and constraint-rich abstractions that were suited to

> building the non-game applications of the day, and they did it with a pace

> that was slow enough to appreciate the motivation behind the design of the

> abstractions they were using. Call it a liberal education if you like, but

> I think the route to producing individuals capable of being leaders of a

> major advance in game development practice spends more time passing

> through

> building games on platforms at the sides of my spectrum of "game engines"

> than it does giving students with hand-on experiences with today's

> framework-of-the-month. This means building a videogame with an

> underpowered microcontroller and an overconstrained wizard. This means

> building an operating system application that just happens to be a game

> and

> tweaking the scripting of a game made in a drag-and-drop game maker tool.

> This means building a gaming-relevant library and integrating it into a

> framework. This means partially cloning a given game while staying within

> it's parent engine. And maybe, though potentially not at all, this means

> build a partial clone of a current engine in a current framework.

>

> /rant

>

> Rant aside, I think several here would get something out of browsing the

> slides linked above. To hit on the thread's topic, it's getting to convey

> the kind of wisdom in there fuels my passion to teach gamedev. And it's

> the

> expectation-reinforced tradition of prioritizing things that could be

> learned from free tutorials online over broader knowledge that isn't

> documented anywhere else that I'd cite as a reason not to teach gamedev.

>

> On Tue, Nov 22, 2011 at 9:55 PM, <pawlicki at cs.rochester.edu> wrote:

>

>>

>> Greg,

>>

>> I do appreciate your insights. Both my courses are for first semester

>> students. So, my comparison is based on equally novice students.

>> What we wanted was a way to attract students to CS with a "learn

>> to make a video game course". I don't intend to be a total Negative

>> Nancy - the course is going ok, for the most part. My point is/was

>> that there is really no way to avoid the conceptual complexity of

>> development. Building a game is a hard task - harder in fact than

>> the simple programming tasks in a traditional course. There are just

>> a lot of concepts.

>>

>> TFP

>>

>> > I read what you had written below, Ted, and saw some things which

>> threw

>> up

>> > red flag for me.  I hope my insights can help you.

>> >

>> > In regard to student frustration, I can place some of the issues on

>> the

>> > fact you are using the Platformer kit.  So on top of all the work you

>> need

>> > to do to have your students learn and use XNA, you then place the

>> burden

>> > of using a considerable code base. The platformer on a student's first

>> > go-around is a considerable amount of code and assets to wade through.

>> > Ultimately, what they produce is a product which is only a derivative

>> of

>> > the Platformer kit.

>> >

>> > Another red flag is that you call XNA an "Engine". Than that's flat

>> out

>> > wrong. It's a framework that is designed to be genre neutral. What I

>> have

>> > found and honed in my own XNA course is to approach XNA is as a lego

>> set

>> > for making games in C#.  So I get down to basics. I explain the game

>> loop.

>> > Render a texture and then Move it around. Walk them through creating a

>> > Sprite Class. Get User Input. Play with Sound. Do Collision Detection.

>> > This ends up being the second lab in this course. Granted, this does

>> take

>> > me 2 weeks to get through this in my Freshman Course.

>> >

>> > What isn't evident in your description below if your course is a first

>> or

>> > second term course. In my case XNA is a Second term course after

>> taking a

>> > standard introduction C++ course and an Introduction to Game

>> programming

>> > using Adobe Flash Platform with Actionscript. If your course is a

>> first

>> > term course, then the approach you need to take will be more like our

>> Game

>> > Programing Introduction course. You have to easing them in teaching

>> > programming fundamentals along the way. (Here's what's a variable,

>> Here's

>> > how to generate random numbers, Here's an if statement).

>> >

>> > We maintain all our course files on a web server, if you (or anyone

>> else

>> > for that matter)  would like to explore our Freshman Classes and

>> > curriculum, please contact me off list directly so I can provide you

>> with

>> > the information.

>> >

>> > Greg

>> >

>> > Gregory Walek

>> > Professor AGGP

>> > NHTI, Concord NH

>> > ________________________________________

>> > From: game_edu-bounces at igda.org [game_edu-bounces at igda.org] on behalf

>> of

>> > pawlicki at cs.rochester.edu [pawlicki at cs.rochester.edu]

>> > Sent: Tuesday, November 22, 2011 8:40 AM

>> > To: IGDA Game Education Listserv

>> > Subject: Re: [game_edu] an undetermined number of reasons NOT to teach

>> > game dev

>> >

>> > One big reason not to teach "game development" is that "it's hard".

>> >

>> > I teach two Freshman classes, one is "Intro Programming" a 'hard'

>> course

>> > for CS majors the other is "video game development" intended to be

>> > a 'fun and easy' course to get people interested in Computer Science.

>> > In the majors class I use Java in the game course I use C#/XNA.

>> > It turns out that there is a lot of complexity with using a

>> sophisticated

>> > game engine. The VS/C#/XNA tools and support are great, but the power

>> > comes with a price. In the regular majors class, I have them do

>> projects

>> > like "pong" or "tetris" or a simple dungeon crawler - which everyone

>> > should

>> > program at some time in their lives. The students in the video game

>> > class do more sophisticated projects (customizing a 2D platformer) but

>> > they seem more frustrated because they don't have as deep a

>> > fundamental understanding of how it works. So, video game

>> > development courses may scare students away from CS because of

>> > the difficulty.

>> >

>> > The second reason not to teach "game development" is that it's

>> > multidisciplinary.

>> >

>> > When I get Freshmen wanting a course in game

>> > development I now tell them that there is no such thing. In order

>> > to develop games you need strong skills in Computer Science, but

>> > also in media studies (which is in our English department), Studio

>> > Art & Art History, Music, and Business. (Wow - just like what we

>> > used to call "a well rounded liberal education" - surprise!).

>> > I help them put together a four year plan that emphasized their

>> > personal strength, but informs them in the other areas. (And of

>> > course, they need to build games as projects.) They wind up as well

>> > prepared for the video game industry as a formal education can get

>> them,

>> > but they also are ready for other career choices. They get a real

>> general

>> > education, not a "game specific" education. So, the second reason not

>> > to teach game development is that it's too narrow a topic for a good

>> > formal education.

>> >

>> > Yours,

>> >

>> > Ted

>> >

>> >

>> > Thaddeus F. Pawlicki, Ph.D.

>> > Undergraduate Program Director

>> > Computer Science Dept.      (585) 275-4198

>> > University of Rochester       FAX (585) 273-4556

>> > Rochester, NY  14627-0226   pawlicki at cs.rochester.edu

>> > http://www.cs.rochester.edu/u/pawlicki/

>> >

>> >

>> > ''One of the most difficult tasks men can perform, however much others

>> may

>> > despise it, is the invention of good games and it cannot be done by

>> men

>> > out

>> > of touch with their instinctive selves.'' - Carl Jung 1977

>> >

>> >

>> >

>> >

>> >

>> >> Ian, several on your list are already in the first draft! Not worded

>> in

>> >> quite the same way, but really good to know others are on the same

>> >> wavelength as me!

>> >>

>> >> This is going to be for #altdevblogaday and I normally just write

>> from

>> >> the

>> >> hip, but my confidence took a beating last post, when I got savaged

>> in

>> >> the

>> >> comments section. So thanks for the sounding board of suggestions, as

>> I

>> >> feel I'm on the right track. Yes, these lists are generalisations,

>> but

>> >> like all stereotypes the underlying truth often needs airing to be

>> truly

>> >> scrutinised.

>> >>

>> >> Mike

>> >> _______________________________________________

>> >> game_edu mailing list

>> >> game_edu at igda.org

>> >> http://seven.pairlist.net/mailman/listinfo/game_edu

>> >>

>> >

>> > _______________________________________________

>> > game_edu mailing list

>> > game_edu at igda.org

>> > http://seven.pairlist.net/mailman/listinfo/game_edu

>> > _______________________________________________

>> > game_edu mailing list

>> > game_edu at igda.org

>> > http://seven.pairlist.net/mailman/listinfo/game_edu

>> >

>>

>> _______________________________________________

>> game_edu mailing list

>> game_edu at igda.org

>> http://seven.pairlist.net/mailman/listinfo/game_edu

>>

> _______________________________________________

> game_edu mailing list

> game_edu at igda.org

> http://seven.pairlist.net/mailman/listinfo/game_edu

>