Traveller Simulation

[robject]

How could one map mouse movement and clicks to ship movement? Assume one uses the location of a mouse press, location of a mouse release, and buttons 1 and 3.

I have the start of a Traveller simulation: a database of sectors, an Imperial Coordinated Time clock, and a workable solar system Model, View and Controller. Worlds orbit, and the client can zoom in/out and move the viewing window around. My next step is to create a Ship View and Controller.

I'd like to simply use the mouse to maneuver (alter course and stop) and jump. But I'm also thinking about weapons use, and who knows what I'm forgetting. So any suggestions would be nice.


At this point, I'm assuming GG skimming, docking, and landing are taken care of via maneuvering, that is, maneuver into a low GG orbit = skimming; maneuvering into a 'parking orbit' or some such = docking, etc.

 

[robject]

Alllrighty then, I've thought about it a little, so here are my thoughts. Any opinions would be nice.


Maneuvering a ship involves a few common, erm, idioms. I'd like to map that to mousing. In particular, to two types of maneuvering: Tactical and Strategic.

Tactical Maneuvering. Changing/setting acceleration is simply left-clicking relative to the ship's icon (which is always centered on the screen) on the tactical map. Deceleration is accelerating against the current velocity. Would a left-click very, very close to the ship [2.8 pixel radius?] cease the acceleration, letting the ship coast? A simple 'right-click' on the ship reverses acceleration until the ship is at a full stop. Perhaps a right-click on a target begins docking procedures. A 'dragged click' fires weapons -- left for laser, right for missile + sand. Perhaps. [And yes, it would be fun if other logged-on players could fire the weapons as gunners.]

Strategic Maneuvering. To set a course heading, left-click on the destination point -- assuming the strategic map is a birdseye of the solar system. The ship will proceed in a straight line to the destination at full acceleration halfway, then full deceleration the rest of the way, probably resulting in orbital 'parking' upon arrival.

 

[TheEngineer]

Hi robject,

->Tactical Maneuvering
Perhaps you could also show the future position of ship if it would not use thrust at all and a circle around that square/hex showing the maneuver possibilties.
Then you could left click somewhere inside the circle to specify the target square/hex.
By these steps (reverse) acceleration is defined in detail.

Thats the way I want to implement user interaction in the space combat sim.

Regards,

Mert

 

[The Oz]

What about having a point out in space (marked by crosshairs, maybe) that indicates the ship's future position after some designated time interval if no changes are made (no accel or decel)?

And to accel/decel you click on the future position indicator and drag it to where you want it to be (within the limits of your ship's drive). And perhaps that drive limit could be shown as a sphere/circle surrounding the future position indicator with a radius equal to the possible change in position which is found from the ship's max acceleration and the current time interval.

 

[Andrew Boulton]

Some suggestions:

Right-clicking brings up a context-sensitive menu, depending on whatever you click on:

Empty space - Set as destination

Planet - Fly to orbit
- Dock at Highport (if available)
- Land at Downport (if available)
- Skim fuel (if GG or wet world)

Own ship - Jump

Other ship - Match course
- Dock
- Attack

etc

 

[robject]

Good suggestions, Oz and Engineer. What I think
you're suggesting is a visual velocity cue, like
a crosshair or circle indicating the ship's
current speed. I like that.

I also like the maneuver-drive indicator, showing
by how much the acceleration vector may be changed.
How about a visual cue for the acceleration vector
as well? Or is that too cluttered?

Andrew suggested more strategic actions, all of
which are excellent. If possible, I would like
to insert contextual information into the
display itself to allow these actions.

Andrew's suggestion to delegate docking, landing,
and skimming as strategic (rather than tactical)
has merit. Worlds have 100D-orbit 'halos' around
them, thus clicking within the halo sets a parking
orbit, and clicking on the world sets a landing or
skimming plan. Landings are probably going to be
always sent to the downport, if available. The
strategic view ought to have some sort of
clickable highport indicator, which instructs
that ship to dock at highport. Alternately
the ship could just rest near the highport in
a parking orbit, and the player can click the
highport do dock with it on the tactical map.

Jump can get very complicated, so the first
approximation is to use a menu to select a
world (not a system) from a list, then, when
it's time to jump, press a "jump" button
somewhere.

The tactical map is thus reserved for combat,
mainly. Maneuver could be handled with the
keyboard, while the mouse could be reserved
for doing fancy stuff. Left click on another
ship to match course. Right click to intercept.
Left click your ship to break off and evade.
Right click your ship to flee. To fire weapons,
hover the mouse over the target and type 'L' or
'M'.

 

[FlightCommanderSolitude]

Have you ever seen a computer game called Homeworld ? It had a pretty nice (three-space) navigation system, and while it was rather small scale the scale doesn't really matter.

Homeworld site.

Pretty nice graphics too.

 

[The Oz]

If you want to handle tactical combat with mouse and keyboard, you could always adapt the system used in the classic coin-op video game SPACE WARS. You used keys to thrust and rotate your ship. If you wanted to decelerate, you had to rotate 180 degrees first.

Then use the mouse for firing. Put the mouse pointer over a potential target and get information like enemy range, vector and acceleration, plus perhaps my own missile time-of-flight, assuming things remain constant. If I want to fire lasers I left-click, if I want to fire missiles I right-click.

As a side note, whatever happened to SPACE WARS? I've never seen it provided with any of the collections of "classic arcade games" that have been published. I used to spend hours playing that with a friend, and always hoped it'd be updated, perhaps with shields and aimable weapons.

 

[robject]

Of course, The Oz has made an excellent point. Space Wars was a fun, fun game, and the controls made the game enjoyable (not to mention the "sensurround" megabass rumbling from the stand-up coin-op).

The 'original' version of Space Wars -- the one that UNIX was apocryphally written for -- has emulators available. The coin-op version (which is far superior) ALSO has an emulator, at, erm, now where did I put that link?

Well, there's one version at
http://www.digisys.net/users/cogs/spacewar.htm

And here's an article on slashdot:
http://slashdot.org/articles/99/11/14/005257.shtml

 

[robject]

Here's more, better emulation info:

http://caesar.logiqx.com/html/games/spacewar.shtml

 

[Andrew Boulton]

I don't think there's any need to worry about manually changing acceleration or heading.

Effectively, m-drives have two settings - on or off; I can't think of any situation where you'd want to use less than the full acc'n.

The drives only exist to get you to somewhere else, and this somewhere else is all you care about. In non-combat situations, just set your destination and let the computer worry about the details. Combat boils down to three cases:

- you chasing them, in which case set them as your destination,

- them chasing you, in which case pick a destination far away (unless you're going somewhere specific),

- stationary

 

[notagoodusername]

Originally posted by Andrew Boulton:
Effectively, m-drives have two settings - on or off; I can't think of any situation where you'd want to use less than the full acc'n.

Except docking, undocking, landing, taxiing, routine maintinence checks, reducing emissions signature, prolonging a damaged drive's life...

Shane

 

[Andrew Boulton]

docking, undocking - uses RCS
landing, taxiing - maybe
routine maintinence checks - ?
reducing emissions signature - maybe (but since you're moving slower you're giving them more time to see you)
prolonging a damaged drive's life - maybe

It's unlikely the s/w will deal with any of these cases.

 

[robject]

Originally posted by Andrew Boulton:
docking, undocking - uses RCS
landing, taxiing - maybe
routine maintinence checks - ?
reducing emissions signature - maybe (but since you're moving slower you're giving them more time to see you)
prolonging a damaged drive's life - maybe

It's unlikely the s/w will deal with any of these cases.

Right. However, damage 'applied to' a drive will increase its probability of failure under stress.

Full acceleration might not be wanted when matching courses with another ship.

 

[TheDS]

Reducing signature should not be underestimated. Sensing something is based on how much energy it gives off, and if there is enough of it reaching your detecter.

Say for instance that your sensor is capable of seeing a 1 Gw power source at 10 hexes. This means it can see a .25 Gw power source at 5 hexes, or a 4 Gw source at 20 hexes. If your power output was 4 Gw, the enemy could see you at 20 hexes, but if you're able to turn your output down to 1 Gw, he couldn't see you until you're at 10 hexes.

At the point when he sees you (or you're pretty sure he does - he could be faking it to lure YOU in) you turn the drive back up full blast to close the distance before he can do anything about you.

Alternately, if you are simply trying to quietly get away, you drop your drive below what he can see, and scoot, and hope he doesn't glance in your direction while you do it. The further you get away, the more power you can put back in your drive without being seen.

Now all this can be like a MINIMUM detection threshold OR a minimum GUARANTEED detection threshold. In the first case, the opposing sensor CANNOT see you until you are within X range; inside that, he gets to roll, and probably has a slim chance. In the second case, inside this range there is nothing you can do to avoid detection (except lower your energy); it's automatic.

Note that this actually means there are TWO sensor values. One is the guaranteed detection, the other is much further out and is the guaranteed failure of detection. So for instance, inside 10 hexes, a 1 Gw output can be detected automatically, outside 80 (?) hexes, detection is impossible for a given sensor.

I pulled these numbers out of the air, but the multiplying effects are not made up. Decreasing range by half quadruples the energy being detected, and IIRC a sensor's listed short range X 8 is it's max range (in TNE).

 

[TheDS]

Another thought:

Are you wanting to make this RTS/FPS, or map/turn based (or both)?

For control of a ship in RTS/FPS, I ca suggest a couple games to look at: Independence War and Sinistar. Both have "realistic" flight models. Descent may also be worth taking a look at; I played it once, but didn't care that much for it, and it's been a while, so I don't remember if it will help or not.

For map-based, I suggest you take a look at BL, BR, Mayday, or Star Fist (an SJ Game). Their movement models show you a "future position" marker that has been mentioned by other posters, and how to manipulate it.

One must be careful not to turn this game into Elite or Wing Commander. While those were great games, they're not Traveller, and more importantly, Trav combat takes place over great distances and times, while Elite/WC combats take a minute or two at absurdly close ranges.

I personally would prefer to see something more along the lines of a turn-based game, for several reasons.

First, there's so many RTS games out there, and only maybe 2 of them are worth the money (one of them being EU/EU2, which is only half-RTS, and the other being Populous/Pop2). It goes to show that to make the game RIGHT takes a very rare talent, and even if you have it, who really wants to turn Trav into a worthless clickfest?

Second, the important things are WAY too hard to control manually. Try docking in Elite without a computer. That's EASY compared to "real life". Calculating all that crap on the fly, with a 360x360 sphere to work with is NOT fun. Load up Asteroids or some clone of it. Launch your spacecraft in some direction at full throttle (after clearing most of the field so you don't hit anything). Now that you're drifting, try and come to a complete stop. You can't do it, and that game only has 16 directions you can apply thrust!

Third, most of the stuff that could be done RTS would not look good. Combat taking place at long range... you neither see your shots going off, nor do you see the enemy ship blow up, and your laser only fires every 3 minutes or so. Docking isn't fun either. All this stuff is stuff that a computer controls. You tell the computer what you want to do, and it does it for you. So why mess with that? Anything less won't look right to the connessuer. Stars don't move at less than sublight speeds, so a player would wonder if he's even moving!

Basically, on your "turn" to act, you determine where you want the ship to go, how much thrust to use, whether to evade (and how much). Then you go through your list of weapons and enemies and match them up how you want. This is a ship, you can fire at multiple ships with multiple weapons. Next you decide what defenses to employ (sand, EMM, Jammers, drones, etc). You also decide what to launch/recover, what your sensors are doing, and so on. Whatever other decisions need to be made, make them.

Then, let click DONE and the computer processes your input, compares it to the input of other units, and carries out the orders in an RTS-fashion. Basically, the game feels like a TBS with a pause button; at any time you can stop and change the orders you're giving (rather than forcing some one to go through a "full turn").

This kind of interface will allow you to control multiple ships and launched missiles and fighters.

If you want to put some one "in the cockpit" so they can look at a star field, or see other ships that are REAL close, or watch the planet or space station get bigger, or see an asteroid or whatever, well, you just allow some one to do that, but they're not going to really control things from that view. Basically, they watch stuff happen, but don't control things from there so they don't screw up the orders they gave the ship. They can swing their camera around and look at stuff, and not worry about where windows are, and perhaps give a look at that fuel leak the engineers are working on.

 

[robject]

I'm writing it as if it were Elite with a Pirates! insystem travel engine, a Space Wars combat engine, and a MULE commerce engine. Sort of completely unlike Elite, I guess, except it's not turn-based, and it's not tile-based. It's not beautiful, either.

For my Pirates! fetish, insystem modelling is in the 'archipelago' style -- orbiting bodies are like small islands in a large sea. It's 2D, but it's big. I plan on making asteroid belts 'fun' to fly through, though. The player has a tactical view for close-range work, plus there will be a system view as an overall 'map'. Both are 'live'. The tactical view works, but is not integrated into the game.

Because solar systems are so staggeringly huge, I think the whole spaceflight sim may be boring for people who don't like sailing through space (i.e. everyone who's not exploring). I mean, it takes a week to travel 5AU at 1G. The solution is to stay in high-traffic systems, buy fuel at the port, and don't travel insystem. The other side of the coin is that a single click sets a safe course to a destination, and (additionally) every system has plenty of debris -- even ones without asteroid belts -- which can be prospected. And yes, artifacts and salvages are out there, as well as old unexploded mines. And pirates.

For my Space Wars fetish, there's 2D space combat, actually part of the tactical view. After all, one aspect I'd like to model is piracy. But it doesn't resemble Space Wars anymore (that might change again), and I'm modelling Book 2-style combat, not High Guard et al, and combat options are scoped to a bare minimum so I don't bog down.

For my MULE fetish, starports are ugly, blocky affairs reminiscent of the bygone days of 8-bit computer games. How much interaction one can have with other fellow Travellers in port is still up in the air. There almost has to be a pub, eh? Trade is live but probably also boring for those who don't live for trade (i.e. everyone who's not an accountant). So I've got a shortcut for those who just want to grab cargo and go ( = hire a broker at the port to obtain freight for you). Starport 'slumming' and the trade system both work, but are not integrated into the game.

There is a mission engine, with a patron, payment options, and assignments for each mission. It currently doesn't do anything, but the plan is for the starport to have places where missions can be accepted. Since I don't know how to do missions well, they'll probably be limited to running cargo to dangerous locations for a lot of dough, or collecting a bounty on a known pirate.

There's a jump system built, but of course not integrated into the game. Jump is probably really, really BORING, because I feel the desire to model TIME as a component of the sim. Thus it could take 3.5 real hours(!) to jump. That means I jump in the morning, then check my status at lunch break and perhaps jump again. I may really have to make shortcuts here (such as selling jump drives that reduce travel time considerably) because that's bound to make the sim VERY BORING. What I'm experimenting with is a game that doesn't reward players for being constantly logged on, but rather, consistently logged on. That puts busy folks on a more even footing, and reduces server load at the same time.

It's the multiplayer Traveller sim for the casual gamer who has no time and doesn't like action!

Sure to be a big loser!

Half joking, half hopeful.

 

[Andrew Boulton]

So when do we get to beta-test it?

 

[robject]

Yah, that's the proof, isn't it? Well let me figure out a plan to make available a pre-alpha.

Pre-Alpha:
1. plug in a basic ship controller (the easy part)
2. add a logon screen
3. wrap it up with JNLP

If history is any indicator of future progress, I will probably not finish . But on the other hand, it's certainly possible to slap together the above, right? Right??

 

[pwilcox]

Sounds like you've already got most of it figured out, but I thought I'd throw in another idea for sources. Take a look at the computer game Starfleet Command. It's based off of Starfleet Battles, which is obviously a Trek-world game. However SFC is 2d and mouse driven. You can manipulate your camera angle in relation to your ship, and you use the mouse to direct heading. There's also follow and orbit commands that work.

As for missions, make sure you include system/world survey missions. Require a team effort to get the full survey, and maybe a week of time, but boy when you do you sure do get a reward!

I've been waiting for a game like this for a long time, thanks for finally bringing it to life.