But, there are game engines that don't use json. I want Cute Exporter to support those use cases.
My goals in supporting this use case are:
- Easy setup.
- Let user do what they want.
- User provided file extension.
- Easy to change.
Using a template file.
This is easy to set up for the user and easy to change. It fails in user provided file extension. Let user do what they want is a 50/50 here. They can do what they want, as long as it's not advanced.
Now we could extend our scheme to have a definition file written in json or XML. The definition would provide the path to the template file and the file extension. Not bad, but now the user has 3 different files and file formats.
Additionally, there is the issue of where do these file get saved? The files could be saved to a known location on disk. Doing this makes it easy for the program to find and list all different export formats they support along with user provided ones.
I want any user provided data to be located nearby the project file. I want the user to be able to version control their code, images, and exporter tools in the same place. If I want multiple people to work on the project with me, I have to pass along the custom export format in addition to the code and instruct them how to install it.
The way I decided to solve this was to give the user a programming language, Lua. The user can use any template format or techniques they want. All Cute Exporter cares about is returning a string that it will save to a file.
How it works
In the settings the user will tell Cute Exporter it wants to use a custom exporter and provides a path to the script to run. Cute Exporter saves the path to this file relative to the directory the project file is saved in. With the intention that the user will save the exporter script with the rest of their code and assets. That way if you want other people to work with you, they don't need to worry about any setup with Cute Exporter. Download Cute Exporter and open the project file.
When it comes time to export the data, Cute Exporter will run the custom script. To standardize things it runs a function in the script named `doExport` passing in the metadata for the export. It expects a string to be returned. The string returned will be saved to the data file.
What about file extension? The great thing about Lua is it's easy to use for configuration in addition to scripting. In keeping with making it simple the user can optionally provide a global variable declaring the file extension. Cute Exporter will run the script and read the global variable `outputFileExt` if it exists. The string value in that variable is used as the file extension for the custom export format.
I think this hits all my goals. It's easy to setup with a few clicks in the settings. Lua is a full fledged programming language, the user should have no trouble doing what they want. The user can provide a file extension. And the script is easy to change. On top of that, we expect one file only for the user to provide config info about their format. Lua can include other Lua files and code and this implementation allows that, giving the custom format access to any code written by others with a simple import statement.
Let's wrap this up. Here's a minimum example of an export format.
1 2 3 4
outputFileExt = "custom" function doExport(data) return "hello!" end
The resulting data file will have the extension `.custom` and the text `hello!` in it. A non trivial format should do something with the data provided but as shown, Cute Exporter only cares about the return value.