Hi folks!

Moving on to something different for this post, I want to talk about our base design idea for the overworld maps.

From the early days, we knew we wanted to have node traversal akin to FTL. The first issue was that our map is not space-based (and therefore allowed easy random node generation) but rather land-based. This meant generating random node positions could result in them being placed in logically inaccessible areas like seas, mountain peaks and similar. Our first maps were hand made and hand linked to create a general feeling of moving through the world. Encounters were hand placed at first, and later randomly assigned to each node.



For a long time, the movement on the overworld map was undirected, meaning you could go to any node, even if it was already visited. This would mean you’d get no rewards for going there, but based on how the map was linked, you could visit every node on the map before reaching the end. We didn’t really feel this was good because the players felt no sense of urgency, and the choice of taking one path or the other was lost. We needed a way to rush the player to the final node in the zone. The problem was we were directing the player to go towards the danger (as defined by the story), whereas in FTL the player was running away from danger. One of the first methods to solve this was adding a timer during which the player had to reach the end node. This was pretty much a failure because the players didn’t understand the timer at all (it was badly presented), and if it ran out, the game would straight-up end. This was really bad.

After that, we tried adding an enemy unit that moved across the world and destroyed nodes in order to force players to choose which special reward nodes to rush to. These enemy units would randomly spawn across the world every so often and move after every three moves the player made. Instead of the hard “game over” rule when the timer elapsed, we’d have the final enemy unit move to the player and initiate a very tough fight. Most of these attempts weren’t very well explained, and we kept coming up with better solutions to the core problem.



In the end, we decided that we’d just make the links between nodes be one way. This gets rid of the problems presented by the other solutions and solves the initial problem of having a sense of urgency and choice - moving to a location means you wouldn’t be able to reach a lot of the other locations. In some sense, it’s similar to the map traversal in Slay the Spire. The very last thing we added (fairly recently, last month) is random node layout generation. We created a tool that can author various node layout configurations. We then use some graph replacement methods to replace the few nodes we place on the world with a more dense network of nodes. How well this will work still has to be seen, as it’s a fairly new tool in our toolbox.

Thanks for reading! Come back next week for the start of the zone 2 showcase. Spoiler alert: its got snow! If you want to chat with us, come join the Discord server for the Hand of Merlin, or follow me on Twitter.

MarkoP

Hi everyone!

What do you get when you cross a Guardian and an ability? A Spell! That is exactly the topic I want to talk about in this post.

While not every detail about the Spells is finalized, I can at least talk about their idea and role in the game. We had the concept of Spells from as early as I can remember being on the project before we even had Guardians. The idea is that the Guardians have their own set of abilities only they can use. Each guardian grants their powers to Merlin after encountering them in the world enough times. This is represented by unlocking that Guardians “Core”, which, in sci-fi parlance, would be a power core that fuels a ship’s systems. In terms of lowly earthlings from the middle ages, these are powerful spells that just happen. Lowly earthlings have no knowledge about no “Cores”.



The role of Spells is to provide additional power in the fight against the enemy invasion. When you don’t think you can handle the enemy, just use a Spell and smack that thing back into oblivion! Or just, like, deal some damage or whatever. Spells are meant to be much, much more powerful than anything seen or known by the lower planes. These things pack a punch or do some other unique effects that no ordinary man can pull off, like teleportation, restoring unit health in an instant or similar. Yes, we’re taking the approach that restoring health is a slow process, seeing what time period we’re in. Thus, having an instant health restore is something divine, that only a godlike being can do.

Gameplay-wise, every guardian has their own set of Spells and passive ability. The passive ability is active from the start of the fight and triggers every time its conditions are met. Internally, these are implemented via status effects that are granted to all units by default. The Spells have to be selected from the Guardian Core, up to three at a time. Only the selected spells are available in combat and their use is limited by the amount of mana you have. Each Core has its own mana pool that differs in size, and Spells have some mana cost. They don’t cost action points though, and you can use them with any unit. The Spells use the Guardian attributes, which are derived from the Core itself - the higher the level of the core, the more power Spells have! This might change as we iterate over the Spell system as a whole. The game is still in progress, after all!



Since Spells are plain old abilities, creating them is as easy as normal abilities and then setting their mana cost instead of action point cost. The biggest difference is purely in the design and effects they have - we just give Spells the more powerful ones. It’s an interesting balance, trying to define abilities that would logically fit units in medieval times, and abilities that look like Spells, but are actually sci-fi weapons. Our ability system is flexible enough that creating them is just a matter of giving an answer to “what do I want this thing to do”.

The person who will be answering most of these will be our designer Mat! He just came from Brazil to Croatia, just in time for the pandemic to go in full swing and just before an earthquake hit Zagreb. I hope he doesn’t feel like he made a bad life choice :|
He’ll be giving meaning to most of the systems we’ve made so far, from abilities, enemy units, meta-progression, spells, relics, overworld progression, encounters… the whole nine yards. For instance, Mat just started prototyping Spell interaction on the world map. For this reason, the Spells themselves are not very precisely defined and we don’t yet have any cool Spell effects to show. When this changes in the future, I’ll showcase them around the web, either via a blog post, the Discord server for the Hand of Merlin or through Twitter, so don’t miss out! Thanks for reading!

MarkoP

Hi folks!
In some of the previous posts, I mentioned Spells. Before diving into what Spells are and what their role is, I wanted to first introduce the concept of the Guardians. The name is WIP and I’ll be using it for now, but we’ll probably be changing it to something else, like Watchers, Wizards, The Guys Up Above or something.

The following is a part of the world-building document our writers made that I modified for the post:
Guardians are immortal and transdimensional beings, creatures like Merlin and Morgana. There are probably only a few hundred of them scattered across the cosmos, and many may be lost or asleep, having put themselves into a state of suspended animation. Some may conceal their identities and become the source of legends about gods and wizards, having settled down in individual worlds, and no longer participate in the affairs of the cosmos.



Since we use the concept of multiple dimensions, there are many worlds Merlin can affect. These worlds are being destroyed by the Cataclysm, a transdimensional event that is tearing apart the borders between the worlds and the Void between them, letting in the horrifying world-devouring monstrosities that dwell in the darkness. Merlin believes in protecting as many worlds he can, no matter how impossible it seems. His plan to stop the Cataclysm from destroying this cluster of worlds we see in the game was to shepherd history into creating Arthur, an inspiring leader who would build an empire based on virtue and equality. Merlin couldn't predict where exactly in the world the first break, the source of the infection, would appear, and he needed a powerful force capable of dealing with any scenario. In Arthur's Camelot, he sought to create just that, and he gave each Arthur (across dimensions) a Grail, an artifact of immense power capable of healing that world.

Without going further into the story aspect, stuff happens, Merlin wakes up weakened and finds the Cataclysm had already begun to affect these worlds. He scrambles to find a group of heroes to help him prevent disaster and destruction, and this is where our game starts.

From a gameplay point of view, the player acts as Merlin, trying to save as many worlds as possible. At his disposal is his fort, “Avalon”, which is something like a ship capable of travel across worlds, and possibly much more. The ship has systems that can affect the lower planes, manifesting as Spells for the humans. The ship is powered by Cores. Each Core is associated with a Guardian and provides you with a set of active Spells and one passive Spell. Each Guardian has their own set of Spells unique to them, making each run feel different, as each run must be started and finished with the same Core.



You can acquire the Cores of other Guardians via specific encounters on the world map that have a more global story arc, spanning several runs through the game. For instance, on your second run, you get to a node where you meet Morgana. After some talking, she tells you to meet her in another dimension. On your next run, you can meet her again, and so on until you finish the quest. Once the quest is finished, Morgana grants you access to her Core which can be used on any of the future runs.

Next week I’ll get into Spells themselves. Thanks for reading, and come share your opinions on what you’ve seen so far on the Discord server for the Hand of Merlin, and yell at me on Twitter if you want to know something I haven’t already mentioned!

MarkoP

Hello again!
In the previous post, I talked about our abilities, and in this one, I wanted to expand on the topic a bit. Specifically, I wanted to touch on status effects, because they’re the other part of what makes our abilities cool.



Any ability can grant a status effect to all targets in the area of effect. The area of effect is either a radius around the target tile or the entire map. The status effects have the expected functionality you’ve seen in other games - increasing stats, applying debuffs, damage over time, etc. Their functionality is split into 2 main parts - a passive and active component.
The passive component can be any flags that are boolean in nature - you either have them or you don’t, like Phasing, Immune to damage, React to attacks, and similar. They can also be numerical modifiers to any unit attribute - +10 to max health, -50% accuracy and so on.

The active component is a list of actions triggered by an event. Most of these events happen during the processing of any other ability, like dealing damage, killing a unit or spending all action points. The events can be filtered, so a status effect can only trigger its actions if, say, a friendly unit spends all action points or an enemy unit takes damage. The actions that trigger currently only apply to the unit affected by the status effect that triggers the actions. I have plans to change this so the unit that applied the effect can also be the target of the actions. The list of actions includes the classic ones - damage, healing, restoring action points or resetting ability cooldowns. Status effects can also grant other status effects through these actions, to make an infinite chain! (god, I hope not)



My favorite is the “use ability” action.
Yes, status effects can use other abilities, that could inflict other status effects, that could use their own abilities, etc. It’s kind of insane.
At some point in the dev process, we were tinkering with an enemy that, when killed, would spawn a smaller version of himself. The small one would run away from your units and regrow back into the full-sized unit. It’s a slightly annoying enemy, but hey, we were adding general functionality. It definitely didn’t help both of them had a ton of health…
Anyway, I implemented him by giving him an innate status effect that grants him an out of turn action when hit and also detects when he’s killed. When that happens, the status effect uses the Spawn Mini-Me ability on his own position, after which he promptly dies. The little guy, newly spawned, then runs away, uses a Grow ability and waits for a few turns. If you don’t kill him, he regrows back into the full unit by casting an ability on himself that changes his base unit class. The whole process was especially pleasing to me because it allowed me to delete a bunch of code that handled the specific “when a unit dies, use this ability” logic, and move it fully into the content.

There are going to a bunch more ability effects and status effect actions and modifiers. I’ll probably showcase them as we make more cool ones. Thanks for reading, come join the Discord server, or follow me on Twitter.

MarkoP

Hi all!
Last week I introduced the abilities used by our units, and this week I wanted to talk a bit more about them. Our ability system has received 3 iterations. The first was done by Robert in the old engine, and after the engine switch, I reimplemented it in the Serious Engine. Finally, I revamped the entire thing to make it a bit more flexible and content-driven without the need to write any scripts. Was that a good idea or not? I dunno. It works, tho!

We start by defining an ability in a read-only resource that is taken by our game logic, which after processing spits out a bunch of actions that describe what happens to the units and environment. Conceptually, it’s kind of like recording yourself in The Talos Principle (you did play that game, right?), then watching the replay of everything you did.
Every time the player clicks on a tile to use an ability, we calculate everything, and I mean everything, that happens to the units and the game world, and store these events in a nice little queue. Then we playback these actions and you see the result. Arrows fly, rocks get destroyed, units die and are spawned, time slows down and resumes, etc.

Each ability can affect units and/or tiles, depending on how it’s configured. We have a small list of unit effects that are applied to all units caught in the area of effect of the ability. These are your standard effects, like damage, knockback, pull-in, granting status effects, etc. There is a way to define multiple sets of effects that get applied to different units as well. For instance, all enemies in the area of effect get damage and a bleed, while all friendly units on the map get healed. All of these effects can happen by using just one ability. We probably won’t have such overpowered abilities. Or will we? :)
Tile effects are things that don’t require a unit as a target, like spawning another unit, or a ground effect.



Yes, I totally created the ability mentioned in the previous paragraph. It took a whole 3 minutes.



There are 3 categories an ability falls under - Run, Attack, and Teleport. A Run ability will (obviously) move a unit by calculating waypoints to the target tile (the clicked tile). A Teleport ability is similar to Run but has only two waypoints, the first and last waypoint of the equivalent Run path. Both of these are capable of inflicting effects to units and tiles as well, and they do it by finding targets from each waypoint. The last category, Attack, just applies all effects to the selected targets.

The entire structure of abilities has a lot of tiny configurable nobs and toggles that allow us to create a wide range of Skills, Spells, and Relics. The current set of effects we can do to units is not large but still allows us to implement interesting Skills or Spells. We’re planning on expanding the list once we get a better idea of what the game needs. The combat layer is feature complete, so now we’re gearing to filling out the missing content. Our artists are doing a great job (except Ivan) at creating levels, next week they’re starting work on the monsters, and sometime after that we’re giving them abilities and AI.

Thanks for reading! This post was a lot more technical the first time I wrote it, and I might publish the more technical version somewhere after I cover some more functionality of the abilities, for any technically minded readers. Do tell me if you’re interested in reading the nitty-gritty technical details of how these are implemented (since I did that), so I can gauge interest. You can express your thoughts on our Discord server, or you can contact me on Twitter.

Random fact: The other Marko created the icon for the ability I made for this post a few years ago.

MarkoP

Hi!
The topic last week was units, and units are nothing without interesting abilities!
The two core aspects of combat in our maps are unit skills, and the enemy AI. Since the AI relies on the skills to be able to do anything, I’ll first dive into our skill design and implementation.

The player party is comprised of up to 3 units belonging to any of the 3 classes. Each class represents a specific role and has a set of skills exclusive to the role/class. All skills are categorized as either Offense, Defense or Mobility. Every unit starts with default Run and Attack skills, the first one to be able to move at all, and the second as the default method of dealing damage.



I wasn’t really satisfied with units starting out with almost no interesting skills, so I decided to give each class an extra starting role-specific skill. This would have the units start with a Run, Attack and a Special skill, which is still not the final count. Each unit will be given a number of opportunities to learn new skills in order to expand their options in combat. During these opportunities, the player is presented with one random skill from each category and picks which one the unit will learn.



In our current implementation, each unit gets to learn two additional skills, putting the final count at 3 Special skills (I’m not counting Run and Attack here). Our current internal build has 2 skills per category, per class, but the plan is to expand this further. We’re still figuring out how many skills to make in total to have enough replayability. The task fell to me to make all of the skills in the current build (from a list of skill ideas - I’m not very creative T_T) and I’ve given each some mechanic to make them interesting.



Since I did such a great job with the skills and the distribution of opportunities to learn new ones, our overlords we have decided to hire a game designer full-time.
Jokes aside, it's mostly because none of us have the time for it. Everybody on the team has their hands full with their primary role (and secondary for some of us), so we need a person dedicated to making new abilities, general playtesting and balancing, tweaking the AI, creating templates for encounters so our writers can make cool stories from them, etc. That means our team will count 8 full time working members: 5 artists (Ivan, Lucija, Mateja, Toni, Kaz), 2 programmers (Marko and Marko - yes, it’s hilarious when we both introduce ourselves as Marko the programmer), and a game designer.

I guess I can introduce myself this time around? As you probably figured out, my name is Marko. I’m a programmer on the team, I write the blog posts and do community interactions, do ad-hoc design, draw shitty programmer art, and a bunch of other things because indie teams have people with many hats on. I’ve been programming for over a decade now and was rewarded with the title of lead programmer after two years being on the project, which is so totally meaningful with two programmers on the team. I’m also one of the first people hired, which gives me some seniority on the team and is the reason why I’m doing way too many things, and doing too many things is the reason why I’m behind on my coding task, so I’m getting back to that now.

Thanks for reading! Give it a thumbs up, like, subscribe, follow, comment, share, etc. I monitor the Discord and my Twitter on a daily basis, so let me know what you think of everything I’ve shown so far. Feel free to ask questions about anything and I’ll try to answer them all. Except cooking, I suck at that.

MarkoP

Hey everyone!
Last week I showed and talked about the maps where combat takes place. The combat requires some units that do the… combat. So, let’s talk about those a bit.

When discussing what we wanted to do with the units, our writers Jonas and Verena were a big help, as they gave us the idea to use historical figures. Instead of using the popular ones - like Galahad, Lancelot, Percival and similar - we could use the more obscure ones, like Sir Breunor or Safir. This would still anchor us to the Arthurian legend, but give us more leeway with the characters, their backgrounds, and storylines. If we can give the second-grade knights a cool story, maybe they get the recognition they deserve!



The current roster consists of 9 heroes, 3 per class (with uniquely made-up names such as tank, support, and ranger - I know, we’re so inventive), spread evenly between the 3 regions of the world. Every hero will have their own set of encounters for meeting them in the wild, and the player will most likely start with a full party, one hero of each class. We’re discussing if and how we’d allow starting party customization, so players can pick their party composition, and try the “imba 3 ranger starter combo”. Maybe we should make that an achievement? Anyway, one idea floating around is to add any hero you meet in the world as a potential starting hero, turning it into a small meta progression system that just opens up customization for starting future runs. This is something we still haven’t decided on, and I’m interested in hearing your opinion on this. Shoot them my way in the comments, the steam forums, Discord or Twitter!

Each hero has their own traits that affect how they approach world encounters, opening up additional options and ways to resolve encounters and reach different outcomes. We have a small number of traits (ballpark of 8, stuff like “strong”, “perceptive”, “herbalist” etc.), and each hero unit gets 2 of those, which gives them a small bit of personality during encounters. For the combat part, every hero unit will have a starting skill (besides the default movement and attack abilities) that highlights their role in combat. The skill isn’t exclusive to that unit, though. Any other unit of the same class can learn that ability through upgrades, susceptible to randomness.



This is the part where I introduce another member of the team: our character concept artist / texture artist / RoomC psychologist / horse wrangler - Kaz. Nobody knows her real name. She came to work with the team after leaving prison, and we’re too afraid of letting her go.

She actually just worked there, which was a relief to some and a letdown to others...

She has drawn most of the concept art for the heroes (we have some extra hero concepts stashed if we get the time to model them), drawn every UI icon for status effects, skill icons, spell icons, character portraits, textured every 3D character model, painted the terrain for the world maps, and is generally the main point of contact for texture related stuff and psychological torture. I’ve been told Ivan does some texture stuff as well, but nothing worth mentioning. ;)

The animations for the human models are done by Toni (talked about him, like… two weeks ago), and we’re in the process of doing a better rig for the units to make even better animations. There is baseline of 11 unit animations, and there will probably be additional ones required for specific abilities. I’ll talk about abilities in general next week, and their implementation the one after. For now, I’ll leave you with this beautiful animation of a dead unit.



As always, thanks for reading. Join the Discord, follow me on Twitter, and comment on what you’d like me to write about if there’s a specific topic you’re interested in. I’ll be back next week, cheers!

MarkoP

Hey everyone!
Starting this week, I’ll be talking a bunch about the combat layer of the game.
Most world encounters will be of a social nature, designed as a story driven by your choices, with branching narratives and different outcomes. However, some encounters are just a means to an end - to get you into combat. Once you get such an encounter, after a short introduction and setting the scene, you’ll be transitioned into one of our skirmish maps.



The combat works similar to XCOM, so it should be mostly familiar if you’ve ever played it: it uses a square tile grid, the player and enemy each have their own party of units, and take full turns to do all of their actions. Each unit has 2 action points to spend on movement and/or using abilities. There will be dedicated blog posts about units and abilities later. In this post, I wanted to talk specifically about the maps themselves.
A lot of roguelite games try having randomized levels to increase replayability and variety. We discussed doing random level generation, but ultimately decided against it. The reason is mostly that with a team of this size (only 2 programmers), it would take too much time and resources to implement a correct level generation that takes into account all aspects of what a level requires. Levels should be visually interesting, have unique elements and layouts that make them distinct from each other, have decently placed spawn points for both player and enemies, have enough obstacles and cover objects placed to make the gameplay satisfying for any combination of abilities that the players units can have. So, we hand craft each and every level.



This work is mostly done by 2 of our most recent additions to the team, Mateja and Lucija. They joined the team when they were still students of the Academy of Fine Arts in Zagreb around a year ago, and in the meanwhile, Mateja finished her studies and got hired full time, while Lucija is about to finish her degree. They joined to help our 3 poor struggling artists spread out the work, from modeling and texturing objects, animating environment objects and units, and creating levels and concept art. Most of their time, however, has been put into making the levels (and any required props to make them). A single level, from it’s concept stages to the finished visual design, takes around 2 days, if they have enough general props that can be just positioned in the world. If not, a single prop takes anywhere from 2 hours to a day, depending on complexity. Also, since each level is used by only one encounter, there is no fear that levels would be seen too often, as getting the same encounter in two successive runs has a low enough chance.



All maps feature certain obstacles in them. Some obstacles are based on terrain features, and define mostly where you can stand, and whether you get any sort of cover benefits. The other kind of obstacles are our destructible objects. They grant cover the same way as terrain features, however, they are fully destructible by abilities that have the “destroy cover” functionality. We’re in the process of giving them all a proper destruction effect, and the current idea is to have most of the small obstacles (around the size of a unit) reuse a pool of similar destruction effects, categorized by material (wood, stone, dirt/grass, etc), but for the larger ones we’d do a full destruction into pieces, like in the gif below.



Next week I’ll be showing off some player controllable units available in the first region of the game, and the party with which the player will most likely start first. Thank you for reading, and feel free to join our Discord serverurl], and [url]follow me on Twitter if that’s your jam. In croatian, jam is spelled pekmez.

MarkoP

Hey everyone!
Last week I showed you the book that acts as our interface to the party management screen, and the interaction with encounters. The encounters are short stories that describe what happens to your party when they arrive at a world location. The world map has a series of nodes, and each node will have one of these. Encounters can be a very short introduction to the combat you’re about to enter, just setting the scene, or they can be a story about a terrible robber that preys on rich travellers, a maiden in distress, a magical monocerus, fairy rings in the forest, and so on. As you can see, the world has some aspects of “magic” in it, however, we’re going down the route of “magic is just science that is not yet explained”. This ties into the reasons why our combat is low fantasy without magic - our units all just use science that would be available to them (alchemy, chemistry and the like), which is the baseline for our support class. The exception to this is a category of abilities we call Spells, but those follow the same idea (they’re spells to the uninitiated, i.e. the units), and I’ll write a post about the combat in a few weeks where i’ll explain all of that.



As you can see in the picture above, the encounters are split into short segments that can fit on one page. Each segment is usually accompanied with a set of choices the player can make to drive the story forward, or bail out on the encounter altogether. We try making it a point to allow the player to bail on the encounter several times in the buildup or introduction phase, since in most cases we don’t want to lock the player into an encounter which he doesn’t want to do (for example, forcing the player to spend gold without making it a conscious decision).




The dialog choices the player can make are written in a way that progresses the story and time forward. Each choice advances the “state” of the encounter, if it makes sense - imagine each option as an action the player makes in the moment. A ‘look’ action is not the same as the ‘take’ action, as one of them will alter the situation, and the other is just information gathering. Once the player makes a decision on what to do, (usually) there’s no going back. If you choose to sell a relic to a merchant, there's no chance he’s willing to sell it back to you. At least, not without increasing the price :) Deciding to walk over a rickety bridge might mean it collapses under you, losing you some gold or supplies, but it could also mean you narrowly make it to the other side before it collapses. The same encounter in one run can have a vastly different outcome in another run, all depending on the choice the player makes, and some internal randomness in each encounter (like the bridge example above). We won’t have any timers when choosing an option, since different people have different reading speeds, and different decision making speeds. Also, some decisions might require you to look at your party’s status (which is always reachable via the bookmark in the top left of the book), to determine if a choice is useful for your current situation. If your units are low on health, you might prefer a choice that heals your units instead of a choice that gives you gold, and the other way around if you’re full on health.



All of the encounters are written by the Kyratzes family: Jonas and Verena. They're a writing team that started by making story-heavy indie games like The Sea Will Claim Everything. Jonas then worked on The Talos Principle, and later Verena joined him on Serious Sam 4. Jonas also worked on Phoenix Point and The Eternal Cylinder. It’s through their work on The Talos Principle that we got to know them, and at some point, asked them if they were interested in working on the story and encounters for our game. They agreed, and have written several encounters to test the waters - how they would function in the limited confines of our presentation methods (we have to limit the amount of text per page due to clipping and to not have a wall of text for the player to read). Based on their feedback on writing the encounters, we wrote a custom syntax file format that allows a lot of control over how the encounters play out: randomness, different page paths, character specific actions, global state changes, combat spawn location variations, and more. Jonas and Verena have a lot of experience writing stories, and we are working on a streamlined process that allows them to think only about the story itself, and leave all the game balancing and pacing of the encounters to us. We look forward to seeing what great stories they come up with. :)


Next week I’ll start getting into the other aspect of our game, the combat scenarios. They’re turn-based grid-based party-based skirmishes, that pit the player’s 3 man party against various bandits and a sinister unknown threat from the beyond (ooo spooky).
As always, you can join the Hand of Merlin Discord server, and you can follow me on Twitter if you want to throw some questions about the game in my direction. I’m still learning how to effectively use the damn thing, but I might throw some exclusive screenies there from time to time.

Until next time!
MarkoP

Last week we talked about the first region of the game, and this week we want to show you what happens when you arrive at a notable location or world nodes. Every region is made up of a network of nodes that form a directed graph towards the boss fight for that region. Each node contains an encounter (similar to FTL), with a short story driven by player choices on what to do next. We call this interface “the encounter dialog”, and this went through its own evolution, first as a 2D scroll, and finally became the book we have today.



We wanted the interface to be a physical object that you can interact with, and we looked for inspiration in several places: Skyrim books for one, and the feel of Tom Riddle's diary from the second Harry Potter movie, with how it absorbs the text. Our 3D modeling artist Toni modeled and animated the book, while Marko, the other programmer on the team, implemented the text dissolve and most of the code driving its’ animations. Everything you see in the book is essentially a standard UI widget, we just display it as a page in the book instead of it being on the screen as a HUD. The book is internally split into chapters. The Warband chapter is where you can check the stats of your current party members, the Encounter chapter is where we go through the encounters themselves, and there are a few other chapters for features we’ll talk about in the future.



Marko is a student in his final year, finishing his degree soon (hopefully, it’s been long enough, dude!), and Toni is a self-taught 3D modeling artist. Toni helped the rest of the team learn Blender, and eased the transition from 2D to 3D. Marko is also learning Blender in his spare time, even though it doesn’t do him any good in his daily tasks, as he’s busy working on game features and bug fixing.



In the next post we’ll talk about the encounters themselves, so stay tuned. You can join us on The Hand of Merlin Discord server.

MarkoP