Archive for March, 2005

As posted by Thox to the QS forums – there is an issue with the URL authorisation process for users. Basically it prevents using two browser windows to simultaneously access two separate game processes. This is because the system ties the user into one single request path, by storing a list of all URL’s they are allowed to request (and therefore returning an error, or redirection if any request is not listed). It’s an oft misunderstood idea – so here’s an example:

Player accesses location.php (http://myserver/location.php) and is granted a Star System overview and links to several facilities (let’s assume a Homeworld is present). Next, the player opens in a new Window the authorised link (http://myserver/homeworld.php?pid=1) accessing the Homeworld summary and services list. On the original Window the player then attempts to attack another Fleet. The result is that this request fails (and the user is redirected, effectively, to the Homeworld summary where the game knows they should be, i.e. their combat request is not listed as an authorised URL on the database!). Net result? Player can really only do one thing at a time, regardless of the number of Windows they utilise – unless of course the two Windows both display the same authorised link (hence we should really refer to this being a single request path system – you can use two Windows, under limited circumstances).

As Thox questions – why do we dare remove the Player’s ability to use multiple windows?

Simply put – QS3 is a game, not a forum, not a CMS, not another generic app – a GAME. Games are funny creatures. Give them a rule, even a simple one, and you need to enshrine that rule in layers of protection so it can’t be broken or bypassed by those tricksome cheating bunch of maniacs we call “players”. Additionally online browser-based games suffer a minor flaw – every action requires a user’s input (a browser request). So any user can delay the outcome of any action – simply by not requesting another page, or worse logging out, and logging back in to reset.

This small upset in the flow of a game has a knock-on effects elsewhere. In many games, all actions take a single request-process-output cycle (not counting any confirmations) which means even very large and possible disastrous outcomes are instantly calculated and acted upon. Combat is a prime example – to attack or not to attack… If you do, and lose, you die – it’s all calculated immediately with no regard to letting the player adapt or react to a losing trend. This stinks of a failure to accomodate strategy within combat…

QS3 in future versions would like to offer more than a single option “Attack”, adding “Cloak”, “Flee” and “Kamikazi” options and others that can be used. But this offers the problem above – if you allow battles to continue through several requests – the player can simply break off the attack by requesting a different file in the game. Doing so means any player can “test the water” for a combat round to gauge an enemy Fleet before committing to a complete battle. This lowers the overall risk and cost to the player for initiating combat – which is not great. Combat should be risky – it should be difficult to assess an enemy target, that’s where strategy becomes useful.

So lets assume we add all our extra options – and add a game rule: any attack must be completed before other game requests can be processed. It’s a reasonable rule – you start a fight, you better be ready to finish it! See why we must disable any alternate request route into the game now? Now the player is forced to attempt to Flee or otherwise – subject to the game mechanics which we’re enforcing. They are prevented from bypassing the combat process, and escaping unscathed (relatively speaking), unless permitted by the game rules and a check against their Fleet attributes. This is supposed to be a strategic game – not a another exercise in “I’ve more fighters than you – you die” thinking…

Now it could be noted that such a radical departure from SE norms is pretty over the top – I agree it can be interpreted as such in the context of Generic SE where the current combat system is well entrenched, but a rule is a rule is a rule. Why should I drop some game functionality just to add some extra useability? Why should I limit rules at the expense of more in-depth strategic gameplay? The benefit (in terms of more strategic combat) far outweighs the cost (single click attacking – no options to adapt or recover). Besides Combat is just one example…this issue is scaleable.

The added beneficial side-effect of such a system also – is that the entire URL (including query string) is authorised. I won’t explain the possible security benefits of closing off routes to the Game Engine by manufactured URLs doped with malicious data designed to allow cheating or worse. We still validate all incoming data – but a little extra preventative doesn’t do any harm….

In conclusion – less useable perhaps, but if it adds better game flow, more security, and allows more complex strategic options then it does have its benefits. Players would still have access to non-game processes through a secondary Window such as messaging and forums – so where’s the massive cost to the player? Players do not make good referees for game rules… What defines the start and end of any game process is a developer’s decision – not a player’s. Would players be allowed to simply escape combat on a PC game? Should players be allowed to simultaneously attack and re-supply their attacking fleet in the middle of combat? Yet such are the possibilities in some PHP games. Some others would produce an error perhaps – but is that all too different from blocking access to the file in the first place? They both result in a similar end – blocking user requests to other files.

I do agree that messing with a users access is interference – however let’s not forget that in a complex scenario such as a game there are rules and game mechanics to be upheld and enforced. In QS2 and some other SE versions there were a lot of open holes for players to throw a spanner. Backspacing could allow a user to re-send specific forms, url editing could be used to horrible effect, the point is that when we say the player is in combat – they should be, and should also stay in it, until the game decides otherwise…