Feels like half of Milestone, as one new big system was added and is now functional. First, I didn't want to add this system at this point, as I didn't want to decide about look of the game (3D or 2D) until very far into the development, after all functional stuff has been done. But after thinking about future of the project during MS2 I thought that it will be best to have it done as 2D, as creating 2D graphics is much more straightforward for most people and it can be done much easier and faster (unless you have base of animations and you just rig meshes to same animations).
Gameplay and animations systems are separate beings and at the moment there is no need to have any interface between them, although I want to add something that may help keeping track of played animations etc. Currently animation system watches gameplay object it represents and tries to show what is going on. Example: Chest gameplay object may have three states: Locked, Closed and Open. By using certain key it may go from Locked to Open and then from Closed to Open and back. But animation tree for it uses just two big states: Closed and Open, since there is no difference between Locked and Closed. And there are also two extra states, one for chest being open and second for chest being closed (animations). As soon as animation system notices that gameplay object has changed its state, it changes state as well. As look doesn't affect gameplay, when animation for chest being open is played, it is already open and may be closed. So when this happens, animation is stopped and switched to animation of chest being closed. It is automaticaly synchronised correctly - with all data about synchronisation stored in animations, as at the animation tree level we shouldn't be bothered with such details (this is what annoys me with game engines that rather force high level systems with such tasks, even if most of the time animations are used for just exact one thing, and even if there would be need to use one animation for more than one function, it is better to have two animation objects sharing same data, but that's a thing to discuss in other topic). There was one thing I had some little trouble deciding how to approach it. As characters and items may face different directions, it was not so clear how I should store Animation vs Bitmap objects. Should I have separate animations for different angles? Or better have one animation with some atom objects and inside each different angles should be provided. At the moment I have no idea how I could think about first approach as it is pretty clear that it is much better to have single animation with bigger atom objects. Easier to maintain and change.
Ok, one more thing. I needed to have state machines and having in mind that I will use them couple of times (I am also using them for items now), I wanted to have pretty generic system but at the same time without some implications on use. And I decided to make a little experiment. Make state machine objects just a components of some arbitraty hierarchy. And it just works nicely and gives me freedom of implementation of other stuff. I have now two objects related to state machines. One is handler that allows deciding which state I want to be my current state (I call it "desired state"). It relies on some logic, decisions and/or copying state of owning object. The other is state itself or rather rules for state. It takes desired state as input, chews it and gives out state we need/may to go. How does it work? Well:
In example with chest we had three states Locked, Closed and Open. Handler copies state and replaces Locked with Closed. Then if state has changed rules tell that to go from Closed to Open, animation tree needs to go first to Opening. And Opening tells that it may finally reach Open only when current state has reached its end (in this case: when animation has ended). Or it may go back to Closed via Closing.
Ok, but that's enough. Now for some AI.
Gameplay and animations systems are separate beings and at the moment there is no need to have any interface between them, although I want to add something that may help keeping track of played animations etc. Currently animation system watches gameplay object it represents and tries to show what is going on. Example: Chest gameplay object may have three states: Locked, Closed and Open. By using certain key it may go from Locked to Open and then from Closed to Open and back. But animation tree for it uses just two big states: Closed and Open, since there is no difference between Locked and Closed. And there are also two extra states, one for chest being open and second for chest being closed (animations). As soon as animation system notices that gameplay object has changed its state, it changes state as well. As look doesn't affect gameplay, when animation for chest being open is played, it is already open and may be closed. So when this happens, animation is stopped and switched to animation of chest being closed. It is automaticaly synchronised correctly - with all data about synchronisation stored in animations, as at the animation tree level we shouldn't be bothered with such details (this is what annoys me with game engines that rather force high level systems with such tasks, even if most of the time animations are used for just exact one thing, and even if there would be need to use one animation for more than one function, it is better to have two animation objects sharing same data, but that's a thing to discuss in other topic). There was one thing I had some little trouble deciding how to approach it. As characters and items may face different directions, it was not so clear how I should store Animation vs Bitmap objects. Should I have separate animations for different angles? Or better have one animation with some atom objects and inside each different angles should be provided. At the moment I have no idea how I could think about first approach as it is pretty clear that it is much better to have single animation with bigger atom objects. Easier to maintain and change.
Ok, one more thing. I needed to have state machines and having in mind that I will use them couple of times (I am also using them for items now), I wanted to have pretty generic system but at the same time without some implications on use. And I decided to make a little experiment. Make state machine objects just a components of some arbitraty hierarchy. And it just works nicely and gives me freedom of implementation of other stuff. I have now two objects related to state machines. One is handler that allows deciding which state I want to be my current state (I call it "desired state"). It relies on some logic, decisions and/or copying state of owning object. The other is state itself or rather rules for state. It takes desired state as input, chews it and gives out state we need/may to go. How does it work? Well:
In example with chest we had three states Locked, Closed and Open. Handler copies state and replaces Locked with Closed. Then if state has changed rules tell that to go from Closed to Open, animation tree needs to go first to Opening. And Opening tells that it may finally reach Open only when current state has reached its end (in this case: when animation has ended). Or it may go back to Closed via Closing.
Ok, but that's enough. Now for some AI.
