TaleSpire Dev Log 313
Hi folks,
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”).[0]
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.
[0] 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.
ttrpgacademy
ttrpgacademy
·doskious
doskious
·The paradigm shift here is motivated by the change from a static, fixed set of minis (for which static attribute values are uniformly constant and always known to all clients), to a variable set of minis (for which individual attribute values, despite their remaining static from the frame of reference of an individual mini, are explicitly neither static constants nor inherently synchronously available -- in that different clients might download the asset data at different speeds -- from the frame of reference of each participating game client).
The implications for the degree to which minimization of synced data exchange between clients (mediated by the central server) is being implemented here is also very encouraging.
This kind of realization (and trivial solution) underscores the value to be had in Letting Developers Take Their Time properly. :D