Jump to content

Fun with JSON

Josh

279 views

I realized there are two main ways a plugin is going to be written, either as a Lua script or as a DLL. So I started experimenting with making a JSON file that holds the plugin info and tells the engine where to load it from:

{
    "plugin": {
        "title": "Game Analytics",
        "description": "Add analytics to your game. Visit www.gameanalytics.com to create your free account.",
        "author": "© Leadwerks Software. All Rights Reserved.",
        "url": "https://www.turboengine.com",
        "library": "GameAnalytics.dll"
        }
}
{
    "plugin": {
        "title": "Flip Normals",
        "description": "Reverse faces of model in Model Editor.",
        "author": "© Leadwerks Software. All Rights Reserved.",
        "url": "https://www.turboengine.com",
        "scriptfile": "FlipNormals.lua"
        }
}

I like this because the plugin info can be loaded and displayed in the editor without actually loading the plugin.

I also wanted to try using a JSON file to control script properties. For example, this file "SlidingDoor.json" goes in the same folder as the script and contains all the properties the engine will create when the script is attached to an entity:

{
    "script": {
        "properties": {
            "enabled": {
                "label": "Enabled",
                "type": "boolean",
                "value": true,
                "description": "If disabled the door will not move until it is enabled."
                },
            "distance": {
                "label": "Distance",              
                "type": "float",
                "value": [1,0,0],
                "description": "Distance the door should move, in global space."
                },
            "opensound": {
                "label": "Open Sound",              
                "type": "sound",
                "value": null,
                "description": "Sound to play when door opens."
            },
            "closedelay": {
                "label": "Close Delay",              
                "type": "integer",
                "value": 2000,
                "minvalue": 0,
                "description": "The number of milliseconds a door will stay open before closing again. Set this to 0 to leave open."
            }
        }
    }
}

I like that it is absolutely explicit, and it allows for more information than the comments allow in Leadwerks 4. There is actually official tools for validating the data. The json data types map very closely to Lua. However, it is more typing than just quickly writing a line of Lua code.

While we're at it, let's take a look at what a JSON-based scene file format might look like:

{
    "scene": {
        "entities": [
            {
                "type": "Model",
                "name": "main door",
                "id": "1c631222-0ec1-11e9-ab14-d663bd873d93",              
                "path": "Models/Doors/door01.gltf",
                "position": [0,0,0],
                "euler": [90,0,0],
                "rotation": [0,0,0,1],
                "scale": [1,1,1],
                "matrix": [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]],
                "mass": 10,
                "color": [1,1,1,1],
                "static": false,
                "scripts": [
                    {
                        "path": "Scripts/Objects/Doors/SlidingDoor.lua",
                        "properties": {
                            "distance": [1,0,0],
                            "movespeed": 5
                        }
                    },
                    {
                        "path": "Scripts/Objects/Effects/Pulse.lua"
                    }
                ]
            }
        ]
    }
}

 

  • Like 1


15 Comments


Recommended Comments

I love the idea of having JSON for scene data.

This would allow for multiple people to make map changes using version control.

For data like heightmap, you could even store it as a base64 encoded text. By storing as base64 text, it could also allow to users to modify different parts of the heightmap at the same time without issues

Share this comment


Link to comment

I think binary data should be in a separate file, like GLTF does it.

Share this comment


Link to comment

Not a big JSON user, but a text format for maps hits close to home. I really liked WorldCraft/Hammer mapfiles because of this. Does that mean the maps need to be compiled into a binary format so the engine can read the data quicker?

Share this comment


Link to comment
5 minutes ago, reepblue said:

Not a big JSON user, but a text format for maps hits close to home. I really liked WorldCraft/Hammer mapfiles because of this. Does that mean the maps need to be compiled into a binary format so the engine can read the data quicker?

No, a .bin file will be stored in the same folder with the same name, and it will contain all binary data. The JSON file will just store a position for the data.

Well, brushes aren't very high-poly, so maybe they don't need to be encoded in binary. Terrain heightmap data definitely does, but with the infinite terrain system I already was planning on storing those in separate files, like "myscene_134_842.patch" with the X and Y positions of the patch in the file name. So maybe the entire scene format can just be text.

Share this comment


Link to comment
Quote

However, it is more typing than just quickly writing a line of Lua code.

That is what Visual studio code snippets are for. Just type vec3prop or something, press tab and you get a snippet with common options. You can even tab through the parts of the property.

156376771_leadwerksvscodeextension3.gif.d23fc18bcc49f3c66d1e58ce61dcbd4a.gif

 

And JSON for file format sounds great. Having a filesystem that can be merged by any versioning protocol is great to have. In the past you mentioned this would get make a bad design choice because of the file size. Is this no longer that relevant or are there good solutions to work around that?

Share this comment


Link to comment

Scene loading will be slower but it seems like an acceptable tradeoff.

Share this comment


Link to comment

Not to mention, it being text, it should be a lot easier to copy and paste data from one map to another. In theory, you will be able to load maps within other maps without compromising instead of the limited prefab system in LE4. It would be like how prefabs work in Hammer. You should be able to store flowgraph data in it too.

A tad worried on the speed cost as this is the first time I heard you planning on something that doesn't prioritize speed. I would do benchmarks to see how slow this might be. 

Whatever you decide, I'm looking forward to seeing what you come up with.

Share this comment


Link to comment

I'm a little concerned with the scene loading being slower too.  Tempted to make a scene versus non-scene loading comparison.

Share this comment


Link to comment
59 minutes ago, reepblue said:

A tad worried on the speed cost as this is the first time I heard you planning on something that doesn't prioritize speed. I would do benchmarks to see how slow this might be. 

Loading speed and rendering speed are two different things. I am not as worried about the first one.

Share this comment


Link to comment

If the loading speed is long enough to make a sandwich and come back on something like The Zone, then you have a problem. Other than that, I'm looking forward to text formatted maps.🙂

Share this comment


Link to comment

Don't forget a plug-in script/json should have a version property. It helps when updating scripts and making sure multiple scripts are interoperable with each other.

  • Upvote 1

Share this comment


Link to comment
11 hours ago, reepblue said:

If the loading speed is long enough to make a sandwich and come back on something like The Zone, then you have a problem. Other than that, I'm looking forward to text formatted maps.🙂

You'll spend more time loading assets than you ever would parsing a JSON file.
 

Share this comment


Link to comment

Again, not that familiar with the format. Just took for granted that text is slow. Interested in how this will turn out.

Share this comment


Link to comment

I think the majority of loading time will be in model vertex / indice arrays and those are still in binary format.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Create Your Account

Sign in

Already have an account? Sign in here.

Sign In Now
×