Re: Definition of "The Right Thing" (long)

[Brad Johnson <foxtrot@autobahn.mb.ca>]

	(Note: These replies are from multiple authors, but I decided I'd just
reply to the rest all in one email, as it's easier for me)

[Michael Day <mikeday@corplink.com.au>]
> Certainly Windows is an environment that appears to prefer huge, ornate
> applications that can't talk to each other, although that too is changing
> now that everything is Just Another COM Object(tm). It's certainly an
> interesting topic, but for games take the easy route, cram as much in as
> possible, makes the game more fun to play :)

	The "Just Another COM Object" approach is starting to get into Linux
too though, just look at the KDE and Gnome apps, and a lot of them are
actually starting to work very well together. For the most part though, stuff
like CORBA works great for word processors and spreadsheets, but I don't see
any need for a game to use it (perhaps as a plugin architecture? though that's
probably a more difficult way...)

[Bert Peers <rat@larian.com>]
> Sounds a bit like pragmatic vs theoretic, either you want a reasonably good
> product in a reasonable time of development, or you want The Ultimate
> product but that could take forever to finish/get stable/learn to use/...

	I think that adding features in at a later date can be very difficult
though. I mean, what if all of a sudden you decide you want to add in a freeze
ray, but some aspects of your game prevents characters being frozen for some
reason? You might have to rewrite a lot of the game just to support that one
weapon. However, if you went with a more general approach straight from the
beginning, you leave yourself way more room. Of course, like you say, if you
start off with something simple, you can release it right away. But if you
began with plugins for everything, it would take longer to get it into the
initial usable state. I suppose a balance has to be struck somewhere.

[Bert Peers <rat@larian.com>]
> Maybe the Right Thing is making the concept of a plug in so simple, that
> a program that doesn't accept any plugin at all seems as silly to us at that
> time as a program written entirely in assembly.

	After reading the man page for dlopen(), this has almost become my
opinion. Plugin's are quite easy, and I don't think it would be difficult at
all to implement them in almost everything. This makes the program very
expandable. However, how much overhead does this add to the program? In Linux,
I get the feeling that all the overhead is already there in the C library and
such, so it's not really an issue.

[Michael Nachbaur <nachbaur@nachbaur.com>]
> Ideally, I think the Enlightenment model works best.  Don't ever stop
> cramming features in, always look to the greener hill, and always pay
> attention to good user feedback.  You don't have to heed their advice, but
> listen to it.  And, never be afraid of rewriting a large chunk (or all) of
> code for the good of the system.

	I like Enlightenment too, and if I ever wrote a window manager, it
would likely try to take E's footsteps. But I've noticed a lot of people who
believe it is way too bloated for a window manager. Sure, it has TONS of
features, and can do anything you want, but there's a price to pay for it.
Most of the time, I just use FVWM, because all I really need most of the time
is to be able to move the windows around, and iconize them occasionally.
Loading up E and Gnome and such is a little excessive if all I'm doing is
testing if my latest X program will segfault or not.

	I have to say, I'm glad X itself is so versatile as to allow me the
freedom to choose wether I want all kinds of bells and whistles on my windows,
or wether all I want is a handle. (But then, many people claim X is bloated
too...)

[Michael Nachbaur <nachbaur@nachbaur.com>]
> There are times when small/separate programs come in handy (awk, cp, etc.)
> but a game is not one of 'em.

	This is a very good point. Often, games are expected to tax the system
nowadays. And why not? It's rare that you're running anything critical in the
background, because all your attention is on the game (Well, maybe running an
mp3 player or such). Take Quake for example. It has more features that you can
shake a stick at, but it's the features that make it so good. Besides, if you
took out it's programmability, it would still hog resources to render 3D and
all (Yes, I'm using a software renderer... My pc is dimensionally-impaired).
In retrospect, the question of minimalism or ultra-usability would probably be
best posed to the Gnome or KDE lists. It doesn't much apply to games.

[Michael Nachbaur <nachbaur@nachbaur.com>]
> My method for judging what is the "Right Thing" is when an idea is
> introduced, and I think "Whoa!  Cool!".  Thats when its the Right Thing.
> If no one can use it in the immediate future, who cares...someone,
> somewhere, sometime will find it usefull, and will thank you up and down
> for putting it there.

	I usually think this too. I used to write programs that just did weird
graphic tricks and cleared the screen in different ways. They looked cool, but
I never really used them for anything. But at what point does the unused parts
of your code begin to get too bulky? 

[Philipp Ghring <p.guehring@xpoint.at>]
> Wieviel Platz braucht ihr denn?
> Ich hab eine Kombination aus ics.at und xoom.com genommen.
> Unter ics.at liegen alle HTML Seiten und Perl Scripts und Perl Daten,
> und xoom.com alles andere. (Mega-Downloads)

	Oh, ah, actually, I don't speak German, and that's a different thread
altogther :)

	I think there's another side of this whole story too. I just realized
it when I noticed a program called popexec (Please note, I am not insulting
this program at all, nor praising it. It just happens to be a good example for
me to use). I'm sure everyone here has noticed the multitude of programs that
watch for incoming mail, and then play a noise, or they open a mail reader or
such. Well, popexec happens to just execute a file. It seems very simplistic
to me, but I suppose it has almost limitless expandability. I mean, you could
get it to do almost anything by having it run a script. But it seems to me
like a lot of this expandability makes you work harder to get the program to
work. With a simple program like biff, all you do is run it, and it'll tell
you when you have mail. But popexec would require more customization to
achieve it's expandability.

	This seems to almost be the Unix attitude though; Anything is
possible, as long as you know how to do it. There are lots of program out
there that do exactly what they intend to, and there are programs that do half
of what they intend to, and let you do the other half. In many ways this is
good. For example, you have Quake (Yes, I use this as an example a lot). But
if you don't like the game, you can modify the levels/weapons/etc. If you
don't like the engine, you can write your own with Crystal Space. If that's
not good enough for you, you can write your own damn thing in C.

	This was more of an observation than a question really. Is it best for
your game to be a "pure" game, or do you want most of the functionality in a
library, and your game is just a set of calls to that library. Just some
thoughts off the top of my head.
								--Brad

(I hope all that made sense... it seemed to when it was in my head :)