Towards Graphical Debugging

[Cu3PO42]

Hi there!

I understand graphical debugging is currently on the future roadmap and this discussion is not intended as a feature request. However, I am very interested in graphical debugging and am willing to do some exploratory work in that direction. While I'm probably going for a custom solution without the express intent of it ever being upstreamed, I believe it would make sense to start in a direction that might resemble an eventual upstream implementation.

The main challenge I see for graphical debugging is the modular nature of Robocode Tank Royale with potentially varying frontends employing different rendering techniques. Here are the main approaches that I believe could work:

• Add the possibility to send arbitrary debugging data to the UI. The UI is free to do with that as it pleases. This would essentially allow any UI implementation to implement its own debugging capabilities and a bot's graphical debugging would typically only work with its accompanying UI.
• Implement a Graphics2D-like API by buffering any draw calls, serializing them and executing them in the UI. This favors the default UI implementation, but could theoretically be supported by and other UI as well. This has the additional charme of also enabling any legacy bots to use their graphical debugging.
• Let the bot process render all of its debugging information in-process and send either a raster or vector image to the UI. This has the advantage of being easy to support for any possible UI target, but adds some complexity to the bot API wrappers, which would need to include rendering facilities. You might also run into some performance issues with raster images. On the upside it would allow any bot API to use drawing APIs that are familiar to the relevant platform.

All of these have a fair number of details to work out and tune, but are likely all feasible. Do you have any opinions or feelings regarding this you'd like to share? I'm personally leaning towards implementing the first solution in a fork for my use case and then see what kind of protocol evolves from that.

Thanks for your consideration!

[flemming-n-larsen]

@Cu3PO42
I have already started working on this feature, even though it is currently paused to fix some issues seen with the Robocode Bridge.

I want the graphical debugging be simple and implemented in a language and UI independent fashion using a protocol like the rest of Tank Royale. Note that I just got started, so it is in progress.

I split the current schemas into two parts: game and gfx. The new one being gfx containing graphical/drawing primitives:
https://github.com/robocode-dev/tank-royale/tree/gfx-debugging/schema/schemas/gfx

It is missing the instructions to draw the primitives. It will probably be as simple as a list of primitives to paint for the next turn.

The UI will need to draw the primitives, if it supports graphical debugging. And the bots need to tell want they want to draw.
The bot should give a command like paint(List<GraphicalObject> graphicalObjects whenever they want something to be painted for debugging.
I also think we need some limit of how many graphical objects (drawing primitives) a bot can send per turn.

That is my thoughts so far. 😊

[Cu3PO42]

Thanks again for the quick reply! I must have missed that branch. It seems to me that the approach you are describing is a variant of the second approach that I proposed, possibly for a different set of primitives. Graphics2D is relatively powerful and it may not be necessary to support all of it for reasonable graphical debugging. That said, in one of my Robocode bots I employed a lot of different primitives. It may not be necessary to support all of these, but it sure would be nice.

Since graphical debugging is just for debugging and should not usually be enabled, I would tend to forgo any limits on the number of primitives. If a developer tanks their own performance during development only, I don't consider that a problem. Following that argument, it would be necessary to either enable graphical debugging only via a command-line flag or with a toggle in the UI similar to legacy Robocode.

The more I think about which primitives are reasonable, the more this feels like an ad-hoc specification of a part of SVG. It seems to me SVG would be a perfectly reasonable choice. It's well understood, extremely powerful and renderers exist for (almost) any target, making it easy for authors of UIs to implement. Bot APIs could still provide some methods to quickly and easily build simple primitives.

[Cu3PO42]

For the main UI specifically, JSvg looks great, which renders SVG through calls to Graphics2D methods. Also, Batik has an implementation of Graphics2D that renders to SVG, so that could be used to enable graphical debugging via the bridge.