[Edu-sig] PySqueak: More on Croquet and 3D (was: Just ran...)

[kirby urner]

Hi Paul --

You bring up a lot of important issues, I think the main one being:
how real do we really need it to be?  And leading up to that:  what
parameters are we talking about, when measuring the degree of realism?

I think an important language game to hold in mind as relevant is that
of chess.  The strategies don't change just because the pieces get
more detailed and animated.  P-K4 is still P-K4, even if the King's
lip is seen to quiver (hey, that looks like Johnny Depp!).

So in some sense all that texturing is extraneous in chess.  And yet
artisans lovingly carve chess sets out of every material (or build
them in OpenGL), using a vast assortment of designs.  Why?  Because
there's an artistic dimension orthogonal to the ostensive goal of the
game (to checkmate your opponent).

I get lost in this orthogonal dimension playing multi-user Quake or
Doom.  I'll just start admiring the artwork, smiling at all the
skillfully rendered skulls, nevermind the loser pumping me full of
bullets just now.

They say chess is a war game, and this spectrum between spare
iconography, versus vividly detailed scenes, is played out in the
military sphere big time.  Battlemaps, perhaps laid out as tiles,
perhaps hexagonal, contrast with a more on-the-ground first person
presence, sighting down the barrel of a gun or whatever.

Computer games will often emulate both aesthetics, as does ordinary
fiction.  We're accustomed to a mix of first and third person.

When it comes to highly detailed renderings, keep in mind why computer
games always seem tackier, less realistic, than state of the art
computer-generated movies:  the latter have all the CPU time they need
for each and every frame whereas the former have to keep a human
player entertained in real time, a whole different ball game.

Sustaining a high enough frame rate is what applications like Croquet
and Civ IV have to manage (many per second), whereas frames of 'Shrek'
might each take an hour in some rendering farm.  It's like the
difference between having hours to rehearse, versus spontaneous
improv.  Which isn't to say the skill sets aren't overlapping.
Practiced actors are also better at improv on average.

Anyway, I think the degree of realism needed, and in what dimensions,
is very application-specific.  That's why it's dangerous for the OS to
weigh in too heavily with a graphical view.

I like the stronger dichotomy between the GUI and kernel in Linux.
Windows users get confused by this, thinking GUI and OS must be
synonymous.

For the same reason, I like it that Python-the-language isn't too
vested in any one GUI solution.  It's a lexical controller of an
abstract model, via some API, not a view.  I think we should keep it
that way.  We're not trying to come up with the one set of graphical
motifs that "defines Python" -- because Python is ultimately lexical,
not graphical.

Python's "look and feel" has to do with syntax, not the shape or shade
of the widgets.  Python isn't Java, and no, we don't need our own
version of Swing.

So the degree and type of realism is application specific, is not
defined by the OS, is not defined by Python.  Python, like the OS, is
fairly agnostic about the user's world, its look and feel.

I don't imagine oil executives want cartoony avatars on screen, but
having all present gaze upon a shared view of some new drilling area,
complete with high def representations of rigs, pipelines (current and
projected), equipment and crews, makes the meeting more effective and
productive.

Oil execs are more like generals pouring over a battle map.  Their
vista is more game-like than ultra real, although shifting to overhead
photography ala Google Earth is always an option.

Kirby

PS:  I'm posting from my borrowed Edubuntu box for a change.  Dave
Fabik (appears in my blogs) lent me this Buffalo ethernet converter,
which goes from wireless to a regular ethernet card.  It's browser
configured.  This way, you don't need to mess with some PCI wireless
card or other gizmo needing a Linux-specific driver, provided your
eth0 NIC is already operational.