Working on modules with large maps it seems that it would often be convenient to be able to display different parts of the same map in separate windows Eg to allow access to information/reinforcement table on the map and places where action is required. At present you have to scroll backwards and forwards/use overview/zoom in and out. Which becomes a pain in very large maps.
I was thinking of implementing it for a particular module I’m working on by splitting the functionality of Map class into two classes: Map itself and MapView and allowing multiple MapViews to be active on a single Map.
Before I do this I wanted to check whether there was any work planned along these lines for 3.2 or later to avoid duplication of effort.
Working on modules with large maps it seems that it would often be
convenient to be able to display different parts of the same map in
separate windows Eg to allow access to information/reinforcement table
on the map and places where action is required. At present you have to
scroll backwards and forwards/use overview/zoom in and out. Which
becomes a pain in very large maps.
I was thinking of implementing it for a particular module I’m working on
by splitting the functionality of Map class into two classes: Map itself
and MapView and allowing multiple MapViews to be active on a single Map.
Before I do this I wanted to check whether there was any work planned
along these lines for 3.2 or later to avoid duplication of effort.
What you’re asking for will be easy to implement following completion of
the Model-View Separation project listed under 3.3:
If you try implementing this prior to that, it will be painful to do it
and the Model-View Separation project will just make your code obsolete
anyway.
The best thing you can do to help us get with your request is to help us
clear away the things which are occupying us right now—in particular,
sorting through all the bug reports against 3.1. If you’re a sufficiently
confident coder to consider tackling the multi-view problem you’re
describing above, then we could sure use your help. Interested?
Working on modules with large maps it seems that it would often be
convenient to be able to display different parts of the same map in
separate windows Eg to allow access to information/reinforcement table
on the map and places where action is required.
Wouldn’t it be simpler to just split off the information/reinforcement
table into a separate chart or map window, instead of keeping it on
the same map?
The combination of all of that onto a single sheet of paper is a space
and time saving device when playing on the table, where you have a
full view of everything. When changing media to Vassal, though, it
often makes more sense to have only the playing surface on the main
map and put the other elements into their own windows.
Very true but often the other elements have been placed in unused corners of the map and the naive player still expects to use them there and may not see your separate window for the purpose. Allowing this sort of facility would also make it easy to move a piece a long distance on the map which can take a lot of autoscrolling with a big game since when it is fully zoomed out you can pickup and drop pieces very easily. Another use of such views would be for a scenario in a game to only display a portion of the map by using a partial view rather than the default full view.
I’m not sure if separate windows would be the best approach for playability. An alternative would be for the main map window to be tabbed. Each tab would given a different view of the map (at different zooms). The default tabs would an overview of the whole map and any other views of the map the designer chooses. The player would get a detailed view of an area by clicking on the overview map which would create a new tab and open it centred on the hex clicked (right mouse would give a menu allowing zoom to be selected) and make the new tab active. The player could thus create tabs viewing different parts of the map. These tabs would be scrollable allowing them to be moved. If a player drags a piece to the tab of an inactive tab it will become the active tab and be displayed so the player could move pieces easily between tabs. This approach might give a more friendly interface.
But of course the functionality required in the engine would be the same. The split I envisage is not quite the same as the model-view split since I’m just think of allowing a map to multiple active views (or with the tabbed solution multiple views of which one is active at any one time) which means shuffling some of the code from Map to its View (currently an internal class) and some of the children of Map (eg Zoomer)
The layers can be seen as something like this (first pass):
Model Layer - maintains info on the boards, positions and contents of stacks etc. Allows these to be changed (from GUI, or logfile or server or module programming etc)
Mediation Layer - one way combines information with graphic images to draw map with a view and the other way convert GUI events (mouse ups and downs and drags) into changes to apply to the map
View Layer - this basically translates between view co-ordinates and map co-ordinates
A model layer could have multiple mediation layers (you could then restructure the system so that the model layer was held on the server if desired) and each mediation layer could have multiple view layers.
The view/meditation split is the easiest to implement and the one I’m proposing, whilst the mediation/model split is the model-view split in the 3.3 roadmap which is a bit more difficult to design (especially if you wanted the layers to possibly exist on separate machines - need methods like Image getAllPiecesInRectange(Rectangle aRect) or GamePiecegetAllPiecesInRectangle(Rectangle aRect) depending on where the user specific processing is done (hideable and maskable pieces etc). hmm might be quite heavy - probably need some caching system for piece images on the client)
Even without splitting the layers over servers there are decisions to make about which layer holds information such as whether a stack is expanded or not; where does the identity of the player and the side(s) he controls fit in.
I’m not sure if separate windows would be the best approach for
playability. An alternative would be for the main map window to be
tabbed. Each tab would given a different view of the map (at different
zooms). The default tabs would an overview of the whole map and any
other views of the map the designer chooses. The player would get a
detailed view of an area by clicking on the overview map which would
create a new tab and open it centred on the hex clicked (right mouse
would give a menu allowing zoom to be selected) and make the new tab
active. The player could thus create tabs viewing different parts of the
map. These tabs would be scrollable allowing them to be moved. If a
player drags a piece to the tab of an inactive tab it will become the
active tab and be displayed so the player could move pieces easily
between tabs. This approach might give a more friendly interface.
Tabs are already planned: See “Docking” under 3.3, same page.