The problem with greedy choosing was that it often chose stupidly. As stated before, the problem was in the landing contours. However, the problem turned out to be forgetting to assign a private variable to the latest contour field. So every time, the contour field evaluated on was {0,0,0,…}. Should be fixed and I will check it out in the lab today.
EDIT: Checked it out in the lab and that was the problem. Next up is putting in the code for the evaluation function.
Added in some evaluation function tests that have helped shape the design of the initial evaluation function but some tests may be tricky to pinpoint, as sometimes, there is no clear difference between 2 moves. Both the evaluate field method and evalFunctionAction methods have been tested, but contain no code yet. Will be filled in later (probably later today).
Also, added a new member variable to keep track of the raw data of the field. This variable is initialised every time contourField is called at no extra cost and it only includes the field data; no falling piece, no piece type, no dimensions.
The evaluation function looks like this at the moment:
A field’s worth is calculated by:
– Highest block (where 0 is an empty field)
– Number of holes * 2 (This is every hole that has a block above it, including blocks several units above. So a sealed off chasm is likely to have several holes under it.)
– Bumpiness. Calculated by summing the absolute contour field.
– Number of lines removed by placing piece * -2 (Note the negative to make it more desirable)
– Number of chasms (gaps ideal for I-pieces only)
The last one I may take out or decrease. The sum of those factors is the worth, where a lower score is more desirable. So a worth of 0 is an empty field. A worth of 20 is not a great field.
The evaluation function simply evaluates the piece at every position and chooses the best worth one. Bias towards making lines if a tiebreaker is probably necessary.