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