PreView of mayor Points 1) Increase Brush-Diameter-Range up to 16, 20 or even 32. 2) Don't open Editor with new Default-Map without Dialog 2.0) Dialogs to specify Properties for new Map: 2.a) Dialog to select Terrain-Set called World for new Map 2.b) Dialog to select Default-Terrain for new Map 3) Feature to change Map-Geometry of loaded Maps (remove/insert Rows/Columns) 4) Additional Constraint/Option-Flag that new Maps are (always?) quadratic
I did start yet a new Map and stumbled another Time again over multiple Matters I consider to rather unnecessary/uncomfortable/annoying for Edit-Issues.
When I start Editor to wait for significant Time till Default-New-Map got loaded. I wait effectively always for something I don't want as I can't change basic Properties of existing Map like its Geometry or its Terrain-Set called World like GreenWorld etc.
I prefer regularly Freedom of Foo resp in this Context ITC Freedom of Map-Designer but now I suggest an additional Limitation for Maps which I consider to have small Impact to the needed/utilized Freedom of Map-Designers. I suggest to make Maps per Default quadratic. That means in Pseudo-Code Width=Height. Very Most Maps are more rather or even totally quadratic - IIRC Exceptions exist. I don't argue against past/existing Maps with different Properties but for new Maps which are quadratic by Default. Due to Freedom I don't argue against a Way to overdrive that Default (but don't like - that's no Argument) by Map-Designer. ROI for Designer (like me) is that Maps keep quadratic if Geometry get changed. Starting from Scratch with Width=Geometry=32 the Way to 512 is rather long. Next Point concerns to Geometry as well.
I miss a Way to change Geometry of existing Maps. The Designer can select Origin resp for Definition of Change he can select Row/Col R1,R2,C1,C2 as Section to remove from Map and thus the new Map gets cut from loaded Map. The reverse Way is useful or even more than the Cut-Feature and would help to extend existing Maps eg if intended to make it more quadratic (that's Favour of most Map-Designer visible by Avg of existing Maps and therefore a Change is surely more likely to go more quadratic than more linear).
If you consider Work with SpreadSheets you may find that proofed GUI-Approaches exist to change Geometry with related BackGround - adding/removing/changing Rows/Columns/Sections and we may not worry if Matter is to difficult to handle.
If the Geometry should eg from 32X32 get enlarged to 64x96 the Designer need just to specify a Point inside the Map where the Map get spliced vertical/horizontal and Rows/Cols get added.
With arriving SeaFaring-Extension the Need for Water will grow. If the Designer
want to make a Map with Shares of Water on Ground like used to from Earth he will
aim at ca. 75%(72%) Water and 25% (28%) Terrain. Starting with 100% GreenLand means
that he have to turn 75% of Map manually into Water. Starting with WaterWorld could
solve that Issue effectively but the immediate Problem is that there exist to few
Tools to change effectively larger Territories. I did start with Water-Brush Radius
5 Fields and feel that a Brush with Radius 8 or 16 would even better match my actual
So I suggest two Things: A Way to select Standard-Terrain from/for different World-Types (eg GreenLand with Mountain .. or something else like Water, not the Point). Another straight Approach is to select a File for Edit before launching the Editor resp to define by Default-Map-Saving as Template how the StartUp define the Properties for a new Map. Sure that both can be done by Map-Designers: saving Template-Maps and changing Source in C++ to add Features. Point is it does not exist in Package. And last but not least these Templates does not exist! I could now start creating them 512X512 for different Worlds and TerrainTypes but .. you may call me lazy but I won't. Then there remain the Tool-Polishing to increase Brush-Size-Range up to 16 or even 20 Fields Diameter as simplest Way to update ToolSet to deal with larger Map-Geometries. Assumed if Map is 512X512 and Brush quadratic 16X16 I would have to make 1024 Brush-Spots perfectly to change full Map into Ocean resp 3256 Spots minimum to get 75% Water. So I don't consider D=20 for Brushes to be oversized for such large Maps. Without Zoom of MainMap a Brush D=32 would AFAICS be larger than the visible MainMap on my Display - that's an Argument against but not a Reason - and with theoretical 364= 192 Brush-Touches minimum the 512X512-Map would get much more rational get changed into Map with about 75% Water. Generally I miss a Lot of specific Tools for Map-Design reso consider the existing Tool-Set as rather tight and cumbersome. The Editor is at the StartingPoint for Game-Content and could get relatively simple get extended to offer more Comfort/Features to the Map-Designers.
If is assume effective avg Brush-Diameter to be like Square-8 I have now to perform
about 3x1024 Clicks to brush 75% Ocean. That's the Origin of my present Motivation
to get 100% Ocean from Scratch. With that Ocean would 25%=1/4 Terrain remain to get
brushed to Land equivalent to a 256X256-Map which is rather close to Geometry of
ordinary large Maps (about 196x196) without large Shares of Water.
In that Sense 512X512 are not really giant but with reasonable much Water and thus well suited for SeaFaring.
In this Context I point to Need of Port-Ability-Default that Map-Designer don't have to change all suited Points from GREEN into BLUE to enable Ports for specific Positions but get able to solve it generally by enabling ALL_SUITED_GREEN_GET_BLUE=true.
The Point is not that the Designer can do it anyway different but that Task can get solved manually. Taking HexEditor would even enable capable Designer to write Data directly into compressed Archive-File to create/design intended Map total totally manually - but nobody would do it. Creating SeaFaring-Maps with 75% Water-Share and Terrain-Size comparable with 196X196-Maps point into Direction of Map-Geometry 512X512 and therefore are no theoretical distant MarginalCase but close to that Maps I consider the best resp which I play only. Below 160X160 I don't touch it. Other may prefer smaller but these large exist and I guess their Designer did not consider these Geometries to be oversized and I don't ask for drop Support for Design of smaller Maps but for reasonable Support for Design of larger Maps.
For special UseCase I can imagine a Map which is intended to get played just in a linear Section. That could get realized by different Approaches like Obstacles like Mountains or Ocean but Ocean gets penetrable by SeaFaring. Let's consider Balloon for AirFlight or UFO for FOO each of those Obstacles by SideEffects may get anyway overwhelmed. What misses is a Way to omit that Way directly even if the Map-Representation does not show why that is. Eg we have Forest and anywhere is Forest that can not get entered due to it's tooo wired. Some Story-Matter for Campaigns that entering that dangerous Forest is still impossible etc. I don't know what these String-Maps want to represent by that Geometry and we may accept that Author don't want Players to spread square due to any special Matters like expressed but I prefer to keep at quadratic Constraint-Approach and supply other Ways to reduce GamePlay to the Map instead supporting strange String-World-Geometries (Width=32 Height=512 .. perhaps a Torus?) we may doubt that these strange Properties resp resulting Behaviours of such odd Properties were aimed by the Author. The logical simplest Solution is an additional Attribute for restricted Area with LookAhead towards advanced Restriction-Ruling-Set like just if Unit got Key-Attribute 'did-defeat-power-foo' resp attributed Restrictions like RestrictionType_Foo for simplified Code-Handling according to RuleSet and/or Events etc ... some generic Stuff considering any/arbitrary future Enhancements even if a plain Restriction-Rule gets implemented. I don't argue for advanced Restriction-Rule-System here but about factoring in when decided to take plain Restrictions to simplify future Changes adding more additional Features. So there may be a single Type of Restriction-Flag but with generic Slots to add specific Rules and Attributes. Even if these Slots/Teks changes the Code-Structure would need lesser UpDate if they were generic factored in into Code-Structure. Straight is to make Slots generic and add a single specific Rule for Standard. Specific Rules may exist for Critters and Workers, Vehicles, (Ships are not really Workers I think resp would/should/could cached by a 3rd Rule) and these get added for those leaving Space for later customized Rules inside Campaigns. IIRC there exist Tutorial-Campaigns which use any Trigger-Stuff-Things if specific Terrain gets discovered with Ruins from lost Colonization. I don't know how that was realized but from Aspect of special Terrain-Behaviour that Matter concerns to Restrictions as another specific Terrain-Behaviour. Eg. a special Type of Pseudo-Restriction could trigger these Things if a Unit enter these Fields which could make these Discovery-Events more credible. Just to factor in into Consideration.
Resume: 1) Increase Brush-Diameter-Range up to 16, 20 or even 32. 2) Don't open Editor with new Default-Map without Dialog 2.0) Dialogs to specify Properties for new Map: 2.a) Dialog to select Terrain-Set called World for new Map 2.b) Dialog to select Default-Terrain for new Map 3) Feature to change Map-Geometry of loaded Maps (remove/insert Rows/Columns)