Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualheh65532

Posted 17 May 2013 - 07:29 PM

I'm guessing your portal would be like ours. A portal has some number of lanes (usually 1), and the routing system automatically routes near the portal, waits for a lane to become free, marks the lane as in use, then travels across it. Only certain units can travel across particular lane types. There is an animation that plays (very similar to the basic walking cycle) when a unit travels between the portal endpoints. And finally, you can place multiple portals together end-to-end and have them work continuously.

We have many kinds of portals. They include bridges, ramps, stairs, doors, and elevators.

For us, we simply add a portal component to a game object, fill in a few functions that the interface requires such as the portal type and the animation names, and routing automatically picks up whatever new portal type we added.

 

that sounds like a good way. but the thing is i added access logic to each building so they can tell the pathfinder in which various ways they can be traveled through. for example there maybe a tower with one door on ground level and two doors at the top leading outside where a wall can be. So the tower needs to tell pathfinder the ground door can be used if there's ground and not water for example or some other obstacle and the top doors can be used if there's some connection like walls/platform next to the doors. 

this seems to require rather complex set of portals. so i might use some kind of portal component system or try to do better OO design. 


#1heh65532

Posted 17 May 2013 - 07:27 PM

I'm guessing your portal would be like ours. A portal has some number of lanes (usually 1), and the routing system automatically routes near the portal, waits for a lane to become free, marks the lane as in use, then travels across it. Only certain units can travel across particular lane types. There is an animation that plays (very similar to the basic walking cycle) when a unit travels between the portal endpoints. And finally, you can place multiple portals together end-to-end and have them work continuously.

We have many kinds of portals. They include bridges, ramps, stairs, doors, and elevators.

For us, we simply add a portal component to a game object, fill in a few functions that the interface requires such as the portal type and the animation names, and routing automatically picks up whatever new portal type we added.

 

that sounds like a good way. but the thing is i added access logic to each building so they can tell the pathfinder in which various ways they can be traveled through. for example there maybe a tower with one door on ground level and two doors at the top leading outside where a wall can be. So the tower needs to tell pathfinder the ground door can be used if there's ground and not water for example or some other obstacle and if the top doors can be used if there's some connection there like walls/platform next to the doors. 

this seems to require rather complex set of portals. so i might use some kind of portal component system or try to do better OO design. 


PARTNERS