There was recently a significant stated desire for conquerable content in the game. This always has been a major goal of ours, and we've made some strides in this past year, but creating a system of more complete dynamic flexibility, outside of factions and corporations, requires some thinking. Even before one goes to ask "well, what does station conquest mean", one is faced with "how does it even work?". This is the sort of area where it's better for us to spend a little time thinking of a design with long-term flexibility and usage, rather than simply hacking something together quickly.

The Key System

Background - One of the issues with implementing conquest of stations, capships, even space, is determining who "owns" the resulting conquered objects or territory, and what that actually means. Individual ownership is possible, but gets a bit weird when one runs into various access control issues (having your station turrets not fire on your friends or guild mates, or even letting people dock). Guild ownership could work, but from a philosophical design standpoint I am loathe to require guild membership to fundamentally access a whole area of gameplay (like content conquest). Guilds should stand on their own, the inherent benefits stem from the organization and resources accumulated by a coherent whole; not from any special dispensation handed out by "the rules". Any ad-hoc group of players should be able to achieve anything that a guild can. Thus, such a system should dovetail well with guilds, but remain fundamentally separate to allow usage by single players and ad-hoc groups.

Outline

When a dynamically-conquerable object comes under new ownership (station conquered or build, capship purchased, etc), the new owner is given a special "key". This is the "Owner Key" and is generated either at the time, or may be selected by the player from pre-existing keys on their "keyring". The Owner key inherently allows all high-level access functionality (whatever may exist, given the type of content).

The Owner may then hand out to other players a User Key. In general, this key would permit basic access functionality: docking, IFF for turrets (they don't shoot you), etc. At the time when the Owner configures the station or hands out the first User key, again, they would be prompted to either generate a new key, or select one from their keyring. A given Owner & User key are generally associated as a fixed pair.

A Key Itself is a virtual construct that is kept completely server-side. It is never exposed to the client in any way. It doesn't matter how the key is implemented behind the scenes, as long as multiple (different) keys never collide. It could be as trivial as a number we increment as new ones are generated. Given that it never leaves the server cluster, it is practically unhackable, barring someone compromising an Owner's account and giving out keys using the game with their inherent access.

If a given dynamically-conquerable construct is re-conquered, the next "owner" is presented with the same options as the last: select an Owner Key or generate a new one. The keys of the previous owner would no longer serve any purpose on that particular construct; but even if all associated constructs (stations, capships, whatever) were removed, they would still continue to exist in the keyrings of the previous owner(s), for future usage in other ownership scenarios.

All keys have default short descriptions (owning character + location, or some such), but may have their description lines edited by whomever has the key on their chain (whether owner or user). Description changes only alter the instance of the key on a given character, so many people may describe the same key in different ways, as suits them. All keys should also contain a visible, fixed unique identifier, such as the date/time of the initial key creation and original creator, to allow people to compare keys if confusion should evolve.

Owner keys may be distributed to others, as well as User keys, but the given pair, once generated, are linked: only the Owner(s) may designate new User(s). Players with User keys, however, may attach new content to the key. For instance, someone conquering a new station can define the User key to a pre-existing key in their ring. This would then allow anyone else who already had that key to pass unharmed by the defenses and dock. The conquering player would not be able to hand out new copies of that User key (unless they were also an Owner), but they could expand upon its pre-existing utility.

Whomever retains a given Owner key may revoke the associated User key from specific players. Or, as a more automated functionality, an Owner could check "grant User key to all active members of my guild", then the keys would be automatically granted and revoked as new people joined or left the given guild. Similarly, an Owner could check "grant User key to all members of my buddy list" and the same behaviour would apply.

In the case of giving Owner key access to others, the transfer inherently adds all the privileges of ownership. An option "grant Owner keys to active Guild Leadership" would give owner keys to the Commander, Lieutenants and Council of a given Guild, and would remove old keys as people moved in and out of these positions. Aside from this, Owner keys cannot be revoked and only be voluntarily deleted by the given Owner. Owner keys could also be granted via the same mechanics as User keys, so an entire guild or buddy list could be given an Owner key, if wider total-access was desired.

Usage

What these two access levels would mean could greatly vary depending on the type of content, and how much configurability we allow in the long run. For instance, we could eventually let people select different station-access features that might be granted to the given User key, via a set of checkboxes. In this way, an Owner might allow all Users to buy and sell items, but not use manufacturing facilities, etc. There would remain only the two levels of access control, for the sake of simplicity.

Similarly, different types of content have different ramifications. With conquerable territory, a beaten sector satellite could be set with a new key, then associating any automated IFF response with anyone carrying that key. In this way, conquered territory could be held by the Owners, with access given to Users who wish to pass through any automated defenses (turrets, hired NPCs, etc) that might patrol the conquered region.

The same key can, of course, be re-used as often as desired, for any amount of content, allowing territory and construct ownership to fluctuate, growing and shrinking while retaining the same virtual access lists.

Income gained through ownership of a station or territory (percentage of station profits? route tariffs? kickbacks from pirates permitted to operate in Owned territory?) could be split amongst those with Owner keys of the given location. In this way, a myriad of future gameplay constructs could make use of the same fundamental key implementation. Keys coupled with territorial or station income start to take on many of the properties of a player-based faction, but without any additional complexity or special game mechanics. Plus, they may be default-associated to a guild, to allow guild membership to maintain a 1:1 auto-updated mapping to the given key set, without mandating that all key-driven features require a guild.

Keys could even be used for access-control of fundamentally "player-owned" content, like ships and addons. In this way, access to a certain character's inventory could be allowed, so friends could make use of ships or resources. This is a little further out there, as we have a lot of programmatic infrastructure that is not built for this particular case, but the illustration still holds true.. keys can be used for any hierarchical, distributed access-control scenario.

Key Management

Features would be needed to see, by clicking on a key, all the content to which it grants access. At the same time, an Owner clicking on a given User key would need to see all the Users who have the key (and revoke from them, if needed). An Owner clicking on an Owner key would simply see all the other owners who also had the key. Other features would likely be needed down the road, to help manage complex keychains and assignments.

The Near Term

For right now, this would simply be used for stations. A few that would probably be specifically set up to be dynamically conquerable, and the mechanics for the key system implemented. It might be feasible to try it on some territory as well, eventually, and add in some benefits to having territory (sectors) near a given station. Further profits from local NPC miners, or some such.

-------------------

This is a basic overview, and perhaps not written as clearly as I would like, as I'm kinda tired and it's been a long night. Still, I wanted to post this and get some feedback.

I'm going to try and chill out this weekend, so don't expect responses until Monday probably.

[EDIT]: RFC Addendum - We are planning, at this point, to allow multiple user keys per owner key. These could each have separate authentication features defined for them, so some people could be allowed only to dock and repair at a station, while others can trade. Or, someone could be permitted to pass through space (IFF with turrets), but not allowed to dock with stations therein, etc. All owners can revoke all associated user keys. To reiterate an earlier point, user keys can only be distributed by owners.

A clear enough post to me, looks good. Can't spot any obvious exploits at the moment. Good job!

Very nice, Inc. I do love your ideas. ;) All very complicated, as one may expect, however, that's just how it has to be. ;) Good job.

Just to see if I got this right: this sounds pretty much equivalent to a privilege system in an RDMBS. An object is owned by a role, this role may grant privileges to other (implicitly created) roles. A loss of said object would revoke existing privileges. An existing owner role can be assigned to another object (eg when another station is conquered), just as privileges for users can be assigned to an existing (non-owner) role (which would be the user keys).

Did I get that right?

This sounds pretty mint.

Wow, incredibly well thought out. The key system seems very in depth and sounds great. I love the ideas of having benefits for nearby conquered territory from NPC miners! There's so many ways to go with this, it boggles the mind.

Heck, just giving people the opportunity to conquer a station is cool enough for now with no benefits or perks. As far as possible benefits to owning a station go- the idea of getting a cut of the profits from NPC traders sounds very reasonable.

Also, things like escorting a trade convoy from an owned station could result in the normal pay for the escort, and some of the rest of the profits can be automatically divided out to those with keys to said station.

This would encourage more trade right?

When your station is under attack, the owners should receive an automated message notifying them of the attack like when a flag was capped in the beta.

OK, I gave it some more thought, and came up with three issues:

1. Merging/Splitting Keys

Someone conquering an object may generate a new OK, or assign a pre-existing OK to it.

Say I do the former, for five different objects. After a while, I realize that management of 5 different OKs (and the associated UKs) is a pain, so I want to merge some of those OKs - let's say 3 of them - into 1 OK. In that case, the UKs for the obsolete OK would have to be reassigned to the primary OK.

Same thing, other way around: I conquer five objects and assign them to a pre-existing OK. Later on, I realize I want to separate the owner privileges into 2 OKs.

2. Transferring OKs

Transferring OKs to active Guild Leadership sounds fine, but what if I want to transfer it to another player (sell a station, for example)? Technically, this would be equivalent to another player conquering that object; the issue is more that the necessary infrastructure for voluntarily transferring the object would be nice (this is the often-requested feature for selling ships, I guess).

3. Temporary Ownership

OK, I haven't given this much thought yet. In general, I was thinking of "hostage" situations, for example pirates conquering an object and demanding ransom.

It would be nice if a conquered object would retain the original OKs for a given period, depending on the object type. This would lead to the awesome situation of pirates holding said object, and players either paying ransom or mounting a counter-offensive. The ultimate furball, so to speak.

i have a few questions, but i suppose they arent as complex.

firstly, do you plan on designing new systems for the conquerable territory/stations?

second, are we going to build the stations or are we going to have pre-existing stations to conquer?

third, are we going to have any control of the npc's we "hire"?

Players should be able to steal keys from other players. Not sure how to implement that offhand. Maybe an extremely low drop-rate cargo, that players only have on them if they take the key with them. That way somebody can go for a big round of dueling in b8 and not worry about dropping a key to the guild station or whatever.

Having an access key stolen from you should not exclude the original owner from using it, as it's digital in nature. You could say it the computer core of the players destroyed ship survived or whatever and the key(s) were recovered.

The stolen key should only be good until the stealing player misbehaves at the station or the original key is revoked. Stolen keys should be loadable as cargo as well, so somebody who just happens to find a key could sell it to somebody who wants it. Revocation of the stolen key should also revoke the original key, as my idea is that the player using a stolen key is essentially running in disguise.

I guess that would also allow access to the other player's inventory at the station in question. This would make carrying all your keys on you have a very slight incidence of extreme loss.

Players who have access keys, either original or stolen copies should also be able to turn the key in, in person. This means that if your key is stolen, you can rush to the station and hand in your key for a new one, much like if you're wallet is stolen you can call your credit card company. This would invalidate the stolen key without loss of your inventory. The reason for having to show up in person is to give the stolen keys some usability.

Stolen keys being turned in at the station should confer a cash reward, but no access to the original key owners stuff. The cash reward should be based on the immediate full sale value of the original key owner's stuff at the station. On second thought, this creates a money tree, as I could launch ec 89's and /explode to drop a key, then pick it up with an alt and turn it in for reward, and just keep doing this.

I've got more, but ive got other things i have to do now, so ill elaborate later

LNH: Stealable keys is entirely possible and we can look at the eventually, but I'm not that interested right now.. I'd rather just make the overall system work and get dynamically owned content rolling. We could certainly "wrap" keys in droppable objects and things like that.

Armonia: Yes, I was looking at expanding grayspace (another whole ring around the current univ, that touches in Ukari, Edras and Deneb, which would be basically "free for all" and completely dynamic. But, this topic is also beyond the scope of this post, best left to another thread.

In the short term, the stations will not be buildable, we'll just place some which are conquerable, and tweak the mechanics with that. "Buildable" has a lot of other requirements.. checking of real-estate and distances, the lack of intra-sector basically forces one station per sector, the need to create a whole "modeling" system to allow real station assembly from pre-existing components (something we've wanted since the 90s). So, for now we will Keep It Simple and just place some conquerable stations in existing grayspace.

The degree of control over given NPCs is another useful topic for.. another future thread. I was just throwing that out there as an example of something that could work with this mechanic.

Wild Thing: It definitely has some similarities to RDBMS auth, although I was also considering general packet filter mechanics as well.

1) Merging/Splitting - I did consider this, but left it out of the post until I could think about it more, and potentially talk to people about variations on implementation complexity. For one thing, it could be useful to simply have multiple UKs per OK, this would also allow separate auth rules for a single location (users with UK X can trade but not mfr, users with UK Y can mfr). If this were permitted, then "migrating" to a single OK would simply require attaching multiple new UKs to the one OK. But, having some ability to merge might also be worthwhile. I've also considered "Master Key" supersets of OKs that, while simply groupings of OKs, could be distributed as simply as any other key. Anyway, we'll see, having more power in the system is good, but I'd like this to not be horrendous to implement.

2) Transferring ownership. I thought of this too, and there is value to doing a trust-free system on this. As-is you could see if someone were keeping access by simply clicking on the OK and seeing if they still had it, but that doesn't solve the problem. Anyway, I think this sort of special-case key addition/revocation scenario shouldn't be a big deal.

3) I'm not sure that I see the value in temporary ownership. If the pirates are able to conquer the station, normally, then they could simply.. do that, and demand their ransom. Upon receiving it, they could hand over the OK they used (or perhaps use the same "station selling" mechanics above).

Anyway, I'd rather not special-case ourselves to death here. If we can cover even 80% of prospective cases, and move forward with actually implementing something sometime soon, that'd be cool.

On the surface I like the "key" Idea/metaphor HOWEVER it seems to only allow explict access. There needs to be a "public" level of access as well. A good analogy would be the differance between your house key, a key to the Guild software office and the mall entrance key. This would suggest private,group and public access levels are needed.

An old locksmith method is to have different levels encoded in a single key. For instance if a key had 7 tumblers then 3 would unlock a single door and 5 would unlock several doors and all 7 would unlock all the doors. With an infinate number of software tumblers availible creating a single key code and handing out only the relevent sections might be more managable...

I was going to suggest something similar to Kettle

While less secure blanket access to certain factions/nations should be optional to grant because i'm sure trading junkies want lots of people to visit their station

Knowing LeberMac, he will lose all of his "keys" in Sedina and have to call a locksmith... (Or ONSTAR) to open up the station for him.

Substitute "permissions" for "keys" and it sounds like we're determining access for a website or program, which I think is an excellent basis for a working system of permissions. Let's make the permissions/keys as "granular" as possible, and this will be a great idea.

In fact, "keys" could interface nicely with the existing faction system. except in that case, the Owner Key is owned by the faction A.I. which determines which permissions you should have.

I think we should also be able to set levels on keys for certain guilds, factions, and players that are considered greater threats than "zero permissions." For example, a n00b might have "zero permissions" key level for a guild-owned station, which means that they just get fired on if they get too close. There should be a few levels below this where the response is far more aggressive, i.e. immediately launching flare-armed warthogs to intercept the intruder if the pilot or guild is at the lowest "key" level would be nice.

Any further thoughts as to combining the faction system and the key system?

Keys should be 1cu and required to be carried by a pilot. Obviously, if dropped, they're free for whoever. You can only leave the key at home if there's someone staying behind to let you in.

I'm not sure I like the idea of capturable keys. It reminds me of losing/stealing a driver's liscence or ID. If it gets taken people will still know who you are even though you don't have it, and someone else trying to use it probably wouldn't get away with using it. It wouldn't make sense for Ecka to get fired on at TGFT station if he lost his key, but UIT can still tell who he is. It just seems like keys should be intangible and automatic, like faction standing.

If anything it should be like a credit cards. Someone can steal it and use it, but the original user can alert the credit card company and cancel the card. Maybe both the person that dropped it and the person that picked it up should both retain their key privileges, but the person that dropped it can report the person that picked it up and cause the other to lose their privileges.

Also, because it hasn't been explicitly mentioned, I think there should be options based on faction standing and/or nation alignment. It would make it easier for a serco guild to exclude all itani if there was an option for that.

Yes, you will be able to universally permit people based on major faction standings or other fundamental tenets. Having public stations is not an issue. Having non-public stations is, hence the key system.

We aren't doing capturable/droppable keys right off the bat. If someone wants to take a station, they can do it by force. Droppable keys and ramifications thereof can come at a later point.

w00t!

I was thinking more of how to handle NFZ violations and so on. This would imply a unique local "faction" for each station and each player. Without it the station owner would have to constantly update the keys and so on by hand. Not exactly a trivial amount of information to keep track of and perhaps a rewrite of the faction system may be needed....

Keys seem to work well for access to the non public areas but may be a bit overkill. If a faction system of some sort is used for handling normal stuff then the "owner" or commander could just specify additional "managers" or lieutenents to access the top level functions.

Excellent idea Inc.

I can see the role play possibility of a stealable key for minor assets, but for major assets a pilot ( or a suitable alt ) would just become an asset manager and stay at home.

The key system sounds well thought out, whether or not they are actual widgets or can be stolen it would be good to have two levels of security and the ability to grant or revoke access based on rank, faction, or even license levels. I also think the paradigm of allowing ad-hoc groups of individual players to theoretically accomplish anything a guild can is a wise decision.

I think we could use another thread for the mechanics of conquering dynamically conquerable content, unless you wanted that to go here, Inc. I really like the idea of having sector satellites that can be destroyed in order to trigger the change of sector ownership, some of these satellites could be placed around points of interest in different sectors. I also like the idea of the ownership of proximal sectors having an effect on the station itself.

Two questions, who is defined as the "conqueror" (are there one or many?) of a construct?

Would it be possible to go directly after a station at will or will there be prerequisites such as owning a certain percentage of sectors around the station first?

As a related topic, see this thread:
http://www.vendetta-online.com/x/msgboard/3/11317