ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / games / netrek / suggestions / part2 < prev

Wrap

Internet Message Format | 2001-12-03 | 27.4 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!howland.erols.net!news.maxwell.syr.edu!news1.best.com!nntp1.ba.best.com!not-for-mail From: doosh@best.com (Tom Holub) Newsgroups: rec.games.netrek,rec.answers,news.answers Subject: rec.games.netrek Frequently Offered Clever Suggestions list, Part 2/2 Supersedes: <netrekFOCS.2_1004702400@best.com> Followup-To: rec.games.netrek Date: Sun, 2 Dec 2001 12:01:26 +0000 (UTC) Organization: The ISP formerly known as Best Lines: 678 Approved: news-answers-request@MIT.Edu Distribution: world Message-ID: <netrekFOCS.2_1007294401@best.com> References: <netrekFAQ_1007294401@best.com> Reply-To: doosh@best.com NNTP-Posting-Host: shell3.ba.best.com Content-Type: text/html X-Trace: nntp1.ba.best.com 1007294486 50803 206.184.139.134 (2 Dec 2001 12:01:26 GMT) X-Complaints-To: abuse@best.com NNTP-Posting-Date: Sun, 2 Dec 2001 12:01:26 +0000 (UTC) Xref: senator-bedfellow.mit.edu rec.games.netrek:79265 rec.answers:70338 news.answers:220243 Archive-Name: games/netrek/suggestions/part2 <a name="21"><h4> 21. Add ship collisions. </h4></a> Problem: It would be neat to have ships collide. Proposal: Have ships either damage each other on collision or bounce off in some elastic manner. Why Not: Bouncing ships would be, well, weird. Crunching ships in a BB by rolling over them would be amusing, but probably wouldn't add much to the game. However, there are more serious considerations. First, consider what happens if you are cloaked ogging somebody, and collisions do damage. Now you don't even need to uncloak to kill the other guy; just run into him. Makes avoiding oggs nearly impossible, especially since you can't pressor the attacker away. Second, suppose you are cloaked taking a planet. As it is the defenders have to locate you and hit you with enough torps/phaser hits to blow you up. Escorts can det torps to keep their takers safe. Collisions make it far easier to defend planets: whether the collisions bounce or do damage, planet defenders can simply cloak and fly over the planet and have a good chance of destroying you or at least knocking you off. They don't even have to uncloak anymore, making it harder for the escorts to do something useful. And if collisions bounce, you can just knock the escorts into the planet takers. Heck, if you want to defend a planet, just sit right in the middle, and nobody else can orbit. This last issue is a strong reason for disallowing collisions between friendly players: you could never have more than about four people in orbit at once, and getting more than two in orbit would require a minor feat of coordination. <hr> <a name="22"><h4> 22. Give planets gravity or motion. </h4></a> Problem: Planets are boring. Proposal: Give planets a gravitational attraction. Also, make them move around, perhaps in some sort of localized circular pattern. Why Not: Gravity is really sort of silly. It won't do anything but make it harder to get away from a planet. Might be useful for dodging sideways or running, but you either need to make it too weak to be interesting or too strong to be playable. Moving planets is harder than it seems. The client wasn't designed to allow planets to move. You will also increase the amount of network traffic (by quite a bit, since planet positions are currently only sent right after you log on) and the CPU load, which are Bad Things. It really isn't all that exciting anyway. It can change the galaxy around making Kli or Ori space more "fair", but any serious amount of movement will have to be carefully tested so you don't end up with cluster-galaxies and huge neutral zones. It's been done once or twice and hasn't been really popular. <hr> <a name="23"><h4> 23. Set up an invitation-only clue server. </h4></a> Problem: There are so many clueless weenies flying around that I'm not having fun anymore. Proposal: Set up a clue-only server. Access would be by invitation only, with players selected by the admin or invited automatically after achieving a certain rank on certain servers. Why Not: It's been tried. auk.warp.cs.cmu.edu was run this way, and nobody ever played there. There are two fundamental problems with the proposal. First, the invitation mechanism is bad. Either the server admin has to spend a fair amount of time adding players and passwords, or it has to be done automatically. However, as discussed earlier, rank is a horrible indication of clue, talent, and skill. Automated systems will be prone to adding clueless players with lots of hours or missing clueful players who just don't care about rank (or reset their stats). Even if that were solved, there's another problem: it's not easy to get 16 clueful players in one place at one time. Players come in and out constantly. Getting it organized is a pain and is just too inconvenient for the players to make it worth doing. auk failed miserably because nobody worked to get the players there (apparently it was also a bit on the slow side). If you propose this, be prepared to accept the burden of organizing it. Many people have said, "somebody should do this", but nothing will happen until "somebody" steps up and does it. If you want to set one up, feel free, but don't expect much UNLESS you are willing to spend a LOT of time massaging the player database, sending e-mail to players, and doing general organizational stuff. One acceptable alternative is the "minimal clue" system that Nick Trown came up with. Basically, after you sign in the server tells you to send a message to yourself. If you don't, you get blown up, and eventually get kicked out. All this does is require the player to have the message window *mapped*, which is a big step toward playing in a clued manner. It has been tried and generally accepted as a Good Thing, though many feel it doesn't go far enough. It's now in the vanilla server, and most Bronco servers have some form of clue-checking. The common scheme these days is to announce "clue games" on rec.games.netrek the clue-pickup mailing list, and/or the Netrek Game Board. See <a href="http://www.best.com/~doosh/netrek/netrekFAQ.html#25">The Netrek FAQ</a> for details on accessing these resources. <hr> <a name="24"><h4> 24. Allow ships to drop mines. </h4></a> Problem: There just aren't enough ways to kill things. Proposal: Allow ships to drop mines which explode when you run into them. Why Not: The first thing to ask yourself is, what good are they? A new way to runner scum? Maybe it's supposed to garrison an SB or planet? Or is it just a new toy added for the hell of it? They aren't really all that useful unless you want to give them serious damage capability (say 150 points - otherwise I'll come by in an AS and soak up half a dozen), in which case they'll be used either while running away at maxwarp or during oggs, essentially giving you a single big torp. If you make them more expensive than torps, they won't get used here, but when will they be used? Guarding an SB? Just steer around them, or send a suicide minesweeper in. For a planet? Maybe. It might slow down SC-taking. If they can be destroyed with phaser shots though then they're pretty much worthless. On the other hand, during an LPS you could have everyone on your team drop a mine on the home planet, making it impossible to take. One proposal was to allow SBs to either fire torps or mines (i.e. you would choose on an individual basis whether what you fire is going to be a torp or a mine). This restricts the #of mines active by essentially crippling the starbase every time it drops one. It also requires that the team HAVE an SB for them to work at all. Something like this was tried on Calvin. At any rate, all mine proposals have one major flaw: how to display them. Unless you want to force a change to the client code, you have to represent them with a player's torps, plasmas, etc. Unfortunately these tend to look just like vestigal torps which were "forgotten" by a UDP connection, so remote players tend to slam into them (or end up swerving around bogus torps). If you want to get fancy (say, have two standard torps orbiting each other) you will be using two torps per mine (which might not be a bad thing). If you're going to propose this, you need to consider: <li>who gets them (ship type, #of kills, rank) <li>how many each person/team gets <li>how they are drawn (plasma, photon, phaser, Iggy?) <li>how they are removed (only on collision, at request of "owner", when phasered, when plasmaed, after n seconds) <li>how much damage they do (point-blank damage + blast radius) <li>whether or not they can be tractored/pressored/beamed <li>whether they can be dropped while cloaked (VERY bad idea) <li>who causes them to explode (other team, everyone, all != owner, non-cloakers, just cloakers, other exploding mines) <li>who takes damage (other team, everyone, all != owner) The really hard part is making them useful but not abuseable. <hr> <a name="25"><h4> 25. Have the client update the torps instead of the server. </h4></a> Problem: A lot of network traffic is spent sending torp updates. Proposal: This could be avoided by just sending the "start" packet with direction and speed, and sending an "end" packet when the torpedo dies. Why Not: The main difficulty is losing synchronization with the server. If a "torp death" packet is lost or delayed, the position of the torpedo will be inaccurate because of torp wobble or possible early expiration. It might reduce net traffic, but it could be really confusing. The biggest obstacle is "torp wobble", which is a random change in direction added every update. If the client misses an update, the torp will continue off in the previous direction until the next update arrives, at which point it will jerk back on course. This can be worked around by sending a random number seed to the client, and then having the client emulate the wobble, but this is just making more work for the client and creating the opportunity for borgs to accurately predict wobbling torps. Since borgs have all but disappeared from the scene, and most machines aren't taxed for CPU, this change has become more realistic; however, the problem of synchronization is not a small one. This idea is often batted around when people discuss creating a format for recording netrek games that doesn't take enormous amounts of space. It's a lot of coding and testing, though. <hr> <a name="26"><h4> 26. Have ships come in at the starbase instead of a planet. </h4> Problem: LPSs are hard to break, and transwarp is nice but not really necessary. Proposal: Have ships come in at their starbase instead of a planet. Why Not: One big reason is that a traitor SB could drag its entire team off into 3rd space, allowing an easy genocide by the other team. This isn't a problem in clued games, but it only takes one bozo. It has some tactical problems, like making it impossible for the starbase to sneak around cloaked. Killing the starbase becomes easier or more difficult depending on where the new ships come in: newbies appearing right on top of the SB and exploding repeatedly will make it die faster, while clued players appearing a short distance away will increase its lifespan by providing a continual escort. But, worst of all, it makes Ged happy. You can avoid some of the problems by looking at SB docking permission or having people set a preference somehow, but the usual question needs to be answered: does this really enhance the game? Incidentally, a little-known fact is that ships do NOT have to come in at the home planet. The server admin can specify a list of planets in the server .sysdef file, and have one chosen at random. This feature is rarely used though. <hr> <a name="27"><h4> 27. Ships should auto-repair at warp 0. </h4></ha> Problem: It's really inconvenient to have to hit 'R' to repair. It should happen automatically. Also, it's tough to exit repair to fire weapons. Proposal: Have damaged ships auto-repair when they hit warp 0. Also, have repair mode deactivate when the player fires weapons. Why Not: There's really no reason not to do this, but it's unimportant, so overcoming inertia is difficult. <hr> <a name="28"><h4> 28. Change the way the wait queue works. </h4></a> Problem: Sitting on the wait queue sucks. Proposal: Either have players with more DI move through the queue faster, or have the players get booted to the end after every time they die. Why Not: For the first one, you're increasing the importance of DI, which will lead to more scumming. It will also encourage people to play on only one or two servers, share high-DI logins with friends, and will effectively block newbies from playing. Increasing the importance of DI is *not* a worthwhile goal. In the second case, you're making life incredibly valuable. Nobody will want to ogg if it means waiting for a couple of minutes to get back in... and when people start guarding their lives carefully, the wait queue will take longer and longer to shrink. There is also the (non-trivial) problem of balancing the wait queue across teams (if three FEDs die do you let three ROMs in the game, making it 11 on 5?). <hr> <a name="29"><h4> 29. Add steering keys. </h4></a> Problem: Netrek's clumsy and outdated user interface requires you to use the mouse to steer your ship. Proposal: Define keys that turn your ship regardless of the position of the mouse. These could be incremental (turn 1/16th per keypress) or continuous (keep turning left until you hit the other one). Why Not: There are two very important actions that require you to position the mouse: dodging and shooting. You can't dodge torps and shoot in the same instant unless you want to dodge directly at your target. Only borgs and robots can do this. A player who practices with these keys for a while will be able to maintain a continuous phaser lock and fire torps while effectively dodging enemy torps. There are a few people who can approximate this with the current setup, but they are among the best dogfighters in the game. This change would make it much easier for people to reach the pinnacle of dogfighting skill, which is not a desirable quality in a game. If there's no challenge, there's no point in playing. The argument about Netrek's interface being clumsy is ridiculous. F-16 fighter pilots (who fly a very capable combat borg) have stated that they would've loved to fly in World War I, when combat had more to do with individual skill and cunning than electronics. Turn keys were implemented in one client, but it has been declared INL- illegal, and its RSA keys have been turned off by most servers. <hr> <a name="30"><h4> 30. Prevent butt-torping. </h4></a> Problem: Twinks in DDs keep toasting my CA by firing torps while running away. Proposal: Prevent players from butt-torping by altering the way torps fired out of the rear 60 degrees or so are handled. Why Not: "Hey Doc, it hurts when I do this." If you're getting butt-torped to death, you have to stop flying into the torps. If that means not killing the other guy, then don't kill him. Players who do nothing but butt-torp are lousy space controllers and are remarkably easy to clear off planets (just cloak and charge in their general direction). Netrek physics are such that torpedos always move at the same speed, regardless of the speed of the ship that fired them. This means that firing while running works to your advantage, since their torps have a closing velocity of (12 - yourspeed), whereas yours have a closing velocity of (12 + theirspeed) (assuming CA torps). Various proposals have been suggested (and often implemented) over time, including: <li>"vector torps", where the firing ship's velocity is taken into account. In the above example, the closing speed for both sets of torps would be warp 12 if yourspeed == theirspeed. Care must be taken to avoid giving SCs warp 28 torps. Also, butt-torping a starbase that has you tractored becomes next to impossible. <li>no torps out the rear section <li>limited # of torps out the rear <li>higher wtemp/fuel cost for torps out the rear If you want to implement one of the latter proposals, you must also take into account things like starbases (which don't really have a front and back), and orbiting ships (they aren't running, just happen to be on one side of the planet and not the other). These ideas weren't all that popular in practice, because most players spin around a lot while fighting, and even though they aren't running they are still penalized. Some people differentiate between "runner-scumming" and "butt-torping", though this is largely a difference in attitude rather than technique. <hr> <a name="31"><h4> 31. Have a database that's shared between multiple servers. </h4></a> Problem: I want to use the same character on all servers, but somone's scummed the name on some of them. Proposal: Have a single player database that's shared between all major servers. Why Not: First of all, it's a logistical nightmare; syncing all the current player databases, getting rid of duplicate names, deciding which person gets to keep "James T. Kirk", etc. You also create update problems; if the database is stored on a central server that the netrek servers query when you log in, you create a failure point for the whole network of servers. If the database server goes down, you can't use your character anywhere. And if you have each server maintain its own database, what happens when you play three hours on wormhole, quit out and then play three hours on lexus? Getting that information into the central database is a mess. More than that, you run into problems with ratings. Your ratings are a measure of how often you do something compared with the average person in the database, so if your planet rating is 2.0, you take a planet twice as often as the average person. The problem is, not all servers are created equal. The big-name servers like wormhole and lexus tend to have a higher level of clue than new or lesser-known servers; because of this, it's harder to take planets, bomb, or kill people on wormhole than on (say) curly. You can't fairly compare planet ratings from the two servers. Besides, it's silly. Get some originality and come up with a unique name. Everything from Star Trek and Star Wars has been taken, as well as most things from Asimov books (ugh), and just about anything containing the word "anus". <hr> <a name="A1"><h4> A1. Appendix: Sturgeon II changes </h4></a> This comes from the motd (Message Of The Day) on sturgeon.cs.washington.edu, port 2592. Other upgrade servers (and even sturgeon itself) may differ at the time you read this; this is more for example than anything else. [ This was added some time in late 1992, and is now very much out of date. ] <pre> This server has a lot of changes. I shall try to describe all the ones I can remember making. There may be a couple more. (1) Phasers have longer range, but damage does not decrease linearly, but rather with the square of the range. They're faster on bigger ships. (2) Only starbases and battleships can fire a stream of 8 photon torps. Cruisers are limited to six, destroyers five, assault ships four, and scouts three. Starbases have fighters too (hit "C" to toggle) (3) Photon torpedos are identical for all ships, in terms of fuel cost, damage, fuse, and weapon temperature. (4) Phasers do double damage to shields, and photons double damage to "hull" (damage points). Example: 15 point phaser hit to shields of 20 will reduce the shields to 0 with the first 10 pts, and do 5 hull points with the remainder. Not many ships can take more than one torp hit to downed shields. (5) All ships can fire torps while cloaked, at 5x normal cost (300 x 5) (6) Cloaking enemies will be revealed for a short time if (a) they get hit by a torpedo, (b) they get hit by phasers with their shields up, or (c) you detonate your own torpedos, to show them in a radius. (7) Upgrades. If you refit to the same ship type, you can "upgrade" some aspects of your ship, in return for kills. If you refit to another ship type, you regain most of your "used up" kills. (8) Plasma torps now "cost" 2.0 kills. They only take two seconds to upgrade. They are "upgrade 2", and are *not* automatic for refits from ships with 2+ kills. (9) Scouts don't bomb; they strafe. While this is much less time efficient, the advantage is that they can strafe until a planet has less than TWO armies. (A) Planets now have variable resources. Home planets (Ear, Rom, Kli, Ori) are always Fuel/Repair/Agri, and Core planets are always Agri. Any planet with less than 10 armies is Agri; from 10-19 it is Fuel, from 20-39 Repair, and Fuel/Repair from 40 on up. (B) Phasers can be fired before they fully recharge. This costs the same amount of fuel, but does less damage. (C) The base number of kills received is equal to (Hull points of victim) / (Your hull points). Thus, a scout destroyed by a cruiser is only worth 0.75 kills, while the cruiser is worth 1.33 to the scout. UPGRADES -------- To upgrade, have available kills and orbit your home planet. Refit to the same ship type, and a menu will come up on your messages display. Press the number corresponding to the upgrade you want. The kills will be deducted from the number available, and your ship will be upgraded (with some amount of refit time, depending on the upgrade). In all menus, press 0 (or a non-number) to abort. From the Main Menu, 1 works the same as the classic refit (fixes damage, shields, fuel, wtemp, etemp). Upgrades cost k1 + k2 * (previous upgrades of same type) kills, listed as (k1/+k2), and your ship will be nonresponsive for that many seconds. Upgrades include: - Shields +10 pts to your shield maximum (1.0/ 0.0) - Fuel capacity +250 fuel maximum (0.5/ 0.0) - Fuel recharge +10 fuel/sec (0.5/+0.5) - Max Speed +1 to maximum warp speed (2.0/+1.0) - Acceleration +0.1 warp/sec acceleration (0.5/+0.1) - Deceleration +0.1 warp/sec deceleration (0.5/ 0.0) - Engine Cooling +10 engine temp cooling/sec (1.0/+0.5) - Phasers +3 to point-blank damage (1.0/+1.0) - Photons +1 to photon torpedo *speed* (base is 15) (3.0/+2.0) - Weapon Cooling +10 weapon temp cooling/sec (2.0/+2.0) - Cloaking Device halve the fuel cost (round up) (2.0/+1.0) - Tractor/Pressor +100 tractor/pressor strength (1.0/+0.5) - Damage Control +1 damage repair/sec (1.0/+1.0) Commodities: upgrades that are "no deposit, no return"... - Overload shields +50 pts to your current shields, one use only (1.0/ 0.0) - Pseudoplasma 0 pt plasma (12) (1.0/ 0.0) - Type 1 Plasma 50 pt plasma (12) All plasmas cost: (2.0/ 0.0) - Type 2 Plasma 75 pt plasma ( 6) - Type 3 Plasma 100 pt plasma ( 4) - Type 4 Plasma 125 pt plasma ( 3) - Type 5 Plasma 150 pt plasma ( 2) - 10 megaton nuke Just like in Nuclear War (1 army = 1 million) (1.0/ 0.0) - 20 megaton nuke The tables have been duplicated, except for (2.0/ 0.0) - 50 megaton nuke the "destroy the solar system", which may (4.0/ 0.0) - 100 megaton nuke later... (8.0/ 0.0) Plasmas cost no fuel to fire. Nukes take up (1/2/3/4) army bays until used. Switch between special weapons with the "C" key. </pre> <hr> <a name="A2"><h4> A2. Appendix: Extreme Netrek </h4></a> <pre> From: async@illuminati.io.com (Felix Sebastian Gallo) Three planets; earth, rom, indi. In an equilateral triangle 1.5 screen lengths on a side. All planets start with 30 armies; Indi has independent armies. No pops, no agris, all planets repair/fuel. Bases regenerate with 45 seconds remaining. Six-player t-mode, anyone can base. Standard vanilla ships. First side to take a planet wins; after five minutes of t-mode the galaxy resets. </pre> A game similar to this one has been implemented in the vanilla server. If you go to an empty server with some friends and send TRIPLE to yourself, you may be able to play Triple Planet Mayhem. It's a nice change of pace. <hr> <a name="A3"><h4> A3. Appendix: How to propose a change </h4></a> First of all, if it's in here, don't post it to rec.games.netrek. It's in here for a reason: it was suggested, and died. That doesn't mean you can't ask a server deity to add it for you; some of them are quite amenable to new ideas (the weirder the better). The most important item to remember is DETAIL. Describe your change in absolutely painful amounts of detail. Include sample code at the end, if you have it. For example, take a look at <a href="#24">Clever Suggestion #24</a> (mine dropping). I have a list of questions that must be answered by the person proposing what, on the surface, seems to be a very simple idea. You need to anticipate what people will ask, and provide details for all contingencies. A modest proposal might look like this: <li>Summary: explain in a couple of sentences what you want to do. <li>Explanation: explain in depth how what you're planning will work, from a player's perspective. Don't include lists of source files, cost estimates, or source code here; this should be readable by Admiral Fubar, even if old Foo couldn't write a line of C to save his/her/its life. <li>Justification: explain why the world needs this change. Explain how it will improve the game, and why it is important enough to spend time doing it. <li>Rebuttal: play Devil's Advocate, and dream up every possible objection to your proposal. Then answer those objections. This ought to save hundreds if not thousands of dollars by avoiding yet another r.g.n flamefest. It will also make it easier to add to the FOCS. <li>Technical stuff: if you've already made the changes or you're familiar with the client and server, explain where you think the changes need to be made and how much effort it will take. Include source code here if you have it, but keep it short! If it's huge, make the context diffs or the modified files available for FTP. If you just have a dopey little change, there's no reason in the world why you can't just post the code to r.g.n and say, "here's some nice code, feel free to use it if you want." I did visible tractor beams this way, and look at how far they've gone. (Tedd Hadley gets credit for the nice segemented lines though.) All source code bug fixes are posted this way, usually as context diffs (use diff -c oldfile newfile ... the order is important). </body> </html>