Archive for February, 2006

Quick review for the unaware. Quantum Star SE is a browser based space strategy game written in PHP I’ve been working on in jumps and starts for a while. Back in September I got around to revisiting the project and started rebuilding it from the base up using a reusable framework I helper create called Partholan. QS is a fork from the much older Solar Empire project. I forked since maintaining Solar Empire and getting anything done was nearly impossible due to poor design, the absence of security, and a reliance on spaghetti procedural style code.

Having released QS Evolved 0.18 and picking up several minor bugs… Nothing major reported as yet except for a failed schema install I can’t replicate. Hopefully someone can find out how to replicate it and debug it. One other minor bug was a missing directory, and a template path mishap causing the installer to load the wrong header html hence the wrong CSS file (still scratching my head over that one).

Since the release I’ve updated the database for the game and module tables and regenerated all the TransferObjects. This brings the basic nuts and bolts of the Data Access layer back up to date. I’ve since completed character creation, fixed a minor DAO bug which failed to correctly report failed SQL queries, and redrafted the Universe Generator class.

With these basic in place I should have Star System game pages available and loading along with the normal run of the mill navigation system for Fleets finished. Not sure where I’ll move after this (it’s maybe two days away). I’m thinking to add at the very least Homeworlds (specialised Planet instances) with a Shipyard and several ships available for purchase. That’ll round off Character Creation, Star Systems, Navigation and Ship Purchasing for a nice base test release (got to keep the testing coming in consistently).

From there its only a matter of a few hours slogging to have Resources and Mining ready. Ports I’ll peek at but I want to have some time to think over how Ports will work. At a minimum Port should act as trading depots for Resources and Components. The key here is Trading – I may skip this one for the moment and return to it but Trading is a definite addition. The lack of massive Resource counts and prices make Trading a more viable (and less expontntially dangerous) feature in QS Evolved.

A few ideas have popped up on the forums in other areas. Hades has made an intriguing suggestion of allowing destroyed ships spawn Components as salvageable remains. Never considered this, but the separation of content from the game engine in QSE makes this quite an easy behaviour – all Ships even keep a serialised array of all installed Component IDs for easy reference. Its great to see the game’s flexibility making such out of the blue suggestions possible with little effort.

Still there’s a lot of game elements I need to code for before worrying about content all the shop, trading, combat and facility features need to be coded into the game engine along with the more detailed Ship and Planet Models. Hopefully as all this progress builds up I’ll see more developers chip in to add bits and pieces. It’s certainly easy enough to do basics…

Today marks another Quantum Star SE milestone. Back in September the quest started to rewrite QS in earnest in what we called the “Evolved” branch. Today I have released a limited version of Quantum Star SE Evolved 0.18 which is primarily aimed at exercising the backend library (Partholan) and catch any final bugs that need fixing.

The download: http://www.quantum-star.com/devsite/Quantum_Star_SE_Evolved-0.18prealpha.tar.gz

So what makes QSE so different from the normal Solar Empire derived flavour of QS2 and QS Generations? A lot. QSE leapfrogs 6 years of PHP usage, debate and best practice. Where SE still lingered in the 90′s when PHP3 was predominant and security practice non-existent, QS Evolved was written for the new age of PHP. It relies heavily on design patterns, code generation, variable filtering and escaping, object oriented programming, and the key objectives of security, maintainability and reuse.

Its not perfect. I never had an intention of building an all-consuming framework. But as a loosely combined collection of classes it excels for my purpose – creating PHP games easily modified by users. So where complexity might have made things easier to maintain, I opted for simplicity in some cases. Where a design pattern may have injected an unintuitive connection, I opted for a roundabout yet clearer method. The code is readable, commented, tested, PHP4 compatibable, easy to work with and avoids any form of messy spaghetti solutions Solar Empire is famous for.

It’s one of the most complete approaches ever seen in a PHP game. And its completely re-usable. Want another game? Then take a shortcut, grab Partholan 0.18, change a few constants, and off you go. The basics you get for free – no time investment of a few months required.

This is not a complex application to figure out. Knowing what MVC stands for is 80% of the battle, the rest is experience and a little experimentation. The main barrier is the OOP approach. Most novice PHP developers are procedural fans, but the jump to OOP is worth making.

The good points get better. Where QS and SE generally are difficult to install and work with, this new version offers as its test case the new Installer. This is so simple a complete newbie can install the game in a few minutes. It just requires a little general server know-how for changing 2 directory permissions, and knowing your database details. No path settings, no url setting, no niggly little variables about file writing or other options. It’s simple, intuitive, effective and fast. It works.

The installer saw a lot of attention. Many will see that as something of a waste of time but QSE was never going to follow the Solar Empire tradition. QS has always had a strong user focus. Despite its numerous flaws, a year-old version of a buggy QS2 beta still draws a loyal following. QSE will draw a lot more when its playable. If anything the Installer is key to gaining a following. It is the single most important application that determines how an application is perceived by the public. Make it simple and they will see quality and care, make it difficult and they will see the opposite. It’s worth the time spent designing and simplifying it.

Now the bad points.

There are problems with my approach. Every “action” requires the use of 3 classes: Command, InputFilter and View. You need all three to be created and edited for every action in the game/installer. The reasoning is to facilitate flexibility. So thinking an action needs one class is not possible in QSE. The code is also slower than an equivalent app written without OOP (i.e. procedural code – like QS2). This is a price paid for the superior maintenance and stability of an OOP based framework.

There is also a level of inflexible structure in the source. For example the code cannot handle UNIONS, JOINS or other database queries that generally save the app from running unnecessary queries and slowing execution. Another price paid for the simplicity and standardisation of Data Access via a fixed, predictable API.

There are other problems and blemishes, but none at this stage are considered show stopper criticals, barely any are even rated minor. What’s important is that this release complete testing, we fix the bugs, we announce it stable and we get this game up and running!