3 ms·

-complete game state should be compactly represented, ultimately it will need to be in a form that can be inputted to an NN - player actions should be enumerab

-complete game state should be compactly represented, ultimately it will need to be in a form that can be inputted to an NN - player actions should be enumerable (if there are discrete actions) - score is reward, it should be easy to access directly - game will be much easier to learn of there are shorter goals with more score feedback. long puzzles with very sparse reward is still challenging for RL

keerthiko 8y ago
Funnily enough, our game has these properties as part of its core game design, independent of the AI-friendly aspirations. It's a puzzle-based anti-grav racing game where you try to complete N laps in the fastest time possible. When I was playtesting it I realized "huh there are only 2 buttons involved, the game state exists as a 2D bitmap + a few vectors we can serialize to disk, there are predefined deterministic victory parameters (times for medal) and the randomness is 0 outside of physics. This should be an ideal game for AI training." While I'm sure I miss some knowledge on optimizing the design, what I'm more interested in learning about are pointers to technical frameworks/API implementation details needed to be friendly to tools like TF/PyTorch for developers to train with the game.
- mooneater 8y ago
  Im working on a game RL framework for turn-based games, my aim was to learn about self-play and RL. I found if you structure the human controller in the exact same way as the AI controllers, you can swap them easily. So I have Agent (abstract), HumanAgent (takes keyboard input), and DqnAgent (DQN learning agent) as the different controllers, the rest of the code is agnostic to the controller. With this setup you can also do things like record your own gameplay. If your goal is running the track in minimal time, you could reward it at the end (reward = -1* elapsed_time), or as you go (reward=current_speed), or once each lap, etc. These sound similar but may have different training properties. So maybe plan to explore your reward shaping space a bit.

keerthiko 8y ago

Funnily enough, our game has these properties as part of its core game design, independent of the AI-friendly aspirations. It's a puzzle-based anti-grav racing game where you try to complete N laps in the fastest time possible. When I was playtesting it I realized "huh there are only 2 buttons involved, the game state exists as a 2D bitmap + a few vectors we can serialize to disk, there are predefined deterministic victory parameters (times for medal) and the randomness is 0 outside of physics. This should be an ideal game for AI training." While I'm sure I miss some knowledge on optimizing the design, what I'm more interested in learning about are pointers to technical frameworks/API implementation details needed to be friendly to tools like TF/PyTorch for developers to train with the game.

mooneater 8y ago
Im working on a game RL framework for turn-based games, my aim was to learn about self-play and RL. I found if you structure the human controller in the exact same way as the AI controllers, you can swap them easily. So I have Agent (abstract), HumanAgent (takes keyboard input), and DqnAgent (DQN learning agent) as the different controllers, the rest of the code is agnostic to the controller. With this setup you can also do things like record your own gameplay. If your goal is running the track in minimal time, you could reward it at the end (reward = -1* elapsed_time), or as you go (reward=current_speed), or once each lap, etc. These sound similar but may have different training properties. So maybe plan to explore your reward shaping space a bit.