Não fique muito envolvido com o padrão de estado. Isto tem um uso específico que eu não acho que necessariamente se aplica ao seu jogo, pelo menos não quando você está manipulando o estado do jogo.
Tome, por exemplo, um aplicativo de desenho. Neste caso, o botão pressionado na barra de ferramentas afeta a maneira como o painel de desenho reage a certos estímulos - neste caso, você não quer que o aplicativo saiba o que ele vai fazer, você apenas quer que ele passe o estímulo. para o objeto State e deixe-o descobrir o que fazer.
Assim, o botão de desenho do retângulo está inativo, o aplicativo contém um RectangleDrawingState do qual ele pode solicitar um tipo de ponteiro com o mouse ou uma ação do mouse ou qualquer outra coisa. Se você pressionar o botão elipse-drawing, então o controle muda o RectangleDrawingState para um ElipseDrawingState e o aplicativo continua a pedir um tipo de ponteiro com o mouse e uma ação do mouse e obtém respostas completamente diferentes.
Este é o tipo de situação que faz um bom caso de uso para o Padrão de Estado.
Agora você pode querer isso em seu jogo de estratégia por turnos, para saber se o botão de ataque está pressionado ou se o botão reunir recursos está pressionado. Mas você deve lidar com o estado do jogo de maneira diferente.
O estado do jogo deve ser tratado como um único objeto mutável, que é manipulado no final de cada ação. Este objeto precisa ser serializável de alguma forma.
O que você deve fazer é obter um objeto Command por qualquer meio necessário e agir sobre o objeto mutável state-of-play (pode ser que seu objeto State imutável, que depende da ação selecionada a qualquer momento, retorne um comando que pode atuar no objeto state-of-play, por exemplo).