== Overview ==
The normal 'design' and 'test' modes exist, but are different from most games in that the test mode allows jumping backwards/forwards in time (in a similar way to recorded games), and all the editor's features are still available while testing.

The reason is to blur the distinction between editing and testing, to allow much faster iteration. If you're playing a scenario and notice that a trigger has incorrect timing, or a river crossing is too narrow, or there aren't enough trees nearby, you can immediately fix it and then carry on playing with the updated map.

The implementation doesn't require many new features from the engine - it mainly relies on the same systems as recorded games, saved games, and synchronised network play, which will have to be implemented anyway.

It is a superset of the normal design/test cycle, so users are not forced to use the extra complexity if they don't want to.


== Details ==

The editor can be in one of two modes:

 * Design
 * Test, with two submodes:
  * Play - similar to the normal game
  * Edit - similar to the design mode


Data can be categorised as:

 * Static data - time-independent
  * Triggers
  * Players
  * Civ tech tree
  * Diplomacy
  * Playlist
  * Cinematics
  * Name, description, instructions, author, etc
 * Dynamic data - time-dependent. (Initial state is specified; future states are calculated deterministically)
  * Entities
  * Nonentities (may be deleted by building placement)
  * Terrain (may be autoflattened by building placement)
  * Lighting (may be changed by triggers, particularly for pretty cinematics)


The world has an ''initial state'', containing all the static data and the initial states of the dynamic data.

The world also has many ''dynamic states'' (each at a different time) and a continuous ''input recording''. The dynamic state at time 0 is solely based on the initial state. The dynamic state at time ''t''+''dt'' is calculated from the dynamic state at ''t'' followed by a deterministic simulation-update of length ''dt'' with the appropriate section of the input recording.

The dynamic state is equivalent to the data that is used when saving the game or when resyncing over the network - it must include JS state, GUI state, as well as all the static data and the current state of all dynamic data.

The input recording is equivalent to the data that is used for recorded games.

Any dynamic state can be calculated from the initial state, the current time, and the input recording up to that time; but that is probably not particularly fast, so the dynamic states are cached at occasional intervals (e.g. every few seconds) (compressed so that it uses a sensible amount of memory). The user can jump backwards and forwards (and the game will calculate from the nearest cached state), play (in the 'play video' sense, rather than 'play game'), fast-forward, etc.


When editing static data:
 * In design mode, things are easy.
 * In test-edit mode, changes will either:
  * be easy, e.g. when editing the scenario's instructions; or
  * invalidate all cached dynamic states, e.g. when editing a player's initial resources; or
  * invalidate cached dynamic states after a specific point, e.g. when editing the effects of a trigger but not editing its conditions (since it can't affect the simulation before it is first triggered).

When editing dynamic data:
 * In design mode, the initial state is edited, and things are easy.
 * In test-edit mode, the current and future dynamic states are invalidated.


When dynamic states are invalidated, it means they no longer correspond to `simulate(initial_state, t, input[0..t])`. To avoid disrupting the user unnecessarily, they will simply be marked (probably in red on the timeline), and no immediate action is required.

At any time, the user can:
 * delete all invalid states and restart the simulation from the last valid state, either automatically (using their original inputs) or manually (recording the inputs again).
 * mark the states as 'acceptable', if they wish to clear the warning without having to do any work.
 * mark a given state as 'acceptable' and delete all subsequent states, and resimulate them (as above).
 * ignore the warning.

(The difference between 'acceptable' and 'valid' is that the 'valid' states are known to exactly match the deterministic simulation, while 'acceptable' states probably don't but the user has stated that they don't care about the possible differences.)

The aim is to achieve a balance between correct simulation and user convenience - they will often not care that their new hill would have slightly affected all pathfinding since the beginning of the game, and will just want to carry on playing/editing the map. They would, however, care if they were convinced their map was fine when actually they had stuck a lava pit underneath the starting position of their army.


In test mode, the user can choose to play the game (in test-play mode), in which case they can make use of normal inputs; the game will be storing the input recording and valid dynamic states.

The input recording is exactly equivalent to recorded games and replays, and it would make sense to make it compatible - if someone is playing a scenario and finds a bug, and they have been recording the game, they can send it back to the scenario's designer, who can then open it directly in Atlas, fast-forward to the appropriate point, see the problem, rewind, make minor edits the scenario, then go into test-play mode and see if it's now fixed.