Traveller On-Line

[robject]

As usual, in the springtime I start thinking about my favorite vaporware program -- Traveller On-Line, or TOL for short.

TOL is a barebones, generic Traveller simulation. Rather than being robust vaporware, it concentrates on existing. Its only working version was written in 1998, and was, to understate things, limited. But it existed.

It was strictly HTML-based. Despite that, it was nifty. So I want to write it again. It's all in my head, except for one issue I need to understand.

Space combat. How can you possibly represent space combat between two players in a strictly non-dynamic HTML context?

I can only think of one way: resolve it automatically. In a way, this is unsatisfying, because you don't manually fire the guns and see bits of ships flying off. On the other hand, it makes combat fast and simple. You can get a combat summary, too, which can be a dramatic read.

All I can reasonably see, within the given project scope, is a list of ships in hailing range with an "attack this target" button next to each one which runs the combat sequence.

Am I missing something?

 

[MR TEK]

the only alternative would be orders, of a very simple nature, and then a set of rules ala blitzkrig or ace of aces that matches your oders aginst their orders and that plus that apropreate stats drives the resolution. then a short movie, or sequence of pages to show SOMETHING happening would be the most you could get that would allow players a little control over combat.

Movies would be limited to one sequence that is just a generic excahnge of fire.

Pages you might be able to get a few basics, so that atleast there is a generic view of what your orders did.

Just some thoughts. Html is the hardest way to do something that by it's nature requires some interaction.

Mr Tek

 

[robject]

Thanks, good suggestion. That would work. From an HTML standpoint, your observation is correct: it wouldn't be worth the effort.

 

[inexorabletash]

You mention non-dynamic HTML, so that says we're dealing with rather basic HTML 3.2. Possibly no script (so just forms), or just script that can interact with form data (but not the DOM). That means the user experience is going to be (1) enter commands (2) submit (3..9) wait (10) see update

How smart is your server? Mr Tek's idea of a moderated Ace of Aces isn't out of the question, nor are movies. But take it further.

Imagine combat on a Mayday-style hex grid. Take what my site does for static UWP data and apply it instead to ships with motion vectors and weapons. Instead of rendering a single frame, render a sequence of frames and composite them into a movie (we're talking retro browsers, so an animated GIF would work; concede a little bit of script and do a slideshow). So in step 10 you'd see a movie of "what happend resolving the last set of orders". This isn't that difficult, nor is it too different than traditional game programming, just sliced differently.

If you allow for AJAX (modern browsers as a baseline) you could do anything from Asteroids to Wing Commander in terms of visuals. There's no reason you couldn't have a large "viewport" (either first-person or overheda) with command/control UI scattered around it. (I'm assuming this is not realtime - then you're dealing with lag and chatty protocols.) As a comparison, someone managed to put together an AJAXy implementation of a terminal emulator. Graphics are just a fancy layer on top of that.

 

[robject]

Joshua,

Your site rocks.

In fact, my previous attempt used a Java WebStart client talking to a Perl middle layer using YAML over UDP. The client had... aw heck, maybe I still have screenshots. Hang on.

Nah. Well, it was primitive, but I loved it. My ship was a little vector-drawn asteroids-ship-clone, and I could jump from system to system, and flyby the planets. I used planetary images pulled from NASA, so that part was cool. I was working out how to do combat when the project just fizzled. It was too much for me.

In other words, I can't produce anything useable when the sights are set even to that elementary scale. The project just becomes too much. Scope creep, you know. Add another rock to the cart.

On the other hand, Joshua, you've done some very nice things with .NET. I don't suppose you'd be interested in figuring out a graphical client? Once we establish the protocol rules (i.e. the control language), there's just the model and view to write. One for you and one for me?

 

[jfetters]

That IS cool.

Joshua, where did you get all that data for the Zhodani core expedition sectors? I hope you don't mind, but I think I may use your site to figure out where I am going to create my new setting in relation to everything else.

But to the topic at hand - what about the thought of translating Brilliant Lances movement rules to this format. (I know mayday was mentioned, but just asking.... I would love such a site!)

 

[robject]

Ah, Joshua was probably the guy who built the core route sectors. Am I right? I thought I recognized you...

 

[inexorabletash]

If you read the More Info page (hidden, I admit) you'll see that the Zhodani Core Route sector data from The Core Route Projects (http://www.geocities.com/traveller_core_route/), courtesy of Clifford Linehan. Please use the site - that's why I put it there!

Re: starting another project -

I could possibly be suckered into it, but I'm away from home at the moment and will be spending most of March away on vacation (Los Angeles, then New Zealand). So anything would have to wait until after that.

I hear you re: scope creep. I have a vast pool of unfinished projects.

You have a good insight into this one - break it down into the m/v/c components. Come up with a nice model, build the rules that act on it, and the view is resonably.

 

[robject]

I booted up my old server, and it (apparently) still works (what do you expect, it's perl!). The client, however, dies after several attempts at extracting data. Probably is looking for data that's not there.

So now I'm faced with figuring out what's missing with last-year's client. I'll probably do that, rather than start over. Maybe. I don't know.

 

[robject]

Joshua, in reply to "how smart is your server?":

It's flexible, meaning it's currently as dumb as a box of rocks. But its only bottleneck is that it assumes client-pull: it only serves data based on requests.

However, it's also flexible, in that any number of server-side software clients can connect and change the system state. These clients are, in effect, part of the server, and in fact represent in-game processes. And they have unrestricted access to the system -- something true clients don't have.

For example, the clock client logs in once every 50 seconds or so updates the world time by an hour (I should do this with fork instead). The NPC client updates vectors of NPC ships and missiles. The damage client checks for damage inflicted on ships by anything at all. The starport-market client randomly logs in and consumes imported goods and produces goods for export. You get the idea.

 

[aramis]

I, too suffer from massive scope creep.

I've an MT CG module in partial completion in Python... it climbed above my scope limits when I went back to start my master's... this fall just past.

 

[robject]

Ahhhh, Python. I should've coded the client in Python.

 

[inexorabletash]

Fun - nice architecture. There'll be issues with growing it, but there always are.

Sounds like it'll be simple to bolt on another server-side client that does handles rendering requests. So if you want a snapshot, the user-client just requests a render (e.g. "http://server/showmeview?hashed_client_code=1234abcd") and gets back an image.

To get started with my map site I started small - I wrote client code that requested a bunch of images (x=-2..2, y=-2..2) and assembled the HTML, and server code that rendered a tile by setting a viewport and rendering a big circle (so each tile saw part). Once everything matched up and I saw the whole circle on the client side (i.e. got the bugs out), then it was just a matter of adding features one at a time: replace circle with vector borders, add sector lines, load UWPs and render worlds, add client-side dragging/zooming, etc.

So I'd recommend starting small: whatever web server your box is running, grab an appropriate server-side graphics package and just render a big (e.g. 500x500px) image with a text dump of the state. Then it's just a matter of defining what you want to show! I.e. get an artist or draw on your artistic side. Note that I skipped that - I'm drawing on existing render styles from Traveller sources, so I didn't have to get creative.

 

[FlightCommanderSolitude]

Robject, have you considered inline SVG for simple graphics? You can do some interesting things, and with CSS and JavaScript integration you can really mess around interactively with graphics.