I did a version previously with a seeded deterministic RNG though I think the animations will be sufficient to cover up the majority of the latency. If it proves to be an issue during testing then I’ll revisit it and re-implement the RNG using a unique seed (probably the unix time from when the game was created salted with some other hidden value) and an index based on the actions. I guess as long as the salt stays hidden, there’d be no easy way for people to ‘crack’ the RNG and predict the outcome of the game.

How about this for a bit of a creative solution: a random seed across all parties with a pseudo random number generator for combat, growth, and spell generation?

So this would remove the latency issue for the only person who would notice it, i.e. the local user.

Yeah I recall what I assume to be a bug in that disengaged units can move-attack and then attack again once the game registers them as engaged. Whether or not it was intended I think it’s probably worth reproducing (although perhaps this is one of the less desirable bugs which may be configurable during pregame?)

Regarding latency and movement, currently the client awaits a response from the server before a move is performed, which will inevitably introduce a delay, however this will only be during testing as once all of the bugs and inconsistencies are worked out between client and server, the client should be able to be nearly 100% confident that a move can go ahead without needing to check it first, so the move will be performed in tandem with the move being sent to the server – if there’s inconsistency between the two then some error correction will have to take place – but if there’s any inconsistency then it can only really arise from a bug.

Also, in the case of non-flying units with >1 movement, the API ‘move’ endpoint accepts either a single co-ordinate or an array of co-ordinates. The client will be responsible for how those co-ordinates are generated (either individual moves a la original Chaos or a pathfinding system to interpolate the positions between start and end) and the server will then check the move to determine if it’s valid. In the alpha, movement will be done manually, and the client will send the whole move as an array of positions once the unit has expended its movement allowance or become engaged to another unit.

Ahh, I think I may have mis-read the original post, I thought there was a problem with tracking which moves had been ‘capped’, rather than disconnecting the move-attack-ranged-attack cycle.

Another gotcha I experienced with the movement cycle is when attempting to fly onto an enemy, thereby attacking, when already situated right next to the enemy (this assumes of course that the creature you’re moving isn’t engaged). This action, if unsuccessful would take up both the movement and attack phase, whereas my original assumption is that event though the movement fails I would still be able to initiate combat on the adjacent square.

I found myself poking values into a Spectrum snapshot to try out a lot of this stuff, just to make sure I was getting it right, which even with a disassembly is incredibly difficult.

I wondered if you’re chunking moves together, because my concern with a RESTful service is the latency issue. If you’re waiting on the server to receive a POST request each time you’re moving a non-flying creature, then it may take some time?

I really wish you’d taken your version further Andy – what I saw of it was absolutely fantastic!

I’ve opted for the ‘realtime’ route because I want to keep a sense that someone at the other end is moving the pieces around as you watch – it’s important for me that in a turn-based game, the pace and drama of the game is represented as closely as possible to what it’s like to play a tense hot-seat game. “Uh oh, he’s moving his vampire now…”

What I’ve implemented is pretty much as you’ve described it – the board state maintains the current status of each unit (moved, attacked and rangedAttacked each being flags that start each new turn as false) and each is represented by a different action (‘moved’, ‘attacked’ and ‘rangedattacked’) to place them chronologically and to describe the details (i.e. where the unit moved, who it attacked etc).

On the issue of not being able to track combat moves after a disconnect, I had the exact same problem, but my work-around was different as I was transmitting the entire spell-selection/cast/move-list to the client, instead of the current state of the board.

The server should know if it hasn’t received an instruction to close the move-combat turn (creatures/wizards/shadow-wood turns with no rival neighbours should be automatically closed), so surely all is required, when a reconnect occurs, is to transmit some meta-information on the board state instructing the client on which pieces still require their move turn completing?

Apologies if this is confusing, or if I’ve mis-read the original problem, but I’d be happy to discuss it in further detail.