Now I’m using collision detection when approaching a resource patch. My current way of doing things is that the resource patch center is set as pathfinding destination tile. When a unit collides with the resource patch it stops and switches to working mode( resource gathering). I have to dump this model. I need a different approach to the problem. Any kind of feedback is appreciated.

Calin said:
I have to dump this model. I need a different approach to the problem.

Why? What's the problem with your current method? Which behavior do you want instead?

JoeJ said:

Calin said:
I have to dump this model. I need a different approach to the problem.

Why? What's the problem with your current method? Which behavior do you want instead?

I’m switching from an event driven system to state machines. In my current model when a unit collides with the resource patch it stops between the center of two tiles hence when it finishes work it needs do make a step back and return to the center of a tile. If you try to implement such behavior in a state machine, the state machine becomes too complicated.

Calin said:
I’m switching from an event driven system to state machines. In my current model when a unit collides with the resource patch it stops between two tiles hence when it finishes work it needs do make a step back to return on the center of a tile. If you try to implement such behavior in a state machine, the state machine becomes too complicated.

Aside from that being nonsense (statemachines are used to implement way more complicated things than a unit having to do something on state switch) - why use State-Machines then? You should use an implementation that fits your design-needs, and not model your design around your implementation.

Calin said:
I’m switching from an event driven system to state machines. In my current model when a unit collides with the resource patch it stops between two tiles hence when it finishes work it needs do make a step back to return on the center of a tile. If you try to implement such behavior in a state machine, the state machine becomes too complicated.

Sounds you got something working from using trial and error, and now it turns out your logic is too tightly coupled to a spatial state which is not robust. Maybe spatial behavior should deal with local problems automatically but independent from a higher level state machine controlling long termed objectives. Basically, the high level state machine would think ‘i'm close enough to the patch, let's start collecting resources’. A lower level system controlling the units motion in detail then cares about details like stepping close enough, avoiding contact with other units, waiting for other units to leave so there is enough space, etc.

Juliean said:

Calin said:
I’m switching from an event driven system to state machines. In my current model when a unit collides with the resource patch it stops between two tiles hence when it finishes work it needs do make a step back to return on the center of a tile. If you try to implement such behavior in a state machine, the state machine becomes too complicated.

Aside from that being nonsense (statemachines are used to implement way more complicated things than a unit having to do something on state switch) - why use State-Machines then? You should use an implementation that fits your design-needs, and not model your design around your implementation.

I’m not saying it can’t be done. All I’m saying is a state machine like that is too complicated and I can’t figure it out.

JoeJ said:

Calin said:
I’m switching from an event driven system to state machines. In my current model when a unit collides with the resource patch it stops between two tiles hence when it finishes work it needs do make a step back to return on the center of a tile. If you try to implement such behavior in a state machine, the state machine becomes too complicated.

Sounds you got something working from using trial and error, and now it turns out your logic is too tightly coupled to a spatial state which is not robust. Maybe spatial behavior should deal with local problems automatically but independent from a higher level state machine controlling long termed objectives. Basically, the high level state machine would think ‘i'm close enough to the patch, let's start collecting resources’. A lower level system controlling the units motion in detail then cares about details like stepping close enough, avoiding contact with other units, waiting for other units to leave so there is enough space, etc.

JoeJ thanks for advice. That’s something to think about.

Calin said:
In my current model when a unit collides with the resource patch it stops between the center of two tiles hence when it finishes work it needs do make a step back and return to the center of a tile.

If the unit moves in 1-tile steps and harvests into an adjacent tile this process of moving, colliding and undoing the move is a completely unnecessary cluster of complications.

Before the harvester “moves” you already know whether the current location is adjacent to any resource tile of the appropriate type (or to the original designated target tile, but there might be more than one in general).

If the resource is adjacent, harvest in the appropriate direction instead of moving and colliding; if it isn't, walk one more tile.