Author: HanishKVC Version: 20221208IST1607 License: GPL-3.0+
Allow controlled playback and look at captued game play data like from robocup soccer simulator 2d. Also allow connecting to a live server to get and display live game play data like from rcssserver.
Additionally allow augumenting of displayed player movements playback with info captured manually or automatically (during the game or later). This can include
- game actions captured like goal, kick/tackle/..., penalty/cards, ...
- inturn try infer
- good / bad passes (using a minimal logic),
- good / bad (self) goals (including chain of actions leading to it)
- virtual ball (if required)
- performance scoring based on infered/otherwise game actions
- ball possession wrt both sides
- inturn try infer
- color coding, graphs, etal of
- performance from captured game actions.
- coarse grained view of captured/tracked health params like stamina, ...
- overlapping of past games data wrt movements/actions/performance in useful ways.
To playback the contents of the rcg file generated by robocup soccer sim 2d server
--mode rcg --src <path/file>
This sets the mode and specifies the rcss rcg file as mentioned above.
--mode rclive [--src <nw address>]
This runs the program as a simple and minimal robocup soccer sim monitor. It can be used to watch a game live as well as kick-start(kick-off) wrt the 2 halfs+ if & when needed.
If the --src argument is specified, it will be used as the address of the robocup server to connect to. Else it will try to connect to the server on port 6000 on the local machine.
NOTE1: Ideally one needs to start rcss server first, before starting this program, this will ensure tha tthe initial init handshake that is sent when this program is started, to the server, will succeed. However if one starts the rcss server after this program, then one can use key seq c-0 to initiate the initial handshake.
NOTE2: One can use c-1 key sequence to kick-off the 2 halfs wrt and also as needed by rcss.
NOTE: Also do note that when ever the init handshake is successful, and the server sends out a message to this program, it switchs the server address to point to the address(including port) from which the message was recieved. From then on this program cant connect to a freshly/newly started server, as the internally stored server address has changed. So If one wants to connect to new rc server again, after a previous successful handshake + msg, one needs to quit this program and start it fresh again.
--save_interval <OnceEvery???Frames>
This makes the program save raw prg screen dump files into /tmp folder. As this is raw currently, it will eat up the disk space, so be aware and careful.
--fps <The.Fps>
Current flow, overrides this with the fps suggested by playdata source.
--virtball <path/virtball.csv>
VirtBall.CSV should be a csv file containing a series of records, consisting of time stamp/counter, ball x, ball y. Inturn the logic will show a virtual ball, by interpolating where required.
The program auto saves a virtball.csv file into /tmp folder, based on the game actions it encounters.
When the program is running, one can use the following keys (including sequences) to control the behaviour as noted below.
p -> to pause/unpause the playback
h -> to hide/unhide the help msg box
s -> enter set-show/hide-mode
- s -> to show/hide the display of stamina
- a -> to show/hide the display of actions
- b -> to show/hide the ball
- c -> to show/hide the card issued to player
- d -> to show/hide player view direction
- any other key -> exit set-show/hide-mode
Seeking
- right arrow key -> to seek/jump forward
- NOTE: Any messages in the skipped records, wont be shown.
- left arrow key -> to seek/jump backward
- NOTE: The messages shown dont get reverted back wrt time.
- NOTE: Seeking back after reaching end, will bring back the source to be alive.
- NOTE: This does mess with action sequence cross-check/analysis logics
and can inturn lead to messed up scoring++ and or worst case crashing
of program currently, as seeking can lead to illogical sequence of
events to been seen in a simple minded flow. Code may be updated in
future to be more forgiving and thus support seeking without crashing,
but analysis results could/would be still messed, unless even more
effort is put in the logic.
- seeking back wont crash, but the anal/infering flows and inturn scoring/graph etal will be messed up, bcas the logic wont take back / undo what it has already given.
- seeking forward can crash in some cases currently. As for anal/infer flows, it will be messed up, as we jump over rather than run through the skipped records.
- right arrow key -> to seek/jump forward
FPS - frames per second
- f -> to reduce the current fps
- F -> to increase the current fps
NOTE: This helps change the rate of playback in the default one record per frame mode. However in the interpolated movement mode, changing fps, doesnt allow one to change the rate of playback.
b -> to change the background color
c -> enter send-record-coded-mode
If working in RobocupSoccerSim monitor live mode, then
- 0 -> send the initial handshake (dispinit) command to the server
- 1 -> send the kick-off (dispstart) command to the server.
- any other key -> exit send-record-coded-mode
d -> enters internal-debug_explore-mode
- e -> to dump current data associated with entities in the playground
- ie players, ball, msgs, actions info, ...
- a -> to show ActionsInfo relative perf summary based on best team local performance.
- A -> to show ActionsInfo relative perf summary based on best perf across both teams.
- NOTE: Pressing <a> when already in <a> mode, clears it. Same with <A>. However pressing <a> when in <A> or otherway, changes the summary type.
- d -> to show ActionsInfo relative distance traversed summary based on most distance traversed wrt own team players.
- D -> to show ActionsInfo relative distance traversed summary based on most distance traversed across both teams.
- c -> toggle whether to include penalty card based scoring in ActionsInfo relative perf summary graphics.
- t -> to show ActionsInfo time vs perf plot wrt all players, scaled relative to best and worst player perf score in the team.
- T -> to show ActionsInfo time vs perf plot wrt all players, scaled relative to best and worst player perf score across both the teams.
- any other key -> exit internal-debug_explore-mode
- e -> to dump current data associated with entities in the playground
One can see the following messages on the screen in addition to the player movements.
- the score, at the top left
- the game time as represented by the playdata source, at the top mid
- game related messages in the play data, at the bottom left.
- any unknown/unhandled messages in the play data, at the bottom mid
- curently active starting key in multikey cmds and set+actual fps, at the top right
- ball possession of both sides on the top towards to the center.
The following geometric characteristics wrt the player could be used to map to different player performance and or other characteristics
color and its shading of the player
colors of the 4 outerlines around the player, Currently * both vertical lines are mapped to player stamina by default
good stamina is green, in between is yellow and low is red
- both (top and bottom) horizontal lines are mapped to any card issued to player, for now.
color and arc length of the arc around the player Currently it is mapped to actions like kick, tackle, catch
one can optionally add individually timed additional supported graphic primitives wrt each gentity (including players).
One can also super impose translucent graphs ++ on top of the playground. Which is currently used to show
- player relative performance scoring and distance traversed as bar graphs.
- players (of both sides) performance wrt/vs time, as overlapping cumulative line graphs, to help identify performance of individual players wrt game phases/time.
During a pass, if the recieving player foolishly or due to lack of experience /skills, fails to take the pass, currently the logic will only penalise the sender of the pass and not the failed reciever. Which in a way may be fine, in real world as the sender should know whether the receiver is capable or not, in a way to an extent !?! However wrt current robocup teams, I may have to look at position of ball and players and inturn penalise really nearby players, during a failed/bad pass to some extent ???
If there is no ball information along with game data, use game actions like kick, tackle, catch, etal to interpolate a virtual ball.
Use a two pass flow, where 1st capture the useful ball related game actions and inturn use it to visualise a virtual ball using interpolation.
When the playdata source indicates that the playback has reached the end, the logic will automatically capture the required actions related data, into a tmp file.
NOTE: The logic accounts for seeking in a crude way, currently, which should be ok to an extent.
Look at the chain of actions leading upto the goal and inturn reward players of the side which got the goal and penalise the otherside players in the chain a bit. The chain stops either when the specified time window before wrt goal is reached or a player (beyond a goalie triggered self goal) belonging to the otherside has intervened in the chain.
As the players of the otherside could not defend their side and stop the goal, so penalise them a bit. Currently goalie is penalised only if they arent able to hold on to a ball catch, and beyond the goalie self goal, only 1 player from the otherside is penalised. Maybe I need to penalise beyond 1, if we are still within the specified time window wrt goal and equally reward players from the goal taking side, who moved ball to reach till the point where the other side player intervened.
Look at git log in general, the below captures things only sometimes.
Patched the latest external release wrt below and inturn rebased the currently internal exploration on top of the same
- fixing Rcg helper to support non hex state info and stamina record at almost any position within the player record.
- add support for opting out of WM_PING mechanism in sdl helper
- consume all events before handling the playback and related logic
Infer passes and their success or failure and inturn score the same. Also track the distance moved/traversed by players. Allow comparing these wrt best in same team as well as across both teams.
Add support for tagged commandline arguments.
Virtual ball, if required.
Infer goal as a good or a self goal and identify the player responsible for same
Timed messages box for user config change at runtime
Update the handle action logic to check thro all possible prev and cur action sequence possibilities, to a greater extent, with the new flow, in a explicit manner.
Account for -ve scores, wrt the relative perf bars based graphical score summary logic.
Determine program window resolution dynamically at runtime based on screen res.
Use generic summary relative calc type identification chars T(eam) & A(ll)
Try identify the chain/sequence of actions leading to a goal, and inturn reward the involved players of the successful goal side. And penalise 1 or 2 players from the otherside who are in the goal chain nearer to the goal action.
Optionally include penalty cards (yellow,red) in performance scoring shown.
Make seek back not crash wrt ActionsInfo.
Allow additional graphical primitives to be decorated/tacked on to the gentities, in a flexible way. Use same to show RCSS Ball2Player and Player2Ball states wrt players.
Remove old branches used for exploring and crystalising different ideas and inturn replace with tags to the tips of these old branches.
Plotting of Time vs Player Perf AScore (IndividualScoreChanges/Cumulative, Points/Lines) wrt individual player / full team / both teams, with controllable positioning.
- filtered plotting of time vs player perf graphs
Track and show ball posession.
RCLive extract game mode info and update pu.state.
Filter out duplicate goal action data.
Avoid low pass filtering of t vs s data before plotting.
Ignore unexpected message format messages from the rcssserver, for example wrt wrong initial handshake.
Show player's body, look(body+neck) direction along with view angle width.
Switch to using string based PlayerIds and inturn hashmap wrt players, rather than vectors, where vector index would have been playerid previously. So also avoid player id of 0, as well as map to RCSS's actual player ids.