Multiplayer Component Based Space Combat

Show off your games, demos and other (playable) creations.
User avatar
Elvashi
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

Re: Multiplayer Component Based Space Combat

Post by Elvashi »

Lap wrote:Weapon Checks- Here's the tricky part
0. If it's time to find a new target...
1. Loop through all shapes throwing out shapes that are too far away.
Create a bounding <shape> for each ship, and test whether each bounding <shape> can see/is in range of the other's bounding <shape>, if they can't, then theres no way they can see each other at all, so there's no reason to check each sub-piece for visibility*.

* So long as the bounding <shapes> are properly sized, of cause.
---a. How do we determine the distance between two shapes? There is no shape:getPos() or equivalent that I know of.
I'm not real familiar with love.physics, but it looks like positions are associated with bodies, and bodies have positions. Personally I'd wager you are better off storing the data you need on the object itself in this instance, but I defer to those with more familiarity with the matter.
---b. If we get the center of a piece it's kind of inaccurate because the center might not be in range, but an edge might.
While I can understand your interest in being accurate, it might be overkill in this instance; plenty of games have done fine with nothing but bounding-boxes.
if you must, pixel-checking (of the part's imagedata) or clipping against its shape would probably work (remember to use Bounding shapes to determine if such a detailed check is required, though)
This last part could derail the whole project or at least drastically change all the guns to manual instead of auto-targetting, which makes this an entirely different game.
A page from the big book of FPS design might be helpful here.
In an average FPS weapons are generally of one of two implementations: Projectile, and hitscan.
  • Projectile weapons actually generate in-world objects, they actually move through the world, have whatever degree of physics is required, and trigger collision events when they hit something. This can get a bit hairy as the projectiles approach higher speeds, which is why hitscan exists.
  • Hitscan weapons just make a line-check when they are fired. they either hit, or they don't. and you know right away.
    Hitscan is obviously very simple; You do the check, apply the results. done.
Now if I have to do that for every single physics.update that seems awful, especially considering box2d has to have the x,y of each shape stored somewhere.
Remember, these aren't free-floating objects, they are in neat little groups called ships :)
As I suggested above, Bounding <shapes> greatly cut down the number of checks you need to do here.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene
User avatar
Lap
Party member
Posts: 256
Joined: Fri Apr 30, 2010 3:46 pm

Re: Multiplayer Component Based Space Combat

Post by Lap »

* So long as the bounding <shapes> are properly sized, of cause.
---a. How do we determine the distance between two shapes? There is no shape:getPos() or equivalent that I know of.
I'm not real familiar with love.physics, but it looks like positions are associated with bodies, and bodies have positions. Personally I'd wager you are better off storing the data you need on the object itself in this instance, but I defer to those with more familiarity with the matter.

They do have positions, but as I explained, finding the relative position from the body is terrible.
This last part could derail the whole project or at least drastically change all the guns to manual instead of auto-targetting, which makes this an entirely different game.
A page from the big book of FPS design might be helpful here.
In an average FPS weapons are generally of one of two implementations: Projectile, and hitscan.
  • Projectile weapons actually generate in-world objects, they actually move through the world, have whatever degree of physics is required, and trigger collision events when they hit something. This can get a bit hairy as the projectiles approach higher speeds, which is why hitscan exists.
  • Hitscan weapons just make a line-check when they are fired. they either hit, or they don't. and you know right away.
    Hitscan is obviously very simple; You do the check, apply the results. done.
I'm not seeing how this is relevant.
User avatar
Elvashi
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

Re: Multiplayer Component Based Space Combat

Post by Elvashi »

Lap wrote:I'm not seeing how this is relevant.
I didn't really make myself very clear. The point is either is that its either a slow projectile, in which case theres no way to be certain what it hits, so a educated guess is the best you can hope for (ie, don't try too hard. Just make the simplest, most obvious check, and move on.), or its fast moving/hitscan, in which case you know exactly what its going to hit, and when.

(in both cases, bounding <shapes> can help you decide quickly if a shot is likely to be blocked. if one shot hits an intervening ship's Bounding <shape>, and another doesn't, then there's your shot. You only have to do a more detailed check if there's no clear "bounding <shape>" shots)

Obviously your pathological case is bad, but pathological cases are (hopefully) not your common case. and these should make your common case quite reasonable.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 2 guests