It’s a little past midnight but who cares, it’s been a great day.

Jonny has got the basics of the new placement code working. It’s now much easier to move pieces under overhangs regardless of if they are on the same floor or not. He also got drag-select in so I will hook that up in a few days so we can delete/move multiple tiles.

I’ve been working on the game state and player handling code. It’s now much more reliable and a fair bit cleaner. This work makes sure that if ‘host’ (the client tasked with syncing to the server) leaves that the job is passed to another client.

I’ve also started work on supporting having the same user logged into multiple clients simultaneously. In the future this could allow us to provide additional tools that hook into the current play session.

It’s hard to stress how much nitty gritty stuff has been, if not implemented, at least properly speced out for the release. I’m stoked for the next 2 weeks of progress.

G’night folks.

Hi again folks,

I’m down at @jonnyree’s place right now for a couple of days hacking on TaleSpire and it’s been going great. We have been going through the features that will be in the alpha and making decisions of behaviors that, up to now, were a bit vague. That has unblocked a bunch of tickets so they are all on my todo list for the next couple of weeks (not that I have been short of work).

Currently I’m fixing some bugs by setting up some simple state machines for managing the current game mode and client state. This just makes some things more explicit and makes the transitions between the states very explicit.

Tomorrow I’ll switch from this onto the rewrite of the placement code. This is the bit that handles the behavior of picking up and moving pieces. Naturally it’s critical to nail the feeling here as it’s its your primary interaction with the game. It seems like you could just attach the piece like a pendulum and let physics drive the experience but nope :) Lot’s a pair programming will be on the cards.

Alright, that’s the lot for tonight.

Peace

Good evening! Today I got the multiplayer undo/redo code merged in, fixed some bugs related to NetworkIDs for objects and started planning the code to handle host migration.

Tomorrow’s task will be to finish of the aforementioned plan and get as much of it implemented as possible. The goal there is just making sure the game knows what to do when players with specific roles leave or join and how to migrate responsibilities as it happens.

On Wednesday I’m back visiting @jonnyree where we have a of tonne planning to do (especially around gameplay behaviors for the alpha) and we need to make a solid foundation for the new piece placement code. This is one area where the feel is super important so it’s best for us to pair up on that.

As every we’ll be keeping you posted as this progresses.

Seeya!

Today was spent chasing down smaller issues and, for features that need UI work, writing down behaviors which I don’t think we have defined well enough.

As an example for the latter we haven’t defined whether a player who does not have permission to GM can join a game without a GM. It might make sense as maybe the GM has said they’ll be there in 5 mins. It could be cool to let the player look around and re-familiarize themselves with the board, however there are also certain tasks that a player needs to have certain permissions to perform and that player may not have them. To be more specific some server calls require someone with GM rights.

The first task will be to define what behavior we think feels best and doesnt pose any risk to the integrity of the play session. Then we need to work out what technically needs doing and whether it will be feasible (along with everything else) to get done for the alpha.

Please don’t get to hung up on the example above though, it’s just and example and there are plenty more tickets to review :)

Today I also worked a little more on sync, making sure host migration worked properly. There are still some details to take care of there but it requires some of that planning mentioned above. I also am finally writing the undo/redo code for multiple simultaneous GMs that will be in the alpha. This is resulting in some changes to the serialization code which should help us down the line.

As the alpha rolls onward we will need to be able to make changes to the file format that the boards are stored in. To support this I’ve started stubbing out the format upgrade code. This will just handle the case where a newer version of the game is opening an older version of a board file. Simple but necessary stuff.

All in all it’s been an ok day. I’ll kick of tomorrow by finishing the undo/redo stuff and then dive into the next pile of tickets.

Until then,

Peace

Evening all!

Today was spent testing the ‘unique creature’ code across multiple clients. This went well and found a good few bugs. I rewrote the board sync as that was on the todo list for a while and started looking at other aspects on sync which need to be better.

The first one on my mind is making sure that each client knows whether their version of the board is more recent than the version on the server, it’s a simple problem but has a few subtleties to it. It’s not good enough to know that the server version is different as it is possible that you are building a board on your own (for a future session) and the power goes out. We would like to use the cached version of the level on restart and know that it can be pushed over the server version. A simple version id can handle this but I’d still like to muse a little longer on the potential downsides of this.

Another thing I need to consider is how scriptable assets handled with regard to sync, we obviously want to be timely about pushing the state of things like locked doors & chests to the server but with modding it will be possible to create assets who change state near constantly, how frequently do we really want to sync this? I’m not gonna spend too much time of this now as modding wont be exposed in the alpha and next year I’ll be adding support for huge boards which is going to require changes to sync anyway.

There are bunch of other little details but this will do for now,

Until tomorrow,

Peace

Evening folks, unique creatures seem to be syncing well now and I’m on a bit of a hunt to clean up a bunch of warnings that have been piling up for a while. This touches on one rather annoying aspect of Unity where, if a script has become disconnected from a prefab (due to a rename or something, it can’t tell you what the file used to be called so it’s damn hard to find out how to fix it. Bites when a bunch of stuff in unity is pretty great.

Anyhoo tomorrow I’ll introducing a second client and then will be doing more testing and fixes.

Thanks for stopping by!

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