More of my writing at Gamasutra/Game Career Guide:
Tuesday, December 23, 2008
Tuesday, December 9, 2008
Tuesday, December 2, 2008
What makes it especially applicable is that the writer-director had worked for years to create the movie, including four years to make a 6 minute short (starting with an Apple II, later with a better machine). That short is one of the videos, and can be seen as a particularly successful portfolio/demo. (It's also instructive that he could get a producer to look at it because his brother's wife knew the producer socially from having been to college together.) It is remarkable for the technology of the time, and imaginatively stylish to boot.
There are also two videos (Chapter 1 and Chapter 2) about the making of the movie. The second is particularly good because, I think, it shows the kind of mentality that often exists when a company is making a AAA game, right down to working hours past midnite and everyone pulling together in difficult circumstances.
This is a prime example of how, on rare occasions, a person conceives something that comes to fruition despite major obstacles and the sheer unliklihood that it will get done. My students (most of them high school age this term, though in college classes) watched with great attention, which is VERY unusual.
(The movie nearly made its budget in the US, but was not widely regarded as successful, so the writer-director has not yet had another movie credit. Unfortunately, the plot gets exceptionally dumb at some points, and the acting occasionally wanders despite presence of three Academy Award winners. But it is amazing technically. It's 1:46 long, I showed much of it on the day before Thanksgiving when many of the students were thinking about anything but school, after the videos (I'd showed the remarkable 6 minute short the day before).)
Monday, November 17, 2008
We’ve all seen movies where we can say “that movie was well-made,” that is, the directors, photographers, sound people, and so on are good professionals who did their jobs well. It could still be a bad movie owing to having the wrong actors (not necessarily bad ones, just ones not suitable for the part) or a bad story. Some people would say that ALL fantastic adventure stories (Mummy, Indiana Jones, Spider Man, etc.) are bad stories, but those movies were generally quite well-made. (This is as opposed to “the old days” when fantasy and science fiction movies tended to be cheap junk.)
When you start designing games, you’re no more likely to be very good at it than Beethoven was when he started composing music, or Rembrandt was when he started to paint, or John Steinbeck was when he started to write. If we hear early Beethoven nowadays, it’s usually because it’s by Beethoven, not because it’s good. Creative endeavors take lots of practice, it is very rare that someone is outstandingly good to begin with.
Further, I am not going to arrogate to myself the idea that I, unlike anyone else in the world, can easily recognize what games are really good, outstanding, just OK, etc. I can tell when games are bad, I can tell when they need to be improved, but at some point I don’t know. If nothing else, I won’t have the time to play the games many times myself, so how am I going to know exactly how good it is? (Again, I can tell when there are bad aspects.) Reiner Knizia makes over a million dollars a year as a freelance game designer, and has had over 200 games published, yet he is sometimes surprised by sales of his games; not even he knows how good a game will be, though he can likely tell the poorest ones from the rest.
So I am not going to grade you on “how good” your game is, or “how much fun” it is. Only people who don’t design games think they can do that.
What I’m interested in is whether the game is well-made, even if it isn’t particularly good. If you do the right things, especially playtesting the game and recognizing that changes can be made to improve it, implementing those changes where time permits, then you’ve got the essence of proper game production. I give you milestones when certain things are due, not only to try to help you stay on track, but to see if you’re doing the right thing.
You won’t have time to “finish” the game or even come close to “perfecting” it. (In a sense a game is never finished, you just finally can’t afford to spend more time for the minimal benefit you can achieve: it’s the law of diminishing returns.)
One of the best, if not the best, games students have made was in my very first game class, fall 2004. The group of students liked their game so much they kept working on it through the following spring and summer, making an electronic version as well. (Notice it was a group project; which means more could potentially get done in a given amount of time, as more people were involved.)
The goal of a teacher is that students gain the confidence to do well in their lives and their jobs, and to "be all they can be".
The satisfaction comes from seeing the students get jobs in their field, or go on to succeed at higher levels of education.
The fascination comes from watching how the students--people who are often still in formative stages--behave, and work with one another.
The fun comes from talking with the students.
(And the frustration comes when the students are their own worst enemies.)
Teaching is not about “delivering content” or “covering the material”. Teaching is about influencing students to think and solve problems, to understand how to behave in the workplace, to take responsibility for their work and their behavior.
Thursday, November 13, 2008
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/
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/
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.
Wednesday, November 5, 2008
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.
Thursday, October 9, 2008
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.
Sunday, October 5, 2008
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?
Tuesday, September 2, 2008
My article "Pulling the Plug: In Defense of Non-Digital Teaching and Learning"
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.
Friday, June 13, 2008
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.
Sunday, May 18, 2008
The very fact that this problem can arise highlights the malaise we see in some universities and colleges today. The teachers don't teach, they lecture. If they TAUGHT their classes, that is, if they interacted with the students, if they discussed topics WITH students rather than lecture AT students, then this problem would never arise. Whenever a classroom becomes the equivalent of a book, with the students partaking of the author's expertise but never able to question or ask for clarification, why would students come to the classroom if they hae an alternative? Moreover, this leads to an environment of regurgitation of material, rather than of thinking, of education. Education is about understanding; understanding is enhanced when the teacher and the students work together to understand. Lectures are more appropriate for training, not education (see http://teachgamedesign.blogspot.com/2008/04/training-vs-education.html).
In the past people came to the classroom because the material wasn't otherwise available. (It has to be said, even then if the teacher had written the textbook, and then lectured the same material as the book, students wouldn't bother to come to class.) Now that it's available elsewhere, why would they inconveniently come to listen to a "lecture"?
If someone asks if I'm going to "lecture" about something, I say, "I don't lecture to students, I talk with them". I am a teacher, not a lecturer. Teaching is more akin to coaching a sports team than to writing a book; lecturing is much more like writing a book.
One objection that might be raised to my point of view is, "the classes are so large, no one could actually TEACH them." That's not true; I've read of "lecturers" who went out into the audience, who conveyed information via questions and answers. No, they can't learn all the students' names, they can't get to know the students so that they can coach them, but they can make the learning interactive.
But more important, there shouldn't BE huge classes, as huge classes are necessarily poor education. I had a class of "only" 48 recently, and I managed to make it interactive, but it was very difficult; when the students really got into a topic, discussions were going on all over the room and chaos reigned.
Apply this to a hands-on topic like game development, and the objections to this lecture-style "teaching" are even stronger. Most game development students are of the millennial generation, and millennials thrive in group settings, in sharing, and in interaction. Add to this that the students are game players, very much used to interaction, not passive absorption of material. Finally, millennials hope that their authority figures will be their friends, or at least friendly--like their parents--which the university "lecturer" cannot be because he or she cannot get to know the student.
Yes, I learned the name of every person in that class of 48. And in my smaller (24) classes, I spent at least 10 minutes individually with each person, at one point, to get to know more about them. I'd like to have spent more time but my "office" was a tiny cubicle amongst many more, not conducive to private discussions with students!
Go back to the medieval roots of the university system, and you won't find huge classes, you'll find teachers with small groups. Fundamentally, huge classes are a symptom of the ultimate disease in education, "money". If someone can cope with (I won't say teach) 48 people instead of 24, the school spends half as much on pay for faculty. If a "lecturer" can talk at 200 people, and let poorly-paid grad students take care of the labs, the school saves lots of money.
This is why a good community college--they aren't all good, and that includes the one where I was given 48 students--is likely to provide a much better education than a large university, for the first two years. (Perhaps this is confirmed by the research showing that students who transfer from community colleges in my state to colleges do better there than the students who start their education at those colleges.) Community colleges hire teachers, not lecturers, and classes are usually small, not large.
I have much more to say about this, but I'll stop for now.
Thursday, May 1, 2008
I was educated as an historian. One of the things you learn is skepticism about information sources, though some historians seem to lose that skepticism at times.
Many of the stories "everyone knows" are in fact apocryphal, never happened. Something sounds so good it gets attributed to an historical figure who in fact had nothing to do with it. This is true even for living people. Half of what Yogi Berra is supposed to have said, he didn't say. (One of his "Yogiisms" is, "I never said half the things I really said!")
Furthermore, people write and say things that aren't true, sometimes by accident, sometimes deliberately. I am personally skeptical of memoirs that discuss in detail something that happened 20 or 30 years before, especially if it was during the writer's childhood. If the writer didn't keep a diary at that time, I think to myself, how can he or she remember all these details? *I* don't remember that kind of detail, though my memory generally is excellent. So how much do they get wrong, or are they making up?
Lawyers know and study how unreliable witnesses can be, and in what ways. [books about it]
The astronaut Frank Bormann tells a story about something that happened along the way on a trip to the moon. Someone listened to the actual recording of the incident, and found that it was drastically different from the story. He played it for Bormann--I heard this on NPR radio, by the way--and Bormann said, well, yeah, I guess so, but I'm still going to tell the story, it's so good. Imagine how many books about the moon flights, about Bormann, about space flight in general, will include this entirely wrong story as "truth".
The Fayetteville, NC newspaper had a nice report about a meeting at Methodist University (then college) where a well-known writer had given a talk. The problem is, it never happened. Weather was so bad that the meeting was called off. But the report had been "pre-written", and published as is. And a historian reading that paper 50 years from now probably will take it as fact, as truth.
Now I've said this, about the newspaper, but I'm repeating what my wife, who was then chief librarian at Methodist, told me. I wasn't actually at Methodist to see that there was no meeting, nor did I read the newspaper report as far as I can recall. So I could be wrong, eh?
Initial reports on September 11, 2001 (9/11) stated that the State Department had been bombed. Never happened. But this was in the heat of the event. The next day (IIRC), all the major broadcast TV networks reported that some people had been rescued from the rubble, found in an SUV. I checked every network, and all reported this as truth; yet the next day, all admitted that no such thing had happened.
I rarely listen to the news right after some shocking event has happened, because the report will likely have "substantial inaccuracies" in it.
But for months, even more than a year perhaps, after the destruction of the World Trade Center, the tally of dead was about 7,000. Then that was reduced to about 3,000, a number which has held up. Wikipedia now says 2,974 died as an immediate result of the attacks with another 24 missing and presumed dead. (Of course, not everything in Wikipedia is correct.) With all those resources, with the importance of who had died and who hadn't (insurance claims, government and charitable perks for the relatives of those who died), the number was drastically wrong.
Be skeptical. Try to find out where stories come from. Yes, the BBC may report that one Chinese killed another because the latter sold his "magic sword" from an MMORPG, and it MAY be true, but then again, how reliable is news from China as reported by the BBC? Yes, a South Korean may have died from failure to take care of bodily functions while playing online games--or may not. One student told me he knew someone who had to go to a hospital to be treated for malnourishment because he played video games day in an day out--and maybe that was true, or maybe not.
Just because you heard it, just because someone told you about it, just because it was in the news, doesn't mean it's true. "What everyone knows" isn't always true, though frequently it is.
If it sounds unbelievable, maybe you shouldn't believe it! "Take everything with a grain of salt". You can rely more on your personal experience than on anything else, but even THAT can be deceptive.
This is part of critical thinking critically, discussed in Wikipedia as:
"Critical thinking consists of mental processes of discernment, analysis and evaluation. It includes possible processes of reflecting upon a tangible or intangible item in order to form a solid judgment that reconciles scientific evidence with common sense. In contemporary usage "critical" has a certain negative connotation that does not apply in the present case. Though the term "analytical thinking" may seem to convey the idea more accurately, critical thinking clearly involves synthesis, evaluation, and reconstruction of thinking, in addition to analysis.
Critical thinkers gather information from all senses, verbal and/or written expressions, reflection, observation, experience and reasoning. Critical thinking has its basis in intellectual criteria that go beyond subject-matter divisions and which include: clarity, credibility, accuracy, precision, relevance, depth, breadth, logic, significance and fairness."
In some ways game design is an exercise in critical thinking! Especially as you decide how to modify a game based on playtesting input.
Sunday, April 20, 2008
Any “review”, whether of a book, a movie, a play, music, software, or a game, must answer three questions: what was the creator trying to do, how well did he do it, and was it worth doing? These questions can help guide a teacher grading a student game project, just as they help a reviewer evaluate a commercial game. However, I am not going to discuss these questions, except insofar as what follows indicates how well the student(s) did it.
If you don't play games, all you can do is try to judge effort and professionalism. If you do play games, but are not accustomed to evaluating games without playing them (perhaps talking with people who have), you’ll have a problem, because you often won’t have enough time to play the game enough to really find out what it’s about. (This is why game reviewers must spend a lot of time playing a game, to avoid being misled by first impressions.) Some games just don’t sound (or look) like much until you play them. Some sound or look really good, but fail in actual play.
Fortunately, if you’re very familiar with games and have some design experience, you can judge the important things fairly easily.
Just as the three most important factors in real estate are location, location, and location, the three most important factors in a game are gameplay, gameplay, and gameplay. There are several aspects which I’ll discuss in the next paragraphs.
The most important question about any game is, what does the player DO? What are the challenges the player(s) face? What actions can they take to overcome those challenges? This is the heart of most games. You can often see quickly, when evaluating a student game, that the player just doesn’t have much to do, or that what he is doing is quite repetitive without compensating factors.
Related to this is player interaction. What can players to do affect each other? There are certainly good games (often “race” games) where a player can do little to affect another player, but most good games have a significant-to-high level of player interaction. Or if it’s a solo game as are many electronic games, interaction between the player and the game becomes the target.
Another question related to what the player does is, is the game replayable many times without becoming "just the same" over and over? Perhaps this is less important with electronic games, as players EXPECT such games to become “the same”, and they also don’t mind sameness as much as the non-electronic gamers do. (So many AAA list electronic games are quite derivative of the gameplay of so many predecessors.) Nonetheless, the better a game is, the more replayable it is likely to be.
Some people would add one more thing, is the game fair? Do the rewards seem to match the effort?
So much for gameplay design. What about what we might call the professional aspects of the game? Care of construction (NOT looks--construction of the “rules” or electronic equivalent, game mechanics) is important. Sloppiness leads to imprecision which leads to confusion.
Even more important, how much was the game playtested? Are there records (not necessarily elaborate–I tend to list the date, who played, and anything unusual that occurred, along with changes I decided to make (or decided did not work, so I changed back). That can be just a couple lines of documentation per play.
With very few exceptions, a game with a good basic gameplay design won’t actually play well unless it has been thoroughly playtested to work out the little (or big) obstacles to good gameplay.
While the instructor may not be able to play the game enough to know it well, he can suppose that a poorly playtested game won’t be worth much, and that one that is playtested a lot is more likely to be a decent game. “Playtesting is sovereign”, whether the game is digital or not.
I usually ask students to give me the original playable prototype, and the “final” version. There should be very significant changes in the game, if it has been playtested much. You might even ask students to list what significant changes were made.
Here are some specific comments about what NOT to use as criteria:
"Fun" is not a criterion. We can't generally agree what fun is, and your idea of fun is different from mine. A chess master has a different idea of “fun” than your mother has! Some people like party games, some like silly games, some like perfect information, some like planning ahead (hence tend to like perfect information), some like much that is hidden, some like reaction to circumstances (hence tend to prefer hidden information), etc.
Likely hundreds of thousands of people have played my game Britannia, yet even *I* wouldn't call it "fun". It may be interesting, fascinating, and lots of other things, even educational, but many players would not call it fun.
Story is not a criterion. This is especially important because so many students don't understand this, and think story or something other than gameplay is what's important in a game. People play games, they listen to/watch stories. Yes, you can make the story interactive to an extent, but a great many game players really don't care about story. It is absolutely necessary to pound into students’ heads that story is not important in the design of most games.
What about the marketing palaver–the game concept and treatment and so on? These are not even written for non-digital games, though when the game is “finished” and the designer is trying to persuade a publisher to look at it, and then only sometimes, a description of the game will be written that is something like the game concept.
These documents in the electronic game world are marketing documents that have NOTHING to do with the quality of the game, NOTHING. They represent a simple plan for what the game will be.
Consequently, does it even make sense for a teacher to require students to produce these documents? I would say, it makes sense only insofar as the document might help the instructor evaluate the game, or help the students create the game. In that context, the two to three page game concept is useful, but something longer such as a game treatment may not be.
At the least you might ask the student(s) to briefly characterize the “essence” of their game–and let them decide what “essence” means.
Looks of the Game–not a criterion. This counts for virtually nothing; in fact, for non-electronic games I definitely do not want students to spend a lot of time on looks. As long as the physical components of the game are clear, not confusing, that's what counts. (There's a rule of thumb in the boardgame world, that the better a prototype looks, the less likely it is to be a good game, because novice designers spend far too much effort on the looks of the prototype.) I want students to understand that gameplay is what counts, not graphics, even though in the AAA list electronic world graphics become quite important simply because of the youthful audience.
I heard of a “game design teacher” who severely downgraded a student’s non-electronic game project because the box he supplied wasn’t large enough for the game. “The BOX?” That’s completely irrelevant to design; most experienced designers don’t make a box for their prototypes (I *never* have). This is something only novices who don’t understand what they’re doing think is important.
For electronic games, looks only matter near the end of development. And students will rarely have the time to do the playtesting and incremental, iterative modification necessary to “complete” a game and get to the true end of development.
So what else do you evaluate? Appropriateness for the audience. Is there an appropriate mixture for the audience and game type? If it’s a party game (whether “Apples to Apples” or a Wii party game, is it relatively easy and does it promote interaction amongst the players? Here we might actually ask if it’s “fun” in a party sense.
I am not a person who lists exact grade points and values, because I don’t think you can consistently judge this carefully, nor am I confident that my “rubric” would take everything into account. But I can judge an “A”, or a “B”, or a “C”, or something in between, based on these criteria, without assigning specific percentage numbers.
It's very difficult for anyone to "grade" these games without playing them several times, for which there is no time. My main criterion, aside from what I can see about the gameplay, is whether the students playtested the games and benefitted from that.
For groups, I also give them a peer evaluation sheet to fill out. The idea is that I may find out which people in the group actually contributed most, or least. It has its flaws, but is better than nothing.
Saturday, April 5, 2008
Everyone seems to have his or her own definition of "training" and "education". Here are mine.
In general, when you train someone, you tell them a specific way to do (or not do) something. In some cases it can be strictly rote learning, as in how to assemble or disassemble a weapon (there's only one way to do it, by the numbers). In any case, you're not trying to help people make judgments about uncertain situations, you're telling them, "if A, then B; if not A, then C." Many corporate training sessions are of this sort.
In education, you explain to people why something works the way it does or is the way it is, so that they can understand its nature, what's going on. If they lose their way, they can figure out what they need to do to get back to their objective. They can deal with uncertain situations, where there's no clear answer.
In general, the training recipient requires good memory and good organization more than good thinking processes; the education recipient requires application of intelligence, and sometimes critical thinking.
To me, this is the difference between having a set of written directions to get somewhere, and having a map. If you go wrong with the written directions, you may be able to backtrack, but if you get off the path you may be completely lost. If you have a map, you can figure out where you are and get back to where you need to be even if you've strayed far from the proper path. The first is analogous to training, the second to education.
In K12, we now have many schools that are training institutions. The teachers know what is required in the "end of class" test (EOC) , and they know that their job security depends largely on how their students do on those tests. So they drill into their students what they need to know to pass those (usually, multiple choice) tests, and that's all. The students, too, know this is the score; they know they can do next to nothing during the semester, as long as they pass the EOC. Even the smart ones tend to do little, then cram from the book (which, of course, is supposed to contain everything they need to know to pass the EOC), then forget it after the test. (Yes, there are many exceptions: this is the trend, not in every school or every class.)
I've seen the results of this time and again in college. Students expect to be told exactly what's on a test, and what they need to regurgitate, and are dismayed when I require them to actually think. They don't have any idea how to think, because they haven't been required to. In classes I try to impose the "educated" attitude from the beginning, but it's hard for kids to adjust.
Unfortunately in colleges of all types we have teachers who think their job is to "convey the material". I had one teacher say to me, when I was discussing a difficult class, "but you covered the material, didn't you"? That's a dumb question, I'm afraid. That's not what education is about, but it is what training is about. A corollary of the "training mentality" is that if you present the material and the students have the chance to absorb it, and some don't, then oh, well, that's the way it goes. In education, you're trying to find ways to convey what you mean to each class (and each class is different). You've not only conveying information, you're conveying an attitude, a way of doing things. If you can't cover "all the material" because a particular class is having problems, oh, well, your job is to choose (to judge) what's best for the class, and do it, not necessarily "cover all the material".
This is something like sports team coaching, but we don't have as many hours with the students, and we have a lot more students than, say, Coach K at Duke has basketball players (and he has three assistants). Many "trainer" types don't even know the names of their students, let alone understand them as individuals, and don't think that's a problem! How can you judge what the students need, when you know so little about them that you don't know their names?
The problem is, many "teachers" aren't interested in this more complex kind of thinking and understanding of what is needed. It requires more effort, more thought. And unfortunately, school accreditation people also aren't interested, because they can't measure it.
See my post about "educated" people (http://teachgamedesign.blogspot.com/2007/11/game-industry-wants-educated-people.html). I'm not talking about degrees here, I'm talking about a way of thinking and approaching life.
Unfortunately, the US "education" system is becoming more and more training oriented, and less education oriented, every year. Perhaps one indication of this is the very strong tendency of accreditation organizations to emphasize (in teacher qualification) degrees and classes taken rather than actual ability to do something. We are more and more finding "teachers" who have never done what they're teaching in the real world, and it shows. But if all you're doing is conveying material, telling students what to regurgitate on multiple choice tests, how much will the experience of a person who's actually done the work professionally matter? It's a system geared to turn out people who cannot do complex work in the real world--people who have been trained, not educated.
Thursday, March 20, 2008
If you'll bear with me and read all of the following, I think it may help you a lot in the programming class. The summary is: use pseudo-code (English) to write out what you want a program to do, then turn it into whatever programming language you're using, and you'll be much more successful.
Beginners in programming, especially those who don't find programming an interesting and attractive pastime, have many struggles.
There are always two problems in programming: first, what do you need to do to solve whatever problem you're working on (what is the logic of it), the second, how do you convert that solution into something the programming language can execute (what is the syntax of it)?
It is possible to have a computer program that compiles and runs perfectly (correct syntax), but fails to correctly solve your problem, because the logic is incorrect. That is, you can get the second part right, but if the first part isn't also right, the whole fails.
Hence, initial student programs should be ones where either you don't worry about coding--you just solve the problem--or ones where you don't worry about how to solve the problem--you just code it.
For example, the (logical) solution to the problem of saying "Hello World" on the screen is trivial. In English it's:
Blank the screen (clean off whatever was there)
Show "hello world" on the screen
Make sure the screen doesn't go away because the program ends (or we won't see the message)
You can take that English description and code the program in dozens of different languages. Each one will be more or less different, but all will do the same thing. That's why "hello world" is usually the first program you do in a language, it is entirely a problem of language syntax, not of logic.
Example from one of the simplest programming languages, Windows command files (batch files):
echo Hello World
Now, comparing the pseudo-code with the actual code, you can figure out what "CLS" means even if you don't know that it stands for "Clear Screen". You can figure out that "echo" means "Show (by default, on the screen) whatever comes after echo". You can guess that "pause" means "wait for the user to hit a key".
But if your problem is, "take a group of numbers and decide which ones are prime numbers", then you have to figure out how you can possibly do this at all, before you try to code it. If at the same time that you're trying to solve the logic problem, you try to figure out the program syntax, it becomes MUCH more difficult.
Object-oriented programming can throw kinks in the process, but most of the code in most programs is procedural, telling the computer to do this, do that, do the other thing. Any set of instructions, whether game rules, or product manuals, or software how-to's, amounts to a set of sequences of instructions, loops (repetitions until something particular happens or doesn't happen), and branches (decision points where the instructions go one way or another, sometimes from a choice of more than two). Since you can write English to reflect these three structures, you can write English pseudo-code for most any procedural problem. The example above is strictly a sequence. We could add a couple lines where the program would ask the user if he wanted to see "hello world" again or not:
Clear off the screen
Show "hello world" on the screen
Ask user if he wants to see more "hello worlds" on the screen
If user says yes, loop back to "Show", or else continue on to end
Make sure the screen doesn't go away because the program ends (or we won't see the message)
Now we have a branch (the IF) and the potential for a loop (going back to the "show"). Note the loop doesn't go all the way back to the start, or else the screen would be cleared again.
In fact this is not possible to do in Batch files (which are very, very simple), because there's no way to get user input within the program! (unless you use other programs for that purpose). But any "real" programming language can do it.
Here's an analogy. If you "kinda" know a second language, it is much easier to listen to (or read) that language and figure out what it means, than it is to take a meaning and turn it into that spoken (or written) language. In computer programming terms, in the first case, you're only worrying about the syntax; in the second you're worrying about both the logic and the syntax.
So, if you know some Spanish and you're trying to talk with a Spaniard who knows some English, you should speak English, and he should speak Spanish. You'll find it much easier to understand the Spanish you hear than to make it up and speak it, because you're not worrying about the creation, about solving the problem of what to say; he'll do much better sorting out your English and not worrying about how he's saying what he's saying, because he'll be using his native language.
By using pseudo-code you separate your "big mess" into two problems that you solve one after the other. It's much easier.
So, you've all heard (I hope) that the longer you take to plan a program, the less time it takes to code it. Pseudo-code is a principle tool when you're writing simple, short programs. (Longer ones require much more elaborate planning, such as systems analysis.)
This is why I advocate not teaching any one language to "novices", instead concentrating on the logic needed to solve problems with computer languages.
Sunday, March 2, 2008
- The "AAA list" electronic games are really designed by committee. When I design a game, it is almost all MINE. (The rest is playtesters and publisher.)
- For most of the age of video games, you had to work full time in the industry, yet the pay was and is poor. I'd rather help young people as a teacher, get paid at least as well, and have lots of time to design games.
- The working hours are bad. "Crunch time" (unpaid overtime) is common, though designers are not involved in that quite as much as programmers and artists.
- Fighting with the electronics obscures the purity of design. You worry about what the computer can do instead of what the players can do.
Tuesday, February 5, 2008
Put another way, game design students often adopt characteristics of traditionally popular games in their designs. Part of the reason for discussing traditional games is to point out that they are not necessarily designs worth emulating.
So I’ve tried to write a brief analysis of what is wrong with (and right with) some of these games. Sometimes I’ll use the following questions as a framework, after a general discussion of the game.
1. What are the challenges the player(s) face?
2. What actions can they take to overcome those challenges?
3. What can players do to affect each other?
4. Is the game replayable many times without becoming "just the same" over and over?
5. Is the game fair?
6. Is there an appropriate mixture for the audience and game type (consider "take that")?
7. What is the "essence" of the game?
General comments about “traditional” games
There are two types of “traditional” games, the public domain ones that have come down to us over centuries such as chess and pachesi, and those that are commercially-produced games that have become habits with the buying and playing public. The former tend to be for two players only, while the latter are often for two or more players.
I must say I am NOT a person who thinks that recently-designed games are necessarily better designs than “old” games. I am definitely not into “the cult of the new”. But I do believe that the really old traditional games often benefit greatly from the lack of competition when they were first devised/published. Most “traditional” games are played because “everyone knows how to play”. They are bought because “everyone is familiar with it”. They are not traditional because they are particularly good game designs, in many cases. They have attained a place in contemporary culture, have become “a habit”. When you ask boardgame fanatics how well such games would fare if published today, the response is often something between “a dog” and “just another game”.
I have one general comment about the “roll dice and move accordingly” mechanic used in many commercial traditional games. This mechanic gives a player little to no control over what happens. It is almost universally despised by experienced boardgamers. I pose it to video gamers this way: “if you were playing a video game, and your avatar suddenly slowed down for a while, and then sped up for a while, and periodically changed maximum speed at random, wouldn’t that annoy the heck out of you? And what if other player’s avatars were moving at different speeds than yours? You’d hate it. So why would you want to do that in a boardgame?” Yes, it’s easy randomization, but there are better ways to randomize, and in any case don’t we usually want to make games of skill, not games of chance?
I may as well dispose of a class of traditional games here: Bingo, Candyland, and Chutes and Ladders are all entirely random games. This is OK for little kids, who don’t recognize the randomness, and who aren’t up to “strategizing” to beat older players. It’s OK for gambling, too. But it’s worth nothing to people who like games involving skill, who want to take actions to overcome meaningful challenges.
Another point worth discussing is player elimination. Insofar as multiplayer (more than two) traditional games tend to be family games, the possibility that players can be eliminated is undesirable. The argument runs, when a player is eliminated, he’s no longer part of the fun. The counter-argument is, why stay in the game when you don’t have a chance to win? My response is that in family games the purpose is not to win but to enjoy socializing with your family, and there is more interaction if you’re still in the game even if there seems to be little chance that you can win. Some games, such as Careers (one of the best traditional games, but evidently out of print), do not include player elimination, but some do, including our first subject.
As this is the game people often think of first, I’ll discuss it first. Monopoly is a “family game” with a leaning toward adults. It is an average game at best, though quite despised by many boardgame experts. The “roll and move” mechanic is the first point of complaint, but there are others.
There is a dominant strategy--buy everything you land on, if you possibly can, early in the game. This leads to the strong possibility of stalemate, as players may choose not to trade properties to make the sets that allow house building. Consequently, there is a strong possibility that the game can go on for many hours with experienced cutthroat players. In any case, it is a long game–-my students often say they’ve never actually finished a game.
Further, the game works poorly with fewer than four players.
Let’s examine the questions:
1. What are the challenges the player(s) face? The player must get sets of properties, construct buildings to raise the rent, and avoid big payouts.
2. What actions can they take to overcome those challenges? Not much. Movement is random, and decisions are fairly simple. Trading is a major action, as is management of funds (how much to spend on buildings, how much to hold against the possibility of paying large rents).
3. What can players do to affect each other? Trade properties. Otherwise, next to nothing.
4. Is the game replayable many times without becoming "just the same" over and over? Replayability is low, I think. The game quickly becomes repetitive. Few people actually play Monopoly a lot in a short stretch (say a year), but they may play a lot over a very long period, where they will forget how repetitive it actually is.
5. Is the game fair? It’s symmetric, and the advantage of moving first doesn’t seem to make much difference in the long run. There are no “take that” cards to drastically change the game, though a bad roll or two can be deadly.
6. Is there an appropriate mixture for the audience and game? It’s a family game, and there can be big changes in fortune depending on the dice rolls, but it seems appropriate to a “game for all ages”.
7. What is the "essence" of the game? Theoretically it’s a real estate trading and development game, but the emphasis is on the chance of movement rather than on the trading, unfortunately.
There are many variations of Monopoly, in fact most people don’t play according to the rules. I’ve never thought about how to “fix” the game, but one notion that comes to mind is this: instead of playing through rolling around the board a few times, why not allow players to choose some properties to start with? This could be arranged to remove the advantage of playing first, as well. So players might write down a list of five properties (no two from a particular group such as the red properties or the railroads). All are revealed, everyone pays for their first choice (or next, if there’s a tie), etc. until all have three (not five). Then play proceeds.
An interesting variation from Boardgamegeek is, every unowned property landed on is auctioned! The “lander” does not get an opportunity to buy before the auction.
As with most traditional games, Monopoly has a very poor score on Boardgamegeek: http://boardgamegeek.com/game/1406.
Here is a traditional simple game popular with kids. It is so simple that it has been “solved” by many, and it’s easy to write a set of instructions to follow that will result in a draw every time, or a win when it’s available (I have done so). The problem is that there’s a dominant strategy, which amounts to “occupy the central square whenever you can”.
A major advantage of the game is that there is no chance, other than the big difference-maker of who plays first. The major value of the game is to teach kids that they can play a game and not understand its strategy, but as they get older they can learn to be a perfect player in its context.
A much more interesting variation on this game is a four by four grid. You win with four in a row or four in a square.
I am not going to ask the seven questions, which would be overkill here. BGG: http://boardgamegeek.com/game/11901.
I have not played this game in 40-50 years, but it is simple enough for limited comments. It is a race game dominated by chance (roll-and-move again). It does have the virtue that more than two can play. There is some strategy in the use of blockade, either to stop opponents or to clean up behind the blockade by “hitting” stopped opponent pieces. The frustration factor can be high when you’re the one who’s blockaded.
The seven questions would again be overkill. BGG: http://boardgamegeek.com/game/2136
Next I’ll turn to the ultimate Western traditional strategy game, Chess. Chess rules are fairly complex for a traditional game, though it’s really quite simple to learn and play. The play is very complex and highly strategic, of course. Theoretically the game may represent Indian (subcontinent) warfare, but practically speaking it is abstract.
Also unlike most traditional commercial games, there is no chance element other than who moves first. As with Tic-Tac-Toe, a perfectly played game will always have the same result, but because no one has specifically “solved” Chess, we don’t know which result it would be, white win, draw, or black win. In practice, as played by experts white has a significant advantage, and draws are common (55% of top-class human games, 36% of top computer-program games (Wikipedia)).
One of the flaws of the game is that a big advantage accrues to those who know “the analysis” of certain situations, such as the openings. Chess has a vast literature, and the solution(s) to certain situations are known, but only to those who learn the literature. In effect, other people have done the thinking for you. Yes, this is a possibility in any game, but other games have not been intensely studied for centuries.
For most people, there are too many possibilities to calculate once the game gets going. This can lead to what is called “analysis paralysis”: people cannot decide what to do and take a long time. Even when played by experts, chess can be a very long game, hence the artificial limitation of two hours for 40 moves imposed via chess clocks.
Finally, many people would say there are too many draws. In a game designed today, the designer would try to find a way to avoid draws; though given the advantage of moving first, perhaps it’s best that draws are possible.
I’ve read that former champion and famous recluse Bobby Fischer advocates a variation of chess that would remove the “prior analysis” advantage, at least for a while (Fischer was one of the best at knowing prior analyses when playing). IIRC, he suggests scrambling the order of pieces in the back row, imposing that order on both players. So from one side of the board you might have bishop, queen, knight, rook, rook, etc.
Despite all of the above, chess is obviously an excellent game. But would it stand out among other games if published today? In an era that values short games, simplicity, and “that was easy”, perhaps not. Let’s consider the questions:
1. What are the challenges the player(s) face? Deploy pieces in a superior arrangement in order to take more of an opponent’s strength than one gives, and finally to capture the king.
2. What actions can they take to overcome those challenges? With perfect information, it’s all about looking ahead, anticipating your opponent, finding ways to make your opponent feel that he is defeated even if, in reality, he is not. Everything revolves around the moves of the pieces.
3. What can players do to affect each other? Player interaction is very high in a two-player, eliminate-enemy-pieces game.
4. Is the game replayable many times without becoming "just the same" over and over? History shows that it is, despite its fundamental simplicity.
5. Is the game fair? Symmetric, but significant advantage to first mover in expert play.
6. Is there an appropriate mixture for the audience and game type? Yes.
7. What is the "essence" of the game? Movement and position.
This is a traditional game popularized by Milton Bradley’s boxed plastic version. It is largely a guessing game, though some would call it a “deduction” game. As with any game, you can “play the player”, predicting what your opponent will do. For example, a colleague of mine has noticed that his sons will not place their ships in the outer rim of squares. Consequently, instead of 100 squares to shoot at, he has 64. Chance should tend to award him the game most times.
Beyond simplicity, there isn’t much to recommend this game.
An excellent word game. I would eliminate two-letter words from the game, or at least many of the 101 “official” two-letter words.
1. What are the challenges the player(s) face? Make words from random letters, and find places on the board where those words can be placed and score well
2. What actions can they take to overcome those challenges? Very much a thinking game.
3. What can players do to affect each other? It may be possible to block occasionally, but in general, not much.
4. Is the game replayable many times without becoming "just the same" over and over? Given the complexity of language, yes.
5. Is the game fair? There may be a very slight advantage to playing first.
6. Is there an appropriate mixture for the audience and game type? Evidently.
7. What is the "essence" of the game? Creation of words preferably using uncommon letters.
This is a simpler-than-chess strategy game. The game is sufficiently simple that it has been “solved” by computer using brute-force (trial and error) methods (http://news.bbc.co.uk/2/hi/science/nature/6907018.stm).
As with most of the public domain traditional games, this one is only for two players.
Game design students who have played hardly any commercial games, have usually played Monopoly and have often played Risk. Risk is very simple to learn and to play, with so little real strategy that there is rarely “analysis paralysis”. Although the theme is world conquest, it has abstracted the world so heavily that few players will feel like there’s a real war going on.
However, Risk is a weak strategy game, and a “dicefest”. There’s a heavy dose of luck in combat and in the cards. It is a long game with player elimination, a poor combination in today’s terms.
The turn-in-cards-for-armies mechanic is necessary to end the game in a few hours, but fairly random.
The “Mission cards” victory condition introduced “recently” mitigates some problems, but unfortunately the missions aren’t tailored to the number of players in the game.
As with Monopoly, most experienced boardgamers dislike, if not despise, Risk.
1. What are the challenges the player(s) face? Management of resources to end up with more armies than the opposition; there’s a little strategy involved in acquiring armies; and choosing the right time to try to wipe out an opponent and obtain his territory cards.
2. What actions can they take to overcome those challenges? Choosing where to attack, with how many armies. Choosing where to defend with more than one army.
3. What can players do to affect each other? When it is not a player’s turn, he is usually inactive except when attacked. However, every move affects at least two players.
4. Is the game replayable many times without becoming "just the same" over and over? Strategies are limited, but there’s a fair bit of variety.
5. Is the game fair? Symmetric, but there may be a slight advantage to moving first.
6. Is there an appropriate mixture for the audience and game type? Well, lots of people fondly remember playing it as kids, so there must be something to it.
7. What is the "essence" of the game? Some would say “interminable dice rolling”. Choosing where to attack is probably the essence.
Game of Life
This game appeals to younger people, and actually has more choices than Monopoly. However, it is strictly a family game, and players have little control over what happens. It does have the appeal of a partly three dimensional board, and a spinner instead of dice. There’s a story involved (the story of life), and that is nearly unique to traditional games.
I remember it as one of the worst games ever, but this may be too harsh. It is very positive–nothing really bad happens, everyone succeeds in life–but it may teach the wrong habits for the 21st century.
The Chinese/Japanese game of Go, the analog of chess in East Asia, is an outstanding abstract strategy game. It is played on a 19 by 19 line grid, with black and white stones places on the intersections of the lines rather than in the squares. The rules are very simple, though I find them slightly difficult to grasp. The strategy of controlling areas is very deep, even compared with a game like chess. From a game design perspective, the game is so unusual that there may not be many lessons to learn.
Monday, February 4, 2008
This is the third annual iteration of the event, though the name has been changed. According to the college newspaper, attendance was 700 the first year and 1,400 last year. A security guard told me that last year you could hardly move upstairs where the games are being played. This year, that condition occurred only at a couple spots. I certainly don't think there were as many as a thousand at the event.
I arrived not long after the 10 AM opening. Fortunately, I'd pre-registered, so I didn't have to wait in line with the "munchkins" who were there primarily for the tournaments. Because this is primarily a game playing event rather than an event ABOUT games. The entire second floor of classrooms was devoted to gaming, from a "modder demo" room (not well attended) to a Wii room (little kids there) to some hard-core gaming.
There was one seminar series, with the addition of a keynote from Bruce Shankle of Microsoft, who used to work for Red Storm in the Triangle. More about the seminar in a bit.
The only game developer of note "exhibiting" was Red Storm. I'm not sure why, recruiting testers maybe? And why else would they be there? It can't be worth the cost to the developer to exhibit at such a small event, especially one where the emphasis was on game playing, not on game development.
I saw only six first-year students from Wake SGD there, and in general I think there were many fewer game developers/ GD students than at an IGDA meeting.
The most interesting exhibitor (for me) was NC State, both programming and industrial/art design. Some students were showing a mod they'd made, and there was a notice about a game development expo in late April at NC State, one evening. Prof. Tim Buie was working extensively with one of the new Wacom Cintiq large LCD/tablets devices ($1,500)--got a few photos and movies.
Now for the speakers. These were generally scheduled for an hour or two, sometimes filled the entire period, sometimes not.
The first session was a panel about game education available locally, NC State, UNC-CH, Pitt CC, Piedmont CC (Roxboro), and Wake CC participated.
The next, about learning to play piano with a game, I did not attend.
Then Joel Gonzales talked about game education and serious games. This was rather unfocused, but it was interesting to hear that he had had one company die under him. It seems to be a pretty common experience.
Then Dana Cowley, PR manager for EPIC, talked about public relations for game companies large and small.
I attended the keynote next; Tim Buie from NC State had a session about art in the seminar room.
The "keynote" in the autditorium was delayed 40 minutes owing to a "Rock Band" competition and technical problems with projection and sound. Putting on an event like this is a LOT of work, and this was the only glitch I know of. Unfortunately, people were wandering into the auditorium for the keynote, seeing nothing but a "rock band" on the stage, and wandering away. It wasn't until eight minutes after the keynote was scheduled to start that Michael Everett (the organizer himself) manned the doors and tried to explain the delay, up to that point we were in the dark.
It was another 35 minutes before the keynote could start. Bruce Shankle from Microsoft's DirectX group talked about some of the video settings that many games let you adjust, and what you can do to make your video work better when playing games. He is involved in testing video cards to make sure they conform to DirectX requirements. He also conducted the door prize giveaway of Microsoft-published games and two 8800GT video cards (a Wake student got one of them!).
At 5 PM "Marx Myth" (Mark Smith), an art manager/director, talked about creating a self-promotional packet for the game industry "your art portfolio packet". I wish all the artist-SGD students had heard this. He talked for the entire hour and ran short of time. MM sent me his slides, so I can give some approximation of what he had to say to students in the future. MM had THREE companies that he's worked for, die.
The last session I attended, at 6, was by Alex Macris of Themis Group, about "gamer snacks". What he meant was the equivalent of casual games, but written for hard-core gamers rather than "for your mother". Runescape and Travian were two games he particularly discussed. This is really interesting information for students, who aren't likely to find an immediate place at a AAA list company, but who don't want to make games "for my mother". I had not ralized how many of these games exist, and Macris gave his formula for what makes them popular, the "3 Cs", cumulative (what you do affects you in later sessions, unlike casual games), competitive, contextual (metagame exists). He used the example of his own company's "advergame" for Heroes of Might and Magic V (http://www.heroesmini.com/), which turned out to be more popular, perhaps, than the actual video game. Fascinating.
I didn't stay for the 7 PM "how to break-in" panel with developers.
24 January IGDA meeting: something like 230 people were registered, and it was CROWDED. There were two talks, one about the networking/server aspects of running games online, that I went to, and one about "next-generation narrative". As the speaker for the latter spoke at Wake (I have the DVD, haven't watched) and has written a book, I went to the former. This was especially interesting because Emergent, the host and the company the speaker works for, is mainly known for the Gamebryo engine that is used by such games as Civ IV and Morrowind. The speaker is chief architect for it, and his interest is in making it useful to people who are developing massively multiplayer online games. MMO cost vast amounts to produce ($50 million plus), and having an engine that efficiently provides the online connection (and update capability) would be very valuable.
Unfortunately, the speaker's original talk was not approved by the Powers That Be in his company, he was giving away too much info, so in the preceding 16 hours he'd made up another talk. And while he described what the problems are with specific examples from online games, and what some solutions are that fall short, he couldn't say what his company's solutions would be! And somehow he'd been told to take 20 minutes instead of 45, so he didn't talk so long (25 minutes). A bit disappointing.
Tuesday, January 1, 2008
Although the book is apparently error-free, and has the reader make some interesting games within the distinct limitations of the engine, it suffers from the major problem of all such books. I call them "monkey books", because typically the reader rushes through the instructions, finishes the project (not without various detours in some cases from failure to follow instructions), and has little to no idea of what he or she actually did. I think of it as like monkeys somehow following directions but being no wiser when they're done. A person can certainly go much more slowly and try to understand what is happening, and the book usually makes an effort to explain why it is necessary to do such-and-such, but typically this is ignored by the students. I tried to go the slow route, and was frequently amazed that the students finished the projects so much faster than I did at home.
Even though it is possibly the best "monkey book" I've seen, it is still a monkey book. Worse, the students get sick of "monkey business" in the long run. They want to "do their own thing".
What can be done about this? The students MUST learn the basic techniques of Gamemaker if they're going to make simple electronic games of their own. Yet some students point out, quite correctly, that they won't be listing Gamemaker on their resumes. (It should be said here that last year this class began using the Alice programmer training environment, but that didn't prove to be very good for games. Gamemaker became the substitute.)
A big problem with the syllabus I inherited, is that the lab (Gamemaker) is a significant part of the grade and the majority of the class meeting time, but no testing of Gamemaker knowledge was provided for, while the CD in the book contained all the finished projects and their milestone versions. So having students hand in a completed project was pointless and proved nothing. In the end I told the students the lab grade would depend heavily on their attendance, and that I could not give them credit for projects they might do outside of class because they might not be doing anything at all! With no testing, students did not care a great deal whether they actually understood Gamemaker or not, once again encouraging "monkey" methods.
However, I am not a proponent of testing as a way to encourage students. I'd rather have them do something productive and instructive--testing is neither. What I would do in a future version of this class is, unfortunately, a bit more work for the instructor, but better for the students. We would still use the textbook as a means of introducing/reinforcing various programming techniques associated with Gamemaker, but we would spend more time creating very simple games, in part collectively, in part individually. We would discuss the designs of these games, discuss how they can be structured for Gamemaker, discuss whatever is needed to make the actual creation easier, and then have the students do it.
We would make "clones" of well-known old-time video games, provided Gamemaker was up to it (and usually it will be). These games, though simple, clearly had good gameplay, good design, and are still played by many people now and again. The games in the textbook are clever, but the students don't connect with them/identify with them the way they might with the famous old-timers. Examples in rough order of increasing complexity:
• Space Invaders
• Donkey Kong
• Missile Command
Even though these would be clones, I think there would be more sense of accomplishment in figuring them out, and in having a variation of a famous game, than there is in reproducing monkey-style the games from the Gamemaker book.
Second, we would "mod" existing Gamemaker games, whether the ones included with the textbook, or others we'd obtain online. (There is one chapter of the book that mods a game from earlier in the book, though in this case the reader observes the effects of the modding, rather than doing the modding themselves.) I would probably mix these two activities together with material out of the book.
In the end, the class is supposed to be about game design. But if students are going to get jobs as designers--level designers, almost certainly, not game designers--then they'll need to produce games for their portfolios, and so we're trying to "kill two birds with one stone". The class MUST do non-digital games as well so that the students can concentrate on game design rather than game production, but doing the game production helps the artists and programmers learn things they need to know, as well.
"Always do right--this will gratify some and astonish the rest."Mark Twain
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." Antoine de Saint-Exup'ery
"Not everything that can be counted counts, and not everything that counts can be counted." Albert Einstein
"Make everything as simple as possible, but not simpler." Albert Einstein