Project Dusk #5 - Testing scene graph webbuild 3

Testing the build of last week revealed a render issue on older Android smartphones. The issue was that the depth buffer resolution was significantly lower than on other systems. Adjusting the depth range to a small slice helped fixing this issue.

So let's start with the current version of this week:

It doesn't play any different compared to the previous version though visually it has changed quite a bit:

• The ground is desaturated by a shader for a fog like effect - also because it's too distracting otherwise
• There's more ground and less water
• Clouds are drawn to create more feeling of flying
• The left and right of the screen is now overdrawn with a border to handle different aspect ratios

Technically there are a few more changes. I am trying to move towards enabling reloading game data while the game is running. A JSON file is parsed and I am reading values that modify certain game parameters. The idea is, that I want to life edit enemy patterns and their behavior and that is difficult to do in C. I started with reloading the shader, which brought me some annoying buggy effects:

I eventually figured out what the reason was, but it doesn't matter much - let's just say that when unloading a shader and it's locations, you better don't use those any more.

When thinking about how to add enemy patterns and UI, I decided to pick up the original idea again: creating a scene format and eventually an editor for that. While the later is currently not the highest priority for me, collecting some experience with creating a format that is loaded by C code is a good direction to start with.

My current (working) draft is this here:

{
    "root": "ui",
    "objects": {
        "ui-border": {
            "type": "MeshRendererComponent",
            "mesh": "ui-border",
            "litAmount": 1
        },
        "border-element": {
            "components": [ "ui-border" ]
        },
        "border-group": {
            "children": [
                {
                    "prefab": "border-element",
                    "position": [ 0, 6, 0 ]
                },
                {
                    "prefab": "border-element",
                    "position": [ 0, 2, 0 ]
                },
                {
                    "prefab": "border-element",
                    "position": [ 0, -2, 0 ]
                },
                {
                    "prefab": "border-element",
                    "position": [ 0, -6, 0 ]
                }
            ]
        },
        "ui": {
            "children": [
                {
                    "prefab": "border-group",
                    "position": [ 8, 0, 0 ]
                },
                {
                    "prefab": "border-group",
                    "position": [ -8, 0, 0 ],
                    "rotation": [ 0, 0, 180 ]
                }
            ]
        }
    }
}

What this does is a description of an object, its children and components. It's a little bit similar to what I worked out with Raygine, though there are some deviations for the sake of human readability:

• It's not a nested format; nested formats have in my experience lot's of issues with readability and maintainability. While it is convenient to see the hierarchical structure in a nested format, it quickly becomes a burden after the 4th indention level or so.
• It's a flat list with named references: The object keys are the unique identifiers and the elements refer to each other using those keys.
• Objects and components are in one list.
• References are instantiations: when referring to an id, the target is instantiated and returned. This enables nested prefabs and easy reuse of objects: The "border-element" is a prefab and is used multiple times in the "border-group". Values can be overridden in the instantiation step. It doesn't allow nested overrides yet. I will work this out once I need that.
• Currently it only supports the MeshRendererComponent - that's a part that's hard wired. I am thinking of utilizing the code I started writing 3 weeks ago which led to the type system approach; then I could create a schema description in C and use that to initialize component data via JSON.

It's a little weird that I am now working on a concrete game and trying to fit editor like features to the test whereas the Raygine project was the reverse. Solving concrete problems is a good way to find out what's really needed and what's not. Though I really miss some visual editing tooling here already.

I am thinking of making a video about the approach I am using here and publishing the scene graph code base as a library. It's really versatile, even if it isn't finished yet. It's proving itself to be quite stable and I think it could be useful for others too.