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.

We are very close to having the Settings classes finished for Partholan. Our tests show the work to date is looking good…

Says it all really…

I finally did the unthinkable and proofread the entire text being used in the website for QSE – the one currently online for people to stare at during testing: http://www.quantum-star.com/devsite2/. I’ll upload the new correctly spelled and gramtically corrected version at the weekend and place at the URI root.

This is still (and always will be) open country. If you believe more information should be added then drop us a note on the forums. At present it basically a set of minimal pages designed to sketch out what the project is all about, how to contact us, how to help us out, etc. Items like a FAQ, manual etc. will get added eventually.

Of particular relevance are the Bug Reporting Guidelines which have proven highly successful so far. I know those following Generations are waiting for another release, but hopefully Ikoda will be available at some point in the near future to make a release. QSE hasn’t seen any major bugs – but then it’s not even playable yet, nor close to for the moment…

Since I won’t be online tomorrow… Hope everyone has a good St. Patrick’s Day, and for those with the day off from work, enjoy the parades!

I won’t go into huge detail on current QS progress. I’ve not had much chance to do anything on the project this week, so at the weekend I’ll spend a few hours on it. I have most of the game support ready to go, so all I really want to do for next release is have a location page finished, and fleet navigation enabled. Maybe an Admin Panel section for universe generation. That would make the first release where you can explore the universe and actually do something .

I also need to get that translation code pulled together and tested – see if this system is workable or an unrealistic pipedream. No detailed planning for this one so its off to unit testing to build it from the ground up.

Back to topic.

I made a new topic on the QS forums regarding what players/users want in QS. It’s one of those sticky threads that are meant as permanent fixtures. So far there’s been a good amount of contributions, and some ideas being swirled around. Many at the moment have been covered by QSE planning – its sad to see the most mentioned are truly bad areas of QS2 in terms of gameplay. Even QSE in its basic form would be a significant improvement over QS2 I think… Anyways, one of those perpetual followers of all things QS (and BNT/AAT more likely ), Kitty, made some good points. One thing she noted was planets and how they’re done in SE style games. QS2 did a little tinkering to limit planet counts, but it was never ideal (and it’s buggy in the current QSG legacy release unfortunately). BNT of course uses the star type to determine number of planets allowable – most logical system.

The QSE aim, and I’ve thought about a bit more, should attempt to force a diminishing return in benefits from creating more and more planets in the same star system. Rather than having an upper limit of 5 planets where those planets will all be identical in type, instead do something more along the lines of reducing the size/limits of each extra planet created (noting there would still be an upper limit of about 4-5 planets).

So a 5 planet limit would give rise to a normal “large” planet, a medium, and three smalls – or maybe just use a fixed scale where the limits for subsequent planets are always 15-20% less then the last preceeding planet. This would encourage players to move outwards since a star system would only support one large planet – the rest being smaller. This of course has a neat side effect of placing a lot of value on the number of systems controlled by a player – something completely missing from QS2. What’s a strategy game without some need for grabbing territory?

A few other posters have noted a need for more ships (and more variety within them), along with similar suggestions. The point to make is that Ships technically are nothing more than a virtual container of attributes in QS Evolved. They basically act as a collection of “Components” each of which confers an Attribute value upon the ship. So, for example, you could have a ship comprised of Cargo Bays +1000, Mining Laser +5, and Thrusters +10. Result is a ship with attributes of:

Cargo Bays: 1000
Mining Rate: 5
Manouver: 10

These attributes would be used within certain calculations and process effecting that ship, as well as specifying any ship restrictions. Since they’re all component based, and attributes are simple serialised arrays, attributes can be added to the current list with ease – another factor to consider in creating future modifications and plugins.

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.

After putting in a lot of hours on Quantum Star SE Evolved this weekend I have moved onwards from my earlier 0.18 test release. That was aimed at exercising the Partholan backend to find any last obvious bugs. This weekend I finally got into the meat and bones of the game. I started with a diversion into the Installer which had a few issues in 0.18 (most annoying was the lack of a proper theme for it!). I’ve updated and added back the Install theme however and the results are quite satisfying. I’ve added a few screenshots to this post to show it off.

The opening Installer page.

The Installer is an attempt to simplify the often horrible level of detail some PHP applications will require. Most of the in-depth options are hidden and can be changed from their defaults later from the Administration Control Panel. In most cases they won’t need adjusting. A lot of the messy items from Solar Empire and QS2 have been removed. QSE automatically figures out the URL and full system path with little trouble. Database choices are down to a minimum with any specialised requirements managed fluidly by the backend. There’s been an effort to simplify the number of directories requiring permission changes (just Data and TplCache).

Now on the game side I’ve upped the ante and created a simplified CSS based theme called BlueSpace. It’s layout is flexible and completely CSS driven. Tables are being used only to support our form layouts and even that can potentially be replaced with a CSS style when I spend the time needed.

The temporary Admin CP page using the BlueSpace theme.

The theme is pure CSS. I spent time wondering how to manage theming and making it as flexible as possible, but in the end the usual lack of theme making on open source games decided the issue. Themes are now nothing more than customised headers, footers and CSS – that in itself adds most of the flexibility needed. The templates themselves are fixed XHTML though obviously you can alter these on a private server – I’ll note this means text is not changeable if you decided to upgrade directly from the standard QSE development releases without text diffs. This by effect decided how to manage translations. My translations approach is going to be to pre-generate translated versions of the base “tpl-en” English templates into separate Template directories; tpl-fr, tpl-cz tpl-fr-CA, etc. In effect I want to remove the need to translate on-the-fly at runtime anything except Game Module content. So lets just translate and store the templates as semi-independent entities, allowing perhaps some minimal CSS adjusting for things like text direction. The approach makes possible a more manageable translation effort matching full English sentences to translations – not the flawed key phrase matching that is very hard to get right.

Anyway to round out this post, the game is moving ahead steadily now that Partholan is feature frozen. I’m currently playing about with the Administration Control Panel to add the most necessary functions such as the Game Creator, Game Manager, and the updated Universe Generator. I have to admit feeling some growing pride with QSE. It’s hard to get that from working on a technical blunder like the original QS2. Evolved is waaaay better . I’m having fun working on it at least…

Another BlueSpace view – the Create Game form view.

Can’t wait to get a starting Star System view finished so I can start adding in all the funky fun stuff like Fleet navigation and Homeworlds. Looks like yet another more complete release by week’s end!

QSG is a branch of the v2.2 code developed by Ikoda. I don’t blog all that much about it since I’m not personally involved – I work solely on the Evolved branch.

So far the project has been leaping ahead in bounds. Yesterday saw the release of QSG 0.55 by private mail (beta testers only). In the meantime the activity has moved up a notch with Hades opening a QSG game server. Another is now also open.

Looks like playable QS versions are back in fashion…

Hades ServerFransie’s Server

The new QSG version eases the old QS2 load a little by using ADOdb-Lite. Hopefully that makes some impact on the server load issues. A few other changes have eased up on database load also. This is pretty traditional QS gameplay – but without most of the irritating bugs. Try ‘em out.

Well outside the licensing entries I am still working on Quantum Star SE, in between reading the latest Robert Jordan novel from the Wheel of Time series that is.

Recently I decided to do a minor web update to the main site – at the moment we’re largely working on automatic through the forums. One change put through yesterday was to install the Mantis bug tracker for Quantum Star SE – http://bugs.quantum-star.com.

Now Sourceforge runs its own facilities, however I wanted a little extra control over some of these. Henceforth all QS bugs should by declaration of the Lead Developer (that’s me ) will be reported first to the tracker, and then to the forum where it warrants further discussion.

The first bug to be reported is of course that continued use of PHP_SELF to construct a root URI for the game. Its a known security issue, and has been for a while – we’re not really worried about it until we start making alpha releases more publicly, i.e. through Sourceforge.

On a side note, I’ve noted Moocat to the list of blogs (see left). PanamaJack’s rss feed seems to headed upriver for Winter. Some type of internal XSLT error. I’ll drop him an email to get it fixed if he doesn’t read this first.

I know I’ve spent a few entries moaning about licensing – but this is not a preview to a sudden licensing change. As far as I am concerned (thus far – and until the GPL is finalised) the Affero General Public License is suitable for the Quantum Star SE project.

To explain – the AGPL explicitly states that if a program is distributed under the License offering a mechanism to download the source code, than that mechanism must also be replicated in any modified versions. For QS, that mechanism will be a simple link to the Sourceforge download space. Any modified version used would therefore have to maintain a link – but to a similar archive of the the modified source code.

Now QS has no such link at present – we haven’t distributed any source code including game features just yet. But it will be – and so we require no license change except to GPL3 once the draft process is completed and an equivalent protective measure is included.

Never hurts to repeat myself on the blog. To force some differentiation between the two QS branches, Quantum Star SE Main branch is now known as “Quantum Star SE Evolved”. Hopefully this will send out a message that QS2 is older, and therefore not actively developed. There’s a common misconception for players especially that the new versions are a continuation of QS2 – they’re not. QS2 was an extremely buggy, server intensive, insecure pile of code. QS Evolved is designed and written from scratch, and avoids those problems – at least it better .

There are still some sideline areas I need to address to QS before releasing the future stable versions. Problems fall into three camps; PHP Source, Licensing and Intellectual Property, and Transparency. My groupings might not be intuitive, but for what its worth Transparency applies to the internal running of the project, its policies and practices, and its financing (in a fit of optimism I declared QS a non-profit project). I’ve looked at a few areas, and had a go at implementing some solutions.

For example, the current available code carries both a human readable, and XML P3P Privacy Policy (not integrated into the HTML yet). It’s a nice idea, and the policy validates even on quite strict restrictions under IE6 (strict due its bugginess no doubt). As a result of that initial review, I removed the collection of demographics (one of those QS2 hack ons), sex, age and the requirement that was there for real names. I think this might even get us past the COPPA requirements – possible, but needs to be confirmed.

COPPA is a US Law governing access by under 13′s to registration on websites – basically if the website collects certain information, or targets certain age groups, it is required (internationally – don’t ask why) to collect written permission from the child’s parents or guardians. It’s a good-feeling policy – not well implemented (the child can simply lie obviously). It is still in force (unlike the much confused COPA).

Anyways, before I went on a rambling spree I was where again? Ah, policies, transparency, etc.

My current bright idea is to look into formalising the management of the project. The problem with a democracy of one, is that its suspiciously like a dictatorship. One man development holds a certain risk of losing sight of what your community wants, rather than what you think they need. I’m looking into the possibility of an initially informal arrnagement where two or three long time groupies and developers would have a little more power in how QS is run. If it works well, and smoothly, I might consider transferring a little more weight. That of course means we would need rules, and some long term goal in those rules (so there’s no sudden policy shifts down the line). I’m not up to paying solicitors, so an imperfect custom agreement is in the making