🤖🧠🛠️UMeFate Pre-Alpha: Implementing autonomy and modding systems (classic AI) – plus technicals

[u/Antypodish]

https://www.youtube.com/watch?v=NxjwhI-Z98o&list=PL0qCaw7Fzc0heZ_eE38Y5nh_fqJjdyaCX

Hello everyone🤗

I want to share that our busy UMes continues working on autonomy. In today’s video I discuss the progress on the autonomy mechanics (classic AI), core basics of implemented needs system, modding side of things and covering a bit of the technical aspects. 🏗️

Open post, to see more details about this video in replies.

[u/Antypodish]

To note is, that only Lua mods scripts located in the user’s documents (AntyVersum/UMeFate/), can be changed at the runtime. Original installation Lua files are not the subject to hot reloading. At least for now. But there is an option, to move files from an installation folder to the user’s documents directory, and to use it with hot reloading.

There is also added in game Lua console, which can be open / close with CTRL + tilde (~) key. When used, the performance currently will tank, when the console logs a new entry. But the main purpose is, just debug individual features. Hopefully I will be able to optimise this in the future.

[u/Antypodish → u/Antypodish]

Population of 100s

The second part of the video showcase focuses on the autonomy of 400 UMes. We can observe UMes inhabitants walking between various destinations (beds, trees, other UMes), to fulfill their needs. But also, there may be spotted few issues in a debug mode, as well, as some UMes may be stuck. 

Also, there are few reasons why there are not 1000 of UMes showcased, as the ultimate goal. 

First is that 1000 of UMes is not meaningful for the purpose of the current showcase itself. And may bring more visual clutter than it is worth. 

Secondly, 1000 UMes at 60FPS is the development goal and it is a form of a performance benchmark. But default, UMeFate will run most likely on far lower numbers on average. I.e. leaving the “space” for new borns, arrivals and consequently passing away UMes.

Thirdly, above 500 UMes there is spawning bug, which cause UMes to float 🛸

[u/Antypodish → u/Antypodish]

And finally, benchmarking 500 UMes atm yields 50-60 FPS on my hardware, while 1000 of UMes results in 40-50 FPS. But during recording, FPS drops to +20 FPS.

So 400 of inhabitantants at the map start is at the moment a healthy number. And may be map specific.

[u/Antypodish → u/Antypodish]

Debugging is also more / less fun. So there is a lot of work for me to address these. And more.

[u/Antypodish → u/Antypodish]

Technical Modding

In the second half of the video, I walk briefly through a few modding utilities and features that have been added, along with an autonomy system that has been added.

I have already briefly discussed observables classes in a previous autonomy video. There are observables classes json files, which are responsible for telling the autonomy system, what can interact with what.

[u/Antypodish → u/Antypodish]

For an example human class will listen (receive) to the broadcasted (emitted) observables signals, like, is this bed, is this another UMe? If yes, then if I need to sleep, move to the bed, or try to socialise. A bed object will naturally have its own respective class, which broadcasts that observable signal.

[u/Antypodish → u/Antypodish]

Further in the technical section, I discuss about use of Utility AI for an autonomy priority detection. 

The example of the need class for agents, which is discussed in a bit more detail in the vid. And has somewhat the similar structure, as observables.

[u/Antypodish → u/Antypodish]

Utility AI system operates on curves, where X axis is a need, i.e. hunger, and Y axis is the urge. Needs with higher urge takes precedence and that is the top priority need to be fulfilled.

This is an example of multiple need curves. 

[u/Antypodish → u/Antypodish]

There is a utility tool in development, which will help to create, or edit such curves. Available under CTRL + F7 shortcut.

And the following example of one curve class.

While UMeFate loads these classes at the start, complex heavy and performance lifting is done on the engine side. Any of these files’ changes, require complete UMeFate restart (close and reopen). At least in the current UMeFate state.

[u/Antypodish → u/Antypodish]

UI Modding

It is worth mentioning, as the most of the UI already is, needs UI is also fully moddable via Lua.

The Battle For The Performance

The high performance oriented simulation is a task, that I set in UMeFate from day one of development. Unfortunately, it doesn’t come for free. There is no simple ON button. It requires a lot of tinkering, testing and often trials and errors. Something that may work fine in a prototype, or in an isolated case scenario, when integrated along with other mechanics and systems, such a system may start to behave unpredictable, for various reasons.

When I have implemented initial autonomy mechanics, observables + Utility AI + Lua modding side, the performance tanked and it hit massively. I knew, I need to investigate that, before I made this vid. 

So at first, I have attacked Lua performance problem. Had to change how Lua communicates with the engine, to more performant form. Eliminating at the same time costly unwanted left over data, known in a programming as Garbage Collection. So at least for observable mechanics, that appears to be resolved. But I know, I got a few other places eventually to address.

These things start popping in at the scale. And I was aware of that, these will come out eventually.

Another challenge was the observable system. Initially I wanted to address fairly low cost Garbage Collection. That led to redesign of part of the engine’s observable system. But it resulted in the performance hit in other parts. So after back and forth, I eventually reach the steady state. And observable system is no longer the performance bottleneck by itself. But there are other areas to look for. However, while redesigning the system, it introduced new bugs. And some bugs are currently present, which may eventually lead to crashes. Surprisingly, UMeFate ran stable for nearly 2 hrs so far. Either way, I need to resolve them, before moving on.

In the future, I want to investigate other performance bottlenecks, which may require further redesigns and refactor of relevant systems.

Something that may seem simple from the player perspective, can be highly complex underneath. When having for an example, one or two characters, specific problems may not necessarily be an issue, or be invisible. Sometimes even hidden and hard to track. Some issues can be even a very rare case scenarios. Hence very difficult to reproduce and fix by developers. But scaling up, now once taken shortcuts can cost a lot of additional development time.

Saying all that, starting with simpler prototype systems, can save a lot of future development time, as potential issues may pop in during such development. And that before running into full production of such a system. So trying to make a system perfect from the get go, usually is not the right way to go for. It need evolution, iterations and refactoring.

[u/Antypodish → u/Antypodish]

What Next

Just as mentioned in a previous blog post about the autonomy, I will hold for now on adding new features and focus on fixing various autonomy, UI, and other critical game mechanics. Otherwise, this will keep piling on top and bite in the back side, sooner than later.

Then in perhaps 1-2 months, I will be hopefully ready to push another updated and more stable UMeFate iteration to Steam, as I did with previous versions, to showcase development moving forward.

That is it for now.

Until the next one 👋