2 ms·

In regards to your specific question about how to cleanly resolve the two AI problem, I can think of two ways to deal with that situation. 1) Lock-based "updat

In regards to your specific question about how to cleanly resolve the two AI problem, I can think of two ways to deal with that situation. 1) Lock-based "update the world state" kind of solution. Whichever thread manages to grab the lock for being able to pick up an item is the winner, and actually gets the item. The world is modified so that the item no longer exists. When the other AI gets the lock and tries to pick up the item, it will get some kind of error letting it know that the item no longer exists. Or it can double-check for the existence of the item, and abort the pick up attempt before an error can be generated. 2) The other resolution I can think of is to have a queue of state updates. Basically, both AI broadcast to a queue that they wish to pick up an item. Whichever AI queues first, gets the item. Some logic runs to give the item to that AI, (thus removing it from the world) and then sees that the second attempt to get the item is no longer valid and aborts the attempt. I think those two ideas make sense at a high level. (I'm sure the nitty gritty is complicated) Also they don't deal with having to roll back state to a previous point in time. (I think) Any thoughts?

Morgawr 13y ago
With Clojure it's a bit different cause you want to handle non-locking using atoms/refs/agents/whatever. In my engine you can either a) have the first entity send a message to the object it wants to pick up, then have the object handle a queue of transformation functions on its state. The first function that is run on the object's thread is the one that changes its state or b) if you want immediate response have the first entity actually act on the object to pick up, due to atom (or refs) locking/transactions only one of the two entities can act on the object, hence the second one will fail to pick it up.

Morgawr 13y ago

With Clojure it's a bit different cause you want to handle non-locking using atoms/refs/agents/whatever. In my engine you can either a) have the first entity send a message to the object it wants to pick up, then have the object handle a queue of transformation functions on its state. The first function that is run on the object's thread is the one that changes its state or b) if you want immediate response have the first entity actually act on the object to pick up, due to atom (or refs) locking/transactions only one of the two entities can act on the object, hence the second one will fail to pick it up.