Archive for January, 2017

A little in-service. Finally.

January 30, 2017

I am excited, but then I excite easily.  My local university, University of Montana, on my local campus, as opposed to half way across the State, which is a long, long way away, is offering what could be considered an in-service course for programming teachers.  It is a modification the U.C.  Berkeley Beauty and Joy of Computing.  It seems to have been re-branded the Joy and Beauty of Computing (the J before the B).  Not sure how or why but I am not being fussy.  Yes, it is a bit of a canned course but again, I am not going to be fussy.  The course is wrapped around Python, which is great for me.  I need to do some upgrading of my present Python offering.  I am hoping the course will not turn out to be simply the JBS course.  I do not need a low level Python course, I can read and the course is intended to be a self-guided course.  What I want is how to teach the course, how the curriculum works, where the kids have problems and how best to address them.  You know, all the stuff a teacher needs to know to actually teach the course.  I will walk in with an open mind and if it turns out to be a Python programming course, well I will live with it but not happily.

Another happy piece of news is UofM is building a CS Ed minor.  I have only been trying to get something going over there for 10 years.   It supposed to be in place this fall.  It is still in the approval stage and the powers are being a bit closed mouth about it at the moment.  I am hoping (I hope a lot around here) that it is not just the CS minor with some Ed school courses thrown in for looks.  Considering the number of schools in Montana that want a full-time CS teacher (zero) a CS minor is a bit of over-kill.  What we need in Montana for now is a certification program that is practical for in-service teachers with little CS/programming to get started with.  I think the JBC course is intended to be the beginning of that route.

No matter what these two turn out to be they are both a step in some direction.

Human Experimentation with a Programming Class

January 20, 2017

This year I am teaching a course titled “Intro to Game Programming”.  With a broad title like that I can teach almost anything or any language.  I wanted to get a lot of kids into my programming classes so I figured if I give the course a cool name they will sign up.  They did.  I have 20 kids in the class this semester.  Not bad for a school of 175 kids.  I also wanted to look at game engines as a teaching tool so I guess you would call this live experimentation on humans.  Cool.

I originally started with GameMaker and Corona (Lua) but after looking at the future in my crystal ball, which is oh so reliable (it did not predict Trump but then nothing else did either), I have moved the class into a couple of industrial strength game engines.  I have part of the class in Unity and part in Amazon Lumberyard.  In both cases I just looked for really cheap or free textbooks.  In both cases I hit the jackpot.

For Unity we are working through Patrick Felica’s “Unity From Zero to Proficiency”.  This is actually a series of books that starts at the absolute “do not know didly” stage and advances to a fairly proficient level.  Patrick actually solicits advice and suggestions on improving his books so I give feedback from my students to him.  Considering the price, the resources and the readability it is a great way to go.  Are there errors in it?  Yup but so far they are things that can be figured out.

Amazon Lumberyard is a real experiment.  Amazon bought CryEngine and is revamping it.  The new Lumberyard version is new, as in maybe two years?  After reading the reviews comparing it to Unity I was not going to bother but the author of the textbook I use for Corona suggested I give it a try.  He would send me an early release of his new Lumberyard textbook to beta test with some kids.  New software?  New book?  Human experimentation?  What could go wrong!  Let’s go for it!  So I have three of my sharpest kids working through the book and taking editorial notes as they go.  The book is Dr. Brian Burton’s “Game Design Fundamentals with Amazon Lumberyard: Space Explorer”.  The book is a complete game building course starting with building the objects with Blender, shading with GIMP and then game building with Lumberyard.  The book is very incomplete at the moment.  Chapter 3 is about 8 lines, pictures are missing captions and so on.  Very early release.  I love it.  Instead of the kids just reading the tutorial and following along they actually have to figure out what Dr. Burton’s intent is and fill in the blanks.  I get editorial suggestions from them at the end of the period and forward them on to Dr. Burton.

At the moment the “programming” part of the course has not hit the traditional concept of coding.  We are building things now.  ZtoP uses Javascript for its language and Lumberyard uses Lua.  I know nothing of Javascript and I know Lua in a different environment.  No problem.  After taking a quick look at the programming chapters in ZtoP we should do just fine.  Dr. Burton has not written the chapters on programming for his book yet.  This might be a slight problem but there is always hope the chapters will arrive before the kids get to that point.  After all this is human experimentation so there is a bit of risk involved.

Learning by mistake

January 2, 2017

It is a method.  It is a long, slow and frustrating method but it does work.  For example my latest project is learning Unity.  Unity uses C# as its scripting language.  No big deal there, I know enough C# to get me in trouble so I should be OK.  I am learning through doing so I am building a little 2D platform game just as a learning exercise.  I got the basics down so I figured I would get cute and build a recycling elevator to carry my little character up to a higher platform.  Many hours and several days later the elevator still drops like a rock.  No continuous up and down like I want it to.  I have perused all the Googled suggestions, tried all the sample code and even, at this point, understand the code.  Owl boogers.  This should work.  I am at the point of just staring at the screen.  It works!  (The staring at the screen part, not the elevator part.)  Somehow I made my elevator platform a Rigid Body.  Rigid Bodies are subject to gravity.  If the platform is subject to gravity it falls off the screen.  I kill the Rigid Body component and the elevator works.

How has this helped?  I rewrote the code in about 5 different ways and I understand them all.  Before I was just cut-and-pasting with only a vague understanding of how this worked.  I know to watch out for the Rigid Body thing.  I know after hours of trying different code and scattering print statements all through the code to see what is happening that sitting back and staring at the screen is not a bad thing to do.  I know that even though I spent many hours trying to find the solution when it was actually something really simple having nothing to do with the code I was troubleshooting, I came away knowing a lot more than I did going in to the problem.

I also learned that although making mistakes like this leads to great learning experiences, it is still a royal pain in the ass.

Now I have to figure a way of teaching this technique to my students in a way that they do not think I am more of an idiot than they already know I am.