home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / netrek / 11250 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  50.0 KB

  1. Path: sparky!uunet!gatech!europa.asd.contel.com!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!agate!ames!pacbell.com!charon.amdahl.com!amdahl!fadden
  2. From: fadden@uts.amdahl.com (Andy McFadden)
  3. Newsgroups: rec.games.netrek
  4. Subject: Frequently Offered Clever Suggestions
  5. Message-ID: <89H=03SFc5zd00@amdahl.uts.amdahl.com>
  6. Date: 21 Dec 92 21:18:44 GMT
  7. Reply-To: fadden@amdahl.uts.amdahl.com (Andy McFadden)
  8. Organization: Amdahl Corporation, Sunnyvale CA
  9. Lines: 1187
  10.  
  11. Here's the monthly FOCS posting.  Nothing new here.
  12.  
  13. --
  14. rec.games.netrek Frequently Offered Clever Suggestions list
  15.  
  16. Maintained by Andy McFadden (fadden@uts.amdahl.com)
  17. Revised: (no changes)
  18. Last revision: 26-Oct-92
  19. Changes: (no changes)
  20.  
  21.  
  22. The same ideas get proposed over and over by people trying to enhance the
  23. game, and the same discussions come up again and again.  This file is an
  24. attempt to stem the flow by presenting old discussions and arguments against
  25. the ideas.
  26.  
  27. This assumes you are familiar with the game itself and some of the vocabulary
  28. (argot) involved (e.g. scum, ogg, LPS, Iggy).  This is NOT intended to be a
  29. capsule summary of rec.games.netrek discussions; it is intended to help
  30. people trying to enhance the game understand why many of the obvious
  31. improvements won't work or won't be accepted by the Netrek community.  As
  32. such, it contains one-sided and occasionally opinionated material.  I welcome
  33. improvements and stronger arguments, but if you want to debate the value of
  34. something I will probably ignore you.
  35.  
  36.  
  37. REMEMBER: Netrek is not Star Trek.  Netrek is not reality.  Star Trek is not
  38. reality (despite my earlier assertions to the contrary).  DO NOT suggest
  39. modifications purely to make the game "more realistic".  ONLY consider ideas
  40. that will improve game play.
  41.  
  42.  
  43. CONTENTS:
  44.  
  45.   1) How about team DI?
  46.   2) How about no DI at all (+ changes in general)?
  47.   3) All ships shouldn't fire 8 torps.
  48.   4) Let's make cloakers blind.
  49.   5) Let's allow cloakers to fire.
  50.   6) The DD needs to be improved.
  51.   7) Here's a neat idea for a new ship.
  52.   8) How about a ship design system?
  53.   9) Remove the kill restriction on army carrying.
  54.  10) Remove the kill restriction on plasma torps.
  55.  11) Get rid of LPSs.
  56.  12) Get rid of Iggy!
  57.  13) Combine all of the server processes into one.
  58.  14) Put the number of armies next to the planet.
  59.  15) Highlight ships with kills.
  60.  16) Prevent bombing/taking out of T-mode.
  61.  17) Stop 3rd race scumming.
  62.  18) Just have a two-race galaxy.
  63.  19) Add incentives for scout bombing.
  64.  20) Protect ships that are fully lagged.
  65.  21) Credit kills appropriately.
  66.  22) Get rid of borgs!
  67.  23) Change the names of the races or the planets.
  68.  24) Add ship collisions.
  69.  25) Give planets gravity or motion.
  70.  26) Show the list of players or a "rank weighting" on entry.
  71.  27) Set up an invitation-only clue server.
  72.  28) Allow ships to drop mines.
  73.  29) Have the client update the torps instead of the server.
  74.  A1) Appendix: Sturgeon II changes
  75.  A2) Appendix: Sturgeon II kill credit rules
  76.  
  77.  
  78. You can skip straight to the one you're interested in (say, chapter 2) by
  79. searching for the regular expression "^2)".
  80.  
  81.  
  82. 1) How about team DI?
  83.  
  84. Problem:
  85. Too many rank scums out there for themselves.  Need to add an incentive for
  86. team play, so that they will get more DI if their team does better.
  87.  
  88. Proposal:
  89. Change the DI structure so that you get points for stuff your teammates do.
  90. Alternatively, change it so that you get points for different "team stuff",
  91. like taking strategically placed planets or killing carriers.
  92.  
  93. Why not:
  94. Most "team DI" schemes will cause people to switch to the team that's
  95. winning, because that's where the points are.  It is possible right now to
  96. see the players on each team before making the initial team selection; this
  97. would make unfair teams the rule.
  98.  
  99. Changing the individual values of things is difficult when you consider how
  100. the current DI scheme works.  "DI" is simply the sum of offense, bombing,
  101. and planet ranks, multiplied by the number of hours you have been playing,
  102. and then adjusted according to the global average.  There are no fixed DI
  103. values for doing certain things; just your relationship to the rest of the
  104. people on the server.
  105.  
  106. Killing people with armies gives you (5*armies) bombing credit, and taking
  107. core planets is worth more than other planets, so the incentives exist;
  108. people are simply unaware of them or feel it is easier to do things the
  109. scum way.
  110.  
  111.  
  112. 2) How about no DI at all?
  113.  
  114. Problem:
  115. DI is a mistake.  It is the reason for scumming.
  116.  
  117. Proposal:
  118. Toss it.  At least toss all the ranks above Captain.
  119.  
  120. Why not:
  121. Many people like to advance in rank.  DI was developed because the original
  122. Xtrek had nothing but win/loss stats, so ratio scumming was the only way to
  123. look impressive (you think DI is bad... heh).  There are a large number of
  124. Admirals who like having their rank (hey, it took them a long time to get
  125. there), and some of them run servers.  DI is like the USA's electoral voting
  126. system: it's not great, and the country might be better without it, but it's
  127. not going away without a major fight.
  128.  
  129. Besides which, it's a good way to attract [scum] players to new servers.
  130.  
  131. Any change to DI is simply going to shift scumming one way or the other.
  132. Most arcade games are centered around the accumulation of points; the object
  133. is to do certain things, for which you rewarded.  The idea of Netrek, however,
  134. is to win the game; rank should be just an incidental feature.  However,
  135. there will always be those who see the accumulation of points, rank, or
  136. whatever as the driving goal.
  137.  
  138. The Holy Grail of DI changing is a system that rewards only non-scum
  139. activities.  However, telling scumming from teamwork requires human
  140. intervention or artificial intelligence in most cases.
  141.  
  142. Other interesting ideas:
  143. - Have players promote each other.  Once you get to a certain rank, you can
  144.   promote those beneath you.  This has a chicken & egg problem which can be
  145.   solved by importing a database or with some active administration at first.
  146.   Note this is open to abuses (demoting people you don't like, promoting
  147.   really lame players to embarass them, etc), and tends to trivialize rank.
  148.   Tried on b62150.student.cwru.edu.
  149.  
  150.  
  151. 3) All ships shouldn't fire 8 torps.
  152.  
  153. Problem:
  154. The game is unbalanced.  SBs should be able to shoot more torps than others.
  155. Maybe SCs shouldn't be able to shoot as many.
  156.  
  157. Proposal:
  158. Increase SB torps to 12, or scale all others accordingly.
  159.  
  160. Why not:
  161. Going to 12 torps requires mods to both client and server.  This will increase
  162. CPU time slightly, and will increase network usage.  You can't just switch
  163. on the ship type, either, because a SB could fire 12 torps and then refit.
  164.  
  165. Scaling all ships down (so that an SC would fire, say, three torps total)
  166. has been tried on Sturgeon; see appendix A1.
  167.  
  168. Any change to the ship characteristics is going to be met with a great deal
  169. of resistance.  The game is very carefully balanced, and any changes can
  170. result in drastic changes in the way it's played.
  171.  
  172.  
  173. 4) Let's make cloakers blind.
  174.  
  175. Problem:
  176. Cloaking is too powerful.  Ogging is getting out of hand.
  177.  
  178. Proposal:
  179. Remove certain items from the tac display of a cloaked ship, like enemy
  180. ships, planets, torps, etc.
  181.  
  182. Why not:
  183. Been done.  Not very popular.  Removing planets makes them hard to take
  184. (you just sit there watching your 'O' flag, hoping that nobody will kill
  185. you because they KNOW you are coming straight in).  Removing torps is bad
  186. for the same reason.
  187.  
  188. Removing other players to make ogging harder is bad because most players
  189. LIKE ogging.  It's fun, and it's part of the game.
  190.  
  191.  
  192. 5) Let's allow cloakers to fire.
  193.  
  194. Problem:
  195. Now that Star Trek VI is out, cloakers (esp. Kli) should be able to fire.
  196.  
  197. Proposal:
  198. Allow ships to fire when cloaked, possibly with a higher fuel or wtemp cost.
  199.  
  200. Why not:
  201. Gimme a break.  Ogging would become trivial without changes to other parts
  202. of the game.  See the Sturgeon changes in Appendix A1.
  203.  
  204.  
  205. 6) The DD needs to be improved.
  206.  
  207. Problem:
  208. The DD is weak.  It can't take bomb as well as an SC, and it can't fight as
  209. well as CA.
  210.  
  211. Proposal:
  212. Give the DD bigger shields, or bigger torps (30 is too small), or more
  213. powerful phasers, and perhaps a bigger fuel tank.
  214.  
  215. Why not:
  216. As Tom Holub put it (paraphrased), "The CA is weak.  It can't bomb as well
  217. as a DD, and it can't fight as well as a BB."  All ships have their place,
  218. it's just a question of finding the right niche.  DDs can carry 5 armies,
  219. making them more of a threat to planets than the SC.
  220.  
  221. Several discussions have raged over rec.games.netrek about what the One True
  222. Use of the DD is.  None have been found.  They can't be used as a big SC
  223. nor as a small CA; they require a different perspective.  I won't offer
  224. them here, but will instead relegate it to the thrice-revised DD Players Guide.
  225.  
  226. As a side note, the cooling rate on DDs was changed from 6 to 7, allowing
  227. them to go great distances without overheating.  Many players who previously
  228. thought the DD fully worthless now consider it to be valuable in certain
  229. circumstances.  For those of you who are beginning to think that I'm totally
  230. anti-change, let it be known that I sent private e-mail to about ten different
  231. server dieties asking them to make this change, and campaigned long and hard
  232. on rec.games.netrek.
  233.  
  234. I detest the phrase, "Ship of Lose."  It doesn't even make sense.  Stop it.
  235.  
  236.  
  237. 7) Here's a neat idea for a new ship.
  238.  
  239. Problem:
  240. There's a gap in Netrek that really needs to be filled.
  241.  
  242. Proposal:
  243. I want a new ship X that can do Y and Z.
  244.  
  245. Why not:
  246. KSU-Galaxy/Chaos servers are a prime example of ship design run amok.  The
  247. GA had huge torps, fast phasers, an incredible refueling rate, and eventually
  248. they even boosted the manuverability on some servers.  As a result, nobody
  249. played anything but GA (there were some DD holdouts, but once you could turn
  250. in GA at a reasonable warp most of those switched over).
  251.  
  252. You may think your new design will fit perfectly into Netrek.  You're
  253. probably wrong.  Some examples from the past:
  254.  
  255. - mini-starbase.  Like your normal SB, but less filling.  You'd get a couple
  256.   on a team, or maybe just have them more often.  Two of these together,
  257.   pressoring each other out of danger, would be damn near invincible when
  258.   guarding a repair planet.  It's basically a Super Planet Defender, like
  259.   a BB on steroids, and it really wouldn't add anything new to the game,
  260.   since it's easier to ogg than an SB and slower than a BB.
  261.  
  262. - fighters.  SBs would launch these, perhaps they'd be robot-controlled.
  263.   Again, neat idea, but so what?  They would either have to occupy a player
  264.   slot (reducing the number of other robots you can have) or require
  265.   modifications to both client and server (which is a Bad Thing).  Again,
  266.   what do they add?  Are they any different from plasma torps with a high
  267.   tracking setting?  See the Sturgeon changes, which implemented them as
  268.   slow-moving tracking torps, which SBs could fire instead of normal torps.
  269.  
  270. - floating fuel platform.  Another pseudo-SB, which looks like an AS but
  271.   has fuel like an SB.  Easy ogg target; what good is it if you have to keep
  272.   it sitting behind your home planet?  One BB can off the thing, so it's
  273.   not even valuable as a distraction.
  274.  
  275. - ogger ship.  Maybe it uncloaks fast (a la the old Calvin scheme), or it
  276.   does 200 points of damage when it explodes, or it has small torps but a
  277.   big phaser, or whatever.  Anybody who thinks they need this has never been
  278.   ogged by somebody in a CA who knows what they're doing.  This would just
  279.   make Ogging by Idiots that much easier.
  280.  
  281. - super scout ship.  Strip off most offensive weaponry, make it real fast.
  282.   What's the point?  Try stopping a good SC player, and THEN see if you
  283.   really want to propose this.
  284.  
  285. - big fat starbase.  This one has the actual size increased, making it easier
  286.   to hit, but is given better shields to compensate.  So what's the point...?
  287.   It would involve changing a lot of code in the server and client to special
  288.   case the various options, plus new bitmaps (for shield/cloak as well),
  289.   etc, etc.
  290.  
  291. Many suggestions like these come from people trying to compensate for
  292. inadequacies in the ships (sounds vaguely Freudian, doesn't it?)  It takes
  293. time and a lot of practice to become a really effective player; even
  294. the lowly SC can be a marvelous dogfighting ship when it's flown by a
  295. skilled player.
  296.  
  297.  
  298. 8) How about a ship design system?
  299.  
  300. Problem:
  301. Other games (e.g. xtank) allow you to change the way your ship is set up.  I
  302. want to be able to adjust my ship characteristics according to the way I play.
  303.  
  304. Proposal:
  305. Allow ship characteristics to be adjusted by the player.
  306.  
  307. Why not:
  308. This was implemented in a version of the original Xtrek game.  The tendency
  309. was to do things like strip all torpedos, most of the hull, half of the
  310. engines, and all of the cloaking ability from the ship and get phasers that
  311. could do 40 points of damage to ships outside of visual range (but had to
  312. be orbiting a fuel planet to fire more than twice).
  313.  
  314. Games quickly became ridiculous.  Either your planets were being taken by
  315. someone completely invisible, or you were getting destroyed by ships you
  316. couldn't see.  Nobody bothered dodging, because nobody fired torps.
  317.  
  318. Any implementation will require carefully balanced limits and a lot of play
  319. time before it would become widespread.  Anyone who wishes to try this will
  320. likely have to set up their own server and then try very hard to attract
  321. players to it.
  322.  
  323. As a side note, Sturgeon has a feature somewhat like this: predefined ship
  324. upgrades after you get kills.  Unfortunately this can encourage ratio
  325. scumming and runner scumming, because nobody with a nice big fat ship wants
  326. to die.  (It also introduced "upgrade scumming" to the world: repeatedly
  327. killing a second login to get lots of upgrades.)
  328.  
  329.  
  330. 9) Remove the kill restriction on army carrying.
  331.  
  332. Problem:
  333. Imposing a restriction based on kills is unrealistic and silly.
  334.  
  335. Proposal:
  336. Allow any player to carry armies.
  337.  
  338. Why not:
  339. If you allow this, you remove a big part of the challenge of the game.
  340. Getting a kill and staying alive while trying to move armies around is
  341. one of primary challenges in Netrek.  If anybody can carry armies, then
  342. every player is a potential planet taker, and it's impossible to focus
  343. the defense of your space.
  344.  
  345. You will also increase the instances of Ensign Fubar scampering about,
  346. picking up armies and dying with them.  This is a Very Bad Thing when your
  347. team is low on armies.  If a player can't get a kill, he probably doesn't
  348. have the skill or experience to take a planet without getting nailed.
  349.  
  350. (People who need practice taking planets need to practice staying alive first!)
  351.  
  352. For those who insist on reality, it can be argued that Star Fleet Command
  353. doesn't like to entrust armies with commanders who haven't proven themselves
  354. in battle (especially Kli!)  It has also been suggested that the captains
  355. use the hull fragments of the enemy starships to build crew accommodations
  356. for the armies.
  357.  
  358.  
  359. 10) Remove the kill restriction on plasma torps.
  360.  
  361. Problem:
  362. Requiring kills for plasmas is silly.
  363.  
  364. Proposal:
  365. Allow plasmas for one and all.
  366.  
  367. Why Not:
  368. While this is a trivial server change (quick alteration to .sysdef), it's
  369. there for a reason, namely that having 8 battleships with plasma torps makes
  370. taking planets impossible.  LPSs would never end.  Chaos servers allowed
  371. infinite plasmas, and plasma-wars became rather common.  So did plasma-
  372. muggings (you can't shoot three incoming plasmas!)  The ping-pong plasmas
  373. made life interesting, but then there's not much point in taking planets
  374. on a Chaos server anyway.
  375.  
  376. The way things are now, players with 2+ kills can be ogged, which prevents
  377. them from firing more plasmas.
  378.  
  379. While it's true that the rich become richer (or perhaps the deadly become
  380. more deadly), there's nothing wrong with elitism in Netrek.  It's just a
  381. game.  Deal with it.
  382.  
  383.  
  384. 11) Get rid of LPSs.
  385.  
  386. Problem:
  387. LPSs suck.  They're boring and they make my stats hurt.
  388.  
  389. Proposal:
  390. Various ideas.
  391.  
  392. Why Not:
  393. The Last Planet Stand is one of the few things in Netrek that absolutely
  394. REQUIRES teamwork.  It is nearly impossible to break an LPS unless the
  395. attackers are organized or the defenders are largely clueless.
  396.  
  397. A reasonable solution to the Indefinite LPS (one that drags on and on
  398. because all the clued players on the attacking side bailed) is the Bronco
  399. LPS timer.  The attackers get 45 minutes to break it, at which point the
  400. galaxy resets.  There are players who dislike the timer because it encourages
  401. the attackers to slack off ("oh, we'll just wait for the timer, we'll never
  402. break through), but it's proven to be a reasonable compromise.
  403.  
  404. LPSs are here to stay.  It is possible to come back from one, just as it is
  405. possible to genocide a race.  If you are concerned about the damage to your
  406. stats, then set up your own server, scum your way to admiral, and get on
  407. with life.
  408.  
  409. There are some ideas floating around about encouraging teams to go for the
  410. genocide, such as resetting the galaxy afterward instead of leaving a
  411. 20 planet vs 10 planet setup (whether that's a punishment or a reward
  412. depends on your point of view).
  413.  
  414. Side note: LPSs with homeworld agris are monumentally unpopular.  You can
  415. hold off against a fleet with greater numbers without too much difficulty.
  416. Many servers explicitly prevent the home world from being agri; if your
  417. favorite server doesn't, tell the server admin.  (The other side of the
  418. coin is that, once taken, it's harder for the home team to retake.  I don't
  419. think this balances the pain of taking it in the first place, however.)
  420.  
  421.  
  422. 12) Get rid of Iggy!
  423.  
  424. Problem:
  425. Iggy is nothing but a pain.
  426.  
  427. Proposal:
  428. Lose him.
  429.  
  430. Why Not:
  431. Iggy is a Bronco server feature that adds a bit more randomness to the game.
  432. Opinions on Iggy are rather divided, but most everybody seems to have one
  433. (at this point I will plead neutrality so as not to start ANOTHER flame war).
  434.  
  435. If you really dislike Iggy, either:
  436. - kill him as soon as he shows up,
  437. - ask the server god to remove him, or
  438. - play on servers that don't have him.
  439.  
  440. Some people will argue that Iggy is "terrain", i.e. a part of the game like
  441. planets (only a bit more aggressive).  A common phrase is, "if you're fighting
  442. Iggy, you don't understand him."
  443.  
  444. Some servers have banned Iggy during t-mode; you might request this.  It
  445. should be left to the individual admins however.  Some servers (e.g. Calvin)
  446. have snakes instead, which don't really do much but get in your way (they
  447. look cool though).
  448.  
  449.  
  450. 13) Combine all of the server processes into one.
  451.  
  452. Problem:
  453. My workstation can't handle all the context switches.
  454.  
  455. Proposal:
  456. Merge all the ntserv processes into one, and maybe even combine them with
  457. daemonII, so instead of the Server Union we'd have the Unified Process.
  458.  
  459. Why Not:
  460. Ray Jones is working on this.  There are advantages and disadvantages to
  461. doing this, not the least of which is that it requires a complete rewrite
  462. of the server, a partial to full rewrite of the client, and will work best
  463. as a strictly UDP implementation (which requires a whole new protocol).
  464.  
  465. Among the disadvantages are the possible loss of the shared memory segment
  466. (which kills the traditional tool interface), the need to bring the server
  467. down whenever changes are made, the inability to simply restart failed
  468. components (ex: restartable daemon), changes in CPU load possibly resulting
  469. in lower UNIX process priorities (and thus worse real-time performance),
  470. changes in the way the kernel sees Netrek (e.g. waiting for I/O), poorer
  471. performance on MP machines, the larger executable will be more likely to be
  472. swapped out under BSD, loss of memory firewalls between components, etc, etc.
  473.  
  474. There are a number of advantages, but this file is meant to discourage you,
  475. not entice you.  A reading of the process scheduling chapter in _The Design
  476. and Implementation of 4.3BSD UNIX_ should be required for anyone contemplating
  477. this.
  478.  
  479.  
  480. 14) Put the number of armies next to the planet.
  481.  
  482. Problem:
  483. It's annoying to have to hit 'i' all the time to get army counts.
  484.  
  485. Proposal:
  486. Put the number of armies on each planet next to the planet's bitmap on the
  487. galactic map.
  488.  
  489. Why Not:
  490. This is the first step down the path to "Netrek for Morons(tm)".  You can see
  491. when a planet pops by watching the galactic map; having ever-increasing army
  492. counts staring you in the face is like having a compass attached to your
  493. nose.
  494.  
  495. It's true that the information is accessible, if somewhat inconvenient.
  496. However, players who aren't paying attention won't see the new army
  497. numbers, and are less likely to react to an army bitmap on the display than
  498. they are to seeing "15" next to Sir.  If you aren't paying attention to
  499. armies, you lose.  There are several places in Netrek where this is the
  500. case.
  501.  
  502. Netrek rewards vigilance and a keen eye as well as intelligence and fast
  503. reflexes.  Being constantly aware of everything around you is a challenge
  504. beyond the goals of the game itself; it requires the player to improve
  505. himself, and rewards experience.  Doing all but say, "do this next" will
  506. make things too simple, and reduce the sense of accomplishment acquired
  507. from mastery of the game.  Knowing exactly where the armies are and how many
  508. requires as much skill as holding a phaser lock, which is as it should be.
  509.  
  510. There are those who think otherwise.  I'm not presenting their opinions here,
  511. because if you are about to propose this then you share those opinions
  512. already.  Suffice it to say that there is enough disagreement to keep this
  513. from becoming a standard feature of Netrek.
  514.  
  515.  
  516. 15) Highlight ships with kills.
  517.  
  518. Problem:
  519. It's too annoying to have to look down at the player list, and relate that
  520. to the people flying around.
  521.  
  522. Proposal:
  523. Mark players with kills somehow.
  524.  
  525. Why Not:
  526. This is yet another stepping stone on the path to ButtHeadTrek.  This would
  527. essentially stick a big "Ogg Me" sign on the engines of anybody with a kill.
  528. You don't even have to pay attention to the game to know what you should do
  529. when you encounter a ship with kills.
  530.  
  531. While this is in the same vein as the army counts, it isn't really
  532. controversial, possibly because the guys who like the army counts also like
  533. to take planets and don't want to get swamped by "stupid oggers."
  534.  
  535.  
  536. 16) Prevent bombing/taking out of T-mode.
  537.  
  538. Problem:
  539. Many players either don't know Netrek-etiquette about not messing with
  540. planets outside of T-mode, or they choose to ignore it.
  541.  
  542. Proposal:
  543. Make the server enforce it.
  544.  
  545. Why Not:
  546. Actually, I kind of like this one.  Sickdog had a mod where trying to bomb
  547. or drop armies out of t-mode caused you to explode.
  548.  
  549. The main problem with it is that sometimes its okay to bomb out of t-mode.
  550. If you've got a 2-on-2 "training" session and just want to practice trading
  551. planets, it's annoying to have it blocked.  Making this policy work without
  552. getting in the way generally requires human intervention.  You could do
  553. something fancy, counting how much time has elapsed since t-mode was lost
  554. and take into consideration #of players on a team, etc, etc, but you'd have
  555. to lean on a server deity to get this to happen.
  556.  
  557. Another problem is that simple implementations don't give you enough warning
  558. (one minute you're dropping, the next BOOM!).  Any solution will have to take
  559. a lot of stuff into account, and so far nobody has stepped forward to provide
  560. something that is widely accepted.
  561.  
  562.  
  563. 17) Stop 3rd race scumming.
  564.  
  565. Problem:
  566. When players are unable to break an LPS, or they just want more armies, they
  567. may go over to a race with no players and take some planets.  This happens
  568. often when a 20-on-10 game has slowed to an impenetrable impasse, and the
  569. team with 20 planets decides to reset the galaxy by capturing a 3rd race.
  570. It's also used to draw LPS defenders away from the planet, and make them
  571. try to defend 3rd race space.
  572.  
  573. Proposal:
  574. Don't allow 3rd race planets to be taken over.
  575.  
  576. Why Not:
  577. I really hate 3rd-space scumming, but I'll bite my tongue (ouch!) and try
  578. to give some reasons not to propose this.
  579.  
  580. First of all, it's already been discussed several times, so unless you plan
  581. to undertake a direct-mail campaign to server dieties, forget it.  It's been
  582. a part of Netrek for quite some time, and there are some dedicated 3rd-space
  583. scummers out there.  It's also a viable (if cowardly) alternative to the
  584. genocide timer, especially on servers that don't have the timer.
  585.  
  586. However, as one slightly opinionated player put it:
  587. >From: tom@soda.berkeley.edu (Tom Holub)
  588. >Subject: Re: 3rd space planet taking
  589. >Date: 11 Aug 92 07:49:12 GMT
  590. >
  591. >People are for it because they are fuckin' WEENIES who don't want to
  592. >play the game.
  593. > -Mojo
  594.  
  595. If you propose it, you will have support, but you won't get anywhere unless
  596. you're willing to put your back into it.
  597.  
  598. Some ideas from the past (other than "just don't allow it"):
  599. - Make war status permanent.
  600. - Force players to be peaceful against all races except their t-mode
  601.   opponent.
  602. - Make more intelligent/stronger guardians (go after people with kills, etc).
  603.   Unfortunately, a team which is about to perish will likely bomb the 3rd
  604.   race to bring in a super-guardian to help defend their new territory
  605.   after the genocide (this can be fixed, of course).
  606. - Have robot appear when hostile player ENTERS 3rd space, not just when he
  607.   attacks it (presume guilt).
  608. - Make undefended planets do more damage to attackers.
  609. - The neutral race gets ticked, and some planets join the non-offending team
  610.   for protection (interesting, but it's actually worse).
  611. - Add robots which actually attack the attacker's space (bombing/taking).
  612.   The large number of armies on 3rd race planets makes this attractive.
  613. - Leave it legal for servers without a timer, but simply ban it from servers
  614.   with an LPS timer.
  615. - Have a two-race galaxy (see next item).
  616.  
  617.  
  618. 18) Just have a two-race galaxy.
  619.  
  620. Problem:
  621. Netrek is a descendant of Empire, which had four warring races.  However,
  622. Netrek games typically have only two races fighting each other, so the rest
  623. of the planets are just worthless junk.  This increases network/CPU overhead,
  624. and leads to 3rd-race scumming.
  625.  
  626. Proposal:
  627. Remove two of the races.  Leave Fed/Rom, or Rom/Kli (with a reorg of KLI
  628. space).
  629.  
  630. Why Not:
  631. The other planets serve a variety of uses.  They can be used by scout bombers
  632. and planet takers for refueling and repair, and allow cloaking near hostile
  633. space.  It also allows 3rd-space scumming, but that's a different issue.
  634.  
  635. Most importantly, the size of the galaxy increases the area which needs
  636. to be defended.  If you reduce the galaxy to a two-way, it will be impossible
  637. to attack from or retreat to neutral space.  All offensive actions will take
  638. place in a single corridor, making starbases and large ships much more
  639. important.  Bombing and deep planet taking will become more difficult
  640. because there is a single path of attack.
  641.  
  642. Whether you think this is a good idea or not, there's no denying that it
  643. will dramatically change game strategies.  It is unlikely that such a
  644. proposal will be popular.
  645.  
  646.  
  647. 19) Add incentives for scout bombing.
  648.  
  649. Problem:
  650. Very few people are willing to SC-bomb because of the drain on stats (too
  651. much time away from taking planets).  Bombing 2 or 3 armies at a time doesn't
  652. really help the bombing stats much; ogging carriers may do more.
  653.  
  654. Proposal:
  655. Change the amount of bombing credit based on the number of armies sitting
  656. on the planet when bombing began.  So you'd get massive credit for bombing
  657. the last three armies, but not nearly as much for bombing it from 60 to 55.
  658.  
  659. Alternate proposal:
  660. Start all planets out at 5 or 6 armies.
  661.  
  662. Why Not:
  663. Both proposals suffer from the fact that average bombing stats have already
  664. been computed on most servers based on the "one army, one vote" scheme
  665. with 30 initial armies on each planet.  Changing the setup mid-stream would
  666. make it nearly impossible to get a 1.0 bombing rating.
  667.  
  668. It's also highly unlikely that anybody really concerned about rank is going
  669. to do much scout bombing anyway.  Advancing bombing at the expense of
  670. offense and planets is not a good way to scum up to Admiral.
  671.  
  672. The alternate proposal also affects the ability of a starbase to fill up
  673. with 25 armies at the start of a game.  Overall, the second proposal will
  674. likely have a dramatic impact on the way the first few minutes of a game
  675. are played - something that isn't likely to go over too well with the "old
  676. timers."
  677.  
  678.  
  679. 20) Protect ships that are fully lagged.
  680.  
  681. Problem:
  682. When a client becomes seriously lagged, the player usually ends up getting
  683. snuffed by the first bozo who comes within visual range.
  684.  
  685. Proposal:
  686. Make a server mod so that ghostbusted players are invulnerable until the
  687. connection gets reestablished.
  688.  
  689. Why Not:
  690. >From: jch+@cs.cmu.edu (Jonathan Hardwick)
  691. >Subject: Re: Playing with lag
  692. >Date: 11 Aug 92 01:24:29 GMT
  693. >
  694. >Last time it came up, one objection I remember is that it would become
  695. >trivial to abuse.  Want to take that last planet?  Lock on, cloak, max
  696. >warp, and then yank the ethernet connector out of your machine.  Wait
  697. >30 seconds while the defenders waste all their fuel on you, and then
  698. >finally realize that you're in Protected Mode.  Stick the ethernet
  699. >connector back in, beam down your armies, genocide the galaxy.
  700. >
  701. >Or if you're worth less when in Protected Mode, just yank the ethernet
  702. >connector whenever death seems inevitable.
  703.  
  704. Depending on the implementation, you might be able to just hit ^Z and
  705. suspend your process.  When the client host's buffers fill up it'll look
  706. just like a network storm to the server host.  If all you want to handle
  707. is fully severed clients then you won't be solving the problem; the only
  708. time my client has been severed is when the server goes down (I can't do
  709. the "automatic reconnect" because I'm running through a firewall machine,
  710. so I *know* when I get completely dropped).
  711.  
  712.  
  713. 21) Credit kills appropriately.
  714.  
  715. Problem:
  716. The person who causes deaths doesn't always get the credit (e.g. F1 fires
  717. torps at R2; R2 dets; F0 dies from the detted torps.  Credit should go to
  718. R2 who did the detting, but currently goes to F1 who fired the torps.)
  719.  
  720. Proposal:
  721. Implement some fixes to make it work out right.
  722.  
  723. Why Not:
  724. This is actually a pretty good idea.  It won't affect the game much, and
  725. it makes things fair.  However...
  726.  
  727. It will change the game.  There were be situations where people who would
  728. have had kills will not got them, and vice versa.  Exact impact on the game
  729. needs to be better understood.
  730.  
  731. A similar idea is to have "kills" and "wins" be the same, for statistical
  732. purposes.  So killing a ship with 5 armies would get you 1.5 wins as well
  733. as 1.5 kills.  I don't know that this really does anything useful though.
  734.  
  735. Sturgeon II has some new rules implemented; see appendix A2.
  736.  
  737. If you would like to take it upon yourself to define a clear-cut set of rules
  738. AND modify a server, test it, AND THEN provide diffs for the rest of the
  739. world, you will probably see this change happen.  However, it's probably
  740. more than your average server deity wants to deal with.
  741.  
  742.  
  743. 22) Get rid of borgs!
  744.  
  745. Problem:
  746. Cyborgs are evil!  They're for loser weenies!
  747.  
  748. Proposal:
  749. Fully ban them.
  750.  
  751. Why Not:
  752. Well, this isn't really a "clever suggestion", but it appears so frequently
  753. that I figured I ought to mumble a few words of pseudo-wisdom.
  754.  
  755. Borgs are neat.  You can sit back and watch them destroy everything around
  756. you without moving a finger.  This is far more satisfying if the borg you
  757. are using is one that you have written yourself; you're testing your
  758. programming skills and algorithmic cleverness against others.  The ultimate
  759. is to write a fully automated android, like SFOP.
  760.  
  761. Some servers have "borg hours" so that people who want to use them can,
  762. and so that the authors can test them in battle.  If you don't like playing
  763. against borgs, find out which servers support them and when, and don't play
  764. during those times.
  765.  
  766. Generally speaking, people who use cyborgs are atrophying their own skills.
  767. Playing a borg and playing a regular client are two very different things;
  768. after a while you become accustomed to firing without aiming, and to having
  769. oggers snuffed by your auto-pressor and auto-phaser.  Going back to being
  770. stricly human can be a difficult experience.  For this reason, most
  771. experienced players don't use them.
  772.  
  773. They do make for an interesting change of pace, and it can be fun to sign
  774. on to a clueless server and munch newbies without breaking a sweat.
  775. "Borgtrek" is also amusing from time to time (100% borg games).
  776.  
  777. Cyborgs only become a problem when people sneak blessed borgs into human-only
  778. hours.  Usually they'll turn most of the offensive weaponry off, but they
  779. usually leave on special features like the ability to determine which players
  780. are carrying armies or special highlights on players with kills.  This gives
  781. them an advantage, as they can fight, fly, and be fully aware of what the
  782. other team is doing all at the same time (in some cases they can get
  783. information unavailable to the standard client).
  784.  
  785. If you really dislike borgs, go play somewhere else, consoling yourself with
  786. the fact that, if they try to play a standard client, they will fare far
  787. worse for their cyborg experience.
  788.  
  789.  
  790. 23) Change the names of the races or the planets.
  791.  
  792. Problem:
  793. Feds never fight Klingons, and who are these Orions, anyway?  The names
  794. are outdated and don't reflect Trek stuff.
  795.  
  796. Solution:
  797. Use Ferengi, Cardassians, or some other "real life" hostile races.  Change
  798. the names of some of the planets to reflect Star Trek stuff, i.e. use
  799. names like "Farpoint" and "Vulcan".
  800.  
  801. Why Not:
  802. The names of the races and the planets are ingrained into Netrek players.
  803. If somebody says "clear org", experienced players know where to go without
  804. even looking at the map.
  805.  
  806. Races are the same way.  Everyone who has played for a while is used to Rom
  807. being top left, Fed being lower right, etc.  People don't write, "K3 is
  808. scumming in lower-left space".  It's Fed space, and it always should be.
  809. Sure, people would get used to it after a while, but I don't think most
  810. people WANT to get used to it.  In a few situations it can be a real pain,
  811. such as when the first letter changes.  If you want to send a message to the
  812. other team, you have to use a different key.  It's also used in a lot of
  813. places in the code, so it'd be a pain to change (and if you didn't change
  814. the code, but rather just the external appearance, it'd be very confusing
  815. for people prying into the source code).
  816.  
  817. Remember what this document says up top: Netrek is not Star Trek, Netrek is
  818. not Real Life.  It's a game, with names chosen as convenient points of
  819. reference.  If you want to set up a server with California city names or
  820. campus buildings instead of star systems, feel free.
  821.  
  822.  
  823. 24) Add ship collisions.
  824.  
  825. Problem:
  826. It would be neat to have ships collide.
  827.  
  828. Proposal:
  829. Have ships either damage each other on collision or bounce off in some
  830. elastic manner.
  831.  
  832. Why Not:
  833. Bouncing ships would be, well, weird.  Crunching ships in a BB by rolling
  834. over them would be amusing, but probably wouldn't add much to the game.
  835.  
  836. However, there are more serious considerations.  First, consider what happens
  837. if you are cloaked ogging somebody, and collisions do damage.  Now you don't
  838. even need to uncloak to kill the other guy; just run into him.  Makes
  839. avoiding oggs nearly impossible, especially since you can't pressor the
  840. attacker away.
  841.  
  842. Second, suppose you are cloaked taking a planet.  As it is the defenders have
  843. to locate you and hit you with enough torps/phaser hits to blow you up.
  844. Escorts can det torps to keep their takers safe.  Collisions make it far
  845. easier to defend planets: whether the collisions bounce or do damage, planet
  846. defenders can simply cloak and fly over the planet and have a good chance of
  847. destroying you or at least knocking you off.  They don't even have to uncloak
  848. anymore, making it harder for the escorts to do something useful.  And if
  849. collisions bounce, you can just knock the escorts into the planet takers.
  850. Heck, if you want to defend a planet, just sit right in the middle, and
  851. nobody else can orbit.
  852.  
  853. This last issue is a strong reason for disallowing collisions between
  854. friendly players: you could never have more than about four people in orbit
  855. at once, and getting more than two in orbit would require a minor feat of
  856. coordination.
  857.  
  858.  
  859. 25) Give planets gravity or motion.
  860.  
  861. Problem:
  862. Planets are boring.
  863.  
  864. Proposal:
  865. Give planets a gravitational attraction.  Also, make them move around, perhaps
  866. in some sort of localized circular pattern.
  867.  
  868. Why Not:
  869. Gravity is really sort of silly.  It won't do anything but make it harder
  870. to get away from a planet.  Might be useful for dodging sideways or running,
  871. but you either need to make it too weak to be interesting or too strong
  872. to be playable.
  873.  
  874. Moving planets is harder than it seems.  The client wasn't designed to allow
  875. planets to move.  You will also increase the amount of network traffic (by
  876. quite a bit, since planet positions are currently only sent right after you
  877. log on) and the CPU load, which are Bad Things.  It really isn't all that
  878. exciting anyway.  It can change the galaxy around making Kli or Ori space
  879. more "fair", but any serious amount of movement will have to be carefully
  880. tested so you don't end up with cluster-galaxies and huge neutral zones.
  881.  
  882.  
  883. 26) Show the list of players or a "rank weighting" on entry.
  884.  
  885. Problem:
  886. Teams are often unbalanced, because people must blindly choose which team
  887. to join.
  888.  
  889. Proposal:
  890. Display the list of players, or at least some sort of rank distribution,
  891. to players entering the game.  That way they can choose teams to even them
  892. out.
  893.  
  894. Why Not:
  895. People don't choose the less-clued team as a rule.  Should they?  Yes.  Do
  896. they?  No.  Why?  Well, they may be rank scums who want some easy targets
  897. (undefended planets, easy kills, etc), or they may just be sick and tired
  898. of playing on clueless teams.  It gets frustrating after a while when you
  899. get killed with 6 armies behind your home planet by four oggers while your
  900. teammates do nothing but shoot torps at you because they think you're a
  901. bad guy (yes, this has happened to me).
  902.  
  903. It's also difficult to force people onto one team or another; considering
  904. that rank is generally not a good indication of skill, solving the problem
  905. of "what team should I assign this person to" is about as hard as making
  906. DI meaningful.
  907.  
  908. Incidentally, it IS possible to see a player list before you enter the game.
  909.  
  910.  
  911. 27) Set up an invitation-only clue server.
  912.  
  913. Problem:
  914. There are so many clueless weenies flying around that I'm not having fun
  915. anymore.
  916.  
  917. Proposal:
  918. Set up a clue-only server.  Access would be by invitation only, with players
  919. selected by the admin or invited automatically after achieving a certain rank
  920. on certain servers.
  921.  
  922. Why Not:
  923. It's been tried.  auk.warp.cs.cmu.edu was run this way, and nobody ever
  924. played there.
  925.  
  926. There are two fundamental problems with the proposal.  First, the invitation
  927. mechanism is bad.  Either the server admin has to spend a fair amount of time
  928. adding players and passwords, or it has to be done automatically.  However, as
  929. discussed earlier, rank is a horrible indication of clue, talent, and skill.
  930. Automated systems will be prone to adding clueless players with lots of hours
  931. or missing clueful players who just don't care about rank (or reset their
  932. stats).
  933.  
  934. Even if that were solved, there's another problem: it's not easy to get 16
  935. clueful players in one place at one time.  Players come in and out constantly.
  936. I personally play whenever I (a) have the time and (b) feel like it; I'm
  937. not likely to turn up at a specified hour on a specified server on a
  938. specified day (if I could fit that into my week, I'd be on an INL team).
  939. Getting it organized is a pain and is just too inconvenient for the players
  940. to make it worth doing.
  941.  
  942. auk failed miserably because nobody worked to get the players there (apparently
  943. it was also a bit on the slow side).  If you propose this, be prepared to
  944. accept the burden of organizing it.  Many people have said, "somebody should
  945. do this", but nothing will happen until "somebody" steps up and does it.
  946.  
  947. If you want to set one up, feel free, but don't expect much UNLESS you are
  948. willing to spend a LOT of time massaging the player database, sending e-mail
  949. to players, and doing general organizational stuff.
  950.  
  951.  
  952. 28) Allow ships to drop mines.
  953.  
  954. Problem:
  955. There just aren't enough ways to kill things.
  956.  
  957. Proposal:
  958. Allow ships to drop mines which explode when you run into them.
  959.  
  960. Why Not:
  961. The first thing to ask yourself is, what good are they?  A new way to
  962. runner scum?  Maybe it's supposed to garrison an SB or planet?  Or is it
  963. just a new toy add for the hell of it?
  964.  
  965. They aren't really all that useful unless you want to give them serious
  966. damage capability (say 150 points - otherwise I'll come by in an AS and soak
  967. up half a dozen), in which case they'll be used either while running away at
  968. maxwarp or during oggs, essentially giving you a single big torp.  If you
  969. make them more expensive than torps, they won't get used here, but when will
  970. they be used?
  971.  
  972. Guarding an SB?  Just steer around them, or send a suicide minesweeper in.
  973. For a planet?  Maybe.  It might slow down SC-taking.  If they can be destroyed
  974. with phaser shots though then they're pretty much worthless.  On the other
  975. hand, during an LPS you could have everyone on your team drop a mine on the
  976. home planet, making it impossible to take.
  977.  
  978. One proposal was to allow SBs to either fire torps or mines (i.e. you would
  979. choose on an individual basis whether what you fire is going to be a torp or
  980. a mine).  This restricts the #of mines active by essentially crippling the
  981. starbase every time it drops one.  It also requires that the team HAVE an SB
  982. for them to work at all.  Something like this was tried on Calvin.
  983.  
  984. At any rate, all mine proposals have one major flaw: how to display them.
  985. Unless you want to force a change to the client code, you have to represent
  986. them with a player's torps, plasmas, etc.  Unfortunately these tend to look
  987. just like vestigal torps which were "forgotten" by a UDP connection, so
  988. remote players tend to slam into them (or end up swerving around bogus torps).
  989. If you want to get fancy (say, have two standard torps orbiting each other)
  990. you will be using two torps per mine (which might not be a bad thing).
  991.  
  992. If you're going to propose this, you need to consider:
  993. - who gets them (ship type, #of kills, rank)
  994. - how many each person/team gets
  995. - how they are drawn (plasma, photon, phaser, Iggy?)
  996. - how they are removed (only on collision, at request of "owner", when
  997.   phasered, when plasmaed, after n seconds)
  998. - how much damage they do (point-blank damage + blast radius)
  999. - whether or not they can be tractored/pressored/beamed
  1000. - whether they can be dropped while cloaked (VERY bad idea)
  1001. - who causes them to explode (other team, everyone, all != owner, non-cloakers,
  1002.   just cloakers, other exploding mines)
  1003. - who takes damage (other team, everyone, all != owner)
  1004.  
  1005. The really hard part is making them useful but not abuseable.
  1006.  
  1007.  
  1008. 29) Have the client update the torps instead of the server.
  1009.  
  1010. Problem:
  1011. A lot of network traffic is spent sending torp updates.
  1012.  
  1013. Proposal:
  1014. This could be avoided by just sending the "start" packet with direction and
  1015. speed, and sending an "end" packet when the torpedo dies.
  1016.  
  1017. Why Not:
  1018. The main difficulty is losing synchronization with the server.  If a "torp
  1019. death" packet is lost or delayed, the position of the torpedo will be
  1020. inaccurate because of torp wobble or possible early expiration.  It might
  1021. reduce net traffic, but it could be really confusing.
  1022.  
  1023. The biggest obstacle is "torp wobble", which is a random change in direction
  1024. added every update.  If the client misses an update, the torp will continue
  1025. off in the previous direction until the next update arrives, at which point
  1026. it will jerk back on course.  This can be worked around by sending a random
  1027. number seed to the client, and then having the client emulate the wobble,
  1028. but this is just making more work for the client and creating the opportunity
  1029. for borgs to accurately predict wobbling torps.
  1030.  
  1031.  
  1032. A1) Appendix: Sturgeon II changes
  1033.  
  1034. This comes from the motd (Message Of The Day) on sturgeon.cs.washington.edu,
  1035. port 2592.
  1036.  
  1037. -----
  1038. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
  1039.       The Experimental Server at the University of Washington, 24 hrs
  1040.  
  1041.                           UDP 1.0 compatible.
  1042. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
  1043.  
  1044. 9/14/92: NEW UPGRADES.  Read on...
  1045.  
  1046. Borgs : Allowed, but if others ask you not to, please comply.
  1047. UDP   : Supports UDP 1.0.  Please use UDP clients, especially from the
  1048.         UW computers Wolf, Lynx, Hardy, Shelley.
  1049. SCUM  : T-mode scumming will not be tolerated.  Upgrade-scumming is
  1050.     strongly discouraged (i.e., please don't bring in a second
  1051.     character to kill for upgrades, if you plan on playing with
  1052.     others, keeping your rank, etc).
  1053.  
  1054.      'telnet sturgeon 2591' does a ck_players.
  1055.  
  1056. Mail compliments (and complaints/bugreports) to tsang@cs.washington.edu
  1057.  
  1058. TO ENTER GAME TYPE:
  1059.           [s]  Scout             [a]  Assault Vessel (planetary)
  1060.           [d]  Destroyer         [b]  Battleship
  1061.           [c]  Cruiser           [o]  Outpost/Starbase
  1062.  
  1063. Press 'R' in this screen to reset your stats.
  1064. Press 'f' and 'b' to page through news and instructions.
  1065.  
  1066.  
  1067. This server has a lot of changes.  I shall try to describe all the ones
  1068. I can remember making.  There may be a couple more.
  1069.  
  1070. (1) Phasers have longer range, but damage does not decrease linearly, but
  1071.     rather with the square of the range.  They're faster on bigger ships.
  1072.  
  1073. (2) Only starbases and battleships can fire a stream of 8 photon torps.
  1074.     Cruisers are limited to six, destroyers five, assault ships four,
  1075.     and scouts three.  Starbases have fighters too (hit "C" to toggle)
  1076.  
  1077. (3) Photon torpedos are identical for all ships, in terms of fuel cost,
  1078.     damage, fuse, and weapon temperature.
  1079.  
  1080. (4) Phasers do double damage to shields, and photons double damage
  1081.     to "hull" (damage points).  Example: 15 point phaser hit to shields
  1082.     of 20 will reduce the shields to 0 with the first 10 pts, and do 5
  1083.     hull points with the remainder.  Not many ships can take more than
  1084.     one torp hit to downed shields.
  1085.  
  1086. (5) All ships can fire torps while cloaked, at 5x normal cost (300 x 5)
  1087.  
  1088. (6) Cloaking enemies will be revealed for a short time if (a) they get
  1089.     hit by a torpedo, (b) they get hit by phasers with their shields up,
  1090.     or (c) you detonate your own torpedos, to show them in a radius.
  1091.  
  1092. (7) Upgrades.  If you refit to the same ship type, you can "upgrade"
  1093.     some aspects of your ship, in return for kills.  If you refit
  1094.     to another ship type, you regain most of your "used up" kills.
  1095.     
  1096. (8) Plasma torps now "cost" 2.0 kills.  They only take two seconds
  1097.     to upgrade.  They are "upgrade 2", and are *not* automatic for
  1098.     refits from ships with 2+ kills.
  1099.  
  1100. (9) Scouts don't bomb; they strafe.  While this is much less time
  1101.     efficient, the advantage is that they can strafe until a planet
  1102.     has less than TWO armies.
  1103.  
  1104. (A) Planets now have variable resources.  Home planets (Ear, Rom, Kli, Ori)
  1105.     are always Fuel/Repair/Agri, and Core planets are always Agri.  Any
  1106.     planet with less than 10 armies is Agri; from 10-19 it is Fuel, from
  1107.     20-39 Repair, and Fuel/Repair from 40 on up.
  1108.  
  1109. (B) Phasers can be fired before they fully recharge.  This costs the same
  1110.     amount of fuel, but does less damage.
  1111.  
  1112. (C) The base number of kills received is equal to (Hull points of victim) /
  1113.     (Your hull points).  Thus, a scout destroyed by a cruiser is only worth
  1114.     0.75 kills, while the cruiser is worth 1.33 to the scout.
  1115.  
  1116.  
  1117. UPGRADES
  1118. --------
  1119.  
  1120. To upgrade, have available kills and orbit your home planet.  Refit to
  1121. the same ship type, and a menu will come up on your messages display.
  1122. Press the number corresponding to the upgrade you want.  The kills will
  1123. be deducted from the number available, and your ship will be upgraded
  1124. (with some amount of refit time, depending on the upgrade).
  1125.  
  1126. In all menus, press 0 (or a non-number) to abort.
  1127.  
  1128.  From the Main Menu, 1 works the same as the classic refit (fixes damage,
  1129. shields, fuel, wtemp, etemp).
  1130.  
  1131. Upgrades cost k1 + k2 * (previous upgrades of same type) kills, listed
  1132. as (k1/+k2), and your ship will be nonresponsive for that many seconds.
  1133.  
  1134. Upgrades include:
  1135.  
  1136.  - Shields            +10 pts to your shield maximum                 (1.0/ 0.0)
  1137.  - Fuel capacity      +250 fuel maximum                              (0.5/ 0.0)
  1138.  - Fuel recharge      +10 fuel/sec                                   (0.5/+0.5)
  1139.  - Max Speed          +1 to maximum warp speed                       (2.0/+1.0)
  1140.  - Acceleration       +0.1 warp/sec acceleration                     (0.5/+0.1)
  1141.  - Deceleration       +0.1 warp/sec deceleration                     (0.5/ 0.0)
  1142.  - Engine Cooling     +10 engine temp cooling/sec                    (1.0/+0.5)
  1143.  - Phasers            +3 to point-blank damage                       (1.0/+1.0)
  1144.  - Photons            +1 to photon torpedo *speed* (base is 15)      (3.0/+2.0)
  1145.  - Weapon Cooling     +10 weapon temp cooling/sec                    (2.0/+2.0)
  1146.  - Cloaking Device    halve the fuel cost (round up)                 (2.0/+1.0)
  1147.  - Tractor/Pressor    +100 tractor/pressor strength                  (1.0/+0.5)
  1148.  - Damage Control     +1 damage repair/sec                           (1.0/+1.0)
  1149.  
  1150. Commodities: upgrades that are "no deposit, no return"...
  1151.  
  1152.  - Overload shields   +50 pts to your current shields, one use only  (1.0/ 0.0)
  1153.  
  1154.  - Pseudoplasma        0  pt plasma (12)                             (1.0/ 0.0)
  1155.  - Type 1 Plasma       50 pt plasma (12)           All plasmas cost: (2.0/ 0.0)
  1156.  - Type 2 Plasma       75 pt plasma ( 6) 
  1157.  - Type 3 Plasma      100 pt plasma ( 4)
  1158.  - Type 4 Plasma      125 pt plasma ( 3)
  1159.  - Type 5 Plasma      150 pt plasma ( 2)
  1160.  
  1161.  - 10 megaton nuke    Just like in Nuclear War (1 army = 1 million)  (1.0/ 0.0)
  1162.  - 20 megaton nuke    The tables have been duplicated, except for    (2.0/ 0.0)
  1163.  - 50 megaton nuke      the "destroy the solar system", which may    (4.0/ 0.0)
  1164.  - 100 megaton nuke     later...                                     (8.0/ 0.0)
  1165.  
  1166. Plasmas cost no fuel to fire.  Nukes take up (1/2/3/4) army bays until used.
  1167.  
  1168. Switch between special weapons with the "C" key.
  1169. -----
  1170.  
  1171.  
  1172. A2) Appendix: Sturgeon II kill credit rules
  1173.  
  1174. -----
  1175. (a) You can get credit, but never actual kills, for killing your teammates.
  1176.  
  1177.     Example: F0 phasers R1, who explodes on F2.  F0 gets credit for killing
  1178.     both R1 and F2, but only actually gets kills for R1.
  1179.  
  1180. (b) Except in the case of a point-blank plasma explosion, you never get
  1181.     credit for killing yourself.  In that exceptional case, refer to (a).
  1182.  
  1183.     Example: F0 oggs R1.  R1 explodes, and takes F0 with him.  Each gets
  1184.     credit and kills for the other (posthumously)
  1185.  
  1186. (c) If you det someone's torp, or phaser someone's plasma, any deaths
  1187.     that result are credited to you, except your own.  Your own death
  1188.     is credited to the person who fired the torp or plasma.
  1189.  
  1190. (d) If you are credited with someone's death, anyone who dies as a
  1191.     direct result of that explosion is credited to you (except
  1192.     yourself, as above)
  1193. -----
  1194.  
  1195. -- 
  1196. fadden@uts.amdahl.com (Andy McFadden)
  1197. [ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
  1198.