[Edu-sig] re: The trackball reality

[Kirby Urner]

I'm teaching a class billed as a combination of Python and geometry.  It's
for middle-school aged home schoolers, though one student is I think early
high school age, plus his mom is learning too.

This desire to program a kind of fantasy world interactive game is strong
with several students.  It's sort of the "hello world" paradigm they have of
what programming is good for.  Programming is about writing interactive
games, duh.

Rather than fight this paradigm too hard, I've decided to use it, as
geometry is still in the picture:  characters have a position in space
(either on a flat surface or in volume).  So we need to change their
coordinates, figure out when they hit a wall and so on.  There's some
geometry involved, and more could be added.

So we started with the basic data structures (list, dictionary, string),
moved up to functions (def), then string substitution in print statements
(madlibs), then classes.  At this point, I started showing a game paradigm,
with a Game, Player and Powerobj (power objects) classes.  

Instead of enough fluency on their part to write such a game themselves, I
expose them to already-written examples.  I think this is a very valid
approach, by analogy with language learning.  We need to be exposed to the
'real thing' in a more mature form, learn how to read, with the grammatical
stuff already taken care of.  

Exposure to pre-written code gives us an appreciation for the overall
structure (we can take apart the source, analyze it), plus (and this is the
best part) we can run and test the code (and modify it to suit as time goes
on).

But a lot of this discussion is somewhat orthogonal to Arthur's original
post, as doing a primitive game framework and using it as a basis for
further learning, does not require digressing into heavy use of any kind of
trackball device, nor even into using visually-sophisticated graphics.  My
game.showboard() method just spits out an ascii representation of a
rectangle, with characters as capital letters.

Of course we could get Pygame working, or VPython, and start moving towards
fancier representations, and in a geometry class you'd think we might.
However, at this juncture, where we're still just learning basic Python, I
don't want to introduce the overhead of additional external frameworks and
add-ons.  It's just to soon for that.  

No trackball, no gee whiz graphics, yes lots of text-based stuff, yes game
programming paradigm.

My source code examples, what we're using in class, plus some other
materials, are at my web page for the course:
http://www.4dsolutions.net/ocn/pygeom.html

Kirby