3D space combat software

[flyingsquid]

Vectors... love 'em or hate 'em, they just get in the way of good role-playing. But if there were a computer program (with GUI) that allowed players and GMs to direct a space combat in 3D using all the clunky physics but without ever having to calculate even one distance, it would be popular among Traveller fans.

Trouble is, where do I start? I'm not a High Programmer, but I think this doesn't have to be too complicated to be highly useful.

Any suggestions? Anyone interested in collaborating on something?

- Milo Holt

 

[WendellM]

Milo, Beladan, Big Tim, and anyone else interested:

The current version of Book 2 Combat Test is now available at (see post below for latest version). It's pre-alpha, meaning that it's missing major features (like combat ). At this point, it's only a set of vector routines, but it might be worthwhile to see how it runs on everyone's machines. The current graphics are just placeholders and will be improved before any actual release (which would need Marc Miller's approval, since it uses his universe). The plan is for this to be freeware with the source code released along with it (once it's been tidied up - it's rather messy right now).

You can move the ships by adjusting their thrust vector endpoints (the green spikes) with the mouse with the left button pressed. The gravity midpoint is shown as a yellow spike, and the gravity at that point is added to the end of the inertia vector. Your thrust is applied from that point. There's little math involved (even internally - the program represents vectors as cylinders that are joined together, so that they work just as in Book 2, rather than as sets of calculations).

I'd be interested in hearing how it runs for you and what your hardware is. If you'd like to help, I could use original 3D models and textures of Book 2 ships (Types S, A, R, M, Y, C, and T) and small craft, based on the Supplements, Adventures, and appearance in the FASA Adventure Class deckplans. These could be done in Milkshape, 3D Studio, Lightwave, Carrara, Ray Dream, etc. since I can convert many formats for Blitz to use (we can discuss details via email or here). Or, if you have comments or just want to discuss this type of project, I'd enjoy hearing from you.

 

[TKalbfus]

Is it a third person, God's eye point of view of a 3D playing surface? Is it a referee's playing aid, or do you intend to make a flight simulator out of it. I think both would be cool. For some things a 3D playing grid would be a good thing. For some other things, it would be fun to sit at in the cockpit of a scout courier, press some buttons and blow things up. perhaps involve a little hand eye coordination as well. Though for Traveller I'm not sure how much would be appropriate. Would the characters in the Traveller Universe actually line the crosshairs up against the target and press the fire button or would they use targeting computers (random die rolls) and simply select the target to be fired upon?

 

[WendellM]

Originally posted by Tom Kalbfus:
Is it a third person, God's eye point of view of a 3D playing surface? Is it a referee's playing aid, or do you intend to make a flight simulator out of it. I think both would be cool.

I first intended this to be a third-person view, single-player game against computer opponents (with networking for multiple players maybe added later). Milo seems more interested in a referee's playing aid, which is fine with me - it's actually easier, since no AI is required

, and since I'd need to allow full, "manual" control of combat results (i.e. referee-determined as opposed to just die rolls) for testing anyway. In this case, the players and referee would gather around the PC rather than around a tabletop. Both are possible, since they're variations of the same thing.

For some things a 3D playing grid would be a good thing. For some other things, it would be fun to sit at in the cockpit of a scout courier, press some buttons and blow things up.

Turning off the grid could be easily done. Sitting in a cockpit would require the construction of that cockpit (one for each ship type), which wouldn't be too hard for a purely visual (as opposed to interactive) one. Enemy ships would still need to be enlarged as they are now, though, for them to be visible at typical combat ranges.

perhaps involve a little hand eye coordination as well. Though for Traveller I'm not sure how much would be appropriate.

Yeah, I don't know that that would work well. Currently everything is 10-minute turn based, rather than real-time.

Would the characters in the Traveller Universe actually line the crosshairs up against the target and press the fire button or would they use targeting computers (random die rolls) and simply select the target to be fired upon?

I imagine those with Gunnery skill using some sort of interactive system that allows their skill to be put to use, while those without just tell the computer which target to engage. In game terms, the player will likely select the target with the mouse, with results resolved by Book 2 die rolls and modifiers (or referee intervention), and the results displayed with 3D animation. I do plan to allow for computer programs to be used as in Book 2, but the simplification used in Mayday would be an option for those who don't want to do this. Since this looks like it's becoming a group effort, I could also make various "house rules" possible options if they aren't really difficult to implement.

 

[flyingsquid]

Wendell, Tom,

I'll email you shortly, Wendell, but I'm gonna continue here as well, in an effort to keep this going on the forum.

Wendell typed: "Milo seems more interested in a referee's playing aid..."

My tunnel vision is so bad that I hadn't even considered a one-player game. Even when I saw your screenshots pasted in the "space combat" post, I was thinking how great it was that you were working on such a visual-intensive referee's aid... but as you already mentioned, a turn-based player's aid is simpler to code anyway.

I have a couple concerns about Blitz, however. How restrictive is the language environment? Could the program allow movement along a third axis, or are the ships restricted to one plane?

Ideally, in addition to movement vectors, the program would allow certain ship orientations, maneuvering options, and firing arcs based on parameters entered for each particular ship. Tom's questions regarding gunnery options highlights the difficulty in assimilating gunnery skills and probabilities into the program's targeting interface. I would suggest in the beginning that we simply allow the gunner to choose a target (The gunner's skill could be listed with each ship's stats), and let the program simply calculate the result. Missiles are a bit more problematic, since they'd have to allow probability re-calculation at each turn, and we'd have to treat sandcaster spreads as area objects with parameters of their own... Still, I don't think it's too much to consider.

My main concern is still whether Blitz allows movement along the z-axis.

Whatever happens, it's good to know that others are interested in putting the Traveller combat grid to code.

- Milo Holt

 

[WendellM]

Originally posted by flyingsquid:
Wendell typed: "Milo seems more interested in a referee's playing aid..."
My tunnel vision is so bad that I hadn't even considered a one-player game.

Heh, I was in a tunnel of my own: I'd never considered it as a ref's aid until I saw your post.

I have a couple concerns about Blitz, however. How restrictive is the language environment? Could the program allow movement along a third axis, or are the ships restricted to one plane?

Blitz3D is quite happy with all three axes with no plane restrictions and is specifically designed for writing 3D games (Details Available Here). Since Book 2 is 2D, I just limited them to two, but there wouldn't be a problem programming it in three. The display and user interface would get somewhat more complex, though. The thrust endpoint would need to be placed in 3D, so you'd probably need to move the camera a couple of times to get a clear picture of exactly where you're going relative to other ships. The gravity wells would become translucent spheres instead of disks. I'd prefer to get it going well in 2D before moving on to 3D, if that's OK.

Ideally, in addition to movement vectors, the program would allow certain ship orientations, maneuvering options, and firing arcs based on parameters entered for each particular ship.

Yes, those are do-able. In Book 2, arcs (and thus orientation) don't really matter. Orientation would be restricted when thrusting to keep the engines pointed correctly some/most/all of the time: TNE/Brilliant Lances deals with this. I don't believe that firing arcs are ever defined in the CT canon, but TNE/BL also covers them. Or, if there's another method besides TNE/BL you'd prefer, I'm open to it (knowing that TNE isn't exactly the best-loved version).

I would suggest in the beginning that we simply allow the gunner to choose a target (The gunner's skill could be listed with each ship's stats), and let the program simply calculate the result.

I agree. The referee could override any result if he so desired

.

Missiles are a bit more problematic, since they'd have to allow probability re-calculation at each turn, and we'd have to treat sandcaster spreads as area objects with parameters of their own...

The Book 2 rules (clarified by Special Supplement 3) cover missiles pretty well. I put in an "Ask Avery" question about sandcaster spreads a couple of months back when I was first working on this, but there's no reply yet. I've never read an explanation of exactly how they work, so I have some unproven assumptions about how they'll need to be programmed.

I assume we'll be starting with Book 2 and then move on from there (CT is listed as Favorite Version for everyone who has posted on this program topic, here and in the earlier thread). In the back of my mind, I've always wanted to see a Book 2/High Guard fusion (as hinted at in Mayday), but that's a possibility for later....

 

[Ranger]

I think the issue of arks of fire are handled in High Guard with the difference between Batteries and Batteries Bearing in the USP. If your planning on integrating High Guard eventually, you can use these two catigories from the begining, even thought they are the same for most of the book 2 ship designs that are converted to HG states (IIRC).

Just a thought,

Rob

 

[flyingsquid]

Rob,

You're right in pointing out that "firing arcs" aren't really handled as such by the Traveller rules; realism has to be balanced against playability, so arcs and headings are largely ignored. It only comes into play with the monster battleships, where I guess the size of the thing prevents all its weapons being brought to bear at once.

But a computer program (if coded correctly) could bust through the calculations for arcs and bearings with relative ease, opening up a whole new aspect of space combat strategy. Granted, these would be "house" rules, so we'd have to give people the option of disabling advanced or "non-traveller" features of the program...

Whaddya think? Wouldn't it be cool if you had to take into account your heading, their heading, your weapons' bearings (not mathematically -- but visually, using a computer GUI)... Imagine frustrating an opponent by avoiding his optimal firing arc... Maneuver drives would be decidedly more important.

 

[Beladan]

Finally got around to taking a look....

I get a 'Memory access violation' error trying to run it. I'm running windows XP Pro on a newer type machine (P4 2gig) with a Radeon 7000 PCI 64 meg graphics card and the onboard AGP disabled. I have 640 meg or so of RAM and gobs of disk space so I'm not quite sure what's what...

Bela

 

[Ranger]

Originally posted by flyingsquid:
Rob,

Whaddya think? Wouldn't it be cool if you had to take into account your heading, their heading, your weapons' bearings (not mathematically -- but visually, using a computer GUI)... Imagine frustrating an opponent by avoiding his optimal firing arc... Maneuver drives would be decidedly more important.

I think it would be awsome. If your going to do that I would suggest a couple of things to take into account. First, as has already been mentioned, you would have to differentiate between ship orientation and direction of movement. A captain with a stronger ship would presumably want to match course and speed, then rotate the ship to get maximum fire power on target while maintaining a matching movement vector. As long as the ship only rotated around it's center of gravity and did not attempt to accelerate it would seem possible to be oriented in any direction and continue on the same movement vector. Second, since orientation would become significant, you might want to build in the option of multiple accelleration legs in the same turn, so that a ship would be able to manuver into a fire postion while accelerating as well (kind of like the movement system in Mayday works). I just tried playing with the program a little bit, but that option didn't seem available.

One note on the program, the ships and the grid flickered in and out while it was running for some reason, not sure why. To be honest, I am not enough of a gearhead in real life to know what kind of info you need to figure out why or put together a good error report for you.

Great stuff guys,

Rob

 

[WendellM]

Originally posted by Beladan:
I get a 'Memory access violation' error trying to run it. I'm running windows XP Pro on a newer type machine (P4 2gig) with a Radeon 7000 PCI 64 meg graphics card and the onboard AGP disabled.

Originally posted by Ranger:
the ships and the grid flickered in and out while it was running for some reason, not sure why. To be honest, I am not enough of a gearhead in real life to know what kind of info you need to figure out why

Thanks for the bug reports. This is just a quick compile of the version I was last working on for my own use, with no routines for configuration on other systems. Future versions will allow more fiddling with video parameters and have more reporting capability to show what's going on. (If that doesn't help, I'll see about putting together a diagnostic program to try various things one at a time and narrow down what's causing the problem/crash on a given PC.)

Helpful info would be your CPU, how much RAM, your video card type and how much RAM it has, what version of Windows you're running (Beladan seems to have done this sort of thing before

), and what version of DirectX you're using. Lastly, it'd be good to mention if your system has trouble with any other games, or if you run tons of 3D games with no trouble at all (in case it's a problem with video drivers or something like that).

The discussion of firing arcs matches my views: CT doesn't have them, except abstractly in High Guard, but they could be done as house rules (whether based on TNE or not).

Originally posted by Ranger:
you might want to build in the option of multiple accelleration legs in the same turn, so that a ship would be able to manuver into a fire postion while accelerating as well (kind of like the movement system in Mayday works). I just tried playing with the program a little bit, but that option didn't seem available.

The current method is straight Book 2, which only has one leg. Multiple legs are certainly possible, but Book 2 only has a single firing at the end of the entire 17-minute turn and assumes that the ship can always manage to bring all turrets to bear, which raises an issue with arcs and multiple legs: If you're oriented where your turret can't bear for 2/3 of the turn, does the laser fire with a negative modifier? Or do you have a 33% chance of firing normally and a 67% chance of not firing at all? Or, should there be multiple firings possible (since each turn is 17 minutes after all), but each with a proportional chance of not having an effect in order to keep the average damage per turn consistent with Book 2 (i.e. if you decide to fire three times during the turn instead of just once, each one only has a 1/3 chance of actually counting).

This isn't meant to shoot down any variation from the way Book 2 does things, but just to point out that things can get tricky when you do. It's certainly possible to have multiple methods to choose from in the program, and now is a good time to start working out and discussing what you'd like to see (while I get the basic Book 2 combat routines in place, so that they can be modified by whatever gets decided on).

 

[WendellM]

Version 3d of Book 2 Combat is now available at (see post below for latest version). It contains the same data files as version 3c, so you only need to download this version. If you've previously installed the 3c version, you can unzip into the same directory and overwrite files, then delete the old "Book 2 Combat Test 3c.exe".

This one has debug enabled, so it should provide a more meaningful message if it crashes. Also, it creates a "log.txt" file. If you experience a crash, please email this file to wendellm'AT'warpmail.net (replacing 'AT' with the actual symbol) before running the program again. Also, please let me know of any error message that may have popped up and what you were doing when the crash occurred.

This version also allows for full control of video setup. If you experience graphics problems such as low FPS or flickering, please try different settings (resolution, fullscreen/windowed, z-buffer/w-buffer) to see what works best for you.

 

[Beladan]

Seems to be running for me. I must have missed the need to extract all the files except the exe to a DATA subfolder... when I did that it worked just fine. I wonder if that was my error with the past version?

Bela

 

[WendellM]

Ah, good! Yes, there is a data subfolder like last time, which your unzip program should create automatically (maybe its "create directories" or "restore directory structure" option is turned off?).

 

[Ranger]

It works great on my system now. No more flickering or 'ripping'. Great work! It just keeps better and better. While we're putting together wish lists for what this program can do, here are a couple more ideas that have come to me. First, could you work in an option for sumultanious movement, that is, plot all ship movements first, then run them simultaniously. Second, when you get to the point of setting up the play field, would it be possible to work it to take imput from Heaven and Earth, or another program like that which generates system data.

Just some thoughts,
Rob

 

[WendellM]

Originally posted by Ranger:
It works great on my system now. No more flickering or 'ripping'.

I'm glad it works properly for you now. Was it w-buffering that fixed it?

First, could you work in an option for sumultanious movement, that is, plot all ship movements first, then run them simultaniously.

That should be do-able (and would work a little like the WW II PC game, Combat Mission). Do you see firing occur at the end of movement, in the middle, or at some random point for each ship during movement?

Second, when you get to the point of setting up the play field, would it be possible to work it to take imput from Heaven and Earth, or another program like that which generates system data.

Given the scale, combat would almost certainly take place around just a single planet and maybe its moon(s), so there's no real need to have the whole system mapped out. However, it's possible to have an entire solar system active in the game. The .DTA file generated by Heaven and Earth is plain text, so it wouldn't be hard to extract planetary orbits, diameters, and atmospheres. I don't think that it specifies how far along in each orbit each planet/moon is, but those could be created randomly (or specified). So, I'd say yes, this could be done, but would probably be pretty far along on the to-do list.

 

[Ranger]

Sorry for the delay in responding. Work and a cold have slowed down my extra-curricular activities (I hate it when real life gets in the way of gaming).

Originally posted by WendellM:
</font><blockquote>quote:</font><hr />Originally posted by Ranger:
It works great on my system now. No more flickering or 'ripping'.

I'm glad it works properly for you now. Was it w-buffering that fixed it?

I think so, I am running it with that option enabled.

First, could you work in an option for sumultanious movement, that is, plot all ship movements first, then run them simultaniously.

That should be do-able (and would work a little like the WW II PC game, Combat Mission). Do you see firing occur at the end of movement, in the middle, or at some random point for each ship during movement?

I've been thinking about this a little bit, and thinking back on some old discussions on line about book 5 combat. IIRC the fire ratings are based on the sustained fire output for the enture turn. It would make sense then to do fire at the end of the turn then, but then the question of range comes in.

Second, when you get to the point of setting up the play field, would it be possible to work it to take imput from Heaven and Earth, or another program like that which generates system data.

Given the scale, combat would almost certainly take place around just a single planet and maybe its moon(s), so there's no real need to have the whole system mapped out. However, it's possible to have an entire solar system active in the game. The .DTA file generated by Heaven and Earth is plain text, so it wouldn't be hard to extract planetary orbits, diameters, and atmospheres. I don't think that it specifies how far along in each orbit each planet/moon is, but those could be created randomly (or specified). So, I'd say yes, this could be done, but would probably be pretty far along on the to-do list. </font>[/QUOTE]A couple of other things that come to mind thinking about this. First is range. Book 5 has two ranges, but no specific distances are given. The main limit is on energy weapons, so at some point there will have to be a range limit established for energy weapons. So, it looks like there would be three sepereate fire arch before even taking turrret placement into acount. One narrow forward arch for spinal mounts, one large arch (maybe 300 degrees) for energy weapons, but with a limited range, and a final large arch for missile targeting.

The next thought is agility. Book 5 makes agility a significant factor. Perhapse you could use the agility rating as the number of legs a ship gets to plot during movement. That would give a significant advantage to ships with higher agility.

Combining these two concepts, you could have the two sides plot the movement of their ships and designate targets at the start of the turn. Then the computer moves them simultaniously, and calculates how much firepower each ship can bring to bear on each target, and adjusts the firepower factor for each attack based on how long the target is in the specified archs.

Just some stuff to think about,

Rob

 

[Andrew Boulton]

Version 3d of Book 2 Combat is now available at http://www.petesprint.com/~wendell/Book2_3d.zip.

I love you and I want to have your babies

This is exactly the kind of thing I've been after for years (or it will be when it's finished, anyway).

Some comments:

- I haven't managed to crash it yet (although it did get unhappy when I flew both ships into a planet...)

- Store the screen size etc, so you don't have to enter them each time.

- Don't use Book 2! I'd prefer T4/FF&S2 because of the extra detail (especially sensors, which are one of the most important/interesting bits of space combat). Failing that, I suppose MT might work.

- Don't hard-code any of the data (ship/weapon stats etc) - store it all in text files. That way, it's easy for the user to alter things.

- A clock would be nice (showing elapsed time/turns).

- Enter orders for both sides, then move/fire simultaneously.

 

[RabidVargr]

Gave it a test run and recieved no errors except a "No objects selected" and then it shut the program down. (This was after I managed to ram both ships into a stellar body though) Seemed to work fine otherwise.

Will you be adding combat features to the program too or will they be played out on the table?

I like this program a lot, shows real promise as a good ref aid. (who knows, maybe hunter would be willing to package it into the GM's Ref aids in the future??)

RV

 

[WendellM]

Andrew Boulton wrote:

I love you and I want to have your babies

Err, why thank you.

Store the screen size etc, so you don't have to enter them each time.

There will be a proper configuration screen that allows saving of settings - this is just to get started.

Don't use Book 2! I'd prefer T4/FF&S2 because of the extra detail ... Failing that, I suppose MT might work.

Well, I intend to start with Book 2 because it's the simplest. After that, who knows?

Don't hard-code any of the data (ship/weapon stats etc) - store it all in text files.

Yep: I started separating those out into files this past weekend. They're plain text, too, so they're easy to modify.

A clock would be nice (showing elapsed time/turns).

Once there are scenarios, this will be added.

Enter orders for both sides, then move/fire simultaneously

This is looking like a popular request. It shouldn't be too hard to add as an option in the future.

RabidVargr asked:

Will you be adding combat features to the program too or will they be played out on the table?

I plan to have straight Book 2 combat at first with the computer doing the rolls, but to allow results to be specified manually (for testing purposes). This capability could also be used to do the combat yourself and just assign those results should you prefer.

I like this program a lot, shows real promise as a good ref aid.

Thanks - it's more promise than substance at the moment, but it's slowly getting there. I intend to make it open source (Marc Miller permitting) so that those interested can use it as a base for whatever they like.