Archive for February, 2006

QS Evolved: The Ship Model

I’ve gotten a few questions (again) about needing to add more ships to QS Evolved over what is available from Solar Empire and QS2. I’ve blogged about this before so here’s the short version.

QS Evolved uses a hierarchical system. At the top are Fleets. Fleets are a collection of Ships. Here’s the kicker, Ships are a collection of Ship Components which infer attributes and value upon the Ship. I know it’s not instantly intuitive but ships are not a fixed entity. There are fixed Ships you can buy - however these are standard offerings only - even they can be modified over time. The big clue is Ship Production. If you want a ship you have two options. Buy it or make it. If you make it you can within reason design your ship from the Hull up, add components to it, and manufacture it. In the end what the ship is capable of is your choice - you designed it!

The other thing about ships is they’ll carry a few new limitations. Some weapons may require a finite supply of ammunition. Some may depend on your ship having sufficient power to fire them. Similar restrictions impact engines and shields. The idea behind all this is to remove the stupidly obvious scenario in QS2/SE that a game with unlimited resources will tend to identical fleet strengths - i.e. a stalemate, and usually one that emerges within days - not weeks. It also adds more strategic flavour to the game - if the ship components are up to you, then you can make a lot of choices to favour your tactics. You could outfit a ship with nothing but big powerful engines - let a Warship try catching you then ;-).

The attribute model of ships also enables ships to continually improve their performance - again within reason, and bounded by the capabilities of available components. Rather than having a ton of ships with limited abilities, you’ll have a smaller (25-50 range max) more easily managed set of ships which you could spend weeks constantly improving in small and large ways.

Absolutely key to everything is a simple assumption:

“Ships are a valuable asset. Losing a ship imposes a cost in time and cash.”

In Solar Empire and QS2 ships are NOT a valuable asset. You can lose 150 ships, and rebuild your fleet from scratch in a few days if the game settings are liberal (which they nearly always are). This is a big let down - ships are not worth upgrading unless they have a real value, enough that losing even a handful is a painful experience. The more value driven they are - the more incentive to upgrade, improve and increase their inherent value more. The more these occurs the more time and cash it takes to replace lost ships.

Like I said before, I am not cloning Solar Empire. This is a new Ship Model where losing a ship is a big deal - not an inconvenience solved by visiting a shipyard at Earth. A well upgraded ship with top-notch components could have cost you 5 days of mined resources. Even if you dragged all your other ships up to a superminer configuration it could still take 3 days of mining to even come close to replacing it - and that’s without the time needed to build it, and maybe collect any rare resources required for the construction of its rarer components.

So keep this in mind. When QSE is playable you will be able to manage up to 50 ships. Personally I’d prefer less - but lets say 50. To get truly powerful ships you’ll need to build them on planets. Doing this takes time, and a lot of cash. Losing a ship will be a big deal - it could take days to replace if of a high level. Ships are therefore a valuable asset - sacrificing them is still a strategic option, but a costly one if done for something stupid ;-). Ship management will require actual thought - those of a strategic mind would do well to plan carefully.

PHP Applications using UTF-8 - should we believe them?

It’s not everyday you see both these terms side by side. PHP has poor UTF-8 support. Well, actually its non-existent once you ignore the optional libraries that many shared hosts probably won’t compile with PHP. Now many will know all about setting up HTML pages for UTF-8, for many its the latest programming mantra. Unfortunately just setting a content-type is not enough. This will work completely for English webpages - and only English webpages using unaccented roman characters [a-z0-9].

So what is this mysterious character encoding and why is it so very important to get it right?

The problem is the 16 ISO-8859′s (ISO-8859-16 is a necessity for the EU Euro symbol I think), ASCII, and dozens of other language and custom character encodings to support native character sets. In short its a case of too many cooks. To try and unify all these variants and offer a single standard supporting all character sets (and therefore all languages) we have Unicode, and by extension UTF-8 encoding of the Unicode character set. With UTF-8, a UTF-8 encoded file can represent anything from standard ASCII (read English) to Hindi and more. For a multi-lingual web application this is the best thing since fire was invented - or would be if PHP supported UTF-8 and PHP developers figured out that string functions in PHP at present are doomed to failure with UTF-8.

Consider the example of a Sourceforge page - . Yes, that’s my profile ;-). However there’s a small problem. The page insists it is encoded in UTF-8 (view the source). That’s not true. You see, a simple European accented character in my first name is not displayed - its replaced with a ?. Why? Because its not UTF-8 encoded. Ha! So much for internationalisation on Sourceforge. It claims to be UTF-8 - but its obviously not UTF-8. The truth is that only parts (if any) are actually UTF-8. The rest is most likely ISO-8859-1 - i.e. ASCII English.

One could blame me - I’m a bad person who uses a name containing a Gaelic accented character (equivalent to the french a-acute character). Why not blame the French why we’re at it, or the rest of those pesky non-English speaking people?

Its because of this that many self-proclaimed web apps purporting to support internationalisation or localisation (we use the abbreviation I18N for the latter) are being unrealistic. Many will support I18N for English, and a subset of European languages where accented characters can be given an English character variant, or maybe if they use a template system with UTF-8 encoded templates that require no manipulation - i.e. no database storage or use of PHP string functions. Some will require the mbstring library be available for PHP.

There are still problems. Take a simple example. I create a form accepting a username of no more than 32 characters. So someone from India drops by and enters a Hindi username - 32 Hindi characters. Now the form is submitted. Everything is great, right? We just check for 32 characters. But wait - there is no character length function in PHP! And no, strlen() is not that - not at all.

strlen() does NOT count characters - it counts BYTES. Never forget that distinction lest it burn you. Now UTF-8 is a multi-byte encoding. Keeping in mind UTF-8 incorporates single-byte ASCII we can say the string “Reaper” has 6 bytes, equalling 6 characters. This is what most of us already do - its the evil assumption. But what about Hindi? Hindi uses multi-byte characters.

A 32 character Hindi string will actually contain a lot more than 32 bytes - some languages may take up to 32 * 6bytes, i.e. 192 bytes to represent a 32 character string! Result - our filtering logic fails miserably, a victim of our false assumption that the whole world speaks English and writes with Roman characters.

There are other deeply set practices that fail to account for UTF-8. While Perl supports UTF-8 in RegExp, PHP’s PCRE does not. How many of us use regular expressions in form validation? Probably the same number who use strlen() to count characters… There are other examples. Basically you could list all the string functions.

There is a solution however - we can compile (or edit php.ini for dynamic inclusion) the mbstring library for PHP. However this has one flaw - it’s not a default library which means many shared hosts will not actually support it. So much for PHP’s UTF-8 support. The other solution is to wait for PHP6 which will have native UTF-8 support. But then what about all those hosts who’ll persist in using PHP4 because PHP5 is not backwards compatible?

In short, unless you’re a native English speaker - people using PHP and outputting UTF-8 html while claiming to support I18N are (in the majority) completely ignorant. Afterall for an English speaker there is zero difference between using ISO-8859-1, ASCII and UTF-8. Its the rest of the world that must jump through hoops. Even worse - many of the UTF-8 HTML out there is not even encoded in UTF-8. Often its just a typical ISO-8859 document (written on WindowsXP in almost all cases) with a UTF-8 content-type charset - this largely explains why name is commonly corrupted with question marks and boxes on many English sites claiming (falsely) to be UTF-8 encoded.

My name is not P?draic or Pdraic - it’s Pádraic! ;-)