You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add actions, failed actions, and collisions to saved game state. #123
changed the title [-]Add actions, failed actions, and collisions too saved game state.[/-][+]Add actions, failed actions, and collisions to saved game state.[/+]on Jul 31, 2018
Yes, let's do that. I had actually already made this change in the research we had been doing (that led to Backplay).
@suphoff , it seems like you had another motive for this re recording actions. Does that mean you have already made the change along with that extra recording?
S(t+1) = forward.model.step ( S(t) x A(t) ) .... well the current recording of the states in json.
My main reason is that just recording all the states S(0) .. S(T) does not really describe what actually happened in a game. (Example: Agent A actively colliding with Agent B to prevent a move in contrast to both Agents just not moving). ( For a given states S(t), S(t+1) the set of Actions A(t) : S(t+1) = forward.model.step ( S(t) x A(t) ) may have multiple members ).
The recorded action could be used for improving visualization of a recorded game (showing collisions, failed kicks ...) using an enhanced step function or actions could just be displayed (as arrows) in a state transition animation.
It could also be used to replay a game with a new or changed step functions and verify that the resulting states are as expected. (A nice and easy code regression test)
Ok, so just to clarify, would it be sufficient to additionally record the
action requested at every step by each agent? We could additionally record
the action actually taken.
On Thu, Aug 9, 2018 at 16:36 Stephan Uphoff ***@***.***> wrote:
State as in:
- S(t+1) = forward.model.step ( S(t) x A(t) ) .... well the current
recording of the states in json.
My main reason is that just recording all the states S(0) .. S(T) does not
really describe what actually happened in a game. (Example: Agent A
actively colliding with Agent B to prevent a move in contrast to both
Agents just not moving). ( For a given states S(t), S(t+1) the set of
Actions A(t) : S(t+1) = forward.model.step ( S(t) x A(t) ) may have
multiple members ).
The recorded action could be used for improving visualization of a
recorded game (showing collisions, failed kicks ...) using an enhanced step
function or actions could just be displayed (as arrows) in a state
transition animation.
It could also be used to replay a game with a new or changed step
functions and verify that the resulting states are as expected. (A nice and
easy code regression test)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAljt6-e5FBFToUWIdPFnmwH5ty2aXB3ks5uPJ1ogaJpZM4VpcsE>
.
I believe the action requested is all that is needed.
( If anyone really needs the action taken it can be easily extracted from state changes (unless the agent is dead in the next state) or calculated from start state and requested actions)
On Fri, Aug 10, 2018 at 10:53 AM Stephan Uphoff ***@***.***> wrote:
I believe the action requested is all that is needed.
( If anyone really needs the action taken it can be easily extracted from
state changes (unless the agent is dead in the next state) or calculated
from start state and requested actions)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAljt3JLUyYrCjadElycfiMOIDqXIXmUks5uPZ5ogaJpZM4VpcsE>
.
On second thought - for human players we definitely need to render before asking for actions.
So unless save_json is split out from render in the environment we can only report the previous actions.
... and actions can be reordered anyway as part of processing the game file without changes in the env api. @cinjon : Happy with the current solution.
Activity
[-]Add actions, failed actions, and collisions too saved game state.[/-][+]Add actions, failed actions, and collisions to saved game state.[/+]suphoff commentedon Aug 4, 2018
I propose reversing the order of the calls to env.render() and env.act() in run_battle.run._run().
This way env.act could just stash the last actions in the environment for env.render to display/store as json, ...
With actions and states recorded everything else (Failed actions, and collisions ..) can be deterministically determined.
cinjon commentedon Aug 5, 2018
Yes, let's do that. I had actually already made this change in the research we had been doing (that led to Backplay).
@suphoff , it seems like you had another motive for this re recording actions. Does that mean you have already made the change along with that extra recording?
suphoff commentedon Aug 5, 2018
@cinjon - Don't have any code (and very happy not to have to write any) - was just planning ahead to prevent pipeline stalls.
suphoff commentedon Aug 8, 2018
@cinjon : Any chance you can cherry pick those changes from your research branch?
Do you also have code to compare two states (for #108 )?
cinjon commentedon Aug 9, 2018
I'm actually a little confused now. Is it the case that in totality you just want the actions recorded along with the game state?
cinjon commentedon Aug 9, 2018
And what do you mean wrt code to compare two states? Is a "state" here the info in a game state file?
suphoff commentedon Aug 9, 2018
State as in:
My main reason is that just recording all the states S(0) .. S(T) does not really describe what actually happened in a game. (Example: Agent A actively colliding with Agent B to prevent a move in contrast to both Agents just not moving). ( For a given states S(t), S(t+1) the set of Actions A(t) : S(t+1) = forward.model.step ( S(t) x A(t) ) may have multiple members ).
The recorded action could be used for improving visualization of a recorded game (showing collisions, failed kicks ...) using an enhanced step function or actions could just be displayed (as arrows) in a state transition animation.
It could also be used to replay a game with a new or changed step functions and verify that the resulting states are as expected. (A nice and easy code regression test)
cinjon commentedon Aug 10, 2018
suphoff commentedon Aug 10, 2018
I believe the action requested is all that is needed.
( If anyone really needs the action taken it can be easily extracted from state changes (unless the agent is dead in the next state) or calculated from start state and requested actions)
cinjon commentedon Aug 14, 2018
cinjon commentedon Aug 15, 2018
0017eef should handle the issue by including an "intended_actions" in the json. Let me know if this is insufficient.
suphoff commentedon Aug 15, 2018
It is sufficient - however would it not be nicer to group S(T) with A(T) instead of S(T+1) with A(T) ?
suphoff commentedon Aug 16, 2018
On second thought - for human players we definitely need to render before asking for actions.
So unless save_json is split out from render in the environment we can only report the previous actions.
... and actions can be reordered anyway as part of processing the game file without changes in the env api.
@cinjon : Happy with the current solution.