Traveller Simulation

[robject]

Heh, don't thank me yet. I've been waiting for this kind of game for a long time, too, and I'd been alternately wanting and trying to do it off and on for the past five years. And once it's working, it's almost guaranteed to be unsatisfying to everyone (including me) in many ways. But ah well. This appears to be the most flexible and modular yet simple design yet, so there's hope.

Status

The pre-alpha test release is getting closer. The list stands thus:

1. build the tactical control

The controller is in place, but I still have to translate mouse actions into ship actions in a reasonable way. Using keyboard events would probably be easier, if I can get JPanels to listen for key events.

2. build the login window

Done and working.

3. deploy with JNLP

I learned how to do that yesterday. I'll probably have to tinker more with it to get it working over the internet with Apache.

Design

For those interested, I'm using a Model-View-Controller pattern to manage complexity. The Model talks to the server -- currently just a database connection -- and spawns Views. The Views, in turn, each spawn one Controller. Movement is almost guaranteed to be horribly jumpy, so I'll have to compensate by not trying to do "smooth" spaceflight, but something rather more like 1-second-interval positional updating. We'll see. The database hit is bound to be the bottleneck. Of course, that can be largely fixed by creating a server-side listener that caches positional data and broadcasts it by UDP. But there's no way I'm going to introduce yet another layer of complexity at this point.

 

[robject]

Update

More success with JNLP. I've successfully deployed a test app with Apache. WebStart is Very Cool. No forseen problems here, so all that's left there are unforseen ones. Which leads nicely into Controller news:

Success with keyboard listeners. By making views internal frames onto a desktop pane, I can make each one able to pay attention to mouse focus, and therefore have a keyboard listener for each. Thus I can ignore a lot of trigonometry by just using keys for maneuvering. I can also, by default, fix the size of views, thus preventing the inherent update-mega-delay when resizing. Another freebie is that views can be moved around, minimized and restored on the desktop pane if the user wants to do that.

 

[robject]

Update

Awright, can anyone explain to me why Apache on my Win2k box at work can deploy JNLP applications, yet Apache on my WinXP box at home cannot? The jnlp mime type is in the config file for both. A current JRE is on both. Perhaps the version of Apache is different... but I doubt it. I even installed Firebird to see if it might be the browser... but no.

Any suggestions?

 

[robject]

Traveller On-Line Release 1.0

These shots were taken within the 100D limit of a small world in the Darrian system just outside the primary's 100D limit:

http://home.comcast.net/~downport/tol/tol-1.jpg
http://home.comcast.net/~downport/tol/tol-2.jpg

Once I figure out how to deploy with JNLP from my home computer, the pre-alpha test (i.e. Version 1.0) will be released.

This release does very little; essentially it allows registered players who are currently on starships to cruise around a solar system generated from UWP data. Your 'ship' is always in the center of the Tactical and System views; a pointer on the Tactical view shows the direction your ship is aimed, and the current velocity x & y values are displayed to one side. The arrow keys rotate, accelerate forward, and accelerate reverse, while clicking on your ship will initiate a full-stop.

Left-clicking the System view will zoom out; right-clicking will zoom in (I'd also like to make that a click-drag for those who use Macs).

I played around with the sizes and orbit distances some and got them to a good test size. It takes a few minutes to cruise from the center of a system to its edge. Each large body in the system has a "100D" circle drawn around it; however, the Star's circle is 20D I think, because otherwise the whole system's just too friggin' big.

Darrian has a pretty cool solar system. Five gas giants, IIRC.

I haven't put in any code that displays other ships that are in the same system.

If you're interested in checking out the pre-alpha, let me know. I can put you in any system in the Spinward Marches, Deneb, Gvurrdon, Tuglikki, Corridor, Trojan Reaches, or Reft.

 

[Granpafishy]

I would be intrested. Any old system would be fine with me.

at.hastings@verizon.net

 

[TheEngineer]

Hi robject,

I would like to take a look, too

Regards,

Mert

 

[robject]

Logins for Traveller On-Line

All I'll need from you is a user id and a player name. The player name corresponds to a Player Character's name, while the user id can be your first name, or last name, or a unixid, or anything really (though I'd keep it simple so as not to forget it). Email your preferred userid and player name to me at
downport at comcast dot net

If I can ever figure out why Apache on my XP box doesn't server JNLP then we'll be ready to roll. Perhaps I ought to try installing Tomcat.

Very Minor Update

Highports are now displayed on the tactical view as 4 pixel by 4 pixel squares, just below and to the right of the mainworld. All class A starports have a highport, and class B starports with world TLs greater than 9 do, too. You can't do anything with them, but they're there.

 

[robject]

Jump Capability Added

There's now a rudimentary jump capability. A small window holds a scrolling list of reachable destinations and a "Jump!" button. And so I spent an hour or so last night jumping around the Regina and Vilis subsectors. There is no week-long jump delay, and fuel is not checked, though jump drive number is.

This is getting interesting. But I'm getting ahead of myself, because my first order of business should be getting JNLP working on my home computer.

To-Do List

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">A - Urgent
1. JNLP!

B - Normal Precedence
1. Other ships
a. Store positions in Model
b. Realtime updating
2. Object selection on the Tactical (& System) View

C - Lower Precedence
1. One-click in-system course setting
2. Fuel
a. Gas-Giant & wet-world refueling
b. Fuel use for in-system maneuver
c. Fuel check for jump
d. Fuel use for jump
3. Jump
a. Add delay (say, 15 sec for starters)
b. Expand to include non-mainworlds
c. Expand to include empty hexes</pre>[/QUOTE]

 

[TheDS]

Egads! Sorry I wasn't back sooner.

Hours for jumps, are you crazy? Who the heck do you expect to tie up their phone line, just to watch a jump field for 3.5 hours? The whole "on line" phenomenon could stand a bullet or two on the head; there's way too much crap out there, and a game like this that takes so much time to do any single thing is NOT going to appeal to anyone.

Have you played the Megatraveller games at all? I finished the first one, never got into the second. The first one was really cool, really well done, considering. I was hoping you were going to make something more along the lines of that, with, like, more than 1 color. Elite was advanced for 1985 (or whenever it came out). It frightens me to look at your screenshots. I'd never have wanted to play an MMORPG version of Elite back then (well, maybe until the novelty wore off a day later). MULE, maybe, but please tell me your interface for it won't be as cheesy. MULE looked ugly even back then.

I'd like a game that's more along the lines of selecting where I want to go, and getting there quickly, like in seconds or less. if I wanna watch the stars sit there for hours, well, I can do that, but it'll be more entertaining to do it from a rotating space station, cuz at least they'll move. Maybe watch as my ship docks and undocks, but if I have to dock in a rotating station, through a narrow hole that I crash into 98% of the time, well, let's just say I won't be happy with you.

Space is boring. Why bore people? I sure ain't gonna sit there, watching. If I'm crazy enough to execute the file a second time, you can be sure that there better be an auto-pause for when interesting stuff happens, so if I'm away from the pikachu, it doesn't die on me suddenly. (What are those stupid electronic pets called?)

It's neat to look at space rocks, of course, including those big blue planets, and those bigger, red gas giants, but just traveling through space, well, I'm not interested in that. Let me skip to the parts where something happens, and don't FORCE me to watch something if I have no interaction with it.

That's what made games like MULE so awesome: interaction. Elite survived because you could watch stars go by, and they were big ones too, so you could see them even if you photographed the screen or had glare.

I seem to recall another game, called Starflight, in which you had a ship, and you could upgrade it over time, you'd go collect resources and fight aliens and look for clues on how to stop this black planet from destroying Arth (Earth 2). Really cool, but wandering around the planets got kind of boring, unless there was something for you to shoot. Flying around space was boring for long flights too, unless there were aliens you wanted to fight or needed to avoid. (Some of those buggers were tough!)

In any case, Starflight and Elite didn't have TOO much slack time. Generally no more than a minute or 5 between important decisions, and you usually had something to do (though setting auto-pilot let you walk away for a minute; just be sure you come back in time!).

No one's going to want a boring game. You've got a number of interesting ideas there, and they would be cool to implement into a game, but you can't go and bore the crap out of people and expect them to do anything but call you names. So cut the useless, time-wasting stuff off the "you must do this" list, and put it on the "you CAN do this, or you can skip it" list. And put in some better graphics. They don't have to be award-winning, but really, those screenshots scared me. I could be scarred for life! Or at least the next couple minutes.

 

[robject]

Hello DS, thanks for coming back. I'm glad the info and pics got your attention, so to speak.

As a way of sympathizing with you and explaining myself at the same time, here are guiding principles of TOL, fuzzy and flawed though they be.


0. It's not a game.

A game requires more resources than I can ever hope to muster.

The other side of this coyn is that someone ought to produce a Travelleresque, navigable, interesting insystem that's just a big, online battleground.


1. Seek and ye shall find.

This is a principle of least surprise. If you want uneventful travel, let the ship fly itself. Game state is persistent; log off and come back after arrival time, and your ship will be parked, safe and waiting for you.

Too boring? Jump to a frontier mainworld and lurk inside the 100D limit. Or the gas giant. Or land at the downport and hang out in Startown. Trouble will find you.

The other side of this coyn is the Principle of Artifacts and Upgrades. Upgrades cost money, while artifacts are usually in inconvenient places.


2. Time waits for no man.

Starports are cramped and fast. Soldiers, mercenaries, traders, and pirates come together to refit, organize, cash in, or look for trouble.

On the other side of this coyn is the price of space travel -- wait time. There's no gratification in space travel. That's why TOL is not a game.


3. Graphics are not a priority.

I've no graphic art ability. Just getting this out the door will be a major feat for me.

 

[robject]

Update

Alright then. I may have resolved the JNLP and server issues. The simulation requires a recent JRE and WebStart, and loads the core jar (38k) plus the MySQL connector jar (225k). Once the thing loads, the only updates that you would ever require are to the core code, so the MySQL connector only downloads once.

Both files are signed jars.

If you asked for a login, try it out and see if it loads:

http://24.1.3.180


Rob

 

[tjoneslo]

I just tried it and am getting connection refused. It won't even connect to the IP address.

 

[robject]

Yep, I'm getting that too. The computer must have been shut down.

 

[robject]

Must have happened in the last hour or so. Sorry about that... I'll set some policies about when the computer should be left on...

 

[mabmoro]

hmm... how does one join this alpha? it sounds great to me...

 

[robject]

Hello all, this thread is quite cold, but I thought I'd post a link to the guiding philosophy of what I want to do with Traveller On-Line:

http://home.comcast.net/~eaglestone/sim/Simulation.html

And if you're interested in what I'm doing, let me know your suggestions. Even if I'm unable to do them, I still want to hear them.

How many types of rewards are there? Things like money, access, privilege, skill, promotion, and ownership.

 

[JustinThyme]

I have to disagree with items 1 & 3 in the Art of a Good Simulation. The early Traveller rules always warded off numerous payoffs, no matter how small. This supported your item 4. E.G. you may have finished the scenario/episode but you got your nose bloodied; or Rifle skill may have improved one, but getting shot taught you to clean your weapon.
Item 5? You can run off players with that one. Or do you mean something in the material sense?
Item 6? Please clarify.
Item 9 is a little broad. Even individuals must exercise a zone of control when in conflict.
I don't understand the bent of item 10. Need your help on that one.
Item 13. You're going to need a lot of it if you try to roleplay number 12 with any validity.
Everything else brings a satisfied smile to me, especially the Successful, Addictive Games section.
The types of rewards? Sounds/reads like you know your Traveller.
Enjoy your posts. Will look for your response.

 

[robject]

Hi Sol,

Maybe it helps to know that those notes for simulations are not Traveller-centric; rather, they're for computer simulations. I think that helps explain points 5, 6, and 13 -- computer simulations lose their way when they become mere engines to fiddle with. Points 9 and 10 may be rather archaic (the list itself might be several years old).

Now as to points 1 and 3. Since I can't simulate character generation -- which is how Traveller awards numerous small, early, fast, incremental gains -- I have to think of some other way of making players happy to be playing. Of course, I will just be happy feeling like I'm trading along the Spinward Main, or exploring along the Rift in Corridor, or taking the long pilgrimage to Vland or Sylea.

But everyone's going to need some way(s) of making themselves useful, some way(s) of defending themselves, and some way(s) of travelling. Noone has to own a ship (though I expect many people would want one). But if you don't have a ship, then you'll need a way of getting a passage, or you'll have to have contacts -- intangible benefits, perhaps. Or privelege. A Baron might not need to worry about money. Nor might a courier.

Rob

 

[cq081]

But isn't character generation an integral part of 'getting into' one's character? Certainly rationalizing all those 1&3 incremental changes is a large part of how I personally build up my initial character and his or her attitude at game start. As such, I think CharGen should be simulated, if only by invoking a character generator.
This is why I don't invarably muster a character out ITMU, especially those in non-military service -- I'll often permit the mustering out rolls to show accumulated wisdom / stuff to date, but a good merchie has reason to travel, no?

 

[robject]

vel,

Yes, chargen is integral to Traveller roleplaying. And a player has to get his stats somehow. So I'm thinking you're right. And that's not a show-stopper anymore.

I've written a server "middle tier" that acts as the go-between for the client and the database, so that means anyone could write client software for it, as long as they spoke the server's protocol. Any client could connect as a player and interact with the universe.

So, has anyone out there written a modest chargen program that can talk across the network? If so, let's talk about protocols. I've started the protocol work here:

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

If you want cool graphics, sound, and special effects, you can code it up; all your client needs to do is be able to talk to the server correctly.

In fact, here are the client programs I think would be good to have. In the best of worlds, they'd be integrated into one big app, but they don't need to be that way.

(1) a character generator
(2) a 'starport simulator'
(3) a 'downport simulator'
(4) a world-surface exploration simulator
(5) a space travel/combat simulator

#4 would have to take combat into account as well.

It might be nice if #5 took shipboard combat into account as well. Boarding actions, etc.

Of course, all this is pie-in-the-sky. Coding these client programs can be difficult.