UI idea: MOOOS :)

[Thomas M. Farrelly]

Tom Novelli wrote:
> 
[ MOOOS ]
> So, the first thing we write for Tunes should be a game.
> 

I so totally agree with you here. With TOOL I was thinking about
creating "an empty" networking game. It would be like a MUD, but
preferably graphical. The ability to create new objects or artifacts,
could be directly connected to "experience points". So in a medevil
environment, coders would be magicians, and the 'new' object would
correspond to a spell :) I think this would be very good motivation for
people to get started using the system, and from what I've seen in the
quake scene, people really love this. And you get alot of non-coders
coding ( even if they don't know it themselves ), which produces a very
inspiring and productive situation.

Such a virtual world is also a great experimental ground, where people
can try out ideas which generally is very expensive and risky to do in
real life - like digital money and security.

Fact is, that making a game instead of an OS, has may pros ( that I can
think of ) :

First of all we're not obligated to porting/writing all the drivers,
because our game could run as happily run on top of something as it
could on its own.

It lets us more freely consider alternative interfaces. Not because we
actually have more choice, but because it's "just a game". And a
particular idea of TUNES in the first place is _interface_independence_,
so if, eventually, this turns out to be a problem, then we would have
failed anyway:)

Generally, developing a game instead of an OS ( read on, I don't really
propose this ), would take the edge of alot of difficult, architecture
dependent and other issues. Which, the way I see it, has less to do with
TUNES, and more to do with the way we chose to "simulate" the TUNES idea
on existing systems. And it could be the vehicle of much rejoyce and
inspiration - for all of us. Any preferences or experience with gaming
or game development?


Now, choosing the game approach, could lead us into believing that we
have TUNES, when all we have is a overly flexible game. It's a trap we
must be careful not to fall into. But, hell, choosing the OS approach,
we might end up with a perfectly good,
just-as-f*-useless-as-everything-else, OS.

To me ( and my OO-rated approach to TUNES :), creating a game still
leaves us with the essential problems of TUNES - extensibility,
portability, inter-architectural comunication, ease of use, security and
fun. And we get to go there on very comfortable and abstract terms -
like a virtual world, where things are objects, and everything is
possible.

And if we did succeed, our game would _be_ TUNES ( only some of the
concrete object in it would have silly restrictions on them, like this
object is dead, but that would be only the in-game objects, to which
death applies ), because in a game in TUNES, browsers, data-bases,
interfaces and everything would be possible to add as in-game objects.
And one potential everything is as good as another potential everything,
right ? :)


 
===============================================================================
    Thomas M.  Farrelly     s720@ii.uib.no     www.lstud.ii.uib.no/~s720
===============================================================================