Using resources for data in Godot

We chose to use Godot’s native resources over a text data format like JSON for this series. You can use either to manage data for your games; each has its pros and cons.

In this series, we’re going to use resources as they are Godot’s native data containers. If you were to create a large game project, I think resources could be a useful tool. Still, you would likely want to code an editor plugin to edit your game’s data efficiently.

JavaScript Object Notation (JSON)

JSON is a text-based data format initially designed to translate JavaScript’s types into text and vice-versa. It initially allowed developers to send data over the web in a human-readable, making it easy to inspect and edit the data in case of errors.

As it’s easy to read, edit, and pretty much all programming languages have built-in support for it. It’s become pretty ubiquitous, taking over XML in popularity.

Here are JSON’s pros:

• You can put a lot of data in one text file, read it, and edit it in a code editor.
• It’s the most common interchange data format today. It’s ideal for exporting the data from your game and importing it into another program.
• Third-party game database applications like the Open-Source CastleDB export JSON data.

The cons are that:

• JSON only supports JavaScript’s basic data types. For example, it doesn’t support integers specifically. When parsing plain JSON, all numbers get converted to floats.
• To store any native Godot type as JSON, like Vector2, you need to write code to parse each type.
• You can’t edit JSON files from within Godot.
• Text data is slower to serialize and load than binary.

You’ll want to go with JSON mostly if you or a designer in your team uses an external program to edit your game’s data, like a spreadsheet program.

Godot’s Resource class

Resource is Godot’s built-in base type for data containers. All textures, 3D models, shaders, audio streams, and many more kinds of data extend the built-in Resource class.

The advantages of native resources include:

• Resources can serialize and load any native Godot type, including Vector2, Vector3, Image, and much more.
• They can contain nested sub-resources which all get saved with their parent.
• They are shared in memory. Godot only loads a resource once; every object that tries to load it afterward receives a reference to the already loaded resource.
• They get saved as plain text in your project and converted to binary on export, maximizing performances.
• You can edit them in the Inspector.
• You can create and save them inside a scene if they’re specific to that scene, allowing you to pack the data in it.

The disadvantages of resources are:

• They work best as small separated files, so you tend to end up with many files.
• As a result, you need to double-click each individually to edit it. With many small resources, doing so can be slow compared to editing a big spreadsheet.
• Because resources are shared in memory by default, you need to remember to duplicate the ones that need to be unique, for example, when multiple monsters have the same base stats.
• Some initialization steps don’t work the same as with other types in Godot and can be un-intuitive as a result. We will see one example in the series.
• If you change a resource’s interface, for example, by renaming a variable in its GDScript file, you may lose data. You’ll have to be careful when doing so.