Archive for November, 2006

As those watching the SVN repository are aware, there have been a few changes going on outside the actual AF code. I’m going to run through these quickly.

For those not familiar with the repository layout, the distributable Astrum Futura source code is located (from the svn root) at /trunk/astrumfutura. Back to the topic at hand…

First of all, I’ve added a /documentation subdirectory in trunk. Documentation has always been a problem in QS and earlier in SE. For AF we’re considering a policy of making each developer who makes a change responsible for updating the documentation. How we enforce that is another matter I’ll discuss with my fellow developers.

Documentation is being written in the Docbook XML format and will be versioned in the mentioned documentation directory. To allow future scope for translation efforts, the actual files relevant for the default documentation are stored in /manual/en. The en directory contains a manual.xml file which is basically what determines the layout and contents. Individual pages are stored as separate XML documents in manual/en/module_specs. Common page components and miscellaneous appendixes are stored in manual/en/ref. The remaining directories and files allow the Docbook XML to be processed using xsltproc under linux (or Cygwin on Windows) to generate HTML. Options are open for using Apache fop to generate PDF (not really a concern right now). Directions for generating HTML are included in a README file in the /en subdirectory.

Secondly I have added a /standards subdirectory in trunk. The idea is to determine a final coding standard (see PEAR’s PHP_CodeSniffer) and ensure its adhered to. Might seem like a pretty worthless thing to be doing right now but once the code grows to a point where global file formatting changes are time consuming it will prove its worth. The standard being adopted is adapted largely from the PEAR standard. The main difference is that we’ve adopted a different bracing style (opening brace on new line) and modified a few rules to be either more PHP5 specific, or simply to match the preferred styles of the current developers.

Also added, but not yet utilised for AF specific code is /tests. Since most of the classes we use are already sourced from unit tested libraries like the Zend Framework, Swiftmailer and Quantum Star (that independent game library being segregated to a separate project) this will mainly hold web tests. AF will operate strictly on a REST basis, so all requests are in some way reproducible.

Next to be added (later today) is the /build directory. The core idea here is to automate building a distributable as much as possible. Distributing is often seen as a matter of export/copy/zip. In AF it’s a bit more complicated – we need to run all available tests (including all tests for libraries we are sourcing from non-stable sources like SVN trunk) including web tests, build and copy the documentation to its correct location, check the coding standard is clear of errors (ignore warnings), copy all files to a build directory in the correct locations, and finally create distributable archives for zip, gz and bz2. The distributable code must also be tagged in subversion.

I haven’t decided on a final build process and am currently trying out a few tools. The one I’ll be testing later is Phing (since it’s relatively famliar to an Apache ant user).

Did I miss anything?

Iamsure has returned to the blogosphere over on http://kabal-invasion.blogspot.com.

For those not familiar with his open source developments, he’s a developer on the PHP Blacknova Traders game project, and is currently planning a PHP library focused to an extent on games, called JOMPT. To add to infamy, Iamsure suggested a name for my current game project which eventually won the tie-breaker after a public vote – hence we have "Astrum Futura" .

In the opening post of his new blog, he makes some general observations. He mentions Astrum Futura, and gives a quick opinion on the opening shot in this project. One note is that he’d like to see the "ability to drop-in/override certain backends with alternatives". Presumably this is directed towards the interface between the current Controllers and the ZF which is pretty tight at the moment. As an observation, I’ll quickly note the ZF defines a series of Interfaces which make adding alternative backend libraries relatively simple (just need a specific Facade/Adapter for each alternative library). Largely explains why I’m using Zend_View for now instead of Template Lite which I would prefer, among other things.

A second observation is made that a few of the open source PHP games he follows (as do I) have slowed down. I suppose that’s an inevitable facet of open source development in general – only the larger popular projects manage to maintain momentum in the absence of the main developers driving progress with their big picture objective setting and the help of cat-o’-nine tails… Legend of the Green Dragon lost a few of its primary developers some time ago, so until the takeover developers pick up momentum and/or get a grip on where the game is going and get an action plan together we’ll likely see the current progress inch along.

Final mention goes to JOMPT, the proposed PHP library Iamsure has had on the back burner for a while now (I remember it being mentioned way back when). As noted Astrum Futura does sort of hit similar objectives, though our reliance on the Zend Framework has restricted out own goals to a more specific set of functionality – primarily reuseable classes that are independent, unit tested, and target specific game elements like Mapping and AI (plus more as the AF project moves along).