Today has been spent in a test and fix loop. Every now an again I find something that I had missed or put off is actually required and then I have to push some changes server side. I’m fairly happy with that process so I’ll probably write a post on it sometime.

Tomorrow I’ll be carrying on with the same as today. I got some error to do with Photon IDs when spawning the unique creatures so I’ll start with that. Then it’ll be hooking up the calls to update server side info on the unique creatures.

Seeya tomorrow

Evening all, another small update. I’ve continued work on the syncing of unique creatures which are creatures that can move between boards and who’s stats, hp, inventory, etc are stored on the campaign (player controlled characters are the main example).

Tomorrow will be spent testing what I have so far and trying to find where it can break down, hopefully Thursday will then be spent cleaning it up. As such it’s going to be a couple more days with short dailys as there is very little to tell. It’s just small iterations and plenty of thinking :)

Until next time, Peace

Hi again, today has been spent hammering away at more sync code. Campaigns and boards seem to be playing alright and we ‘unique creature’ stuff is starting to take shape too.

Hmm it’s a bit of a short daily but the rest of the work has mainly been tweaks and fixes, so yup that’s all for now.

Well today was a major pain in the ass. It started ok, I was exposing the recent changes to the api but it all went south when I got to syncing board data. Up until I had been lazy and had been saving the boards in the database as a binary blob, not good practice I know but it let us get moving quickly. Now of course we need a better path and so it was time to do something, there were a couple of choices that seemed obvious.

Sync board zones to database

This one is still keeping binary data in the db but we sync individual zones. This is cool as we can then pull data on demand which gets us in the direction of large board support. The issue though is that we don’t need that feature for the alpha and it’s a bit of an unknown what extra code we will need on the client side.

I don’t imagine it would be hard, but that never stopped problems turning out to be a nightmare before :)

Seriously though, given how tight it’s going to be to get the alpha out as it is we don’t need more unknowns.

Sync the whole board to S3

This one was the clear winner from the client side, we use the same code we have but upload to amazon s3 instead. However the unknown here was on the server side. I’m still kind of a noob with s3 and the erlang library ecosystem often puts you in a place where you need to cobble some things together.

This time I was lucky in that the folks who make Chef have a library called mini_s3. However, as documentation is often thin of the ground, I needed to read parts of Chef to understand how to use it.. and this is where the noob thing caused issues.

Almost the biggest issue when trying to learn from code you don’t understand is that you have very poor metrics for separating things, it’s hard to derive what is intentional and what is a hack and terminology doesn’t yet give you the usual clues to help separate concepts. I went on a wild goose chase as I thought that Chef’s OrgID & Checksums were intrinsic to the s3 code so I was reading far back into the codebase trying to derive how they were getting the values so I could work out to do for our code.

Eventually, after a lot of shouting, I stumbled on my mistake and got things working. It’s painful as it was all for a single function, one that generates presigned urls to allow upload or download to a specific file on s3 for a limited period of time.

With that done I got back to what I though would get finished this morning, finishing exposing the new api functions and pushing the a version to staging.

That brings us to now. I need to do a little more testing (which I’ll do now) and then I’ll get back to hook this up to the engine.

Here’s to tomorrow

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