Graph Implementation

2007-04-30

Permalink 03:21:05 am, Categories: Pathfinding  

Graph Implementation

Mostly what I have about our graph implementation is that we should use a vector-like structure to store nodes and edges.

Why?

Most of the time graphs will be loaded during the begining of the applycation and they will rarely change during the game. This means, we will only add nodes and edges once and almost never erase them. This unless a bridge explodes, an avalanche blocks a way or a door opens(and even in this case we can mark those edges as blocked or unblocked without erasing them).

This means, most of the time, almost every second we will be performing searches over the graph.

Vectors are known for their slow adding/erasing performance but very good searching performance becuase they maintain all their elements within the same memory block (this helps with element indexing).

I am not saying I will use vectors, but something like that. I have to explore what structures CS offers for me to use :). Maybe you can give me some ideas on that.

Besides from that, I think graphs should be aloud to be defined dynamically (by an automatic graph generation algorythm) and statically (defined in world files).

I have some ideas on dynamic graph creation, these are:

Polygonal Meshes
The level is made of polygons connected to other polygons. Each polygon acts as a node in the graph. Nodes are connected if their corresponding polygons share an edge

Dirichlet Domains, also known as Voronoi Diagrams
Graphs can be defined by Dirichlet domains by defining a set of points (called characteristic points) in the level which will serve as nodes. Each node has a region of influence around it, and it is connected to all other nodes within its region of influence.

Points of visibility
I am short on time right now, but I will add a description, later ;)

Trackback address for this post:

This is a captcha-picture. It is used to prevent mass-access by robots.
Please enter the characters from the image above. (case insensitive)

Comments, Trackbacks, Pingbacks:

Comment from: Mat Sutcliffe (Oktal) [Visitor] Email
csArray is the Crystal Space equivalent of std::vector, so judging by what you've said, it sounds like csArray is what you want to use in your graph implementation. Other containers in CS are listed in the Containers module section of the online API documentation.

I think perhaps the graph interface/implementation belongs in CS, not CEL, because it is useful for a much broader range of problems besides AI and games.

Because you want to be able to construct a graph in code and also in world files, I suggest for the graph interface to be an Object/Wrapper pair... For example, an interface (abstract base class) called iGraph and another called iGraphWrapper; iGraphWrapper would subclass iObject (all objects that can be stored in world files have a Wrapper that subclasses iObject). The iGraph interfaces with the actual graph implementation, while the iGraphWrapper connects it to the iEngine, which stores a representation of the world file in memory (as a tree of iObject's). To get a reference to the iGraph from an iGraphWrapper the user would use a iGraphWrapper::GetGraph() method, and conversely, to get to the iGraphWrapper from an iGraph, use iGraph::GetGraphWrapper(). Because iGraphWrapper subclasses iObject, it can therefore be loaded from a world file. If you wanted to dynamically create a graph in code you could use the iGraph directly and create a wrapper for it with iEngine::CreateGraphWrapper() so you could put it into the world.

Maybe also each of the nodes of the graph (and maybe the edges too) should be able to store an iObject reference (so you could nest any other type of worldfile object within the nodes) and/or any of the types of objects which can be parsed by iSyntaxService.
PermalinkPermalink 2007-04-30 @ 15:15
Comment from: Jorrit [Member] Email
iGraphWrapper would not subclass iObject. But the object that implements iGraphWrapper would also implement iObject. That's the way it is usually done in Crystal Space.

Greetings,
PermalinkPermalink 2007-04-30 @ 20:25
Comment from: Alex Michael [Visitor] Email · http://sc2cheats.org
Thanks for sharing.
PermalinkPermalink 2010-11-19 @ 07:10
Comment from: Volunteering abroad [Visitor] · http://www.projects-abroad.co.uk
nice post, thanks!
PermalinkPermalink 2011-01-18 @ 14:17
Comment from: Loft Conversions Brighton [Visitor] Email · http://www.controlbuild.co.uk
thanks for the informative and helpful post. You have good expertise on the topic and have presented it in a very professional way. Thanks for sharing! :)
PermalinkPermalink 2011-04-06 @ 16:21
Comment from: Sash Windows [Visitor] Email · http://www.controlsashwindows.co.uk
Hi i really enjoyed reading through your post, really had me thinking in depth which is a rare thing these days with all the rubbish in the news, keep up the good work, and I will be sure to bookmark your blog and visit again in the near future, greeting from the United Kingdom
PermalinkPermalink 2011-05-11 @ 17:05

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))
This is a captcha-picture. It is used to prevent mass-access by robots.
Please enter the characters from the image above. (case insensitive)

February 2012
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29        

Search

Archives

Misc

XML Feeds

What is this?

powered by
b2evolution