Easy Charts: a Control-based plotting addon for Godot 4

Six plotter classes cover the chart types a game UI actually needs

Easy Charts is a Godot addon for plotting charts, and the implementation lives in a single directory, addons/easy_charts/control_charts/plotters/. Six plotters are listed as implemented: AreaPlotter, BarPlotter, LinePlotter, PiePlotter, RadarPlotter and ScatterPlotter. A seventh name, FunctionPlotter, is described as the shared base plotter used internally by multiple chart types rather than as something you place in a scene.

That list is the honest scope of the project. A telemetry panel in a game HUD wants a line chart. A leaderboard or a progress summary wants bars. A pie chart covers a share-of-total breakdown. Radar and scatter cover comparative and correlation views. None of those need to be drawn in world space.

The examples folder, addons/easy_charts/examples/, contains working scenes for the realtime line chart, the realtime pie chart, the radar chart, the scatter chart, a composite chart and a multiplot. Those last two entries matter more than they look. A composite chart draws more than one plotter into the same visual, and a multiplot puts several charts side by side, which is how a dashboard gets built rather than one chart at a time.

The realtime examples are the ones worth studying first, because they show the intended update path: a chart whose data is fed as it arrives rather than computed once at startup.

Control-based charts are the current scope, and 2D and 3D are still listed as unavailable

The project status section is unambiguous. Easy Charts currently supports Control charts only, the Control chart plotters are marked as implemented, and dedicated 2D and 3D chart systems are marked as not available yet.

This is the gap between the repository description and the code. The description calls the addon a collection of Control, 2D and 3D Nodes to plot every chart possible, which reads as a promise of all three families. What the status section says is that only one of the three exists today. Anyone deciding based on the marketplace description alone would pick the wrong expectation, so the status section is the place to check.

Working with Control nodes has real consequences. A Control chart is laid out by the Godot UI system, so it inherits anchors, containers, theme overrides and the usual sizing rules. That is exactly what you want for an in-game dashboard, where a chart has to resize with the viewport and pick up the project's theme. It also means a chart cannot simply be positioned in world space, which is the case the 2D and 3D systems would eventually cover.

There is also a version split to keep in mind. Users of Godot 3.x are pointed to a separate godot-3 branch of the repository, so the main branch is the Godot 4 line and the older engine version is maintained in its own place.

Running the documentation locally with MkDocs and mise

The full documentation is hosted for the project, and the repository also carries a local copy under ./docs that is built with MkDocs. The requirements file pins the exact versions of the documentation toolchain, including mkdocs itself at 1.6.1 and the mkdocs-material theme at 9.6.20.

Serving the docs locally takes three commands:

mise install            # optional: installs tooling from mise.toml
pip install -r requirements.txt
mkdocs serve

The mise step is marked optional and pulls the tooling from a mise.toml file at the repository root. Once the dependencies are installed, mkdocs serve renders the site, and mkdocs.yml at the root holds the site configuration.

The interesting part for an adopter is what the pinned requirements list reveals about the toolchain. It is a documentation-only dependency set, with the usual MkDocs plugins such as material and pymdown-extensions, and it is entirely separate from the addon itself. The addon is GDScript inside the addons/ directory, so nothing in this list needs to be installed for the charts to work in your game. Only people who want to build or read the documentation need Python at all.

For working on the plugin itself, the project says to clone the repository and open it directly as a Godot project, with project.godot at the root. That means the editor, the addon and the examples are all in the same tree, and you can run an example scene without a separate test harness.

Version tags are inconsistent, so pin a commit rather than a release name

The release history has a rough edge. The listed tags are v26.05.29 from 2026-05-29, V16.05.26 from 2026-05-16 and v28.08.25 from 2025-08-28. The naming shifts between a lowercase v prefix and an uppercase one, and the numeric part does not sort as a version number in any obvious way, since the 2025 tag carries 28.08.25 and the 2026 tags carry 26 and 16.

For a plugin that you vendor into a game project, that matters. A tag that does not sort predictably will not behave well with a version comparison, and an inconsistent prefix will defeat a case-sensitive match. The safest approach is to pin the exact commit you tested rather than to select by tag, and to record that commit in your own version control notes.

The repository is not archived and the last push was on 2026-10-10, so the code is moving. The project ships a disclaimer that says the addon is open source and still evolving, and asks users to apply normal project safety practices such as version control and backups, especially before integrating major updates. That is an unusually direct instruction for an addon, and it applies to your game project as much as to the addon.

The licence is MIT, with a LICENSE file in the repository root, so vendoring the addon into a commercial game carries no copyleft obligation on the game itself.

Charts that update live need a data path you design yourself

The examples directory ships a realtime line chart and a realtime pie chart, which tells you something about the shape of the data flow. A chart in a game does not poll a server by itself. Something in your game code has to push new values into the chart node, and how often you do that decides whether the display is smooth or jittery.

The practical advice follows from the node types. A Control chart is a UI element, so it participates in layout. If you drop a chart into a container it will be resized by that container, and if you size it manually you have to handle resizing yourself. Either way, updating data at a high rate means invalidating the node's drawing, and the cost of redrawing a chart is proportional to how much is on screen.

The composite and multiplot examples point at the other half of the design. A composite chart draws several plotters together, which implies a shared coordinate system between them, so a bar plotter and a line plotter in the same chart need their scales to agree. A multiplot puts separate charts next to each other, so each one keeps its own axes but shares the panel's layout.

None of this is documented in the visible portion of the project notes, which cover the plotters, the examples and the documentation workflow. The full API documentation lives at the hosted docs site and in the ./docs folder, and that is where the property names for feeding data to a plotter are defined.

Why this addon instead of drawing the chart yourself

The comparison worth making is not against another Godot charting addon but against the default of writing the drawing code yourself in a Control's draw callback, which is a common approach in Godot projects.

Doing it by hand means implementing axes, scales, labels, legends and the mapping from data space to pixels, then handling resizing, theme colors and updates. The plotters here already exist, they are shared through a common base plotter so the coordinate logic is not repeated six times, and the examples show the intended usage patterns for realtime and multi-chart layouts.

The alternative in the other direction is a general purpose charting tool that runs outside the engine and exports an image. That approach produces a static picture, so it cannot animate with the data, cannot follow the game's theme and cannot be interacted with, and it adds an external dependency and a build step to a project that otherwise has none. A Control based addon keeps everything inside the engine's own rendering and layout path.

The cost of that choice is scope. Everything is Control based, so world-space charts are not there yet, and the addon is young enough that the project tells you to keep backups. The trade is a smaller, engine-native feature set in exchange for a chart that behaves like the rest of your UI.

Editorial conclusion

Easy Charts is worth adopting when you are building a Godot 4 interface that needs a dashboard panel, a telemetry readout or a settings visualization, and you want chart nodes that behave like any other Control rather than a drawn-on texture. It is the wrong tool if your plan depends on charts inside a 3D world, because dedicated 2D and 3D chart systems are still listed as not available, and it is the wrong tool for a Godot 3 project, since that line lives on a separate godot-3 branch. Before you integrate it, verify three things yourself: that the plotter you need is on the implemented list, AreaPlotter, BarPlotter, LinePlotter, PiePlotter, RadarPlotter or ScatterPlotter, that the addon works with your Godot 4 version, and that you keep a version control checkpoint before pulling a major update, which is the caution the project itself states in its disclaimer.

Frequently asked questions

Official sources

1. fenix-hub/godot-engine.easy-charts on GitHub
2. License: MIT
3. Project website
4. README
5. Releases