First, try the installation document. If that fails, contact the author.
First, try the troubleshooting document. If nothing there works for you, contact the author.
Start with the documentation index, and work out from there. If it seems like the information you're seeking is just not there, contact the author.
PIGGE is an acronym for Perl Interactive Graphics and Games Engine, and is a 3D engine written in Perl.
Because my goals were different from those leading to other engines; different goals, different engine.
Sure. My goals were:
Oh. Well, see the next several questions (linked from the above list).
Programming a 3D engine is not exactly easy, but mostly it's a matter of having a lot of random knowledge, and some mathematical skill -- about what is expected of college sophomores. Yes, there's an art to making a good engine, but even the best engine is meaningless without content (art, music, game design, and so on). Well, aside from educational value, I suppose; see a later question. Content, on the other hand, is hard, takes a tremendous amount of both talent and time, and is what makes or breaks a game. I don't want to lose the amazing game design forming in an artist's mind, just because he doesn't happen to be a programmer, or have easy access to a free engine to work with. Essentially, I want to lower the barrier to entry for content makers.
There are a lot of crappy engines out there. Some of them produce nice visuals and sound, but are a horrible crufty mess internally. Others are relatively clean inside, but are anemic in features, only containing the abilities required by a single game, or a single genre. My goal with the PIGGE engine is that it support the gameplay of every freely available 3D game out there, and have an easily extended featureset that will grow to accomodate entirely new genres in the future. In addition, the license will be sufficiently free that no one should have a good reason to use a crappy engine in the future. Of course, during the early development phases, PIGGE itself will inevitably have crusty bits, and lack many features, but that's why it's called "early development".
I believe that with performance and feature improvements to virtual machines, and the large (and growing) performance differential between graphics processing hardware and CPUs, the time has come to dump mid-level implementation languages such as C++ for 3D engine design. In particular, I think the best implementation for a 3D engine will consist of a combination of a very high level language such as Perl for the majority of the functional code, and optimized kernels written in low-level or purpose-built languages such as VM assembly and shading languages. With as much processing as possible offloaded to the graphics subsystem, the traditional advantages of very high level, dynamic languages should make for a vastly simpler, smaller, easier to maintain system, while still retaining most of the throughput of a C++ implementation.
I find that most 3D engines are (to put it mildly) a mess inside. That makes for both a maintenance nightmare and a serious headache for people trying to educate themselves by reading the code. There are any number of methods for keeping things clean inside; I've focused on a few for PIGGE:
I love to teach, almost as much as I love learning new things myself. PIGGE is an opportunity for me to educate myself on a great many topics in real time computer science, and it's also an opportunity to create a teaching environment that can be used by others to get a leg up and avoid many of the dead ends and blind alleys that I went into. For some, PIGGE may simply be a base to build on, because their area of interest lies at a higher level. Whatever the situation, PIGGE has been designed to make it easier to learn whatever you want. It includes a growing documentation tree; a clean, easy to read code base; a data-driven design that allows many changes to be tried out without touching a line of code; and a great deal of flexibility, so that whatever your interest, PIGGE can be bent to your will.
Above all, I find this stuff fun. If you're anything like me, you could spend years playing with game and graphics code and never get bored. The truth is, this is probably why most 3D engines get created, and why there are hundreds of engines out there already. Even if you don't use PIGGE yourself, I'd be happy to hear that it encouraged you to give engine building a try. If you don't think it's fun, I hope that PIGGE convinces you to change your mind. And failing that, well, thhhbbbbbt.
Sometimes the simplest things take the longest to truly understand. In my case there's a simple programming principle that took me a good quarter century to really grok, and I suspect I've probably got more to learn about it. It's hard to really put into words (think Zen), but many people have talked around it over the years. "As simple as possible, but no simpler." "Do the minimum necessary." And so on, all of which are nice quotes but not terribly helpful.
A little more useful is "Until you've done it twice, you don't know how to do it the first time." Some things I've done a thousand times, and a good design is obvious from the outset. I just code that directly even if it takes a little more work, because I know from long experience it's the right choice. Some things I've only done a few times and I'm not confident that I know the best way (or even a good approximation). In that case, I'm more cautious of overdesign, and tend to do a mixture of design and baked-in assumptions. Even if one of my assumptions turns out to be wrong, there's not too much effort involved in reworking the code. I've got better things to do with my time than build up and break down big scaffoldings over and over. On the other hand, if my assumptions were right I just saved myself a lot of design and coding time.
Finally there are the things I'm coding for the first time, or the first time in a particular context. In this case I feel pretty safe hardcoding the heck out of the code, because I know I'll soon be back with more experience, and can morph the design in the right direction. In fact, I will often seek out another use case that impacts the same section of code so that I can force this to happen earlier, on the principle of limiting the scope of egregious hackery (both in time and (code) space). In fact, one of the most important reasons for the ports tree is that replicating numerous other programmer's functionality forces me to revisit code I had no idea needed to be refactored or had only dimly realized was the product of inexperience.
At this point PIGGE is getting to a reasonable size, with thousands of lines of code. At any given time there are dozens of code blocks in each of the states above. Some are so solid that they may not get changed for months; some get a good workover on a monthly basis as cruft builds up, and basic principles from multiple use cases become clear that can be the basis of a refactoring pass; and some get scrambled every time I add functionality anywhere near them. This is a healthy state to be in! For each function, I've expended effort proportional to my experience with the function and its importance to the code base. I've also avoided wasted effort on things I don't really understand or that don't require grandiose design to get the job done.