attal-devel Mailing List for Attal : Lords of doom

Hi!

I have a few suggestions to make about how we can code
the map..

About the number being used..I think it is a good
idea.. But instead of predefining what these numbers
represent.. I think a better alternative would be to
allow the map to carry its tiles in the following
form..

Initially we can have a list of tiles. as follows..
First byte of map stores tile no 
Then each subsequent line stores a file-name.
i.e The file storing the tile..
Now we can have a tile class which can be used to
store the details of the tile.including loading the
tile from the file..

Now the map class stores a pointer to an array of
tiles..

So the map now can be written in terms of indexes into
the array.. This will allow us the flexibility to add
ne number of tiles.. as and when needed.

Or else even better we can store the tile no with the
file-name in the map file. This way we need not rely
on the index..

What do u say guys..I think this is much more elegant
solution.Since this will allow us to add new kind of
terrain ne time we need.

Let me know ur views.

Bye
Bhasker

--- Pascal Audoux <pa...@ya...> wrote:
> > About today developpement: how is it coded?
> Well, for the moment : numbers (0, 1, 2, ...)
> 0 = water, 1 = grass, etc...
> in an array...
> Of course it is temporary... but close from the
> final form, I think.
> 
> > I suggest you to put it on a forum thread,
> > in order anyone to answer :-)
> So, I add the mailing-list adress in the 'To' field
> of this mail.
> 
> 
> > >Some terrain types would be:
> > >Forest
> > >Hill
> > >Impassable
> > >Lava
> > >Mountain
> > >Plains
> > >Water
> > >
> > >A map could look like:
> > >WWWWWWWWWWWWWW
> > >WWWPPPPPPWWWWW
> > >WWPPWWWWPPFFFF
> > >WPHWWMMWWPHPFF
> > >PFHWMMLMWWHPFP
> > >PHWWWMMMWWFHPF
> > >FWWWWWWWWPFHFF
> > >WPFFPFPFMPFHFF
> > >WWWFPPFPHPWWWW
> > >WWWWWWWWWWWWWW
> > Well.
> > Think about:
> > ...WLL...
> > The L in the middle is not shown on screen
> > as the L at the right, cos it shows sea's border.
> > Maybe two ways for coding it
> > (we sould ask the developpers about it)
> > 1) like HoMM3: many and many sprites/tiles
> > for each type of terrain (about 80!),
> > when terrain is surrended by same type of terrain,
> > and when terrain is close to each other type of
> terrai
> > In the map: type of terrain+nb to precise this
> terrain
> > I mean: two datas are needed to each tile
> > 2) like you say, only the terrain type
> > It implies calculating which sprites/tiles to
> take,
> > within game (instead of pre-calculating while
> creating
> > the map within the editor).
> 
> I think that the (1) is a better way of coding... 
> The map editor will have to calculate the transition
> between different
> type of terrain... We just have to find a way of
> coding these transitions,
> indeed.
> 
> Note : I prefer number to letter because of the use
> of theme... I think
> that a map could be used in different themes...
> 
> 
> _______________________________________________
> Attal-devel mailing list
> Att...@li...
>
http://lists.sourceforge.net/mailman/listinfo/attal-devel


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

> About today developpement: how is it coded?
Well, for the moment : numbers (0, 1, 2, ...)
0 = water, 1 = grass, etc...
in an array...
Of course it is temporary... but close from the final form, I think.

> I suggest you to put it on a forum thread,
> in order anyone to answer :-)
So, I add the mailing-list adress in the 'To' field of this mail.


> >Some terrain types would be:
> >Forest
> >Hill
> >Impassable
> >Lava
> >Mountain
> >Plains
> >Water
> >
> >A map could look like:
> >WWWWWWWWWWWWWW
> >WWWPPPPPPWWWWW
> >WWPPWWWWPPFFFF
> >WPHWWMMWWPHPFF
> >PFHWMMLMWWHPFP
> >PHWWWMMMWWFHPF
> >FWWWWWWWWPFHFF
> >WPFFPFPFMPFHFF
> >WWWFPPFPHPWWWW
> >WWWWWWWWWWWWWW
> Well.
> Think about:
> ...WLL...
> The L in the middle is not shown on screen
> as the L at the right, cos it shows sea's border.
> Maybe two ways for coding it
> (we sould ask the developpers about it)
> 1) like HoMM3: many and many sprites/tiles
> for each type of terrain (about 80!),
> when terrain is surrended by same type of terrain,
> and when terrain is close to each other type of terrai
> In the map: type of terrain+nb to precise this terrain
> I mean: two datas are needed to each tile
> 2) like you say, only the terrain type
> It implies calculating which sprites/tiles to take,
> within game (instead of pre-calculating while creating
> the map within the editor).

I think that the (1) is a better way of coding... 
The map editor will have to calculate the transition between different
type of terrain... We just have to find a way of coding these transitions,
indeed.

Note : I prefer number to letter because of the use of theme... I think
that a map could be used in different themes...

Hello,

Indeed it does seem like the same algorithm; thanks for pointing it out.
Dividing some of the nested code in:
void PathFinder::computePath( GenericCell * start )
GenericCell * PathFinder::getNearCell( GenericCell * dest )

into functions would probably make it a bit easier to follow; but, would slow it
down, I don't know if this would be worth it.

Cheers,
Enrique


>Well, I just have a quick look on your Algorithm and I think that is the
>one we use (A* algo are classics). But I'm not sure :))
>(our algo is in common/pathFinder.h/cpp)
>About the algo we use, I know that it should be better written, it will be
>done soon... but I don't know when :-))
>


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Well, I just have a quick look on your Algorithm and I think that is the
one we use (A* algo are classics). But I'm not sure :))
(our algo is in common/pathFinder.h/cpp)
About the algo we use, I know that it should be better written, it will be
done soon... but I don't know when :-))

> Hello,
> 
> I've looked into pathfinding algorithms and the best pseudo code description I
> could find is at:
> http://www.geocities.com/SiliconValley/Lakes/4929/ascode.txt
> after reading this I finally understood the astar ( A* ) algorithm. I've copied
> the text below.
> 
> Other good descriptions of the astar algorithm are at:
> http://theory.stanford.edu/~amitp/GameProgramming/
> his C code .cpp file is at:
> http://theory.stanford.edu/~amitp/GameProgramming/path.cpp
> and a good link page is at:
> http://www.gameai.com/pathfinding.html
> 
> For the future use, what is the best place to put this kind of development
> information? On the mailing list, the forum or maybe in the cvs?
> 
> Cheers,
> Enrique
> 
> 
> bool AStarSearch()
> {
>   // priority queues are explained in the next section  
>   priorityqueue OPEN 
>   
>   list CLOSED
>   
>   NODE node
> 
>   node.application_stuff = (start conditions of application specific stuff)
>   node.cost = 0;
>   node.heuristic = GetNodeHeuristic( node )
>   node.f = node.cost + node.heuristic
>   node.parent = null
>   push node on OPEN
> 
>   // this is the body of the search
> 
>   while OPEN is not empty  
>   {
>     node = Pop the best node from OPEN 
>     // ie: take the node off the open list
> 
>     if node is a goal node 
>     {
>       construct path  (by following the parent pointers)
>       return success
>     }
>     
>     // otherwise we need to find what nodes can be generated from this node
> 
>     NodePushSuccessors( OPEN, CLOSED, node ); // see below
> 
>     push node onto CLOSED list // as we have now examined this node
> 
>   }
> 
>   // if we got here we emptied the OPEN list and found no GOAL states
>   // the search failed
> 
>   return FALSE 
> 
> }
> 
> // Create the successors for the given node and add them to the open or closed 
> // lists as required
> 
> void NodePushSuccessors( priorityqueue OPEN, list CLOSED, parent_node )
> {
> 
>   // This is where you apply each valid rule to the node we're checking out
>   // In the case of a pathfinder, for example, a rule is a direction of movement
> 
>   for each rule we can apply create the successor new_node
>   {
>     new_node.cost = (application specific cost of this node) + parent_node.cost 
> 
>     // you need to write this function for your application
>     // usually the toughest part of implementing the astar.
> 
>     new_node.heuristic = GetNodeHeuristic( new_node )  
> 
>     new_node.f = new_node.cost + new_node.heuristic
> 
>     if the new_node is on CLOSED but the node on CLOSED has a lower 'f'
>     {
>       continue;
>     }
> 
>     if the new_node is on OPEN but the node on OPEN has a lower 'f'
>     {
>       continue;
>     }
>         
>     remove new_node from the OPEN list if it is on it
>     remove new_node from the CLOSED list if it is on it
> 
>          new_node.parent = parent_node
> 
>     push new_node on to the OPEN list
>   }
> 
> }
> 
> 
> -- 
> Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
> _______________________________________________
> Attal-devel mailing list
> Att...@li...
> http://lists.sourceforge.net/mailman/listinfo/attal-devel
> 

Hello,

I've looked into pathfinding algorithms and the best pseudo code description I
could find is at:
http://www.geocities.com/SiliconValley/Lakes/4929/ascode.txt
after reading this I finally understood the astar ( A* ) algorithm. I've copied
the text below.

Other good descriptions of the astar algorithm are at:
http://theory.stanford.edu/~amitp/GameProgramming/
his C code .cpp file is at:
http://theory.stanford.edu/~amitp/GameProgramming/path.cpp
and a good link page is at:
http://www.gameai.com/pathfinding.html

For the future use, what is the best place to put this kind of development
information? On the mailing list, the forum or maybe in the cvs?

Cheers,
Enrique


bool AStarSearch()
{
  // priority queues are explained in the next section  
  priorityqueue OPEN 
  
  list CLOSED
  
  NODE node

  node.application_stuff = (start conditions of application specific stuff)
  node.cost = 0;
  node.heuristic = GetNodeHeuristic( node )
  node.f = node.cost + node.heuristic
  node.parent = null
  push node on OPEN

  // this is the body of the search

  while OPEN is not empty  
  {
    node = Pop the best node from OPEN 
    // ie: take the node off the open list

    if node is a goal node 
    {
      construct path  (by following the parent pointers)
      return success
    }
    
    // otherwise we need to find what nodes can be generated from this node

    NodePushSuccessors( OPEN, CLOSED, node ); // see below

    push node onto CLOSED list // as we have now examined this node

  }

  // if we got here we emptied the OPEN list and found no GOAL states
  // the search failed

  return FALSE 

}

// Create the successors for the given node and add them to the open or closed 
// lists as required

void NodePushSuccessors( priorityqueue OPEN, list CLOSED, parent_node )
{

  // This is where you apply each valid rule to the node we're checking out
  // In the case of a pathfinder, for example, a rule is a direction of movement

  for each rule we can apply create the successor new_node
  {
    new_node.cost = (application specific cost of this node) + parent_node.cost 

    // you need to write this function for your application
    // usually the toughest part of implementing the astar.

    new_node.heuristic = GetNodeHeuristic( new_node )  

    new_node.f = new_node.cost + new_node.heuristic

    if the new_node is on CLOSED but the node on CLOSED has a lower 'f'
    {
      continue;
    }

    if the new_node is on OPEN but the node on OPEN has a lower 'f'
    {
      continue;
    }
        
    remove new_node from the OPEN list if it is on it
    remove new_node from the CLOSED list if it is on it

         new_node.parent = parent_node

    push new_node on to the OPEN list
  }

}


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su