Phew, this one took a while to get out.
The art team is hard at work, prepping the next big asset patch. Should be another fun one!
On Wednesday, I had some boring life stuff to sort out, so I wasn’t working that day.
On Thursday, Jonny and I had a catchup meeting and roughed out a plan for the animation system for tiles & props. To get working on this, I first need to extract the animation data into a format we can work with from the job system. It took a while to realize that, if you load a prefab from a Unity AssetBundle, the full curve information is no longer available. This is ok, as in TaleWeaver we work with the original prefab files, but it was still a slow journey learning the ins and outs of this part of Unity.
With that worked out, I wrote the first pass on the extractor. This was looking ok, but the standard asset serializer only supports classes, and I want the data in a job-friendly format. Now, Unity does have a serialization scheme they use inside their ECS when serializing Entities to their Scene format. They call these BlobAssets. These are fast, immutable, and pretty much ideal. However, they are not compatible with the AssetBundle serializer we mentioned early. To get around this, I have written an adapter that makes this possible. That took a long time, and I still would like to add a bit more data validation. However, I’m happy that I can now write the data in the way I want.
The next task is to rewrite the animation extraction code using this new store. I’ve been going slow here as I need to be able to uniquely a given resource (e.g. an animation clip) inside an asset, and I want to make sure that these are stable to the kinds of changes that are made when developing a tile or prop.
With that done, I’ll be writing a new system for packing the board asset data. I’ve looked at this several times when I was investigating CaptnProto and FlatBuffers, now I have a good workflow with BlobAssets I’m going to use that instead. The current JSON format will continue being used by TaleWeaver to allow the art team to iterate on that format as required; however, when we export an asset pack, we will use the new system instead.
And once all that is finally done, I can start writing the animation system :)
I have also been researching Unity’s new Physics engine again and am slowly designing how we are going to interface with that. It’s going well, but I wanted to get animations working first as some assets (like doors) move colliders using animations.
Alright, until next time.
Some good progress today. The new batcher seems to be laying out tiles correctly now, so I can kind of build again. I haven’t hooked into the new physics engine so I can only build on the build plane currently.
What was nice was I could do some quick performance tests to see what ballpark we are in. I was able to spawn 10000 tiles in one frame without dropping below 60fps which is very promising. There are things the code doesn’t have to deal with yet, such as animations and physics. However I’m feeling confident that we’ll be able to get a large speed up in tile spawning over what we have in the beta today.
Here is a very wip, potentially misleading clip :P
Next, I’ll be adding jobs to build the per-zone physics data. It won’t be the code that ships, but like this, it will give me some insights into how the final system might behave.
Hey again folks.
Saturday’s work went well. I spent most of it reviewing the current code and double-checking the tile spawning implementation. We’ve put out a bunch of fixes since the beta release, and so I wanted to be sure the code still matched my design notes from earlier in the development. Luckily it did, and working through all the code paths gave me a much clearer idea of what needed doing first.
It looks like I can get something working without having to handle uncommitted changes at the same time. This means the response time of build actions will be unacceptable (as it requires a round trip to the session host), but it will let me tackle the tooling and copy/paste before having to deal with that additional complexity.
That’s all for now.
 In TaleSpire, in order to keep network traffic low enough to be manageable, we send ‘operations’ over the network. These are instructions telling the game what to change on each person’s copy of the board. For this to work, all operations must be applied in the correct order. However, games feel bad unless changes happen as soon as you request them, so we keep track of changes that have not been given their final order yet. These are what we call ‘uncommitted’ changes.
On Thursday, I continued work on the batching code. I got a first approximation written, but upon trying to hook it into the existing setup, I noticed that disabling the current system is not trivial. In fact, I had a choice between working a bunch for a test that wouldn’t teach me much or just plowing into the real work of replacing the current system. I chose the latter.
This means that the goal I set for myself of “something rendering by the weekend” was not feasible, and I shouldn’t push myself unnecessarily. The task of replacing the system touches a lot of code and requires a different mental approach.
So instead of fretting Friday, I decided I’d take it off and just work Saturday instead. One of the blessings of working for yourself :)
Because of that, I have no news for today. I also expect that the updates from me for the next week will be variations of “Replacing part X of the old tile system”. However I will try to keep the posts coming in case anything interesting crops up.
Until then, Bye!
 Approximation as it just positions all the parts of the tile at the tile’s origin. So it’ll be a mess but will show if things are working. I did this as the math requires a focus to make sure I don’t screw it up and should be taken slowly.
 I have already made experiments to learn how the BatchRendererGroup behaves, and the process of writing the batching code had given me a good deal of the context I had hoped to get from the exercise.
It’s the summer holidays over here, so we’ll see a little less of Ree this week as he takes some well-earned breaks. However, you still have to put up with me :)
Today I’ve been looking at writing the batching for the rendering as we move away from Unity’s GameObjects. It’s slow going, but I should have something running before the weekend. This version won’t have GPU-culling, but it will let me progress on the rest of the systems that need rewriting. Once this is working, Ree and I can work out the bare essentials we need for the animation system the tiles will use.
I also had another brief look into Unity’s new physics engine, and I’m reasonably confident we’ll be able to drive that efficiently. More on that another time.
Back tomorrow with more very incremental news :)
Just signing off for the night, so not gonna write much.
I got the server patch tested and deployed. It will have no effect on the current TaleSpire release, but the next patch will start using it.
Right. Sleep is in order. Bye!
Hey folks, I hope your week has started well.
Ree has been busy taking care of business and working on rulers, and I’ve turned my attention to the backend.
I really want to get TS streaming zones rather than downloading the whole board, but before I do that, I want to look into any issues in the current system.
First orders of business are finishing the changes to session management and removing a bunch of old code. We have had quite a few updates to the server code since launch, and the old code has a mental cost when working on the system.
Most of this is relatively straightforward. However, it requires a lot of care and double-checking to make sure the updates never interrupt service.
I’ll probably push the server update tomorrow with is the safest part (adding new code). I can then update TaleSpire to use these new entry-points, and then soon we’ll be in a good position to remove the old ones.
Until next time.
Today we got another patch out, which felt good. Since then, work has continued of visuals for the rulers, and I’ve made a couple of tweaks I can show.
First, creatures have their own panel now. A little while back, we made placing creatures not transition to building mode, and this continues on that path of changes we want to the building experience.
I’ve also patched the backend and thrown in test UI for units. This will let you set the default units for the campaign. In time we will likely add ways to add multiple units (for larger distances), and we’ve also thought about per board settings so your overworld could be measured in a more appropriate scale. That is all still up in the air, though, and the UI is just so we can make progress with the rulers.
That’s all for now.
Hi all. Work has gone well today.
Ree’s been working across a few tasks include starting on the proper ruler UX.
I spent the first half the day working through the list of feature requests categorizing them. I’m hoping to put out a more organized list by the end of play tomorrow so that you can have a peek at it before the Dev Stream this Friday.
That work is super tedious, though, so I took a break and added support for customizing the names of the four stats used by all creatures. It looks like this now:
This hasn’t yet been merged into master, but the backend has already been patched to support it. While I was doing that, I added the flag that indicates flying to all creatures. So we can now persist this info once we ship that feature.
That’s the lot for today.
Seeya next time
WARNING: The visuals for, and even the kinds of, rulers in this log are 100% temporary. The point is to work out a possible structure for the code and network sync. Drawing any data or conclusions from the clips presented in this update is meaningless.
Heya folks, today Ree has been prototyping props, and I’m going to ramble below about what I’ve been noodling with.
After seeing a conversation in the discord about area-of-effect, I got a strong desire to hack on rulers again. My goal was to make a prototype of one possible mechanism which could give us fairly a simple way to define rulers.
I wanted the ability to support simple point-to-point or volume rulers, but also ones with some additional adjustable parameter (like a cone area-of-effect)
The approach is as follows:
- A ruler is a container which holds some different visuals for rulers (which I’ll call presentations in this update)
- The ruler is a simple state machine with four states
- Placing the first point
- Placing the second point
- Adjusting the ‘parameter’ (optional step)
- The ruler might be visible to other players. In which case it handles the sync
- A presentation does not have to support a parameter
- Presentations can be cycled at any point before the ‘Done’ state
The ‘parameter’ is one part that might seem a bit vague right now. We should talk about it, but first, have a peek at this clip.
Unlike the sphere and line rulers, the circle area-of-effect presentation had an additional step after placing the center and defining the radius. It allowed the user to show a slice of the circle. To make this, I needed the third point to be on a plane defined by the first and second points. From the volume selection tool, I had already seen that it was handy to define a plane to raycast against, so I decided to add that to the parameter. The optional parameter is either a point on the board (just like the first two), or it can define a plane to constrain the point. Simple stuff but might allow some useful tools.
So this prototype is done we can kick the tires and see if it’s in the right ballpark. It’s totally fine if we throw it all away, or gut it and do something similar. The main thing is that it’s something tactile in-game that we can play around with.
With this itch scratched, I’ve jumped branch to look at the session/chat panel prototype again.
That’s all for now. Seeya
p.s. Here is a little clip showing sync working between two copies of TaleSpire.