Heya folks!

In preparation for creature modding feature shipping, we are making the tool available so you can try it out, and we can fix any egregious bugs you find.

You can find a guide on how to get the tool and how to use it over here:

https://talespire.com/taleweaverlite-guide

NOTE: You cannot load the mods into TaleSpire today. This is simply a build of the tooling used to make the mods.

What is this (and what is it not)

TaleSpire is going to have a couple of ways for you to add new creatures to the game:

• In-game creature creator: A way of building creatures out of a palette of configurable parts
• Mods: mod-files are composed of pre-made assets outside of TaleSpire

TaleWeaverLite is for the second approach. It is a very minimal tool for composing pre-made assets into a creature mod that is ready to be used by TaleSpire.

It is not a modeling or posing tool. It expects content in specific formats and with specific layouts.

The expected usage is that the mesh and textures are prepared in other tools, such as Blender, and using TaleWeaverLite is the final step in making a mod.

The good

Once you are producing meshes and textures in the correct format, it’s trivial to turn them into a mod. Simply drag them into the Unity project, set the fields in the creature panel, and save.

The meh

We’ve been using Unity for our asset tools for a long time. It handled processing assets for us and gave us a UI we could use to make tools.

This means that to use TaleWeaverLite, you need to install the free version of Unity.

We have mixed feelings about this, as packaging this stuff for public use has not been as easy as we had hoped. Your feedback will help us decide whether to stick with this in the long term or to start moving to a more standalone tool.

The future

We are busy working on the backend changes needed to support the new creatures. Once we have that done, we’ll wrap up the needed changes in TaleSpire and get ready to ship. We are pushing hard for this and hope we can get this in your hands very soon.

By getting TaleWeaverLite out now, there might even be some new creature mods ready to ship the moment that TaleSpire gets the feature!

Until then, thanks for stopping by.

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

Heya folks!

We’ve found a bug with creature tags where they were only working in the community browser and not the library. That fix is in the works and will be shipped as soon as it passes the tests.

It also seems that mod.io has a bug (or has changed it’s api) so that tag searches now return results for things that match any of the tags, rather than all of them. This breaks the expected behavior in TaleSpire, as you can’t refine searches properly now. We’ve reported the issue and will keep you posted.

I’ve got a build of TaleSpire with the new physics and batching performance improvements. It needs final testing, but then it’ll be on its way to you. We’ll probably keep it in public Beta for one week, just in case anything else has slipped through the cracks.

The batching changes have finally put us in a good place to look at replacing the shadow implementation, which has been blocking us from upgrading Unity and getting some of the fixes and improvements we could really benefit from. I’m currently investigating how difficult it will be. Hopefully, it doesn’t put up too much of a fight.

Whatever happens there, my attention will return to the internal systems upgrade as soon as possible. That’s a very vague-sounding task, but it should make it much easier to fix a long-standing bug if I can get the code in the shape I want.

More news soon.

Peace.

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

G’morning folks.

While I wait to see if there are bug reports from the hide-volume improvements Beta, my focus is back on Physics optimization.

It’s very important to us that TaleSpire runs well on lower-end machines. Not least because the cost of upgrading is, for now, so much higher than normal.

I’m currently working on the Physics front-end. The code that the game interacts with to use the physics engine. The changes allow more of the physics code to run concurrently with other tasks and to replace code compiled using Mono with code that can be Burst-compiled.

On a board with a lot of creatures, a significant amount of time was spent simply writing data into and out of the system because the GameObjects we were using stopped us from using the Burst compiler. I’ve rewritten all of that code, and I’m confident that those steps will not be an issue in future.

I’ll keep on plugging away at this. I’m not loving my old spider’y code, but untangling it is letting me find better ways to get performance out of it.

See ya 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

Heya folks.

It was lovely to see a bunch of you on the bimonthly banter last week. Since then I’ve been keeping busy.

Monday was spent on research. I had a terrifying number of tabs queued up, and it was time to work through them! The reading was not focused on a specific feature, but instead is about giving me new tools to apply when challenges appear. I won’t link everything I was working through, but here are three I enjoyed:

• Ray Tracing of Signed Distance Function Grids It was really neat to see how to use trilinear interpolation to get the exact ray intersection.

• H-PLOC: Hierarchical Parallel Locally-Ordered Clustering for Bounding Volume Hierarchy Construction We have a lot of things to draw so techniques for quickly building volume hierarchies are always of interest. Also I’m not as familiar with more complex compute strategies so this exposed me to a little of that.

• Filtering, Convolutions, and Quaternions This is such a gem. Incredibly well written, and a goldmine of information. Unlike many of my friends, I don’t have an audio background, and so didn’t get exposure to signal processing until much more recently. This article was just what I needed to start a whole bunch of puzzle pieces falling into place in my head.

So a very fruitful day, all in.

Today I’m back on physics. I’m slowly updating our frontend to the engine, trying not to break anything in the process :) If all goes well this will give a good performance boost to the physics code.

That’s all from me today. See you in the next one.

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

Heya folks,

Wait.. I already did this today. I wrote a dev-log, and then told myself, “Alright, I’ll just code this one thing and then post it”… and now it’s midnight. So, just before my original dev-log here is the one from today:

I worked on exactly the kind of polish I mention below, with lots of focus on how the system communicates errors to the user.

I’ll leave it at that as there’s already a whole post to read.

Bye!

Heya folks,

Work continues well on the VFX-System[0]. Over Friday and Monday, I got the effects running in Unity’s edit-mode instead of just play-mode. This makes it way easier to iterate without having to start the game every time. It took a little extra prodding to get it behaving well in prefab-scenes too, but that also works as expected.

Along with the usual bug fixes, I also got to work on little details that make the experience nicer for the artist. Nicer defaults in new assets, right-click menu options for easily adding effects to scenes, pre-configured effects so things are immediately visible when you create them. And so on.

Today I’m going to continue working on polish, and then I’ll dive back into effects that procedurally generate geometry, instead of just drawing meshes or billboards. We had that working in an earlier build, so I don’t foresee that being difficult.

After that, it’s all about fleshing things out! I’m hoping to hand this over to Ree later this month. Then, as they explore what Alex and I built, I’ll get stuck into the next project (the system architecture improvements I mentioned in a previous log).

Today is one of those wonderful days where the road, while long, seems clear. TaleSpire is a lovely project to work on, and it’s going to get so much better.

I hope inspiration finds you today too.

Peace.

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

[0] I’ve been calling it a particle system, as the name was more familiar. However, in our current terminology, the top-level concept is an ‘Effect’. An effect is a container for multiple ‘Particle Systems’. Each particle-system updates separately, but each particle can add new particles to any of the other systems (amongst other things).

Today I continue plugging away at our effect system.

I’ve been steadily writing code to handle the various ways an artist may reconfigure the effect while it runs.

It’s a lot of work, but I’m seeing the light at the end of the tunnel. Tomorrow I hope to finish the code around particles that spawn other particles, and to take a good crack at the code that uploads uniforms to the compute-shaders. There are improvements to both that have been on my wishlist.

That’s all from me,

Goodnight from Norway.

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

Allo folks,

This dev-log is for the last two days

I’m working on the code that runs an “effect” as defined in our particle system. This code is currently called the “effect-driver” which may change, but will do for this log.

The effect-driver is a MonoBehaviour (a component that lives on Unity’s GameObjects and gives them behaviour) that holds a reference to an effect made in our system. It then does three main things:

1. Dispatches the various compute-shaders that updates the particles, and then the code that draws them

2. Notices any changes to the definition of the effect and updates or recreates the buffers used for the effect

3. Provides a Unity-friendly UX to the folks configuring the effects. This means both that it’s associated with a GameObject and that it provides UI in the inspector to configure the values used by the effect.

This is already a bunch of work, but there are also other concerns. Unlike normal game code, we need the effect to run in edit-mode rather than just play-mode. This is the norm for tools like these, it would suck to have to run the game every time you wanted to tweak how a particle effect would behave.

There is a tool for this, ExecuteAlways. I’m getting used to how this works. Along with disabling domain-reload (which I mentioned in the last log), this does make fairly major changes to the normal flow of a MonoBehaviour’s lifecycle, so I’m having to read a lot to make sure I have actually understood what it’s doing.

Progress is steady though. I am currently working on the code that works out what parts of an effect have changes and reconfigures the driver.

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

Heya folks,

Today I worked on updating a bunch of our libraries to support a feature in Unity: Disabled domain reload

You can find out the official details here. It does a good job at explaining it actually, so I’ll quote it here:

Domain Reloading resets your scripting state, and is enabled by default. It provides you with a completely fresh scripting state, and resets all static fields and registered handlers each time you enter Play Mode. This means each time you enter Play Mode in the Unity Editor, your Project begins playing in a very similar way to when it first starts up in a build.

Domain Reloading takes time, and this time increases with the number and complexity of the scripts in your Project. When it takes a long time to enter Play Mode, it becomes harder to rapidly iterate on your Project. This is the reason Unity provides the option to turn off Domain Reloading.

It doesn’t affect you folks directly, as it’s purely a Unity Editor thing, BUT being able to iterate faster will be huge for us, so it’s worth the investment.

It took all day, but in the project where I am developing the particle system, the time to enter play-mode went from over six seconds to under one! I’ll take it.

Learning this has been very useful so now I can dive into writing code to run the effects in edit-mode with more certainty.

Until tomorrow,

Peace.

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

Friday went well enough. I was preparing to rewrite the editor code that runs the effects, as I need to make it work outside of play-mode.

This was a good time to restructure the project, so I was doing that and experimenting with what Unity allows it terms of spreading the definitions of scriptable objects over multiple assemblies. The answer is, in short, it doesn’t. The C# compiler is happy enough with it, but Unity’s runtime is not. It’s fine though, it was simply an effort to keep the codebase cleaner by separating the code that is needed at runtime from the parts that are not.

Tomorrow I’ll be getting stuck into getting particles back on screen, and exploring ExecuteAlways, which is something I’ve only used for very simple systems before now.

Seeya in the next dev-log

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

Hey all,

Decent progress yesterday .

• Fixed cases where curves connecting nodes were laid out incorrectly during certain inputs
• Dedicated types for various internal IDs
• Added the ability to drag/drop resources from the Unity project directly into the canvas.
• Improved debugger integration
• Users can now replace connections without removing the old ones first.
• Added a way to specify default values for connectors
• Got user-defined functions to compile correctly when used in other effects.

The drag/drop one is simple but it’s nice to be able to drop a texture into the graph and get a texture node immediately. The same is true when dropping in a user-defined function asset.

The connection replacement, too, is a nice quality-of-life improvement. Previously, connectors could be turned into value slots with a right-click action. However, based on feedback, we’ve moved to showing the value slot whenever a connection is not made. It doesn’t always make sense to have a slot though, for instance, you wouldn’t want to type a texture!

Today I’m going to focus on improving resource handling. In the graph, resource-nodes are nodes where the value comes from the CPU, rather than being computed on the GPU.

Seeya you then.

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