Gather round explorers, as I release my first Dev Log of 2022! These will continue to be released on a monthly basis until the launch of the game, so be sure to check in now and then to see what’s up. Now, without further ado, let’s excavate the hidden ruins of The Amulet of AmunRun!



Stone Is But Compacted Dust

In pop culture and movies, a common element that always struck my mind with many archeological adventures is the “delicacy and extreme attention used to handle millennial artifacts,” but then the complete, utter chaos that always ensues after handling the item. Most times after our “Hero” is done doing whatever it is that they do. Buildings, temples, and even caverns, surprisingly always seem to self-destruct. I mean, it’s pretty obvious that the heavily armed, gun-slinging chick might not be the best fit to handle fragile pots (looking at you, Miss Croft). I still find it pretty surprising that ancient civilizations decided to booby trap the whole place rather than just not building it in the first place.

So, as a historian at heart, I decided to follow logic and reason. Even if it feels underwhelming to many of you, I wanted to make sure realism would become a core value of my game design.

….

Actually, just kidding, everything is going to crumble and explode!!! That brings us to today’s Dev Log, which is all about destroying everything and blowing stuff up in a convincing manner.

Ladies & Gentlemen Don’t Look At Explosions

The main course of this update is going to be about physics. The core idea of “destroying something” is to break it’s integrity in such a way that it will create a cascade of critical failures, leaving us with nothing but dust at the end.

The good news here is: that’s pretty easy to do (don’t quote me on this). Code a physics engine using Newton's laws, fix stability and voilà. Luckily, I’m using Unreal Engine, so it comes with the engine itself, easy peasy. I would just have to put all the different destructible elements I want in the correct places, set up the ancient egyptian explosives (that’s a thing I’m pretty sure), and trigger them as the players move along. Sounds easy, right?

Wrong! Or at least, wrong in my case. In a single player game that would work very well, up until the simulation is too big to fit in the player's computers, but for a multiplayer game? It’s a whole different ordeal.

The Computerverse Of Physics

Now, contrary to popular belief, computers don’t exactly do the same thing all the time. I'm not gonna go into details here, but the idea is that different computers might do some computations ever so slightly differently. In doing so, we run into a concept known as floating point determinism. This means that A + B on computer X, is different from A + B on computer Y. That is fine for single player games, as every computer will yield a result only seen by itself, and the difference between multiple computers is going to be insignificant and invisible to the human eye in most simulations. BUT, for multiplayer games, you have different computers talking to each other through the internet, and in the case of physics simulation, it can cascade into completely diverging physics worlds.

You probably are familiar with the butterfly effect, and in replicated physics simulations, it happens A LOT; small changes will lead to bigger changes, over and over, and cascade the scene into a very different result for each player. This makes simulating the destruction of the pyramid on every computer either a really bad idea, or a really expensive one. As I don’t want adventurers to evolve in different physical realities though, I had to come up with another solution.

Destiny Better Stay Tiny

Instead of synchronizing the simulations on different computers, I found it easier to not simulate anything, or rather, I’m only going to simulate it once. My first thought towards a solution was to have an authoritative server run the simulation and transmit it to the clients, thus making everyone synchronized in the same physical crumbling world; but unfortunately, this would come with a pretty hefty price in terms of internet usage.Turns out that sending updates about thousands of moving objects multiple times a second is a pretty big challenge, albeit not insurmountable. It seemed like a good solution that I kept in mind, however after some more thinking about the situation, I went for something even simpler.

The solution I went with is probably the simplest you can have in this situation, but it does have a single massive drawback (luckily, not in my case). The idea is to simulate the physics once, record it, and store it within the game itself. Then all the players will just play the recorded version, in a synchronized fashion. This method’s drawback is that the player cannot interact with the simulation, for example, preventing or interfering with objects moving into one another or destroying each other. So in the end, it made perfect sense that the interaction between players and the crumbling environment would be kept to a minimum anyways. After all, in The Amulet of Amunrun, the falling debris are carefully carved metric cubic ton stones and our heroes are not really superhumans…A slight advantage to this is that I also get to keep complete control over the simulation, and can avoid weird, rare situations where small misalignments would make the scene explode.

Fine Tools For A Tine Fool

Now, having this solution in mind, it was time to implement it! I have to say that the wonderful and free open source software Blender, came in very handy! Thanks to Blender and its physics engine, I could register simulations and export them to Unreal. Then I just had to use a lot of magic and careful planning in order to put all the pieces of the puzzle in place.





I hope you’ll enjoy this adventure as much as I loved making it, and trust me; it’s shaping up to be an epic and memorable one in my books!



I hope you’ve had a great start to your 2022 and see y’all soon!

Louis
Fruits of Yggdrasil Sarl