Next version

design goals:

• clear separation into rules logic and user interface
  • was already a goal of the current GC when it was started in 2012
    • in comparison to the pre-2013 GC, this goal was actually achieved (i.e. actions do not need to directly update the UI anymore)
  • however, both are still tightly coupled through function calls
  • it would be good if the rules logic was a library/server/whatever that could be used by different software (e.g. simulators)
  • perhaps use the concept of microservices, and separate every piece as much as possible so it's pluggable and can be used by other leagues
    • networking to/from robots
    • networking to/from tcm
    • frontend with separate components (one-team vs two-team, penalties, settings, statuses, undo stack, etc.)
    • clock (wall clock or simulated clock)
• concepts that are close in the rules should be close in the code
  • this is not the case now
  • the class AdvancedData handles pretty much of the logic (probably too much)
    • besides that, the Log needs to know much about the internal structure of AdvancedData to be able to go back in time, which is not good
• testability
  • at least when considering the "undo" feature, manually testing every feature of the GameController is unfeasible, especially undoing multiple steps
• extensibility for future rule changes
  • obviously necessary, but very hard to achieve because noone can tell the future
• include the "active" part of the referees in the project (as a second "library" next to the "core logic")
  • B-Human's "autoreferee" (https://github.com/bhuman/BHumanCodeRelease/blob/master/Src/Controller/GameController.cpp) can automatically place robots and proceed game states (i.e. ready -> set when no robot moves, set -> playing after 5s, goals, free kicks)
    • it would be nice to be included, with some interface by which it gets the state of the world
  • advantage: there is a "reference implementation" of a referee which complements the rules
  • also opens the door for automatic referees based on ceiling cameras

other requirements:

• works cross-platform, including mobile
• what the GC sends to the robots must be "states", not "events", due to unreliable communication and robots being restarted during the game

ideas:

• GameController text logs

  • contain the list of actions
  • current main usage: converted to CSV by LogAnalyzer, which is then put into an Apple Numbers table by Thomas Röfer (which to my knowledge only exists on his computer) that creates the statistics PDF (https://spl.robocup.org/wp-content/uploads/2019/07/RoboCup2019Statistics.pdf)
  • the integration of statistics / transformation into a database could be done by software that is part of the GC distribution
  • see https://ssl.robocup.org/match-statistics/ for what the SSL has
  • replay feature, in case the GameController crashes or runs out of power (ran out of power 2019 German Open)
    • may also help when undoing, to instead replay all previous events
    • supporting startup scripts (which is basically the same as replaying an action log) aligns well with Issue 39

• GameController/TCM logs

  • can be a valuable source of data, e.g. for opponent behavior modeling
  • currently use Java Serialization, which impedes their usage from Python/whatever
  • Arne wrote Protobuf descriptions for the data stored in those logs + a java program which converts TCM logs to protobuf, but while we're at rewriting the GC altogether, it's of course a good idea to let the GC/TCM write protobuf (or whatever format is more suitable than Java Serialization) directly
    • Java is not a requirement for this application, so protobuf or flatbuffers may be better

• What kind of interface between core and UI?

  1. Core is a (C++?) library, exports its functionality via classes/whatever
  • simple, no overhead when calling from a C++ program
  • necessity to have interfacing code for Java/Python/web based frontend/whatever (might be eased by automatic wrapper generators)
  2. sockets
  • timing issues?
  • need to start a second process in the "simulator scenario"
  3. REST(like) API
  • seems to be used by SSL GameController
  • probably hard/impossible to handle non-real-time scenarios
  • preferred by Jayen as he's a web developer and believes modern frontends should be made for the web
  4. gRPC-Web
  • Would work well if gRPC (protocol buffers-based) is used for communication between the backend modules (microservices)
  • preferred by Jayen as he's a web developer and believes modern frontends should be made for the web

UX thoughts:

• start/resume from command line
• most keyboard shortcuts visible in interface
• f1/? help
• ctrl-z to undo, ctrl-shift-z to redo?
• manual override of score or time
• text-to-speech when action is taken or undone, or to notify side refs of upcoming unpenalty
• can press player before penalty
• mobile interface for testing robots by yourself
• change visuals at runtime (e.g. swap sides)
• show secondary state (e.g. free kick) & secondary time
• setup page/mode - teams, colors, kickoff
• future actions (upcoming unpenalise robots)
• showing actions on-demand (penalize -> team -> player)
  • still show player states, but don't make them buttons - show them when you click on the player
  • radial/circular menus
• one button per penalty (or one button for penalties) and one button for cards?
• test mode decided at launch time, not at runtime
• https://docs.google.com/presentation/d/1Z20upU4ukHemybueBlgu0WY4Enty0MEOVYLvdbPUxic/edit?usp=sharing