Who owns student work--the school or the student?

This is a comment I made on a Gamasutra article about schools claiming to own student work (click the title of this post):

Many people misunderstand copyright. I've had to research copyright law extensively because of games and articles I've had published, but I am not a lawyer. For a more authoritative opinion (which matches mine, as it happens) read what Jim Charne, the lawyer who writes the legal advice column for IGDA, has to say. See http://www.igda.org/columns/lastwords/lastwords_Nov08.php for his take on this question, which in my words is "these schools have no basis in copyright law for claiming any ownership, and I don't understand why they'd even think of trying." The notion that a school owns the copyright because their equipment/software was used is ridiculous, in my view. The idea that students attend a school to find cut-rate ways to make games is laughable. Doesn't attending school cost the students a lot of money?

All of my game-related work other than teaching has been on a freelance basis, and in my view no self-respecting freelance author/creator EVER allows his IP to be transferred permanently to someone else unless there is absolutely no alternative--or the lump-sum payment is ridiculously high. "Assurances" often don't matter when money is actually on the line.

I strongly advise prospective students to avoid any school that claims to own the student's work. Always carefully read what you're asked to sign, but better yet, ascertain beforehand what the school's policy is and don't attend one with a doubtful policy. Anytime you attend a school that is owned by one or several individuals, you need to be especially careful, about *everything*. If you sign away your rights, it's your fault.

However, there is a reason for a school to be cautious. Publishers routinely require creators, who pitch a game to the publisher, to sign an agreement protecting the publisher if the publisher should later publish a game that might be construed as similar in any way. This protects the publisher from frivolous lawsuits by game creators who don't understand that game ideas cannot be protected by copyright in any case. (http://www.copyright.gov/fls/fl108.html) While a school doesn't publish games, there might be occasions when a student or former student would sue a school for use of his or her game for other purposes. So the school would be wise to require students to sign a document equivalent in some ways to the document creators must sign before submitting a game/game concept to a publisher. That is what the IDGA should work on.

Nonetheless, like Tom Buscaglia I feel IP ownership is a moral issue, and my gut feeling is that most of these schools are just hoping to steal something from their students, to gain control of something they didn't earn by their own efforts. Digi-pen overriding the creators of Toblo appears to be just one of those cases.

Educational videos that come with UT III

Two videos come with the Deluxe edition of Unreal Tournament III. The shorter one is in some sense an advertisement about UT, while the longer one (25 minutes?) is about making the game.

The latter is the best video I've seen about making games. It is not only well-made, it emphasizes the importance of playing the game as soon as possible (in little more than a month from starting, in this case), the iterative nature of production, and way that new ideas are discovered along the way, the importance of getting rid of what doesn't work. It also clearly shows that level design is a part of game design, with the art important to the end product but added after the game design is tuned to perfection.

The short video is good for making a point, as Cliff Bleszinski says early on that a designer's best resort is to put things into a game that he likes/thinks are cool. This is dead wrong, of course, if you design a variety of games, but is correct if you only design shooters (which is what CB and Epic make). More than any other genre, shooters are all "the same" in the end, so what one fan of shooters really likes, another is likely to like. Even so, he says in speaking of UT I, that they threw lots of things into the game to see what stuck, which again is a reference to the importance of testing, testing, testing. No matter what you think, not matter how cool something seems to be, you have to test it and see what a variety of people think.

UT III Deluxe is also good for the UT editor and many tutorials for the editor.

Teaching critical thinking, teaching attitudes

There's a fundamental problem in game curricula that a pamphlet cannot repair. When you teach game design, you are teaching critical thinking. You are teaching habits and attitudes that contribute to success as a designer. And you are teaching people to DO, to actually design games (generally to begin with, non-electronic ones, and electronic ones later).

What you should not be doing, because it's very little help, is teaching people to memorize a lot of material and regurgitate it on multiple-choice tests. Yet most teachers are content with that memorization as "teaching", not just in game curricula, in all curricula. I recall one college teacher who insisted on teaching the Windows 2000 operating system even though the school's computers only had Windows 98. She showed the students slides from the textbook. She said "they're scoring 80% on the tests", and I said, "but I bet they can't DO diddly squat." In another case a LONG time ago, a college taught COBOL at a location where none of the computers (Apple IIs) could compile COBOL. "Do"?

High schools have become pure training centers, where students are taught to memorize the answers to the end-of-class tests. The kids get to college and have no clue about thinking or about learning. Unfortunately, "memorize and regurgitate" is the easy way to teach, and multiple choice tests are easy to grade (Blackboard can do it).

Actual successful practitioners are often not allowed to teach subjects because they don't have a degree in the field. Teaching is more and more a matter of "those who have never done, teach".

Until we change this situation--and we're going the opposite way at the moment--teaching at any level will tend to be mediocre, no matter what the actual practitioners hope for.

Sorry state of game education

Some comments on my second GameCareerGuide article referred to an awful advertisement, by a college I've not heard of, showing "game designers" lounging around playing games, with the implication that game playing is a major part of the work. I've also recently read a book titled "Virtual Apprentice, Computer Game Designer" that does exactly the same thing: one photo caption reads "Imagine a job where you play computer games all day long!" (p 5). These kinds of lies distress people in the game industry, and they distress me. Students should be told the truth.

Someone suggested that the IGDA (International Game Developers Association) should produce a pamphlet that "tells the truth".

Unfortunately, there are many teachers (and even more college administrators) who are unwilling to tell the truth to students, ultimately to tell them "you might be better off pursuing some other subject". Those awful advertisements are an example of the lying that goes on.

Many colleges are desperate to replace the shortfall of technology students, as members of the millennial generation are comfortable with using technology but rarely interested in it as a career. Technology enrollment is weak at most schools, and game subjects are seen as a source of replacement bodies.

Dollars rule in 21st century education. If the school isn't willing to tell the truth, will the students ever see the pamphlet?

Another GameCareerGuide article

"The Idea is not the Game", 23 September

http://www.gamasutra.com/php-bin/news_index.php?story=20356

(You can click on the title of this post.)

Article on GameCareerGuide

My article "Pulling the Plug: In Defense of Non-Digital Teaching and Learning"

http://www.gamecareerguide.com/features/602/pulling_the_plug_in_defense_of_.php

was published 2 September on Game Career Guide, the major Web site for people wanting to learn video game creation. This is an edited version. My title was "Why we use non-electronic games to teach game design", they wanted something more provocative.

What is "game development"?

Recently I talked with some folks from a college involved with game development.

One of them says, "(person X) says he doesn't know anything about game development". Person X is a major official of a group that's all about game development! Then later "(person Y) doesn't know games" (or maybe he said, "game development"). Person Y is heavily involved in game development/creation education, and ought to know something about game development, surely. But person Y comes from the art side of things.

On thinking about it, I recognized that the speakers equated "games" and "game development", and further equated "game development" with computer programming.

Fairly obviously, you can know a lot about games, in a variety of ways, and not know much about game development. We get students all the time who think they'll be good at creating games simply because they like to play games a lot: NOT SO, bucko. Yet you can also be an important part of a team that creates electronic games, and know next to nothing about computer programming.

This long introduction leads to the key question: is "game development" now the equivalent of computer programming for games, or is it something much broader? When creation of an electronic game was a one-person endeavor, back in the 70s and 80s, every game developer had to be a programmer. But this "one hero per game" style practically ended around 1990--I've had students who were born later than that--as most games became too big to be done by one person.

Nowadays, many more artists than programmers work on electronic games. And there are teams of game designers, level designers, sound people, narrative writers, and so forth working on big games. Programming is the minority endeavor.

More important, in almost all cases programming nowadays can only screw up a game, not make it outstanding. What makes an electronic game outstanding is, first, the design, the gameplay; second, the look and feel of the game, which is a combination of design and art. Good programming can certainly contribute, but mostly, programming is there to implement the vision of the designers and artist, and is a fairly mechanical contribution to the game. But if it's poorly done, then it can ruin the game. Patches typically fix programming problems, they can rarely fix fundamental design problems.

Now mind you, unlike a great many of the people who teach programming (I do not), I actually worked full time as a programmer for a while before getting deep into networking and user support. Nonetheless, this is my take on programming, especially today:

"Programming is donkey work".

What I mean by "donkey work" is that programming is mechanical. We know today that many of the steps programmers used to have to do manually, are now done by software tools. Ideally, we'd like to be able to tell a computer-based tool what kind of game we want, provide it with art, and it would write the programming. Game engines go partway in this direction, simplifying programming by (in effect) doing some of it themselves.

Constantly, people are trying to write tools that will make programmers less and less necessary, less and less important.

Yes, yes, we know there is creativity in programming. But once we get past the highly entrepreneurial stage (which we have), too much creativity in programming causes problems. In games we want programming to be reliable, solid, fast--mechanical, not creative.


So what is "game development"? Not programming, folks, it's design and art, with programming coming in near the rear. Programming is a necessary evil, not the heart of an electronic game. (And if we stray into the world of non-electronic games, we have design and we have art, but we have no programming at all.)

Now perhaps we could agree that "game development" means programming, and we can change our "game development" curricula names to "game creation" (those that includes artists and designers, at any rate). Or we can recognize that "game development" means all aspects of game creation, not just programming.

Unfortunately, "game development" programs in colleges and universities are often started by programmers, who have no interest in art and little interest in design (and sometimes, little interest in games!). In many less-well-known schools "computer programming" is going away as a topic of interest for the millennial generation, or has already been dropped; "game development" is grabbed as a life-saver for those who want to teach programming but lack students. These "game development" curricula are about fifteen years out of date when they start. My own experience of this is that when programmers start "game development" programs, those programs are a disaster for artists and designers. "Game development" should be in the hands of gamers who are teachers, not of programmers.

If you're a student planning to pursue game creation as a career, find out whether the school you have in mind runs the programming version of game development, or the broader version that accommodates non-programmers.