Make it clear when a game has ended. Maybe put stats here.

The visualizer should be able to visualize turns as they become available (i.e. not after the game is entirely resolved). This is handy for debugging a bot, as it lets you see the current game state while you step through the bot logic.

"Ficheur" is already a Dutch bastard word (if it even exists), so we should definitely not use it in an English context. I propose "filer" as a replacements, which is a related translation. It's still vague, but somewhat less confusing.

Log format is a line separated json stream of states, but currently the visualizer accepts a json array of states.

• #8 Client
• #9 Visualizer
• #11 Ruleset

The superviser contains the bot driver 'logic'.

This module should couple the ruleset to the bot processes wrapped by #15 .
It is responsible for the flow of the game:

• call out to the ruleset to start a new turn
• communicate to the bots to get their inputs

In short, it glues everything together.

Change the path an expedition takes to another planet form a straight line to an elliptical orbit.
See: Homann transfer

Currently matches and their results are not logged to something persistent, preventing us from visualizing the game. This is the last bit of functionality the botdriver really needs for the MVP I think.

The simplest way to currently do this would be to log each gamestep completely, together with some metadata.

I have 2 proposals for the format:

{
  meta_x: x,
  meta_y: y,
  turns: [
    {turn_1}, {turn_2}, ...
  ]
}

{
  meta_x: x,
  meta_y: y
}\n
{turn_1}\n
{turn_2}\n
...

The seconds has the advantage of allowing us to do incremental parsing.

Replace the current expedition graphics with swarms of ships. The size of the swarm should be based on the strength of the expedition.

Create some fun and interesting maps for introduction day!

With Hohmann transfers in place, the visualizer is very fancy but not really clear.
It would help to trace a expeditions trajectory in a dotted line, and perhaps leaving a trace behind (coloured by owner, so that it is immediately clear who owns this fleet).

Currently, expeditions have no id's, because they don't need any from a bot or rules point of view, as there is no need for 'continuity' of one particular expedition. A step in the game is currently a valid begin state as well. This is not the case if we want to do fancy visualization though, as a visualizer would assume an expedition launched from some planet at some time, so that it can calculate the trajectory to it's destination, with each move being a transition from the previous state, instead of a brand new location.

The most important components (visualizer/botdriver/gamerules) have a minimal working version or are close. This signals a time to get all of this shit together, reassess in what state we are in, and lay out our needs for the future.

Things that need to happen (somewhat in order)

• Merge all (somewhat) finished branches and PR's. This includes @tl3ilaxu's visualizer things, @wschella's botdriver, @iasoon's gamerules, and bots by @timodw and @Str-Gen.
• Organize folders mainly per game, not per component. Includes JSON-Schema's, testbots, gamerules...
• Make things act nice together. Try to use a bot to play a game and visualize it. Clean out the kinks.
• Update documentation to reflect current state. Make it easy for coders to get things working.
• Decide how we want to go further with the project.
• Lay out new issue's and project boards to assist in giving an overview (for old and new coders) what can be improved.

Allow the camera zoom in and out of the map and allow for dragging and moving the map around. Just like your favorite RTS!

Use this:
https://github.com/d3/d3-zoom/blob/master/README.md#_zoom

Depends on:

• #30

When the player is "iepoev", this players owned planets should be jiggelypoevs.

Now that we should try to decide on an universal logger interface, it is important to think about the logging format that we want to support.
As usual, being more restrictive will give the framework more power, but being permissive is just, well, generally being nice.

The most important considerations, according to me™:

• Do we force a line-based format
• Do we force a JSON-based format
• Do we force having a record for each turn played

Yes, this one is quite essential.

The game rules module should:

• Keep track of the game state
• interpret player commands
• step the game state

Note that this module doesn't have to take any actions by itself, it will be driven by the 'supervisor' (#16).

For starters it is fine to silently ignore illegal moves and similar edge cases.

Create a simple map builder form the existing visualizer.

Depends on:

• #30
• #31

Currently, in all matches the map is randomly generated, but for various use-cases (tournaments, monitored play, ...) we want to manually select a map (or multiple) for play. Which map to play should be a config option, and in case none is present, one will generated randomly.

Color the background in the color of the player that owns nearby planets. This will make it easier to see what planets are owned by whom.

Make the visuals have one style so they fit together.

Implement a simple bot so that we can test the infrastructure.

Requirements:

• When given a game state on stdin, it outputs a valid command to stdout
  (preferably not an empty one, since that does not allow for much testing)

Since the bot is an external process, you can use any language you like, though our lives would probably be easiest when we picked a dynamic language.

Basic controls for the visualizer. Should at least have the following buttons:
Play
Pause
Speed controls
Hide controls

Would be nice to keep them small and minimalist. So the viewport can have more screen estate.

As discussed in #44 already, there are some options with associated costs and benefits in how we handle differential game steps in PlanetWars.

Some assessments:

• A planet changes with every incoming and outgoing expedition, as well as every automatic increase in ship count. This can change both the owner and the ship count
• An expedition changes every turn, but only in the turns remaining to destinations
• Players never change

Options:

• An object-scoped diff
• A property-scoped diff

In our MVP, there will only be a client, no server.

• #11 A Game
• #16: Supervisor
• #15: Communication with bot processes
• #9 : Visualizer
• #12: Get scratch bots working

Add basic transitions between game turns.

Create a transition that makes it clear when an planet is taken over by another player. (Maybe simply size up and down the planet)

Depends on:

• #28

See this doc.

I believe it would simplify bot implementation (especially blockly style bots) if we allowed multiple moves per turn.

Opinions?

The animations with the Homann transfers sometimes stutter. This has probably has something to with the turn timer resetting before the animation timer.

We might want to enforce a turn limit for games, and it's the gamerules responsibility to handle it, and act accordingly (although it is also in the interest of the botdriver).

This issue will function as an overview for all issues off this type, as each component-relation deserves it's own issue.

• Filer -> Data store
• Filer <-> ELO
• Game server -> Filer
• Game server <-> Matchmaker
• Game server <-> Rule set
• Game server <-> Bot driver
• Bot driver <-> Bot
• Arbiter <-> Rule set
• Client GUI <-> Arbiter
• Client GUI <-> Visualizer
• Client GUI <-> Bot driver
• Web server <- Data store
• Web server <-> Visualizer

Write bots in blockly!

We would like:

• A nice and friendly blockly dsl
• A runner for blockly code (connection between bot runner and blockly runtime)
• A sweet editor
• integration between editor and visualizer

See this file.

Implement example gamerules and extract a general interface.

• #13 Pick a game
• #14 Game state format
• #19 Implement a sample ruleset

Create logs of complete games.
A typical game log.
And a large game log for stress testing the visualizer.

Pick a 'test game' to implement. The game should be easy to write a bot for, but keep it challenging so that we don't get bored.

Proposal

Planet Wars with an added rule:

• Each player can only have one fleet in transit at any given moment.
  This rule greatly reduces the complexity of the game, yet does not alter its core principles.

Well, obvious reasons why.

Add a score board to the bottom of the page. So when games get hectic we can see what is happening.

The bot driver needs to communicate with a bot process.

We would need a rust wrapper of this process.
It should:

• start the bot process
• send the game state to the bot
• receive the bots instructions

Communication should happen over (bot process) stdin/stout, encoded using JSON.
(see #14 for JSON format)

For writing and parsing JSON in Rust, you can use Serde.

For now, we will ignore time-outs and other nasty errors.

Move the essentials of the visualizer to a separate file so it can be reused for other game types.

See this doc.

Implement a visualizer!

• #13 Pick a game
• #14 Game state format
• Actual visualizer

Some plumbing has to be done to join everything together and actually let people play a game at the press of a button.

Ideally, we would have 'stages', which lets your bot fight against progressively stronger opponents (or harder maps).
This way, we would have a nice intro-day minigame, which we can then follow op with an intro-week competition for new students.

Plug: Do we need a ranker for the competition, or do we organise a 'tournament day' on which we let the bots battle in single/double elimination style, shown on a large screen?

Make a viewbox that spans the entire browser screen and contains the entire svg.

Given the game decided in #13, write a JSON Schema for describing game states and bot commands.

Schemas should go here.

See:

• #1 Architecture Diagram
• #2 Component functionality
• #3 Introduction Day MVP
• #4 Platform features
• #5 Component interactions

When the player is "relix" the players ships should be relix rockets.

Welcome to MOZAIC!

We already did a lot of thinking and wrote a lot of documentation, but ain't nobody got time for that! I made you a quick TL;DR instead.

So, we're writing a programming game! The objective is to write the cleverest bot for some game (think chess or checkers). Of course, to determine which bot is best, we need some infrastructure to run the game. That's what MOZAIC is for!

To get this party started, we'll need:

• A game
  • We'll be playing Planet Wars.
• Bots
  • External processes that communicate with the game server.
  • Communicate over JSON streams (we'll need a schema: #14)
  • We'll need a test bot for testing: #18
• A game server to communicate with, which has
  • An implementation of the game rules (#19)
  • A component that wraps bot IO (#15)
  • A 'supervisor', which glues these components together and drives the game. (#16)

We're tracking our progess here.

If you have any questions, need help or emotional support, be sure to ask myself (loser with manbun) or @wschella (tall dude with luscious locks). We're here to help!