The new arena, colisee, has a proper visualizer api: https://github.com/siggame/colisee-visapi/

When the connection is set to "Arena", it should hit-up that API and play back a gamelog from there.

Currently the simple arena implementation is done here:

Ideally this would probably be moved to a separate function, complete with JSDoc comments, and updated to work with the new visapi.

Currently staying on Font Awesome v4.7 to avoid the paid headaches in v5.

However it should move to an alternative package that regularly gets updates, and ideally has TypeScript definitions.

Options:

• Line Awesome
• Feather Icons
• Jam Icons
• Material design icons

One of the most expensive operations is when the game state changes, because we have to merge delta state(s), then tell the BaseGameObject instances that they have updated so they can update sprites and such.

This leads to micro stuttering between frames when a merge occurs, and the UI locks up.

Instead, we should use web workers to throw that expensive load to another thread, so the UI does not stutter.

If you go to arena mode, give it a valid url, and make sure presentation mode remains checked, it will not enter presentation mode upon refresh.

This is because the &presentation url parameter does not get set. This appears to be because the FileTab.presentationInput.value is always false, regardless if it is checked.

This is probably a simple fix, but I don't have time at the moment to investigate it.

During Human Playable Mode, if the first move is the opponent disconnecting it stays paused. Instead, it need to play to the end to show the game has ended.

Currently the title of the page is static, Viseur

It would be cool to update the title. Say for example we were playing back the gamelog 2017.03.23.12.29.15.006-Chess-1

Once parsed, we know the gamelog will be

game: Chess
session: 1
date: 2017.03.23.12.29.15.006

So, we can then make the title Viseur - Chess - 1 - <formatted date>

That way if you have multiple gamelogs open, you can easily tell what they are for.

An expansion on this idea would be to update the favicon as well depending on game. But that is outside the scope of this issue.

Mostly a toy feature I want an excuse to test out:

https://developers.google.com/web/fundamentals/app-install-banners/

The file input for local gamelogs, while present, is not hooked up. It will need to read the local file.

For now assume the file is JSON, and not gzipped json. The endpoint for users to save gamelogs should be through Viseur, and so we should never let them save gzipped json in the first place.

The visualizer will randomly pause, and must be manually unpaused by clicking the pause/unpause button.

From src/viseur/time-manager.ts

        this.viseur.gui.events.playbackSlide.on((value) => {
            const index = Math.floor(value);
            const dt = value - index;
            const current = this.getCurrentTime();
            if (Math.abs(value - current.index - current.dt) > 0.10) {
                // the change in time was too great, they probably clicked far away
                this.pause(index, dt);
            }
        });

While the intent of this code is to pause the visualizer when the user clicks on the slider, it seems to also trigger randomly because the slider is not always in sync with the timer.

I'm not sure of the reason for the desynchronization, the pauses are always at different deltas even for the same gamelog, so I'm inclined to believe there is some sort of race condition.

A proper fix would distinguish human-generated clicks on the slider from programmatic changes to the slider's value, however the necessary information to distinguish (event.isTrusted) does not seem to be piped through.

An easier fix would be to replace
this.pause(index, dt);
with
this.setTime(index, dt);
So that changes to the slider never cause a pause. If the user wants to jump to a specific point while paused, they can simply pause, and then click.

Spectator mode is essentially playing parsing a gamelog that is streamed to you as it is created.

Playback by the user is disabled, instead they... well... spectate. When a delta comes in, animate it. Then wait for the next delta.

Most of this involves actually communicating to Cerveau and interpreting its I/O. Thankfully, Cerveau already supports WebSockets as an IO endpoint.

In Chess during human playable mode right click, and you might get the following error:

Uncaught TypeError: Cannot read property 'file' of null(…)

Should this be Math.max?

    last: function(offset) {
        offset = Max.max(Math.abs(offset || 0), this.length);
        return this[this.length - 1 - offset];
    },

Including a dockerfile would make it easy for us to have automated docker builds directly out of Docker Hub. This would be really beneficial if we start running everything on Google's Container Engine.

I got lazy and did not include proper JSDoc styled documentation in all source code. Need to do that.

Also include instructions on running JSDoc to generate documentation.

the progress can go over the summed causing at the end, the bar to overtake the allotted area. Happens if a game can increment passed the win condition.

It happens in chess, but probably all games for streaming gamelogs.

1. Connect two chess human clients.
2. Have white (the first player) make a move.
3. white player will render correctly
4. black player will not

It appears as if the second player animates the delta "backwards", where the currentState and nextState are reversed, so the move is played back in reverse and it sits in the start position instead of the end.

Any subsequent deltas to that piece are correct though. So it's something with initiation.

This requires #2 to be done first, as essentially you now send run commands to the server and spectate the results. New UI features will need to be added.

This is essentially a Chess only features, but should be made generic enough that if devs want a future MegaMinerAI to be human playable they can add that feature to the game plugin.

If the name has a ' in it, it displays as '.

When the visualizer is in full screen, the Info Pane, while hidden, is still taking up space.

This should not be the case. It's probably a renderer math bug where it is taking into account the infopane's size when it is hidden.

lets human playable characters choose the promotion type

Babel 7 and TypeScript 3 are out. They should be used.

In addition with the Cerveau V2 TypeScript re-write the Creer based types can support much more robust type features.

Gamelogs are delta by delta, so playback of delta by delta was naturally the simplest, and correctly displays how the game actually played out.

However, often for turn based games most of what happens in 1 delta will not affect the other game objects, so delta by delta can feel boring and slow.

Turn by Turn would be an optional playback mode in games that are turn based. In these, we "flatten" all deltas to be animated over the course of 1 "turn".

This would naturally be tricky. As during 1 turn some unit A could have 100 different Deltas, while others may just have 1 Deltas. We'd then have to figure out how to animate units at different rate, and then there could be more complex situations like determining how many times exactly is was effected?

This will be exceptionally tricky, if not impossible.

Another way, that looses game information would be to just flatten deltas based on turns. So, if you have 100 deltas per turn, you would just take the delta 0 for the start of the turn, and delta 100 for the end of the turn. Deltas 1, 2, ..., 99 are dropped out.

Again, this is lossy compression, and less desirable. However, it may be the only realistic solution.

In the structure file for the viseur for catastrophe, the setup for what sprite to select to display is structured wrong. The constructor is a collection of ifs but the last statement is an else. The actual structure should be if, else if, else if, else.
Location
at lines: 67-85

Backport MegaMinerAI17: Spiders and/or MegaMinerAI 16: Anarchy, for more example for future devs.

When it is the current player's turn in human playable mode, the other player will be highlighted.

When playing as a human client, if run out of time a fatal message is sent from the server.

The error message currently is confusing due to a lack of a string.format call. However fixing this causes the error to disappear after about a second, which is less useful.

In addition, when a game ends (or you timeout). the ticker should stop ticking. It might be good to update the player pane that they timedout as well.

As in siggame/Chesser show somewhere on the GUI should show the SAN moves.

Not sure where...

Another solution would be to allow spectator mode to replay moves so they can roll back the time.

Currently, all deltas are "played" even if there is no animation width the delta. This greatly slows down the rate of playback, particularly if a client generates many errors.

These deltas should never update relevant game structures because if an animation isn't played generally only back-end stuff will be updated. It may still be better to supply an option to play them / only play them if an option is selected and the inspect tab is open.

Arena mode should endlessly play gamelogs from the Arena.

1. Page loads, everything initializes
2. Go to some remote arena endpoint, get a gamelog
3. Play it back, disable playback controls
4. When done wait a few seconds, then refresh the browser (which then goes back to 1, and would grab any updates to the visualizer on refresh).

This will be easy, but requires the arena to have the endpoint defined or made.

Sometimes error modals do not mean the whole thing is borked. Allow those modals to be dismissed (closed)

Deselecting a Tile doesn't allow for reselecting right after.
Example: click 'c4' three times, the tiles should be highlighted but is not.

Have a way (preferably a really easy way, competitors are lazy) for viewers to vote on the 'excitingness/interestingness' of a game. Send that data somewhere where the arena can get at it.

Once the game specific code is mature, convert them to Creer templates so that new games can be automatically added along with the game server & clients.

The comment for this line says that it is for Anarchy for every game.

A delta merge error can occur given the following sequence of events:

• a new game object is created
• it is added as references in multiple locations in a game structure
• depending on the order keys are iterated in the delta, the game object may not be known to be new, and thus set to undefined till seen

Need to create all new unseen game obejcts before complete delta merge.
Thanks to @MasterCash for bringing to my attention.

Currently the Inspect tab is by far the largest performance hog. Profiles done in Chrome show it taking up ~83% of the time used "rendering" the game just updating the DOM from the inspect tab's code.

This is not too surprising, the inspect tree represents the entire game structure as a tree of DOM elements, and large games can have a tree with a branching factor in the tens of thousands.

The easiest solution would be to just drop the inspect tree entirely. But I don't think that is worth it.

Instead we should turn to some technique like virtualization, where DOM elements not being rendered are not even added to the document. it's a bit hackish, but it can have HUGE speedups. We could also employ types of lazy loading, where if a node is not expanded don't even build it's DOM elements until (if) the user expands them.

This is not a trivial rewrite, but it will be needed to keep Viseur performant.

Currently, only the human player's time ticks when it is there turn.

In addition to fixing #12 this should be fixed as well, though it is a separate issue, hence this.