NOBLE APE MAILOUT - FEBRUARY 2006
WHAT IS NOBLE APE?
WHAT IS NOBLE APE?
As the decade of Noble Ape looms, I'd like to spend some paragraphs this mailout exploring the question - what is Noble Ape?
For me, Noble Ape is a series of ideas over time. These ideas are best described through documentation rather than source code (in the most part) and that is why the original manuals are particularly important. Over the past month, I rediscovered one of the spin-off developments from Noble Ape in 1998 not as source code, but as documentation. The first five years of Noble Ape produced a number of spin off projects - the source code of these projects is long-obsolete but the documentation for a number of these projects persist to this day in a wide variety of archives.
Noble Ape as the Noble Ape Simulation is something I don't personally see. I think of Noble Ape as something quite different to the Noble Ape Simulation. It's unquestionable that the Simulation is the must recognisable part of the development. I've tried to estimate the number of users of the Simulation over the past decade. The largest number is the total number of Macs sold over the past three years. About eighteen million total. Of course, a small fraction of these folks probably install Noble Ape. With the departure of Sanjay and Nathan from Apple, time will tell what will happen with the Noble Ape inclusion with Apple's future machines.
Consider Noble Ape as a number of technologies that can exist autonomously. This is, in part, the spin-off project model of the first five years of Noble Ape. The current development of Noble Ape lends itself to the autonomous model but rather than being insularly autonomous, the new Noble Ape autonomous allows other developments to benefit from features of the development. This collaborative communication should yield a number of interesting examples of Noble Ape as component technology.
The decade has been remembered by others on the Noble Ape site;
As a subscriber to one/many of the Noble Ape mailing lists, please feel welcome to add your experiences to this page through the email address provided.
Earlier this month I found myself in Santa Monica. After many years of correspondence and more than a year of collaborative work, I met Bruce Damer. The background to our meeting was laid out in last month's mailout with the discussion of a DLL implementation of Noble Ape for Dave Kerr's AIR development.
Bruce's project, Digital Space had a similar requirement. I'm not sure of the background time frame relating to Digital Space, but the take-away information is that Bruce (and his team) use Digital Space in their consulting for NASA. All their demonstration work relates to lunar surfaces and similar extra-terrestrial physics environments.
Whilst the word ''DLL'' has some programming weight, I can't resist a good project name. Although AIR offered some good combinations, Moon Monkeys is the name that has stuck. I pulled together an explanation document on the components that were available.
In Pedro and my discussion, I summarised these components to;
Slightly more evolved than the original document but briefer too.
Interestingly enough, I passed the problem of selection and communication between these modules to Pedro and he derived exactly the same model I created through the Stockholm Rewrite period.
Sadly whilst being computer science gold, the complex communications interface isn't applicable to either the AIR or the DigitalSpace application due to the lack of free processor power. We should assume less than 20% of the processor being used for Noble Ape related simulation. This begs the question what parts of the Noble Ape Simulation could run under 20%. The brain component fails this basic requirement. The weather component will reach around 10% which almost removes it from giving benefit to either AIR or DigitalSpace (not to mention the lack of weather on the moon).
For my thinking, that leaves ApeScript and biology. The current biology of the Simulation is relatively hard coded and it is a set of ideas that could easily be written in ApeScript. AIR and DigitalSpace have their own land formats although the Noble Ape landscape gives size and diversity options. ApeScript replaces the being code, potentially the biology code, and has the benefit of quick changes to suit the specific environments. So the shortlist becomes;
The Noble Toolkit is an interesting option because it provides the line of sight code, the randomisation code but most importantly the file handling code. This could be beneficial to both AIR and DigitalSpace, however it requires education as much as investigation.
There is one final point on the Moon Monkeys development. Both Digital Space and AIR have industry standard, full screen polygonal graphics. From the last mailout this begs the question, what happens to True3D during the Moon Monkeys development. My estimation is that the Noble Ape side of the Moon Monkeys development shouldn't take more than three months and at the same time the interface development relating to Moon Monkeys directly improves the True3D development.
NOBLE APE 0.679 / DLL
Moving the Noble Ape Simulation to the Moon Monkeys development will take a few version releases. This development direction started with the release of 0.679.
This release also contained an HTML ''what's new'' file that incorporated links to all the new development documentation on the Noble Ape site. This set of links worked particularly well. Users, rather than going to the main Simulation page explored the new sections of the site and new documentation including the Moon Monkey information. This model of getting users direct and updated project information in links with the Simulation release makes a lot of sense.
As a mailout reader, you get this information once a month. The average number of Simulation releases is two per month. This provides update information in a direct means to a number of folk who are either new users or users who don't get the mailout.
A footnote from this last release for the mailout. There seems to be a decreasing user base of Noble Ape over recent releases. My thinking on this goes in two directions. First, the release time is critical - both the day of the release and the time of day. The best time to release the Simulation is around 2pm GMT early in the week. This is an empirical fact found over many releases. This, unfortunately comes in at 6am PST. Not ideal. The other issue is the number of substantial, user viewable features has dropped in recent versions for bug fixes and ApeScript additions. Not something most users are receptive towards.
Hope all is well with you all,
Tom Barbalet, 28 February 2006.