For me, I either use factory methods on a class or I use groovy. To me, using JSON to create entities is just like groovy with a lot of extra quotation marks. Remove the extra quotation marks and it’s almost groovy already.
Just depends on what I need after the game has already been running… or if I want some nice DSL stuff for entity creation.
For example, in Mythruna I had a small DSL that would let me register factories. The code could then call that factory by name to create the entity. So I’d have a bunch of object factories defined in one .groovy file, organized however made sense at the time.
For my Outside engine, being a server side drive platform, I have SQL Types that build out the metadata for prefabs (or at least something similar in concept that the engine calls assets) There are corresponding java beans for passing the metadata to the client for how to render/use the assets. Some assets are a sound, material, etc (things that are not directly renderable in the scene).
I feel comfortable using JSON for organizing my entities. It is supported by most DBs if you decide to use DB as well and it is naively can be used in NodeJS wen I decide to Get/Post data to my web server. JSON is just great
Suppose I have an entity prefab (in groovy) that creates an entity of object type “Peasant” and I want to use this prefab for multiple game scenes but with slightly different components in each scene, like a different name,… in each scene.
Would you put only common components in an entity prefab and set the scene-specific components somewhere else ?
or would you handle it all in the same entity prefab script with some if/else statement when creating entity? (i.e if it is for scene X use this component, else if scene Y use that component,…) ?
or would you create multiple entity prefabs with different object types for each specific scene, for example something like “PeasantTypeX”, “PeasantTypeY”,…?
The temptation is to make things like “name” that will be different for every entity into a parameter on the factory. Especially if you wanted to make sure that all entities had one. And for me, it’s quite common that my factory methods take at least name and position… though position is probably best set last.
If you plan to want to override things that you would already be setting on the prefab then that indicates that you may really want more than one prefab. For example, if Peasant normally has Strength(1) and you want to create a Peasant with an overridden Strength(2) that may indicate it’s not a regular peasant anymore.
…and if you know that you will never “override” of “conflict” components like that then you could have your factory method take a list of extra components as a convenience. (Which also means if you have an empty prefab you have a convenient factory that will create an entity and set a bunch of components from a single call already.)
So in some ways, it depends on the use-case.
The benefit of groovy as the prefab format is that you can put logic in there and I’ve done that, too… but it’s generally very generic logic that would make sense for almost any type of entity. Like generating a Name or picking a model info based on some other criteria or something (maybe tall peasant versus short peasant or whatever… but it’s a very contrived example.)