# Need Help with Conveyor Belt Logic for My 2D Top-Down Game

Hi everyone,

I’m currently working on implementing conveyor belts in my 2D top-down game, and I’m facing some challenges with determining the correct direction of the belts when placing them. My game supports 12 possible directions for conveyor belts. Here’s an example image of the possible directions:

I want to implement a logic that adjusts the direction of the belt based on its neighboring belts. So far, I have a function for the “Up” direction, but it’s already quite complex and involves a lot of switch cases (and it’s not even full of them…). Here’s my current implementation:

``````public Direction GetProperBeltDirection(Vector3Int futureBeltPos, Direction futureBeltDirection)
{
int x = futureBeltPos.x;
int y = futureBeltPos.y;
Direction resultDirection = futureBeltDirection;
ConveyorBelt rightNeighbour = GetRightNeighbourConveyorBelt(x, y, futureBeltDirection);
ConveyorBelt leftNeighbour = GetLeftNeighbourConveyorBelt(x, y, futureBeltDirection);
ConveyorBelt upNeighbour = GetUpNeighbourConveyorBelt(x, y, futureBeltDirection);
ConveyorBelt downNeighbour = GetDownNeighbourConveyorBelt(x, y, futureBeltDirection);
switch (futureBeltDirection)
{
case Direction.Up:
if (leftNeighbour != null && rightNeighbour != null && rightNeighbour.GetDirection() == Direction.Left && leftNeighbour.GetDirection() == Direction.Right)
{
resultDirection = futureBeltDirection;
}
else if (rightNeighbour != null && rightNeighbour.GetDirection() == Direction.Left)
{
resultDirection = Direction.LeftUp;
}
else if(rightNeighbour != null && rightNeighbour.GetDirection() == Direction.Right)
{
resultDirection = Direction.UpRight;
}
else if (leftNeighbour != null && leftNeighbour.GetDirection() == Direction.Right)
{
resultDirection = Direction.RightUp;
}
else if (leftNeighbour != null && leftNeighbour.GetDirection() == Direction.Left)
{
resultDirection = Direction.UpLeft;
}
else if (upNeighbour != null && upNeighbour.GetDirection() == Direction.Up)
{
resultDirection = futureBeltDirection;
}
//should be more .....
break;
}
return resultDirection;
}
``````

As you can see, this is just for the “Up” direction and it’s already quite verbose. I need to implement similar logic for “Down”, “Left”, and “Right” directions, and I’m worried that my code will become very cumbersome and hard to maintain.

Does anyone have any suggestions for a more compact or efficient way to handle this logic? Any advice or examples would be greatly appreciated!

Demo :

We can definitely find a way to shorten your code, but I’m more concerned about something else: what should the pathfinding logic be in situations where the situation is ambiguous?

For example, we were building the path with blue arrows and everything was fine until we reached the red arrow:

How should the path understand that the direction for the red arrow is from above

and not from the left?

I think such situations may arise quite often.

1 Like

@samana1407 Thanks for your reply, but yeah unfortunatly i really don’t know, maybe i just complicated stuff by having 12 directions instead of having only 4, i just want a simple conveyor belt system “visually” with a good path fiding (directions show on the belt) because having all that directions can lead to ambigous scenario another example : why should the UP turn into a left up in my demo? What if i put a RIGHT direction next to the left-up in my example? Will it turn into a right-up? or will it turn into a left-right-up?

So i will try to revisit the logic and comeback here with updates !, feel free to post your ideas.

1 Like

A game to take inspiration from here would be Factorio.

From memory, you can specify the rotation of the conveyer belt you’re going to place. If there’s an ‘end’ belt piece, it will update to be turning towards the piece you place. If you put a belt perpendicular to a non-end piece it won’t update (so that the belt can dump its contents onto one side of the belt it’s up against).

Then the player can rotate individual pieces without affecting other pieces. If you haven’t played it, it’s worth looking at for inspiration. Along with some of the other conveyer belt-centric games.

1 Like

For readability, it may help to have a function which returns the output direction of a specific X, Y location rather than a ConveyorBelt reference. There are three different tile directions that can send stuff “up”, so those would all return Direction.Up from this function. If there is no belt in the location, it can return Direction.None.

This lets you remove the null checks from all of the “if” statements and also lets you easily handle all of the different flavors of belts which send objects in the same direction.

2. Each belt only has 3 possibilities.
When placing your Up belt, I expect you want objects to flow out to the top of that tile. Therefore, this function should only return Up, LeftUp, or RightUp when placing an Up tile. You shouldn’t need your code for UpLeft and UpRight.

3. Just detect the corner-belt cases and let everything else be handled by “else”
When you are placing an Up arrow, you really just need to decide if it should be replaced by a RightUp or LeftUp arrow. Just detect those two cases and otherwise just output Up in the else clause.

If you can simplify the if/else tree to this degree, then maybe it will be ok to replicate it for the other four directions. I personally feel that trying to create one set of conditions that is somehow agnostic to the current direction will end up making the code harder to read.