Components enhancement
While thinking about the modifiers, I stumbled upon a problem that might not spring into mind when figuring out a game system. I wondered, how I would handle components that should be removed or deactivated? What should happen, when the game is paused?
Imagine a character has attached a buff which gives him ie. +5 Health every 10 seconds. When you pause the game, you might still want to update any graphic animations (ie. idle animation) but you certainly don't want any buff continue it's work. So you might have to put the buff into "pause mode", you'll have to deactivate the buff.
I played around with the components and modifiers (which are components, too) in my mind and finally decided that it was a good idea to have a ComponentContainer. This container would hold any type of component, and could hold a set of flags which ie. activate a component, tell the container, that the component should be removed (ie. during next update) or that the component should not get an update.
I then decided to derive my Component class from the ComponentContainer. The benifit of this is that I automagically have the possibility to attach ie. a modifier to a modifier (remember the timer example from yesterdays blog entry?).
Currently I have 3 flags: IS_ACTIVE, DO_UPDATE and DO_REMOVE.
DO_REMOVE flags a component to be removed during ie. the next update of the parent component (well... in fact, the one that holds the component container should decide when unused components should be removed. A character class ie. would remove them in every game turn, while a component would remove them in the next update.).
IS_ACTIVE and DO_UPDATE mostly come in pair. Only active components can receive updates. You can see that removing the DO_UPDATE flag from component would make them "pause" until you set the flag active again. Disable IS_ACTIVE is useful when ie. the player wants to push things around from the inventory to the character and vice versa. A grapped item (attached to the mouse) would be set inactive (while remaining on the character in a greyed out manner) and thus have no more effect on ie. the characters values (if there was a value modifier attached to the item).
That's my current state of the components. I'm thinking of how to handle those flag changes with small effort and the more I think of this, the more I'm convinced that my SSCXML has found a new place to be :)
Have fun,
Stefan
PS: It's quite possible that I'll have no blog updates in the next two days since I have to travel to some clients on monday and tuesday.
Imagine a character has attached a buff which gives him ie. +5 Health every 10 seconds. When you pause the game, you might still want to update any graphic animations (ie. idle animation) but you certainly don't want any buff continue it's work. So you might have to put the buff into "pause mode", you'll have to deactivate the buff.
I played around with the components and modifiers (which are components, too) in my mind and finally decided that it was a good idea to have a ComponentContainer. This container would hold any type of component, and could hold a set of flags which ie. activate a component, tell the container, that the component should be removed (ie. during next update) or that the component should not get an update.
I then decided to derive my Component class from the ComponentContainer. The benifit of this is that I automagically have the possibility to attach ie. a modifier to a modifier (remember the timer example from yesterdays blog entry?).
Currently I have 3 flags: IS_ACTIVE, DO_UPDATE and DO_REMOVE.
DO_REMOVE flags a component to be removed during ie. the next update of the parent component (well... in fact, the one that holds the component container should decide when unused components should be removed. A character class ie. would remove them in every game turn, while a component would remove them in the next update.).
IS_ACTIVE and DO_UPDATE mostly come in pair. Only active components can receive updates. You can see that removing the DO_UPDATE flag from component would make them "pause" until you set the flag active again. Disable IS_ACTIVE is useful when ie. the player wants to push things around from the inventory to the character and vice versa. A grapped item (attached to the mouse) would be set inactive (while remaining on the character in a greyed out manner) and thus have no more effect on ie. the characters values (if there was a value modifier attached to the item).
That's my current state of the components. I'm thinking of how to handle those flag changes with small effort and the more I think of this, the more I'm convinced that my SSCXML has found a new place to be :)
Have fun,
Stefan
PS: It's quite possible that I'll have no blog updates in the next two days since I have to travel to some clients on monday and tuesday.
Labels: components, container, modifier, SCXML, SSCXML
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home