After being sealed up for many years…the tombs of the Amulet of Amunrun are finally ready to explore!
It has been a long journey to get to this point, with over x years in development, and I am so grateful for every explorer that joined me along the way! From x to y, you’ve heard it all, and now you get to experience this puzzling and mysterious world for yourself. The highlights for me, in the game’s development have been the following:
ENIGMAS.
Here is a classic example of an enigma you may find. While the goal is apparent to most gamers, the way to achieve it is not. Their main purpose was to create challenges in areas where the game may seem easier than others, as well as to heighten the game’s puzzle element further.
GAME PHYSICS.
I have to say that the wonderful and free open source software Blender, came in very handy! Thanks to its physics engine in particular, 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 puzzles in place.
Having now taken my fervent sketches and used them to create this 3D world of mystery, all that’s left to do is hear about your Amulet of Amunrun experience! As always thank you all for sticking with me through it all! It’s been an exciting journey. I’ve learned so much along the way and cannot wait to keep going!
If you like the game, please leave a review on the store page.
Be sure to celebrate with me on Twitter and Instagram too, as well as with fellow explorers in Discord.
Now grab your backpacks, sharpen those brains, and get ready to explore!
See you inside!
Final Journal Entry
Greetings, Explorers!
I am relieved you're here. If you have made it this far into the journal, congratulations! You're now about to start your own journey inside our pyramid. Now, let's get into the final journal entry.
There is a rule in software engineering called the ninety-ninety rule, which goes something like this:
“After finishing 90% of the game, there’s only 90% left”.
The Final Boss
That’s what finishing a video game feels like! Once you move from a prototype, to turning the features of the game into a completely playable version, there is the final boss: the polishing phase. It is, in my opinion, a strange phase: the game is done, it can be played and enjoyed from start to end, but you still have to continue working on it; battling with the devil hidden in every little detail, in order to provide the most enjoyable player experience. These details are sometimes so small, however, that one might wonder if anybody would notice.
The hardest part is triaging the details. Not all details are born equal and as time is a finite resource, one must make a decision on which detail to focus on, and how to tackle it. You'll realize too, that a small detail sometimes masks a much bigger problem that needs more time, making your to-do list longer rather than shorter. In a more pragmatic way, these details can range from altering the a sound or effect, adjusting musical arrangements, polishing the aspect of a small rock, or rearranging the papyrus ten times to have a more appealing layout, etc.
Sunrise Over The Pyramid
Despite this seemingly insurmountable amount of work however, this is also the time where the build really starts looking like a game! Playtesters enjoy test sessions without bugs, and as a developer, that’s honestly a big relief; in a sense, you finally crystallize the game’s full picture. Whereas before it was a work in progress with many lines of code, it's now software that stands on its own and can be enjoyed. And as a game developer, there’s a very peculiar feeling that happens when you see people playing your creation and enjoying it, and that for me, can only be labeled as relief. This idea born a few years back is now living and ready to be enjoyed, despite my fear around testing that the cards might be enjoyable, but the castle would not hold.
This is finally the time when you can start looking back at all the path traveled, because it’s now longer behind than in front. From the sketches to an actual 3D world, diving into the progress made is always a cherry on the cake after long hours of work; We were there and we are here, and now it’s better.
A Journey With A Destination
Now, after a few years of development filled with its twists and turns, The "Amulet of AmunRuuUUUN!" is finally ready to release in just 4 days time, this Wednesday April 27th! I can’t wait for you all to enjoy this amazing cooperative adventure, and to hear your feedback and joy whilst playing it.
Till then, make sure to wishlist the game on the Steam store and remember: if you pick up the game at launch, you’ll enjoy a 10% launch discount! Be sure to join our official Discord Server to talk with other explorers about the game too.
I wish you all a great day and can't wait to see you all play on launch day! April 27th!
The Amulet of Amunrun Releases on April 27, 2022!
[previewyoutube="g0PBnOwr8dY;full"]
Welcome Explorers! It has been a long journey up to this point, but we have finally seen the light inside the depths of the pyramid!
The Amulet of AmunRun is releasing on the 27th of April!
We are thrilled to finally see this come together, and we're excited to take you on this journey with us! The fun doesn't stop with just the release though, make sure to come on over to the official Amulet of Amunrun Discord server, take part in events, and meet other explorers who want to share their experiences with you.
Make sure to stop by our Steam Store and click the wishlist button to make sure you don't miss out on the fun!
Check out our posts on Twitter, and our Steam Forums for even more Amulet Of Amunrun, and we shall see you in the pyramids on April 27th!
Until then we hope to see you on release day in our Discord server!
Cheers,
Randall Amulet of Amunrun Community Management Team
Journal Entry #3 - Rules Of The Journey
Hello Explorers,
Anatomy Of A Risky Journey So I’d like to tackle an interesting (I think) discussion about what a video game actually is. To keep it simple, I would say it is a virtual world subjected to specific rules in which a player has to accomplish a goal. It is a very open ended definition, and some might argue that not all games follow this definition (what is the goal in The Sims? it has no specific end etc, but we all know it really ends with the pool haha), still though, generally I think it holds up pretty well. For the sake of this Journal Entry, I want to focus on 3 key words: rules, accomplishment, and goal.
A Book, A Movie, And A Comic Enters A Bar Accomplishment is, for me, the defining word that separates games from any other art piece/object/work in which you do not partake in the creation. You read a book but never write a word, you watch a movie but never act in it, etc. The events happen when you read or watch the medium it is in. In a video game though, it is a bit different. Things do not happen if you do not do anything.
Action is the center element that splits a video game from being a movie, you have to consciously make a decision and interact with this world to make anything happen within it. I think this is why (video) games are so enticing to so many: you get to be the active main protagonist in a world and write your own story, (yes, even though the story and the whole world has been planned by a game designer and such, no playthrough will be exactly the same, ask speed runners they’ll tell you). This uniqueness is exceptional, but it’s not the center of what I want to discuss.
Rule GoalBerg Machines Rules and Goals are the interesting bit for this devblog. I feel like a rule and a goal are actually the two faces of a single coin. You cannot accomplish a goal if a rule prevents you from doing so, and conversely there can be no goal if there are no rules (which in my opinion is one of the reasons some folks strive to find a goal in life when they feel like there are no rules, but this is a completely separate topic). A small painless challenge: the goal here is pretty explicit, the rules as well I’m sure some people will nitpick on my last sentence by saying “yeah but you can create your own goal” which I’ll answer with, “usually you give yourself a set of dedicated rules you abide by to create this goal”. Typically, Minecraft is a pretty goalless game where players and their creativity are making new explicit goals to achieve: “build a whole village”, “create a pyramid”, etc. But these goals are actually implicitly describing rules. What does building imply? Can I download a world made by someone else with a village in it? Does it satisfy your definition of build? Probably not. On the same aspect, what does village imply? If I randomly put squares here and there, can I call it a village? If I build a single house, is it a village? A fortress? This goal comes with (implicit) rules but nonetheless, it comes with rules.
So a game is basically a set of rules in my opinion. Now this becomes interesting (and soon is connected back to The Pyramid of AmunRun). A game is an interesting eldritch monster of rules: they come in all forms and shapes. From the simple shifumi, with very few explicit rules, to the sublim baba is where the players can partially rewrite the rules as they play. There exists a metric video game ton of ways of approaching those rules in a video game and in the kind of game I’m developing at the moment, I’m focusing on one kind: the game where the rule is to find the rules.
Example of an enigma: while the goal is pretty obvious in this situation, the way to achieve it is not.
Enigma vs Challenge In my previous paragraph, I highlighted explicitly and implicitly for a reason. This difference is at the core distinction between puzzle/enigma based games, and all other games. In my own jargon, I like to call one side of the coin an enigma, and the other a challenge. (I agree this nomenclatura could be better, but stay with me). For me a challenge is a trial where a given set of rules has to be followed in order to reach a set of goals. On the other hand, an enigma is a trial where a given set of goals is provided to reach a set of rules.
In the first one, the rule set is explicit while in the second, it is implicit. So this probably seems pretty off putting, so let me give you a real world example where this difference has been observed. In World of Warcraft, at the beginning of the game, (some) quests were closer to unguided formats than the direct quest you see nowadays. The quest was written with some hints like “bring me 10’000 quilboar’s swords”, but nothing would tell you where to find those quilboar, nor how to get a sword. So you would spend time walking around to find those quilboar, and then opening chests and genociding virtual characters to get your swords. The rule about the location of the quilboar and the one about the location of the weapons were implicit. They exist, they are there but you have to discover them. Nowadays a non diegetic indicator on the map tells you exactly where those guys are and if you need to kill them or not to get the swords, the rules are now explicit.
Interestingly, such an example is a big source of inspiration for my game. When Indiana Jones must choose a holy grail, the goal is implicit: “find the right grail and drink from it” while the rule that defines “right grail” is implicit and must be guessed.
And I have to say that personally, I enjoyed the former more than the latter. The former motivates exploration instead of exploitation. When you do not know everything, you have to try, when you know everything you have to optimize. Thus the games I'm making are oriented towards exploration.
From Anarchy To Procedural Democracy All this introductory text, and for what? Simply to highlight that the design process between an enigma and a challenge is not that different after all. On one hand you have to focus on providing a set of clear rules to make a goal interesting and entertaining to reach. While on the other, you have to design a set of implicit rules that make an obvious goal reachable. But here is the catch, we -the players, are much more used to being given rules and following them to the goal.
I usually follow one of two design processes for these enigmas or challenges:
Either bottom-up, where I have a specific goal in mind (an object /code) I want the players to find, and I can then design a set of rules that will be guessed on top of it.
Or, I take the top down road, when I have a specific process I’d like the players to use (finding similarities or patterns, deducting rules from trials, etc).
Then comes the most difficult part; making this guess & trial r approach pleasing. It should be hard enough that it becomes rewarding to find the solution (An enigma in the style of “oh? A red keyhole, I wonder where the red key can go?”, are not that rewarding in my opinion), but also not convoluted enough for it to become painful to solve. unfortunately, after seeing many folks play those kinds of games, there is a big subjective aspect to it. During my playtests I have seen people struggle on an enigma that has been more or less instantaneously solved by another group. Luckily for me there is a set of tools that can be used to provide hints and guidance without explicitly doing so.
Typically, and probably the best known one, is level design. By putting dark corners and lighter ones, by arranging a room in specific fashion, I can (try) to give non verbal cues that can direct the players attention to the object of interest.
First view of the game after starting, I don’t think anyone will doubt what to do in this room despite all the stuff in there.
One last topic I'd like to cover is one that was asked to me during an interview a few years back about red herrings. There is a whole lot that could be said about it, but generally I don’t think they are a great approach at making enigmas. For example, having all the tools required to do a task and finding the right combination is rewarding, while having too many tools and needing to find the right one just feels cumbersome. So in my design process, I try to avoid misleading the players as much as possible. Ideally, I’d like them to always be on the right path, but without knowing it.
All in all, that’s a lot of text but I couldn’t imagine approaching game design without providing a bit of reading material. It is a very complex and subjective topic, so I thought a “few” lines of text would be great to expand on my personal views of the process.
Thank you for sticking with me throughout this entry, and most importantly for continuing to support Amulet of Amunrun! We appreciate the support and would love to have you in our Discord community where you can chat with other explorers and talk about all the puzzles to your heart’s content!
Cheers,
Louis Fruits of Yggdrasil Sarl
Dev Log #2 - Nothing But Dust
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.
https://www.youtube.com/watch?v=QK-MrrO30Og 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.
https://www.youtube.com/watch?v=nA4_zCod9cM
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
Dev Log #1 - A Fresh Start
Hey there everyone and welcome to my first Dev Log for the upcoming development cycle! I am getting close to the end of the development (crazy I know), so it’s time to bring back these updates on a regular cadence.
Today, I want to take a look at a room that I designed for the game and teased in our last update, that includes a few interesting mechanics, and how I went about creating it.
The Portal Room:
The Inspiration:
Unlike most game developers, I am a scientist at heart. This means that geometries, especially those of a non-euclidean nature, have always been particularly satisfying to imagine and create.
If you grew up in the nineties, or even watched cartoons, you would’ve seen these geometries. One that will never go out of style and that struck me a lot as a kid, was the Scooby Doo corridor chase! Who remembers this? https://www.youtube.com/watch?v=RcWxQUMLsLA
I always thought those scenes were funny when I was younger, but they’re also frightening in a sense if you think about it. Alongside the physical absurdities in those scenes that our brains can’t process properly, there’s also clearly a danger running after those characters, with no way to know where it’s coming from or where it is going.
These geometries have also been used in video games as well as animation. We see it in video game classics such as the portal series for example, as well as in more modern titles such as the amazing Superliminal!
So from the very beginning, I knew I wanted this in my game! I wasn’t super excited about adding a gun to shoot portals however, so I used what I had at my disposal: Two players, a space I could modulate at will, and a source of danger coming after you. Thanks to Scooby Doo, all I had to do was to implement it in-game!
The Technique:
With all of that in mind, and having done the research, I went about finding solutions to make it happen in the Unreal Engine. Programming-wise, non-euclidean geometries are very interesting to look at, but quite tricky to implement. Depending on how the game is made, it can be a walk in the park (not like central park though, more like a northern alaskan park with polar bears).
Typically a game relying on cast casting or path tracing has a much easier time dealing with those kinds of geometries. Unfortunately for me, The Amulet of AmunRun follows a much more traditional rendering approach which forced me to use other tricks. I did not reinvent the wheel however and went with the standard trick in the trick book; rendering the scene multiple times. So looking through the portal is like looking through a TV that changes the camera viewpoint based on where you are relative to the TV.
And this is how you get an ancient pyramid Scooby Doo chase! Fascinating, right? I’ll not be spoiling what’s chasing you today however. ;) You’ll have to find for yourself in The Amulet of Amunrun, coming soon!
I hope you enjoyed my devlog and found it interesting. Rest assured, throughout 2022, I’ll be back very soon with more!
In the meantime, you can try the Demo, and let me know what you think in our Discord!
Take care!
Louis Fruits of Yggdrasil Sarl
Mid-Summer Update !
Hello everyone !
Introduction
Time has come for a new update on the state of The Amulet of AmunRuuUUUN. I will split this post in 2 parts: The first one will be general and without spoilers and the second part will dive a bit further in the details of the first part, but with spoilers this time. I am doing so to offer the possibility to whoever would like to, to keep track of the development of the game without discovering parts of the game and maintain as much mystery as possible.
Stone after stone towards the light at the end of the tunnel
The pyramid has grown quite well in the last months. We are now having 20 different enigmas & challenges spread in around 10 different rooms and corridors. 4 iconic moments have been implemented (think the boulder run of the demo that is, for people born in the previous century like me, extremely iconic of the action adventure genre) and (at least) 2 more are to come to complete the epicness of the game.
Developmentwise, I am very happy about the current state, due to additions I have made during these last few months, the game will probably be longer than originally planned but I think (probably) no one will complain about that. So far, I'd estimate the game is nearing 60~70% completion for the development phase. I am starting to plan some internal play tests to begin polishing what has already been done which is a sign of the end approaching.
To conclude the spoilerless part, I'm working hard on developing the game and if you'd like to follow the updates more closely, you can follow me on the Fruits of Yggdrasil Twitter account . If you'd like to support us, please talk about the game and spread the word that the pyramid is soon opening that would help me immensly.
For those leaving the post here, have a nice day and take care ! For the rest, the juicy stuff is coming.
The sand under the rug
Welcome to all of you whose curiosity cannot be contained. I'll be expanding further on the 2 iconic moments that have been implemented.
The first one is ... a maze !
I have been pondering about adding a maze and in what form into the game. For someone like me who's been born in the previous century, a maze is an element that has been present in the action-adventure genre in many different movies and it's been a hallmark of many myths from different places around the world. The tricky thing with a maze is that its goal is to loose anyone who enters it, and from a gameplay perspective, the frustration that comes with being completely lost is not something particularly enjoyable. So I devised the maze with two main properties in mind: first, it must be fun and provide an enjoyable moment by proposing interesting enigmas and challenges or moments (think the very famous "I told you so" that you'll be able to exchange at many points during the maze). Secondly, intensity. I didn't want the maze to be a painfully long experience to start over again every time the player is lost, thus I punctuated it with many checkpoints and kept it relatively short. I am pretty satisfied with the result and hope you'll enjoy losing yourself in the maze and blaming it on your mate. I obviously can't really show pictures of the maze (at least not top view) so here are some things you might find while cruising through it.
The second one will require you to think with portals. I will not go much further on this one but I'll give you food for your imagination in the form of those two pictures:
I hope you enjoyed this post and wish you all a good day and take care !
