The question arises, what should the Liquid object encapsulate, and what should the LiquidComponent object encapsulate?
Should the user make liquid objects at all, or should the liquid objects be internally generated by the library, based on user-defined LiquidComponent objects?
In other words, should the game writer write Liquid objects or LiquidComponent objects?
Should Liquid really mean "mixture" (of one or more liquid components)?
What's a good terminology? Should we rename Liquid -> Mixture && LiquidComponent -> Liquid?
That's not entirely satisfactory....
Note that non-liquid objects can serve as liquid components, as in sugar-water or salt-water.
Obviously, the elements should be taught how to interact with one another, both when initially mixed, and when operated upon (when a mixture is drunk, poured, shaken, etc.). This would also involve counteracting each others action routines. So it would appear that components should define all the specific behavior, and that Liquid would be a class, defining general behavior of all liquids, and perhaps handling the mixing code and component interaction.
Should Liquid be a superclass of LiquidComponent?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> should the game writer write Liquid objects or LiquidComponent objects?
My idea was that the author codes components, and the module takes care of creating and destroying Liquids.
So a Liquid object can be a mixture, yes. I prefer the names Liquid and LiquidComponent, because I think they emphasize the fact that Liquids are game-world objects (they inherit from Thing), where as components are not game world objects (they can't be manipulated directly by the player.)
> Note that non-liquid objects can serve as liquid components
On her Liquid Modelling page, Emily Short uses the notion of "dry liquids," i.e. powders.
I guess we can use a similar approach.
(http://emshort.home.mindspring.com/liquids.html)
> So it would appear that components should define all the specific behavior,
> and that Liquid would be a class, defining general behavior of all liquids, and perhaps
> handling the mixing code and component interaction.
Yes!
> Should Liquid be a superclass of LiquidComponent?
Not at all; LiquidComponents should not inherit from Thing, as they're not game-world objects.
Also, while Liquid and LiquidComponent will share some descriptive properties (volume, weight, color, etc.), these properties will be implemented much differently in the two classes, and not share any common behaviour.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The question arises, what should the Liquid object encapsulate, and what should the LiquidComponent object encapsulate?
Should the user make liquid objects at all, or should the liquid objects be internally generated by the library, based on user-defined LiquidComponent objects?
In other words, should the game writer write Liquid objects or LiquidComponent objects?
Should Liquid really mean "mixture" (of one or more liquid components)?
What's a good terminology? Should we rename Liquid -> Mixture && LiquidComponent -> Liquid?
That's not entirely satisfactory....
Note that non-liquid objects can serve as liquid components, as in sugar-water or salt-water.
Obviously, the elements should be taught how to interact with one another, both when initially mixed, and when operated upon (when a mixture is drunk, poured, shaken, etc.). This would also involve counteracting each others action routines. So it would appear that components should define all the specific behavior, and that Liquid would be a class, defining general behavior of all liquids, and perhaps handling the mixing code and component interaction.
Should Liquid be a superclass of LiquidComponent?
> should the game writer write Liquid objects or LiquidComponent objects?
My idea was that the author codes components, and the module takes care of creating and destroying Liquids.
So a Liquid object can be a mixture, yes. I prefer the names Liquid and LiquidComponent, because I think they emphasize the fact that Liquids are game-world objects (they inherit from Thing), where as components are not game world objects (they can't be manipulated directly by the player.)
> Note that non-liquid objects can serve as liquid components
On her Liquid Modelling page, Emily Short uses the notion of "dry liquids," i.e. powders.
I guess we can use a similar approach.
(http://emshort.home.mindspring.com/liquids.html)
> So it would appear that components should define all the specific behavior,
> and that Liquid would be a class, defining general behavior of all liquids, and perhaps
> handling the mixing code and component interaction.
Yes!
> Should Liquid be a superclass of LiquidComponent?
Not at all; LiquidComponents should not inherit from Thing, as they're not game-world objects.
Also, while Liquid and LiquidComponent will share some descriptive properties (volume, weight, color, etc.), these properties will be implemented much differently in the two classes, and not share any common behaviour.