I think the objects need to have a memory of where they were before. I think it's the only way to do stuff like pushing things into water. If the object doesn't remember where it was you would get multiple messages of the object falling in water when it's pushed to the next water tile. The funny thing is that I previously had that kind of data, but for some reason I removed it. I need to look at action data again, because creatures do have current task they are doing, like swimming. But I think that can't be used with other type of objects, because things like barrels don't go swimming, they just fall into water and float in there.
I'm thinking of breaking the big poop into micro actions. Like "fall into water", "float in water", "get out of water" etc. Well maybe I don't need the previous action to determine things, just current action.
I've also tried to clean up some of the mess in Message class. It's scary, that's all I can say about that.
Maybe have a queue of events that happened during the update? Then, when you're moving an object you compare its old and new positions, and generate events as appropriate. The objects would not need to remember their old positions afterward. Following the update, present the events to the player and clear the queue.
ReplyDeleteThis might work more reliably in some instances. As a contrived example, say an object moves into water and then its old position becomes water later in the same turn. If the object is examining its old and new locations after the update it wouldn't detect that it had moved into water.
What you want here is a finite state machine for the movement type.
ReplyDelete