Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team
I’m back from my break and have been getting stuck into things for the last two days.
- I’ve updated the HeroForge convertor to use some metadata embedded in the model (previously, this was in a separate file)
- Thanks to some changes by HeroForge, I can now separate the ‘extras’ from the base so we can use our own base (which we need for the indicators)
- I’ve tested our code with the production version of their API (I have been using their api sandbox until recently)
- I tried making some very large minis to explore edge cases of the conversion process.
- I’ve merged the latest work from the master branch into the HeroForge branch.
- Worked on some server stability improvements (still got some code-gen things to finish there)
Tomorrow I’ll be focusing on making tools to help the team with support tickets. Currently, things like restoring deleted boards rely on some hacky scripts I wrote ages back and are not in a state useful for anyone else.
I’ll be visiting Ree from Friday to Monday to work on HeroForge integration together. I’m hoping to deal with most of my loose ends on the tech side during that time. It’s optimistic, but we’ll see how it goes.
I had a lovely break and am glad to be back into the swing of things again.
I should have another dev log for you tomorrow.
I’ve been bamboozled, hoodwinked, and led astray.
I was tricked into adding a feature I was not ready to add, but we will be shipping anyway.
Today we are talking about creature copy/paste!
So, creature copy/paste is a bit of a minefield. The reason it has been delayed is that supporting everything we want is hard. For example, if you can copy/paste a creature, you expect it to work with slabs, which means selection bounds should work with them, which really implies multi-delete should work too… and undo/redo.
This is not trivial. Multiplayer undo/redo gets hard in ways that you cannot get around with quick fixes. Explaining why would turn this post into an essay, so I’m going to ask for your forgiveness in not covering this and instead ask you to trust me on that point. 
I did try to get it working before the Steam release, but it got nasty, and it was a case of pushing back the release or delaying the feature. I’ll admit that I didn’t expect I wouldn’t have revisited it yet, but c’est la vie.
Just a warning, this story doesn’t end with all of the above being supported, but you will be able to copy and paste creatures in (and out of) the game soon.
This all started with me trying to add “creature blueprints.” The idea of creature blueprints is to let you right-click a creature and generate a talespire:// URL containing all the setup info for that creature. This would allow you to share these blueprints with others. It was a simple, neat idea.
So, in short order, I had it working. You could right-click and click a button to get the URL. For convenience, we allow people to paste talespire:// URLs into TaleSpire to get the same effect as following the link . It seemed like the correct behavior, so I added that too.
I showed it to some folks, and they said it would be neat if Ctrl-C did the same as the button. It sounded good to me, and, dumb as I am, I didn’t notice until I tested it that I had just been prodded into adding creature copy/paste .
Of course, it lacked all the complimentary features that I listed above. But this time I looked at it, I felt a bit differently. No, it does not work with undo/redo yet, but neither does spawning creatures right now. This means it isn’t out of place in the current build. It also is only about copying single creatures at a time, so none of the expectations around selections apply yet.
Honestly, I should have realized this a lot sooner. I just have to chalk it up to experience and remember to challenge my assumptions more. “Perfect is the enemy of good” seems relevant here.
The next thing to crop up was that when you paste a creature, it comes with all its stat values. However, the names of the stats in the campaign the creature was copied from might not match yours. In the future, the stat names should probably belong to a rule system, and the blueprint should hold an id to the rule system in use. However, I don’t want to repeat the same mistake by waiting for future features. So let’s get something simple out.
We are adding a copy button to the stats settings. Clicking it adds a URL to the clipboard, which contains the names. You can then ship these around to allow others to quickly apply the same stat names as you.
While not being the smoothest journey, it is working, and I want to get this out to you asap. We are still testing and ironing out some of the uglier bugs, but we haven’t seen any scary release blockers so far.
More news on this coming soon,
 Even just selecting and deleting is scary. What if you select 100 unique creatures, delete them, and then hammer undo/redo a little? The server has to be informed of all these changes, and that is no small amount of data. And yes, it’s trivial to come up with ideas for handling this, but being good enough 90% of the time is not good enough. In short, this feature needs to be written slowly, carefully, and with testing.
 We added this when we saw confusion around how to use talespire://published-board URLs. Probably due to being used to how slabs worked.
| It really is staggering how blind one can be when being single-minded. I knew what I was making so clearly that what I was actually making was a surprise :|
As you’d expect, I’ve been working on HeroForge stuff.
I carried on with metadata integration into the conversion process. Most of Monday was messing around with HeroForge and looking at what kinds of scales, bases, etc., we get for different builds.
I had a few questions about some values in the metadata, so I sent off an email to HeroForge and, as always, got a quick response. So I know what to mess with next.
I had some time before the response came, however, so I did some work on internal tools. I resurrected some unfinished code for managing the news feed.
Both the news feed tooling and the HeroForge code required patching the backend, so I did that too (yay erlang live patching)
That’s all from me for today,
Have a good one!
p.s. Amongst a ton of other work, Ree has got a few bug-fixes/tweaks written, so I’ll probably put out an update tomorrow with those and the fix to the “names of hidden creature incorrectly visible to players” bug.
Work continues well on the HeroForge Integration.
In the last dev-log, I wrote about a specific issue related to perception updates. I was pretty confident with the solution I had come up with. But then I had a sleep and didn’t like it anymore :D
So I reworked that code again, and I’m now much happier with the approach. The TLDR is that in cases where the creature index (some metadata) isn’t yet available, we queue up the perception updates. There are, of course, details that made it easier said than done, but the result should serve us well.
Next, I started integrating the miniature metadata from HeroForge. We can pull metadata for each miniature as well as the asset file itself. This contains a bunch of info that we need, such as points of interest like head/s, chest/s, hand positions, etc.
I made a quick first pass that used this data, and it looked good. The first draft helped me spot places that were sub-par, so I’m currently rewriting it.
Technically this is all going well.
On the more human side: I needed to visit the police today to finalize my permanent residency. The Norway side of this has been flawless, but dealing with it put me back in the Brexit headspace, along with other thoughts I was happier leaving back in England. This distracted me today, and I decided to work Saturday instead and take the afternoon for some rest and games.
Hope you are having a good day,
 I was only pulling and processing the metadata when pulling the mini itself. If I, instead, handled it before downloading the model data, the game could start using that data without waiting for the whole mini to download.
To support HeroForge and creature modding, we had to start supporting the spawning of creatures before their meta-data is available locally.
This means (amongst other things) that we don’t know the head position and thus can’t correctly calculate vision when a creature moves.
As getting this right is one of my blockers, I decided I would take today very easy and not force a solution. I wanted to play around and give myself time away from the screen to think about it.
Initially, I thought that I might just sync the head position to other clients when a creature is spawned and when a board is synced. However, this fails in the following scenario:
- Player A joins a board
- The board contains a creature they don’t have locally
- Player A’s client starts downloading the creature
- Player B joins same board before Player A’s download completes
- Player A is now responsible for syncing the board to Player B, but doesn’t have the data for the creature
Perfectly reasonable, but messes up the approach. After thinking it over and discounting another idea or two, I decided to sync the head position along with position and rotation when a creature is dropped (dropped in this case, meaning released from the player’s “hand”).
This had me revisiting the code that handles syncing the creature drop, which was a little dated. I cleaned this up, and it should now be trivial to send this data. I’ll add that tomorrow and start testing.
So that’s it, not much for a day, but I’m glad I wasn’t rushing this.
Have a good one.
 The idea being that the player should have a creature loaded before being able to move it. I’ll have to add some UX to communicate this clearly.
The server upgrade today went well. Since then I’ve switched to our HeroForge branch of TaleSpire and was able to pull my first mini from production, which was very satisfying.
Now to do all the remaining stuff. After the butt-ugly merge I did yesterday, I have to test everything slowly to ensure I haven’t broken anything. I took an hour or so to test basic creature behavior and started writing a manually testing script.
Another big issue I want to deal with early is that we can no longer be sure creature meta-data is loaded before joining a board. This means (amongst other things) that we don’t know the head position and thus can’t correctly calculate vision when a creature moves. At the very least, this means that we need to push the head position to other clients when a creature is spawned and when a board is synced.
That might be enough, but I need to test the theory first.
After that, it’s UI, base conversion, stuff, and also things. But we’ll get to all those in future logs :D
Have a great evening folks.
Happy new year!
We will be performing server upgrades at 11:00am UTC on Monday, the 3rd of January. You can see what time that is in your region here https://www.timeanddate.com/worldclock/fixedtime.html?msg=TaleSpire+Sever+Maintenance&iso=20220103T12&p1=187&ah=2
We have scheduled two hours for the maintenance, but if all goes smoothly, it will take much less than that. During the update, the servers will be unavailable or unreliable.
The upgrades aim to fix a logging issue we have had for a while and add the code for the upcoming HeroForge integration.
Have a great weekend folks.
p.s. Please note, this does not mean that HeroForge support will be available immediately after this upgrade. This is just one step in the process. We will keep you posted with news as it develops
Today has been focused on the upcoming HeroForge integration.
I’ve tested the server code with the current build, and all is looking good so far. I will put out an announcement to schedule the server as soon as we have decided when that will be. This will also land some other bug fixes I’ve been waiting on, so I’m eager for this.
I’ve also started merging the master branch into the HeroForge branch. Both have significant changes, and so it’s quite a beast. I could see this taking me a day or two.
Also, the new year is here, so work will be a little broken up around that.
That’s all the news for today,
It’s my first day back to work, and I’m happily settling back in. I only tackled two things today:
- I added some options for use in the Unity Editor to allow username + password login instead of Steam. This lets us test interactions between GM & player clients more easily on one machine
- I fixed a regression where names of hidden creatures have become visible to players again.
Tomorrow I’ll probably tackle another smaller bug, but I’d like to focus on getting the next server patch ready. That one lands fixes and the bulk of the HeroForge backend code. It’s working with my HF branch of TaleSpire, but I know there are some places where the master branch doesn’t play nice with it.
That’s all for now. Hope you had a lovely Christmas.
Since last time I’ve worked on the polymorph feature, which is going quite nicely.
We still need UX, better transitions, etc. But the direction feels good.
Photon suffered what seems to be another attack. As the attacks affect specific regions, we pushed a patch to TaleSpire to redirect users to different regions. It is currently just a simple lookup table, but it was the fastest way to progress. The next step on that issue is making server changes to allow region remapping per campaign session.
A couple of weeks back, I did some performance work to improve the handling of large boards. I pushed a build of this to Steam for some internal testing. An issue was quickly found in hide-volumes, so I’ve fixed that and pushed another build so we can continue the testing. After that, we’ll merge that branch and ship it to you folks.
I also found a bug that hide-volumes don’t save when placed in a zone with no tiles or props. This should be an easy fix.
Continuing the subject of bug fixing, I am spending this next week fixing reported bugs. I have no strict criteria for which I’ll be tackling. If I can replicate the problem, I’ll try fixing it :)
That’s all for now. I hope you have a good day.