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:

  1 {
  2     "root": "ui",
  3     "objects": {
  4         "ui-border": {
  5             "type": "MeshRendererComponent",
  6             "mesh": "ui-border",
  7             "litAmount": 1
  8         },
  9         "border-element": {
 10             "components": [ "ui-border" ]
 11         },
 12         "border-group": {
 13             "children": [
 14                 {
 15                     "prefab": "border-element",
 16                     "position": [ 0, 6, 0 ]
 17                 },
 18                 {
 19                     "prefab": "border-element",
 20                     "position": [ 0, 2, 0 ]
 21                 },
 22                 {
 23                     "prefab": "border-element",
 24                     "position": [ 0, -2, 0 ]
 25                 },
 26                 {
 27                     "prefab": "border-element",
 28                     "position": [ 0, -6, 0 ]
 29                 }
 30             ]
 31         },
 32         "ui": {
 33             "children": [
 34                 {
 35                     "prefab": "border-group",
 36                     "position": [ 8, 0, 0 ]
 37                 },
 38                 {
 39                     "prefab": "border-group",
 40                     "position": [ -8, 0, 0 ],
 41                     "rotation": [ 0, 0, 180 ]
 42                 }
 43             ]
 44         }
 45     }
 46 }

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.