Re: Guidelines? (And a quick note about the website)

[Timothy Twelves <trix@goshawk.is.und.ac.za>]

Hi

I've been following pp for quite some time, but have never had enough time
to pick up a programming part in the project.  I do have some comment on
your possible design structure/steps forward.

Before you even start programming, you should have you're API's well
thought out, and then possible get some comment back from game developers
themselves.  After all, you dont want to program something and find that
noone's going to use them.  By game developers, I mean corporate game
companies.

Approaching them might be easier now more than ever.  Linux is getting
some light in the media and i'm sure game companies would be interested in
commenting on API interfaces.  A good, stable, preformace related set of
SDKs are what gamedev's would want for linux before they even think of
moving software to the linux platform.  They want to minimise time of
porting to linux, and we want to ease creation of games using linux (or
any unix).

Design, RFC, Redesign, RFC, Redesign, Implement, Debug, Implement,
Optimize, Advertise, . . .

The biggest part is getting a non-redundant API working.  Which means
you're not trying to hit a moving target while you're programming.  Aim
high, aim very high.  The API should include everything possible, even if
it were not implemented in hardware, and it must be implemented.

In the end you've gotta consider what the APIs for... you're ideally want
games being bought off the shelf that can be run on linux? right?
Starcraft for Linux?

Anyway, my few cents on the topic.

Tim

PS: Greene is very correct on knowing whats ahead.

On Fri, 26 Mar 1999, The Greene Family wrote:
> I'm aware of development stages sir. :-) I just think about things ahead of
> time, probably a character flaw of mine, but my excuse is that i like to
> know what's coming before it hits me. :-)
> Derek 

> At 12:58 PM 3/26/99 +1000, you wrote:
> > Here, here! Don't want to get too far ahead of ourselves. Something like:
> >-Design
> >-Implement cross-platform C/C++
> >-Debug
> >-Refine design, fixing the things we got wrong.
> >-Debug final design
> >-Once design is finalised & portable C/C++ code working, THEN optimize
> > with architecture specific assembly where needed.
> >(probably missed something..)
> >
> >btw, Eelke Klein has already done a preliminary sound interface, minus
> >3dsound, surround sound & other fancier stuff.