Friday, December 23, 2011

Learning to Program

I just finished teaching the senior seminar in Advanced Game Design at Digipen University here in the Seattle area.  For those who do not know, Digipen is an accredited four year university that offers BS, BA, and BFA degree programs.  The unique thing about the school is that they focus the curriculum and career counseling entirely around the video game industry.   Now that the class is over, I have been thinking about how to teach game design to the current group of students.

When I first accepted the Digipen position, it had been several years since I had taught anything, but I actually have a long history of teaching.  The first job I ever got a paycheck for - back in 1983, when I was only 15 - was teaching computer programming to kids.  It was considered peer instructing.  Classes were taught on the Atari, in Atari Basic, and mostly involved PRINT, GOTO and FOR/NEXT as I recall.  In the advance class, I also taught video game programming.  You couldn't do much game-wise in Atari Basic, but I did have them make a little ASCII tie fighter (|=0=|) that was chased around the screen by two  space mines (*).  It was simple, but it had all the basics.  Reading user input, updating the enemy, detecting collisions, keeping score, and the notion of levels.  A week of classes for a kid was around $40, I recall, taught at the local computer store (EBM).


This was enough to make most kids happy, but some kids really wanted more.  Unfortunately, doing more on the Atari meant jumping into 6502 Assembly language.  There was no such thing as C or other high level languages at that time so it was assembler or nothing.  And for kids that merely wanted to move some sprites around the screen, learning the ins and outs of accumulators, registers, display lists, ANTIC, CTIA, and so forth was way too much of a wall to scale.

I didn't have that problem.  My life in computers started at a much lower level indeed.  My first computer was a Bell Labs CARDIAC.



The CARDIAC was a computer made entirely out of cardboard.  In fact it wasn't much of a computer since it essentially used YOU as the CPU, and you programmed it by first writing and then decoding machine code yourself.  I am not sure how old I was when I got it - probably like 8 - but I know I loved it.  I actually created a tic-tac-toe program for it, which I would be willing to bet is the most complex program ever created for this "device".   I remember spending weeks trying to figure out how to "encode" the state of the tic-tac-toe board, and that first amazing rush when I came up with an encoding which worked not only for storing the game state but which could also support the game logic.  That was probably the thrill that led me to continue my pursuit of programming in the first place.

I begged my parents exhaustively for a computer, and eventually I got my wish.  My dad bought me a HeathKit ET-3400 microprocessor trainer.


Because this was a HeathKit, the first thing I had to do was solder all of the pieces together.  I got this for my 4H electronic projects, so I was meticulous with my soldering.  I remember when I entered it into the local fair, one of the judges thought that it had been soldered by machine!  I was very proud.

You programmed the HeathKit by entering the machine code instructions in Hexadecimal using the keypad.  It sounds almost crazy now, but this was so much more high tech than the CARDIAC that I was in heaven.  After getting all of the self-tests and everything working, the first thing that I did was write a program that would like the user enter any two numbers and present the sum of them.  I proudly showed it to my Mom and sisters and asked them to try it.  My first sister entered "16" and "34".  She was not impressed when the answer came back as "4A".  Apparently she was expecting "50".  I quickly tried to explain hex vs. decimal, but the moment was lost and she wandered off.  My mom was still a good sport and suggested "200 + 100".  I quickly converted to hex (C8 + 64) and entered them for her.  The answer came back as "2C", which I translated to "44" for her.  Again, she was not impressed and was apparently expecting more like "300".  I again quickly explained that the maximum number I was displaying was 255, and anything more than that would wrap around again.  300-256 is 44, so the answer was correct!  Again, the moment was lost.  My mom smiled in a sort of pleasant yet distant way and went about her work.  In the years and decades to come, I would see that smile many more times.

I guess I am thinking about all of this now because I wonder what it is like for kids nowadays who want to use computers.   On the one hand, it is so easy now to get something on the screen.  There are lots of tools - from Kodu to Codea - that let people make games with little or no programming.  No more sweating over the hot assembly language.  But when it is so easy to get beautiful graphics on the screen, are people still going to be motivated to learn how things work under the hood?

Since those early days at EBM, I have taught many students in a variety of different roles.  In working at Microsoft Research, I would often teach classes in interaction design or game design for students in China and Japan at a variety of Universities.  I rarely found a student who had a deep understanding of how computers worked.  That is, how you can make a machine that can compute something.  For all intents and purposes, it is all just magic to them.  I even meet many supposedly hard-core computer science graduate students that cannot describe how to make a full adder out of logic gates, or really explain how a computer can talk to another over a wire.

The real question is - does it matter?  We can accept that a composer does not need to know how to play an instrument, or that a pianist doesn't need to know how to make a piano.  But does a pianist even need to know how a piano works?  I honestly don't know.  It bothers me when I see people who spend all day working on computers but who fundamental treat them as magical devices.  But a lot of people treat flush toilets the same way.  Does it really improve the experience to know how the sewage collection and treatment system works in a major metropolitan city?   Does it matter for the user?  Does it matter for someone creating a better toilet?  Perhaps not.

Japanese are way more advanced than us in the toilet department


But perhaps so.  I mean, people with more knowledge of the sewer system probably use less water.  They probably are less prone to dump harsh chemicals or strange objects down the drain.  Maybe it just makes them more responsible.  Maybe you need to have a deep knowledge of the sewer system to design a better toilet.




No comments:

Post a Comment