Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  "fog of war" algorithm  (Read 3615 times)
0 Members and 1 Guest are viewing this topic.
Offline john9231

Senior Newbie





« Posted 2008-02-22 19:36:50 »

I have a simulation of shipping traffic around the world, which is displayed on a 3d globe via java opengl (my question has nothing to do with java opengl though).  I would like to be able to evaluate which units can be "seen" by another team of units.  The end effect is pretty much a fog of war.  The unit's positions are stored in spherical coordinates and I will probably just assess distances between units to determine if one can see the other.  If a unit not owned by the user is seen by a unit "owned" by the user, this non-user unit  will be rendered on the globe (along with all the user's units).  The problem is I would like there to be many units and for the evaluations to be carried out quite often.  I have asked this question on another site and the only advice I got was to not model that many objects, which isn't helpful.  What I really want to know is what is the best way to make these evaluations given that I have a very large number of units that can be detected and units that are capable of detecting.

I am currently planning to take a list of all non-user units and iteratively consider whether or not each one can be seen.  This involves taking one of the non-user units and then iterating through the user's units to evaluate if one of them sees it.  If none of the user units see it, the non-user unit is not flagged for rendering and I move on to evaluating the next non-user unit.  If a user unit did see that non-user unit, I stop the evaluation, flag the unit, and move on to evaluating the next non-user unit.

I would appreciate any advice on how to make this better.  Perhaps some heuristic tricks could be of use here.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #1 - Posted 2008-02-22 20:03:47 »

You could use something like a Binary Space Partition(BSP).  You basically divide your entire game area into grids(cubes for 3D) and only check units that are in a grid that would be close enough to the user units.

Offline john9231

Senior Newbie





« Reply #2 - Posted 2008-02-23 00:40:19 »

I had thought about using a technique like that to reduce making comparisons of units on opposite sides of the world, but I was concerned about how far the "line of sight" could be for some of the units.  The users of the simulation will decide the parameters of the units (such as line of sight radius) and if possible I wouldn't want there to be a maximum light of sight range just for flexibility's sake.  The performance benefits would probably be worth it though so maybe I will implement it in the end.  Thanks for the suggestion.

Are there other improvements that anyone can think of?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2008-02-23 00:59:58 »

Just to a get the idea... how many units are we talking about?

Hundreds?
Thousands?
Millions?


Anyway, a 3D space partitioning system will do this for you easily.
Octtrees as easiest, but slightly less efficient than BSP-trees.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline john9231

Senior Newbie





« Reply #4 - Posted 2008-02-23 02:11:12 »

The number of units (n) is really up to the end user.  I really can't conceive of n ever being less than 100 or more than a million.  It depends on how complex the simulation needs to be.  I would guess the "average" user would opt for around 1,000 to 10,000 units.  An important point is that I am planning to have some units grouped together moving as one "super-unit" which would reduce the burden of the fog of war calculation.  If I had to guess, I would say that in the limit as n goes to infinity I could probably expect a 10 fold drop in the number of units I have to run calculations on.  It is possible that I may not have performance issues, but I would like to have a fairly efficient algorithm to start with.

I don't need cube partitions since all the units are positioned on the surface of a sphere.  Would it be best to divide up the units into lists representing portions of the earth's surface area?  It is easy to divide up the sphere surface into rectangles (like this: http://upload.wikimedia.org/wikipedia/commons/3/38/Sphere-wireframe.png) , but it might be best to just lump all of the polar regions into two lists because the rectangles get small at the poles and there will probably be little activity there.  For a unit in a given rectangle, I would then see if any units in the adjacent rectangles can see it.  I'm new to this, so perhaps you can think of a more efficient way to divide up the units.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2008-02-23 08:47:04 »

Well, you can indeed chop your surface into non-uniform areas (Object per area) only based on their spherical angles. You'd then store all neighbour areas in each area in an array (for example) along with the distance between the center-points. Using a simple floodfill-algorithm you'd easily rougly find all areas within a distance of X. Each area would ofcourse also have a list of units.

If you make your areas small enough, you can just have the user see all units in a certain set of areas. Otherwise you'll have to start figuring out distances between units that probably see eachother. Not that hard.


But well, an octtree will solve this all for you, although it's probably a bit harder to implement, yet it is probably more effictient... even though it's overhead will be quite a bit larger due to the cube-hierarchy.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline abies

Senior Devvie





« Reply #6 - Posted 2008-02-23 16:54:35 »

I don't know details about your application, but think about few points:

1) Do the visibility evaluation once per some time -  probably once per second is just ok. You can distribute the work per certain area over time - so instead of doing one global check, you can spread multiple subchecks during this time

2) You will probably like to also give some different kind of indication about fog of war - some kind of shading. In this case, it is not about enemy units, but terrain. Maybe think about solving this part first and you will get unit visibility for free (if it is on revealed terrain, it is visible)

3) It seems to be some kind of multiplayer game? In such case, think very seriously about doing at least basic checks on server side (area-wide at least). You can leave the edge cases for client, but by doing at least preliminary checks on server side, you will be able to save some traffic (by not sending invisible movement) and make it bit more hack-proof (compromised client can display only what you send to it)


Artur Biesiadowski
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-22 08:34:11

rwatson462 (55 views)
2014-12-14 14:26:44

Mr.CodeIt (45 views)
2014-12-14 00:50:38

BurntPizza (88 views)
2014-12-09 03:41:13

BurntPizza (111 views)
2014-12-07 09:46:31

JscottyBieshaar (82 views)
2014-12-04 17:39:02

SHC (92 views)
2014-12-02 21:27:13

CopyableCougar4 (99 views)
2014-11-29 02:32:03

toopeicgaming1999 (159 views)
2014-11-25 20:22:04

toopeicgaming1999 (157 views)
2014-11-25 20:20:36
Resources for WIP games
by kpars
2014-12-17 15:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 03:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 03:36:02

List of Learning Resources
by Longor1996
2014-08-15 15:40:00

List of Learning Resources
by SilverTiger
2014-08-05 00:33:27

Resources for WIP games
by CogWheelz
2014-07-31 21:20:17

Resources for WIP games
by CogWheelz
2014-07-31 21:19:50

List of Learning Resources
by SilverTiger
2014-07-30 21:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!