So for a long time now, Yin has been using a Geometry format I quickly threw together which was heavily based on the PLY model format - I basically butchered a PLY plugin for Blender so I could quickly export Geometry files from there for testing. You've already seen the results of that in my previous posts.

Now that the Node implementation is complete and I've migrated some other systems to use it, it's time to rethink how a world is going to be represented in Yin.

First, before we get too far into the big wall of text, I've made some slightly earlier code for Yin from April of last year available here - everything included is under public domain, so you can do whatever the hell you like with it and don't necessarily need to credit me (though it would be appreciated 💗.)

This was an experimental branch of the engine which looked to add support for Eradicator's level format. Work started on this around the same time I was finishing up for a game jam, hence why there's still a lot of Doom references in there, but it didn't get very far before I decided to move onto something else. If someone is dedicated enough they could probably pretty easily finish this, Eradicator's level editor was a huge help!

Anyway back to the subject at hand, the existing Geometry format is made up of the following components.

• Materials
  
• Vertices
• Faces
• Sectors

You can see an example of the Geometry format here.

The Materials component provides a list of paths to each material used within the given area, so for example, materials for terrain, walls or other elements of geometry.

The Vertices component provides a list of all the vertices, providing their position, normal, UV and colour.

The Faces component provides a list of all the faces. Each face provides a number indicating the number of vertices used to represent the face, followed by a list of indices into the Vertices component and then another number representing the index into the Materials component.

Finally the Sectors component provides a list of all the individual sectors, each with a number indicating the number of associated faces and then a list of each face associated with that sector. This isn't really being used at the moment and isn't really sufficient for our needs anyway - Yin internally clumps everything into the same sector, essentially skipping this component.

Of course, the Node container isn't exactly compatible with the Geometry format and thus all of that needs to be thrown out or revised. Not to mention the previous implementation really didn't suite our needs anyway...

We know what to do with this.

So let's sit down for a bit and think about what we really need here.

First we want to be able to include worlds within other worlds. How's that going to work? The desire is for us to be able to essentially create props or other details within the level editor and then include those within other worlds - external prefabs basically.

There's a pretty easy solution for this I think wherein each world will have a selection of meshes and these meshes can either be stored externally to the map itself or packed within, and then used everywhere as required.

Second issue we need to resolve are sectors and the portals between them. I'm not going to worry about this too much right now, as it's not really useful for the game I'm currently working on, but this should be an opportunity to lay a little bit of foundation for later.

The last issue to resolve are how we will handle actors and their properties. Thanks to the new Node structure, it's pretty easy for us to just provide a list of objects each with their own properties; we can take the name of the actor and just simply pass the node into some deserialisation function that'll deal with whatever properties it needs for that particular actor.

An overhead of the new format probably looks something like this.

• World (head)
• Global Property Object Array
  
• Actor Object Array
  
• Transform Matrix
  
• Property Object Array
• Meshes Object Array
• Identifier String
  
• Material String Array
  
• Vertex Object Array
  
• Face Object Array
  
• Sector Array
• Body Object (points to primary mesh object)
  
• Meshes Object Array (list of sub-meshes for detail)
• Transform Matrix
  
• Mesh Identifier String (either for mesh in array or external)
  

The meshes are a bit special, as the new implementation is being designed so that we can load meshes externally as well. The idea is that you could create props within the level editor and save these out to their own mesh, which you can then import into your map and use wherever you need them within each sector (and we can then instance them too).

A Mesh translated into the Node format looks something like this right now.

Yeah, not very efficient perhaps but this will be translated into a binary form and compressed when run through the PkgMan tool.

Anyway I guess that's that for now - I better get a move on and finish this up. Until next time!