With the goal of creating a smoother level-up experience and raising the maximum level a player can achieve, the following changes have been made:
✅ The maximum upgrade level has been increased from 50 to 70.
✅ The amount of experience needed per level has been significantly smoothed out, meaning you will gain substantially more in the higher sectors.
✅ The price increase per upgrade level when purchasing them has been softened.
As you may know already, recently UMeFate had an update of Pre-Alpha Tech Demo v0.0.9, now available on Steam in playtest. That is a great and exciting milestone for us. In the following days after, UMeFate has pushed a few critical fixes. With all that, our lovely playtesters have used UMeFate internal feedback system and reported various issues. Now UMeFate focuses on the modding architecture, while opening the path for UMes autonomy.
For more details on the Pre-Alpha Tech Demo v0.0.9 release, you can read in our previous blog post
https://antyversum.com/2025/09/16/umefate-v0-0-9-pre-alpha-steam-release-of-tech-demo-51/
List Of Discussed Topics
Ingame Feedback And Bug Report System
Lua Modding In Works
NPC Autonomy / AI In Lua
Refining UI As Modding In Lua
Affected Saves And Saved Construction Blueprints
It is important to mention, that implementing UMeFate ingame feedback and bug report system, became highly valuable and the time spent adding it to the game, as shown, was well worth it. Our early playtesters were already able to use the system, to report multiple bugs. Some are more, or less critical. But saying all that, there is quite a list of them. Funnily saying that, bug report itself has also own bug, which need to be addressed 🙂
The main benefit of the bug report, when the player submits it, it allows to collect important information. For example including the screenshot, plus player description. But there is more.
Also, when an ingame bug, or feedback report is submitted by the player, they are reported to the discord, which gives immediate feedback to UMeFate dev team. Now these issues are in the backlog and are planned to be reviewed and tackled respectively. Soon after the current task regarding modding and UI is resolved.
At the current time, UMeFate focuses on various modding aspects. Specifically in the respect to Lua modding. Until now, Lua side code only handled spawning and navigation destinations of UMes in their world. Spawning and moving to the destination are mostly random and decided, when UMes have arrived to their destination.
Code and structure wise, it was actually a bit of dumpster fire. More proof of the concept than anything, without much of files structure. All lua logic was placed into one file. Even tho, not so much of the code itself. In the end, we have saying: “first make it work, improve it later”.
But it was expected, for Lua modding to work, these have to change. So currently our UMes are working on restructuring whole Lua directories, how files are read and how they are accessed. Mod directories will be organised per modders and their mods names. There is a bit of flexibility here for the future modders, regarding how things can be organised. But the base is already there.
From now on, various UMeFate Lua related logic will be written as mods. This hopefully will ensure that Lua modding is as stable and functional as needed.
One of the additional features of Lua modding system is, that some Lua code will be possible to change at the runtime, without needing to restart the game. While not perfect and has some limitations, for example atm., if syntax code error is present, unfortunately this requires restarting the game. Hopefully this will be resolved in the future. But the system has already shown benefits during recent testing of UI (more about UI in a bit).
Since major logic of UMes and their autonomy will be in Lua, solid core and the architecture of Lua modding is required. This is the part of approaching work on Classic AI / Autonomy for UMeLand inhabitants. This is a very exciting time for UMeTeam.
At the moment our UMes are testing possible and right paths for implementing whole autonomy logic along with modding in general. Once that job launches, there will be tons of work ahead. That is regarding UMes behaviours, relations, needs and whats not.
And not to forget, all aspects related to split-screen.
As the result and the requirement for UMes autonomy, there will be needed new UI informations and inputs for players.
Considering the current version of UMeFate, one of the natural approaches would be to keep polishing and adding features to the current UI system. Which is fine in a design sense. However there are various bugs still, which need to be fixed first. But if being able to refine and test changes of UI at the game runtime and without needing resetting the game, this would be a massive workflow improvement. So to not dive too deep into the current UI architecture, while still needing to resolve various bugs, the current UI state gives a great opportunity, to make it moddbale. Or at least partially (for now) moddable.
So the first part of the process, which has already started last week, is to rebuild the current UI, but as mods. That where we earlier have discussed restructuring modding architecture for Lua.
Following that, ensuring that new UI features works at least as good, or better than the current UI.
Then existing bugs and new features should be easier to tackle.
With all that said, there is a significant time cost for these implementations. But we believe in the long run, we can see huge benefits of UI being able to be modded. Also doing UI from almost day one as mods, as previously mentioned, will make UI modding and designing much more stable. Additionally, that allows to clear up any technical depth early.
It is similar in a sense, as UMeFate split-screen that has been implemented early in the development, as the core mechanics. Now anything regarding UI, or game mechanics is much simpler and more fluid.
Following changes to the restructuring mods system, all current models moved their location.
That breaks any map saves and saves construction blueprints, which use objects like chairs, beds etc. Naturally things will keep breaking with consecutive updates as all is in the early development stage.
Fortunately, the fix is relatively simple. But since there is no game update yet, this will be left for the future to discuss.
And that's all for today's update. 🙂
Until the next one 👋
Revolts now start with a bigger area
revolts "desired area" has a 1 in 100k chance of stoping calculation to make bigger cultures has a chance of not including the entire area to lower calculation pre war time
Revolts capital now starts in the center of one of the "blobs"
Revolts capital losing strength loss is now less
increased revolt starting strength
countries can now only run out of resoruces 1 time per war
countries now remove all other funding tags when running out of resources
new running out of resources message for when they are not already scrapping the barrel
can now choose game files location in settings
in pause menu you can now toggle 3D height map based on full,half and off (only visual) (sadly worked in editor but not in full build of version, will be looking into and hopefully quickly fixed in bug patch)
in pause menu you can now toggle 2D height map based on full,half and off (only visual)
decreased render distance of capital city markers so that you can't see them throe planet earth when they are on the other side
Removed micro nations from base big country map
Capitals that spawn in turned off continents are now relocated to a new random position
HEY! i added setting to enable vsync and also set a max FPS
i did this for you... because i love you...
as always, tell me if there are any issues! kiss kiss
