NOBLE APE MAILOUT - MAY 2005
GALAXY OF MONKEYS
GALAXY OF MONKEYS
I'd like to start the mailout with some long-term projections of the development. Through BiotaAtHome and Noble Warfare, the returning issue of the Noble Ape Simulation is abstraction and modularisation. There is no reason the individual graphics windows can't be applied to multiple apes - the brain and terrain windows at least.
Every aspect of the Simulation needs to be modular and abstract-able. There are visible components, like the graphics windows, editable components like the file/script handling and stuff you never see like thread balancing, memory management and shared codebase with Noble Warfare. In the next year I want to abstract the Noble Ape Simulation even more.
Looking at the slew of 'documentary history' surrounding the final Star Wars release, I noticed footage of the original vector graphics Star Wars game. In many regards, this was the American view on the BBC Micro's Elite. There was a time when galaxy flying based games, at least graphically, were the standard. A rich galaxy simulation is certainly inspiring with an abstracted Noble Ape Simulation.
To-date, the Planet Noble Ape development has not been properly integrated with the Noble Ape Simulation. I would like to take the Planet Noble Ape code-base in a modular form and place components of Planet Noble Ape together with the Noble Ape Simulation. Putting a string of planets and a star or two together is a long term goal of the code modularisation.
About a day after the last mailout, I finalised the documentation for ApeScript and put the information online.
The explanation of the interface between ApeScript and the Simulation is only explained through a brief variable overview and example code. This needs to be expanded in time. That said, it should be possible working through the example code to get a sense of what the scripting is used for and how to develop your own ApeScript code for running with the Simulation.
As promised through previous mailouts, there are a number of lingering implementation bugs I'm slowly going through. I'm debating putting the remaining bugs online and providing a progressive update change-log to sync with the documentation too. So users will be able to track their code vs the related changes.
As a developer for nearly two decades, the worst aspect of developing with an early compiler is the suite of round-about fixes one writes to get over the compiler's particular issues only to have the compiler fixed through progressive versions without any explicit information on the fixes. I want to learn from my own experiences here and make sure the same problem isn't encountered with ApeScript users.
DEVELOPER MAILING LIST
Part of providing the most robust initial release of ApeScript through the beta testers is having an active developer base. For this reason, as you all read during the month, I restarted the Noble Ape Developer Mailing List [na-dev].
The old developer mailing list was a progressive dialogue between me, new users and Mridul P. It provided an interesting dynamic and allowed for the Windows Ocelot version of the Simulation together with the Linux GPI which produced the Linux version of the Simulation.
The use of scripting is a little different and for this reason I'm hoping a growing subscription to the developer list from non-source code developers looking to develop new ApeScript instances of the Noble Ape.
With the added documentation, putting a software version of the scripted Simulation became a priority. The history of the scripting code was that it was primarily developed in a command line form on my Windows laptop. The command line version was then ported to the Mac, integrated into the Simulation, then reported back to Windows so both the Mac and Windows scripting betas could be released together. The best laid plans...
For Mac users, the Noble Ape Simulation ApeScript beta;
The Simulation handles all file loading code through the same functions. There appears to be a lingering bug in the Windows code which I am still tracking down. I'm hopeful a linked beta Windows should be online in the near future.
BUILDING A COMMUNITY
Working with a project like Biota(AtHome), it encourages a zoom-out from the Noble Ape development to the broader ALife project.
Historically, ALife has been defined by popular culture books - calls to code. In addition to this, the release of occasional games in the commercial domain has encouraged a popular following of these products. But this has rarely translated to publicity for and interest in open source/free ALife projects.
The problem, which translates to most open source development, is that open source/free ALife exists as a series of remotely developed projects which effectively Venn on a number of issues. Finding these ALife projects and encouraging the active hobbyist development of ALife should be enhanced with a greater sense of community. Through the earlier part of this year a microcosm of these issues was discussed through the precursor to BiotaAtHome. ALife developers are using a variety of languages and a variety of methodologies (graphics, ALife methods et al) to develop their respective projects.
My view is that the differences are always less than the collective same in ALife development. Creating a community is challenging. For every one active ALife developer there are probably somewhere between 10 and 100 active ALife users and about 1,000-10,000 passive ALife users. Looking at these numbers, building an ALife community is about getting these folks involved too.
Hope all is well with you all,
Tom Barbalet, 26 May 2005.