What Is This About?
The concept of these mechanics have occupied my brain for at least a year. I have been refining the concept and the primary design ever since. That is one of many conceptualised systems. Until the end of last week, while working, and polishing the UI and during the bed time, my brain couldn’t stop grinding my thoughts about making a prototype for AI. So our UMes have cobbled up the prototype over the past few days.
So let's discuss this in a bit more detail.
Please mind that anything shown, it is still a prototype and is visualised in the game engine, not UMeFate itself. So the final representation and implementation will differ.
First let's consider the following scenario as an example. You are going to a town and you can see people walking and hear talking around. That is an observable mechanic in a principle.
In another scenario, it is a nice and a bit chilly evening. You are going to a restaurant, where you sit at the table, but outside the building. Next to you there is a heater. It heats nearby sitting restaurant guests. That is applying a heat influence. Or, going to the park, where trees influence a positive mood.
Or, looking for collectable food in the fields.
Naturally there could be negative influences too. Like observing a character, with scruff wearing clothes. Etc.
Observable And Influence Challenge
So the goal of this mechanic is, to be able to detect nearby entities, which can be observed and influenced. An entity can be anything. A tree, a townie, a rock, a table, etc. For a few entities, like household characters, it is not so much of a big deal. Neither technological, nor performance wise.
But if we now consider a live dynamic world, in which everything happens in real time, as UMeFate aims for, we can easily end up with 100s thousands of potential observable relations. Not only between characters, but characters and objects, and even objects with other objects (entities).
If we approach this with a brute force, we may need to check 1000s multiply by 1000s entities for possible observable interaction. That is already potentially over a million checks, just for that mechanic. And need not to forget about other game systems and mechanics.
On top of that, if some entities can have multiple observables types, i.e heat, hearing, seeing, happiness, etc. things scale up quickly. Some entities naturally will have fewer, or even none of these.
Observable And Influence Challenge
As some entities move around the world, or are created at a given time, then world cells in the grid of specific observable types are updated. Such relations are tracked, until getting out of range of an influence. (More about grid types and their cells is detailed further in a blog post).
Each observable type and its entity, can have its own influence range. But not greater than the defined cell size of the grid type.
Influence Events Timing
Entities that have an active emitter active, can emit an event with a given frequency, to interlinked other entities of the same type. That means for an example, the heater can apply every 1 second heat around, to all interlinked entities. I.e. characters in the restaurant.
Walls And Obstacles
Walls and obstacles are future considerations. The idea is that observable types like a vision, should be obstructed by obstacles. I.e. walls, floors. But that could also apply to other types of obstacles.
Mechanic Optimisation
With potentially millions of checks, now we really want to look, how to optimise things.
Many games approach similar problems in a way that a far distant part of the world is “frozen”, until the player gets close enough to the area. After which, part of the world becomes active. I.e. Minecraft and world chunks implementation.
This solution however doesn’t fit into the UMeWorld dynamics.
Approximation can be used to group entities of similar behaviour. For example growing crops in the field. A field on its own can be a carrier of information for crops, instead of each individual crop. That alone can reduce the number of required computations.
In UMeFate, the carrier role can be taken by an entity with an observable / influence emitter. It checks all nearby linked entities once, caches them and periodically can apply changes in a bulk to the whole group. This doesn’t have to be field crops.
Factorio applies many clever tricks for optimisation, to run the whole world of conveyors and machines. All based on relations between entities.
UMeFate creates a grid for each type of observable behaviour. I.e. heat, vision, hearing. But the grid is not static, nor is of the same size, nor is the number of cells constant. Cells are added, removed, updated, as entities interact with a given grid cell, of specific type. For an example when UMes townies walk about throughout the world.
Naturally there are far more optimisation techniques, but that is not the designated blog post for this detailed technicalities.
Coding Optimisation
In terms of modding, there could be two main parts considered for this observable system.
One is the performance side, which executes on the engine side. And it is not considered to be moddable.
The other side is Lua modding part. That is where modders can define their own and new types of observables. Meaning, which entities should interact with, by which type. Like i.e. radio playing music, to be heard by characters. And then add behaviours, based on the influence type.
Lua Modding
But for the moment, it is time to back onto UI work. There are still bits left to do. But at the same time, I am very happy that I was finally able to start something on AI mechanics. Something that was pondering my mind for over a year. But patient must accept priorities.
That’s it for now, and until the next one 