Heya folks! I’ve not written in the last couple of weeks as we’ve been going hell for leather, trying to ship two patches a week.

That’s been very successful, and it’s a lot of fun to do from time to time, but it is pretty unsustainable when you hit bigger features. So this week, we are only aiming to ship the board folders. The good news, however, is that the feature I’m chipping away at now is creature mods.

So, where are we at?

Unity can pack stuff into things called AssetBundles. They are very flexible, but one downside is that you need to build one for each platform you are targeting. That isn’t nice for modding, and it also makes upgrading the Unity version stressful, as the AssetBundle format can change over time.

As we don’t need[0] all the features AssetBundles provide, we are opting to make our own cross-platform format that only supports the very few things we need.

The first task was defining a low-level format that only specifies blocks of bytes and an index. That was nice and simple to design, and I’ve left the save/loading code for another day, as it should be pretty straightforward.

From there, I’m making a format for storing meshes that is compatible with Unity’s low-level mesh APIs. We want to use that low-level format as it allows us to create meshes across multiple threads and also do so with a minimal number of copies. I got a nice draft of that format finished in the morning and then started fleshing out the implementation of a zero-copy de/serializer[1].

Until now, we have used Unity’s blob asset reference system. However, it means we need a dependency on an additional Unity library, and I’m no longer comfortable with any unnecessary dependency on Unity systems (due to how Unity has acted this year[2]).

I think I’m about 70% of the way through writing the zero-copy stuff. Tomorrow, I’ll start pushing meshes through this thing and see how it handles it. I’m sure I’ll hit plenty of things I forgot up to that point.

As soon as meshes are working, I’m looking into how we will handle textures. I’ve been giving it some thought already, so it should be quick to make some progress.

I’ll be sure to come back and update you once I’ve got some news to share on the texture progress. Especially as, from there, I should be able to dive into the UI that you folks will be interacting with!

I hope you’re having a good day,

Peace.

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

[0] And actually we actively do not want all the features

[1] Feels weird to call it that when the point is that you don’t need an explicit deserialize step as you just load it into memory and use it.. but meh. I can’t recall a better term right now.

[2] This might seem moot after they rolled back their proposed fee changes for many folks, but I disagree, and I furthermore think the same applies to WOTC. The company is still run by mostly the same people, they still want money, and it stands to reason that sooner or later, they are going to try and extract it from us again. “Fool me once” can be overused, but it feels appropriate here.

Well yesterday was nice! Borodust migrated the database without any major hitches and Golbin shipped another asset pack. I’ve been helping out but my main focus has been on board folders and the slab-browser.

My first pass at my server-side code was a little more broken than I thought, but all the fixes were easy enough. The UI side is also coming along.

That’s all from me for today, see you folks around.

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

Heya folks,

It felt good to get the slab-browser beta out, and while I do have things to fix before it is ready for prime time, I couldn’t help but take a swing at a different feature. One we have all wanted for a while. Board folders.

Today was mostly spent writing server code for this feature. I tested some of it but wanted to get some UI in before trying the rest. To that end, I’ve been hacking the basics together.

For the first version, changing a board’s folder will be done via a dropdown. Really, I’d prefer to make it possible to just drag boards into folders, but I’m not familiar with how to do that yet, and I don’t want to spend too much time on this as I NEED to get moving with the creature modding support. So, the first version will be functional, if a bit basic. I’m also not adding arbitrary nesting of folders for now.

Jumping back to the creature modding, I read more about what kinds of access Unity gives us to mesh data. I’m satisfied that I can make something to cover all the bases very quickly. It’s also tempting to look into Zeux’s excellent mesh optimizer.

That’s enough for today.

See you in the next one.

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

Heya folks,

For the last two days, I’ve been working on the slab upload. It’s going very well.

I’m currently cleaning up a lot of little issues with it, and then it’ll be ready to show it off. The main focus the last two days was being able to edit the details of mods you have already published. That was a slog until about six hours ago when it all started to click.

I’m also pleased to say we support multiple kinds of authentication with mod.io. This means you can sign in via Steam, email, browser, and even QR code.

This is all very meh without some video to show it working, however, so I’ll come back when I have fixed the remaining visual issues.

The big issue right now is that the list that shows published mods doesn’t like certain kinds of filtering and thus can leave gaps between items. I know what to do, but it’s gonna take some hours to code.

Right, seeya folks soon.

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

With yesterday’s realization that some of Unity’s handling of overlapping keybindings is broken, I needed to add our own workaround.

I knew I didn’t want to try and build a complete solution, so the first version was just to handle the issue that caused undo/redo on Mac to be broken.

To recap 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.

I’ve added a simple handler that detects multiple actions happening on the same frame and picks the one with the longest chain of modifiers. This works for the Mac undo/redo issue as both actions will fire on the same frame as z is the last key pressed and is the one that causes both to fire.

We will need to handle more cases in the future, but that’s a problem for another day.

I’ve got some new builds progressing through the build pipeline, so tomorrow, I should be able to ship a fix for that. Then, I can get back to business.

Hope you folks are well,

Seeya in the next log.

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

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