home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / games / netrek / suggestions / part1 next >
Encoding:
Text File  |  2001-12-03  |  38.3 KB  |  1,037 lines

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hub1.nntpserver.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news2.best.com!nntp1.ba.best.com!not-for-mail
  2. From: doosh@best.com (Tom Holub)
  3. Newsgroups: rec.games.netrek,rec.answers,news.answers
  4. Subject: rec.games.netrek Frequently Offered Clever Suggestions list, Part 1/2
  5. Supersedes: <netrekFOCS.1_1004702400@best.com>
  6. Followup-To: rec.games.netrek
  7. Date: Sun, 2 Dec 2001 12:01:08 +0000 (UTC)
  8. Organization: The ISP formerly known as Best
  9. Lines: 1015
  10. Approved: news-answers-request@MIT.Edu
  11. Distribution: world
  12. Message-ID: <netrekFOCS.1_1007294401@best.com>
  13. References: <netrekFAQ_1007294401@best.com>
  14. Reply-To: doosh@best.com
  15. NNTP-Posting-Host: shell3.ba.best.com
  16. Content-Type: text/html
  17. X-Trace: nntp1.ba.best.com 1007294468 50802 206.184.139.134 (2 Dec 2001 12:01:08 GMT)
  18. X-Complaints-To: abuse@best.com
  19. NNTP-Posting-Date: Sun, 2 Dec 2001 12:01:08 +0000 (UTC)
  20. Xref: senator-bedfellow.mit.edu rec.games.netrek:79264 rec.answers:70337 news.answers:220242
  21.  
  22. Archive-Name: games/netrek/suggestions/part1
  23. <html>
  24.  
  25. <title>Netrek Frequently Offered Clever Suggestion List</title>
  26.  
  27. <BODY BGCOLOR="#FFFFFF" TEXT="#111100" LINK="#336699" ALINK="AA0000"
  28. VLINK="#996600">
  29.  
  30. <h2 align="center">Netrek Frequently Offered Clever Suggestion list</h2>
  31.  
  32. Archive-Name: games/netrek/suggestions/part1<br>
  33. Last-Updated: 16 Mar 1997<br>
  34. Changes: Converted to HTML, made significant updates to a number of questions,
  35.      added question about a shared player database.<p>
  36.  
  37.  
  38. <i>Note: This was written by Andy McFadden but is now being maintained by me
  39. along with the other FAQ lists.  Many thanks to Andy for compiling it
  40. (in addition to his other contributions to the netrek world).</i>
  41. <p>
  42.  
  43. The same ideas get proposed over and over by people trying to enhance the
  44. game, and the same discussions come up again and again.  This file is an
  45. attempt to stem the flow by presenting old discussions and arguments
  46. against the ideas.
  47. <p>
  48.  
  49. This assumes you are familiar with the game itself and some of the
  50. vocabulary (argot) involved (e.g. scum, ogg, LPS, Iggy).  This is NOT
  51. intended to be a capsule summary of rec.games.netrek discussions; it is
  52. intended to help people trying to enhance the game understand why many of
  53. the obvious improvements won't work or won't be accepted by the Netrek
  54. community.  As such, it contains one-sided and occasionally opinionated
  55. material.  I welcome improvements and stronger arguments, but if you want
  56. to debate the value of something I will probably ignore you.
  57. <p>
  58.  
  59. [ This file has been evolving since September of 1992.  Some of the info
  60. may have become outdated as Netrek evolved. ]
  61. <p>
  62.  
  63. REMEMBER: Netrek is not Star Trek.  Netrek is not reality.  Star Trek is
  64. not reality.  Netrek is not Nintendo.  DO NOT suggest modifications purely
  65. to make the game "more realistic".  ONLY consider ideas that will improve
  66. game play.
  67. <p>
  68.  
  69. <h3>Contents</h3>
  70. <a href="#1">
  71. 1. How about team DI?
  72. </a><br><a href="#2">
  73. 2. How about no DI at all (+ changes in general)?
  74. </a><br><a href="#3">
  75. 3. All ships shouldn't fire 8 torps.
  76. </a><br><a href="#4">
  77. 4. Let's make cloakers blind.
  78. </a><br><a href="#5">
  79. 5. Let's allow cloakers to fire.
  80. </a><br><a href="#6">
  81. 6. The DD needs to be improved.
  82. </a><br><a href="#7">
  83. 7. Here's a neat idea for a new ship.
  84. </a><br><a href="#8">
  85. 8. How about a ship design system?
  86. </a><br><a href="#9">
  87. 9. Remove the kill restriction on army carrying.
  88. </a><br><a href="#10">
  89. 10. Remove the kill restriction on plasma torps.
  90. </a><br><a href="#11">
  91. 11. Get rid of LPSs.
  92. </a><br><a href="#12">
  93. 12. Get rid of Iggy!
  94. </a><br><a href="#13">
  95. 13. Combine all of the server processes into one.
  96. </a><br><a href="#14">
  97. 14. Put the number of armies next to the planet.
  98. </a><br><a href="#15">
  99. 15. Highlight ships with kills.
  100. </a><br><a href="#16">
  101. 16. Prevent bombing/taking out of T-mode.
  102. </a><br><a href="#17">
  103. 17. Just have a two-race galaxy.
  104. </a><br><a href="#18">
  105. 18. Add incentives for scout bombing.
  106. </a><br><a href="#19">
  107. 19. Protect ships that are fully lagged.
  108. </a><br><a href="#20">
  109. 20. Change the names of the races or the planets.
  110. </a><br><a href="#21">
  111. 21. Add ship collisions.
  112. </a><br><a href="#22">
  113. 22. Give planets gravity or motion.
  114. </a><br><a href="#23">
  115. 23. Set up an invitation-only clue server.
  116. </a><br><a href="#24">
  117. 24. Allow ships to drop mines.
  118. </a><br><a href="#25">
  119. 25. Have the client update the torps instead of the server.
  120. </a><br><a href="#26">
  121. 26. Have ships come in at the starbase instead of a planet.
  122. </a><br><a href="#27">
  123. 27. Ships should auto-repair at warp 0.
  124. </a><br><a href="#28">
  125. 28. Change the way the wait queue works.
  126. </a><br><a href="#29">
  127. 29. Add steering keys.
  128. </a><br><a href="#30">
  129. 30. Prevent butt-torping.
  130. </a><br><a href="#31">
  131. 31. Have a database that's shared between multiple servers.
  132. </a><br><a href="#A1">
  133. A1. Appendix: Sturgeon II changes
  134. </a><br><a href="#A2">
  135. A2. Appendix: Extreme Netrek
  136. </a><br><a href="#A3">
  137. A3. Appendix: How to propose a change
  138. </a>
  139.  
  140. <hr>
  141. <a name="1"><h4>
  142. 1. How about team DI?
  143. </h4></a>
  144.  
  145. <strong>Problem:</strong><br>
  146. Too many rank scums out there for themselves.  Need to add an incentive for
  147. team play, so that they will get more DI if their team does better.
  148. <p>
  149.  
  150. <strong>Proposal:</strong><br>
  151. Change the DI structure so that you get points for stuff your teammates do.
  152. Alternatively, change it so that you get points for different "team stuff",
  153. like taking strategically placed planets or killing carriers.
  154. <p>
  155.  
  156. <strong>Why not:</strong><br>
  157. Most "team DI" schemes will cause people to switch to the team that's
  158. winning, because that's where the points are.  It is possible right now to
  159. see the players on each team before making the initial team selection; this
  160. would make unfair teams the rule.
  161. <p>
  162.  
  163. Changing the individual values of things is difficult when you consider how
  164. the current DI scheme works.  "DI" is simply the sum of offense, bombing,
  165. and planet ranks, multiplied by the number of hours you have been playing,
  166. and then adjusted according to the global average.  There are no fixed DI
  167. values for doing certain things; just your relationship to the rest of the
  168. people on the server.
  169. <p>
  170.  
  171. If you try to reward players on teams that are doing well, people will
  172. quit when their team starts to lose, creating a steamroll effect (all
  173. the clued people join the winning side, all the non-clues stay on the
  174. losing side).  Keeping track of planets won/lost during a game is a nice
  175. idea, but will lead to a lot of quit-scumming when the other team is
  176. taking a planet or two.  Rank scums will always be scums; you can change
  177. the rules but they will always find annoying ways of working around them.
  178. <p>
  179.  
  180. Killing people with armies gives you (5*armies) bombing credit, and taking
  181. core planets is worth more than other planets, so the incentives exist;
  182. people are simply unaware of them or feel it is easier to do things the
  183. scum way.
  184. <p>
  185.  
  186. Incidentally, DI works like this:
  187. <p>
  188.  
  189. <li>There are three factors: bombing (the number of armies you have,
  190. bombed), offense (the number of enemies you have killed), and
  191. planets (the number of planets you have taken).  There's also defense
  192. (number of times you have been killed), but most servers have done
  193. away with the defense criteria since ogging became popular.
  194. <p>
  195.  
  196. <li>The server takes these values, considers how long it took you to
  197. get them, and then compares that against the server average.  From
  198. this you get "ratings", where having a 1.0 bombing rating means you
  199. bomb as many armies per unit time as the average player, 2.0 ratings
  200. mean you bomb twice as many, and so on.
  201. <p>
  202.  
  203. <li>The bombing, planet, and offense ratings are added.  This gives your
  204. total ratings.  An average player would have 3.0 ratings.
  205. <p>
  206.  
  207. <li>The ratings are multiplied by the number of hours you have spent in
  208. t-mode on that server.  This is your DI.
  209. <p>
  210.  
  211. Hitting 'U' (shift-u) while playing brings up a chart showing what ratings
  212. and how many hours you need to make a particular rank.  You can also promote
  213. if you don't have the ratings but have twice the DI, or if you're ratings
  214. are two points down and you have four times the DI.  You can't be demoted.
  215. <p>
  216.  
  217. Many players are under the misconception that you "get DI" for doing a
  218. particular action.  You don't.
  219. <p>
  220.  
  221. <hr>
  222. <a name="2"><h4>
  223. 2. How about no DI at all?
  224. </h4></a>
  225.  
  226. <strong>Problem:</strong><br>
  227. DI is a mistake.  It is the reason for scumming.
  228. <p>
  229.  
  230. <strong>Proposal:</strong><br>
  231. Toss it.  At least toss all the ranks above Captain.
  232. <p>
  233.  
  234. <strong>Why not:</strong><br>
  235. Many people like to advance in rank.  DI was developed because the original
  236. Xtrek had nothing but win/loss stats, so ratio scumming was the only way to
  237. look impressive (you think DI is bad... heh).  There are a large number of
  238. Admirals who like having their rank (hey, it took them a long time to get
  239. there), and some of them run servers.  DI is like the USA's electoral voting
  240. system: it's not great, and the country might be better without it, but it's
  241. not going away without a major fight.
  242. <p>
  243.  
  244. Besides which, it's a good way to attract [scum] players to new servers.
  245. <p>
  246.  
  247. Any change to DI is simply going to shift scumming one way or the other.
  248. Most arcade games are centered around the accumulation of points; the object
  249. is to do certain things, for which you rewarded.  The idea of Netrek, however,
  250. is to win the game; rank should be just an incidental feature.  However,
  251. there will always be those who see the accumulation of points, rank, or
  252. whatever as the driving goal.
  253. <p>
  254.  
  255. The Holy Grail of DI changing is a system that rewards only non-scum
  256. activities.  However, telling scumming from teamwork requires human
  257. intervention or artificial intelligence in most cases.
  258. <p>
  259.  
  260. <strong>Jean-Marc Tanzi writes:</strong><br>
  261. >I believe that any team game, like netrek, where a machine could
  262. >really compute how well you play cannot be that good.
  263. <p>
  264.  
  265. <strong>Other interesting ideas:</strong><br>
  266. <li>Have players promote each other.  Once you get to a certain rank, you can
  267. promote those beneath you.  This has a chicken & egg problem which can be
  268. solved by importing a database or with some active administration at first.
  269. Note this is open to abuses (demoting people you don't like, promoting
  270. really lame players to embarass them, etc), and tends to trivialize rank.
  271. Tried on b62150.student.cwru.edu, never widely accepted.
  272. <p>
  273.  
  274. <li>Shift planet credit so that you get partial credit for making it neutral
  275. and partial credit for taking it.  This is accomplished by (for example)
  276. multiplying everybody's planet rating by 3 and then awarding 1 for neuting
  277. and 2 for taking.  Since the global average is also multiplied by 3,
  278. player ratings don't change, so DI is constant.  Tried on
  279. bigbang.astro.indiana.edu (now lexus).  Doesn't seem to significantly
  280. change the game.
  281. <p>
  282.  
  283. <hr>
  284. <a name="3"><h4>
  285. 3. All ships shouldn't fire 8 torps.
  286. </h4></a>
  287.  
  288. <strong>Problem:</strong><br>
  289. The game is unbalanced.  SBs should be able to shoot more torps than others.
  290. Maybe SCs shouldn't be able to shoot as many.
  291. <p>
  292.  
  293. <strong>Proposal:</strong><br>
  294. Increase SB torps to 12, or scale all others accordingly.
  295. <p>
  296.  
  297. <strong>Why not:</strong><br>
  298. Going to 12 torps requires mods to both client and server.  This will increase
  299. CPU time slightly, and will increase network usage.  You can't just switch
  300. on the ship type, either, because a SB could fire 12 torps and then refit.
  301. <p>
  302.  
  303. Scaling all ships down (so that an SC would fire, say, three torps total)
  304. has been tried on Sturgeon; see <a href="#A1">appendix A1.</a>
  305. <p>
  306.  
  307. Any change to the ship characteristics is going to be met with a great deal
  308. of resistance.  The game is very carefully balanced, and any changes can
  309. result in drastic changes in the way it's played.
  310. <p>
  311.  
  312. <hr>
  313. <a name="4"><h4>
  314. 4. Let's make cloakers blind.
  315. </h4></a>
  316.  
  317. <strong>Problem:</strong><br>
  318. Cloaking is too powerful.  Ogging is getting out of hand.
  319. <p>
  320.  
  321. <strong>Proposal:</strong><br>
  322. Remove certain items from the tac display of a cloaked ship, like enemy
  323. ships, planets, torps, etc.
  324. <p>
  325.  
  326. <strong>Why not:</strong><br>
  327. Been done.  Not very popular.  Removing planets makes them hard to take
  328. (you just sit there watching your 'O' flag, hoping that nobody will kill
  329. you because they KNOW you are coming straight in).  Removing torps is bad
  330. for the same reason.
  331. <p>
  332.  
  333. Removing other players to make ogging harder is bad because most players
  334. LIKE ogging.  It's fun, and it's part of the game. 
  335. <p>
  336.  
  337. It turns out that this is a good example of why not to change the rules of
  338. the game.  As people have gotten better at phaserlocking and being aware
  339. of the galactic, ogging has become very difficult; where it used to 
  340. dominate strategy, now most top teams actively avoid cloaking in most
  341. situations.  
  342. <p>
  343.  
  344. <hr>
  345. <a name="5"><h4>
  346. 5. Let's allow cloakers to fire.
  347. </h4></a>
  348.  
  349. <strong>Problem:</strong><br>
  350. Now that Star Trek VI is out, cloakers (esp. Kli) should be able to fire.
  351. <p>
  352.  
  353. <strong>Proposal:</strong><br>
  354. Allow ships to fire when cloaked, possibly with a higher fuel or wtemp cost.
  355. <p>
  356.  
  357. <strong>Why not:</strong><br>
  358. Gimme a break.  Ogging would become trivial without changes to other parts
  359. of the game.  See the Sturgeon changes in <a href="#A1">Appendix A1.</a>
  360. <p>
  361.  
  362. <hr>
  363. <a name="6"><h4>
  364. 6. The DD needs to be improved.
  365. </h4></a>
  366.  
  367. <strong>Problem:</strong><br>
  368. The DD is weak.  It can't take bomb as well as an SC, and it can't fight as
  369. well as CA.
  370. <p>
  371.  
  372. <strong>Proposal:</strong><br>
  373. Give the DD bigger shields, or bigger torps (30 is too small), or more
  374. powerful phasers, and perhaps a bigger fuel tank.
  375. <p>
  376.  
  377. <strong>Why not:</strong><br>
  378. As Tom Holub put it (paraphrased), "The CA is weak.  It can't bomb as well
  379. as a DD, and it can't fight as well as a BB."  All ships have their place,
  380. it's just a question of finding the right niche.  DDs can carry 5 armies,
  381. making them more of a threat to planets than the SC.
  382. <p>
  383.  
  384. Several discussions have raged over rec.games.netrek about what the One True
  385. Use of the DD is.  None have been found.  They can't be used as a big SC
  386. nor as a small CA; they require a different perspective.  I won't offer
  387. them here, but will instead relegate it to the thrice-revised DD Players Guide.
  388. <p>
  389.  
  390. As a side note, the cooling rate on DDs was changed from 6 to 7, allowing
  391. them to go great distances without overheating.  Many players who previously
  392. thought the DD fully worthless now consider it to be valuable in certain
  393. circumstances.  This is another example of changes in play styles affecting
  394. perception of the game; DD cooling was originally changed from 7 to 6
  395. because DD's were considered too powerful.
  396. <p>
  397.  
  398. <strong>Newer, alternative proposals:</strong><br>
  399. <li>make the CA weaker, by reducing phaser strength or manuverability (but
  400. then the SC gets correspondingly stronger) [implemented on bigbang]
  401. <p>
  402.  
  403. <li>have a reentry delay based on ship size (again, the SC gets stronger, plus
  404. no one wants to spend time looking at the entry screen.
  405. <p>
  406.  
  407. <li>give the DD mondo plasmas, making it a special-purpose ship
  408. <p>
  409.  
  410. <li>remove the DD entirely so people stop whining
  411. <p>
  412.  
  413. I (the pronoun "I" is somewhat ambugious in this document, as I, Tom Holub,
  414. have not removed all of Andy McFadden's "I"s) am personally of the opinion
  415. that there isn't space for a full-time ship in between the current CA and
  416. the current SC--any ship between the two will be either useful only in 
  417. spots, or will be powerful enough to make one of the others obsolete.  I
  418. don't think this is a bad thing. 
  419. <p>
  420.  
  421. <hr>
  422. <a name="7"><h4>
  423. 7. Here's a neat idea for a new ship.
  424. </h4></a>
  425.  
  426. <strong>Problem:</strong><br>
  427. There's a gap in Netrek that really needs to be filled.
  428. <p>
  429.  
  430. <strong>Proposal:</strong><br>
  431. I want a new ship X that can do Y and Z.
  432. <p>
  433.  
  434. <strong>Why not:</strong><br>
  435. KSU-Galaxy/Chaos servers are a prime example of ship design run amok.  The
  436. GA had huge torps, fast phasers, an incredible refueling rate, and eventually
  437. they even boosted the manuverability on some servers.  As a result, nobody
  438. played anything but GA (there were some DD holdouts, but once you could turn
  439. in GA at a reasonable warp most of those switched over).
  440. <p>
  441.  
  442. You may think your new design will fit perfectly into Netrek.  You're
  443. probably wrong.  Some examples from the past:
  444. <p>
  445.  
  446. <li>mini-starbase.  Like your normal SB, but less filling.  You'd get a couple
  447. on a team, or maybe just have them more often.  Two of these together,
  448. pressoring each other out of danger, would be damn near invincible when
  449. guarding a repair planet.  It's basically a Super Planet Defender, like
  450. a BB on steroids, and it really wouldn't add anything new to the game,
  451. since it's easier to ogg than an SB and slower than a BB.
  452. <p>
  453.  
  454. <li>fighters.  SBs would launch these, perhaps they'd be robot-controlled.
  455. Again, neat idea, but so what?  They would either have to occupy a player
  456. slot (reducing the number of other robots you can have) or require
  457. modifications to both client and server (which is a Bad Thing).  Again,
  458. what do they add?  Are they any different from plasma torps with a high
  459. tracking setting?  See the <a href="#A1">Sturgeon changes</a>, which 
  460. implemented them as slow-moving tracking torps, which SBs could fire instead 
  461. of normal torps.
  462. <p>
  463.  
  464. <li>floating fuel platform.  Another pseudo-SB, which looks like an AS but
  465. has fuel like an SB.  Easy ogg target; what good is it if you have to keep
  466. it sitting behind your home planet?  One BB can off the thing, so it's
  467. not even valuable as a distraction.
  468. <p>
  469.  
  470. <li>ogger ship.  Maybe it uncloaks fast (a la the old Calvin scheme), or it
  471. does 200 points of damage when it explodes, or it has small torps but a
  472. big phaser, or whatever.  Anybody who thinks they need this has never been
  473. ogged by somebody in a CA who knows what they're doing.  This would just
  474. make Ogging by Idiots that much easier.
  475. <p>
  476.  
  477. <li>super scout ship.  Strip off most offensive weaponry, make it real fast.
  478. What's the point?  Try stopping a good SC player, and THEN see if you
  479. really want to propose this.
  480. <p>
  481.  
  482. <li>big fat starbase.  This one has the actual size increased, making it easier
  483. to hit, but is given better shields to compensate.  So what's the point...?
  484. It would involve changing a lot of code in the server and client to special
  485. case the various options, plus new bitmaps (for shield/cloak as well),
  486. etc, etc.
  487. <p>
  488.  
  489. Many suggestions like these come from people trying to compensate for
  490. inadequacies in the ships (sounds vaguely Freudian, doesn't it?)  It takes
  491. time and a lot of practice to become a really effective player; even
  492. the lowly SC can be a marvelous dogfighting ship when it's flown by a
  493. skilled player (with no lag).
  494. <p>
  495.  
  496. The "paradise" server introduced a number of new ships, but it also changed
  497. a LOT of other game features, and required a new client to play.  One was
  498. the "jump ship", which could carry 4 players and go warp 30, but had only
  499. 25 shields and 25 damage.  (Paradise continues to be refined, so I'm not
  500. going to try and describe their setup.)
  501. <p>
  502.  
  503. <hr>
  504. <a name="8"><h4>
  505. 8. How about a ship design system?
  506. </h4></a>
  507.  
  508. <strong>Problem:</strong><br>
  509. Other games (e.g. xtank) allow you to change the way your ship is set up.  I
  510. want to be able to adjust my ship characteristics according to the way I play.
  511.  
  512. <strong>Proposal:</strong><br>
  513. Allow ship characteristics to be adjusted by the player.
  514.  
  515. <strong>Why not:</strong><br>
  516. This was implemented in a version of the original Xtrek game.  The tendency
  517. was to do things like strip all torpedos, most of the hull, half of the
  518. engines, and all of the cloaking ability from the ship and get phasers that
  519. could do 40 points of damage to ships outside of visual range (but had to
  520. be orbiting a fuel planet to fire more than twice).
  521. <p>
  522.  
  523. Games quickly became ridiculous.  Either your planets were being taken by
  524. someone completely invisible, or you were getting destroyed by ships you
  525. couldn't see.  Nobody bothered dodging, because nobody fired torps.  
  526. Basically, this winds up removing strategic aspects from the game in
  527. favor of tactical aspects, and that's not a good thing.
  528. <p>
  529.  
  530. Any implementation will require carefully balanced limits and a lot of play
  531. time before it would become widespread.  Anyone who wishes to try this will
  532. likely have to set up their own server and then try very hard to attract
  533. players to it.
  534. <p>
  535.  
  536. As a side note, <a href="#A1">Sturgeon</a> has a feature somewhat like this: 
  537. predefined ship upgrades after you get kills.  Unfortunately this can (and 
  538. does) encourage ratio scumming and runner scumming, because nobody with a nice
  539. big fat ship wants to die.  (It also introduced "upgrade scumming" to the 
  540. world: repeatedly killing a second login to get lots of upgrades.)
  541. <p>
  542.  
  543. <hr>
  544. <a name="9"><h4>
  545. 9. Remove the kill restriction on army carrying.
  546. </h4></a>
  547.  
  548. <strong>Problem:</strong><br>
  549. Imposing a restriction based on kills is unrealistic and silly.
  550. <p>
  551.  
  552. <strong>Proposal:</strong><br>
  553. Allow any player to carry armies.
  554. <p>
  555.  
  556. <strong>Why not:</strong><br>
  557. If you allow this, you remove a big part of the challenge of the game.
  558. Getting a kill and staying alive while trying to move armies around is
  559. one of primary challenges in Netrek.  If anybody can carry armies, then
  560. every player is a potential planet taker, and it's impossible to focus
  561. the defense of your space.
  562. <p>
  563.  
  564. You will also increase the instances of Ensign Fubar scampering about,
  565. picking up armies and dying with them.  This is a Very Bad Thing when your
  566. team is low on armies.  If a player can't get a kill, he probably doesn't
  567. have the skill or experience to take a planet without getting nailed.
  568. <p>
  569.  
  570. (People who need practice taking planets need to practice staying alive first!)
  571. <p>
  572.  
  573. For those who insist on reality, it can be argued that Star Fleet Command
  574. doesn't like to entrust armies with commanders who haven't proven themselves
  575. in battle (especially Kli!)  It has also been suggested that the captains
  576. use the hull fragments of the enemy starships to build crew accommodations
  577. for the armies.
  578. <p>
  579.  
  580. <hr>
  581. <a name="10"><h4>
  582. 10. Remove the kill restriction on plasma torps.
  583. </h4></a>
  584.  
  585. <strong>Problem:</strong><br>
  586. Requiring kills for plasmas is silly.
  587. <p>
  588.  
  589. <strong>Proposal:</strong><br>
  590. Allow plasmas for one and all.
  591. <p>
  592.  
  593. <strong>Why Not:</strong><br>
  594. While this is a trivial server change (quick alteration to .sysdef), it's
  595. there for a reason, namely that having 8 battleships with plasma torps makes
  596. taking planets impossible.  LPSs would never end.  Chaos servers allowed
  597. infinite plasmas, and plasma-wars became rather common.  So did plasma-
  598. muggings (you can't shoot three incoming plasmas!)  The ping-pong plasmas
  599. made life interesting, but then there's not much point in taking planets
  600. on a Chaos server anyway.
  601. <p>
  602.  
  603. The way things are now, players with 2+ kills can be ogged, which prevents
  604. them from firing more plasmas.
  605. <p>
  606.  
  607. While it's true that the rich become richer (or perhaps the deadly become
  608. more deadly), there's nothing wrong with elitism in Netrek.  It's just a
  609. game.  Deal with it.
  610. <p>
  611.  
  612. <hr>
  613. <a name="11"><h4>
  614. 11. Get rid of LPSs.
  615. </h4></a>
  616.  
  617. <strong>Problem:</strong><br>
  618. LPSs suck.  They're boring and they make my stats hurt.
  619. <p>
  620.  
  621. <strong>Proposal:</strong><br>
  622. Various ideas.  A small sampling:
  623. <li>have a 5 second delay before players can reenter
  624. <li>have a delay inversely proportional to the number of planets your team has
  625. <li>enter moving away at maxwarp
  626. <li>have the presence of enemy ships force new ships to appear farther away
  627. (a la Plato Empire)
  628. <li>enter without fuel (this is also used as an anti-psycho-ogging "fix")
  629. <li>use the random entry planet selection stuff, extended to work on planets
  630. that the team doesn't own
  631. <li>allow a certain number of construction points per minute; big ships use
  632. more construction points; once exceeded, you have to wait for it to climb
  633. back up
  634. <li>genocide happens when only one planet remains
  635. <li>allow a ship with 5 or 10 kills to carry a MondoBomb; when it reaches the
  636. planet it obliterates it
  637. <li>turn an SC with 3 kills into Super Ogger, doing several hundred points of
  638. damage with its explosion
  639. <p>
  640.  
  641. <strong>Why Not:</strong><br>
  642. The Last Planet Stand is one of the few things in Netrek that absolutely
  643. REQUIRES teamwork.  It is nearly impossible to break an LPS unless the
  644. attackers are organized or the defenders are largely clueless.
  645. <p>
  646.  
  647. A reasonable solution to the Indefinite LPS (one that drags on and on
  648. because all the clued players on the attacking side bailed) is the Bronco
  649. LPS timer.  The attackers get 30 minutes to break it, at which point the
  650. galaxy resets.  There are players who dislike the timer because it encourages
  651. the attackers to slack off ("oh, we'll just wait for the timer, we'll never
  652. break through), but it's proven to be a reasonable compromise, although it
  653. has definitely reduced the average LPS-breaking ability.
  654. <p>
  655.  
  656. LPSs are here to stay.  It is possible to come back from one, just as it is
  657. possible to genocide a race.  If you are concerned about the damage to your
  658. stats, then set up your own server, scum your way to admiral, and get on
  659. with your life.
  660. <p>
  661.  
  662. Side note: LPSs with homeworld agris are monumentally unpopular.  You can
  663. hold off against a fleet with greater numbers without too much difficulty.
  664. Most servers explicitly prevent the home world from being agri; if your
  665. favorite server doesn't, tell the server admin.  (The other side of the
  666. coin is that, once taken, it's harder for the home team to retake.  I don't
  667. think this balances the pain of taking it in the first place, however.)
  668. <p>
  669.  
  670. <hr>
  671. <a name="12"><h4>
  672. 12. Get rid of Iggy!
  673. </h4></a>
  674.  
  675. <strong>Problem:</strong><br>
  676. Iggy is nothing but a pain.
  677. <p>
  678.  
  679. <strong>Proposal:</strong><br>
  680. Lose him.
  681. <p>
  682.  
  683. <strong>Why Not:</strong><br>
  684. Iggy is a Bronco server feature that adds a bit more randomness to the game;
  685. it's a robot that comes in at intervals and chases the nearest ship.  The
  686. only reason it ever made it into the normal server distribution is that
  687. the server god of bronco, Terence Chang, invented it, and the CMU weenies
  688. thought of it as their own.  Gladly, Iggy has now been removed from all major
  689. servers; robots come in only when players do stuff like take planets out
  690. of t-mode.
  691.  
  692. <hr>
  693. <a name="13"><h4>
  694. 13. Combine all of the server processes into one.
  695. </h4></a>
  696.  
  697. <strong>Problem:</strong><br>
  698. My workstation can't handle all the context switches.
  699. <p>
  700.  
  701. <strong>Proposal:</strong><br>
  702. Merge all the ntserv processes into one, and maybe even combine them with
  703. daemonII, so instead of the Server Union we'd have the Unified Process.
  704. <p>
  705.  
  706. <strong>Why Not:</strong><br>
  707. A few people have tried this.  There are advantages and disadvantages to
  708. doing this, not the least of which is that it requires a complete rewrite of
  709. the server, a partial to full rewrite of the client, and will work best as a
  710. strictly UDP implementation (which requires a whole new protocol).
  711. <p>
  712.  
  713. Among the disadvantages are the possible loss of the shared memory segment
  714. (which kills the traditional tool interface), the need to bring the server
  715. down whenever changes are made, the inability to simply restart failed
  716. components (ex: restartable daemon), changes in CPU load possibly resulting
  717. in lower UNIX process priorities (and thus worse real-time performance),
  718. changes in the way the kernel sees Netrek (e.g. waiting for I/O), poorer
  719. performance on MP machines, the larger executable will be more likely to be
  720. swapped out under BSD, loss of memory firewalls between components,
  721. possibility of security breaches in a UDP-only setup, etc, etc.
  722. <p>
  723.  
  724. There are a number of advantages, but this file is meant to discourage you,
  725. not entice you.  A reading of the process scheduling chapter in _The Design
  726. and Implementation of 4.3BSD UNIX_ should be required for anyone contemplating
  727. this.  It turns out to not be a big deal, anyway; all modern machines can 
  728. handle a full netrek server.
  729. <p>
  730.  
  731. Here's a note from somebody who once tried it:
  732. <p>
  733.  
  734. <pre>
  735. -----
  736. Article 11256 of rec.games.netrek:
  737. From: jrichard@cs.cs (John 'MacGyver' Richardson)
  738. Date: 30 Dec 92 05:31:11 GMT
  739.  
  740. [...]
  741. Ok, not to beat a dead dog, but I've been working on this for a while now.
  742. It was pretty easy to come up with multiplexed I/O for logging in.  HOWEVER,
  743. the big problems are: 
  744.  
  745.     o scheduling becomes a disaster!  However, I'm trying reading 
  746.       one packet from whoever's ready and going on to the next slot.
  747.       Updates taken care of by the daemon now get taken care of by
  748.       a signal handler.
  749.  
  750.     o reading and writing becomes a disaster!  If you use TCP you have
  751.       to deal with partial reads and writes of packets because you have
  752.       to use nonblocking I/O.  If you want to write code, you have to
  753.       have states for everything in the universe (so to speak).  The
  754.       solution?  Use UDP only.  But that requires a TCP like protocol
  755.       to get those packets that absolutely have to get there (like a 
  756.       login name).  Feel like re-inventing the wheel?  I sure feel 
  757.       like I am now.  :)  
  758. [...]
  759. -----
  760. </pre>
  761.  
  762. This guy clearly didn't know about select(), but there are issues with that,
  763. as well.
  764. <p>
  765.  
  766. <hr>
  767. <a name="14"><h4>
  768. 14. Put the number of armies next to the planet.
  769. </h4></a>
  770.  
  771. <strong>Problem:</strong><br>
  772. It's annoying to have to hit 'i' all the time to get army counts.
  773. <p>
  774.  
  775. <strong>Proposal:</strong><br>
  776. Put the number of armies on each planet next to the planet's bitmap on the
  777. galactic map.
  778. <p>
  779.  
  780. <strong>Why Not:</strong><br>
  781. This is the first step down the path to "Netrek for Morons(tm)".  You can see
  782. when a planet pops by watching the galactic map; having ever-increasing army
  783. counts staring you in the face is like having a compass attached to your
  784. nose.
  785. <p>
  786.  
  787. It's true that the information is accessible, if somewhat inconvenient.
  788. However, players who aren't paying attention won't see the new army
  789. numbers, and are less likely to react to an army bitmap on the display than
  790. they are to seeing "15" next to Sir.  If you aren't paying attention to
  791. armies, you lose.  There are several places in Netrek where this is the
  792. case.
  793. <p>
  794.  
  795. Netrek rewards vigilance and a keen eye as well as intelligence and fast
  796. reflexes.  Being constantly aware of everything around you is a challenge
  797. beyond the goals of the game itself; it requires the player to improve
  798. himself, and rewards experience.  Doing all but say, "do this next" will
  799. make things too simple, and reduce the sense of accomplishment acquired
  800. from mastery of the game.  Knowing exactly where the armies are and how many
  801. requires as much skill as holding a phaser lock, which is as it should be.
  802. <p>
  803.  
  804. There are those who think otherwise.  I'm not presenting their opinions here,
  805. because if you are about to propose this then you share those opinions
  806. already.  Suffice it to say that there is enough disagreement to keep this
  807. from becoming a standard feature of Netrek.
  808. <p>
  809.  
  810. <hr>
  811. <a name="15"><h4>
  812. 15. Highlight ships with kills.
  813. </h4></a>
  814.  
  815. <strong>Problem:</strong><br>
  816. It's too annoying to have to look down at the player list, and relate that
  817. to the people flying around.
  818. <p>
  819.  
  820. <strong>Proposal:</strong><br>
  821. Mark players with kills somehow.
  822. <p>
  823.  
  824. <strong>Why Not:</strong><br>
  825. This is yet another stepping stone on the path to ButtHeadTrek.  This would
  826. essentially stick a big "Ogg Me" sign on the engines of anybody with a kill.
  827. You don't even have to pay attention to the game to know what you should do
  828. when you encounter a ship with kills.
  829. <p>
  830.  
  831. While this is in the same vein as the army counts, it isn't really
  832. controversial, possibly because the guys who like the army counts also like
  833. to take planets and don't want to get swamped by "stupid oggers."
  834. <p>
  835.  
  836.  
  837. <hr>
  838. <a name="16"><h4>
  839. 16. Prevent bombing/taking out of T-mode.
  840. </h4></a>
  841.  
  842. <strong>Problem:</strong><br>
  843. Many players either don't know Netrek-etiquette about not messing with
  844. planets outside of T-mode, or they choose to ignore it.
  845. <p>
  846.  
  847. <strong>Proposal:</strong><br>
  848. Make the server enforce it.
  849. <p>
  850.  
  851. <strong>Why Not:</strong><br>
  852. The main problem with it is that sometimes its okay to bomb out of t-mode.
  853. If you've got a 2-on-2 "training" session and just want to practice trading
  854. planets, it's annoying to have it blocked.  Making this policy work without
  855. getting in the way generally requires human intervention.  Most servers 
  856. nowadays do something to prevent you from doing this, but, for example,
  857. on servers where you can't take neutral planets out of t-mode, you can
  858. genocide a team (leaving their last planet neutral), and then they quit
  859. out, you lose T-mode, and you can't reset the galaxy because you can't take
  860. neutral planets.  
  861. <p>
  862. The most common implementation now is to not allow bombing, but to allow
  863. dropping armies out of t-mode.  This gets around the problem resetting the
  864. galaxy.  Most server send in robots to kill people who do this, which 
  865. should keep people from doing it too much.
  866. <p>
  867.  
  868. <hr>
  869. <a name="17"><h4>
  870. 17. Just have a two-race galaxy.
  871. </h4></a>
  872.  
  873. <strong>Problem:</strong><br>
  874. Netrek is a descendant of Empire, which had four warring races.  However,
  875. Netrek games typically have only two races fighting each other, so the rest
  876. of the planets are just worthless junk.  This increases network/CPU overhead,
  877. and leads to 3rd-race scumming.
  878. <p>
  879.  
  880. <strong>Proposal:</strong><br>
  881. Remove two of the races.  Leave Fed/Rom, or Rom/Kli (with a reorg of KLI
  882. space).
  883. <p>
  884.  
  885. <strong>Why Not:</strong><br>
  886. The other planets serve a variety of uses.  They can be used by scout bombers
  887. and planet takers for refueling and repair, and allow cloaking near hostile
  888. space.  It also allows 3rd-space scumming, but that's a different issue.
  889. <p>
  890.  
  891. Most importantly, the size of the galaxy increases the area which needs
  892. to be defended.  If you reduce the galaxy to a two-way, it will be impossible
  893. to attack from or retreat to neutral space.  All offensive actions will take
  894. place in a single corridor, making starbases and large ships much more
  895. important.  Bombing and deep planet taking will become more difficult
  896. because there is a single path of attack.
  897. <p>
  898.  
  899. Whether you think this is a good idea or not, there's no denying that it
  900. will dramatically change game strategies.  It is unlikely that such a
  901. proposal will be popular.
  902. <p>
  903.  
  904. <hr>
  905. <a name="18"><h4>
  906. 18. Add incentives for scout bombing.
  907. </h4></a>
  908.  
  909. <strong>Problem:</strong><br>
  910. Very few people are willing to SC-bomb because of the drain on stats (too
  911. much time away from taking planets).  Bombing 2 or 3 armies at a time doesn't
  912. really help the bombing stats much; ogging carriers may do more.
  913. <p>
  914.  
  915. <strong>Proposal:</strong><br>
  916. Change the amount of bombing credit based on the number of armies sitting
  917. on the planet when bombing began.  So you'd get massive credit for bombing
  918. the last three armies, but not nearly as much for bombing it from 60 to 55.
  919. <p>
  920.  
  921. <strong>Alternate proposal:</strong><br>
  922. Start all planets out at 5 or 6 armies.
  923. <p>
  924.  
  925. <strong>Why Not:</strong><br>
  926. Both proposals suffer from the fact that average bombing stats have already
  927. been computed on most servers based on the "one army, one vote" scheme
  928. with 30 initial armies on each planet.  Changing the setup mid-stream would
  929. make it nearly impossible to get a 1.0 bombing rating.
  930. <p>
  931.  
  932. It's also highly unlikely that anybody really concerned about rank is going
  933. to do much scout bombing anyway.  Advancing bombing at the expense of
  934. offense and planets is not a good way to scum up to Admiral.
  935. <p>
  936.  
  937. The alternate proposal also affects the ability of a starbase to fill up
  938. with 25 armies at the start of a game.  Overall, the second proposal will
  939. likely have a dramatic impact on the way the first few minutes of a game
  940. are played - something that isn't likely to go over too well with the "old
  941. timers."
  942. <p>
  943.  
  944. The INL server, and some pickup servers, have gone to 17-army game starts; 
  945. this helps some, but not enough.  It does allow the base to get 25 armies
  946. fairly easily, however.
  947. <p>
  948.  
  949. lexus.astro.indiana.edu has also implemented "flatten credit"; you get extra
  950. bombing credit for bombing all the armies off a planet, no matter how many
  951. started there.  That way, bombing a planet from 5 to 4 (which SC bombers do
  952. all the time) is worth more than bombing it from 17 to 16.  It still
  953. doesn't make bombing a high-DI activity.
  954. <p>
  955.  
  956. <hr>
  957. <a name="19"><h4>
  958. 19. Protect ships that are fully lagged.
  959. </h4></a>
  960.  
  961. <strong>Problem:</strong><br>
  962. When a client becomes seriously lagged, the player usually ends up getting
  963. snuffed by the first bozo who comes within visual range.
  964. <p>
  965.  
  966. <strong>Proposal:</strong><br>
  967. Make a server mod so that ghostbusted players are invulnerable until the
  968. connection gets reestablished.
  969. <p>
  970.  
  971. <strong>Why Not:</strong><br>
  972. <pre>
  973. >From: jch+@cs.cmu.edu (Jonathan Hardwick)
  974. >Subject: Re: Playing with lag
  975. >Date: 11 Aug 92 01:24:29 GMT
  976. >
  977. >Last time it came up, one objection I remember is that it would become
  978. >trivial to abuse.  Want to take that last planet?  Lock on, cloak, max
  979. >warp, and then yank the ethernet connector out of your machine.  Wait
  980. >30 seconds while the defenders waste all their fuel on you, and then
  981. >finally realize that you're in Protected Mode.  Stick the ethernet
  982. >connector back in, beam down your armies, genocide the galaxy.
  983. >
  984. >Or if you're worth less when in Protected Mode, just yank the ethernet
  985. >connector whenever death seems inevitable.
  986. </pre>
  987.  
  988. Depending on the implementation, you might be able to just hit ^Z and
  989. suspend your process.  When the client host's buffers fill up it'll look
  990. just like a network storm to the server host.  If all you want to handle
  991. is fully severed clients then you won't be solving the problem; the only
  992. time my client has been severed is when the server goes down.
  993. <p>
  994.  
  995. <hr>
  996. <a name="20"><h4>
  997. 20. Change the names of the races or the planets.
  998. </h4></a>
  999.  
  1000. <strong>Problem:</strong><br>
  1001. Feds never fight Klingons, and who are these Orions, anyway?  The names
  1002. are outdated and don't reflect Trek stuff.
  1003. <p>
  1004.  
  1005. <strong>Solution:</strong><br>
  1006. Use Ferengi, Cardassians, or some other "real life" hostile races.  Change
  1007. the names of some of the planets to reflect Star Trek stuff, i.e. use
  1008. names like "Farpoint" and "Vulcan".
  1009. <p>
  1010.  
  1011. <strong>Why Not:</strong><br>
  1012. The names of the races and the planets are ingrained into Netrek players.
  1013. If somebody says "clear org", experienced players know where to go without
  1014. even looking at the map.
  1015. <p>
  1016.  
  1017. Races are the same way.  Everyone who has played for a while is used to Rom
  1018. being top left, Orion being lower right, etc.  People don't write, "K3 is
  1019. scumming in lower-left space".  It's Fed space, and it always should be.
  1020. Sure, people would get used to it after a while, but I don't think most
  1021. people WANT to get used to it.  In a few situations it can be a real pain,
  1022. such as when the first letter changes.  If you want to send a message to the
  1023. other team, you have to use a different key.  It's also used in a lot of
  1024. places in the code, so it'd be a pain to change (and if you didn't change
  1025. the code, but rather just the external appearance, it'd be very confusing
  1026. for people prying into the source code).
  1027. <p>
  1028.  
  1029. Remember what this document says up top: Netrek is not Star Trek, Netrek is
  1030. not Real Life.  It's a game, with names chosen as convenient points of
  1031. reference.  If you want to set up a server with California city names or
  1032. campus buildings instead of star systems, feel free.  This has been done,
  1033. but it's never caught on.
  1034. <p>
  1035.  
  1036. <hr>
  1037.