Hi, @DaBultz . Sorry for contacting you here. I couldn't find your contact details anywhere. I saw a deprecated package of yours on npm and I was wondering whether you might consider gifting it to me. I'd like to rename a project of mine and I like that name. If you could consider, all my contact details are in my profile. Thank you.

Problem

CGO is used to compile the Go code into a C Library, there seem to be a a considerable overhead¹, there are many calls going to go

Specifically these are the calls which call the go code

• env.setup() - called 1
• env.reset() - called 1 per game
• env.step() - called 1 per turn
• env.render() - called 1 per turn
• env_done() - called 1 per turn

The 3 functions, We are mainly intrested in to optimize is the step, render and env_done functions.

Solutions

Render

If we could implement the render in python, we would save 1 call. This already possible as the environments contain the information needed (cached from step)

To create the rendere something like Textualize could be utilized, this would also allow us to show multiple games at once, once vectorization is added.

env_done

we can implement this in python as well, since this can be be using the cached response from the go environment.

The code below is what is returned of the step function and is cached in the enviorment:

Step

This is the only function we can't move out of go, it might not be worth optimizing this code a lot, because vectorization (running multiple environments at once) would speed up training.

That being said, it will be worth comparing these 2 libraries :

• CTypes
• CFFI

As any substantial performance increase, would help speed up training and even more when vectorization is utilized

References

This issue will last all of the current future plans, this will be fledged out in the future.

• #13
• #14
• #15
• #16
• #17
• #18
• Utilities (will be added overtime)
• Publish to PyPi

If there's any wishes, feel free to open a new issue.

The following improvements is planned:

Automation

The environment documentation can be automated, as they all follow the same structure.

Custom Environment

Right now there's no documentation in how to add custom environments, this is supported already but lacks documentation.

The Battlesnake team added support for custom maps to be written for the CLI, the environment should have support for those environments as well.

https://blog.battlesnake.com/build-your-own-battlesnake-maps/

Examples were removed in the last commit, examples would need to be added back.

The examples should be real world examples, this would mean:

• Simple DQN Model without ray
• Simple Model using ray

Ray provides a set of libraries, frameworks to make training AI Models easier and less of an hassle. it would add support for vectorization, easy saving of models, testing various of models, parallelizing training and more.

See more: https://docs.ray.io/en/latest/

Hi, would it be possible to update this repo to use the most recent version of PettingZoo? We want to list this project in PettingZoo's third-party-environments, but we can only include environments which work with the current version.

If you need any help working out issues due to different versions feel free to ask, there were some breaking changes in version 1.2, so it requires a bit of code changes to adapt. The previous API returned done in the step() function, whereas the new one returns truncated and terminated (matching gymnasium). There is a migration guide for gymnasium explaining the changes further, the steps should be basically the same (we're working on making resources for updating old PettingZoo repositories as well): https://gymnasium.farama.org/content/migration-guide/

Running test.py:

from pz_battlesnake.env import standard_v0

env = standard_v0.env()

for _ in range(1):
  env.reset()
  done = False
  alive_agents = env.agents.copy()

  while not done:
      env.render()

      for agent in alive_agents:

          obs, rewards, _done, info = env.last()

          if _done:
              env.step(None)
              alive_agents.remove(agent)
              continue

          action = "up"
          env.step(action)

      if len(alive_agents) <= 1:
          done = True

Clearly in the example below, agent_3 should not be printed from turn 2 onward. The expected behaviour (like in the official rules cli) is that dead snakes are not displayed. The dead snake if not still in the json api object luckily, so this shouldn't be extremely hard to fix.

docker run -v $(pwd):/project/pz-battlesnake  dabultz/pz_battlesnake python /project/pz-battlesnake/example/test.py
2022/06/26 21:01:07 Ruleset: standard, Seed: 1656277267676684699, Turn: 0
Hazards ░: []
Food ⚕: [{0 4} {6 0} {10 6} {6 10} {5 5}]
agent_0 ■: {agent_0 [{1 5} {1 5} {1 5}] 100  0 }
agent_1 ⌀: {agent_1 [{5 1} {5 1} {5 1}] 100  0 }
agent_2 ●: {agent_2 [{9 5} {9 5} {9 5}] 100  0 }
agent_3 ☻: {agent_3 [{5 9} {5 9} {5 9}] 100  0 }
◦◦◦◦◦◦⚕◦◦◦◦
◦◦◦◦◦☻◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦⚕
◦■◦◦◦⚕◦◦◦●◦
⚕◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦◦⚕◦◦◦◦
2022/06/26 21:01:07 Ruleset: standard, Seed: 1656277267676684699, Turn: 1
Hazards ░: []
Food ⚕: [{0 4} {6 0} {10 6} {6 10} {5 5} {7 10}]
agent_0 ■: {agent_0 [{1 6} {1 5} {1 5}] 99  0 }
agent_1 ⌀: {agent_1 [{5 2} {5 1} {5 1}] 99  0 }
agent_2 ●: {agent_2 [{9 6} {9 5} {9 5}] 99  0 }
agent_3 ☻: {agent_3 [{5 10} {5 9} {5 9}] 99  0 }
◦◦◦◦◦☻⚕⚕◦◦◦
◦◦◦◦◦☻◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦■◦◦◦◦◦◦◦●⚕
◦■◦◦◦⚕◦◦◦●◦
⚕◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦◦⚕◦◦◦◦
2022/06/26 21:01:07 Ruleset: standard, Seed: 1656277267676684699, Turn: 2
Hazards ░: []
Food ⚕: [{0 4} {6 0} {10 6} {6 10} {5 5} {7 10}]
agent_0 ■: {agent_0 [{1 7} {1 6} {1 5}] 98  0 }
agent_1 ⌀: {agent_1 [{5 3} {5 2} {5 1}] 98  0 }
agent_2 ●: {agent_2 [{9 7} {9 6} {9 5}] 98  0 }
agent_3 ☻: {agent_3 [{5 11} {5 10} {5 9}] 98 wall-collision 0 }
◦◦◦◦◦☻⚕⚕◦◦◦
◦◦◦◦◦☻◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦■◦◦◦◦◦◦◦●◦
◦■◦◦◦◦◦◦◦●⚕
◦■◦◦◦⚕◦◦◦●◦
⚕◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦◦⚕◦◦◦◦
2022/06/26 21:01:07 Ruleset: standard, Seed: 1656277267676684699, Turn: 3
Hazards ░: []
Food ⚕: [{0 4} {6 0} {10 6} {6 10} {5 5} {7 10}]
agent_0 ■: {agent_0 [{1 8} {1 7} {1 6}] 97  0 }
agent_1 ⌀: {agent_1 [{5 4} {5 3} {5 2}] 97  0 }
agent_2 ●: {agent_2 [{9 8} {9 7} {9 6}] 97  0 }
agent_3 ☻: {agent_3 [{5 11} {5 10} {5 9}] 98 wall-collision 0 }
◦◦◦◦◦☻⚕⚕◦◦◦
◦◦◦◦◦☻◦◦◦◦◦
◦■◦◦◦◦◦◦◦●◦
◦■◦◦◦◦◦◦◦●◦
◦■◦◦◦◦◦◦◦●⚕
◦◦◦◦◦⚕◦◦◦◦◦
⚕◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦⌀◦◦◦◦◦
◦◦◦◦◦◦◦◦◦◦◦
◦◦◦◦◦◦⚕◦◦◦◦

The printMap() & render() functions are extremely similar so it might be a good idea to simply call printMap() from pz-battlesnake instead of re-implementing it. The useColor option should be passed through in the gamestate instead of function arguments.

Tests would allow us to keep the project in a good quality while making sure that changes doesn't break and would also inform of breaking changes.

PettingZoo has environment testing built-in, https://www.pettingzoo.ml/environment_creation#tests

CGO is used to compile the Go code into a C Library, there seem to be a a considerable overhead¹, speeding this up would allow for faster training.

Below there are 2 solutions to the problem

Solution 1: WASM (BEST)

WASM would allow the code to run at much faster speeds (in theory), but might be harder to implement.

Solution 2: Decrease C call overhead

We can also decrease the call overhead, by reducing the amount of calls going to the go code and compare CTypes and CFFI

Benchmarking

To know if the solutions provide any substational benefit, benchmark would have to be ran. Luckily PettingZoo have this built-in: https://www.pettingzoo.ml/environment_creation#tests

References