It’s hard to believe we are already almost 1/12 of the distance into 2008. By now all of you have broken your new year resolutions. I know I’ve broken several at a minimum!

After some months of desperate oft-despairing struggling with work schedules I’ve finally once and for all conquered my lack of free time. It’s an ingenious solution – I’m taking a small break from work before rekindling an interest in financial services in these doubtful times (ask Société Générale if you want to know how doubtful, or the US Federal Rserve).

The outcome of this reorganisation of my career direction is twofold. Firstly I get extra bags of cash. Secondly, I get slightly more vacation time. Thirdly, it won’t require as much overtime. Fourthly, there’s less chance of last-minute-scrambling which became exceptionally evident over the last few months as the Irish market continues to swell (in defiance of the laws of EU Economics). Of course added together this provides more of my most sought after commodity – personal time.

All that’s left is how to use this new-found wealth. In between the extra pub-crawling exercises, engagements as the designated baggage mule on shopping excursions, and the other things an average 20-something is inclined to do, I want to enjoy some travel, take up writing again, and commit some completion time to the open source projects I contribute to.

I’ve been a very bad boy in that regard in the last six months and at one point I became an absolute nightmare for anyone who needed to contact me by email. It was not my finest hour, and I seriously doubt I escaped with a pristine reputation for being dependable. C’est la vie. A few of these “instances” shall we call them, have since been resolved to my satisfaction so I’m 95% back to nominal form as a powerhouse of innovation, inspiration and ingenuity (see, even my ego is back rockin’ at full throttle!). Yep, you can always measure the normality of an Irishman by his level of self-directed sarcasm .

Anyways, enough self-critical analysis – it weakens the ego – since I’m back in fine form after two extremes (a two month vacation, and a four month chaotic period of non-stop work) I have the luxury of directing some of this time where it was always supposed to be: in supplementing my PHP experience with some open source doodling and manic self-promotion . The first target of my ire is a small project with Till Klampaeckel (Seek. Kill. Destroy.). After that is PHPSpec 0.3.0 (Exterminate! Exterminate! Exterminate!). After that is that frickin’ promise-but-never-effing-do component for implementing a Yadis service (Off With His Head! Off With His Head!). I swear that thing has been sitting in a personal subversion repo begging for a few final hours of attention!

After that I’m taking a long breather, attending oodles of conferences, and finding something with a lot of words to write.

For the cool folk who have followed the Solar Empire legacy through thick and thin since 1999, those cute .php3 file suffixes, Moriarty’s continuing denegration of all other developers, the revolution that open source brought, the sudden push towards OOP, and the…err…security and bug population… Working on anything hitting it’s 9th anniversary in PHP is really interesting – 9 times the fun and games .

Astrum Futura was envisaged as a desperately needed update to the long running open source Solar Empire franchise, where players engage each other across a galaxy of 500+ star systems mining resources, building colonies, and generally screaming bloody murder at each other. It’s not the most impressive or ambitious of online games, but it’s always been tenacious and attracted roaming users who like a quick dash of destruction in their daily diet.

In January 2008, the oft delayed development process will once again creak into action. The current tracer code was built originally using the Zend Framework 0.2-0.6 and famously led that Spring to my long running “Complex Views With The Zend Framework” blog series that gave birth to the Zend_View Enhanced proposal, and maybe gave Ralph Schindler a few headaches . Building anything more complex than a login page was pure heart ache previously.

Now that time is available, the Zend Framework significantly more mature, and we have a lot of legwork carried over from 2006 in the Quantum Game Library (thanks to Jacob Santos), it’s about time we got something concrete done. The usual suspects, if interest levels are high enough, can report to the shiny updated phpBB3 forums at http://forums.astrumfutura.com – same domain as this blog you’re reading.

And we will be applying XP this time – the random running process that usually prevails just doesn’t work out well. So get your Selenium gear in place.

It’s been a while since I continued this series. Unfortunately real life workloads are unforgiving of the best of intentions . Part 5 of our series takes a small time-out from approaching a Composite View solution to reusable Views to take a peek at a simpler approach useful for simpler types of web applications. As we’ve discussed previously Composite Views allow the nesting of reusable View elements, effectively building a View based on a hierarchy of Views. But often there are simpler solutions to simpler problems. One such solution is the Two-Step View pattern, sometimes called Layouts if implemented in a specific way (as we do below!).

Imagine a simple website. You have hundreds of pages of unique content, but the header and footer for each page is identical. Applying the Composite View approach has the same problem as applying a standard PHP include or Zend_View::render() call to including these common elements – the calls themselves are scattered across each and every template. This is the hallmark of a Layout – duplicated includes/renders across multiple views:

[geshi lang=php]render(‘standard_header.phtml’); ?>

Here is our unique content! But look, all unique templates
now have the same “standard” headers and footers defined by a
render() call. How do we remove these completely and apply them
automatically instead?

render(‘standard_footer.phtml’); ?>[/geshi]
The key is to take the duplicated calls and other duplicated markup and stick them in a Layout template which will encapsulate all Views automatically. Then the only thing our templates contain is unique content!

[geshi lang=php]

Here is our unique content template! But where have the
standard header and footer includes vanished to?

[/geshi]
All the Layout file needs to do is provide a “hook”, a method placement which signifies where the main View output (which is generated by the current dispatch cycle) should be placed. Since we define two parts the View here we’ll refer to them as the “Layout” and the “Main”. A Layout might look like:

[geshi lang=php]render(‘standard_header.phtml’); ?>

main(); ?>

render(‘standard_footer.phtml’); ?>[/geshi]
The new Zps_View::main() method (Zps_View is a subclass of Zend_View to which we can add customised behaviour) simply tells the View to render its output at this location in the template. This assumes the default Zend_View::render() method now takes a two step approach to rendering (this is where the Two-Step View Pattern comes into play).

1. Render a Layout if one is defined
2. Render the Main template into the Layout

The only funky logic is that the presence of a Layout forces our View object’s render method to take a detour so that Layouts are rendered first. This is a pretty simple change to Zend_View. Here’s our Zps_View class with the revised logic.

Please forgive the lack of proper phpDoc comments – Serendipity won’t play nice with them.

[geshi lang=php]// Zend_View */
require_once ‘Zend/View.php’;

// Zps_View_Interface */
require_once ‘Zps/View/Interface.php’;

class Zps_View extends Zend_View implements Zps_View_Interface
{

//
// The Main Template (i.e. the template file a Controller wishes
// to render).
// _mainFile cannot be set by a public setter so it doubles as
// as a safety valve to prevent unwarranted use of main().
//
// @var string
//
protected $_mainFile = null;

//
// The Layout Template
//
// @var string
//
protected $_layoutFile = null;

//
// Overrides Zend_View::render() to introduce a two step view approach when
// a Layout template has been defined. The two steps are handled using
// separate calls to parent::render() which calls the Zend_View render()
// method without overriding.
//
// @param string $name The script script name to process.
// @return string The script output.
//
public function render($name)
{
if ($this->hasLayout() && !isset($this->_mainFile)) {
$this->_mainFile = $name;
return parent::render( $this->getLayout() );
}
return parent::render($name);
}

//
// Set the filename of a Layout template to be used. The existence of a
// Layout filename will force the over-ridden render() method to detour
// and render the Layout, only rendering the Main template when a main()
// call is issued in the Layout template.
//
// @param $file string
// @return void
//
public function setLayout($file = ‘layout.phtml’)
{
$this->_layoutFile = $file;
}

//
// Return the filename of the Layout. Layouts are like any
// other template script and are located in the same place in
// application filesystem.
//
// @return string
//
public function getLayout()
{
return $this->_layoutFile;
}

//
// Returns true if a Layout has been set for this View.
//
// @return bool
///
public function hasLayout()
{
return isset($this->_layoutFile);
}

//
// Inform the View object that it should render the Main View, i.e.
// render the template handed to the render() method by a Controller.
// This method is only useful if a Layout is being used, otherwise
// expect an Exception.
//
// @return string
// @throws Zps_View_Exception
//
public function main()
{
if (isset($this->_mainFile)) {
return parent::render($this->_mainFile);
}
require_once ‘Zps/View/Exception.php’;
throw new Zps_View_Exception(‘Invalid call: There is no primary View template to render’);
}

//
// Method to clone this View assuming the sub-View (the clone) is from
// the same application Module as the original.
// Here we are simply getting rid of the inherited public variables which
// represent the ancestor View’s model.
// We also disable any Layouts (the inheritance would lead to infinite
// looping otherwise – Apache would bark and die on the spot!)
//
// @return null
//
public function __clone()
{
foreach(get_object_vars($this) as $key=>$value) {
$this->__unset($key);
}
$this->setLayout(null);
}

}[/geshi]
So there we go, functional code for allowing Layouts in a Two-Step View approach. Notice how the render() and main() methods interact. Because it’s both have very specific uses, main() is only useable within templates when injecting the main template into a Layout.

Sample usage is pretty simple – I won’t delve into any details since you just need two additional pieces of work when instantiating a View object:

1. Create a Layout template (you’ll notice a setLayout() default is “layout.phtml” but you’re not bound to that convention by any means.
2. Set the Layout on a View object, e.g.

[geshi lang=php]$view = new Zps_View;
$view->setBasePath(‘/path/to/default/view/directory’);
$view->setLayout(‘layout.phtml’); // this will force render() to perform a Two-Step
$view->render(‘sometemplate.phtml’);[/geshi]
If you followed my previous posts you’ll be able to integrate the Two-Step View/Layout approach pretty easily into your Views. Of course, as usual, a key observation is that in using a Zend_View subclass be sure not to rely on Zend_Controller_Action::initView(). You’ll need to override that method in your own application specific Zend_Controller_Action subclass.

If the lack of a Zps_View_Interface worries you it’s just a declaration of all the public methods above. I won’t post it here, this entry is long enough .

Any final words? A similar system is also possible using an alternate implementation. Matthew Weier O’Phinney, when I originally started asking about complex views in the Zend Framework, posted a Two-Step View implementation using a dispatchLoopShutdown() plugin. You can read more about this over at the mailing list archives – here’s the exact link to Matthew’s email.

http://framework.zend.com/wiki/display/ZFMLGEN/mail/27145

Finally, this is completely compatible with using a Composite View system. You can imagine creating a component full of widgets or plugin output. Each of these would be aggregated into a Composite View. But that doesn’t mean they don’t all share one thing – a common layout. So Layouts (Two-Step View) and Composite Views play quite nicely together.

Have fun! If anyone comes up more bright ideas throw them into a comment for the hordes of blog readers to consume!

Congratulations to Mark Dickenson (aka Panama Jack) and Rick Thomson (aka Tarnus) on their recent release of Alien Assault Traders 0.30. It’s been in development for a while now and it’s cool to see the end product finally let loose .

Alien Assault Traders is an online browser-based space strategy trading game written in PHP. It’s a fork of Blacknova Traders. If you’re looking for a free open source web game then here’s one to take a peek at. PJ is well known for focusing more than the usual effort on optimisation (he wrote the ADOdb Lite and Template Lite libraries) so it’s a bit easier on your hardware than many alternatives.

I haven’t been tracking development as much as I used to (busy with Astrum Futura, QGL and my Zend Framework proposals) but the new version has a significant overhaul of the previous 0.2x code. Have fun!

http://www.php-mag.net/magphpde/magphpde_news/psecom,id,26905,nodeid,5.html

The International PHP Magazine has started a new poll asking readers to votes for their favourite PHP game. Judging by the list it looks like the top 10 Sourceforge registered open source games. I listed these a while back and noted phpDiplomacy in particular was doing really well. Somehow though I doubt the voting will be brisk. Should I tell them the QGL is not actually a game but a PHP game-oriented library? .

Back in 2005, the Quantum Star SE project caught the Object Relational Mapping (ORM) bug and I took a first stab at implementing something that was simple, fast and easy to use. Until this stage I was a regular user of the Data Mapper pattern (among others) but since switching to PHP and developing open source projects found it to be largely unnecessary. The root problem is akin to hammering nails with a sledgehammer – too much complexity being implemented for a simple underwhelming task.

Here in 2007, with the QGL in development I found myself re-assessing my previous experiences and finding it attractive to develop something less complex and hopefully faster than a full scale ORM solution. Taking some previous work I did, I opened a branch in the QGL subversion repository and set to work. The results are slowly coming to fruition – the DAO, Row and part of the Driver families are shaping up going by the unit tests.

So what is Quantum_Db (in practice)? It will be a family of classes which form a Data Access Object (DAO) Framework when complete. This post is largely a ramble about current progress and intentions – so if looking for a complete solution you’re in the wrong place as the current code is strictly in-progress. For reference though, the source code is under the New BSD License. It’s incomplete, but available from its subversion branch at: http://quantumstar.svn.sourceforge.net/viewvc/quantumstar/branches/Quantum_Db/ and the forums can be found for the QGL in general at http://forums.astrumfutura.com/viewforum.php?f=25.

In this specific implementation of Quantum_Db, the DAO class (Quantum_Db_Access) is a Singleton which attempts to offer relatively basic CRUD methods capable of use on any valid database table record. A large part of its responsibility is generating CRUD type SQL. So you could have a User record, which could be saved by passing it to a DAO save() method. It’s not quite as clear cut, since to reduce the mass of code a DAO implementation often needs the “record” is encapsulated in a container called Quantum_Db_Row. This Row class can represent a single table record, but also doubles as a data container for setting up SQL conditions (think of WHERE, IN and INSERT clauses).

One of the goals intentionally targets simplicity, so there is no Propel-style Criteria object to mess about with. There will be in the future, but for simple needs, a simple DAO framework is sufficient as an initial start. A simplistic use case is adding a new User record. Some code showing this task:

[geshi lang=php]require_once ‘Models/User.php’;

// Fields are public properties handled by __get/__set in the
// Quantum_Db_Row class. The User class is actually a simple
// subclass defining valid fields and primary key(s).
//
// We do not specify an Id value for new Users. The DAO class will
// assign this assuming Id is an auto-incrementing value for MySQL
// or a Sequence for PostgreSQL.

$user = new User;
$user->name = ‘Pádraic’;
$user->email = ‘padraic.brady@example.com’;
$user->password = sha1(‘password’);
$user->country = ‘ie’;

// Call on DAO to save this record to the database. Obviously any
// database errors will result in Exceptions thrown by the DAO so
// the database table rules (primary key, unique key, etc.) all apply.

$user->save();[/geshi]

The first thing you can note is that the DAO class (called Quantum_Db_Access is not directly called. Instead all Row objects carry a reference to the Quantum_Db_Access singleton so Quantum_Db_Row::save() proxies to Quantum_Db_Access::save() – we only need one generic DAO object. If one desperately needed the DAO they could just place a call to Quantum_Db_Access::getInstance().

[geshi lang=php]$dao = Quantum_Db_Access::getInstance();
$dao->save($user);[/geshi]

In fact, you can equally access the underlying database extension driver to run queries directly using the following. Of course Singletons have their own evil uses, so ideally you’d pass around the object reference instead of litering source code with static getInstance() calls which explicitly refer to the class name.

[geshi lang=php]// Example of accessing the driver to drop the User table

$driver = Quantum_Db_Access::getInstance->getDriver()->exec(“DROP TABLE user”);[/geshi]

Retrieving records is more interesting. It’s relatively simple to extract a record based on a primary key:

[geshi lang=php]$user = new User;
$user->getByPk(1);

var_dump($user->asArray()); // echo array of User (Id=1) data[/geshi]

It’s much more complex to fetch rows of a very specific nature. Even worse, without a Criteria object using the MySQL IN clause is a challenge. However for those where the SQL values depend solely on simple field values a neat solution is “named queries”. A Named Query (check the excellent introduction at: http://www.tonybibbs.com/article.php/PropelDAO regarding something similar for Propel) is an SQL string containing value placeholders (e.g. for use in a PDO::prepare()) stored in some central file. This has a few benefits and disadvantages.

The main benefit is the centralisaton – like OOP, centralising logic (in this case non-generated SQL strings) reduces duplication and encourages reuse. Allowing the named queries to be indexed (for example, within an XML hierarchy) by a name and model allows them to be easily located and prepared by the Data Access Object. The disadvantages are of course that it’s still limited. For example, use of a MySQL “SELECT id, name, email FROM user_table WHERE id IN(1,2,3,4)” isn’t likely a storeable named query since the IN() range of id values is too variable. But for many queries it’s a good fit in the absence of some form of Criteria class.

Enough of the DAO class however. After beating it to death, there are still pieces to be completed when it comes to allowing complex SQL clauses. The main point is that for simple use cases it is a good match – and simple use cases are extremely common in many of my open source endeavors.

To backup the Data Access Class Quantum_Db also implements a Driver and Results class family. Again simplicity is key, so it’s being written under the presumption that PHP5′s PDO extension is available. The Quantum_Db_Driver_Interface file actually mirrors the PDO interface for this reason. Of course we can’t forget mysqli (the most popular PHP5 database extension) or pgsql and the rest. Quantum_Db_Driver defines an interface to enable additional extension type support. Personally I only intend adding a light abstraction over ADOdb-Lite – it’s not worth duplicating Mark’s already existing library.

The Results class, the one part no code exists for yet – don’t be worried I develop using TDD and unit testing so it’s perfectly normal . Quantum_Db_Results will aggregate the results of queries into a class implementing PHP5′s SPL Iterator. To be specific, the Iterator methods will be tied to each underlying Driver’s fetch* methods. This should allow continued use of Lazy Loading during iterations, and allow continued use of foreach() etc.

Here ends my ramble for now. For those working on the QGL or similar code maybe it will provide a few of my thoughts on the topic – assuming you can summarise the rambling of course .

Iamsure appears to found a sense of the dramatic. So his new blog entry very successfully piques my interest!

Most of all, the end result should be a fun, entertaining, and groundbreaking game. Its massive, it will scale, it will be internet based, and it will be both similar and totally different from other games I’ve worked on and spoken about.

It’s going to be a commercial project I gather so no open source goodies to examine, but these days I’m often less interested in the code, then the approach to execution. I guess once you’ve been using PHP since 2000 you eventually find that your reading leans heavily to theory and the experiences of other developers facing a unique challenge (whether PHP, Ruby or other). I for one look forward to reading more!

The Quantum Game Library (“QGL”) is a PHP5 library aimed at creating a bunch of reuseable classes for use in PHP games. We’re still in early days but with two dedicated developers, lots of feedback and suggestions we’ve already put together a few starting solid components and have others in progress.

Over the last few months the QGL has evolved from a minor offshoot of the Astrum Futura project into a fully independent library. I guess everyone on the team saw a generic game library as something really useful; we’re all game developers on varying projects.

To reflect the library status, as well as to widen the net for potential users and developers we have decided to move from the GNU General Public License (which rules Astrum Futura) to the far more liberal New BSD License. We’ve also provisionally determined that copyrights should be centralised to a degree, this currently is not in operation since the number of contributors remains manageable but may be (pending contributor feedback obviously) in the future.

Given licensing is now decided, file header updates in progress (if gradual), and some useful components are hitting stable, it’s likely we’ll make a public preview release in the near future. Given out focus on doing things right, this will only occur once documentation is completed and our unit tests verified for good measure.

As a summary (feel free to request details on the QGL Forum Section) the current near-stable component list includes:
– Quantum_Db
– Quantum_Coordinate
– Ai_Pathfinding
– Quantum_Map_Measure
– Quantum_Map_Grid
– Quantum_Turing

This is far from complete, and there are literally dozens of possible additions. Those in planning are already shaping up to offer some cool second iteration functionality. That’s not even including the planned ext/qgl PHP extension…;).

A recent discussion was sparked on the Astrum Futura forums regarding player retention and new player protection. It was one of those times when the discussion branched to a higher view – a wider look at how players interact on a large scale.

The current suggestions called for players to be penalised for undesireable actions, e.g. attacking a new player who is incapable of defending him/her self. This remains a long standing issue in many online games. AF could resort to enforced levelling – limited who a player can attack, and be attacked by. But this is all artificial – in the real world it’s open season on anyone.

Cyberlot (Richard) raised the question of penalising through a Karma rating. As a player attacked newcomers they would attract negative Karma marking them out to other players. I can see the rank of “Newbie Basher” emerging as an undesireable outcome for many players. But Karma while adding some measure, does not address enforcement. Exactly who enforces what and when? Who set’s the standard for interacting with other players?

From there we hit the subject of Factions. A Faction would be a specific group of players sharing a common interest. This obviously includes Races, but is also extendable to a Merchant Guild or a Pirate Clan. The point is to give players an instant group they are a member of. Now where it gets interesting in how the player and game logic would respond in the presence of Factions.

Say you have a Faction, Earth Humans United (go Terrans!). What happens if a member of this Faction attacks a new player who is joining the Earth Humans United Faction? Can’t have allies killing each other off (even if it might reflect reality ). The answer is in the Karma. Killing a new member of your own faction is stupid, damaged the Faction, and makes other players less likely to join it. That member should sur be paying tax to the Faction, which is needed. Such a player would immediately get negative Karma.

So we have Karma, and we have Factions – how do they relate?

Karma is a measure of one’s standing within a Faction. If your Karma falls below a minimal level you’ll be declared an enemy of the Faction, and then its time to start running before you’re hunted down by your peers. Where do you flee? If you’re lucky, some other Faction still has you as Neutral.

But this is where Newbie Protection get’s interesting. It’s not Faction specific – your bad Karma is classified when killing a new player as a “Stigma”. It decreases Karma for *ALL* Factions. It’s the ultimate punishment – imagine playing when nearly all the Factions refuse to grant you trade access, when your planets are penalised with “special tax charges”, when other players are unable to maintain an Alliance with you once you become Factionless (Outcast). In short, if you gain a reputation for killing new players, you’ll be kicked, booted and sent to Hell with a one way express ticket. No Admin interference or funny AI fleets required. Society will put you straight or else…

More on this later as details are worked out, but it looks like it’s a feasible and supported suggestion.

Creeping closer to Spring; it’s 1 February if you follow my calendar. One of the things which stand out in my online activities as it touches on PHP is the 3 month period spent working on the QGL (Quantum Game Library). The library is just reaching its 200th commit, and should pass that barrier later this evening when I get around to a small class naming change.

Sticking with the QGL, it’s a small side project which sprung up from a vague idea. Those of us working on the related Astrum Futura game project, knew a standard game library of some description would pay dividends for future projects by centralising a general set of useful classes. It was shortly after this concept was solidifying when Jacob Santos joined the team with his imaginative vision of implementing AI algorithms.

The one thing that really stands out from the usual project hustle and flow, was our shared wish to use Test Driven Design and Unit Testing. It’s very difficult to use it on anything more than personal projects at work where developer resistance (though falling) is still an obstacle. So the QGL was an all too rare opportunity to cooperate in a team led effort focused around the test-first approach.

So how did we fare?

Personally, I think a lot of what we accomplished to date (bearing in mind the time limitations) was a result of TDD, and of course Unit Testing’s benefits in general. There were times where we were working on complementary components such as Jacob on Ai_Pathfinding, and myself on Quantum_Map_Measure where TDD led to simpler more maneageable classes. Of course the unit tests supported our efforts with style. Throughout the process we were both refactoring code, and tweaking interfaces. Without the unit tests we would have reached deep treacherous waters as our respective efforts slowly drifted apart.

I also think poor Jacob may have become test infected. He seems to be recovering, so I’ll have to wind him up later over the current two failing tests he introduced! I haven’t heard any rumours of a bald Jacob Santos so presumably that odd side symptom has yet to rear its ugly head.

Back on track… The most visible benefits of the TDD + UT approach during the last three months can be summarised as:

- Easier Refactoring (perform a refactor, check tests still pass, rinse and repeat)
- Immediate Feedback when code goes wrong (big fat red bars in the testing results. Hard to ignore!)
- Enforcement of Standards (tests discourage questionable hacks/shortcuts)
- Regression Testing (if something goes wrong, we add test(s) to prevent repeats)
- Force Feedback (not just a console controller type, failed unit tests spark attention from other developers)
- Code To An Interface (TDD and unit testing teach you why if you’re a quick study)
- Testable Code is Better Code (adherence to practices which generate clean, focused, flexible classes)

I’m sure there are others, but these were the most obvious over three months of development across 200 commits to subversion from two developers. If the immediate benefits are not a motivation to become test-infected the future benefits might. The one thing I know from past experience is that unit tested code tends to be easier to maintain and generates fewer bug reports.

Now of only someone miraculously removed the initial pain a developer experiences when starting to learn TDD and Unit Testing (the pain that explains why many quit before the summit of the learning curve is reached) we could get more folk on the TDD bandwagon. One unfortunate fallout from following a test-first approach is that it necessitates any new developers becoming educated. No easy task when dealing with a vast population of wannabe programmers taking their first few running jumps with PHP by showing interest in open source projects.