# I think it's possible to architecture around this. For example, here is one idea: - make the game as functional as possible: as in the game state is stored i

# I think it's possible to architecture around this. For example, here is one idea: - make the game as functional as possible: as in the game state is stored in a serializable format. New game states are generated by combining the current game state with events (like player input, clock ticks, etc) - the serialized game state is much more accessible to the AI because it is in the same language AI speaks: text. AI can also simulate the game by sending synthetic events (player inputs, clock ticks, etc) - the functional serialized game architecture is also great for unit testing: a text-based game state + text-based synthetic events results in another text-based game state. Exactly what you want for unit tests. (Don't even need any mocks or harnesses!) - the final step is rendering this game state. The part that AI has trouble with is saved for the very end. You probably want to verify the rendering and play-testing manually, but AI has been getting pretty decent at analyzing images (screenshots/renders). # Here is an example of a simple game developed with functional architecture: https://github.com/Leftium/tictactoe/blob/main/src/index.ts https://github.com/Leftium/tictactoe/blob/main/src/index.ts - Yes, it's very simple but the same concepts will apply to more complex games - Right now, there is only rendering to the terminal, but you could imagine other renders for the browser and game engines