Hi folks,

You may have noticed that I’ve been gone for about a week. The reason for that was that I caught the flu, and it’s been doing a merry dance on me since then.[0]

I’m not entirely back to normal, I still run out of energy after about five hours of being awake, and my coughing sounds like some satanic accordion. But I am on the mend.

My sincere apologies to those of you who I’m meant to have contacted. It simply hasn’t been possible. I’ll catch up when this passes.

For those wondering, yes, this did affect the HeroForge release date, although it has not changed the month it is happening. Also, this has not given us extra time for polish, as I’d haven’t been able to code at all while ill (which has been driving me crazy!). That said, other TaleSpire work has continued, and Ree’s latest post is mind-blowingly exciting.

Here in Norway, we have Easter break rapidly approaching, so we will be away for that. Ree will be along with another dev-log talking about that, though.

Thanks for bearing with us, folks. I can’t wait to be back working while not rattling.

Take care

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

[0] I did test that it wasn’t COVID, which was a relief.

Hey folks, I’m quite frazzled today so no proper update of what’s going on. I can say though, that it’s all going well, and we are still expecting the beta launch to happen on the same date that we still aren’t telling you :P

In lieu of text content, have some video content!

This is a speedy video showing the process of connecting a HeroForge account, linking some creatures to the campaign, and showing how things respond to being unlinked and relinked.

We are still working on bugs[0], and the UI is still changing. However, we are excited to make the experience as smooth as possible. So that this could be done effortlessly, even in the heat of battle.

Please note that you do not need a HeroForge account to play with miniatures created by other players, even if you are the GM. An account is only required for sharing your creations with a campaign.

Alright, I’m heading out.

Have a good one!

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

[0] that ugly lag when opening the HeroForge menu is already fixed, for example.

So while we wait to announce the release date, let’s talk about some other details.

The road to HeroForge release

The release itself is going to be a two-parter. First, there will be a short open beta, and then the more public “launch.”

Now, this is a bit unusual for us, so why are we doing it?

In short, HeroForge has a much larger community than ours[0], and when they publicize a new feature, a lot of folks will rock up to try it out. By having a short beta before pushing announcements everywhere, we all collectively get to kick the tires and find any scary bugs that snuck in before any bigger rush of people.

There are no restrictions to participate in the beta beyond having a HeroForge account[1]. The doors will be open, and you are all welcome in, but we won’t be doing a big PR push immediately, and the word “beta” will be slapped on a bunch of places.

Once both teams are happy, we will remove the “beta” label and then fire up the social medias, blast out announcements, and see how it goes!

The fact there is no restriction will confuse a few people, but after having you wait for so long, we couldn’t stand the idea of only letting some of you in for the beta. This feels like a decent trade-off.

Coming soon

Already we are turning our eyes to what we will be working on next. The art team will be busy with the cyber-punk and scifi pack, so it’s definitely a good time to ship some features.

This is ideal as we have a ton of stuff that feels 80% done and just needs that work to get it out the door.

Even if we marked it experimental and required turning it on in the settings, it would be good to get this stuff out.

One example of this is the change to rulers I’ve been calling “tactical rulers” internally. That change means a ruler isn’t cleared the instant you click on something else. This makes moving creatures (especially troops) pre-measured distances much easier. It is also a requirement for us to be able to start on area-of-effect markers (but that’s a different story).

Another thing that marries well with tactical rulers is group movement. Ree has already put a lot of work into that, and getting the last 20% feels doable.[2]

I feel like I’m tempting fate if I start teasing the other features in that “80%” category, so I’ll leave it for now, but I’m feeling very optimistic about what comes next.

That’s all for today

So yeah, that’s the lot for this log.

More news in the next one.

Have a good day!

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

[0] But hey, no trades, our community rules!

[1] Of course, you or one of your party will need to have bought some digital minis to be able to bring them into your campaign.

[2] We will probably limit the number of uniques that can be added to a group initially. This is due to the amount of data that must be sent to the backend on each movement. I know what changes I need to make on the backend to make this more efficient, but that will take some more time. Non-unique creatures are handled totally different and so won’t have that restriction.

Hey folks!

Things are going great over here. Here’s the latest from me.

Server stuff

Last week was given almost entirely to server work, continuing the work from the previous log. I was able to get our Packer scripts up to the point where it completely replaces how we were building our old docker containers and Amazon AMIs. They’re also way easier to maintain.

HeroForge

We had a planning meeting with the HeroForge team last Friday, and we now have our internal timeline, which is super exciting for us. I say ‘for us’ because we aren’t telling you the date yet so as not to put extra pressure on both our teams.

While that date is ‘soon,’ I’ve probably said ‘soon’ in so many different ways already that it doesn’t really convey how soon we are talking, but you’ll see pretty quickly from what I’m up to how close things are.

Speaking of which!

I am currently working through my last coding tasks marked mandatory for release. All of these are related to handling failure cases and how to expose the issues to the user.

Then I’m onto the tasks marked as things we really should have. This currently includes:

• Adding a panel for managing errors (which will be essential for modding)
• Changing where the HeroForge thumbnail data is stored

Ree has been working on the UI, and as soon as that lands, I’ll merge my stuff and start recording videos of the entire flow of importing minis. It’s a very short process, but we need tutorial content for TaleSpire and HeroForge’s sites.

That takes us to the rest of the work leading up to release. We need to:

• Produce various texts, videos, and images for documentation
• Set up a new Steam branch for testers
• Chase things up with lawyers (for the wording of the ToS around HeroForge)
• Work out our point of contact for HF if they need support
• Write up our PR stuff for the release
• More testing

Writing stuff for humans always takes way longer than I think, so I’m aiming to have as much of the coding done by the middle of next week as possible.

Aaaaaaaa it’s exciting!

We have also been preparing for the feature work we will be doing immediately after this ships. I think we’ll be able to have some cool features landing before sci-fi ships :)

Alright, enough vague info for one day! I’ll be back soon with as many extra details as I can share.

Peace.

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

Hi folks,

Let’s start with HeroForge news. We’ve been working closely, iterating, and finding shortcomings in the format for some time now. As of yesterday, we have finalized the format and conversion process and are looking to the next milestone. We obviously wouldn’t announce any dates for a potential release without HeroForge’s involvement, as there are naturally a lot of overlapping concerns. Not just technically, but from the PR side too. So today, all I’ll say is: Things are looking good!

I’ve also continued work on the backend. I have been working heavily using terraform to get all our backend infrastructure defined as code. In the future, we want to be able to spin up services[0] in whole new regions trivially, and this should let us do that.

Currently, I’m experimenting with an unfinished setup in the EU. This never went live but is a reasonably clean setup and makes for a good testbed.

Please note: I’m not experimenting with live infrastructure. None of this is currently used by TaleSpire, and so any bugs you hit are not related to this :)

As part of this process, I’m working with another tool from HashiCorp, packer. Packer is letting me define our docker containers and AMIs from common scripts.

Previously we have run docker containers on our EC2 servers. However, the separation from the host has caused complications in the past, and, personally, I prefer just using docker to make development cleaner. My goal with packer is to make our AMIs and containers as close to functionally identical as is reasonable. This will remove a small overhead[1], simplify some edge cases, and make building AMIs waaaay easier[2].

Today I’ll continue with that backend work.

Seeya folks!

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

[0] Using this term generally, we don’t use a microservice architecture [1] Which won’t matter now, but that I believe certainly would if we start taking on more real-time traffic [2] I could probably argue that it will make the dev environment closer to the running environment, but that’s another ramble.

Hi folks,

After the latest Photon issue, I decided to look into our options for our real-time traffic going forward. We don’t have any immediate plans to change our setup, but it was bothering me that I didn’t have a good overview.

That took all of Monday and half of today, and it led neatly into reading about tooling for helping the portion of the backend we host.

It has all been research, so I don’t have anything specific to talk about yet, but you’ll have a blog post about it as soon as that changes!

Hope you are doing well, folks Chris

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

p.s: Hats off to the art team for the latest patch!

Yesterday the code gods conspired against us, so we didn’t get to start on the latest iteration of the HeroForge mini specification.

Instead, I focused on packages.

We use a bunch of experimental packages, and naturally, these have bugs from time to time. Yesterday we had such a case with Unity.Entities. The package had already been fixed in the latest update, but that fix was incompatible with the latest version of another package with its own bug (and so on it goes).

This led to me shuffling around packages versions until I got a setup that will work for now.

The amusing part is that we will be removing the Entities package soon anyway. We currently have it because:

1. Unity.Physics depends on it
2. We use a couple of serialization tools that happen to live in that package.

Neither of these reasons will be valid for long, however. We are forking Unity.Physics to optimize it for TaleSpire’s specific use case. As we don’t use Unity’s ECS, we don’t need the ECS integration in the physics engine.[0]

As for Serialization, I have already started working on internal tooling for defining data formats and convertors between them. This will help in a few ways:

• It will reduce the amount of hard to maintain serialization code.
• It will make writing & upgrading binary formats more approachable to more of the team.
• It should make it easier to iterate on the formats used in mods without worrying about breaking what is already out there.

I only need the basics of this to allow us to drop Unity.Entities. That, in turn, will let us to pull the latest version of the conflicting packages and put us in a great place to improve the performance of physics.

And that, for today, is that!

Seeya you around.

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

[0] In fact, I did this today! It’s sitting on a branch, ready to merge

Heya!

Mac support has been going surprisingly well. Let’s natter about it!

Progress

The first order of business was pixel-picking. This requires custom native code as we need to use features of the graphics API not exposed by Unity. I had written the DirectX version over a year ago, but this time I needed something for Metal. I haven’t written any Metal code before, but I found this article and this code sample and felt pretty confident I could bodge something useful.

This turned out to be correct. I am very lucky that, at my previous job, I suffered through so much ObjectiveC development as it made the process much easier. After a bit of experimenting, the solution turned out to match the form of the DirectX one very closely, so the API for our plugin could remain the same.

It was fantastic to see picking come to life!

As you’ll have just seen, the cursors are HUGE! It turns out that Unity will try to match the cursor size as close to the source image as possible, so I need to go adjust the import settings.

Next up, I set myself to fixing a mistake in the build scripts[0], and then I needed to look at some more platform-specific code.

In Unity, if the game is in fullscreen mode, the reported resolution of the display is that of the fullscreen game. This is handy in some cases, but not for us. We want the full pixel resolution of the monitor that the game is currently on (according to the OS). This is easy to get from the Cocoa API, and so this was another job for some native code.

With the pixel-picker under my belt, it was extremely simple to get this written.

Another thing that turned out to be super easy was supporting the talespire:// URLs. Unity has a simple setting, allowing you to set up custom URL schemes. It was so easy that there is nothing else to say about it. So here’s a picture instead:

Issues

There are plenty! The big one is that lots of shaders are broken. As an example, here is water:

The fps is also bizarrely low. Below I have a screenshot of the profiler. You can see that the work on the main thread is done in under 6ms, and the render thread is done by ~9ms. VSync is enabled, so I expect it to wait until 16ms before starting the next frame; however, it is waiting until ~25ms. Clearly, something is wrong or is missing from the graph.

This could be anything from a two-minute fix to a two-month one. We’ll have to see!

What’s next?

Clearly, there is still plenty to do before mac support can ship, but tomorrow I need to switch back to HeroForge and modding. I am also no shader expert, so I’ll definitely have to kick this to Ree so he can work out what is breaking there.

I’m delighted with the 10Gb network gear we purchased to link my dev PC and the Mac. It has made cross-platform development so much nicer than what we have had in the past and has helped Mac support progress smoothly.

So that’s it. I left out a bunch of smaller things for the sake of time, but I hope you’re as excited as I am for where this is going.

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

[0] If BuildPlayerOptions.locationPathName does not end with .app, the dll containing the compiled burst jobs is not being copied to the plugins folder.

‘Allo folks.

Yesterday seemed to want to stop me from working on Mac support, and it won. Today I turned the tables.

Before we get into that, let’s skim through some tasks from earlier in the day.

The first order of business was handling the renewable of some server certificates. This led neatly into one of the problems from yesterday, certificate authentication callbacks failing on the latest Unity version.

It turned out that, while the HttpClientHandler.ServerCertificateCustomValidationCallback callback is now broken, the global ServicePointManager.ServerCertificateValidationCallback one still functions.

I hate this global event as it is fragile to modification by other code[0] and is called for all requests when we only need it for specific ones. We only need to check requests to the backend against our pinned certificate, so I have to filter those cases in the callback. However, at least we can continue work.

I then updated our build scripts, so we could perform mac builds. As I previously had issues building directly to the network share, I now build to a temp directory and copy the files after completion.

Next was updating platform-specific code:

• Reliably obtaining the monitor size on Windows required some calls to the win32 API. For Mac, I’m starting by assuming the Unity commands will suffice and will write a native alternative if needed
• I updated the dylib for miniz to one that supports M1
• Updated a couple of shaders #ifdefs to include them for Metal
• Disabling the pixel-picker on mac
• A whole slew of code house-keeping stuff

That was enough to get TaleSpire to start, login, and load a board. This felt huge as the last time I tried this, I couldn’t make a standalone build, steam’s API didn’t support M1 mac, and I had run a hacker server locally just to get something running.

With all of this, I am finally ready to start coding the thing I tried to start midday yesterday :D

Well… almost ready. I just need to download XCode, and I sure do hate me some XCode. That’s just the price of Mac support, I guess.

Anyhoo, that’s enough for today.

Hope you have a great weekend. Ciao.

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

[0] because, as the docs say, “Despite being a multicast delegate, only the value returned from the last-executed event handler is considered authoritative”

Hey everyone.

Today has not wanted me to make progress!

I have a few working days before the new HeroForge asset changes are available, so I thought I’d look at other upcoming features. So I:

• reviewed the roadmap
• reread the server chat code
• got an overview of rulers
• came up with more emote ideas
• made some more notes for some potential gm tool for previewing what you players can see

But these are just notes. I wanted to dig into something. I did some reading around Metal (Apple’s graphics API), specifically how to read back data from textures. It looked fun, so I thought I’d dig into Mac support.

So I:

• updated the Unity version
• worked around a new bug
• pulled the latest version of Steamworks.NET

…and then promptly ran into a bug where https requests weren’t working. It’s looking like HttpClientHandler.ServerCertificateCustomValidationCallback is not working, and so certificate pinning is broken.

This is maddening, and I’ve spent a good few hours poking around code to see if another code path would work. So far, it seems not.

This means I should probably roll back to earlier Unity builds to see if they work. However, while this was going wrong, I found some server-side work requiring prompt attention. So it looks like that’s where my time is going next.

Yeah, so it was a bit of an annoying day. I was pumped to make stuff, and I ran into walls instead.

No worries, though. That’s just how it goes some days.

Have a good one.

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