[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[org] Aiming for Release 1
Hi all.
You saw the recent mails where Peter pointed out that there's confusion
regarding PPlay's goals, especially about what we're aiming for right now.
So here's a draft describing that. It's still little more than a skeleton
and needs to be filled by the People In The Know.
Ok, the goal of PenguinPlay was and still is the creation of a set of tools
(libraries and applications) covering everything needed for writing quality
games.
Release 1.0 of PenguinPlay has to fulfill that goal (surprise!), but it
also shouldn't do much more ('cause we want to get it out before the next
millenium). So we need the following core functionality:
PenguinGraphics
Penguin2D
Penguin3D
PenguinSound
PenguinNet
PenguinInput
PenguinSupport
PenguinFile
PenguinConfig (see below)
PenguinEvent
PenguinTools
PakCompiler (?)
!! list of existing tools !!
And these parts have to specify their goals for R1, too:
Penguin2D
Not sure. Perhaps a combination of libggi+libggi2d functionality
(framebuffer access, drawing primitives, blitting funcs, alpha
support)
Penguin3D
<fill in>
PenguinSound
<fill in>
PenguinNet
<fill in>
PenguinInput
<fill in>
PenguinFile
Access to Perfectly Normal Files, evtl. PakFile support
PenguinConfig (new sub-part)
management of PPlay options, settable via some function (i.e. by
the game), cmdline parsing, if possible configfile parsing
PenguinEvent
Has to be almost complete. Event transport, distribution, queueing
PakCompiler
only neccessary if PakFile support is in PenguinFile. But then it
has to have 100% functionality
List of existing tools
gfx apps, IDEs, editors, etcetc. Just a list, but a good one.
This should be done together with the LGDC (everything else would
be stupid)
Ok. Please fill in your stuff, guys.
Stuff that's certainly not needed in R1: GUI, AI, GameSpace
BTW - A note about the two-layer model (P/O). That's mostly obsolete, as it
doesn't make much sense for most parts (e.g. in Penguin2D Layer P is simply
libggi*). Having a procedural API for all base functionality is still
important however.
Cu
Christian
--
AAAAA - American Association Against Acronym Abuse