We are going to be building an asymmetric game. This will be a turn based game, not unlike chess in many ways
The game will be played on a finite hexagonal board, at a human scale (like width of 8 or 10 or so)
Pieces will "facing" in one direction, types which will generally not change during the game. and move in ways that are human comprehensible. They may be able to move a limited number of spaces.  
Pieces will usually "take" each-other by moving into an enemy occupied space
There will be a number of different piece types, with different starting numbers on the board, and different movement patterns
Each player will have a king-like piece that represents the victory condition
The two players (black and white)  may have some overlap in piece types, but they will have different pieces to start with and different numbers
There may be some pieces with distinctly un-chess like moves. For instance a piece that may swap with a friendly piece anywhere on the board, or a piece that can be returned next to the board from the graveyard to be placed next to the king as a move. 
The game must have a condition that causes one side to win automatically after a large number of turns. (this prevents looping.. just means one side will win) 
Players (black and white) might have different numbers and types of moves. These should be very low (1,2,or 3) and might be typed or restricted (rotate one piece and move one piece) or (move or rotate two pieces... but they may not be the same piece)

Once the game is designed in broad strokes a written document explaining the rules in detail must be written. 

Then we need to build a game engine with no visual front end. It should allow players to attach via API. It should detect wins, prevent cheating, and be very memory efficient. It should also be tuned so that basic rules (starting piece count, positions, etc) can be changed as pretty trivial variable changes. 

We are then going to write a MinMax game playing engine to play the game. This needs to have a core engine that knows valid moves, and then be able to to take various parameters (like how many points each piece type should be worth as a heuristic, and how deep it should go) We might also need some sort of special endgame engine. 


So here is fundamentally what we are trying to do is make this symmetric game human playable, in a way where better players (those who play to a deeper depth) will reliably win, whichever side they get. This is non-trivial because the sides are going to be *drastically* different. 

The plan is: 
1) generate a set of rules with some novel pieces etc, 
2) Make wild guesses / randomly seed heuristic piece values. Make several sets. (we can call these heuristic sets) 
3) Play off different heuristic sets at reasonably shallow depth of play (4?) as an evolutionary algorithm (introducing variations, walking towards . Find a strong Heuristic set, and use that as the default, it need not be perfect and we don't need to play games to termination. We are mostly looking for Heuristics where the side that was winning starts winning even more after 10-20 moves. 
4) Take that heuristic set and use that to generate a several approximately "balanced" versions of the game (starting piece counts and positions) a version of the game will be called a "rule set"
5) We are going to run the evolutionary algo on the rule-sets. "fitness" is determined as follows: a game is played between two MinMax algos using the current best heuristic set. One of the two is set to a higher depth than the other. The one with the higher depth should win. We want to cover a wide range of matchups (d1 v d2, d1 v d3, d2 v d3, d3 v d5, etc) and we want to make sure that we run each matchup with the deeper view siting in both seats (black & white). "fitness" score is based on how often the deeper view wins, particularly when it is much deeper. Additionally, when we do have instances where the deeper view does *not* win, it is more acceptable if that edge sometimes goes to white vs sometimes going to black. 
Matches should be re-played with a little bit of randomization in the minmax algo for "tied" or near-tied moves by heuristics

We will alter the rule set by adding or removing pieces to try to get the balance right. 
Periodically we should revisit the huristic-set and tune it. 

This software should be written to run on a multi-threaded environment. No LLM calls should be in the core loops. 
There should be some profiling and tuning to maximize speed and manage memory. 
The system should be susspendable and resumable. 
The system should show progress, as well as current results of the best scoring game varient in a human readable format, as well as time run. There should be a log that shows current best version of the game and how each of the depth matchups work out.