PHP, Zend Framework and Other Crazy Stuff
Archive for September, 2005
Quantum Star SE 3.1.0
Sep 13th
I can just see the funny looks at the minor increment – actually 3.1.0 is not due for release any time soon. This is a short thought summary on its goals – namely to extend Gameplay.
QS and its parent, SE, are fairly simple strategic games. Recent years have thrown development off course, or in many regards simply stopped any form of forward evolution. This was a shame in many ways – since the original debut of Solar Empire, PHP games have continued to gain in complexity, popularity, and the fun-factor. Unfortunately SE’s early development issues (i.e. the Light/Dark faction in-fighting) and often it’s lack of any revolutionary development, has left SE way behind of the pack.
Now the last two years has seen a lot of improvement. There a few good developers working on the original SE project and Solar Empire 2. Djcapelis has a none too often mentioned project referred to in his blog as WAR. Even Quantum Star SE is finally hitting its stride with the newly committed (to CVS) v3-0.10. But this is all just a first baby step. QS 3.0.0 is being targeted at duplicating QS2 – not advancing any major gameplay changes. We do have such changes planned – but my lack of development time in the last year has left QS3 with 8 weeks development to date. Still, I’ve done a lot in those 8 weeks as the CVS commit shows.
So what is 3.1.0 all about?
The next version update (after we release 3.0.0) will move towards far more complex and involving gameplay. Although QS will remain set in an SE like scenario – it will have significant gameplay changes. The basis for these changes are what I call Game Assumptions (I’m sure there’s a more technical term – but this works). SE has really simple (and often illogical) Game Assumptions. For example, the implementation of Planets in Solar Empire makes an inherent assumption that a Planet can prevent a Player from viewing a Star System. If that’s not illogical, I don’t know what is…
So we’re talking assumptions. Here’s an example of one planned change. In SE we assume that travel must be done only between Warp Points. Of which there is one Warp Point per system. Now this inevitably raises numerous issues. Worse it immediately places a constraint on our source code – which leads to an exponential increase in processing requirements in some functions. A revised assumption might do away with the idea (or at least the sole travel method) of Warp Points – and instead assume travel through any portion of space, in any direction, is equally valid. Following this we start get getting some pretty complex ideas – if a player can travel literally anywhere in a 3D volume of space (yes, 3D), how are opposing players going to find the buggers? After all a 100×100 pixel map would have an area of (gasp!) 10,000 pixels (one pixel per coordinate). Worse, with 3D, that same map would have a volume of 1,000,000,000 pixel points. Talk about big….
That’s what QS 3.1.0 is all about. We take any SE assumption, turn it on its head, find a new potential direction to evolve, and try it out. Why not have 1 Billion points? Without warp links getting in the way you get a lot of freedom. It opens a more elaborate, yet code simple, game arena.
It for things like this that QS3 was designed. To assure some people – such a move does not necessitate the removal of the old system . With QS3, both can co-exist as discrete code (typically a set of related CommandObjects – and a few minor database tweaks) because QS3 works separates all layers of the application to such an extent, that features are virtually interchangeable. For example lets say I create a new Planet Model. I could combine the 3D-Universe Model, and the Planet Model into one game, the 2D-Universe Model and SE Planets in another. There’s nothing stopping such a approach in QS3.
So the moral of the story is: QS 3.0.0 will duplicate QS2 – but don’t place bets on the follow up versions…
MVC and FrontController: QS 3-0.10
Sep 12th
Quantum Star SE 3.0.0 – the tenth revision
During the next 2-3 weeks, QS3 will hit its first major milestone (set way back in January 2005). The tenth revision (v3-0.10) brings together numerous ideas, plans and test code which have been hanging in limbo for months. In short it shows the future face of v3.0.0 – and what sort of mutated beast it will be .
The primary idea to keep in mind is that QS does a fair job at separating data, business logic, client code, and presentation. The original pre-alpha back in April was not quite so clean – it integrated everything into a ad-hoc hodge podge. v0.10 however handles things quite different.
The primary “structure” being used is one based on the Model-View-Controller design pattern. For those not familiar with the concept – MVC describes an object oriented class structure which separates certain broad tasks – typically Controller, Views, Business Logic and Data Access.
The advantages of the above is that it maximises code reuse, and minimises code duplication (the major banes of QS2). In doing so it breaks down many aggregate tasks into their individual tasks – and sets each as a object method. Doing so allows far simpler maintenance and debugging. There are other advantages (but I’m trying to limit this entry!).
For QS3 the MVC implements a Business Logic Layer, a Data Access Layer, a Presentation Layer, and a Controller (the Controller is yet to be added – since all layers are independent, changes to one do NOT effect another – basically its made of a Front Controller, which makes calls on various Page Controllers). The Data Access Layer handles all SQL queries, and their results. The Presentation Layer (simple Smarty-Lite) prints parsed templates to the browser. The Business Logic (or Model) layer handles any internal logic operations – e.g. deducting credits, adding turns, checking if a ship belongs to a fleets, etc. The Front Controller handles incoming requests, and based on those requests accesses the Model Layer to perform the requested action.
As an example:
Player A wishes to Warp to SS#2 from SS#1. He clicks a url of the form (http://www.example.com/index.php?action=location.navigate&starid=2. The Front Controller will immediately parse the action value – in this case it refers to the Navigate command of the Location module. On this basis, it will search for the relevant Page Controller (/Modules/Location/NavigateCommand.php). The Navigate Class will contain the simple methods (common to all Commands) of execute() and render(). execute() will make calls to the Business Logic Layer to update locations of User and Fleet (in QS3 a Ship’s location is taken from it’s parent Fleet) while render() will parse the relevant Smarty Template and output the result to browser.
Its worth noting that the Business Layer contains delegating functions to the Data Access Layer (in effect, a Command class developer would only need to know the BL API – as the BL will pass off to the DAO layer methods, i.e. it handles any other related classes). I also note that data is passed between all layers as a Transfer Object (i.e. an object with properties populated from the data source with simple get/set methods for each property – TOs are passed to the Data Access layer for writing to the data source is needed).
Now to all reading, this may seem horribly complex (and it can be!), but one thing that should be noted is that all this separation and complex contortions results in very fine grained separation of tasks – leaving (of course) many more discrete files, but which are organised by task and module, and are open to editing without disrupting any other code. It comes at the price of intuitive understanding – but I think its a solid step forward.
So what about the game!!!
The impact on QS3 play is not a huge one (at least compared to the 3-0.6 pre-alpha). The game still does the same things – but it does them faster and more efficiently. There’s been added a certain openess which will allow complex plugins and game modules. Single entry points into the game allow centralised controls over input data, url validation, etc – adding security, and removing any alternate entry paths. It also allows a neater method of developer’s authorising valid url’s in response to any request – i.e. restricting pageflow.
You thoughts are welcome.
