The Hand of Merlin News

Hey folks!

Early access is so close we can taste it. As such, Mat is sweating like a madman from what people will tell us about the design of the game. He’s doing his best to balance the thing as much as possible, but without a larger dataset, it’s not really achievable. So Mat has written a bit about the topic.

This is what he has to say.

---

Balancing a game is never easy. You want it to be a decent challenge to players of all skill levels, you want it to be easy to pick up but have enough complexity to allow everyone to keep improving, and finally, you want it to be enjoyable.

There’s a lot of theory about it. Most game designers can describe a version of the concept of “Flow” or how to graph a difficulty curve… But trying to actually make it work? It’s a whole challenge.

Right now, The Hand of Merlin is a demanding game. It expects you to understand a lot of minutia on how each Abomination works, learn their AI patterns, and how to create viable builds while not having full control and knowledge (Roguelite, y’all.). It’s unforgiving and punishes misplays heavily.



The result is seen on our latest playtests with fresh players - only after over a dozen runs could someone progress to the later zones consistently. This means two things:

1. The game is getting stable - Skill is becoming more and more the greatest marker of success, and luck is less swingy.
   
2. The game is… Hard. New players in particular will face a lot of frustration before they start acquiring some success.
   

And hey, that’s reasonable, right? We have an easy mode if you want to dip your toes, and the game is about learning - you follow Merlin’s quest to regain his powers, and understand how best to save each world…

But I think we are in a spot where most players will face such a wall that they won’t want to put the time in to master the game. Imagine if most players could never defeat the first boss in Slay the Spire in their first dozen runs, or if your first week in Noita was only in the first area.

Pretty sad, man.

So we want to make it a bit more approachable. A bit more forgiving, especially in Albion. Now, this will be an ongoing process, and that’s my favourite part of Early Access: We will be receiving a lot of data from you, our players!

Apart from getting the game in a more approachable state, we also want to tackle how it scales in the late game when you’ll have all your skills and gear.
Do we have enough variety in the viable builds?
Is the “best build” too obviously strong to be the only thing worth pursuing?
Are a few of the landmarks the absolute best to visit every time?

All those questions are going to be answered with your help and a lot of telemetry. I can promise you that we are doing what we can to ensure a fair, engaging experience, but in such a complex game with so many options, we have to get as many players in. During our Early Access, I’ll be perusing the telemetry data and getting to know which abilities you are picking, which ones are never used, your favourite heroes, and even which enemies are giving you guys too much trouble.

So be patient, and thank you in advance for all the feedback! I’m excited to make this game as good as it can be!

---

If you’re interested in the game, you’ll be able to play it real soon! In the meantime, you can come to our Discord server and tell us what you’d like to see in the game, and share your excitement with us. We’re excited about the early access release as well!

MarkoP

https://store.steampowered.com/app/600610/The_Hand_of_Merlin/

Hey folks!

Our early access release is looming. As we’re getting closer, we’re trying to put small bits of polish here and there. This blog post is basically just a bunch of smaller things we did that we’re happy about.

[h2]Landmarks node improvements[/h2]
The Landmarks are special nodes that revolve around a specific world location. These are always around the same position in the world and have a unique name. Up until now, only cities had unique names, so we’ve expanded this to special locations as well. Landmarks are usually also accompanied by a unique model in the world.


[h2]Bestiary[/h2]
We’re finally doing the content for the bestiary chapter in the book. We plan on having entries for all Abominations in there, with some flavor text to accompany them. This one here is a mockup prototype because somebody who was supposed to make it forgot I'd need this image today. *smh*


[h2]Node links[/h2]
A small improvement we made to the node links is adding a soft fade to them when highlighting is turning on and off.


[h2]Outro cutscene[/h2]
We finished the outro cutscene, so now finishing the game will have some visual and narrative sense!


[h2]Spell effects[/h2]
We’re adding some good oomph to Spells to make them visually distinct from Skills.


[h2]Directional targeting smooooothnes[/h2]
Recently we made directional targeting use a different way of calculating the effect area, which makes it feel much smoother when the mouse is near the character, as it behaves similar to when it’s farther away.


[h2]Achievement icons[/h2]
We made all icons for achievements, so now MarkoZ is very sad that his custom-made icon will no longer be featured in the game.


[h2]Pending mana[/h2]
One small pet peeve of mine was that mana didn’t behave the same as AP on the action bar. Now it does!



As you can see, we’re doing some strides to making the whole thing be as polished as we can make it. That said, I absolutely know there are things that could be done better, but as we’ve been working on this so long, we’ve become blind to some inefficiencies and UX issues.
We’re very much hoping to have a bunch of players point these issues out to us and together we’d work out how to best improve things. The best ways to tell us about these issues are going to be the Steam forums and our Discord server for some instantaneous communication.
Next week we’ll drop the early access release date, so stay tuned!

MarkoP

https://store.steampowered.com/app/600610/The_Hand_of_Merlin/

Hey folks!

As we’re nearing our early access release, we’re looking at things we need to improve during it. We have some plans and ideas of additional content to add during EA, but map variations are at the top of that list.

As Mat has been testing combat a lot and playing through the game, he agreed that he’s getting sick of playing on the exact same maps every time. Each map is tied to an encounter, but the encounter drives the initial combat conditions. Based on your choices during the encounter, you might change the position where your units spawn, or whether the enemies start first, or their numbers, but ultimately, it’s still on the same map with the same layout and cover placement.

The core of the issue could have been solved with procedural generation had we approached our map system differently all those years ago. However, it’s important to note that even procedural generation has its issues. Maps could be generated with very bad layouts, bad spawn positions, and generally require a lot of tweaking of a black box system to get a good enough map generation algorithm. Of course, this only applies if the map generation runs on the players’ machines, but there’s a good middle ground: generate the maps in the editor and save the good results. Unfortunately, it’s a bit late to think about that for this project. Next project perhaps. :)

For Merlin, we’re doing it the “dumb” way, which is luckily also very simple. Duplicate the map, change the layouts, polish the visuals. We did a test run on one map called Meadow, and it took Mat (cover placement) and Lucija (visual polish) less than a day to create the variation. Here you can see the result.



I also had to add some tech to support map variations. Since encounters define the combat map to load, they would have to be in control of the map variations. To keep encounter changes to a minimum, they can now reference a Skirmish Map Set resource file that just has a list of maps to randomly pick from. Once an encounter links to this resource, only that resource needs to change to add a new variation, instead of potentially multiple encounters that might use the same [set of] maps. Our plan for early access is to create variations for the most important maps. The maps that get seen most often will be prioritized over maps that get seen less often. Ultimately we’d like to add variations for all maps, but this really depends. Some maps might not need variations because they’re so rarely seen it would make little difference. We’re also still thinking whether boss fights need variations, since they’re kind of set pieces and intended to be tougher than other fights - maybe they would benefit from not having variations so they can be “optimized”? Hopefully, the players will tell us about it during EA.

In the end, map variations are here to solve the issue of replayability, so each run feels fresh in as many aspects as possible. Tell us what you think about it on our Discord server. We’re happy to receive feedback even now before EA.

MarkoP

https://store.steampowered.com/app/600610/The_Hand_of_Merlin/

Heyooo!

About two weeks ago we started doing QA with an affiliate team from Versus Evil. They’ve been great and found a bit over 200 issues so far. Only a few of them are by design so far, in which case we’re still treating them as an issue for not being explained well. Honestly, having 200 issues reported in two weeks doesn’t seem that bad to me. We’ve already fixed more than half of the reported issues and will continue doing so all the up until we release in Early Access in about a month’s time.

We also started marking encounters as finalized. This means they’re ready for localization and will be bundled up in phases and sent to the localization people. There’s currently a total of 350 encounters spread across 4 zones, tho the last zone has a bit under 20 because it’s special. Translating that number of encounters will take some time. :)

We’ve been also working on our gameplay telemetry events. These will come in handy when balancing the game. Mat and Mia have a not-so-easy task to get the game to a semblance of balance. Due to the rogue-lite nature of the game, it’s a tough nut to crack, especially when taking into account there are two difficulties in the game. The initial release will feature Easy mode and Normal mode, and at a later point, should the player base want it, we’ll add a Super-Mega-Difficult mode.

Totally a thing we could do. Hope you like my third difficulty mockup!

One thing to keep in mind when we release in EA: the game probably won’t be perfectly balanced. This is very much where you come in. I think the game cannot be balanced well with a sample of only about 5-10 players. We need a large dataset to be able to fine-tune the game. Reporting issues in our Discord or on the Steam forums will go a long way to helping us iron out the game. Of course, any crashes you might experience will be shot dead as soon as possible, since those are my mortal enemies, and I vanquish my enemies with ruthless determination.

Art-wise, stuff is starting to get polished. Improving levels, filling in missing animations, sounds, visual effects for abilities, the works. We’ve also added inter-zone cutscenes, which is just an image that gives a bit of context for what happens to the hero party between the zones.

A lot of the work done by us programmers has been enabling other people to create content without putting too many limitations and structure on how the game works. Mostly it comes down to allowing the content to drive the game. As such, our plan is to ship the editor with the game at some point down the line, which means anyone will be able to add new stuff in. I know Mat is hoping somebody adds a Kermit unit to the game, and I’m hoping to see the Power Rangers as player characters.

During Early Access, the players will have a lot of influence on where the game goes. I hope to see you there! If you wanna join before then, we have a Discord server and are happy to chat.

MarkoP

https://store.steampowered.com/app/600610/The_Hand_of_Merlin/

Hey!

It's me, Robert, again. Last week I talked about porting The Hand of Merlin to Linux. Today, let's continue the story with macOS.

Mac certainly turned out to be a tougher challenge than Linux, but hey, I love roguelikes and challenges, so that's not a complaint!

Remember how I said SeriousEngine 4.0 dropped support for OpenGL entirely? You know, the nice, cozy old graphics API that worked on pretty much any platform? Well, that leaves us with Metal, the new and modern API developed by Apple specifically for iOS and macOS. Now, SeriousEngine did have native support for Metal, back in version 3.5, when we made The Talos Principle run on iOS. But that was 3-5 years ago, and our Metal code wasn't maintained since then.

You can imagine my dismay! Half the graphics functions had changed signatures. A quarter were never even implemented. It took me pretty much a whole week just to refactor the old code in order to make it even compile. That was the easy part.

The tougher part was writing out missing code. Luckily, we do have a working Vulkan renderer, so I was able to examine how Vulkan code works, and then scan through Apple's documentation to figure out how to remap things. Since both APIs are pretty low level, they do have fairly similar concepts. Oh, and by the way, Apple uses Objective-C instead of standard C++... so that's an extra hard mode there. :)

Finally, a week-and-a-half later, I had a Metal renderer with all the holes plugged. It compiled, I ran it, and... Black screen. Sigh.

Just like with Linux, the problem now was missing shaders. Metal can only work with shaders written in MSL, the Metal Shading Language. Rewriting the entire shader code base from HLSL to MSL was not an option I wanted to think about. I knew I could get DirectX Shader Compiler to work on macOS, since that library is cross-platform. That can get me SPIR-V (Vulkan bytecode) on macOS, but then what? After some research, I found an answer: SPIRV-Cross, a cross-platform library that can decompile SPIR-V into a number of other human-readable languages, including - yes! - MSL.

So let me paint you the full picture. We start with shaders written by a programmer in HLSL. Then we compile those into SPIR-V bytecode, decompile them into MSL, then re-compile MSL into Metal's bytecode. Phew! Talk about making sausages, right? But hey, at least none of this happens on players' machines. That distributed build system I briefly mentioned in the last post, that handles the entire shader creation process. So, when you download the game on Steam, the game data package already contains all of the shaders precreated into the final bytecode form that's directly loadable by your local operating system.

So after all that, I ran the game again, and... Black screen. Again. Sigh.

Back to the drawing board! I stripped down the first scene in the game to a bare minimum, a colored 3D cube. The simplest shader, the simplest possible rendering state. Once I could get that running, I'd add more complexity.

-- Xcode --



At this point, let me introduce you to my new friend - Xcode. That's Apple's main dev tool suite, and the features I was most interested in are: Metal API call validation, and GPU tracing.

The API validation thing is super useful since it tells you as soon as you call a function if you messed something up with the parameters. I caught a solid number of bugs just by examining the validation errors.

The second feature is the real winner, though. By recording a single frame of rendering, Xcode can trace all of the GPU calls you did, along with the entire pipeline state, allowing you to inspect everything. A pixel is black when it should be colored? Just click it, and hit the Debug button. You get a listing of all the textures you're using, the exact shader code that's running, heck you can even step through the shader code.

With this power tool, I was able to really get to the bottom of all the issues I saw, and finally, I could see my beautiful cube. :)

From that point on, it was like climbing a staircase. Add a bit of complexity to the scene, run a GPU trace, figure out what's wrong, fix it. Rinse and repeat. Slowly but surely I got all the way to dynamic geometry (fonts, particles), post-processing (tone mapping, bloom, ambient occlusion), shadow mapping, antialiasing (MSAA), all the jazz.

To round it all off, I also made sure we have proper detection of high-DPI / 4K displays on Mac, too.

-- Performance --



Oh - did I mention the game not only runs on Mac, but also runs pretty darn well? This is where the native Metal implementation really pays off! On my M1 Mac mini, which has an integrated GPU, I'm able to get a solid 60 FPS at 1080p resolution. And that's using Balanced quality presets - so no sacrificing visual quality.

So, there you have it. All in all, several weeks of work, and a satisfying feeling of a port done right.

If you have any questions, stop by the forums or our Discord server. We're pretty much always there.

Robert

https://store.steampowered.com/app/600610/The_Hand_of_Merlin/