Topic: Several Features concerning Editor, Map-Design of large Maps and SearFaring
Adamant Topic Opener |
Posted at: 2013-08-29, 15:05
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 Needs. 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) Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too. Top Quote |
fk |
Posted at: 2013-08-29, 18:22
Two things that I recognized from my own experiences: "Don't open Editor with new Default-Map without Dialog" I couldn't agree more. "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 Needs." I would suggest a terrain fill command (maybe as well?). I expect that this will give the user better control while drawing. Top Quote |
wl-zocker |
Posted at: 2013-08-29, 19:44
If you have a large area whose terrain you want to change, you can push the left and then the right mouse button (order is important). When you move the mouse, the map moves, but at the same time, the terrain under your mouse pointer is changed. This is of course not a real solution, but a workaround. Please note that there are bug reports at Launchpad for the specific issues:
"Only few people know how much one has to know in order to know how little one knows." - Werner Heisenberg Top Quote |
Adamant Topic Opener |
Posted at: 2013-08-30, 17:05
In one ButReport somebody reported that there is coming up a new Feature that simplifies changing of Sections of Terrain that sounds to me like pressing Ctrl-A to select all Terrain and then apply Terrain-Type would offer an even more comfortable Way to select Terrain for whole Map. Other Points remain. The elementarry Point is that several Properties of an opened Map are rather static resp changing them require to start with another new Map from Scratch and changing the Editor to handle these Properties dynamically would reduce ROI from a more specific/covering PreSelection-Dialog to generate a new Map. The Topic Don't open Editor with new Default-Map without Dialog does not mean that a Default-Map shall get opened this or that Way (and did not call for the Opposite). I would like to see the Brush-Size-Tool as Item as in Brush-Tool-Menu at Level like Height-Tool and Height-Noise-Tool. I consider anyway also that Port-Feature-Brush-Tool as some Kind of Tool suited for the Tool-Pallete. The Player-Location-Dialog I would left there where it is as it's anyway a small special Data-Set like Description of Map etc. What I miss really for Player-Settings is a Jumb-to-Player-StartPosition-Button to easily find them when opened a foreign Map. I consider it to problematic when opened that Dialog to make it these Locations visible on Map that Navigation is risky to replace existing Start-Positions. I would prefer to move that Location by Drag&Drop resp remove one by Menu-Button to place freely without trailing the Icon over half Map but Inspection is very dangerous and I wonder IF I did replace a Player-StartPosition ... I can drop all Changes (IIRC Undo does not change Location) If I don't know exactly where it was. So I consider that Menu to be dangerous as I have to safe all unsafed Work or to lose it by droping whole Map and reload from previos SaveFile -- or perform any other BackUp-Methods like second Map, close map, load original Map to recover exact Position , load WorkingMap and correct modificated PlayerStartPositions. So there exist multiple reasons why Problems with Inspection of Player-Start-Positions occours and different Things could minimize the Risk with dealing it. EG a MiniMap-View for Starting-Positions would supply my most Needs for while Problems with dangerous Handling remain. Different Map-Designer may intend to deal different with that Issue but to me I would glady drop the blue Icon for Harbort to specify single Allowance to build there a Port but would like to enable a CheckBox to make a Locations which are suited to get Ports to be capable to get Ports. So I won't have to hunt for all Locations to change them from green to blue resp clear Forests due to I got unsure if the green BuildLocations got marked blue. I think there is a Problem with Approach to address the Problem. If there is a Tree the Terrain can't get any Building -- alright. But if we understand the Sign for Construction as planned Activiy without Need to enforce it immediately we could plug such a sign into deep Forest while wonder when Work on Construction can start. We could understand the Lumberer as some Kind of special Assistant which get Order to clear Site from Trees that ConstructionSite can start Building. This Matter could rather simply get solved by updated Lumberer-Code first searching for Trees inside Construction-Locations. The Construction could anyway like Trees or Plants add Attributes to Locations like clear_for_site or anything that the Lumberer can easily identify them with existing Code. I am not sure why Beach-Terrain is not suited for a Port and if Beach got transformed into Garss why the IIRC Barbarian Port-Construction transforms Grass back into Beach .. visually -- curious. I would aggree if several Terrains are not suited like Swamp than either no Sites can get build there or Attributes - more or less specific/generic like No-Port-Sutiability (NO_BLUE) No-Large-Site-Suitability (NO_GREEN_NOR_BLUE) etc would be more reasonable theeeeen selecting a single Type of Terrain to be able to. However, I did anyway not remind/identify the Property why that or not that Terrain is suitd for Port as inspected W-Confs Years ago. In the BZR-Editor I did identify Symbols which shall represent special Properties of Terrain like Suitability for Construction and RoadTraffic, Liquid, Toxic,. I did wonder several Minutes what that's Cross about but finally identified the East-WideLands-TrafficLight-Man-Symbol -- famous but missunderstood by Wikipedia:http://en.wikipedia.org/wiki/Ampelm%C3%A4nnchen Serious: I care only that I did need Minutes of wondering what it is - no Idea explaining what the Reason was .... edit now I doubt I did really identify it .. is it a Red TrafficLightMan?!? The Plain Matter is: I can identify the Symbols due to I know the Terrain and can do logical Combination but inverse understanding the Terrain-Properties by Symbols - I fail to. Eg I know that the Symbol on Beach explains you can't build there any Site but that Symbol itself ... what is it? Left Topic from additional Attribute(s) for Terrain to clear out Site-Terrain from several Kind of Things. Let's assume any Giant MushRooms grow there and Lumberer don't lumber MushRooms but Trees and ignore the MushRooms - SnowWhote have to come out and plug them or what ever. I mean that clear-out-Thing concerns to Terrain and not to actual Trees. If such a Tree got lumbered, another grows there without that Attribute Things get more wired. Attribute concerns to Terrain there. Result is, if BuilderIcons don't factor in Trees or other Removables they keep visible even if there are Trees and thus could get changed from green to blue or reverse. However, I wonder why a Player shall not be able to build a Harbort into the Mountains - should be possible and no Problem as long as no Ships try to enter it there. Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too. Top Quote |