Math questions for ship movements

[Hal]

Hello Folks,
I'm about to resume work on a project I've been working on back in December of 2003. I've been mulling over some issues about recording ship locations in a star system using polar co-ordinates along with ship facing, along with vector value for velocity and dirction of velocity relative to the sun as a central reference point. What I am considering too, is using a scale where each "unit" of measurement is approximately 1,000 miles. Thus, one AU of distance would be measured as being 93,000 units...

Has anyone found any easier method of doing this? Here is what I am envisioning happening...

Ianic in the Lunion subsector of the Spinward Marches has an E class starport. It is also a desert world without any real surface water available for wilderness refueling operations. In order to make things easier, I created an entity known as the Ianic Refueling Corporation, a privately owned and funded business that does not fall under the domain of Star Port Authority until such a time as the starport is upgraded from its E status to at least a C status.
If the pirate player notices the vulnerability to commercial traffic and hits any of five oilers/fuel skimmers on their runs to and from the gas giant to the main world - it will cause a major headache for the local anti-piracy commander. This means that instead of having the fuel shipped from the Gas giant to the mainworld - the merchant crews will now need to spend nearly a week in transit to the gas giant to refuel. This week in normal space will give the pirate ample time to hit merchants etc.

If the world has some 63 ships inbound in any given week, and the same 63 ships outbound in the same time period - there are going to be a few ships that I need to keep track of

Any suggestions on how to simulate actual plotted trajectories would be appreciated as well. The general assumption here is that while the players themselves may not know how to lay in a course in space, the navigators in the game trained to professional levels most certainly WILL.

Thanks in advance...

Hal

 

[tjoneslo]

I've almost started a project like this about a dozen times.

In my projects I've always used cartesian coordinates based upon the center of gravity of the system (usually the center of the primary). For my calculating mind, I can do cartesian better than polar.

You may think that keeping track of 60+ ships and 50+ system objects to be a lot, but I would just do a simple list and loop through it.

For a program like this, I would do the simplest, fastest to write method to get it to work. Worry about clever bits later.

 

[robject]

I did just that when I wrote my program. Objects in a system have x, y coordinates, centered around the primary star always. I render them with a loop when refreshing positions.

One trick I do do is to calculate planet orbital positions based on a calendar object; this way I don't have to store their positions.

 

[robject]

Hal and tjoneslo, what languages do you think of using when you think about working on this stuff? And what kinds of applications do you think about writing?

I ask out of curiosity, and a hope that someday there will be an easy way to collaborate at some level with this kind of stuff.

 

[aramis]

Since the formulae are in m/s^2, m, and seconds, any other nits needs t keep that in mind...

I usually work in either C (for command line stuff) or one of several basic flavors (for visual stuff)...

I need to start figuring out objective C....

 

[robject]

So here's the reason I'm asking.

I currently have a UDP server connected to a database, which clients can query. The database contains full star systems from several sectors. I've just about decided to move to TCP, which seems to do better across my firewall for some reason.

Anyhow, separating clients from the server allows developers to write clients in their favorite language. Collaboration is minimized down to the protocol spoken; it is not unlike a web service in that respect. Also, a developer only has to write client code OR server code, rather than having to do both. There are other benefits, including the flexibility of writing different clients for different purposes (one for chargen, for instance, and a different one for adventuring).

My current protocol is a relatively simple text-based one, since my needs aren't that sophisticated.

For example, Hal, the client sets a ship position by sending this command to the server:

set-position x y theta id

where x and y are the coords, theta is the ship angle (0 is towards the top of the screen), and id is the ship's ID of course.

Fetching the position is similar:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">get-position 80
: y=-106713 theta=170 x=-28918 id=80</pre>[/QUOTE]If I had my druthers, I'd rather use YAML to transmit data back and forth, but YAML isn't well supported by compiled languages. Also, I have something of an allergy to XML, even though it is an industry standard and would probably be the most robust solution I'd ever need. As it stands, the space-separated key=value pairs works with few bendings-over required (translating spaces to underscores might be the only caveat, but that's no biggie).

For example, to do a scan of the current system, the client passes in the command with the system ID:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">scan 20350
: locationid=20350 type=500 id=22
locationid=20350 type=500 id=23
locationid=20350 type=500 id=79
locationid=20350 type=500 id=137
locationid=20350 type=500 id=139
locationid=20350 type=500 id=149
locationid=20350 type=500 id=687
locationid=20350 type=500 id=702
locationid=20350 type=500 id=704
locationid=20350 type=300 id=20351
locationid=20350 type=300 id=20353
locationid=20350 type=300 id=20355
locationid=20350 type=300 id=20357
locationid=20350 type=300 id=20359
locationid=20350 type=300 id=20362
locationid=20350 type=300 id=20388
locationid=20350 type=300 id=20390
locationid=20350 type=300 id=20392
locationid=20350 type=300 id=20394
locationid=20350 type=300 id=20396</pre>[/QUOTE]500s are other ships, while 300s are "orbits" (100D limits around planets).

As you can see, operations are currently rather primitive; however, they work.

 

[tjoneslo]

In the bad old days I probably would have C. These days I would probably use Java (adding a JDBC link and/or XML messaging) for a project like this. But I would bet with about 5 seconds and goggle I could find a YAML parser for Java.

 

[robject]

Right, my original solution was lots of Java. The painful part was having to digitally sign the MySQL connector in order to deploy the fat client over WebStart.

My next solution is to gut the Swing client to talk UDP to the middle tier on my machine, which is 100% perl, which does the talking to MySQL. Thus I'm protecting my database while also distributing a thinner Java client. That's what I'm now working on, in slow time.

The side effect is that anyone who wants to can write a client in any language with any interface... Swing, AWT applet, CLI, TK, .NET, doesn't matter.

Last time I checked, there was exactly one Java YAML parser, partially implemented, and that only as a proof-of-concept rather than a friendly package.

 

[tjoneslo]

If you aren't going to make the message too complex, I'd think seriously about hardcoding the message parser in Java (or whatever). Using either java.util.StringTokenizer or java.util.regex.Matcher should make this a simple task.

The reason I use XML is because some has already written the parser and a number of tools for working with the data. So it removes a huge amount of work for me. Even if it does look really ugly.

 

[robject]

I agree totally. The messages are extremely simple, and I've done just that -- the client has a TextProtocol object with method hooks to each protocol command. Every command basically looks like this:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> command-name param param ...</pre>[/QUOTE]and return values look like this:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> key1=val1 key2=val2 ...</pre>[/QUOTE]Some return values span multiple lines, one line per object, such as the 'scan' command, which can be used to scan the contents of a solar system.

Each method assembles its request into the appropriate text message and sends it in a packet to the server, then tries to receive a return result from the server. Thus the rest of the client objects are decoupled from the server.

For example, TextProtocol has:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> public Player getPlayer( String uname, String playername )
{
return new Player( fetcher.talk( "get-player " + uname + " " + playername ) );
}</pre>[/QUOTE]Data in the return packets (I'm using UDP) are sent to the appropriate class (for instance, a Player class, or a Planet class), which parses the returned string. They have accessors for the data, of course.

The parsing is normally done by the superclass TolObject, which simply splits the string into key-value pairs, which are then assigned into a hashtable:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> // pseudocode
String[] pairs = message.split( " " );
foreach( pairs[] )
{
String[] onePair = pairs.split( "=" );
hash.put( onePair[0], onePair[1] );
}</pre>[/QUOTE]The TextProtocol's main() method fires up "line-mode" which is simply a loop where the user types commands directly. This helps with client-server communications testing.

 

[robject]

The real fun begins in the client. The client developer has to decide what is to be presented and how it's organized once it's retrieved from the server.

All clients start by getting the username and PC name from the player; from there, the client can fetch the PC's stats, cash, and location. The next trick is to get a model of the PC's environment so the player can do stuff.

If the PC is piloting a ship, then the ship's whereabouts must be mapped out and presented to the player. If the PC is simply on a ship, starport, or planetlike thing, then the 'map' of the ship, starport, or whatever needs to be grabbed and presented.

In the first case, a solar system will be built up. Planets have moons, stars have planets, and all of them have 100D limits. Plus there are other ships likely to be headed somewhere -- the client will have to refresh those quite often. At this level, interactions are vehicular -- movement, combat, and business are all on the ship-level of resolution to this player. Note that other players on the same vehicle will not have this view, but rather have the view described below. For example, one player may be the pilot, but another may be the passenger.

In the second case, the field of play is the vehicle itself -- the ship, the starport, the planet. Relevant targets must be made available to players. They need not be apparent, but the client has to be able to get at the data and present it to the player appropriately. All interactions are personal -- movement, combat, and business.


[Alternately, if one writes a connection-model program like TCP (or a more robust UDP implementation), the server can feed information to clients, which register with it.]

 

[tjoneslo]

I've have a couple of game design books, and seen several more which address this exact problem like this one. Why reinvent the wheel solving this problem.