Wednesday, June 30, 2004

SWG: Jump to Lightspeed: Advanced Sensor Ops +

Janson wrote:
This may be something that gets included with capitol ships, though. It would be necessary for them, really.
Flat, how would you figure this would be implemented?
You're right about the applicability of this idea to capital ships, and I should have said so. Let me try it now:

This stuff is really intended for multi-person ships, and not for starfighters. Basically the only sensor stuff a starfighter needs is an integrated radar/ID transponder analyzer to recognize other ships, an ID transponder of its own, and possibly a sensor jammer (although all this is for is to make it harder for other ships to get lockons). More advanced sensors are really only needed on capital ships and certain highly tweaked freighters.

Of course, if other types of ships are ever introduced, such as research ships or safari vessels, then they'd probably want more complete sensor packages, too. But the full set of sensors (basically everything I proposed in my original message) would really only be seen on purely military craft. (And perhaps smuggler ships and "pirates" as well!)

As for how to implement this idea, there are three key areas that would need code:

  • ships must have the physical characteristics described (mass, radiation, etc.)

  • ships must have sensors that can read these characteristics of other ships

  • space features must block or distort some of these characteristics from sensors
You could get more complicated with the idea of ships having detailed characteristics that can be detected, but these are the essential elements that would have to be implemented in the Jump to Lightspeed code. The good news is that once you have these three essential concepts coded to any degree, adding new types of characteristics (and new sensors to reveal those characteristics) would be relatively simple.

Easy for me to say, of course.

SWG: Jump to Lightspeed: Advanced Sensor Ops

I'd like to see a detailed physics model that allows ships in Jump to Lightspeed to use stealth and disguise.

Consider the ways a spaceship could be detected or identified (these are just some examples I dreamed up):

  • Active scan
    • Physical
      • radar
      • laser reflection (ladar)
    • Nuclear
      • meson deflection
      • pion absorption (think of this as the Star Wars "scanning" technology)
  • Passive scan
    • Nuclear
      • neutrino emission
    • Gravitic
      • mass displacement
    • Electromagnetic
      • infrared (heat)
      • visual
      • size
      • shape
      • color/decals
      • ultraviolet
      • X-ray
      • magnetic field
    • Chemical
      • ion trail
    • Broadcast
      • Identification-Friend-or-Foe (IFF) code (military only)
      • ID transponder
Note that "active scans" are detection-and-identification technologies that send out some kind of signal and then read the signal that bounces back (or not). (Think of these as like the sonar "pings" in movies about submarine warfare.) Active scanning is good for resolving details about other vessels, but it has the drawback of letting other ships know exactly where you are and what you're doing. They use up a lot of power, too.

Passive scans, by contrast, just take in information about other ships that they give off or deliberately broadcast. These don't always give you a lot of detail, and you need to be fairly close to the other ship for certain types of passive scans to work, but they're good for detecting other ships when you don't want to be detected yourself.

So -- given all these ways that we can detect objects in space, and, once detected, learn specific information about them, wouldn't it be interesting if JtL allowed us to explore all these phenomena as sensor options?

You're a Imperial frigate patrolling the spacelanes to control the piracy that's been reported in this sector of space. Your active radar scan is always on, "pinging" the space around you. This has the double effect of letting you "see" any ships in range of your radar, but also of warning off any Bad Guys (because they can detect your active scan).

Today you're cruising along near a "hot" star (one that puts out a lot of junk radiation that makes scans difficult) when your radar picks up a ship far ahead. You move in close enough to run an ID scan (passively reading the ID transponder code broadcast by all ships except pirates). The ID scan says it's the Ghazal, a YT-1300 bulk freighter registered out of Corellia, but you order your sensor operator to run a neutrino emission scan [to roughly determine the ship's power output] and a gravitic displacement scan [to measure the ship's tonnage] just in case. Given the recent outbreak of piracy, you want to make sure this ship really is who she claims to be.

The passive scans report that the Ghazal is a little bigger than expected, but within the upper boundary for freighters. Still, something in your gut is nagging you. Your sensor technician is pretty good, so you order your ship in a little closer and send to the Ghazal to submit to a routine cargo scan. (You're an officer of the Empire; you don't ask for permission.) Another ship shows up on the radar in the distance (too far for ID transmission), but you want to finish with the Ghazal first.

As you close to visual (and cargo scanning) range of the Ghazal, your sensor tech completes a set of active electromagnetic (EM) scans, and you can now see the ship for yourself visually. She appears to have more gun turrets than the typical bulk freighter... and the turrets appear to be sporting quad turbolaser cannons, which are rather more powerful than the typical freighter's defensive armament....

Suddenly your sensor tech looks sharply up at you and says, "Sir, infrared emissions suggest that this ship is masking its real power signature!" The readings on the neutrino scan spike upward abruptly as the Ghazal feeds power from its shielded (and hacked) engines to its weapons systems -- all of which suddenly lock on to you. It's a pirate! She's been using illegal technology to mask her power signature from other ships, and more illegal technology to change her ID transponder code to that of a ship with no outstanding warrants. This must be the ship that's been attacking the honest merchants in this sector!

You order your ship to power up its weapons, but the fake Ghazal is already firing on you. Normally your frigate would be more than a match for a freighter, but this is obviously no ordinary freighter... and that's when you notice that the ship you had seen just at the edge of your radar is running toward you. And so is the ship that has just appeared from out of the photosphere of that nearby "hot" star, where it was using the noise of the star to mask its emissions from passive scans.

Are these ships friends coming to your rescue? Or are they more pirates, which could put you in real jeopardy?

Better run your sensor scans!

So would anyone else like to see this kind of thing in Jump to Lightspeed? Or is it too complicated, and we should just stick to quick-and-dirty fights that are over in ten seconds or less?

Tuesday, June 15, 2004

SWG: Jump to Lightspeed: Capital Ships

I can see three potential good uses for capital ships in SWG:

1. Missions: It would be fun to board a capital ship to accomplish some task for your side. In the same way that Obi-Wan had to find and disable the tractor beam aboard the Death Star in SW:ANH, and that sufficiently burly players can go into the Corellian Corvette dungeon in SWG, some of the things you could do after sneaking onto a capital ship might be:

  • assassinate an enemy commander (NPC)
  • rescue a captured scientist (NPC)
  • extract battle plans from the ship's computer
  • disable the ship's shield generator
  • obtain passage to a hidden enemy base
  • sabotage the ship's engines
2. Flight Operations: A lot of people seem to like the idea of serving aboard a big starship in some official capacity. Usually this seems to mean active duty in one of the following roles:

  • Bridge: commanding the ship (Captain)
  • Bridge: actually piloting the ship (Helmsman, Navigator)
  • Bridge: fire control (Weapons Officer)
  • Bridge: other stuff (Communications, Sensors, Shields, Internal Security)
  • Engineering: servicing the engines, shields, and weapons (Chief Engineer)
  • Gun turret: shooting at enemy starfighters (Gunner, Gunner's Mate)
This kind of gameplay probably owes more to Star Trek than to Star Wars, but it could still be fun to implement somehow in SWG.

3. Carrier Operations: This is all about being a starfighter pilot aboard some big hulking carrier that takes you from one battle to another. As much fun as duking it out one-on-one is likely to be, who wouldn't want to be part of some Midway-sized major furball, with hundreds of fighters buzzing around multiple capital ships unleashing electric death on each other?

Personally, here's what I'd like to see. Every now and then -- maybe once every couple of weeks or so -- two capital ships appear over two different major planets. The announcement goes out: "If you're a starfighter pilot, we need you! Sign aboard our ship now, and we'll take you to the enemy!"

You'll fly to the ship, where you'll emerge on board in a hangar bay (with your ship in your datapad) where you can hang out with your fellow fighter jocks, upgrade your ship's components, or load consumable weapons like missiles and flares. After about 30 minutes you'll get a warning message followed by a "loading" screen... and *BING* your carrier appears some distance away from the other capital ship that also just emerged from hyperspace.

And then it's "all hands to battle stations!" You click on your fighter deed and launch to space to start pounding on the bad guys. Depending on how you do against the enemy fighters, your carrier will take more or less damage. Once either carrier drops below some magic number, it will send out a message that it's bugging out. At that point you'll have something like two or three minutes to break off combat and dock with the carrier.

If you're able to dock in time, you'll return to your hangar bay and be aboard when your carrier returns to the planet from which it picked you up, at which time you'll be ejected in your fighter. (Meanwhile the other carrier, after about ten minutes of mopping up enemy stragglers, will return to its own home planet and eject its own complement of fighter pilots.)

If you don't dock in time, your ship zooms off into hyperspace without you, which could leave you in extremely unfriendly territory indeed.

So is there anyone planning to fly Imperial or Rebel starfighters who wouldn't enjoy this kind of thing?

Friday, June 11, 2004

Player-Defined Organizations


Most MMOGs these days offer some form of long-duration and many-person groups. Whether they're called guilds or clans or corps or player associations, most MMOGs now offer some in-game tools offered to support these in-game community institutions.

However, something few MMOGs offer is to allow players themselves to define the forms of these institutions and -- more importantly -- the functional rules by which members advance within them. Instead, player associations are generally free-form and loosely defined aggregations of players, with all power to control the existence of the association held by one player. Players can simply say, "OK, you're the duke, she's a countess, and we're all knights," but basically you're just hoping everyone goes along with this kind of roleplaying because that's the only way it can currently be done.

This works, but I wonder if it's not missing some useful opportunities to make these associations a more active part of gameplay. What if these roles could be defined by players for their organizations? Even better, what if they could also define the rules by which players shift into and out of organizational roles to fit the organization's goals for gameplay?

"Player Organizations" is my name for this more general version of the player association concept. Here's how it could work.

Concept of Operation

Any player would be able to use a template to create a table of organization. You'd be able to specify the number of levels, the number of people allowed at each level (the "span"), and the names of individual levels (and possibly even groups of levels). Then you'd pick (from a predefined list of rules and triggers) the advancement criteria for going up to the next level.

For example, one person might create a T.O. on a military model: one Field Marshal [Army] who gives orders to two Generals [Brigade], each of whom gives orders to two Colonels [Regiment], each of whom gives orders to four Captains [Company], each of whom gives orders to two Lieutenants [Platoon], each of whom gives orders to four Sergeants [Squad], each of whom gives orders to eight Soldiers. That would give you an organization capable of holding 1207 people -- more than enough for most purposes, I'd think. If you needed more (and if you're the Field Marshal), you could always change the organizational definition to extend the span at one or more levels.

Rules of Advancement

In addition to the names of the ranks, the designer of a Player Organization would also be able to determine the rules for advancement. These would be selected from a predefined list of rule types supplied by the developers to avoid questions of subjectivity, as well as to reduce roleplaying requirements. (Although anyone who wanted to handle rank advancement purely through roleplaying could do so -- advancement rules should be optional.)

Moving up a rank in a military organization might be based on:

  • kills [something specific to a military organization]
  • XP earned in a particular skill or special organizational XP box
  • agreement of a majority of players at the next rank
  • available opening of the appropriate rank
The system itself would monitor "counting" or "trigger" rules to determine for each member of the organization (to whom those rules apply) whether the target has been met. Other rules would require organization members of the appropriate level and role to decide whether the terms of those rules have been met. The combination of these rules would allow the members of organizations to effectively control advancement within the organization. This would solve one of the problems with current "guild" systems, which is that the one person at the top of the group has all the power and responsibility for controlling position within the group. A Player Organization system would allow this power to be devolved into the organization. Players would not be required to do so; they could duplicate the existing guild approach if they chose, but at least they'd be able to create more egalitarian organizations if they wished to do so.

Organizational Diversity

Military organizations are an obvious application of the Player Organization system, but the beauty of the system is that it can be used to create any kind of organization.

Another person might want to form a crafting guild, and would set up her organization based on Apprentice, Journeyman, and Master levels with appropriate advancement rules. Yet another person might form an Entertainer's Union with his own set of levels, titles, and advancement rules; another person might form an organization like a modern business with a CEO, board of directors, VPs, Directors, Managers; and so on. The Player Organization system could accommodate all these and more.

Here's an example of how a player organization interested in crafting and selling products might be designed:









VP for R&D


Regional VP

Board Member

Resource Mgr.

Project Manager

Sales Manager




Account Rep.


(Naturally, at the top of the heap there'd have to be a CEO.)

So if you were interested in sales, you'd start off as an Account Representative talking to other players about the products available from your organization, and picking up any in-game skills that might be useful to that end. If your sales figures were good enough, then when a Sales Manager position opened up you might be considered for that position, at which point you'd get some kind of nice perks in addition to the new title. In return, you'd wind up spending more of your time helping to manage the activities of several Account Reps, and you'd be responsible for their sales to your Regional VP, who in turn oversees all sales in two or three areas and reports to the CFO of the entire organization.

Again, you could have similar hierarchies for any kind of player organization: military, commercial, entertainment, whatever.

It would be helpful to have a way to display these titles/roles within the game. This public recognition would help encourage players to use and participate in the organization-designing system. The system as I've described it would also allow you to have objective rules for moving up in the hierarchy, which is always better than "well, maybe I'll promote you... if I feel like it."

(Actually, one of the tricky bits of my idea is the mechanism for providing rules and perks for promotion. I think it would be possible to pre-define some specific kinds of promotion rules -- number of kills of enemy type X, for example, or Y accumulated experience points in skill Z -- that the organization's designer could associate with a rank/title. But this part of the system would need to be hashed out in more detail.)

Just for giggles, here's another kind of organization you could have:







5000 royal faction, male avatar



5000 royal faction, female avatar



4000 royal faction, male avatar, acceptance by King or Queen



4000 royal faction, female avatar, acceptance by King or Queen



3000 royal faction, male avatar, acceptance by King or Queen



3000 royal faction, female avatar, acceptance by King or Queen



2000 royal faction, male avatar, acceptance by any higher rank



2000 royal faction, female avatar, acceptance by any higher rank



1000 royal faction, male avatar, acceptance by any higher rank



1000 royal faction, female avatar, acceptance by any higher rank



600 royal faction, acceptance by any higher rank



250 royal faction, acceptance by any higher rank



acceptance by any higher rank

Note 1: The # denotes how many of each rank can exist at any one time, and is another kind of requirement.

Note 2: Acceptance by a higher rank is only required if at least one person holds the indicated rank. If no one does, then acceptance is automatic.