
- End-games (both sides having several pawns):
pawn endgames: consider outside passed pawns search and eval.
rook end games: active rook and outside passed pawn in search and eval.
Consider adding OPP for other end-games as well. Maybe when each side has one same piece, think about others too.
- King safety: change kingzone. It should contain two zones. zone 1: squares adjacent to king, zone2: squares which contain and are adjacent to zone1 . So if K is on g8 zone1 is f8 f7g7 h7 h8, zone2: e8 e7 e6 f6 g6 h6. Change related stuff accordingly. Intuitively zone1 attacks score higher than zone2. Then combine for final score.
In general I assume king safety has potential for a lot of improvements.
- Smooth eval: in addition to other tests, use initial test on (huge) set of positions with no deep tactics.Search for a few plies and compare produced eval to pre-computed reference evals. Modify untuned parameter values accordingly using genetic algorithm or other techniques and produce several candidates. Afterwards test them in actual matches. Use this for every new eval term as well. Just note that you may tune key parameter values say max value of an array; use a suitable function (linear, logarithmic,...) for dependent values. Hopefully this would reduce some useless computations. In any event the eval is expected to change smoothly when engine plays.
- Run-time data: data gathered from search and eval placed to allocated memory tables for run-time consumption. For example consider a knight on c3. In cases that it moves (you may keep a record of its moves in the search tree) it goes to e4 in 70% of cases, to a4 in 20% and to e2 on 10%. Suppose we have a parameter Knight_Mobility_Value_In_RunTime set to 10 centi pawns. In next iteration of search it is given values as 7cp for e4, 2cp for a4, 1cp for e2 for the knight in its run-time eval table. The values are to be recomputed after each iteration.
In short I suppose this run-time data area has a lot of room for improvements with many different ideas.