The first part of the title is a small dig at something we’re currently working on rectifying in the immediate future. Over the next day or two, the Astrum Futura forums will see a large expansion as the currently private planning forums are stripped of any clearly private material and made public. This should offer people in the future to post comments and suggestions based on past and current planning discussions.

A roundup of other stuff ;-).

Jan Gundlach, who has followed Quantum Star SE for a long time, has signed up as our German Translator, bringing the current team to four members. This will give the ability to poke and prod Jan’s mind on how to make AF more localisation friendly. We have been discussing on the AF International Forums, how to add regional support for languages, dates and numbers, and more deliberate input validation. The point made here shows regex can be difficult since it’s not obvious which PHP installations would have Unicode support compiled in.

Jacob Santos, has just committed some basic structure for the future Quantum Game Library (QGL) AI component. The immediately useful part of this will be the pathfinding algorithms. I gather I need to get some work finished on Hex map maths (coordinate position and distance calculations mainly) so a Heuristic can be measured. For those not in the know, a Heuristic is the cost of following a specific path in an attempt to reach a specific target. The simplest Heuristic is distance. The less distance to the target we’re attempting to find a path to, the less costly the currently selected path is, and the more weighting that path gains in the algorithm.

Hades meanwhile has posted an internal proposal titled "Player Retention". The subtitle is more descriptive… It’s a proposal to implement what we’re calling Player Banding. In very brief terms, a player who attempts to attack another player will face a Band penalty. If the defending players score (I’m summarising here, the score is not a simple points addup) is 25% of the attackers, than the attacker is penalised. The banding currently proposed reduces the penal cost as the band difference narrows. Attacking a 75% player would have no cost. The aim of the system is to prevent the problem of "Newbie Bashing", the practice where large powerful players continually show a preference for attacking smaller players who recently joined the game.

As for myself, I usually get stuck with some grunt work ;-). I did some developing over the weekend mainly to get Sessions shared properly between the Controller and View layers. Although passing Sessions from Controller to View is easy, it’s also highly repetitive, so a Zend_View subclass using Zend_Registry was added. Sessions are currently abstracted by the Zend_Session class. I have a few issues here since a lot of functionality is handled by Zend_Session_Core, which is mainly a list of static methods. I’ll need to subclass Zend_Session to avoid spreading Zend_Session_Core references too much which would make it difficult to replace the class use if required.

The early weekend also saw the svn commit of a Phing build process file. It’s a simple version that copies the current code to a source directory and creates gzip and zip archives to be distributed. Santos suggested we add a daily svn build for download, so this should do the trick nicely requiring only a simple shell script to navigate to a build directory, issue a "phing dist" command, and copy the distributables to the daily location.

Lastly, I’d like to note Ron Harwood (Blacknova Traders), myself and Santos had a discussion in the comments section of this blog. Ron raised the suggestion of using XUL to create an interface to the game. It’s an interesting idea I might persue in the future. The game as it stands in planning, is aimed at focusing on serving a data format like JSON or XML rather than HTML, making it easy to replace the frontend interface without any major consequences. Ideally the game only serves HTML for the initial template for any given section, making use of future requests to serve only data which the client uses to update the page using the Javascript DOM.