Tuesday, March 23, 2004

Player Contracts +

As I noted in my detailed essay on Player Contracts, I'd like to see MMORPGs offer a feature that allows players to be able to create contracts with each other to perform different kinds of tasks.

Not only would this be fun in itself, it would open the door to player missions, since enforceable contracts would allow players to trust each other in financial deals.

Since the original document was pretty detailed, I thought it might be helpful to provide a more condensed version. This will still seem pretty long to most people, but those who enjoy thinking about game design may find this version a little easier to digest than the full workup.


A Player Contract is an agreement between two players whose terms are enforced by the game to trade items of value. Player A (the "contracting player") agrees to provide goods or money to Player B in exchange for Player B (the "contracted player") agreeing to provide goods, money, or a specific service to Player A. Player A makes the contract offer, and Player B accepts the offer.

A Player Contract system will allow Player A to write a contract document that specifies a number of options:

  • the contract type
  • what things are to be exchanged
  • when exchanges can occur
  • how the contract may be successfully terminated
  • optional penalties for breaking a contract
The game system itself has to be able to do two things:

  • recognize when the terms of a contract are met or broken
  • automatically apply contract terms based on contract status
The important thing to recognize about this is that we won't need player lawyers or CSRs to adjudicate contract disputes because the game itself, acting as a completely impartial judge, will handle all contract resolutions automatically.

What follows are the details that describe how to achieve these goals.


A good contract system goes well beyond merely trading goods. It enables a service economy to flourish because it allows players to perform useful tasks for each other. Not only does this help spread money around, it's just fun.
Examples of possible contract types are:


swap goods for goods or goods for money


give another player goods or money for an unspecified reason


move items [or player characters] to a specified location


give items to a specified player character or NPC


go to a particular location


take possession of a specified item


perform within 20 meters of a specified player character or NPC


heal or cure a specified player character


temporarily improve the stats of a specified player character


create a particular kind of object, possibly with certain stats


bypass the electronic security of a container or item


eliminate a specific lair, destroy a unique item, or kill a creature mob


defend a specified player character or NPC for a specified time period


kill a specified player character or NPC [who must agree to be a target]


marry another player character [allows for divorce, too]

These are just contract types that I've thought of -- I'm sure there are more.


Contracts become truly useful when they're not restricted to being one-shot, immediate deals. Players should be able to specify the periods in which a contract is to be active according to lifespan and frequency. Lifespan options are:

  • immediate (trade happens as soon as both parties agree)
  • limited (trade happens at a specific future time)
  • indefinite (trade may happen at an unknown future time)
and frequency options are:

  • one-time (trade happens once, then the contract ends)
  • recurring (trades can happen repeatedly until the contract ends)

Contracts should have two mutually exclusive termination options:

  • unilateral (either player can cancel the contract without penalty
  • bilateral (both players must agree to cancel to avoid imposing a penalty)
Players won't use a contract system if the other player can just cancel deals, so the bilateral option has to exist to allow for penalties (see next section) against simply breaking an agreed-on contract. But we don't want to force players who trust each other to have to make every contract bilateral (and indefinite-duration contracts should not be bilateral), so there also needs to be an option to allow a contract to be unilateral.


There are two types of penalties that could be applied if one player breaks the terms of a contract:

  • penalty (a cash reward paid to the contracting player)
  • bounty (a cash reward collectable by the first player who eliminates the target)
For a penalty award, both players agree on the reward amount to be paid to whoever doesn't break the contract, and each party puts up half of that amount when the contract is accepted. If Player A breaks the contract, all the penalty money is immediately transferred into Player B's bank account, and vice versa.

A bounty works the same way, except that the penalty money is used to pay a bounty hunter to go after whoever broke the contract.


The key to understanding how Player Contracts work is recognizing that there are three "accounts" in a contract. Each account is a container that can hold money or goods.

  • Payoff Account (what Player B gets when the contract is activated)
  • Provision Account (what Player A gets when the contract is activated)
  • Penalty Account (what one player gets if the other player breaks the contract)
The first thing Player A does when he creates a contract is to choose the contract type from the available options. Depending on the contract type, this may set some other fields, and will at a minimum determine the specific fields Player A needs to fill in for the rest of the contract.

Player A's next task is to enter the desired values into the three contract accounts. He is required to put the actual payoff into the Payoff Account -- if goods, they're taken from his bank vault (or personal inventory in some cases); if money, it's taken from his bank account. Either way the actual items are taken from him and placed into the contract's Payoff Account container. This insures that the contract is for real. (It also specifies what will be taken from his bank account every additional time the contract is activated if it's not just a one-time deal.)

Player A then specifies in the Provision Account what he wants to receive. It could be a certain type and number of goods; it could be money (assuming he's not offering money as a payoff -- simply swapping money for money would be pointless); or it could be a particular kind of service. If it's a service, then Player A will just fill in the details (if any), since the specific type of service will be set when Player A chooses the contract type.

Next, Player A will specify whether the contract is to be unilateral or multilateral -- in other words, whether it will be OK for either player to break the contract, or whether both players have to agree to terminate the contract in order to avoid getting stuck with a penalty. Allowing this choice enables players to either have a penalty (if they want insurance that the other player will honor the contract) or not (if they fully trust the other player, say, if they're both members of the same PA).

Finally, the penalty type is set -- either as a cash payout, or as a bounty. In either case Player A moves half of the specified amount from his bank account into the Penalty Account.


At this point the initial contract (which I call a "draft contract") has been created. Now it's time to negotiate the details with Player B.

After Player A creates a contract he has two choices. The first is to put the contract up on a Contract Terminal (creating an "Open Contract"). Once it's on a terminal the terms can't be altered by anyone; if a wandering Player B reads the terms and likes them, he can accept the contract and it goes into force immediately, or else he can simply choose not to take that contract.

Player A's other option is to offer a contract directly to a player character I call this a "Personal Contract." It's just like the Open Contract except that it's directly offered to one person (another player character), and the terms can be negotiated in real time by both players.

Player A offers the contract to Player B just like a trade request. Player B looks at the terms and changes whatever he wants, then Player A can change the terms, then Player B can change them again, and so on. This negotiation process can continue indefinitely; it ends when one of two things happens:

  • either player cancels the negotiation (ending the contract offer)
  • both players accept the contract as negotiated

    Like the Secure Trade, once either player clicks on the "Accept" button no further negotiation is permitted; at that point all the other player can do is cancel or accept.


    Once both players have accepted a contract, it goes into effect, and both players get a contract document in their datapad.
    If there's an immediate exchange specified, it happens immediately, and if the contract was a one-time deal, it ends. (Notice that this implies that a Secure Trade -- the basic person-to-person exchange available in most MMORPGs -- is just a particular type of Player Contract.)

    If the deal is for later trade (either of goods or for a later provision of some service), then the game itself has to watch for this event to happen. As soon as Player B fulfills the contract's provisioning terms (either supplying money or goods into the Provision Account, or performing the required service), the contract is "activated." This means that the items in the Provision account are transferred to Player A, and the items in the Payoff Account (if any) are transferred to Player B. In a recurring deal, after the first trade any goods are taken from the providing player's bank vault -- to keep the deal going, you just keep putting the required number of those goods into your bank vault. (Note: It might be better to require that goods to be transferred are actually moved into the Payoff or Provision Account box in the contract document, rather than being taken from a player's bank vault, but either approach should work.)

    If this was a one-time deal, then the contract ends. If it's a recurring deal, then it can be activated again when Player B fulfills his side of the contract terms.


    A contract can end in a number of ways, but all terminations are of two types: successful or unsuccessful. Successfully terminated contracts just end; unsuccessfully terminated contracts trigger the agreed-upon penalty (if any).

    A contract terminates successfully when all the terms of the contract are met, including the terms for how the contract is to end. Assuming all goods and money transferred successfully, then if the contract was a one-time deal or if the timer expired on a limited or recurring deal, the contract ends successfully. Also, if the contract is a unilateral contract, then as soon as either player cancels the contract it ends successfully.

    A contract terminates unsuccessfully when anything happens in the game that prevents it from being terminated successfully. The most common ways in which a contract terminates unsuccessfully are:

    1. The service can no longer be provided. For example, if someone other than Player B destroys the object to be destroyed in a Destroy contract, then that contract is broken because there's no longer any way for Player B to successfully complete it.

    2. The goods can't be transferred either from or to a player. If you don't have enough of the agreed-on goods in the Provision or Payoff accounts when a transfer is scheduled, or you don't have the agreed number of credits in the Payoff account or your bank account, then you've broken the contract. Similarly, if you don't have enough room in your bank vault to receive goods to be transferred to you, then you've broken the contract.

    3. Either player cancels a bilateral contract. By definition a bilateral contract requires both players to agree to cancel it; if either player cancels a bilateral contract, then he's broken the terms of the deal. (Note that canceling a contract can happen either by clicking on the "Cancel" button on the contract document or by manually destroying the contract document in your inventory.)

    Regardless of how a contract ends, once it ends the contract document is deleted from the inventories of both players. It's also important to note that any goods or money in the Payoff and Provision accounts return to their owners when a contract is terminated (so there's no way to cheat the system). Also, if a contract is terminated successfully, the money that each player put into the Penalty Account is returned (since the contract wasn't broken, no penalty is enforced).
  • Thursday, March 18, 2004

    SWG: Jump to Lightspeed: Proposed Skilltrees

    [2008/05/06 note: The following was originally written (and later modified) well before Jump to Lightspeed, the space expansion to the base Star Wars Galaxies, was released. At this point it's mostly interesting as a kind of alternate-universe path that SWG might have taken, although I could swear some of the features described here actually did make it into JtL....]

    The subject of space-related skills has been coming up more often recently, so I thought I'd give it a thread of its own.

    I'll start things off with the latest version of what I've been developing.

    **** SKILLS ****


    • Master Spacehand
      • Piloting +5 (50)
      • Carrier pilot certificate
      • Navigation +10 (50)
      • Shields +5 (50)
      • Gunnery +10 (50)
      • Missiles/Torpedoes +5 (50)
      • Cargo Storage +5 (50)
      • Scanning +5 (25)
    • Starship Pilot Discipline ["Starship Pilot"]
      • Starship Pilot Specialist
        • Piloting +10
        • Command: /autodestruct
        • Cruiser pilot certificate
      • Expert Starship Pilot
        • Piloting +10
        • Destroyer pilot certificate
      • Advanced Starship Pilot
        • Piloting +5
        • Command: /overdrive
        • Frigate pilot certificate
      • Intermediate Starship Pilot
        • Piloting +10
        • Shuttle pilot certificate
    • Starship Navigator Discipline ["Starship Navigator"]
      • Starship Navigation Specialist
        • Navigation +10
        • Shields +10
      • Expert Navigation
        • Navigation +5
        • Shields +10
      • Advanced Navigation
        • Navigation +5
        • Shields +5
      • Intermediate Navigation
        • Navigation +10
        • Shields +10
    • Starship Combat Discipline ["Starship Gunner"]
      • Starship Combat Specialist
        • Gunnery +10
        • Missiles/Torpedoes +10
        • Command: /overload
      • Expert Starship Combat
        • Gunnery +5
        • Missiles/Torpedoes +15
      • Advanced Starship Combat
        • Gunnery +5
        • Missiles/Torpedoes +10
      • Intermediate Starship Combat
        • Gunnery +10
        • Missiles/Torpedoes 10
    • Starship Operations Discipline ["Starship Ops Officer"]
      • Starship Operations Specialist
        • Scanning +5
        • Cargo Storage +10
        • Command: /transponder [ID]
      • Expert Starship Operations
        • Scanning +5
        • Cargo Storage +10
        • Command: /sensorlock
      • Advanced Starship Operations
        • Scanning +5
        • Cargo Storage +15
        • Command: /sensorjam
      • Intermediate Starship Operations
        • Scanning 5
        • Cargo Storage +10
        • Command: /scan
    • Novice Spacehand
      • Piloting 10
      • Starfighter pilot certificate
      • Freighter pilot certificate
      • Navigation 10
      • Gunnery 10
      • Shields 10
      • Command: /dock


    • Master Starship Engineer
      • Schematic:
        • Structure: Space Station
      • Vehicle: Carrier
      • Starship Assembly +15 (75)
      • Starship Experimentation +15 (75)
      • Starship Hull Repair +15 (50)
      • Starship Avionics Repair +10 (50)
      • Starship Engine Repair +10 (50)
      • Starship Weapon Repair +10 (50)
      • Salvage +15 (50) (hulls)
    • Starship Design Discipline ["Starship Architect"]
      • Starship Design Specialist
        • Schematic:
          • Starship Hull: Carrier
        • Starship Weapons - Advanced
        • Starship Experimentation +15
      • Expert Starship Design
        • Schematic:
          • Starship Hull: Cruiser
        • Starship Avionics - Advanced
        • Starship Engines - Advanced
        • Starship Experimentation +10
      • Advanced Starship Design
        • Schematic:
          • Starship Hull: Destroyer
        • Starship Weapons - Improved
        • Starship Experimentation +15
      • Intermediate Starship Design
        • Schematic:
          • Starship Hull: Frigate
        • Starship Avionics - Improved
        • Starship Engines - Improved
        • Starship Experimentation +10
    • Starship Construction Discipline ["Starship Constructor"]
      • Starship Construction Specialist
        • Schematic:
          • Structure: Orbital Construction Yard
          • Vehicle: Cruiser
        • Starship Assembly +15
      • Expert Starship Construction
        • Schematic:
          • Vehicle: Destroyer
        • Starship Customization 2
        • Starship Assembly +10
      • Advanced Starship Construction
        • Schematic:
          • Vehicle: Frigate
        • Droid Construction Techniques
        • Starship Assembly +15
      • Intermediate Starship Construction
        • Schematic:
          • Vehicle: Shuttle
        • Starship Customization 1
        • Starship Assembly +10
    • Starship Maintenance Discipline ["Starship Repair Chief"]
      • Starship Maintenance Specialist
        • Starship Weapons Repair +20
        • Starship Avionics Repair +10
        • Starship Engine Repair +10
      • Expert Starship Maintenance
        • Starship Weapons Repair +10
        • Starship Avionics Repair +15
        • Starship Engine Repair +10
      • Advanced Starship Maintenance
        • Starship Avionics Repair +5
        • Starship Engine Repair +10
        • Starship Hull Repair +15
      • Intermediate Starship Maintenance
        • Starship Avionics Repair +10
        • Starship Engine Repair +5
        • Starship Hull Repair +10
    • Starship Salvage Discipline ["Starship Salvager"]
      • Starship Salvage Specialist
        • Salvage +15 (engines)
      • Expert Starship Salvage
        • Salvage +10 (weapons)
      • Advanced Starship Salvage
        • Salvage +10 (avionics)
      • Intermediate Starship Salvage
        • Command: /salvage
    • Novice Starship Engineer
      • Schematic:
        • Starship Hull: Freighter
        • Starship Hull: Shuttle
        • Starship Hull: Starfighter
      • Starship Assembly 10
      • Starship Experimentation 10
      • Starship Engine Repair 5
      • Starship Hull Repair 10
      • Starship Avionics - Basic
      • Starship Engines - Basic
      • Starship Weapons - Basic
      • Vehicle: Freighter
      • Vehicle: Starfighter

    **** DEFINITIONS ****

    Cargo Storage: Knowledge of efficient cargo handling procedures allows more cargo to be carried.

    Command: /autodestruct: If the command is repeated within 30 seconds, the vessel will explode. (Note: Only the designated captain of the vessel can give this command.)

    Command: /dock: Allows vessels carrying cargo or passengers to dock (with consent) to space stations or (with consent, or without consent if the captain is an overt of an opposing faction) other vessels.

    Command: /overdrive: Significantly increases maximum normal-space speed for a short time, but degrades the condition of your ion drives by a random but significant amount.

    Command: /overload: Significantly increases damage done by the next ship's weapon fired, but degrades the condition of that weapon by a random but significant amount.

    Command: /salvage: Searches and retrieves one advanced component, avionics system, weapons system, starship engine, or starship hull from a complex debris field in space. Only one salvage operation may be performed on a debris field.

    Command: /scan: Performs a scan of a targeted starship's cargo hold. With increasing skill may be able to detect smuggled cargo.

    Command: /sensorjam: Activates a sensor jamming system (if installed) to reduce the ability of other vessels to gain targeting lockons -- works like the Scout "/maskscent" command. (Does not affect capital ship targeting; may be defeated by the /sensorlock command.)

    Command: /sensorlock: Improves the likelihood of establishing a target lock on another starship.

    Command: /transponder [ID]: Allows the ship's ID transponder to be reset to a user-selected ID for three minutes. (Note: Any ship seen using using this feature is considered to be a pirate. Any vessel within range when the transponder reset expires will gain a TEF on the vessel that reset its ID code.)

    Droid Construction Techniques: Reduces the time and resources required to construct vessels and structures intended for space.

    Gunnery: Increases the base accuracy and damage of ship's blasters, lasers, ion cannons, and similar direct-fire weapons.

    Missiles/Torpedoes: Reduces the time required to launch missiles and torpedos and to deploy mines. (Speed, tracking accuracy, and potential damage are determined by the missile/torpedo/mine itself.)

    Navigation: Reduces the time required to calculate hyperspace coordinates, and improves the accuracy of arrival positions.

    Piloting: Increases maximum ship speed and decreases turning time. (Works like the Scout "Terrain Negotiation" skill.)

    Salvage: Increases the chances of finding a salvagable item as well as the value and quality of a salvaged item.

    Scanning: Works like the Scout "Creature Knowledge" skill; returns more information with higher skill levels. Also increases the chances of detecting contraband cargo aboard freighters.

    Schematic: Starship Avionics - Advanced: Create schematics for the best starship avionics packages.

    Schematic: Starship Avionics - Basic: Create schematics for simple starship avionics packages.

    Schematic: Starship Avionics - Improved: Create schematics for starship avionics packages superior to basic models.

    Schematic: Starship Engines - Advanced: Create schematics for the best hyperspace and sublight engines.

    Schematic: Starship Engines - Basic: Create schematics for simple hyperdrive and sublight engines.

    Schematic: Starship Engines - Improved: Create schematics for hyperspace and sublight engines superior to basic models.

    Schematic: Starship Weapons - Advanced: Create schematics for the best starship weapons systems.

    Schematic: Starship Weapons - Basic: Create schematics for simple starship weapons systems.

    Schematic: Starship Weapons - Improved: Create schematics for starship weapons systems superior to basic models.

    Schematic: Starship Hull - Carrier: Allows construction of ships based on very large multi-person hull whose primary purpose is to carry starfighters into combat. The number of starfighters carried will vary with the designer's Starship Assembly skill level.

    Schematic: Starship Hull - Cruiser: Allows construction of ships based on large multi-person hull whose primary purpose is combat.

    Schematic: Starship Hull - Destroyer: Allows construction of ships based on medium multi-person hull whose primary purpose is combat.

    Schematic: Starship Hull - Freighter: Allows construction of ships based on small multi-person hull whose primary purpose is to carry cargo.

    Schematic: Starship Hull - Frigate: Allows construction of ships based on small multi-person hull whose primary purpose is combat.

    Schematic: Starship Hull - Shuttle: Creates a schematic for construction of ships based on small multi-person hull whose primary purpose is to transport personnel.

    Schematic: Starship Hull - Starfighter: Allows construction of ships based on single-person hull whose primary purpose is combat.

    Schematic: Structure - Orbital Construction Yard: Allows a permanent construction yard to be built in the space above a planet. This yard is required to construct capital ships. The cost in resources to produce one of these will be extremely high.

    Schematic: Structure - Space Station: Creates a schematic for a permanent station to be built in the space above a planet. This is a large structure containing its own Bazaar, empty lots for residences and shops, and up to 100 docking ports for starships. The cost in resources to produce one of these will be... astronomical.

    Shields: Decreases time required to modify shield configurations, and may offer more intricate configuration possibilities. (Shield strength and recharge rate are determined by the type and quality of shield system purchased and fitted.)

    Starship Assembly: Allows the construction of components, vessels and structures intended for space. Higher skill levels allow more complex items to be crafted.

    Starship Customization 1: Allows the starship constructor to use a customization kit to alter the frame and trim colors of a starship's hull.

    Starship Customization 2: Offers more colors for customizing a starship's exterior.

    Starship Experimentation: Allows the improvement of components, vessels and structures intended for space. Higher skill levels improve various qualities (durability/toughness, effectiveness/damage, etc.) of crafted items.

    Starship Repair - Avionics: Increases ability to repair ship's avionics packages.

    Starship Repair - Engines: Increases ability to repair ship's hyperdrive and sublight engines.

    Starship Repair - Hulls: Increases ability to repair ship's hull. (Note: Capital ships with damage levels above 50% can only be repaired at an orbital construction yard.)

    Starship Repair - Weapons: Increases ability to repair ship's weapons systems.

    **** DESIGNER'S NOTES ****

    These two professions and the skills developed for them came out of an attempt to sit down and actually itemize the space-related skills seen in the five Star Wars movies we've seen so far:

    SKILL SETS (and their users)
    • Operations
      • Piloting (Han, Luke, Lando, Wedge, Anakin/Vader)
      • Navigation (Han, Chewbacca)
      • Weapons (Han, Luke, Vader, etc.)
      • Shields/Tractors (Han, Red Leader, Gold Five; Han, Obi-Wan)
      • Sensors/Jammers/Masks (Han; Boba Fett)
      • Fleet Operations (Dodonna, Ackbar)
    • Support
      • Starship Design (Han, Vader, Wedge)
      • Starship Repair (Han, Chewbacca, R2-D2)
    Starting with this list I tried to organize it into professions composed of four disciplines. I wound up with just about enough disciplines for three full professions, so after some tweaking I got:

    • Starship Crew
      • Starship Piloting
      • Starship Navigation
      • Starship Weapons
      • Starship Avionics
    • Starship Engineer
      • Starship Design
      • Starship Construction
      • Starship Repair
      • Starship Salvage
    • Starship Operator
      • Space Transport
      • Asteroid Mining
      • Cargo Smuggling
      • Piracy
    Since requiring "good" players to learn "bad" skills (piracy in particular) was objectionable to some people, I then further compressed these three skill sets from my version 2.0 space profession list down into the two-profession version shown here.

    PILOTING: Based on previous developer comments and available visuals, the Space Expansion is expected to be "twitch modified by type and quality of ship systems modified by character skills." What I hope that means is this: your maximum possible turn speed in a dogfight should be determined firstly by the type of starship you're piloting (an X-wing should turn faster than a Y-wing), secondly by the rating and condition/effectiveness of your ship's engines (an X-wing with great engines should turn better than an X-wing with lousy engines), thirdly by your Piloting skill level (a great pilot flying Ship X will turn better than an average pilot flying Ship X), and lastly by your real-world reflexes and Internet connection speed. This system is thus still "twitch," but it's also still an RPG.

    SHIP CERTS: I think it's appropriate to offer bigger and better ships to players who advance through the skill levels of the Starship Pilot discipline, rather than basing what ships you're permitted to fly on kill stats, or pure stick time, or faction points. Faction may control what type of ship you can fly, but it shouldn't be the only thing governing what size of ship you can fly (assuming there are both military and non-military craft in the same size class). Making better ships available through training motivates players to participate in the skills system and its related missions. This should encourage players to seek out rich game content rather than simply being the best at beating up on other players. There are other games that offer that mode of gameplay.

    SHIELDS: Although Shields could be considered an Operations skill, I put the this skill in the Starship Navigation profession because that profession needed something other than the Navigation skill, and because the Starship Operations discipline already had too many skills in it. Plus navigation and shield control are two of the things Han kept yelling at Chewbacca to do.

    SENSOR JAMMING: Electronic Warfare (EW) isn't really described much in the movies, but the official Lucasfilm documents clearly state that A-wings and other Rebel craft have a "sensor jamming" (i.e, ECM) feature. So I spent some time tweaking EW for play balance and "fun" factor. Since I added this skill making it harder to acquire targeting lockons, I also added a "/sensorlock" command (i.e., ECCM) to give the other guy a chance to hit.

    NOVICE SPACEHAND: The Novice Spacehand skills are the minimum necessary to let players get out into space for combat and commerce as soon as the Space Expansion ships. I didn't even really need Shields for novices; it just fit better numerically that way.

    NOVICE STARSHIP ENGINEER: Like the Novice Spacehand, the Novice Starship Engineer has enough of the fundamental skills to be useful in the Space Expansion right away -- he can build starfighters and freighters, equip them with basic engines, weapons and avionics, and fix the expensive bits when they take damage. (That would be hulls and engines. Weapons and avionics will have to be replaced or repaired by NPCs until there are Expert Starship Maintenance Engineers. This is for economic as well as skill balance reasons.) It's not certain that players will be able to create capital ships, but freighters and starfighters are pretty certain, so I started with them.

    ADVANCED ENGINEERING SKILLS: The Starship Engineer profession depends on a large number of "ifs." I have no idea if players will be allowed to build capital ships (not to mention space structures such as orbital construction yards and space stations). The Starship Engineer just looked really bare if those abilities aren't there! So I left them in... and yes, I certainly do hope they make it into the Expansion.

    STARSHIP ENGINEERING SCHEMATICS: I split engines, weapons and avionics into three groups of schematics: Basic, Improved, and Advanced to provide a motivation for players to progress through the skill levels of a discipline, in this case the Starship Designer. Also it's important to realize that all the schematic names I've given (such as "Starship Engines - Improved") are just placeholders for schematics to create specific items of that type whose names I can't guess yet. In the actual game you'd see schematics for actual components, such as "Advanced Ion Drive", "Quad Blaster Cannon", "Hyperdrive Computer Mark III", and so on.

    STARSHIP SYSTEMS: For Starship Engineering, I elected to split up starship systems into four parts: hull, engines, weapons, and avionics. This is a reasonable breakdown of a starship that fits neatly into the four-by-four disciplines and professions of SWG -- the design, construction and maintenance disciplines fit together very nicely this way. Even salvage works with this format.

    SALVAGE: Speaking of salvage, I've included this discipline because a number of people asked for it. On the principle that the most valuable item ought to be hardest to get, the novice starts off being able to salvage advanced components ("Look, sir -- droids!"), then works his way up to hulls. If you can salvage a hull, you could actually create a new starship from it, so it would be extremely valuable; that's why it's only available once you've achieved Mastery of the entire profession.

    CONSTRUCTION: A close examination of the Engineering disciplines will reveal that you can create and improve starship components in the Starship Design discipline, but you have to learn the skills in the Starship Construction discipline to actually be able to build starships. This is deliberate -- piling all construction skills into one discipline made that discipline far too powerful compared to the other disciplines in the profession. The split allows players to specialize, and (depending on how many space-related skill points are offered) will help prevent too many players from being both great Pilots and great Engineers.

    CUSTOMIZATION: Starship customization is limited to specifying frame and trim colors using a customization kit. I'd also like to see decals available. Best would be if the hull designer could specify different visual configurations of hulls and large subsystems through the Starship Customization 2 skill, but that may be asking too much.

    TRANSPONDERS: I don't know if ship ID transponders will be included in the Space Expansion. I hope so -- and if they are, then I hope the /transponder command as I've described it will be in there, too. It's not really necessary, but if piracy is meant to be a playable option, it sure would be helpful (and fun) to have.

    DOCKING: If space stations won't be in the game, and docking with other ships won't be permitted, then this command is unnecessary... but I'm hoping those things will be in the Space Expansion. Obviously there'll have to be careful attention paid to the game mechanisms for who is allowed to dock with whom and when. We don't want griefing (say it with me!), but the roleplaying possibilities inherent in being able to swarm aboard an enemy ship to try to capture it are just too juicy to ignore.

    FLEET OPERATIONS: I didn't get to implement Fleet Operations, so there's nothing here for the would-be Admiral Dodonna or Ackbar. I find that disappointing, but it just didn't fit into the scheme. Was that wrong?

    Sunday, March 14, 2004

    SWG: Jump to Lightspeed: Proposed Ship Systems

    [2008/05/17: Before Jump to Lightspeed was released, many of us playing SWG were eager to suggest ideas for what the space-based gameplay in a Star Wars MMORPG should look like. This was my contribution. I have no idea whether the notions here were read or considered by any of SWG's developers, but I found it very interesting that some of these ideas did seem to show up in Jump to Lightspeed.]

    (Note: Although I've adapted them greatly for use with SWG based on the Star Wars Databank, I'm indebted for many of the following concepts to Marc W. Miller, designer of the astonishingly good "Traveller" and "MegaTraveller" RPG systems.)

      • HULL
      • POWER
      • SENSORS
      • 9. FUEL
      • 10. ACCESSWAYS
      • 11. SECURITY
      • 12. CARGO
      • 14. DEFENSES
      • 15. WEAPONS
    Some details of each system:

    1. HULL

    Ship hulls should range from those barely large enough to move one living person all the way up to ISDs and beyond. There should be a selection of different hull types to choose from, including: needle/wedge*, sphere, saucer*, cylinder*, cone*, box, open frame, and irregular. (* indicates which hull types are capable of operating in planetary atmospheres.) The size of a hull should be proportional to its displacement in tons as well as to its cost (with some minor tweaks per hull type).

    Since SWG is space fantasy, rather than more "realistic" science fiction, I expect that most if not all hulls will be either needle/wedge (to land on planets). It might be nice to also have saucer and sphere hull types available to provide some choices, however. (The droid control ships from Ep. I were basically a saucer design... and as for spheres, wouldn't the Death Star have had smaller prototypes? /evilgrin)

    2. POWER

    Typical power plants for starships in science fiction are fusion reactors and antimatter, but apparently the main source of energy in starships in the Star Wars universe is the ion drive itself. Not only does this provide power for in-system flight (see the next section), it also supplies power to the other two types of drive (repulsorlift and hyperdrive), as well as for all other ship systems.

    Many sizes and power levels should be available when crafting (or upgrading) ships in the Space Expansion, with price proportional to power output (faster costs more) and inversely proportional to power plant size (smaller costs more). The ion drive (the Databank notes) puts out a certain amount of radiation, which could make working on active engines a hazardous task for shipboard engineers!


    Ships in SW use at least two kinds of locomotion: in-system, and interstellar. The in-system drive in SW is the sublight drive (of which the ion engine is one common type), and the interstellar drive is the hyperspace drive. Again, many types/sizes should be available. For example, the Hoersch-Kessel ion engine must be available (after all, it's where TIE fighters get their name -- Twin Ion Engine), but it would be helpful to have other kinds of sublight drive available as well to offer more design options. It might also be fun if the engines themselves were composed of subunits (that darn hyperdrive motivator!), but that might be asking a bit much. As usual, with increased power (for both normal space and hyperspace drives) the size and cost of engines should increase as well.

    Note that if atmospheric flight is implemented, this should be based on a third type of locomotion: the repulsorlift. (This is the antigravity technology that landspeeders and swoops use.)

    4. SENSORS

    They don't discuss this much in SW, but since you've got to be able to "see" to navigate, it needs to be addressed. Types of sensors provided should include: active electromagnetic spectrum (EMS) scanning (like "pinging" in submarine movies except that much more detail is provided), passive EMS scanning (ways to gain information about other ships or objects without giving away your presence), mass detectors, particle detectors, energy detectors, and computer systems that integrate all these sources into a coherent picture of your surroundings. Many types of these instruments should be available (at appropriate sizes and costs).

    The distinction between active and passive sensors is mostly needed to support piracy, where it might be helpful/interesting to allow ships to disguise themselves or hide behind objects. Wouldn't you like to be able to make yourself look like a different (less dangerous) kind of ship? How about hiding within some "noisy" space phenomena such as a solar corona, a nebula, or the tail of a comet? If the SE won't be detailed enough to allow disguising or hiding ships, then basic sensors ("is it there?") will be all that are necessary (if disappointing).

    One other reason to include better-than-basic sensors will be if ECM/ECCM ("sensor jamming" in SW-speak) are included in the Space Expansion. Dash Rendar's Outrider, for example, is a stock YT-2400 that (according to the SW Databank) has been upgraded in numerous ways that include "a highly illegal and highly effective sensors/countermeasures/stealth package."


    Again, this isn't discussed much in Star Wars, but again, it's reasonable to expect that they're required in a starship. One particular type of computer that we know is necessary is a navigation computer (navicomp), but really there should be computer capability distributed all over a starship. You'd want a main computer for handling user interaction (queries to the galactic database of objects, games like Dejarik, etc.), but pretty much every ship system should have embedded computer control and communications with the other ships' computers. These will allow control and status monitoring of ship subsystems without having to route everything through the main computer. Think of the main computer and many distributed computers as the brain and nervous system of a starship. Capabilities should vary, and be priced accordingly.


    Well, you've got to control your ship somehow! The bridge (or cockpit in a single-person ship) is the place on a ship to which all control information flows, and from which all command instructions exit. You can get as bare-bones as having nav sensors and a joystick and lift controls, or as fancy as a a bridge crew of 20 staring at a 3-D holotank. Prices, of course, will vary proportionally.

    For a starfighter, controls should be fairly simple. Millions of dollars have been spent trying to figure out the most sensible number and types of controls and their layout in modern fighter jets, but one design principle remains clear: simple is good. A complex arrangement may give you a high degree of control, but it may also become too complex in the middle of a major firefight.

    For larger starships, the canon suggests that control and monitoring functions are often split between multiple personnel. A small freighter might break down operations into Piloting and Navigation/Avionics, while a military vessel might have separate officers in charge of Piloting, Navigation, Engineering, Sensors, Weapons, and Communications, and a full-size military ships would include these officers, sub-officers, and numerous deckhands to serve as crew. In all these cases, separate monitoring and control activities should be routed to individual stations. (Note: I hope sitting down to operate a station won't result in our buttsliding into the void of space. That would be a Bad Thing.) [Historical note: "buttsliding" was our name for a bug in SWG where, after avatars were in a sitting position for a few minutes, they would visibly move several feet in a random direction while still in the sitting position. So if you were sitting in a chair, you'd now just be sitting on air; and if you were sitting on the ground... you'd appear to be sliding across the ground on your butt. This was corrected eventually, but only after many months of puzzlement that SOE would fail to fix such an obvious and disruptive bug.]


    This might be counted as a key system, but I count it as support since it won't be used all the time. Still, it's nice to be able to talk to someone when you really need to.

    Comm hardware should vary by size, distance capability, and cost. A related category is comm jamming equipment.

    The MegaTraveller RPG suggests that certain "channels" are available: ship ID (the "black box" transponder), hailing, distress, landing and takeoff, tactical, etc. This concept is easily extended to SWG and the Space Expansion, where "channels" for various purposes already exist. The existing chat channel system should work pretty well for this; we'd just create new channels for purposes as they come up.

    Some channels should probably be system-run persistent channels, however. Maybe when your ship pops out of hyperspace near Lok you should be able to open the planetary landing control channel (assuming Lok has one; not every "adventure planet" should) for any system messages. Maybe something like, "Attention travellers: due to increased pirate activity, the Imperial presence here on Lok has been stepped up for the duration of this emergency." Or possibly such messages should be more applicable to gameplay: maybe the landing control channel should give you specific instructions as to where you can go to land your ship and how to do it.

    The Space Expansion might even allow you to fill up your ship with cargo remotely. Instead of having to get out of your ship, walk to a Bazaar terminal, buy stuff, carry it home with you under your arm, and only then store it in your cargo hold, you should be able to activate the Sales channel to see the local listing of Bazaar items, then buy whatever you want (at a higher price than if you were using a Bazaar terminal) and have it "delivered" to your ship (as long as your ship has enough cargo/inventory space for it).


    This system includes all the technologies needed to preserve life and comfort in the vacuum of space. It features controls for: temperature, atmosphere, light, humidity, and artificial gravity. But SWG doesn't require any special handling of perishable or living items!

    For example, I've had several fish stuck in my bank vault for eight months now and they show no signs of starting to stink. The various flora in my private chemical and food crafting station have likewise been there for months without degrading in any way. So we probably won't have to start providing special environmental controls for living things or organic matter in SWG just because of the Space Expansion. (Bit of a shame, really, as "decay" of living items would be a way to reduce the number of database objects that players could probably accept. I'm not saying they'd like it -- just that they could live with it because it's realistic.)

    9. FUEL

    It may not be necessary to buy and use fuel in the Space Expansion. The "realism" would help generate a feeling of immersion in the world, and it might make for an interesting component to the economy if it's ever rare. But it could also be considered an annoying administrative impediment to just getting out into space to duel other players. In other words, having to have filling stations might be more trouble than it's worth. Another hint that starship fuel might not be included is the fact that power sources just aren't talked about much in Star Wars -- the Star Wars Databank has nothing to say on the subject. Presumably power in Star Wars is so easily and cheaply generated that it's just taken for granted that you can always have as much as you want for free. If the Space Expansion is implemented this way it would detract slightly from the "science fiction" feel of the game, but the "Star Wars" feel won't be reduced much (if at all).


    You shouldn't have to think about these very often, but you do need them: ramps, airlocks, iris valves, sally ports, hatches, docking clamps, etc.

    11. SECURITY

    If you think about it, security aboard a starship should always favor the defender. With sufficiently advanced computers you can recognize official crew and passengers and (since every access point has its own computer) control where they can go. Uninvited "guests" could trigger an intruder alert mode in which unfriendlies are led into passageways that are then locked off... or perhaps into airlocks that get opened to space. Security on larger vessels might also involve troops whose purpose is to repel boarders.

    12. CARGO

    If you're going to ship cargo (legally or otherwise) you'll need a place to store it. The two main issues here are how much space you need, and what kind of environmental controls do you want for that space. Prices are proportional to both of those. (For example, 500 cubic feet for shipping closed containers of nonperishable items might run you CR10,000, while 10,000 cubic feet for shipping live wampas and tauntauns might cost you CR200,000 (extra space plus environmental controls). Additionally you might want a few special compartments... these should be available, but at a considerable cost. This system also controls cargo bay operations (doors, loading, unloading, etc.).

    It may also be necessary/useful to allow respulsorlift-based cargo loading and unloading. (We might never see it, but that should be the notional explanation.)


    In anything larger than a one-person ship, you'll probably need berths for crew. Furthermore, if you're going to carry passengers, you'll need staterooms. You might want a range of staterooms, with costs to match (see any modern cruise liner's Web site for pictures showing how staterooms are laid out). You might even want special environmental options for non-human passengers... again, at a cost.

    14. DEFENSES

    Ship defenses seem to come in two flavors -- passive and active. The typical passive defense is armor; more and stronger armor means not only higher prices, but more mass to move (which should require larger engines, which cost even more money). This should work like personal armor in the ground game: condition points are taken primarily from armor, but a sufficiently powerful attack may cause "internal" damage. In ships, this would take the form of a reduction in the condition points of subsystems like engines and weapons. You might also lose hull condition points (assuming those are tracked separately).

    Active defenses can take a number of different forms. In SW, the classic active defense is deflector shields (not available on the original TIE fighter, of course), which should be available in different strengths and recharge times at different prices. The Star Wars Databank notes that shields come in two types: ray shielding and particle shielding. (This is probably another way of saying "energy" and "kinetic" shielding.) Ships, with their smaller power sources, typically generate several small shields in "arcs" around the ship; this allows the efficient use of shield power since it can be directed away from where it's not needed to where it's desperately needed. Other types of shield generators include personal shield generators (as found in SWG) and Gungan energy bubbles, and large, ground-based deflector shield generators, which are powerful enough to protect entire installations or even large orbital objects.

    15. WEAPONS

    Ah, the fun stuff. First of all, ships should use the "hardpoint" system to determine where and how many weapons may be attached structurally. Examples of ship-mounted weapons in SW that we know of (we can always make up more!) are ion cannons, light blaster cannons, turbolasers, and various missile and torpedo launchers.

    Mines, such as the ones Jango Fett deployed in the Genosian asteroid field in AOTC, could also be interesting weapons. If implemented, actuation modes could include contact, proximity, magnetic, and signal. (A contact mine detonates on contact; a proximity mine detonates when any appropriately-sized mass field gets close enough; a magnetic mine detonates when a metallic object gets close enough; and a signal mine detonates when it receives some number (1 or more) of external commands, either from a character-controlled key or from a command mine.) Detonation modes could include explosive, concussion, nuclear, and command. (An explosive mine just blows up with a standard destructive charge; a concussion mine produces a concussive wave; a nuclear mine produces a "dirty" radioactive explosion; and a command mine sends a signal to other mines that it's been activated.)

    (A note on command mines and mines with signal actuation systems: These are used together to create minefields into which ships can travel some distance before other mines explode. A signal-actuated mine can be set to require several signals before it detonates -- you could even have a signal-actuated mine that in turn detonates as a command mine to other signal-actuated mines. A ship entering this kind of minefield would pass through a first line of command mines; as it gets into the middle of the field it kicks off more and more signals until the "magic number" is met, at which point the entire field detonates. Very nasty.)

    Other systems that could be counted as weapons include the tractor beam projector and gravity well projector.

    Thursday, March 11, 2004

    SWG: All "Content" Is Not Equal

    JustG wrote:
    Problem #2: Lack of content.
    We are committed to releasing new dungeons in between each publish. We want these to be of the highest quality. The Geo Lab is a good example of what we are shooting for. The Corvette is next, and it is awesome. I'll go into more detail about what else is on the horizon later.
    Where is it written that "content" == "dungeons"?

    I recognize that a majority of SWG players are primarily (if not exclusively) interested in combat, and that development needs to focus on adding content that will keep these folks playing SWG.

    But it's my impression that SWG was never meant to be purely a fighting game. Crafters, explorers, merchants, and even entertainers were all to have useful roles to play. Maybe these roles were simply to support the fighters, but as I understood it the ultimate goal was a game that would allow players the flexibility to have fun in the ways they most enjoyed while supporting the combat-oriented community.

    So why is it that when "content" is discussed it seems always to be combat-specific? I don't mind seeing new dungeons, and combat redesigns, and revamped battlefields, and the many tweaks and fixes to existing combat rules... but where are the busy new crafthalls for the folks making the weapons and armor? Where are the new stages for dancers and musicians? Where are the strange new worlds for Scouts and Rangers to explore? Where are the new Player Contracts? In short, where's the content for non-combat players that's as cool as the new dungeons for combat players?

    One bit of good news here is the Droid Invasion. I applaud the attention now being given to this aspect of SWG gameplay. My hope is that along with the new features the droid constructors will also gain new content that allows them to use those new features. In other words, the new features will be nice but not exciting if all that Droid Engineers can do with them is build more new droids -- they need opportunities to feel that using their new skills matter within the game, just as combat players get to apply their skills in the new dungeons.

    Again, I am in no way suggesting that combat players shouldn't be getting new content. I think it's great that they are; I support that. What I'm suggesting is that some additional attention be given to creating similarly engaging content for non-combat players. These folks matter to SWG, too -- if too many of them walk because they're bored, where will fighters get their weapons and armor? Who'll buff them? Who'll heal their battle fatigue?

    The new content for fighters is great. Now it would be helpful to see that similarly exciting content is planned for the rest of the folks who support SWG.

    Friday, March 5, 2004

    SWG: Modular Architecture Crafting

    If a MMOG offers an Architect profession, it needs to allow players to actually perform as architects. Just allowing them to crank out copy and copy of the same five or six house styles is not good enough. Players need actual building design capabilities to truly exercise the kinds of skills needed to do architecture.

    I recognize that there are technical and other constraints that dictate building system designs. But I believe that a much more satisfying game experience -- for both architects and the users of buildings -- could be had by offering a building construction system that allows variation in the layouts of actual buildings.

    I'm not suggesting that we need something as freeform as the building construction system of The Sims (although that would certainly be appreciated!). I think a sufficiently dramatic improvement could be made by allowing modular construction.

    That is, buildings should be constructed from numerous different types of room modules according to specific rules. This would allow variation in completed buildings while not excessively altering the necessary 3D geometry information that allows mobile objects to move through these buildings once they're constructed in the active game.

    Examples of appropriate rules for the next-generation player building design tool are:

    • every module has a defined cost in resources and components
    • every module has a defined number of items whose storage is supported
    • major modules (big, tall, or special rooms) take up 1 lot
    • minor modules cost 0 lots
    • stairway modules cost 0 lots
    • buildings are limited to 10 modules
    • only one stairway module is permitted per building
    • modules can only be connected to each other by connection points (openings or doorways)
    • modules may not be placed inside other modules (except for stairway modules)
    • modules from different visual styles can't be mixed
    • buildings must have a "building type" chosen (to set the correct structure terminal)
    • a building plan with more than one open connection (to the outside) will not be approved
    • plans for approved buildings may be saved in the datapad for reuse in the design tool
    • the final cost in resources/components of any plan is the sum of the costs for all modules
    • the final number of storable items is the sum of storage counts for all modules
    • the maintenance rate of a building is calculated from its final number of storable items
    • an isometric view of a building as it's being designed is visible to potential customers
    There are numerous other rules that would have to be enforced -- these are just a few I thought of to give you the flavor of how the design tool should work. (And frankly, not all of them may be necessary -- if the 3D code allows it, it might be fun to allow player buildings to have more than one exit point.)

    Note that this more flexible design system usually already exists: the developers themselves have a general building design tool. It might be cheaper to modify this game development tool to an in-game design tool than to write an in-game modular building design tool from scratch. (Or it might not. The developer's building design tool may simply be a generic 3D modeling program, in which case an in-game building constructor could be a pretty complex thing to create.)

    At any rate, this is the more open-ended and interesting kind of building design system I'd like to see in a MMOG. It would be a major boon to aspiring architects (who desperately need a way to differentiate their products and should enjoy the creative challenge), as well as to those who purchase homes and public buildings and want a unique and consistent "look" that doesn't exactly duplicate that of thousands of other players.