Evening all.

All I wanted to do today was finish off the slab-sharing UI, but instead, I spent the day looking into an input bug.

It goes like this. Sometimes, you have keybindings that overlap. For example, on Mac, Undo is Command+z, and Redo is Command+Shift+z. This is an overlap; in order to hit the keys for Redo on Mac, you also need to hit the keys for Undo.

This was a problem we hit when releasing on Mac, so we turned on a setting in Unity’s input system called shortcutKeysConsumeInput

Here’s how Unity describes it:

improves shortcut key support by making composite controls consume control input

actions are exclusively triggered and will consume/block other actions sharing the same input. e.g. when pressing the ‘shift+b’ keys, the associated action would trigger but any action bound to just the ‘b’ key would be prevented from triggering at the same time. please note that enabling this will cause actions with composite bindings to consume input and block any other actions which are enabled and sharing the same controls. input consumption is performed in priority order, with the action containing the greatest number of bindings checked first. therefore actions requiring fewer keypresses will not be triggered if an action using more keypresses is triggered and has overlapping controls. this works for shortcut keys, however in other cases this might not give the desired result, especially where there are actions with the exact same number of composite controls, in which case it is non-deterministic which action will be triggered. these conflicts may occur even between actions which belong to different action maps e.g. if using an uiinputmodule with the arrow keys bound to the navigate action in the ui action map, this would interfere with other action maps using those keys. however conflicts would not occur between actions which belong to different action assets.

Seems ideal, but I think it has a bug. When shortcutKeysConsumeInput is enabled, we see a problem by following these steps:

• User selects a region of tiles
• User cuts with Ctrl+x The user dismisses the slab from the hand with a right-click of the mouse
• The selection mode is stuck on.

What is happening is that when the user presses Ctrl+x, Unity fires an event for Cut and for the selection modifier (the x key by default), but it doesn’t fire when the key is released.

I’ve prodded a bunch of settings, but it does seem to be a bug. My plan is to give up on shortcutKeysConsumeInput and handle the collision cases myself. This sucks, but we really need to get this fixed so we can get back to everything else on the todo list.

It’s rather late here, so I’m gonna get to bed. Hopefully, this isn’t too painful to deal with tomorrow.

Peace.

Disclaimer: This DevLog is from the perspective of one developer. It doesn’t reflect everything going on with the team

This post is about releasing for Mac

We were ready dammit. We had done all the stuff. The build was signed and tested. We had been open about goals and limitations, and we were counting down the minutes to release time.

We. Were. Ready.

Take a look at this:

Now, obviously, we all know from the title that something here is wrong. But take a second, clear your mind, and pretend that the world isn’t a vortex of discount madness. What should this UI do?

To give you a moment and to give some distance before the answer, here are two distractions.

Hey, look! Slabs in the library. We’ve been meaning to do this for a while. Content-packs in TaleSpire will be able to contain slabs. That will let us ship bigger building blocks for speedy building.

Distraction the 2nd. This is a test I’ve been wanting to do for a bit. It doesn’t feel as good as it should, as it feels like it should have smarts to handle intersecting rooms. However, it was a neat test, and it might find its way into the Symbiote API.

ALRIGHT. So you’ve decided what a sane system would do. Now let’s see what we saw 20 minutes before we shipping the Mac release:

Yeah… YEAH.

Twenty minutes before release, we find out that we can’t choose not to ship on Intel Macs, even though none of the Steamworks documentation I’ve found says that is a restriction, and the UI definitely doesn’t suggest it.

As you folks know, we chose not to ship on Intel Macs as we don’t have the resources, as a team, to make the game run well on those machines and support any idiosyncrasies that come up.

Suddenly, we are missing our deadline because of… assuming Steamworks checkboxes work as checkboxes.

If only someone had invented some kind of UI gizmo for this very situation. Maybe even inspired by those old buttons on radios.

Ah, a man can dream.

Back in reality, we were in trouble. We either had to cancel or try and get a valid build ready for intel that day. Naturally, we had to at least attempt the second option.

Telling Unity to build for Intel Macs is simple enough, but when I tried to run it on my 2015 Macbook, it quickly reminded me that we have native library dependencies, too.

Some of those libraries are our own, so we rebuilt those as universal binaries for those. An easy fix. But for some, we didn’t have the binaries required.

For one, we were able to find the Intel version on Nuget, and I tried to tell Unity which one was for what architecture. Sadly, I couldn’t get that to work. I’m 100% sure it was my fault, but we were short on time, and I was stressed. Almost as a joke, I googled how to combine two dylibs into a universal dylib, and bloody hell, there is a way. Lipo is a program that lets you do exactly that!

By simply running lipo libminiz-intel.dylib libminiz-as.dylib -output libminiz-universal.dylib -create, we suddenly had what we needed. I slapped that into the build and got an intel-compatible build.

Now, we still cannot support these platforms, so we whipped up some UI to inform the user of that fact. We saw Unity’s SystemInfo.processorType property, and the docs even showed how to detect ARM. Perfect. We slapped that in, but it didn’t work as, even though Apple’s M processor range is ARM architecture, processorType doesn’t return "ARM" for them. On any typical day, this would be a momentary annoyance, but when the day has already gone so sideways, it’s just an extra kick in the knackers.

Compounding the stress is that a complete clean release build and signing takes a couple of hours, so little issues can really compound.

In the end, as you know, we shipped on Mac a few minutes before midnight in Norway. So we had met our public deadline, but a stiff drink was in order after all that nonsense.

To end, I want to say this to the ether:

Steam peeps, please invest in radio buttons. I no longer know how to trust, but others could be spared.

And to the rest of you, have a good one folks :P

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Hi folks.

Tomorrow at 11:00 a.m. UTC, we will be undertaking a significant upgrade of our backend infrastructure. This will be our biggest one for a long time, so we are scheduling four hours for the maintenance.

Click here to see the time in your timezone

As mentioned, this is a big one for us. Behind the scenes, we’ve been working on the changes we would need to not only scale the game to much larger numbers of concurrent players but to improve our uptime while doing so. Tomorrow, we land a chunk of those improvements. With these changes, we’ll be able to perform backend upgrades just as significant as tomorrow’s one, with zero downtime.

See you on the other side!

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Well, we are nearly there. Depending on where you are, we are shipping Mac support today or tomorrow. I’ve just signed a release candidate build and have it primed on our pre-release Steam branch.

Here’s a fun shot from our recent testing. TaleSpire running on Windows, Mac, and Linux, side-by-side and in the same board.

There simply must be a “three men walk into a pub” joke here somewhere, but I can’t find it.

And here’s a slightly clearer shot

In the last week, I’ve been working on:

• Platform-specific keybinding support
• Updating the cut volume to work with all tiles and props
• Tweaks to improve reconnection behavior
• Allowing Symbiotes to subscribe to creature selection changes.

These will all ship alongside the Mac release, so even pure Windows parties will get something out of it :)

That last one can potentially allow some very cool Symbiote integrations as creators can now react to the player switch between their characters in real-time. It’s pretty speedy with group selections too.

Right, I best get ready and rested for the release.

Have fun folks!

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

In this update, we have a fix and a feature.

GMs can now right-click on rulers made by other players and turn them into AOEs.

We have also fixed a bug where switching back to the TaleSpire window could cause ‘jumping’ due to inputs that occurred while TaleSpire wasn’t focused. Thanks to all the folks who provided info on this, it’s been a long-term bug, and it’s good to be squashing this one finally.

That’s it for today. We’ve got lots more coming this year, but we’ll save that for the dev-logs.

Ciao

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Heya folks,

I’m still around and still pushing toward the macOS release. The last big technical hurdle before we can release is the digital equivalent of paperwork we must do for Apple to allow the game to run.

On Windows and Linux, you can (pretty much) just download programs and use them. Not so on Mac[0]. Apple requires that apps are “signed” and “notarized.”

Roughly speaking, “signing” is a process that makes it easier to know who created an app and to validate that the contents of the app are unchanged. “Notarization” is where Apple scans the app for common vulnerabilities and checks that the app was signed correctly. Apple can then keep that information around so they can check that the app you have downloaded hasn’t been messed with.

This wasn’t always the case, but they’ve got stricter over the years, and now, even though we aren’t using their App Store, we need to do these things.

So I’ve been trying to understand this process so I can add it to our build pipeline, and it has been a draaaag!

I started off looking into ways we could do the signing and notarizing from Windows (as our build agent is a Windows machine), and while there are some interesting options we would have to read all their code to do a security review to make sure they aren’t doing sketchy things with the certificates.

Given that we need to ship as soon as possible, we put that aside and looked into how to do this on Mac. We could buy another Mac, put it on one of our homes, and set up our build infrastructure talk to it. This makes us reliant on that person’s power and internet working and would complicate things when they go on holiday. We could rent a Mac in a data center, but that is a non-trivial cost compared to other bare-metal servers. For now, we chose to use a github action instead.

Github actions are, as always, just code running on someone else’s computer, but it is quite convenient. We can choose to run on a Mac and then define a number of steps to run our scripts. We can also easily drop this if we decide to move to another approach. Borodust set all this up for us. With that, I just needed to make the shell script that would (finally) jump through Apple’s hoops.

Now Apple documentation is a special beast. Whereas Microsoft documentation specializes in blunt unhelpfulness via tautology, Apple has seemingly assembled a team of lawyers and psyche-warfare specialists to remove anything that would allow too much certainty in your life. Apple forums are generally unhelpful, and due to being more of a walled garden, stackoverflow simply has fewer people posting Apple stuff.

It took me an embarrassingly long time to work out why a certificate I had installed and validated was not working (TLDR: it needed to be made from my signing request, not Ree’s). I take some of the blame, but I could install the certificate, right-click on it and validate it for code-signing, and the Mac said, “Yup, this is good to go.” But then, when trying to use it, the Mac would say, “Oh, I can’t find that certificate.”

I don’t have the skill to explain how life-sapping debugging Apple shit is, but if you know an Apple dev, simply mention signing issues while looking in their eyes, and you’ll see the hollow space where hope used to be.

ANYHOO, I finally got it going. If you ever need to do something similar, I’ve put our script online here so you can use it for inspiration [1].

I’m now testing it. Hopefully, this part is almost over.

Once it is, we should be able to give you a release date for Mac. My hope would be only a week or two later. That would give us time for a Beta and to deal with anything else that comes up.

Alright, enough of all that! I hope you are doing well or have something nice on the horizon.

Until next time,

Peace.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

[0] Yeah, of course, you can change settings so that it only tells you it’s not trusted and then forces you to go allow the program. But that isn’t a good experience and is beyond the skill level of many casual computer users.

[1] At the time of this dev log going out, the script is still being tested. I’ve left a warning comment on the gist and will remove it when it works.

Heya folks.

I’ve narrowed the macOS issue down to something happening to the library we use for the Symbiotes web view.

The library itself seems to be innocent, however. My current assumption is that our build process accidentally does something to the library that stops it from loading. The good part, of course, is that we now know where the problem is, so all that is left is the “why.”

That was a bit of a short update, so let’s have a look at something unfinished Chairmander and I have been looking at between other jobs. Symbiote Login Issues.

The speedy explanation is: Lots of websites use other services to handle their login. That often requires some kind of popup where you log in to that service (e.g. google), and then you get redirected back to the site you cared about.

We didn’t have support for that in Symbiotes, and so creators have hit a bit of a roadblock.

Luckily Vuplex (the web view library we use) has a hook for sites trying to open popups, so I hacked together a little test.

The popup has some minor limitations compared to regular Symbiotes. But for login, this will probably do the job just fine. It still needs a bunch of testing and likely some tweaks, but it looks like even more useful Symbiotes will be coming soon!

I’m gonna grab a coffee and get back to it.

Thanks for stopping by.

Disclaimer: This DevLog is from the perspective of one developer. It doesn’t reflect everything going on with the team

Heya folks!

Coding days like yesterday are great. Issues are clear and don’t get weird when prodded, and fixing them is smooth.

I fixed up a bug around the positioning of bookmark names, font issues on Mac, some bugs on scene transition, and a mistake in our Mac build process.

Today my focus is on the Mac builds produced by our build server. The first issue was that I was putting the assets in the wrong place, which was an easy fix. It also let me dip my toes into writing Jenkins files which was… well, I won’t say nice, but it’s good for me to do!

Now I’m looking into a Mac bug where it seems like the root camera is null. Oddly, I’ve not had this in any of my Mac testing so far. It’s likely that I’ve only been deploying dev builds though so this may be specific to release builds. I’m gonna check that first. Hopefully, this is simple.

Alright, I’m too excited to keep writing. I gotta get back to this.

Seeya!

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

What the hell. Days go too fast. Alright, let’s get caught up.

We are getting the Mac build ready. Testing got delayed by several days because the delivery of the m2 Mac mini took longer than quoted. That was disappointing, but eh, it happens. It was also a good opportunity to work on some bugs.

We’ll have a patch out today containing a group of little fixes and a fix for group selection. The group selection issue was very embarrassing as it was much worse than I expected. It was broken in a couple of ways. First off, the stencil buffer wasn’t being cleared, which meant every lasso shape drawn would effectively be combined with every lasso shape drawn that session. Next, the depth buffer was empty, which resulted in group selections selecting creatures through walls. Both of these things got in when we switched out where we were rendering to allow independent scene and UI resolutions.

I went a little crazy looking at the empty depth buffer bug, as it really looked like it shouldn’t have been the case. We were rendering into a RenderTexture with a correctly set up depth buffer, and it was attached to the camera’s targetTexture property (which is, in our case, how Unity wants you to render into these targets).

Ree saved me by making a minimal test case and finding out that if we ran the commands AfterFinalPass instead of AfterEverything the depth buffer was still populated. Unfortunately, this is before the image effects are run, which means things like depth of field affect the lasso.

It’s not game-breaking, and that’s not the usual angle to be commanding larger groups from, so we aren’t going to hold back the patch for this issue, but we will resolve it in a future patch.

Next up on the Mac front, I’ll look into a weird bug affecting overlay text positioning and our Mac build pipeline.

Have a good one folks!

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Hey folks,

As the macOS build is rapidly approaching being shippable, I decided to spend the day looking back into how Steam handles multiplatform releases.

I set up the requisite depots and, after a bit of poking around, got the build script how I’d like it. That let me do a manual push, and so now we have:

Of course, this is not available for everyone yet. We still have a bunch of things to do before this can go public. Including but not limited to:

• Changing our keybinding handling so we can make sensible platform-specific defaults
• Tracking down an error that happens on exit
• Performing heavy testing and fixing any critical bugs that appear
• Fixing up Symbiote issues
• Adding in-game info to inform players about the limitations of the current Mac build
• Updating the info on Steam and prepping for release.

Due to not knowing what bugs we will find, we are not giving a release date yet. But if all goes well, it will be soon.

Big thanks to all the macOS folks who have been so patient with us. We hope it’s worth the wait!

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team