Traveller Simulation

[robject]

In fact, I think a PHP-driven character generation script would do very nicely for a no-frills solution with a reasonably timely development time. I might even be tempted to write that one.

I can see three PHP scripts.

Entry script: the script presents the player with a randomly-generated UPP, and the player enters in his name and his characters' name and selects a service branch to try for. The script records the names, UPP, service determined, notes if it was by draft, sets the number of terms to zero, sets the characters' age to 18, and passes control to the career loop.

Career script: this script runs the character through one term, increments the number of terms, adds 4 to the characters' age, and records any skills learned. It shows the service, term number, rank, notes if the UPP has changed, and shows the current skill list. The player selects whether or not to continue, and selects the skill categories to select from on this term.

Mustering out script: this script displays the character and the player selects how many times to roll on the cash table (+1 modifier always applied if available) and rolls the rest on the benefits table; the benefits table results are displayed, and characters with high rank may choose to add 1 to any of the benefits rolls.

 

[robject]

Update. I had a little free time, so I dusted off my Traveller-On-Line code and did a little work.

I've managed to decouple the client with the database, which means it doesn't need a JDBC driver, and so the client code has shrunk. On the other hand, the client data has expanded, because I've been experimenting with adding true planetary images instead of filled circles. You can see some of the attempts here:

http://home.comcast.net/~downport/etc/tol/

The to-do list is:

1. get the jump-destination list re-populated
2. monitor local in-system activity
3. bundle the client back into webstart

If I get to #3, I'll be ready to extend the existing engine to include trade and ship combat.

 

[asmodeus]

I like your idea robject. I might be able to help with the client programs (character generatation, etc). I am rather time constrained right now, but it seems like an interesting thing to work on.

 

[robject]

Here's Yet Another Update.

Last month I replaced the colored circle planets with JPEG images from NASA as a proof of concept. Next step is to generate images for all of the types of worlds to be encountered. I've found a few programs that can generate planetary images. If you know of a program that does this well, I'd like to know about it.

I'm currently improving the star system generation logic: namely, code that builds systems with multiple stars, asteroid belts, and moons. Should be done with that in a couple days (hobbies move in slow time).

Things that have yet to be thought through are: the speculative trade engine, the NPC AI routines, ship-to-ship combat, starport docking, and interactions and transactions at the starport.

I'll consider TOL to be good enough to be used when a player can buy and outfit a ship at the starport, buy cargo and book passengers, jump to a destination system, dock at the starport and unload cargo and passengers.

I'll consider TOL to be greatly improved when chargen and the main engine take player skills into account, players can book passage aboard any ship that has locked in its flight plans, players can transact and interact at a bunch of different shops at the starports, and ships can fire on other ships.

 

[robject]

Planet images

Some folks suggest taking texture maps for creating planet samples.

Actually, I took images straight from NASA -- they have absolutely huge TIF files.

And for y'all's personal edification, check out this program which generates random fractal world maps:

http://www.eldritch.org/erskin/crida/planet.php

It can do orthographic projections (i.e. globes), but sadly, it doesn't do cloud cover, but since most worlds have next to no atmosphere, that problem can be addressed separately.

Chargen Application

Offhand, for chargen, perhaps using the CT skill set would be an easy start; and that's no problem, since skills naturally appear to be Objects in their own right, and so 'upgrading' to a new skillset for the chargen program should be no problem. As far as connecting a chargen program to TOL (or anything else), as I hinted at earlier it should be standalone, with a factory that returns a proxy. The proxy then talks to the appropriate receiver and transmits character data. That gives you maximum freedom in designing your application, which minimizes our integration testing time as well. And the proxy can be written last, when everything else works. Or, alternately, you could first write an HtmlFileProxy proxy which simply writes the results to an HTML file. That would be neat!

TOL is a Lot of Compromises

And, Vanguard's suspicions and worries are correct about space combat. To date, nearly everything in TOL is a compromise between the Traveller rules, playability, and minimizing the work needed to get it up and running acceptably.

For example, the 100-diameter jump limit is actually a 10-diameter jump limit, because space is Too Big.

And another example: time spent in jump is going to be very quick compared to the real Traveller universe. Even with the usual time speed up (1 minute being 1 hour or some such), jumps will probably not take 168 minutes. Noone wants to wait that long. Although, it does make the game a little more friendly for people who have no time.

Combat Thoughts

Here's what I've done so far to pave the way for space combat compromise with minimal effort:

1. The tactical view represents an indeterminate range -- some tens of thousands of km -- but is the maximum combat range. I decided to not worry about sensor lag until I have something working.

2. I've thought about making mouse actions context-dependent: left-clicking on your ship puts the ship in full deceleration, while left-clicking elsewhere could target and scan a nearby object. Right-clicking would fire a missile, while left-dragging would fire a spread of lasers... something like that. If it works, it means players won't have to fumble at the keyboard. The client currently has code that detects these mouse actions, but the combat actions are stubbed out, so all that's up in the air.

 

[TheEngineer]

Hi robject !

Great work so far.
I hope it goes on....

Best regards,

Mert

 

[Vanguard]

I like that planet generator. I think it would work great for our needs, it just needs some extra code for clouds and it would make a great generator for earth-like planets.

Other planets (rockballs, gas giants, etc) will need a bit different type of generator (or a lot of tweaking to that one)

On the topic of time dialation, I almost think we should let jump take 168 minutes. Almost every other online multiplayer game is designed for people who have nothing better to do than play it all day. It would be interesting to see a game where you're forced to take breaks. Probably the best way to work it is that it would have a minimum jump time of 168 minutes, but you can stay in "jump" as long as you want. Then you can jump, do a little bookkeeping/whatever, then log off. When you're ready to log back in, if the min jump time has passed, you can tell your ship to exit jump. It makes the game a weird hybrid between real-time and turn-based, and I think that's really cool.

As for the combat, I'd like to shoot for something that's a cross between standard overhead space shooters (think Star Control or Starflight) and a submarine game. Sensors and signature management hasn't really been done well in a game that I've seen, and it fits well with (some flavors of) Traveller.

Overall, I think we should be focusing on what "feel" we want from things before we worry too much about implementation details.

Comments?

 

[robject]

Thank you, Vanguard, that's exactly my opinion of jump delay. In fact, a prototype frame had the jump ETA on it, and if the jump was complete an "Exit Jumpspace" button was enabled.

Anyhow, if it turns out to be too long to wait, I can always adjust it.

I think the numbers I did placed a jump duration somewhere around 168 minutes. That works for working folks -- jump before heading off to work, then jump during morning break, then jump during lunch, jump during afternoon break, etc. Folks who want to spend time on the game can wander around the star system -- which means high-pop systems need to have plenty to do, and multi-star systems need to be interesting enough to explore.

And your opinions about combat are much in line with what I'm thinking of.

For the time being, by using that planet generator plus tweaking the NASA images, I'll have the airless worlds, Earthlike worlds, and gas giants pretty much in the bag. I can also use NASA for planetoids. So for now, it will suffice.

 

[Malenfant]

Is it really worth including the ring/ray method of determining world location? AFAIK nobody ever uses it in any published Traveller work - they use the subsector/sector grids instead.

 

[Vanguard]

I'm glad we're agreeing so much on this stuff. I'm used to lots of arguments about design and implementation at work.

Thinking about sensor delay, most of the Traveller starship combat systems eliminate this problem by making the turns really long, so you can detect, predict, and fire all in one turn. We might be able to do the same trick since we'll be already dialating time (1 minute or hour game time=1 second real time, for instance)...then we don't really have to consider sensor and weapon delay, we can just say that the ship's computer is doing all of that for you, and you're seeing the output (which looks real-time, with no delays).

It's kinda cheating, I know, but it might be the best way out of that pickle...it gives us more time to focus on the sub-warfare feel.

 

[robject]

Originally posted by Malenfant:
Is it really worth including the ring/ray method of determining world location? AFAIK nobody ever uses it in any published Traveller work - they use the subsector/sector grids instead.

It's sort of the other 'way round: sector+hex is the inclusion, for user-friendliness' sake, while ring/ray is the internal 'true' location of a hex, used for all interstellar distance calculations.

(Related: since ring/ray isn't used, I suggested to Marc that he eliminate the 0th ray and name Sylea as the 1st Ray, since this would unify the distance formulae used by both schemes. He hasn't responded. Not that I expected him to.)

 

[robject]

Originally posted by Vanguard:
I'm glad we're agreeing so much on this stuff. I'm used to lots of arguments about design and implementation at work.

Thinking about sensor delay, most of the Traveller starship combat systems eliminate this problem by making the turns really long, so you can detect, predict, and fire all in one turn. We might be able to do the same trick since we'll be already dialating time (1 minute or hour game time=1 second real time, for instance)...then we don't really have to consider sensor and weapon delay, we can just say that the ship's computer is doing all of that for you, and you're seeing the output (which looks real-time, with no delays).

It's kinda cheating, I know, but it might be the best way out of that pickle...it gives us more time to focus on the sub-warfare feel.

I really agree here. And since I always assume "the project will never be completed", I therefore prefer to cut corners and make compromises where reasonable.

To give an estimate: the only time a version of this program was running was back in 1998, and it basically had a CGI interface and was very primitive. I've been re-writing it, off and on, ever since. This latest version -- the most promising to date -- has been around since late 2003.

I really need to finish my changes to the database schema. "Real Soon Now", etc etc.

 

[robject]

For your amusement, here's the current output from my solar system generation script.

http://home.comcast.net/~downport/etc/calida.yml

Items remaining to be implemented are (1) determining orbital position and (2) building SQL load file. Neither are very difficult, they just require some time.