tag:blogger.com,1999:blog-27876765.post4456263105260625950..comments2024-03-20T13:37:39.909+01:00Comments on Day to day stuff: Don’t call your state ‘state’Erik van Oostenhttp://www.blogger.com/profile/15976519439979651010noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-27876765.post-59082353413991447132016-03-04T07:09:16.894+01:002016-03-04T07:09:16.894+01:00The point of the article is:
* you can have multip...The point of the article is:<br />* you can have multiple states in your data model<br />* you should name them properly (literally, just don't call it 'state').<br /><br />In your example call them for example movingBy, health and firingWith.<br /><br />You can still group several states together to make state tables possible. They can also help with preventing invalid combinations (e.g. sleeping and firing).<br /><br />'Mutual exclusion' is indeed required, but it is not a good tool to help you model your data. The states of our initial conversation model were also mutually exclusive.Erik van Oostenhttps://www.blogger.com/profile/15976519439979651010noreply@blogger.comtag:blogger.com,1999:blog-27876765.post-72606943515598806042016-03-03T21:41:51.615+01:002016-03-03T21:41:51.615+01:00The problem with having multiple variables instead...The problem with having multiple variables instead of a state variable, means that you can't do state transitions with a state table. States should only be used when they are mutually exclusive (ie a game character may be running, fighting, dying) don't use the state for something that can be independent. Say you have a firing state, then that may be better as a flag, which can be set even if he is running or fighting.nhardinghttps://www.blogger.com/profile/10316489636559586522noreply@blogger.com