|
Rule Generation |
Rule Generation It's a good idea to write rules to cover every possible combination of inputs. This is easily done if you can use some OR statements, but remember the FFLL API doesn't recognize them. That means you have to write out one rule for every set of possible inputs. If you don't and your system encounters a set of inputs that it has no rule for, it won't know what to output. You might actually not care about those set of inputs and adopt a "steady as she goes" type of response to those inputs without rules. It's up to you really. For my project, I decided to cover all the bases and write rules for every single possible set of inputs. For any output, the number of rules needed can be found by multiplying together the number of membership sets for all your inputs for that output. Clearly, in my case, the largest number of rules would come from the Desired_Position output. The total number would be 7*3*3*4 = 252 rules. I recognized though, that I would want similar responses no matter what values some of the inputs had. For example, I'd want the defenseman to react to a breakaway the same way in the first period as he would in the second period. So, a lot of the rules would have the same outputs. At this point, you might be wondering if there's some unnecessary complexity in my system. I won't argue that, I could have just made Game_Time with just two membership sets, Not_End_Game and End_Game and reduced the number of rules. I left it in though, because I wanted to some room to play with just in case I wanted the defenseman to react differently in different periods. The way I have it, I only need to change the rules in the .fcl file and not a single line of application code. So, I still had the problem of writing 252 rules and I sure wasn't going to do that by hand. To help me, I wrote a small helper program that would partially automate the process of writing the rules. My rulegen program can hold certain variables steady at a particular value and then generate rules by iterating through the values for the other variables. The output goes to a text file which you can just cut and paste into your .fcl file. By doing this, I was able to write 252 rules in less than ten minutes. Since the output Velocity has only one input with seven membership sets, it only requires seven rules in its .fcl file. In the end, I decided my project would have two defenseman displayed on the ice at the same time. Each would have the same rules for Velocity, but I wanted different positioning behaviour. One defenseman is a "stay at home" type who is more conservative with his positioning. The other defenseman is more aggressive on the puck and is not afraid to join the offensive rush. You can see these differences in their respective .fcl files for position. I also wanted the end of the game to have extra meaning. To accomplish this, I wrote rules for end game situations where the defenseman's team is either winning or losing. If they are losing, both defenseman adopt an aggressive, offensive positional attitude. They pinch in and stay close on the puck. If they are winning, they'll adopt a really defensive attitude. They'll retreat to their own end much more quickly and only rush up ice if their team has the puck deep in the opponent's end. Here are the .fcl files that define the variables and rules, you can view them using a simple text editor: |