Leviathan - WWII sub simulator

[Lucifer]

So, I've been running around 28 hours now, please forgive me if this post doesn't make as much babble as I normally do.

A couple of days ago I got a hankering to play Silent Service, so I went and found a copy of the Amiga verson of the sequel (which was surprisingly better than the first), rammed it into UAE and went off on it. And felt kinda glum that there's no such game for Linux, or even Windows right now.

So last night my wife tells me if I feel like I need to be studying, I could crank out the trig book in my room and start working on it.

So then I'm looking at armagetron source code and realizing how very little game programming I've done over the years, and thinking if I were to start a new game from scratch and work on that for awhile, it would do me a lot more good than reading armagetron source code (then I'd have more experience to use when looking at the code, there's quite a bit of difference between game programming and pretty much any other kind of programming).

So I can add those up to 3, and last night I started working on a WWII sub simulator intending to clone Silent Service II (the amiga version), making reasonable improvements to the simulation along the way. I dug around and got pyOpenGL installed, already had pygame, and then I needed PIL, which I also already had. It's a surprisingly close approximation to what libraries are being used in Armagetron. I'm not using pygame very extensively, since I'm using pyOpenGL for the graphics, and pyOpenGL is just a thin wrapper on OpenGL (you use the same reference materials for it as you do for regular OGL programming). Not much room for network play, and certainly not at the beginning.

So I've got a plotter and a couple of game objects. One's a sub, surprise surprise. You can manuever the sub a bit. You know, turn the rudder left and right. Of course, you have to be moving to actually turn, so there's commands to move it. And diving, of course. No weapons yet, and some of the things you'd expect with what's there isn't there yet (you go the same speed underwater as you do above water, for example). There is a radar, it was one of the first improvements I made. The original game didn't really have a radar, it just showed you a map with all known enemies plotted. I decided I wanted a real plotter, so I made one, basing the UI a bit on the map room in SSII.

It's got basic font support, but all of the graphics it has now (besides the font) are just lines and polygons drawn with OGL. No models.

So there's a screenshot attached. Anybody want to work on a sub simulator with me? What it needs before other game objects, really, is to be scaled properly. I screwed up and based position on Lat/Long, distances are all stored internally as miles (hardly a good unit for submarine engagements). At least I got bearing and heading right, unlike those robocode people.

So I've gotta go back through the units and make sure I'm storing all distances as feet, using lat/long minutes or even seconds instead of a float lat/long. My brain is burning right now, I got stuck on math I should've blown away 'cause I was so sleepy.

The simulation itself is looking good, but it's feeling sluggish. I think I made the sub accelerate and turn too slowly, heh.

So if any of you wants to work on it with me, PM me or something and I'll create an account for you on my machine (and promptly stick the sources in cvs). You'll need to be ready to use Python.

On a side note, while I was poking around I found python model loaders for 3ds and VRML files. We need python support, we really do.

[Tank Program]

I'm not really up for starting a project, but it looks pretty cool!

[TiTnAsS]

I'd help if i knew how

[Z-Man]

If you need specific help with trig, just ask. But I'm only helping with projects that use metric units

[Jonathan]

Such as Armagetron?

[Z-Man]

Yep. Speed is officially measured in m/s, distances in m. (Whatever that means in a virtual world, don't start that discussion again )

[Jonathan]

Okay, another discussion. Does acceleration in m/s^2, added in zero time at each step, and not touched until the next step, make sense?

Edit: To be more clear,
good (and framerate-independent):

Code: Select all

position=position+t*speed+.5*t^2*acceleration
speed=speed+t*accel

bad:

Code: Select all

position=position+t*speed+t^2*accel
speed=speed+t*accel

armagetron:

Code: Select all

speed=speed+t*accel
position=position+t*speed

...

[Lucifer]

If you need specific help with trig, just ask. But I'm only helping with projects that use metric units

Heh, ok. I might be converting it to metric, actually, after all the hair I pulled out trying to convert nautical miles to feet. I could use metric internally and convert to feet/knots/etc right before rendering.

(realistically, though, the US Navy, who owns the sub I'm simulating, uses imperial units. In 1937-1945 it's possible the brits were still using some imperial units, but I seem to recall the centimeter was standardized at 2.4 cm = 1 inch because of problems in WWII between the american units and british units getting their, uh, units mixed up)

[Lucifer]

You got me curious, z-man, so I went looking.

Apparently there's a metric version of the knot that is equal to 1600 or so meters, but it's use is discouraged. Other than that, I could find very little or no information to tell me what units were used by which navies. Since the base of the game is intended to be a fairly generic submarine simulation, it would make sense to convert to metric units internally (it would simplify a number of calculations) and then make the unit conversion for the UI on the fly, but there's every reason right now to think the British navy still used imperial units, although the germans may have used metric during that particular war. No clue what Japan would have used (and since the metric system originated in France, it's probably a fair bet they used it at that time, there's even a fair amount of Jules Vernes material that uses it and he wrote right around the turn of the century).

edit: now that I think about it, in In Search of the Castaways, one of the characters goes out of his way to explain the "new" metric system to the passengers, so Jules Vernes was evidently an early adopter at least.

[Lucifer]

Ok, I've rewritten all the math substantially. I knew I should have started with a point class. Anyway, now I've got one. It might get rewritten again to use 3 points, since it is an actual 3d simulation, but that'll depend on how badly I need to try to aim depth charges, since there's no air craft.

And I switched it all out to use consistent units internally and return units that make sense when I need them that way. So m/s for speed, m/s^2 for acceleration, the map is meters, and so forth. The only thing that's still like it was is that knots are used in the interface for speed. m/s is what's used for calculations with knots being the unit you initialize it with. I just couldn't see myself hand-converting knots to m/s for every new class of ship I wanted to add.

Ran into an interesting problem with python, though. When I added torpedos, there's now a shared reference somewhere in the torpedoes that's not supposed to be shared. So when you fire one, you're fine. Fire two and the second one has the same heading, distance, and so forth that the first one had. It's really weird. I went to Python-help with it and am working on it, but the guy that responded doesn't have time to look at the code. It'd be nice to get another pythoner looking at it....

(I put it on my cvs server, so if you want to see it I can give you a shell account and you can see it)

[Lucifer]

Okay, another discussion. Does acceleration in m/s^2, added in zero time at each step, and not touched until the next step, make sense?

No. In fact, using the m/s^2 function doesn't make sense, or at least leads to really hairy code. Unless you require absolute accuracy, you don't need it.

Besides which, I think iteratively adding m/s to m/s to calculate accleration somehow reduces to m/s^2 over time anyway.

Now try to work in mass/energy and see what you come up with. I need some sort of simulation of that for the subs, nobody's going to believe (rightfully so!) that a 2000 ton sub can just reverse direction without stopping, even though that's what it does now.

[Jonathan]

Okay, another discussion. Does acceleration in m/s^2, added in zero time at each step, and not touched until the next step, make sense?

No. In fact, using the m/s^2 function doesn't make sense, or at least leads to really hairy code. Unless you require absolute accuracy, you don't need it.

I just edited the post you're quoting and added some stuff because probably not many people know what I meant and what Armagetron does.

Back to your reply, I don't see a problem with the following.

Code: Select all

position += t*velocity + .5*t*t*acceleration; // possibility 1
position += t*(velocity + .5*t*acceleration); // possibility 2
velocity += acceleration;

[Lucifer]

I just edited the post you're quoting and added some stuff because probably not many people know what I meant and what Armagetron does.

Back to your reply, I don't see a problem with the following.

Code: Select all

position += t*velocity + .5*t*t*acceleration; // possibility 1
position += t*(velocity + .5*t*acceleration); // possibility 2
velocity += acceleration;

Hmm, not sure. The m/s^2 function is based on time since the beginning of acceleration, and if you're calculating it with just the interval between frames, the function is different. I sincerely think (and I could well be wrong), that the function is just velocity + acceleration in this case, and if I'm right, armagetron is doing it right. Which also means:

Code: Select all

velocity += acceleration;
position += t*velocity;

looks right to me. I admit I'm only about to take my trig class and I'm skipping college-level algebra to do it, but we did cover acceleration in exercises anyway, last semester.

There are two things to keep in mind here.

1. Like a movie, we use frames to approximate motion because we can't simulate it in realtime. We can only show where everything is at certain intervals, and we can only do collision-testing and movement at those intervals. So some inaccuracy has to be allowed to accomodate it.

2. We don't have to be perfectly exact anyway. The player isn't going to notice a difference of +-0.02 m/s. How high is our margin of error really?

3. (I said I'm only about to take trig) We need these calculations optimized for performance as much as possible, so it's preferable to accept a certain minimum margin of error if that gives us extra cycles to render with. Unless our rendering is spot-on accurate, it's going to hide deficiencies in the physics model anyway.

Anyway, I'll reread this after I've slept, when the math will make more sense to me.

[Lucifer]

Ok, I found this page:

http://www.everything2.com/index.pl?node=acceleration

edit: http://hyperphysics.phy-astr.gsu.edu/hbase/avari.html

It gives an acceleration function as a = (v-u)/t

Where a is acceleration, v final velocity, u initial velocity, and t is time. Some simple algebra turns that into:

v-u = at

If initial velocity is 0, that becomes

v = at

So in real numbers, we get this:

v = .5 * 10 (seconds)

or a final velocity of 5 m/s.

>>> accleration = 0.0
>>> for a in range(10):
... accleration += .5
...
>>> accleration
5.0
>>>

That's for constant acceleration. Does that answer your question to some extent at least? It answers one of mine.

[Tank Program]

v^2 = u^2 + 2as
the sqaure of the final velocity is equal to the square initial velocity plus two times the aceleration multiplied by the displacement.

in fact, there are a bunch of fun physics equations combing this, energy, statics, friction, and many other fun things .

edit: I thinkI'd be interested in helping out with this just to test some of the physics I've learned