Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#Actualfrob

Posted 17 May 2013 - 02:08 AM

So you say better OO approach is to let the world logic tell what accessibility there is between buildings? the reason for each building to have this information is because if there's a wooden bridge then humans can travel across it, but heavy donkey carts cannot because the bridge might collapse so they need to use stone bridge instead.
every time i add new type of these buildings the pathing possibilities increase.
so i might be moving the conditional code outside the class but that seems to require keeping a list of class vs class accessibilities.

Are you remembering to program to interfaces, and also to use composition?

Everything that exists in the world is a game object.

Some game objects are portals. They should implement a portal interface, or if your design prefers, they should have a portal component.

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.

#2frob

Posted 17 May 2013 - 02:05 AM

So you say better OO approach is to let the world logic tell what accessibility there is between buildings? the reason for each building to have this information is because if there's a wooden bridge then humans can travel across it, but heavy donkey carts cannot because the bridge might collapse so they need to use stone bridge instead.
every time i add new type of these buildings the pathing possibilities increase.
so i might be moving the conditional code outside the class but that seems to require keeping a list of class vs class accessibilities.

Are you remembering to program to interfaces, and also to use composition?

Everything that exists in the world is a game object.

Some game objects are portals. They should implement a portal interface.

I'm guessing your portal would be like ours. It has multiple lanes, 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.

#1frob

Posted 17 May 2013 - 02:04 AM

So you say better OO approach is to let the world logic tell what accessibility there is between buildings? the reason for each building to have this information is because if there's a wooden bridge then humans can travel across it, but heavy donkey carts cannot because the bridge might collapse so they need to use stone bridge instead. 
every time i add new type of these buildings the pathing possibilities increase.
so i might be moving the conditional code outside the class but that seems to require keeping a list of class vs class accessibilities.


Are you remembering to program to interfaces, and also to use composition?

Everything that exists in the world is a game object.

Some game objects are portals. They should implement a portal interface.

I'm guessing your portal would be like ours. It has multiple lanes. 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.

PARTNERS