Multiverse Designer News

Hi everyone! These last few weeks, we’ve been hard at work, mostly improving performance and overall smoothness but also implementing new assets. You can see below some cool screenshots of the new maps we have put into Multiverse Designers – although if you follow us on Twitter or Instagram you might have already seen them (we've posted some more over there as of lately, go check it out!)

Wait a second – you don’t follow us on social media? Alright, go there and do it now. We’ll wait for you. Here are the screenshots in the meantime (click on the images to enlarge them).





Done now? Alright, we can go on then. As I was saying, we’ve been working on optimization, and this is already making a noticeable difference, resulting in a more seamless and enjoyable game. That’s not to say we have not had some setbacks, though. We updated Multiverse Designer to Unreal Engine 5.4, its latest version, which can be significantly faster; but it created serious stability problems, and after extensive testing we decided to roll it back to UE 5.3. This version is much more reliable, and we think getting a 5% increase in speed (just a placeholder number) is not worth a less stable version.

But we are still way ahead of schedule – by launching the beta early, we have had more time to gather valuable feedback and make necessary improvements; and despite the setbacks we have experienced, everything is still on track to releasing Multiverse Designer to all backers in the near future. While we work on the other features that will come in the next updates, we ask to everyone tho stay tuned --in the next month we will be releasing the first stable version to all our backers!

Thanks to all our community for your continued support – we can’t wait to put Multiverse Designer in your hands and see what you create with it!

Hi folks! As every Friday, we want to give you a sneak peek at what we are doing right now in the development of Multiverse Designer. This week we got a lot of new assets that we’ll be putting into the level editor very soon, and they all have something in common… but we’ll get to that in just a few lines; let’s talk about something else before, for context.

During the Kickstarter campaign, and particularly during the livestreams, we got a specific question very often: would players be able to enter the buildings? The answer to that is “yes, but only some” – there are assets that are just the front of a building, but are empty inside, and you cannot actually enter them; they’re basically props. Others have functioning front doors, and inside got rooms, several stories, stairs – everything you expect in, well, a building. Thus, when you design a city, town or whatever, you’re supposed to make interactive only the buildings that are important to the story, while the rest are just there for the looks.

You might think, “but I want to design a whole town full of buildings that you can explore!”. But there is a reason to do it this way: performance. Think of it: when you’re designing an adventure in a city, do you actually sit down to decide what’s inside every single building of it? Probably not, because that would take hundreds of hours. You design the important places (maybe a few extra random houses in case your players go rogue) and that’s it. If things go off the script so much that you run out of pre-defined resources, either you invent them on the fly or just tell your players “look, that place is not relevant to the story, stop trying to get into random places or I’ll just go grab the Trivial Pursuit from the attic”.

Well, it’s kind of the same with your computer. A building that is fully interactive means millions of polygons, physics calculations and many other things that your computer has to take care of. A whole town where you can enter and explore every building? Best case scenario, your game would be laggy and stuttering. If you do want to have different pre-designed buildings at hand in case your players are the kind of murder-hobos roguish characters that enjoy entering random buildings, you can always teleport your players there.

But this whole conversation made us realize that being able to enter buildings was a big thing for you when it comes to immersion, so while the point of “if every building were interactive your computer would catch fire” still stands, we wanted to give you as many architectural options as possible. So this week we got a package of assets with a lot of buildings you can enter and explore. And having said that, here are just some of these buildings, all from different settings as you can see, that you’ll be able to place in your towns and cities in Multiverse Designer! Click on these images to enlarge them:









Have a nice and very rpg-ish weekend!

Hey everyone! After we released the first beta version of Multiverse Designer, we expected to spend several weeks squashing bugs and fixing technical issues. But the original build was stabler than even we expected, so we could shift our focus from putting out fires to improving the general performance of our software. In the next dev blogs, we want to explain a little bit what we are doing right now; this first post will focus on the optimization efforts we are undertaking.

The main work we are doing these days is related to optimizing all the assets we have so far in Multiverse Designer to make sure we can enable Nanite in them. Before we move on to explain how we are doing this, we have to answer the obvious question: what exactly is Nanite? As you may recall, Multiverse Designer uses Unreal Engine; for those of you who aren’t too tech-savvy, UE is a 3D graphics engine, mostly (but not only) used for games. A game engine handles much more than graphics, despite what the average gamer often thinks – it’s a complex software framework with many different features, libraries and support programs. And Nanite is one of the major features of Unreal Engine 5, the latest version of the engine.

To be more specific, Nanite lets developers import high-detailed photographic source material into games, so they don’t have to create new 3D assets from scratch -- which would still need to be optimized, on top of it! For example, without it we wouldn’t be able to use Kitbash3D assets without a significant impact on performance. A good example of this is the cyberpunk map we created during the Kickstarter campaign: many of its assets didn’t have Nanite enabled, and due to that, the map caused crashes – because its 3D assets were eating GPU memory like popcorn!

[previewyoutube][/previewyoutube]

So what we are doing right now is going over all the 3D assets we have (which weren’t necessarily created for Unreal Engine) and making the necessary adjustments so they are all compatible with Nanite, in order to make them available and usable (which also means, let’s not forget it, fully customizable) on Multiverse Designer. This isn’t exactly easy, and considering we’ve got thousands of assets, it can be quite tedious too – so we have developed a tool to analyze them and make the necessary adjustments, revamping the loading system and working with some internal procedures to help bulk change assets into Nanite.

The biggest challenge we are facing is the fact that Nanite -- which allows us to use assets made up of millions of polygons - does not work on transparent objects. Our job is, for example, to take a building that contains 4 million polygons and separate it into two parts, one that has few transparent polygons and the other that has many normal polygons and apply Nanite to the second. Now multiply this by 5 thousand assets and you will get an idea of what we’re talking about!

Even so, it’s not a drag and drop thing; it does take some individual checking and tweaking. It takes time, but we’re getting there, and soon we’ll be able to move on to other tasks. The good thing is that making assets fully compatible with Nanite also has the advantage of optimizing GPU memory usage, so when this process is completed Multiverse Designer will also see great improvements in performance.

Mind you, it’s not the only thing we’re doing; in parallel, we are working in Criteria, In the next dev blog, we’ll talk about the current work in Criteria, the system we use to codify and implement TTRPG rules, and the monster/NPC generator we are creating. See you next week!

[previewyoutube][/previewyoutube]

Multiverse Designer started its beta about a month ago. Thanks to our beta testers, we are making great progress in the development, and we are way ahead of schedule, looking forward to releasing Multiverse Designer to all our backers! Here's a sample of the amazing creations our first testers have done in this month. Thanks to all our testers for their contributions, and particularly to those who sent us their creations and gave us permission to use them for this video.

Today we will explain the new features implemented in the Multiverse Designer beta, what we are working in for the next update, and other details about the development. Ask us anything you want to know about Multiverse Designer!