Hello, I think this might be a little bit of a uncommon question.

I wondered if it was possible in some engines to do changes to Gameobjects, like change a texture, and then recompile the game, but only with API commands?

Kind regards

Can you give explain why this would be useful? (Or perhaps an example?)

In theory it's definitely possible but “API” implies imho you have to write code that performs the change (when something calls that API you have to do something), and you have to write code to call the API. That's a lot of code versus opening the game object file, adding a field, and hitting 'recompile'.

So what cost are you avoiding in the latter form that you don't have in the first form?

Sounds like a modding approach and unfortunately this isn't possible except for games which really support mods and even those games ir quiet limited in what you can do. There are also games and techniques to make modding as hard as possible for you without good hacking skills.

The best bet are games made with Creation Engine (Bethesda) as their .bas file format is well documented and provided like an archive. So you can locate certain assets and change the texture ID for example

to recompile the game, you would need the game source, and that could take a lot of time in itself. Are you trying to do modding?

@Alberth I was just generally curious if such tasks could be theoretically done completely within the API because then maybe it would be possible to “automate" them via Script.

Of course it can be done.

Basically you build a description (a set of classes) of what you want to manipulate as an object tree. Standard techniques can be used to load and save such trees. Such trees can also be accessed programmatically to change the objects or the tree, and you can walk over it to produce code (text) you can throw at a compiler.

For a Game object, you may want to have a list of structure elements, where each element has a name and a type field. A value of the type field is represented by another set of classes.

In a mostly imaginary language, it may look like below.

game_object = new ClassType("GameObject", new List<Element> {  // represents "class GameObject { ... }"
  new Element("id", new StringType()),                          // represents "string id;"
  new Element("position", new VectorType(3, new FloatType())),  // represents "vector<float>(3) position;"
)};

// And then you can access or change things like
game_object.name,
game_object.elements[1].type,
etc

The idea behind it is to use a (meta)model to describe your data, so you can store, manipulate, and reason about your data in terms of model manipulations, rather than changing the data directly.

[Note that the meta-model level is even more powerful than my example, as it allows reasoning about any model. My example uses specific field names to access things, so it breaks if you try to use it with another object tree structure.]

I am somewhat familiar with the Eclipse Modeling Project, but no doubt there are many more such tool collections.

hplus0603 said:
If you want the shipped game to also allow in-engine modification, then most virtual worlds support that just fine – Roblox does it, for sure; as does Second Life and There.com and I'm sure others. It's kind-of their “thing.” The main problem there is that, because typical games do massive compilation and optimization of assets that take a long time, the virtual worlds (now known as “metaverses”) end up with lower quality and/or less performance and/or some other trade-offs because the edit has to be “fast enough” and not require, say, re-raytracing global illumination for the entire level just because you plunked down a Christmas tree.

Yes. As I've mentioned, I'm writing a new client for Second Life using Rust and Vulkan, so I'm very aware of this problem. It's quite possible to deal with it, but it takes a lot of caching and rebuilding.

Some of the hard cases require dedicated external servers to manage the changes. Clothes changes in Second Life can take 20 seconds. The client compiles a list of all the layers worn, and sends that list to a “baking server”, which fetches all the required assets, does layer compositing much like Photoshop, and creates some new composited texture assets. It tells the client which assets to use now, the client applies them, the viewer's asset fetcher fetches them, they propagate through the asset system and the avatar slowly appears in all nearby clients in all its glory as the texture LODs (in JPEG 2000 format) load. Now that you've paid the optimization price, rendering is fast.

Similarly, when you change static obstacles or ground terrain, you have to rebuild the navmesh, which is handled by a a different external server and takes 10 to 20 seconds. After that, pathfinding is fast.

Just changing a texture is cheap if the texture is already known to the system. You can just change face N of object M to texture T via an API call, and that happens rapidly. If you want to upload a new texture of your own, you can upload a .png file to yet another external server and get back an asset ID. (There is a service charge of about 5 cents for this, after which the texture is kept as long as it's in some inventory somewhere.) Now you have an asset ID (a 16-byte UUID) and can use it on any object to which you have asset rights.

Adding an entirely new mesh object is also possible. For that, you have to create a mesh in Blender or Maya, export a .dae file with multiple LODs and a physics model, and upload it to still another set of servers, the mesh asset server system. That checks the mesh for sanity, converts it to the internal format, assigns it an asset ID, and puts it in your inventory. (There is a service charge starting at 5 cents and increasing with mesh complexity.) This uploading is all happening live, in game. Once in your inventory, you can “rez” the object in world (someplace where you have the right to create objects, like your own land or a designated sandbox), and it appears all in grey. Then you can edit it by adding textures, which you may have uploaded with the mesh or created separately.

This is how all new objects are created in Second Life / Open Simulator. There is no offline build process.

Asset distribution requires a lot of caching. The assets live on AWS, which is front-ended by Akamai's content distribution network of NGINX cache servers. Clients have a big cache of about 10GB of those assets, all loaded on demand from the content delivery system. Everything is retrieved by UUID, using ordinary HTTPS. Clients start out with an empty cache; there's no content in the initial download.

So that's what it takes to do this in systems with fully general object creation. Think of it as the Software as a Service approach to level editing. Much of the stuff that Unreal and Unity do on your desktop gets done on a server in an AWS data center.

Doing this for textures alone isn't too hard. You'd need some kind of unique ID for textures, a web server where you could upload textures, and a game client which knew how to download and use textures. You're not doing anything to the content, just storing it. It's a good idea to run anything the user uploads through a validator, so they don't upload a hostile JPEG or something.

The voxel worlds, like Roblox, have it a bit easier, because they have more constrained geometry.

@nagle thank you for the explaination, I'd definetly keep this in mind for our SDK, as we have a swarm building/networking feature as well as AI driven real-time content creation on the list