Hey folks, pushing this boulder up hill is slow going but it’s getting there.

Today I continued work on the ‘joining campaigns and boards’ code. Mainly I was looking at how we can used locally cached versions of the boards to make sure that when you log in you see stuff immediately. We of course ping the server to get the latest info on things like the campaigns you are a member of, but those requests can take a few seconds and the most common case is starting a new campaign or continuing and existing campaign.

Whilst working on the database side of this I was touching code I would have to revisit immediately when I got to ‘unique creatures’ (see yesterdays post for details on them) so I decided that I would write the tables and queries for those things today.

And that about brings us up to now, tomorrow will start with exposing this to the web front-end and then its back into the engine to consume this new stuff.

Seeya tomorrow!

Motivation is a fickle thing, after cranking through a bunch of quick tasks I end up craving something more meaty and meaningful to slam my head against, but give that month and I’m just craving the quick reward cycles of small tasks again.

Today was a switch back to the latter, I’ve been neck deep in the search stuff for so long the deadline went from feeling insane to hopeless. Getting that merged in late last night let me move onto refactoring how joining campaigns and boards is handled and it’s felt great.

A lot of the work has been tracing down what code owns what and massaging it into a new shape. Photon’s PUN library (the networking lib we use) has a concept of a ‘room’ where every client in the room can communicate. This maps nicely to our boards and this is what will allow us to have a single campaign with different party members in different boards concurrently (each with their own GMs if you have the people for it).

I have also stubbed out the code for the local and server autosave and started looking into how we handle ‘unique creatures’.

Internally we talk about any controllable thing being a creature, whether it’s a humanoid hero or a sewer rat. Most creatures below to the board and are stored with it, however a creature can be made unique which now means their data lives on the campaign and they can be moved between boards. Every player’s character is naturally a unique creature, but a GM can take any creature and make them unique. This can be cool for story reasons for example, maybe due to the player’s actions the aforementioned rat touches a forbidden emerald and becomes imbued with terrible knowledge, purpose and dark magic, the GM may want to have that rat be a reoccurring part of the story so making it unique makes that much easier to manage.

Ah I cant wait for all that to be working, tomorrow will be finishing off this board refactor and then I’m getting that unique stuff added. That will require changing serialization of both boards and campaigns but it shouldn’t be that tricky.

Until tomorrow,

Peace

Heya folks, last time was a video where we looked at some development surrounding the fog of war implementation. I’ve been hammering away on bugs, both the ones that showed up on the stream and plenty of others.

Things are starting to get a bit more solid and I’ll be merging that work into our master branch tonight so the others can start testing and working with it too.

I’m not super happy with performance in a few cases so I’ll be going back to that but there is a lot of other stuff to do first.

To finish off tonight I need to do a little work on the asset building tool and then tomorrow will probably be when I start looking at refactoring a bunch of the code around joining campaigns and other network related stuff.

Seeya tomorrow

Hi all, I’m going to delay doodles until the implementation is finished but we are changing how the fog of war works..again :p

The last version had some cases we hadn’t considered and so I’m hammering out a new version now. In fact I’m doing it now and don’t want to lose my focus so I’m gonna get back to that now. Sorry this is short but didnt want to leave you without an update.

Peace

Hmm today is a weird one to write up. On one had I made some progress on little tasks which are too specific to be worth expanding and on the other I found some rather annoying consequences of the fog of war implementation.

It all basically boils down to the current constraints result in some unintuitive or slightly sub-par experience and fixing them is fiddly. I want to do a big ol’ breakdown on this but I want to leave it until at least tomorrow as @jonnyree and I are going to have a planning meeting on this tomorrow.

This may result in a relatively large change so, given how little time we have left this year, we really need to nail down something that can work for the alpha and then stick with it.

This doesn’t stop us rewriting it during the alpha but that would make mean less user testing of each implementation which means less data and time to work with.

Trade-offs are.. well, a thing.

On that very insubstantial note,

Ciao

A tiny log today as I’m heading out to see some friends now.

Today I took a little break from engine work to look at server side. The main take has just been tweaking our the DB to store the data we want for campaigns and characters and supporting granular permissions for who can do what. Those controls may not all be exposed but it’s not hurting to have it there.

When the UI for the creating/editting campaigns lands I’ll expose this from the web server and hook it up.

Until tomorrow.

Peace

Hi again, today has been a day of churn. We have known for a couple of weeks that the way floors have worked in the prototype was unsatisfactory. For context you used to be able to delete floors and insert floors below others, which sounds great and felt great to.. on small boards. However when you start making a whole village and want to add a floor to a single building then the problems quickly become apparent, you add a floor to the entire village!

So instead of that we will be replacing it with the ability to select a region and:

• delete it
• delete it and drop the tiles from floors above down
• push tiles up to the next floor (which pushes the ones above up etc)

This will give the level of control we had before but without the caveats. Of course this requires a little more work from the user, but it feels like a necessary inconvenience.

Also, in order to be able to support large board in the future we needed to get away from anything that operated on entire floors so chunking up the board has been on the todo list for a while (we already had started this for the fog of war code). This is where the churn came in as, as you can imagine, floors were pretty central in the codebase so changing that out has touched a tonne of code. Getting things to behave again after those changes took most of today but it’s creeping toward feeling solid again.

I’m not 100% sure what I’m working on tomorrow. I still have a lot of tidy-up work to do, I need to look into how to add ‘hill climbing’ to the octree fill (more on that another day) and I need to make some server-side changes very soon.

Guess I’ll see how I feel in the morning.

For now have a wee video showing the fog of war responding to the door opening. I have to switch between DM and player here as attempting to open the door will try sending a message to the DM.. who is on the same machine and the UI code gets a bit confused :)

Seeya

Almost forgot this evening’s one so it’s gonna have to be quick. Today I worked on the import of the occlusion data from TaleWeaver I’ve got a couple of small issues left where Unity’s behavior mas left me a touch confused but no doubt I’m just being a dummy.

I have noticed a shortening of these dailys over the last few days but fear not, they’ll be getting a bit longer as things get exciting again :)

Peace

Good-evening folks! Today was spent getting used to the profile, finding out ‘deep-profile’ is useless, finding out that some parts are pretty fragile and then making a few speedups.

Mainly it has just be reducing the amount of info that needs to be written into the octrees for each zone. This is kind of avoiding the real issues though so we will need to get back to actually reducing the time things take, but that is for another day. The main thing to tackle was rewriting the code that find which parts of a tile are solid and which aren’t. This was previously hacked into TaleSpire itself and happened on load, but this is daft as it never changes so I have moved this to the tile modding tools.

I’m now going through all the existing assets and adding extra info to all of the floors and reexporting the assets with their new collision info. Tomorrow will basically be finishing that off and using this new data in TaleSpire, which should tale performance back to where it was. I will also serialize the octrees for file/load and syncing floors as it could be a pretty quick win.

Seeya

Today I got a bunch of thing fixed so the new fog of war is starting to behave itself. There is still a bunch to do so my 7 day estimate at the beginning of last week is looking dumber by the day, however it’s still a good day.

I can load boards again, walk my character around and see that the systems are communicating properly. The next things on the todo are (in no particular order):

• Make tile deletion work with the fog of war
• Improve performance of adding tiles (see below)
• Only add occluders (a special kind of tile) to the fog of war zones
• Only update tile visibility info for zones that are on screen or nearby
• serialize the fog of war (maybe)

Right now, when loading boards there is an expected but noticeable lag. I know it’s related to the fog of war system but I need to know which parts are causing the issue. I’m definitely doing that before serializing the fog of war data as that would just mask any issues.

Right, gotta go get ready for a stream

Seeya