Category: Follow-up

A Walkthrough of "The Hermetic Order of Alchemists"

A Guide for the Prospective Alchemist

The following is a walkthrough of my Alakajam game, "The Hermetic Order of Alchemists".

It describes not only the steps necessary, but also why the steps are necessary, which might help you in the later steps or Trials.

...or you can just follow the bolded actions, if you just want to move ahead to the ending.

Trial 1: Produce a Resum Crystal
Objective:

Both the goal and the initial substance has the same amount and type of elements. So you need to break the initial Pure Resum substances down into their Resum elements. Then, make them bond into the goal substance Crystallized Crystal.

Solution:
Step 1:

By hovering the mouse over the starting substances, you can see that Pure Resum has a breaking point of Weak Heat. So start by applying Weak Heat (or hotter). This breaks the substances into 4 elements of Resum.

Step 2:

Hover the mouse over the Crystallized Resum under the Expected trial result, or look it up in the Grimoire. Note that the Bonding point of Crystallized Resum is Strong Cold. Apply Strong Cold (or colder) to form the 4 Resum Elements into Crystallized Resum. Note that if you had instead applied Weak Cold or Room Temperature, the Elements would turn back into Pure Resum instead, since the Bonding point of Pure Resum is Room Temperature. The Reactivity of Crystallized Resum is 8, which is higher than Pure Resum's Reactivity of 2. This is why Crystallized Resum form before Pure Resum, if the temperature you apply, is cold enough to be the same (or colder) than the Bonding point of both of these materials.

Trial 2: Produce Bluemetal from raw materials.
Objective:

The starting substances contain two extra Pyx (green) elements, and 1 extra Resum (purple) element, compared to your goal. You therefore need to get rid of these. In the Grimoire, you can see that the substance of Resrem contains exactly the combination of elements you need to remove. Therefore, your goal is to bond some of the starting elements into Resrem, so that you can remove them. The rest of the elements will then be Bluemetal.

Solution:
Step 1:

Start by breaking the starting substances. Hovering over each of them, you can see that the warmest breaking point across them is Searing Heat. So start by Applying Searing heat.

Step 2:

Now, you must rebond the elements. The objective is to bond your surplus elements into a single substance (Resrem), which you can then remove. Looking in the Grimoire, you can see that Resrem has a bonding temperature of Strong Cold. Apply Strong Cold in order to bond the elements into a Resrem and a Bluemetal.

Step 3:

Finally, use filter to remove the smallest substance. Since Resrem has a size of 3 elements, and Bluemetal has a size of 5 elements, this will remove the Resrem, but leave the Bluemetal in the solution.

Trial 3: Produce a Resum Crystal, while getting rid of impurities.
Objective:

The starting substances contain four extra Pyx (green) elements, compared to your goal. You therefore need to get rid of these. Unfortunately, Resrem is more reactive (and has the same Bonding point) than Crystallized Resum, so you can't use the filtering strategy from Trial 2. Instead you have to form the Resum elements into stable substances, and then purge the unbonded Pyx.

Solution:
Step 1:

Start by breaking the starting substances. Hovering over each of them, you can see that the warmest breaking point across them is Searing Heat. So start by applying Searing heat.

Step 2:

Looking in the Grimoire, you can see that the only substance which only contains Pyx is Pure Pyx. Unfortunately, at its Weak Cold Bonding point, you also find Duresrem, which contains both Pyx and Resum, and which has a higher reactivity than Pure Pyx. So in this case, you cannot isolate the Pyx-elements for filtering. But what you can do, it to find a substance which can bond all of the Resum elements. Then you can purge the unbonded Pyx-elements. In the Grimoire, there are two substances which only contains Resum: Crystallized Resum have a bonding point of Strong Cold, but so does Resrem, and Resrem has a higher Reactivity. However, Pure Resum has a bonding point of Room Temperature, which is warmer than any substance containing Pyx. So apply Room Temperature, in order to bond the Resum elements into Pure Resum, leaving the Pyx elements unbonded.

Step 3:

Use Purge to remove the unbonded Pyx elements.

Step 4:

As in Trial 1, use Weak Heat to break the Pure Resum substances.

Step 5:

Finally, as in Trial 1, use Strong Cold to bond the Resum elements into Crystallized Resum.

Trial 4: Reduce substances to Oprem, while getting rid of impurities.
Objective:

Similar to Trial 3, you need to remove extra elements. But the Reactivity of the possible substances means, that you cannot just break the starting substances, and then apply some degree of cold. Instead, you need to isolate and remove the extra elements, in this case two elements of Resum, before you can bond the remaining elements into your goal substances.

Solution:
Step 1:

Start by breaking the starting substances. Hovering over each of them, you can see that the warmest breaking point across them is Searing Heat. So start by Applying Searing heat.

Step 2:

In Trial 4 you saw that Pure Resum can be easily isolated, since it is the only substance which bonds at Room Temperature. So next, apply Room Temperature.

Step 3:

Now you can use Filter to remove the Pure Resum.

Step 4:

As Oprem has a bonding point of Strong Cold, finally apply Strong Cold to form the remaining elements into Oprem.

Trial 5: Refine Equilibrica from inferior substances.
Objective:

As for earlier Trials, the supplied substances contain extra elements which much be removed. As in Trial 2, the two extra Pyx (green) elements, and 1 extra Resum (purple) element correspond to the elements in Resrem. However, since there are enough elements to create two Resrem substances, you need to bind some of the elements into something different. This leaves only enough elements to bind into a single Resrem, which can then be removed.

Solution:
Step 1:

Start by breaking the starting substances. Hovering over each of them, you can see that the warmest breaking point across them is Searing Heat. So start by Applying Searing heat.

Step 2:

Pure Optium is both very Reactive, and rather temperature stable (it bonds at Freezing Cold, and breaks up at Strong Heat). Tying up the Optium elements first, will ensure that they do not "get in the way" of the later bonding into Resrem. So next, apply Freezing Cold.

Step 3:

The previous step also formed two Resrem elements. You therefore need to break these back into elements. Apply Weak Heat to do so. The Pure Optium will not be changed, since its breaking point is Strong Heat.

Step 4:

Now, you need to find a way to leave only enough unbonded elements to bond into a single Resrem. Since that bonds around a single Resum element, you can bind two Resum elements into Pure Resum, leaving a single unbonded Resum element. As you saw earlier, Pure Resum can be bonded at Room Temperature, so apply Room Temperature next.

Step 5:

Now you can finally form a single Resrem, by applying Strong Cold.

Step 6:

Resrem is the largest substance, as it contains three elements. So Separate it with the Separate tool.

Step 7:

Break up the previously bonded substances, by applying Searing Heat.

Step 8:

Finally bond the elements into Equilibrica by applying Weak Cold.

Final Trial: Refine Bluemetal from Equilibrica
Objective:

The final trial is the hardest, since there are enough elements to form any substance except Crystallized Resuml. Hence, the solution requires mastery of the various properties of these substances. You need to get rid of all the extra elements: 7 Pyx elements, and one Optium element. A logical approach would be to try to get rid of the extra Optium element first, since Optium is a part of most of the substances. After that, you can focus on getting rid of the extra Pyx.

Solution:
Step 1:

Start by breaking the starting substances. Hovering over each of them, you can see that the warmest breaking point across them is Searing Heat. So tart by Applying Searing heat.

Step 2:

Removing the single extra Optium element is the easiest. Start by forming the two other Optium elements into Pure Optium. Do this by applying Freezing Cold.

Step 3:

Purge the unbonded Optium element. As an added bonus, this also gets rid of one of one of the extra Pyx elements.

Step 4:

Break down all the temporary substances again, by applying Strong Heat.

Step 5:

Since there is an even amount of Pyx Elements left, the next sub goal is to merge them into Pure Pyx pairs, which can then be removed. This would leave only the correct elements. But unfortunately, Pure Pyx has the lowest Reactivity of all substances, and a bonding temperature of Weak Cold. This means that almost any other possible substance will bond before Pure Pyx will. The next step is therefore to bind enough of the Optium and Resum elements, so that the remaining Pyx elements can only bond into Pure Pyx. The first step is to bind the Optium Elements into Pure Optium. Do this by applying Freezing Cold.

Step 6:

Apply Weak Heat to break up the Resrem. This does not affect the Pure Optium.

Step 7:

Looking in the Grimoire, you can see that if you can get 2 of the remaining 3 Resum elements to bond into Pure Resum, the remaining Resum element can only bond into Resrem. As you saw earlier, Pure Resum is easy to bond, since it is the only substance which bonds at Room Temperature. So apply Room Temperature next.

Step 8:

Now the remaining elements can only form two different substances: Resrem or Pure Pyx. And as Pure Pyx bonds at a colder temperature than Resrem, you can choose which substance to bond. Apply Weak Cold to form the remaining Pyx into Pure Pyx pairs.

Step 9:

Apply Strong Heat, in order to break the Pure Resum and Pure Optium back into unbonded elements. As Pure Pyx has a breaking point of Searing Heat, these are left unbroken.

Step 10:

Now you can finally get rid of the Pyx, by filtering!

Step 11:

Bluemetal bonds at Weak Cold, so apply Weak Cold in order to bond the remaining elements.

Simple data-driven game design

A simple example of data-driven game design in "Above Your Clearance"

In my latest game, I experimented with making my game objects data-driven.

At its core, the concept of data-driven design is to avoid hard-coding the game objects and game logic into the game code. You can implement this to various degrees. For example, instead of defining your different game objects as different Java classes, you can instead define a generic game object structure. You can then define properties and types that you can then apply to these generic objects. In this way, you can "assemble" game objects dynamically, using these properties and types. And your game engine then uses these to handle the game logic. This is the approach used in Entity Component Systems for instance. You could even implement your game-specific logic in a scripting language, which you could then maintain using external tools.

There are several advantages to such an approach. As your game objects are now data instead of code, the game can import them from external data files. You can then alter these files, for instance using an external editor. This means that designers (or modders!) can tweak the game logic, without requiring any code changes. You also get a clear distinction between the game code and the game logic.

The structure of the game

"Above Your Clearance" is a short adventure-game, which follows the format of classic "choose your own path" adventures. This means that the game has a very simple structure. The game presents you with a situation, and then you get a number of choices. Each choice will potentially change the state of the game world, and then move you to a new situation. I designed this structure as series of nodes, connected by choices, which can be simplified into the following diagram:

The flow of the game

Game concepts

I also introduced two resources to the game, credits (money) and clones (lives). If the player run out of either, he loses the game. Additionally, I also included the concept of "plot flags", in order to track the choices made by the player. This means that the game logic boils down to the following concepts:

  • The game tracks which node is currently the active node. The active node is the node which is currently being displayed to the player.
  • A node has a description, which the player can read. It also has a list of choices, which the player chooses from, in order to change to the next node.
  • A choice has a description, describing the choice to the player. It also has a destination, which is the node which will become active if the player chooses this choice. In addition, a choice has a requirement, which checks e.g. a specific plot flag. If it doesn't pass, the choice will not be visible to the player. Finally, a choice can trigger one or more effects. An effect is a specific change to the game world, for instance setting a plot flag, or changing the amount of credits possessed by the player.
  • A requirement is a combination of the type of resource and a value. The game logic uses these to check the fulfillment of the requirement.
  • An effect is a combination of the type of resource and a value. The game logic uses these to change the specified resource by the given amount (or change the specified plot flag).
  • When the player selects a choice, the game logic will apply any effects related to that choice. It will then check whether the player has run out of any resources. If not, it will change the current node to the destination.

A data-driven design approach

As the concepts above include game logic, I had to isolate this from the concepts themselves. Specifically, there is logic to check the requirements, to apply the effects, and to change the active node. As I did not want to implement a scripting language for this game, some hard-coded game logic was necessary.

One approach could be to have different classes for each type of effect and requirement. Those classes would contain a Java-method to apply the the specific effect or perform the specific check. However, this would mean that these objects would contain game-specific logic.

Instead, I implemented a type property for these classes, with a type for each specific effect or requirement. For instance, I implemented a type for "change the number of credits", a type for "set plot flag", etc. I then combined this with a numeric property that specified the magnitude of the effect.

This meant that I could move the game logic into the game code itself. I implemented the game logic itself as Java methods, which would get the effect or requirement as an input parameter. These methods could then use the type and magnitude on the game object, to determine how to handle it.

Implementation

See the source code

Designing a GUI to handle the above concepts was relatively simple. At any given moment, the player only sees the active node, and the choices related to this node. So I made a GUI to display this information (as well as the current resources). When the player presses a button, it applies the corresponding choice to the game world. It then refreshes the GUI with the contents of the new active node:

GUI mockup

As for the implementation of the concepts above, the data model consists of four data-driven classes:

  • A Node class, which contains a description, a node-number and a list of Choice objects.
  • A Choice class, which contains a description, a Requirement object, a destination node number, and a list of Effect objects.
  • A Requirement class, which contains a type and a magnitude.
  • An Effect class, which contains a type and a magnitude.

Each of these classes only contains properties, no game logic. It would therefore be possible to import them from an external data file. The GUI dynamically shows the currently active Node object. It also determines which choice buttons should be active (depending on their Requirement object). And the choice buttons call the internal game logic, with their corresponding Choice object as a parameter. In all cases, the data-driven classes contain no game logic, only information about how the game logic should handle them.

Try "Above Your Clearance" now, to see the concepts in action!

Conclusion

Hard-coding your game logic directly into your game objects is fast, but it can be inflexible. By using data-driven design, you can handle your game objects and game logic as data, instead of code. This means that you can keep the code separate from your game objects.

Instead, you implement properties corresponding to the game logic you want to support. You can then assign these properties to your game objects. This can make it easier for non-coders to customize and tweak your game play. In addition, this also makes it easier for your game to support external editors, and even modding.