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.

0. OVERVIEW

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.

1. CONTRACT TYPES

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:



Exchange

swap goods for goods or goods for money

Tribute

give another player goods or money for an unspecified reason

Transport

move items [or player characters] to a specified location

Delivery

give items to a specified player character or NPC

Recon

go to a particular location

Obtain

take possession of a specified item

Entertain

perform within 20 meters of a specified player character or NPC

Heal

heal or cure a specified player character

Buff

temporarily improve the stats of a specified player character

Craft

create a particular kind of object, possibly with certain stats

Hack

bypass the electronic security of a container or item

Destroy

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

Guard

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

Bounty

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

Marriage

marry another player character [allows for divorce, too]



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

2. CONTRACT PERIODS

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)
3. PLAYER-SPECIFIED CONTRACT TERMINATION

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.

4. VARIETY OF PENALTIES

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.

5. CONTRACT CREATION

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.

6. CONTRACT NEGOTIATION

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.

    7. CONTRACT RESOLUTION

    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.

    8. CONTRACT TERMINATION

    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 ****

    SPACEHAND PROFESSION

    • 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

    STARSHIP ENGINEER PROFESSION

    • 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:

    v2.0 DISCIPLINES
    • 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.)

    SHIP SYSTEMS
    • KEY SYSTEMS
      • HULL
      • POWER
      • LOCOMOTION
      • SENSORS
      • COMPUTERS
      • BRIDGE & CONTROL
    • SUPPORT SYSTEMS
      • 7. COMMUNICATIONS
      • 8. ENVIRONMENTAL
      • 9. FUEL
      • 10. ACCESSWAYS
      • 11. SECURITY
    • SPECIALIZED SYSTEMS
      • 12. CARGO
      • 13. ACCOMODATIONS
      • 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!

    3. LOCOMOTION

    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."

    5. COMPUTERS

    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.

    6. BRIDGE & CONTROL

    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.]

    7. COMMUNICATIONS

    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).

    8. ENVIRONMENTAL

    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).

    10. ACCESSWAYS

    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.)

    13. ACCOMODATIONS

    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.

    Thursday, February 26, 2004

    SWG: Higher Education


    I dreamed up a new profession some time back that I'd like to bring out of mothballs. Namely, I'd like to see a Higher Education profession.

    It never has made much sense to me that the Artisan profession is the required starting point for both theoretical and hands-on advanced professions. Some people naturally prefer Thinking, and some prefer Doing. Both are valuable ways of dealing with the world, but these approaches require very different kinds of education. How does it make any sense that both Chefs and Droid Engineers are based on the Artisan profession?

    The Artisan profession is mostly a hands-on profession concerned with Doing things. So let's be consistent about that -- let the Artisan profession teach the basic skills needed to do the relatively simple hands-on crafts from which extend the more advanced (but still similarly hands-on) professions of Chef and Tailor.

    The problem is the Engineering discipline. This doesn't belong in the Artisan profession! What we need is a new Thinking-specific profession that includes an Engineering discipline (and three other disciplines).

    The first step is to replace the existing Engineering discipline in Artisan with something like a Machining discipline. The skills of this discipline would allow you to increase your maximum number of Action points or decrease all Action point costs (to simulate an Artisan's improvements in manual dexterity). Another possibility would be a Mechanic discipline. Not only would this allow for a much more enjoyable crafting experience for vehicles (not to mention some great extra features for vehicles!), it's a more appropriate starting discipline for the Shipwright profession.

    The next step is to create a counterpart to the hands-on Artisan profession, which would be would be the more theory-oriented Higher Education profession. This new starting profession would provide basic research and application skills that act as foundation skills for the advanced/elite professions requiring more education such as Droid Engineer. Other disciplines within the Higher Education profession would support other existing professions such as Architect and Doctor, as well as new professions such as Industrialist and Scientist.

    The Higher Education disciplines that make the most sense to me are Engineering, Social Sciences, Life Sciences, and Arts. Starting with those disciplines, some of the existing and new advanced and elite professions might break down like this:

    Engineer *Engineering [Higher Ed]
    ArchitectEngineering [Higher Ed] + Arts [Higher Ed]
    Miner *Engineering [Higher Ed] + Surveying [Artisan]
    Droid EngineerEngineering [Higher Ed] + Machining [Artisan]
    Weaponsmith, ArmorsmithMachining [Artisan]
    MerchantBusiness [Artisan]
    Chef, TailorDomestic Arts [Artisan]
    Journalist *Social Sciences [Higher Ed]
    Industrialist *Social Sciences [Higher Ed] + [Artisan]
    Scientist *Life Sciences [Higher Ed] + Social Sciences [Higher Ed]
    DoctorLife Sciences [Higher Ed] + [Medic]
    Bio-EngineerLife Sciences [Higher Ed] + Hunting [Scout]
    MusicianArts [Higher Ed] + Musicianship [Entertainer]
    DancerArts [Higher Ed] + Dancing [Entertainer]


    * = possible new profession

    A sample skill tree for the Higher Education profession might look like this:

    • PH.D. (10 additional skill points)
    • ENGINEERING (Master of Engineering)
      • Physics (improves effectiveness of armor and weapons)
      • Computer Science (improves effectiveness of droid components)
      • Mechanics (improves effectiveness of harvesters)
      • Mathematics (improves effectiveness of crafted components)
    • LIFE SCIENCES (Master of Life Sciences)
      • Medicine (improves healing effectiveness)
      • Zoology (improves creature identification skills)
      • Botany (enhances food creation stats)
      • Chemistry (improves effectiveness of engineered tissues)
    • SOCIAL SCIENCES (Master of Social Sciences)
      • Military Science (10% bonus to all damage done when grouped)
      • Economics (allows access to Bazaar sales statistics)
      • Political Science (reduces city maintenance costs and taxes paid by 20%)
      • Linguistics (10% bonus to all interactions with factional NPCs)
    • ARTS (Master of Arts)
      • Architecture (allows customization of buildings)
      • Sculpture (additional image customizations)
      • Music (improves effectiveness of music)
      • Performing Arts (improves effectiveness of dancing)
    • NOVICE STUDENT (reduces cost of skills training by NPCs by 5%)

    SWG: Jump to Lightspeed: Summary of Ideas


    [2008/05/06 note: Although version 4 of this document was posted on February 26, 2004, the original version was posted on SOE’s official pre-launch forum in late 2002, and most changes were merely cosmetic. It’s sort of fascinating to see how many of the concepts described here made it into the Jump to Lightspeed expansion as actually implemented.]

    THE NATURE OF SPACE
    I expect that "space" will be implemented as new areas that you can only reach either by taking off from a planet, or by emerging from hyperspace. Each planet will have a space area "around" it, and there may be other space areas that exist independently of planets. From a space area, you will be able to select a new destination from your ship's navigation system: either landing on a particular planet (if you are in a space area around that planet), or entering hyperspace to travel to a new space area. (Note: It is extremely unlikely that you will be able to travel through a planet's atmosphere to land "manually," due to the potential for griefing. Atmospheric flight remains a feature that most players want, however, so if it can be included it'll make a lot of people very happy.)

    OBJECTS
    Some space areas should contain asteroid fields. It should be possible to land on sufficiently large asteroids (for mining, exploration, combat, etc.), and it might be intereting to permit houses to be placed on asteroids, although only special new "enclosed" types might be allowed. Allow gravity and sensor-jamming effects near stars (but also allow "burning up" if one gets too close to a star). Allow the "Kessel Run," and possibly something like "pod racing in space" where the goal is to navigate through an obstacle cource in the least time. Gas clouds, comets, and other stellar and interstellar objects should have appropriately entertaining effects on ships.

    SKILLS
    There should be a number of new skills added with the Space Expansion, possibly creating up to three new professions. The basic skills necessary for crafting ships, flying them, fighting in them, fixing them, and transporting cargo in them should be available as new starting professions. Appropriate skill trees (disciplines) within the new professions could include: Spacecraft Piloting, Spacecraft Navigation, Spacecraft Combat, Spacecraft Design, and Spacecraft Construction/Repair. (Please see my SWG: Jump to Lightspeed: Proposed Skilltrees essay for more details on one way to implement these new skills.)

    SHIPS
    You should be able to walk around inside ships (especially capital ships, if implemented) just as you can walk around inside a house. (This is probably the single most popular player request.) A wide mix of ship types from the movies and Expanded Universe (EU) should be available to players. Among the most requested types of ships are: X-wing, Y-wing, A-wing, B-wing, TIE Fighter, TIE Bomber, TIE Interceptor, Z-95 Headhunter, YT-1300 (Millenium Falcon), YT-2400, Firespray-class policecraft (Slave Zero), Naboo starfighter, and Lambda-class shuttle. (Note: I'm well aware that, following the Star Wars universe timeline, not all of these ships are available in the period during which SWG is set. I've chosen to list these ships along with the others in case the developers feel that perfect fidelity to continuity is less important than having a rich fleet of starships to choose from.)

    SYSTEMS
    Spacecraft should be complex structures composed of multiple subsystems. Each subsystem should be a named physical unit that has attributes (quality, condition, max speed, damage type, etc.), and with a few exceptions and limitations can: 1) take damage, 2) be repaired, 3) be replaced, and 4) be upgraded. The key systems are: hull, engines (hyperdrive and sub-lightspeed engines, as well as power and fuel systems), weapons (lasers, ion guns, missiles/torpedoes, mines), and defenses (deflector shields and armor). Other possible starship systems could include: computers (including navicomp), sensors (and sensor-jamming or -faking devices), communications (and communications jammers), accomodations (crew berths and passenger staterooms), security (if ships can be boarded), cargo bays, and escape pods. Ships, like other in-game structures, will require regular maintenance payments in addition to repair, refit, and refueling costs. Speaking of refueling, some appropriate method of fueling starships will need to be devised that takes numerous points into account: refueling costs should be a near-constant price of engaging in spaceflight, but should also recognize that Star Wars is a high-tech universe (and thus presumably has high-tech energy energy sources); what happens if you "run out of gas" in space?; can you find fuel somewhere other than planets?; should there be different types of fuels with different effects?; and so on.

    USER INTERFACE
    Normal space flight maneuvering and weapon firing will be controlled by mouse, probably with some keyboard controls as well (such as for thrust/braking). Joystick support would be welcome. The default button and key action assignments should be consistent with those provided for vehicle control (once that feature is implemented), but all keys and buttons used in the Space Expansion should be fully remappable. Displays should be uncluttered and easy to understand at a glance, with an audiovisual look-and-feel appropriate to the origin of the ship's electronics (in other words, a TIE fighter's HUD should look and sound different from that of an X-wing). Icons for ship-related functions and commands should be added to the existing list in the Actions screen. A ship's radar display should use appropriate color-coding and symbology to indicate the relative positionl, facing, lockon status, and faction of nearby ships.

    COMMUNICATION
    A way to communicate with other ships that fits within continuity is vital. Players must be able to transmit nav coordinates (as waypoints) to each other's flight computers so that they can remain in formation after flight through hyperspace. It should be possible to target other ships or groups of ships on specific comm channels and send short pre-composed commands ("cover me!", "he's on your six!", etc.) through a hotkey. For players with sufficient connection bandwidth, voice communication would be appreciated.

    FLIGHT
    Flying spacecraft will be "twitch"-based rather than purely RP. (Note: This has already been called "likely" by the developers, and is supported by existing video of game action.) In-flight maneuvering will be controlled by the player in normal space, while hyperspace flight plans will be pre-programmed into the navigation computer. Certain player skills or racial stats may affect some in-flight actions (turning speed, defensive bonuses, targeting bonuses, etc.). In particular, a Jedi player should receive bonuses to ship control and combat proportionate to his Jedi rank. For faster-than-light travel to another star system through hyperspace, the time required to correctly program a navigation computer should increase with distance to the target system and decrease based on the quality of the navigation computer and the Navigation skill of the player doing the programming. "Hasty" navigation should be possible, but should increase the chance of exiting from hyperspace in an unplanned location. There should always be some inaccuracy in where a ship exits hyperspace; this inaccuracy can be minimized (though never completely eliminated) by improving one's Navigation skills. Ships exiting hyperspace should never intersect an existing spacecraft, although a badly calculated (or unlucky) course may result in exiting hyperspace dangerously close to stellar objects such as asteroids and stars. (Question: should ships emerge from hyperspace with their facing and speed intact? Or should they emerge dead still and have to turn and speed up to go anywhere?)

    COMBAT
    Ship-mounted weapons should include those from the Star Wars movies; laser cannons and ion cannons in particular. Lasers should cause damage to other ships, while ion cannons should degrade the effectiveness of engines (and possibly other electronics). Various types of missiles (small, fast, variable accuracy), torpedoes (big, slow, highly accurate), and mines (contact, proximity, and time-delay) should be available to make tactics more interesting. Multiplayer ships larger than starfighters may have direct-fire turrets or batteries that can be controlled by a player. If it's possible to walk around on some ships, then let ships be able to dock with each other in space, and allow for boarding parties. Faction should determine whether a player-controlled ship can fire on or dock with another player-controlled ship without the targeted player's consent. (The rules for firing on or docking with NPC ships may vary slightly from this, but faction should still be considered.) The "lock-on" system currently used for ground combat should be sufficient for direct-fire weapons, but certain other weapons and commands should require "active" lock-ons in which it's not enough to merely target some object; your ship's targeting system must then acquire its own target lock. Once this is done, you should be able to use "fire-and-forget" weapons such as missiles and torpedoes, as well as attempt to break another ship's sensor jamming.

    CRAFTING
    Ships should be made of standard sets of parts, which must be combined using schematics by someone with skills from the Spacecraft Construction discipline -- basically they're built using the same system by which architects build planetary structures. (They should also be able to build spacecraft-specific furnishings as architects do for houses. "Hey, where does this Nemoidian Birdcage go?") Some parts necessary for spacecraft should be relatively simple components that require Engineering skills from the Artisan profession (so they'll have a useful part to play in the Space Expansion). Spacecraft systems can be repaired and/or replaced, but you can't add new systems without a new design. A ship's owner should be allowed to place "decals" (selected from a very comprehensive pre-built list) on that ship to allow distinctiveness. (Or the owner might have to find a Spacecraft Constructor to do this in the same way that an Image Designer is necessary to change the appearance of player characters.) Ship hull types available should be those that can be purchased by players and PAs. Multiple configurations for certain hull types is a very popular player request -- players want to be able to have distinctive vehicles. Players might not be permitted to craft capital ships, such as Nebulon-B frigates, Mon Calamari cruisers, and Imperial Star Destroyers, but the rare inclusion of these ships in some way (possibly NPC-commanded, or controlled by Live Team members for special events) would be hugely entertaining in creating that "Star Wars" feeling. If capital ships can be constructed by players, require that construction take place in (probably orbital) spacecraft construction yards.

    COMMERCE
    Freighters should be one of the available ship types that offer some number of "spaces" for carrying items (similar to item counts in houses). If being able to move around inside ships is not implemented, then there should be a communications subsystem that allows goods to be bought and sold electronically and "automatically" moved into and out of the cargo hold. It should be possible to carry passengers, although this system will need to be carefully constructed to minimize grief play (e.g., "kidnapping" other players instead of taking them where they want to go). If walking around on ships is implemented, it should be possible to craft starships with multiple staterooms of varying quality; NPCs and players could then require appropriate levels of accomodation when traveling (and pay accordingly). It should be possible to carry vehicles on board a ship, cargo space permitting. Finally, one of the most-requested features has been hidden cargo spaces (for smuggling).

    MISSIONS
    The Space Expansion should open up many new missions that occur in space or require objects or skills specifically related to the Space Expansion. Missions that require space travel or space-related skills should be selectable at terminals related to space assets: starports, space stations, and communications terminals inside ships themselves. There should be a good mix of missions: escort, rescue, and straight faction-based combat for those who want to fly starfighters primarily, and delivery missions (including smuggling) of freight, cargo, and passengers. (Note that "freight" is merchandise you transport for someone else for a flat fee, while "cargo" is merchandise you speculatively buy on Planet A and sell on Planet B in the hope of making a profit.) Other missions should be available for those players who want to work in space but who either can't afford or don't want to own and operate their own spacecraft -- survey, salvage, and exploration missions, for example. Space Expansion missions should also be integrated into the "player missions" system when/if that's implemented.

    OTHER POPULAR CONCEPTS
    The possibility of large and complex capital ships being available as places to adventure is broadly and strongly supported. Space stations would also be nice to have. Another concept with fairly vocal support (but some disagreement) is that military-class ships should only be available to overt faction players. Astromech droids (like R2-D2) should be allowed to improve the status of and enhance the effectiveness of ship systems. There should be minigames such as Dejarik (the game popularly known as "holochess") available for playing on multiplayer ships. Ships should be able to carry ore from asteroid mining operations. Ships should broadcast ID codes (possibly with IFF) from a "black box" transponder, but it might be possible to alter that ID code (for a high price, a short time, and with severe penalties if caught). Capital ships destroyed in space should leave behind some wreckage out of which a few useful items might be salvaged -- possibly a "/salvage" command similar to the "/forage"-type commands could be applied.

    UNLIKELY WISH LIST
    Other options not really expected but that would be nice to have include: atmospheric flight and manual landing (not likely given the programming effort required and opportunity for griefing), planetary bombardment (needs anti-griefing limits that may make it too unrealistic), mine-laying, PA ownership of capital ships, and commodore- or admiral-level control of multi-ship fleets.

    Friday, February 20, 2004

    SWG: Modified Jedi Progression


    If we're going to rethink what Jedi do, we need to spend a little time thinking about who Jedi are. What is it about Jedi that really makes them distinct from everyone else, and how can we incorporate these differences into SWG?

    I. GENERAL CONCEPTS

    There is a simple and well-known two word sentence that tells you everything you need to know about Jedi: "Power corrupts."

    Power is seductive; when you have it, you want more. For some people, power changes from being a means to some end to being an end in and of itself. Instead of using power to achieve a goal, power is used to gain more power. When this happens, the person or institution wielding that power has become corrupt.

    What makes this corruption so seductive is that it's always so easy to rationalize the quest for more power. "Well, if it [a dictatorship] works...." "Join me, and together we can rule the galaxy as father and son."

    Some people are able to resist this temptation. For whatever reason, some people are so constituted as to recognize the importance of limits to individual power, and to voluntarily impose those limits on themselves, even at those times when greater power is most desirable.

    Not everyone can be so strong. Sooner or later, everyone succumbs to the whispers... "Take your Jedi weapon and strike me down with all of your hatred." "I wasn't strong enough... but I promise, I won't fail again."

    Power corrupts.

    II. JEDI AND POWER

    In the world of Star Wars, both these elements of power and choice are always present for a Jedi. Training in the Force confers ever greater power on a person, but with that power comes the responsibility of choice -- not merely of when and how to use the power of the Force, but the more difficult choice of when not to use it.

    Those who choose restraint when temptation beckons remain Jedi. Those who yield take their first step down the path to the Dark Side.

    Ultimately, being a Jedi is quite simple. The lessons take many forms, and can be painfully hard to learn, but in the end there are only two lessons.

    The first and easier lesson is how to use the Force. The second and vastly more difficult lesson is when to use the Force. When you're a Jedi, every situation is an opportunity -- and a challenge -- to learn these two lessons.

    Progression through the ranks of the Jedi is based on the student's demonstration of ability and understanding of these two lessons. Much attention is given to learning Force abilities and improving in their use. This obvious manifestation of the Force is what most people see, and what most Jedi novices focus on (since without ability there's nothing to control). But as a Jedi advances, he must begin to show restraint in the use of the Force and demonstrate that he understands why this restraint is necessary.

    The Jedi trials are designed to test the Jedi's mastery of these two aspects of the use of the Force. Within each level, a Jedi is expected to learn and demonstrate ability in a defined set of skills. When the learner's teacher feels the student has advanced sufficiently to earn the next rank, a mastery test will be administered in which the student's understanding of when to use the Force is assessed along with proficiency. Students who fail to demonstrate a proper understanding of when and why to limit one's use of power, or who fail key proficiency tests, will not be advanced.

    III. JEDI IN STAR WARS GALAXIES

    Bearing the above in mind, there are two sets of features that need to be implemented. One is the system of Jedi powers; this is already in the game and looks OK, so no need to change this. The other necessary feature is the set of trials designed to test the student's understanding of the proper use of Jedi powers.

    The first item -- Force powers -- has already been implemented. But when to actually use these powers should also be considered when generating answers to the list of developer questions about Jedi.

    NPCs players might interact with throughout the quest

    A Jedi goes wherever she's needed in the service of freedom. (Or, in the case of Dark Jedi, in the service of order through force.) In other words, there's no such thing as a "typical" Jedi interaction. Jedi must speak and work with people from all walks of life, from the high to the low, from warriors to scholars to crafters to entertainers, from kings to farmers and all points in between -- whatever it takes to accomplish their mission.

    Progression quests and trial ideas

    Typically a Jedi trial is a requirement for the student to confront some menace. In most cases this menace should take some external form that mirrors the student's greatest internal temptation. This will test the student's readiness to responsibly use the greater powers granted at the next level of mastery.

    Within SWG, some of a player's typical behaviors should be recorded, then analyzed when a trial is needed. If a player has a habit of attacking anything and everything with his lightsaber no matter what his surroundings, the quest might be to locate and eliminate a monster threatening some villagers... except that the "monster" is actually just the manifested dreams of one of the village's children, and destroying the monster by whipping out one's lightsaber will cause the student to fail the test. (The correct answer would be to use Force Awareness to locate the true source of the disturbance, then use the appropriate non-combat Force power to solve the real problem.)

    Similarly, a player whose typical reaction is to run from perceived danger might be required to risk death by actually battling a real monster. A player whose dedication to the Light side is to be tested should be required to refrain from use of the Force rescue friends or even to save her own life; a Dark side player would fail a test by showing mercy to a weaker opponent.

    In all cases the test of Force understanding will take the form most likely to require the student to act against his nature (as determined by monitoring what the player typically does). Only when the student can control himself can he be trusted to control his use of the power of the Force.

    What skills a Jedi might use on these quests

    The usual lot: Force Awareness, Force Push, Force Pull, Force Speed, Force Heal, Force Reflection, Force Grip, Force Absorb, and Force Lightning are the ones that come to mind.

    Quests for different profession types, for instance, social quests, explorer quests, combat quests, etc.

    I don't think there should be different quests based on a player's other professions. Different types of quests for different types of other players are fine, but they should all be thought of and structured to be Jedi quests.

    To paraphrase West Side Story: "When you're a Jedi, you're a Jedi all the way."

    Jedi Titles earned through the quests from Force Sensitivity to Jedi master

    Guardian, Padawan, Sentinel, Scholar, Consular, Knight, Master, Savant, Dispatch, all with "Jedi" or "Force" stuck in front. In particular I'd like to see four separate lines (disciplines?) through the Jedi skills -- maybe Offensive (Grip, Lightning), Defensive (Reflection, Absorb), Manipulation (Push, Pull, Speed), and Sensitivity (Awareness, Healing). Each discipline would have its own trainee titles for each the four levels -- for example, the titles of the Sensitivity discipline (beyond the "Force Sensitive" novice skill box) might be:

    Jedi Initiate -> Jedi Seeker -> Jedi Scholar -> Jedi Savant

    Another possibility would be to restrict Force users from advancing more than one level above any existing level. That is, you wouldn't be able to learn a Level Two skill until you'd learned all four Level One skills. Additionally, once all Level One skills are learned it would be necessary to pass the appropriate trial to open up the Level Two skill boxes.

    In this case, progression through the skill tree would be keyed to the well-known level titles (plus a new title for level 2):

    Force Sensitive -> Jedi Padawan (1) -> Jedi ? (2) -> Jedi (3) -> Jedi Knight (4) -> Jedi Master

    Still, it would be interesting to see Jedi recognized for something other than fighting prowess (although all Jedi should be required to demonstrate fighting skills). I find the notion of progressing from Jedi Scholar to Jedi Savant fascinating!

    Sunday, February 15, 2004

    SWG: The Imperial Stormtrooper Water Ballet Team


    So far I definitely approve of the Imperial crackdown -- it's a much-needed boost to the Star Warsy-ness of this game. I thought I'd share a couple of the experiences I've had that lead me to this conclusion.

    My first sign that something was different came a few minutes after I logged in for the first time following the Imperial Crackdown code patches. I had just stepped outside the front door of my house to check on a wind harvester when I heard an odd sound... the sound of a starship. "That's funny," I thought. "How can there be ships out here? I'm nowhere near a city."

    As I looked around, I realized that a Lambda-class shuttle had just landed a few meters away. Suddenly out from the back of the shuttle poured a column of Imperial stormtroopers!

    As the shuttle took off, I ran back to my house. (I'm neutral, but these guys might not appreciate that, I thought.) From my doorstep, I could see the troopers lined up in a formation, not moving. They didn't seem inclined to open fire on me, and they didn't appear to be coming after me to check my ID, so after a minute or two I calmed down and went back to my usual routine.

    Following this I needed to go to Tatooine. While I was there I visited Mos Espa... but I don't recommend it. First, it took so long to log in there after the shuttle trip that I thought my link had gone dead. When I finally appeared, there were so many Imperial troops milling around in the street that my frame rate plummeted to approximately 1 frame per second. Trying to move was so painful I headed back onto the shuttle as quickly as possible. It was nice to see the strong Imperial presence, but the frame rate just can't survive the number of troopers in Mos Espa.

    OK, now jump forward a day. I'm back in my home on Naboo after the trip to Tatooine, and I've just logged back in. I walk outside to check on my equipment factory when I see five or six Maulers on the other side. I try to sneak up to my factory, hoping that the Maulers (like Trade Avengers and swamp rats) will continue not to notice me like they haven't for the past few weeks... but it's no good; they aggro on me and start firing.

    I can just barely hold my own against a full Mauler if I'm lucky, but there were a pair of them after me. I raced back to my house... when with a shock I realized the stormtroopers were still there.

    And then a funny idea occured to me. On my way back home from Tatooine a different group of Maulers had chased me into a nest of shaupauts. After I'd managed to get away I noticed that the shaupauts had attacked the Maulers.

    Now here was another bunch of Maulers after me... and another group of mobs who could protect themselves was nearby. "Hey, maybe stormtroopers don't like Maulers, either," I thought, and with the Maulers on my heels I changed course and ran right into the middle of the stormtrooper formation.

    In seconds, my prayers were answered as every trooper opened fire. Weapons blazing, the troopers converged on the Maulers. After thirty seconds of brightly colored laser bolts filling the air, both Maulers were smoking corpses on my front lawn. Briefly raising their hands into the air in celebration, the stormtroopers then calmly returned to their staging area by my front door.

    "Great!" I thought. "I can just keep leading the Maulers back here, and the stormtroopers will finish them off for me." But no. After a moment's pause, every stormtrooper continued walking... straight into the river that flows in front of my house. In seconds, what had been a crack squad of death-dealing Imperial warriors had become a water ballet team, complete with synchronized swimming moves straight out of an Ethel Merman movie.



    Fortunately for me the stormtroopers had called in a few of their pals to the other side of my house. In a small group were a couple of lieutenants, an exterminator, a swamp trooper, and a random stormtrooper. So for thirty minutes I led respawning Maulers to their doom -- I'd wander over, get one or two of them to aggro on me, and lead them back to the Imperials who made short work of them. Eventually the Maulers quit respawning and I was able to manage my factory in peace.

    Bottom line: I'm no longer afraid of being harassed by Imperial troops. Rather than fearing them, I now regard these stormtroopers as my own personal home security system. Cool.

    One other funny thing happened, however. As I was checking some harvesters on the other bank of the river (where the Imperial water ballet team was still in action), a rogue faamba appeared. Given my pretty good /maskscent I wasn't worried for my personal safety, but I did notice that the swimming stormtroopers seemed to be getting closer and closer to the faamba.

    Sure enough, they finally got a little too close for the faamba's comfort, and he waded into the water. Suddenly the stormtroopers realized their peril and opened fire. Oddly, they were able to do so while in the water -- they'd stand up as though they were on land, fire one shot, then go back to swimming.



    Eventually the faamba succumbed to the massed fire of the stormtroopers... at which point they went right back to their synchronized swimming routine.

    So developers -- for all the grief and whining you get from this board, here's one player who's fairly pleased with what you've accomplished in the Imperial crackdown. Please keep on coming up with such interesting NPC behaviors!

    Especially if they help me stay in business.