physics.cpp

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

physics.cpp

Post by Errol_Summerlin »

chuck_starchaser has tasked me with re-writing the physics back end to imlement 4th order runge-kutte. So, I am trying implement quaternions and I was purusing physics.cpp to see what the previous coder did, and I am fairly certain I found an error

Code: Select all

void PhysicsSystem::ApplyImpulses (float Time) {
	Vector temptorque = Time*NetTorque;
	Vector tempforce = Time*NetForce;
	int i;
	for ( i = 0; i<NumActiveTorques; ++i)
	{
		if (Time>=ActiveTorques[i].t)
		{
			temptorque += ActiveTorques[i].t*ActiveTorques[i].F;
			ActiveTorques[i].F = ActiveTorques[NumActiveTorques-1].F;
			ActiveTorques[i].t = ActiveTorques[NumActiveTorques-1].t;
			--NumActiveTorques;
			--i;//so the loop goes through the active force that was just switched places with
		}
		else
		{
			temptorque+= Time*ActiveTorques[i].F;
			ActiveTorques[i].t -= Time;
		}
	}
	for (i=0; i<NumActiveForces; ++i)
	{
		if (Time>=ActiveForces[i].t)
		{
			tempforce += ActiveForces[i].t*ActiveForces[i].F;
			ActiveForces[i].F = ActiveForces[NumActiveForces-1].F;
			ActiveForces[i].t = ActiveForces[NumActiveForces-1].t;
			NumActiveForces--;
			i--;//so the loop goes through the active force that was just switched places with
		}
		else
		{
			tempforce+= Time*ActiveForces[i].F;
			ActiveForces[i].t -= Time;
		}


	}
	//Vector temp = 0.5*GetElapsedTime()*NetTorque*(1.0/MomentOfInertia);//assume force is constant throughout the time
	temptorque = temptorque*(0.5/MomentOfInertia);
	Rotate (AngularVelocity+0.5*temptorque);
	AngularVelocity+= temptorque;
	tempforce = tempforce *(0.5/mass);//acceleration
	//now the fuck with it... add relitivity to the picture here
	if (fabs (Velocity.i)+fabs(Velocity.j)+fabs(Velocity.k)> co10)
	{
		float magvel = Velocity.Magnitude();
		float y = (1-magvel*magvel*oocc);
		tempforce = tempforce * powf (y,1.5);
	}
	*pos += (Velocity+.5*tempforce).Cast();
	Velocity +=tempforce;
}
Now, the previous coder did some very confusing things, but if you follow what is actually happening to the variables, you will see that temptorque is actually not a torque at all. It is actually a torque*time which is a change in angular momentum. But we continue to follow and see that goes through the active torques on the object and adds on more changes in angular momentum. He then gets down to

Code: Select all

temptorque = temptorque*(0.5/MomentOfInertia);
Now temptorque has become an angular velocity. But the next line is where the actual error is.

Code: Select all

Rotate (AngularVelocity+0.5*temptorque);
If you look at the code for Rotate

Code: Select all

void PhysicsSystem::Rotate (const Vector &axis) {
	float theta = axis.Magnitude();
	if(theta==0.0f)
		return;
	float ootheta = 1/theta;
	float s = cos (theta * .5);
	Quaternion rot = Quaternion(s, axis * (sin (theta*.5)*ootheta));
	Quaternion rotprime = rot.Conjugate();
	Quaternion pquat = rot * Quaternion(0, *p) * rotprime;
	Quaternion qquat = rot * Quaternion(0, *q) * rotprime;
	Quaternion rquat = rot * Quaternion(0, *r) * rotprime;
	*p = pquat.v;
	*q = qquat.v;
	*r = rquat.v;
}
you will see that Rotate does not multiply by dt, and, in fact, doesn't even know the time. So, essentially, the Rotate() call is telling the ship to rotate through an angle = to angular_velocity+change_in_angular_velocity. This is simply wrong. The rotation should be angular_velocity*time. Since temptorque now contain change in angular velocity over the time step..you could call rotate ((angular_velocity+.5*temptorque)*Time). That would be implementing a midpoint method. But regardless, this Rotate is causing ships to rotate WAAAAYY too fast. In fact, it is exactly Hz times too fast..where Hz is the rate at which update is called.

Anyway, that is what I am seeing, but quaternions confuse me and the code, as written, is very difficult to read, so I may have missed something. But I wanted to let you guys know in case someone who is in charge of fixing bugs wants to fix this and see how it changes things.

Now I still have to figure out how to store the object's orientation and then how to change it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

Hehehe, great catch!
This is good! It means that probably the moments of inertia of all ships are 14 times greater than were intended.
Which means that with the new physics they will all turn 14 times slower.
Which means we won't have to fix too many of them to make them slower. :D

That's really awful code... Re-using a variable, first representing a torque, then a momentum-delta, then an angular velocity, and then a bug ... same name throughout ... should bring back the guillotine ...

I think the reason we don't notice this bug is partly the manual entry method for moment of inertia and experimental way of setting its value; and partly that the game currently relies more on limiting angular velocity than on rotational acceleration; --the "governor" settings in units.csv.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: physics.cpp

Post by safemode »

If you're going to make ship turning 14 times slower you might as well add a variable in that equation to multiple the force via config option variable because users will likely flip out if it takes them 14 times longer to turn in ships.

In other words, correcting the physics is good, but we're definitely going to need clear adjustment variables to match the physics to a gameplay state that people will actually enjoy.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

Yes; I was joking.

The solution to this will involve going through all ships in units.csv, I suspect; so I would say we should first implement the earlier idea of allowing multiple csv files, and split up units.csv into many files, --weapons, planets, stations...
and then ships are many; we probably could have individual csv files for 3 or 4 size categories per race or faction.
Then it will be easier to work on moments of inertia's.

I'll write a ticket for this tonight.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: physics.cpp

Post by klauss »

I don't believe the physics is that screwed up.

An error like that would most likely result in far chaotic movement. I bet there's a counter-bug counteracting this bug's effect ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: physics.cpp

Post by Errol_Summerlin »

@klauss well, besides the weird values of the moment of inertia, it will actually make the rotations MORE responsive because there is only one step between torque and rotation. So, I don't think there is a counter bug for it except for the large values of MoIs

@chuck Since I am re-writing all this stuff anyway, the error will get fixed eventually, but you might as well start fixing the moments now cause my code won't have any errors :P The coding is part of the reason this is taking so long. No documentation at all, non-descriptive variable names, the ones that are descriptive change their meaning during the function. I don't mean to disparage the person who originally wrote it, but it is clear that it was written in haste.

Once I get this stuff done I can start working on a function that can calculate the MoI tensor based on the shape of the ship if you want. Then torques can be calculated based on the locations and strength of maneuvering thrusters and this guess work can be done away with.

I am making steady progress now on the physics code btw. I think I have learned what I need to learn (although I will definitely need to figure out a way to test it to make sure I understood quaternions) and I just have to find time to type up all the functions and document the code. Then I will send you what I have and start testing while you figure out what still needs to be done.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

That would be wonderful... an off-line tool that can calculate MOI's and automatically fix units.csv... :D
Maybe I'm dreaming in technicolor.
Well, what we should have in the csv files is TOI's, really; tensors of inertia. Am I using the right term?
Or a quaternion of inertia, if there's such a thing.
Ships long and narrow should have no problem with rolls.
Which in space sci-fi is important, as large ships can rotate when attacked, to give shields time to recharge.
In fact capital ships did this when attacked, in WCU.

Klauss, the most likely counter-bug for this is a data bug.
Wouldn't be chaotic; just too fast, until you hack the numbers in the csv, which I had to do for all our
ships in PU, and numbers made no sense, not that I expected them to. Ended up doing what everybody
else before me did; just tweak until it works; which you know I hate.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: physics.cpp

Post by klauss »

Ehm... it *would* be chaotic, because of the frequent rescheduling.

But now I remember seeing that chaos... when units get rescheduled they sometimes start spinning like crazy - I could never track that bug down.

Perhaps that's it?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

It probably is.
Does the AI control spin rate directly? or thrust? If it controls thrust, and takes feedback from ship position, velocity, etc., to adjust it, then when the scheduling changes gear, the ship would rotate faster until the AI corrects for it.
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: physics.cpp

Post by Errol_Summerlin »

chuck_starchaser wrote:That would be wonderful... an off-line tool that can calculate MOI's and automatically fix units.csv... :D
Maybe I'm dreaming in technicolor.
Well, what we should have in the csv files is TOI's, really; tensors of inertia. Am I using the right term?
Or a quaternion of inertia, if there's such a thing.
Ships long and narrow should have no problem with rolls.
Which in space sci-fi is important, as large ships can rotate when attacked, to give shields time to recharge.
In fact capital ships did this when attacked, in WCU.
In what I am writing, I am currently presuming a scalar moi. I can always change it to a moment of inertia tensor later. There is no quaternion of inertia that I have encountered, but there are some tutorials on how to use the tensor moment of inertia with quaternion rotation representations. In principle though, calculating the moment of inertia tensor is not too hard. However, we will need to make some assumptions about the spatial density profile (easiest is to presume density is constant throughout the ship).

If the ship is regular in shape(rectangular prism,sphere, or cylinder), or can be approximated as such, the calculation is simple. I could write up a quick and dirty Monte-Carlo style computer program that could computer these with this simple algorithm.

Place the object within a bounding box that is larger than it in all dimesions.
Define the center of mass (either by fiat, or by calculation assuming constant density. For simple shapes, the CoM is trivial to calculate)
Randomly select a point in the simulation box(uniform variate over x,y, and z bounds of the simulation box)
If the point is inside the boundaries of the object, calculate its contribution to all of the various moments and add it to a cummulative total of each moment of inertia tensor matrix element assuming the mass element has unit mass.
If the point is outside the box, don't do anything.

After N data points are found inside the object, stop. Multiply all components of the MoI tensor by M/N where M is the Mass of the object.

For complicated objects, the boundaries of the object will be a challenge to define, but it is more flexible than the analytical method. If N =10000, you should get the right MoI tensor to within 1% accuracy in each element.

However, for simple objects, it is probably easier to just directly calculate the MoI integrals.
For any sort of box like structure(rectangular prism, cube, etc.), sphere, or cylinder of constant density, I could actually give you the tensor as a function of its height, width, length, or radius and mass by direct computation of the integral in Mathematica.

P.S. I hate shields...they are another "Big lie" that is really unnecessary. Armor works just as well for a "shield" but is actually, you know, real...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

Totally agreed about shields; I hate them with a passion.
And "tractor beams".
Needless to say I hate "artificial gravity" and "inertial compensation".
Just crap we have to live with because ... Hmm... I can't remember why, now...

Anyways, the problem with your numerical approach is implementational: Given a Wavefront .obj file for a mesh, say, and a point you want to test, how do you determine if it's inside or outside the mesh? This NOT trivial. Specially when you consider that OUR meshes are are the furthest thing from closed manifolds. You find more than two polygons sharing an edge, sometimes, floating edges without a polygon, triangles attached to a mesh by a single vertex, a V-shaped extrusion half-buried in the surface of another mesh, polygons sharing all 3 or 4 sides, but with opposite normals, and horrors my mind doesn't even want to relive.
I think a less accurate but far easier approach would be to run through the list of vertices and consider them point-masses. The .obj format has all vertices in one place, so they are easy to parse.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: physics.cpp

Post by Deus Siddis »

chuck_starchaser wrote:Totally agreed about shields; I hate them with a passion.
And "tractor beams".
Needless to say I hate "artificial gravity" and "inertial compensation".
Just crap we have to live with because ... Hmm... I can't remember why, now...
Because of the non-VS mods, methinks.

VS could instead have plasma-burst reactive armor, healing nano-armor, hull repair bots or whatever you could come up with that replenishes or grows back but isn't realistically impossible.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

Deus Siddis wrote:
chuck_starchaser wrote:Totally agreed about shields; I hate them with a passion.
And "tractor beams".
Needless to say I hate "artificial gravity" and "inertial compensation".
Just crap we have to live with because ... Hmm... I can't remember why, now...
Because of the non-VS mods, methinks.
That was it!
VS could instead have plasma-burst reactive armor, healing nano-armor, hull repair bots or whatever you could come up with that replenishes or grows back but isn't realistically impossible.
As long as the nanobots themselves are not indestructible...
So, @all involved, how about we get rid of shields in VegaStrike? Less handwaivium to have to deal with, and faster graphics to boot, and less requirements for artists... And less sucky graphics. I mean, for PU I still need shields, but we could get rid of this curse from vs land.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: physics.cpp

Post by charlieg »

chuck_starchaser wrote:@all involved, how about we get rid of shields in VegaStrike? Less handwaivium to have to deal with.
Don't make too many changes before releasing. Firstly, this change will have fallout - the HUD, for instance, needs changing, weapons balancing, etc.

TBH I am all for originality in games and so going with an alternative to the typical sci fi shields is not a bad idea - but think it through.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: physics.cpp

Post by safemode »

if we want them gone i'll get rid of them in my branch today, you guys can check out the effect if you like it and i'll merge it to trunk tonight
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: physics.cpp

Post by safemode »

charlieg: none of that stuff needs to be done. The effect of shields isn't being removed. ..only the visual appearance of them. A different mechanism for "shields" is being developed and a new visual interpretation will be used. Weapon balancing and such need not change. Neither does the hud for now.

ie: you will still have this thing that absorbs damage before damaging your hull. So weapon balancing remains unchanged and the HUD still represents the remaining capacity of whatever we decide shields is in the VS universe.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

I meant complete removal, extirpation, erradication...
But charlieg is right.
And your idea of getting rid of its visual effects is good, IMO.
If Klauss and I can come up with something really cool, we can add it back later.
So I cast my Yey.
And if you know how to get rid of the screen reddening when you're shot at, that would be good too.
Maybe we can put some cockpit shaking, instead of changing the color.
Later we can use hardware fog to simulate smoke in the cockpit.
But the screen going red makes no sense.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: physics.cpp

Post by klauss »

chuck_starchaser wrote: And if you know how to get rid of the screen reddening when you're shot at, that would be good too.
Please don't.

Those that play without sound (like I whenever I'm testing something other than sound), need that red stuff to know when you're being shot at.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: physics.cpp

Post by safemode »

yea i know where that's done..saw it when i was playing with mesh_fx ...

I dont see the reason for removing the functionality of shields just to replace it with something else with similar functionality.

As far as the gameplay is concerned. .. you have two layers of protection on your spaceship. 1 outter level that regenerates when damaged. This can be completely obliterated or turned off and you dont die. The second level is persistent with damage and must be repaired manually. Losing this level of protection means death.

If you create some type of level 2 that regenerates automatically (via repair robots or nanomaterial ) then you've just recreated shields for all tense and purposes. No point in removing it.

If you intend on not having any auto-regenerating protection , and no shields, just hull armor that gets damaged and stays damaged until you go in for repairs...then that's a game changer, and can't be done before release at all. No question about that. It would require massive rebalancing.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

Yeah, I meant the game-changing change; not for graphical reasons; but for the sake of getting rid of pseudoscientific handwaivium that could never be explained; that never made any sense; and that's been used and abused by every crappy sci-fi out there.

But anyhow, I'd be happy to just see the crappy gfx gone, for now.
klauss wrote:
chuck_starchaser wrote: And if you know how to get rid of the screen reddening when you're shot at, that would be good too.
Please don't.

Those that play without sound (like I whenever I'm testing something other than sound), need that red stuff to know when you're being shot at.
Hey, I play without sound too; but maybe we could have cockpit shaking, instead, or a single-frame brightening of the screen (luma only; NO chroma change). Do you get my point about it? In Doom and in DukeNukem, you're walking around, and presumably your eyes get blood-shot when shot at; but this is space, and this is a space ship, and the redness makes no sense whatsoever; AND it interferes with recognizing colors in the sensor screen.

EDIT:
If you like my idea of ultra-brief (single frame) brightening, I'd suggest we brighten ONLY the cockpit interior (neither the exterior nor the HUD), and that it be multiplicative brightening, so that it looks like the light level inside the cockpit went up (sparks?).
Last edited by chuck_starchaser on Fri Mar 19, 2010 5:36 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: physics.cpp

Post by klauss »

I believe the color of the effect can be changed in a jiffy. Probably by vegafig.

There is cockpit shake, BTW, but is only applicable if there's a 3D cockpit.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

I was editing the post, as usual :D; check it out.

BTW, we need 3D cockpits :)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: physics.cpp

Post by klauss »

If you only increase brighness (or any other effect) only on the cockpit, right now, you do nothing. Because there's no cockpit. Only HUD.

BTW: we need 3D cockpits :) x2
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: physics.cpp

Post by safemode »

eventually, with shields gone we should go this route.

have a heat sink resevoir fed by nanowires embeded throughout the hull to absorb heat along with piezo conductors to absorb shock and convert that energy to heat as well and have it all being fed to this transformer that converts the heat to electricity or radiates it to space

Now, this takes the place of your shield but is described differently. Instead of being depleted as weapon fire hits your ship, it fills up. When it maxes out, no more energy is siphoned off the hull and the hull takes full damage. Regardless though, the hull will take some amount of damage and it will be dependent on if the weapon is kinetic or energy related.

This utilizes no handwaivium, and we can re-use the concept of the shield HUD, just slightly modify it. Plus it only slightly modifies gameplay in that we still havhe this regenerative damage absorption, but it becomes part of the hull. You can't "divert energy to shields" and the like nonsense. Hull damage reduces this feature in that area as well, as it is dependent on the hull to function.

edit: yes i know piezo crystals convert vibration directly to electricity, not heat, you get where i'm going.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: physics.cpp

Post by chuck_starchaser »

The idea of transforming heat into electricity recurs so often it's become one of my pet peeves. Basic thermodynamics: Heat has the highest entropy of pretty much any energy form. The only way to convert it to another energy form is by having concentrated heat in an ocean of coolness (highly conductive coolness, that is; NOT "space"). Like the heat in a car engine's cylinder is heat in a highly concentrated form: Spatially in the cylinder, and at the highest compression point in the stroke of the piston, AND highly concentrated in time. BOOM, and it produces work over the next millisecond or so. But the efficiency is still pretty low, and it depends on outside coolness, which is why cars run more efficiently at night than during the day, and in winter than in summer.
In space, where there's nowhere to put heat, you probably need to spend energy to get rid of it, such as using refrigerator-like compression/decompression in reverse, to try and concentrate heat onto radiators, for the radiators to run more efficiently.
But the other ideas are a bit more arguable, such as piezoelectrics for kinetic rounds; but there you have the opposite problem: a kinetic round delivers too much energy too concentrated in space and time for any material imaginable to convert that into useful work. The goal would be to limit damage (probably no way to prevent it entirely). If somebody starts shooting at you, the last thing in your mind would be how to produce electricity from the bullets to recharge your cell-phone; you just run for your life. I don't think it would be much different 3000 years from now.
Finally, the same goes for energy weapons: If I shoot a laser at you, would you put on a tin-foil hat or photovoltaic hat? I think it's a no-brainer you'd go for the protection of tin foil.
As for nanobots effecting armor repairs, I don't know... The hype of nanotechnology has been around for decades now and there's certainly been a lot progress in real applications, but none of the hyped stuff has panned out, like atom manipulators that can assemble molecules. In the particular case of armor, where you want to use ultra-strong materials, even assuming you could give nanobots the necessary skills, how would they have enough muscle-strength to work with materials persumably many times stronger than themselves?

But every time I speak my mind on things like these, there's two typical things people say: A) that I'm like those who said that heavier than air vehicles could never fly, or B) that with so much realism there's no way to build a game.

To (A) I say: Those who denied the possibility of heavier than air flight were irrational skeptics, who ignored evidence supporting the theory, such as the fact that birds are heavier than air, yet fly. They were being irrational. I just see no evidence that the future will somehow magically produce all scientific and technological wonders anyone dreams up; and those who believe so they do because they enjoy believing that, not because of any supporting evidence.

To (B) I say: There's no direct relationship between the amount of fantasy you have in a game and the amount of fun in it. I can enjoy games of fantasy, magical spells, healing potions and whatnot; and I can enjoy games with no fantasy whatsoever, like (good) flight sims.
As I once said to Hellcat, paraphrasing myself, "The day we go to space in a big way, IF we do it, --like start mining asteroids and all that--, there WILL be (real) space pirates, and pirate wars between nations, and there will be (real) spacers and forsakens and whatnot. But there probably won't be "shields" or "tractor beams"; and all other things being equal, a game is likely to be more enjoyable if you can feel it represents real possibilities than if it doesn't. We just have to figure how space battle WILL be, implement it in vegastrike, and I can guarantee you we'll have a fun game."
Believability helps immersiveness a lot. Hellcat's argument was that space battle will probably involve long range weaponry, where you never even see the enemy. My argument was, and is, so is much of aircraft fighting today, and the better combat flight sims reflect the fact, and they are fun anyways. And you can only carry so many AAMRAM's, anyways; you'd better also pack some AIM's; and you can blow up a ground target with a long range cruise missile; but that's the expensive way... Drop-bombs are the way to go if the risk is manageable.
Post Reply