How should games battle in space?

Jeff Binder
Unregistered
 
Post: #16
Well, the gravitational pull could be set up to only have an affect when you're reall close to the planet, so you could still do a slingshot type thing, and landing would be easier, but it wouldn't really interfere with interplanetary stuff. You could use it for all kinds of cool things, like if you're fighting by a planet, you can shoot off a rocket so that is goes into orbit and hits the enemy from the other side.

Whether this would actually be fun is something we'll have to wait and see.
Quote this message in a reply
Member
Posts: 39
Joined: 2002.04
Post: #17
Quote:Originally posted by aarku


At the present moment I don't have any gravity mines or things like that due to one problem: computation speed. Because when you get a dozen ships in play with a bunch of weapons, the engine has to figure how gravity will effect everything. Otherwise, you have to compute the distance between the gravity mine and everything, which is costly as well... at least so I would assume.

-Jon

Obviously I don't know what kind of system your intend to run this on but gravity should not need to all that expensive to calculate.
Lets assume the following example (worst case scenario in regards to CPU
load):
- 50 space crafts
- 500 porjectiles (missiles, mines ...)
- a planet and couple of moons (the permanent gravity sources)
- 30 fps (minimum)

This would require use to keep track of (500 + 50) * 30 = 16500 movements per second. If each object movement is defined by one vector, the updateing of the vector during each frame will be:

new_vector = current_vector + course_change_vector + gravity_source_vector_1 +
gravity_source_vector_2 + .... + gravity_source_vector_N
+ Vectors due to tractor beams, collisions and magnetic missiles

N = number of gravity sources

vector addition is a cheap operation (and could pressumably be done with int's i.e. no floating point math required):
v_sum = v1 + v2 => v_sum.x = v1.x + v2.x,
v_sum.y = v1.y + v2.y

vector rotation (to figure out the course_change_vector) is more costly:
course_change_vector = normalized_vector * speed_scalar * rotation_matrix
normalized_vector (i.e. length = 1): v.x = 0, v.y = 1 (pointing north)
speed_scalar: a numerical value that represents the amount of acceleration
rotation_matrix: supply the direction the craft is facing in this matrix


There are several optimisations that can be done:
- gravity pull is = k * 1 / (distance * distance), (k is some constant), this means that gravity
pull falls of rather quickly with distance - so the first optimisation is that gravity pull
can be ignored at a certain distance (depends on the K value - which is basicly the mass of the
planet).
The initial distance check can check distance along the x and y axis instead of calculating the
actual distance ( sqrt(x_diff^2 + y_diff^2) ), this only needs to be done if the first check
succeeds.
- N should be a low number if no gravity mines are used
- Gravity mines are pressumably short range and temporary (thats at least what I assumed when I
mentioned them), so N should remain small.
- Instead of letting each object check if it's affeceted by gravity, it might be more effective
to instead let each gravity source check which objects it might affect this can be done in:
N log M operations if the objects are sorted into a binary tree (on x and y position alternatingly)
M = the number of objects in the world
N = number of gravity sources
This ofcourse requires M log M operations to create the tree in each frame, if everything is resorted i.e. no unmoving objects or if the tree is recreated which in this case might be faster.

- There are also ways to aproximate the effect of distant gravity sources using octree (or in the 2D case quadtrees) where the effect of gravity on each object can be computed in constant time rather than in propotion to the number of N. This on the other hand requiers that new tree is created in
each frame (of movement) and is most likely not efficent when N is a low value.

If N is = 1, on average, then this would only double the number of required vector additions.
Quote this message in a reply
Founder
Posts: 1,139
Joined: 2002.04
Post: #18
This may sound stupid, but when I was thinking of a 2d game and the screen showing a planet and ship, something came to mind. Would you represent the planet with a sprite the size of the ship, like EV or Spaceward Ho??
Or would you change the scale?

Carlos A. Camacho,
Founder
iDevGames
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #19
Quote:Originally posted by Camacho
This may sound stupid, but when I was thinking of a 2d game and the screen showing a planet and ship, something came to mind. Would you represent the planet with a sprite the size of the ship, like EV or Spaceward Ho??
Or would you change the scale?

Right now you can load up any picture you want as "scenery". So the size is up to the person making the scenario, but I've been making everything fairly small in relation to the ships. The reason is basically speed. (memory to a lesser extent) Right now the game uses software rendering meaning that size matters a lot... it gets pretty weird when the framerate jumps from a smooth 120 fps to 15 when you get near a big planet. I really want large planets... but I don't know how to feasibly do it.

-Jon
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #20
Ok, so lets say a planet had gravity in the game. Your ship would be pulled towards it... but it is 2d. Do you collide with the planet and bounce off (that would be really really strange), or...? Things would get screwed up, because as you reach the center of the planet, the gravity would increase quickly, and eventually you would be trapped. I'm not sure how logistics would work with planet gravity... but gravity mines on the other hand... it'd be easy enough to say what happens when you hit a gravity mine.... boom.

-Jon
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #21
Right now the game has inertialess turning like most space games I've played have. Would it be better to have turning with inertia... so when you thrust counter-clockwise you continue spinning until you thrust clockwise? Obviously this is more realistic, and it's easy enough to implement for player and computer... but any thoughts on playability?

-Jon
Quote this message in a reply
Jeff Binder
Unregistered
 
Post: #22
I could see that being somewhat hard to control... I guess it's assumed that you're navigation system takes care of this for you.
Quote this message in a reply
Member
Posts: 92
Joined: 2002.04
Post: #23
what you could have is the following.

ship type 1 has turning speed of 1
ship type 2 has turning speed of 3

while flying ship 1 when I turn to the left the thruster will only fire once. I will then spin left until I press right and it will fire once, stopping the spin. Flying in ship 2 when I turn to the left and hold the the left arrow/joystick/etc it fires thrusters once.. waits for a moment.. fires again.. waits.. and fires again. When I want to spin the other way or slow my spin I turn back the other way.

How does that sound?
Quote this message in a reply
Member
Posts: 39
Joined: 2002.04
Post: #24
Quote:Originally posted by aarku
Ok, so lets say a planet had gravity in the game. Your ship would be pulled towards it... but it is 2d. Do you collide with the planet and bounce off (that would be really really strange), or...?
There are two cases ship-ship and planet-ship collisions, in the planet-ship collision the mass of the planet is so large that the push the hitting ship gives it is unnoticable, the ship on the other hand will litel more than scrap metal due to the speed of impact.

Quote:
Things would get screwed up, because as you reach the center of the planet, the gravity would increase quickly, and eventually you would be trapped.
Planets, stars and gasgiants can be considered to be solid (due to the amount of friction generated when flying into them - impact energy is = ship mass * ship speed ^2) i.e. a ship should not be able to get inside a planet - add colision detection to determine if ship is coming inside the radius of the planet.
Physics side note: assuming that your inside a planet gravity can be determined by only considering the mass inside the current radius (= planet radius - deapth from surface), so your actualy weightless at the center, if you have a frictionless tunnel trough the center of the planet you would actualy fall back and forth between the end points for ever (ignoring minor details like the planets movement, tunnel entry speed and planet rotation).


ps: a proper gravity force formula should look something like this:

F = G * (m1 * m2)/d^2

x^n = x * x * ... * x (x multiplied n times)

F = force (pull - N, newtons)
G = gravity constant ( 6.672 * 10^-11 N m^2/kg^2)
m1, m2 = mass of object 1 and 2 (kg)
d = distance between object centers (m - meter)

This formula holds true:
F = ma -> F / m = a
Therefore if it is assumed that if m1 is a ship and m2 is a planet and A is the acceleration of the ship, the following holds:
A = G * (m1 * m2)/d^2 * m1 = G * m2/d^2

As a ship mass is basicly = 0, compared to a planet, so it's ok to assume that only the ship is moving. This means that the speed incearse for the ship between each period dt (e.g. a rendering frame) can be considered to be SpeedIncrease = K * planetMass/distance^2 (K, planetMass and distance can be any unit of measurement you want depending the actual
game scale and how noticable you want the gravity effects to be).
Quote this message in a reply
Member
Posts: 39
Joined: 2002.04
Post: #25
Quote:Originally posted by hokan

There are two cases ship-ship and planet-ship collisions, in the planet-ship collision the mass of the planet is so large that the push the hitting ship gives it is unnoticable, the ship on the other hand will litel more than scrap metal due to the speed of impact.

The reason the ship doesn't bounce, is because it isn't structuraly solid enough to remain in one piece at impact, instead some of the impact energy will be expanded to rip the ship appart and some will bounce parts of the ship back (some of the impact energy is absorbed by the planet) - this is the reason that crash debris gets scattered, some small pieces may even reach escape velocity and i.e .end up in space again.

Some mars rocks have ended up on earth due to meteor impacts on mars, flining some martian rock into space, that eventualy end up dropping onto the earth (due to earth gravitational pull).

Escape velocity = the speed that allows a object to get into space from a planet surface under the following conditions:
- the object doesn't accelerat, it is simply launched at a certain speed
- the planet will never be able (independent of time period the observer waits) to pull the object back to the planet surface (with gravity)
Escape velocity depends on gravity pull of the planet, Earths escape velocity is = 11 km/s (39600 km per hour).
Quote this message in a reply
Member
Posts: 164
Joined: 2002.04
Post: #26
Make the ships have engines which automatically neutralise gravity (if you have it turned on) So for example if you were trying to dock on a space station or something then your engines would automatically compensate for the gravity which would just mean that you go a little slower in other directions (because its putting some energy into compensation) but it would be easier to control direction.

Although I guess that wouldnt be too much of an issue since you'd be in orbit Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Space Based Games... Why are they not as popular? Your thoughts... carmine 5 5,984 Nov 7, 2008 11:10 PM
Last Post: TythosEternal
  legal issues with borrowing battle systems and such mac_girl 7 5,928 Jun 3, 2007 08:58 AM
Last Post: Rushyo
  opinion:game battle engines, what's the best kind? link_jr97 7 6,241 Sep 18, 2004 03:38 PM
Last Post: link_jr97