Jump to content

Fun with JSON


Josh

4,773 views

 Share

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
 Share

17 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

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?

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.

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?

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.

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.

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.?

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
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.
 

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.

Link to comment

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

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...