About custom editor concepts

[WaterKnight]

I wonder how a good editor for wc3 could look like. The examples of most games in general sort it after physical layers (doodads, units, triggers, sounds, etc.). However, my development of things gave me the idea that it could make sense to work in user-defined scopes.

That means that you could set up a scope Spells\Fireball and save all associated resources within it like script code, dummy missile unit or imports. This way, everything would be well sorted and the working materials are nearby. If you want to delete the Fireball ability, you can do it all at once without forgetting something related. Also, in script code, you can use shortened names to call local resources. Even if you do not want to nest everything, it can be put on a low-level basic scope and then it would be just like the technical layer approach. Still, scoping simplifies moving and corresponds object oriented concepts. Referencing other resources should be highlighted and automatically updated when the target resource changes name/path.

So this concept should work for integral stuff like code and objects since they hardly influence each other and can be merged in the end. The order does not matter or script dependencies can be explicitely done like in vJass libraries at the moment or you sort them during compilation.

What I would not include in this however are terrain and global values like player configuration or gameplay constants. First has to be seen as a whole while developing and it's rarely bound to single features. I do not speak of preplaced widgets here that might be interlinked to code. Those can be put inside the scopes too. But sheer landscape or a global pathing map are less additive. Well okay, it can be done like in Photoshop or Gimp or Farcry but then we need a priority order and that may be done in a separate structure.

After the information has been gathered and unified, upon saving are they redirected to different tools the user would like. Often enough there is need for macroed objects like the method described here makes use of. Since those generated stuff is no explicit user input, it should not show up in the editor, which is why the transformed data should not replace it. Instead, there should be a separate working space the tools modify and the editor finalizes this data to create the playable map file. This is better than to transform the ending-reduced data and it ensures the right format/can give hints.

Generally, I asked myself what would be best to store the development file as and concluded that the interface could run with the normal w3m/w3x files but the dev information is stored inside another file with the same name/other extension in the same folder. This has the advantage that the user would get a playable file everytime without an extra finalization method and would not have to differ between them. Only when the map is moved you need to move the associated dev file along but this is easy to see with the same name. Storing the information directly within the map file as an import would not be senceful because the file size would explode and you do not want to accidentally distribute your dev data via BNet.

The development file is another file but for simplicity, everytime you save it, it builds the output playable file. There could be an import functionality that reads the data of a playable file to just have it all in an unsorted way but maybe this idea should be neglected in order to boost protection of foreign maps.

edit: More ideas:

As you browse through the objects in the treeView, an object inspector will reveal its properties like you know from normal object editor on a right side. But you can pull this window away from the treeView in order to isolate it. When you select another object now, the old window won't be replaced but create another window next to the treeView again instead. This enables editing multiple objects at the same time, so you do not have to switch everytime and search them in the list.

There are object types like units or abilities Wc3 has their idea of which properties they contain. Often enough you do not work with all of those fields though because some are unused in your project or you require additional attributes. That's why it seems to make sense to be able to alter the object definitions. The compiler is open-source or you can transform the data before in order to determine the final wc3 values from yours. You may even set up wholly new objects in order to differentiate between normal units and dummies for example.

 

[WaterKnight]

You could even derive object types from another one. In the normal editor, you can base your stuff off original data. Here you might have a whole hierarchy similar to in programming languages.

Example:

First, you write an abstract type "ability" with all possible fields and default values. Then, you extend it by "channelBased", getting the properties of "ability" presented but it can alter the values like setting abilCode to ANcl and adding new fields "targetType", "channelTime", "displayAreaRange" etc., special features of channel abilities. The third level contains a channelBased ability called "Fireball" with a lot of specific data. Finally, "Greater Fireball" is an upgraded version of "Fireball", updating only some of its values like damage and area of effect.

The advantage is that you do not have to define the fields and what they influence anew everytime you create a more specific structure. Furthermore, it allows default values. When you want to create variants of other objects, other levels of unit summons for example, you only need to state your modifications.

 

[Dr Super Good]

The idea is you make maps out of instances of resources. A particular resource, Systems, are used to represent a fusion between JASS and Object editor data. System instnaces provide you something fully editable from a single window like the object editor that can cross between many triggers and objects. To further increase the engines power you can define child instances of existng parent instances meaning that a change at the parent level can propogate down to children unless the child specificly overwrites the value. Global values may affect all instances of a System or many systems and are identified differently for that reason.

The power of the resources comes from the way they are managed. All resources and instances are located on a cloud that your editor can stream on demand. This means that it would be possible to use instances defined for other maps in your own map. A further feature would be that changes made to the underlying instance by another person for their map can cascade to your map. An example would be having the actual DotA heroes with actual balance imported into your map as simply as choosing them.

Obviously Instances can link other Instances. A Hero Instance might link many Ability Instances to create a single transferable object.

The main advantage this brings is it allows abilites to be designed to scale. Currently most abilities will require the creation of new parallel structures to hold their data only sharing the underlying library systems used. Using this you could create a generic ability engine and the System compiler could feed in specific instance data into the engine so that when the map runs all abilities work as expected and more efficiently.

As there is no longer a direct concept of triggers anymore, all script is compiled from a more abstract form. This allows it to be produced pre-optimized.

As everything is kept on the cloud, the need for backups would probably not exist and you would have subversion services that could allow you to roll back or view changes.

 

[WaterKnight]

The idea is you make maps out of instances of resources. A particular resource, Systems, are used to represent a fusion between JASS and Object editor data. System instnaces provide you something fully editable from a single window like the object editor that can cross between many triggers and objects.

A package, yeah, importing them would not get into conflict with existing names because it may and should open up a new scope. I am wondering how imported packages should be handled though. Are they primarily placed in a special "outsourced" folder? Public packages have to be able to reference each other, which is why you are either not allowed to change the path when you import them or they contain a global path/unique id or all links are updated to refer to the new path.

To further increase the engines power you can define child instances of existng parent instances meaning that a change at the parent level can propogate down to children unless the child specificly overwrites the value. Global values may affect all instances of a System or many systems and are identified differently for that reason.

Which global values might that be?

The power of the resources comes from the way they are managed. All resources and instances are located on a cloud that your editor can stream on demand. This means that it would be possible to use instances defined for other maps in your own map. A further feature would be that changes made to the underlying instance by another person for their map can cascade to your map. An example would be having the actual DotA heroes with actual balance imported into your map as simply as choosing them.

Custom data should not be uploaded unless you specifically state so. We do not want to empower stealing others' work. Of course, downloading systems/packages from a public hub sounds benefitting.

Obviously Instances can link other Instances. A Hero Instance might link many Ability Instances to create a single transferable object.

I think it might be good to list up all the required resources above the object/scope inspector, so the user can view them at a glance and replace long link names by a local abbreviation. Would be good for readability.

 

[Dr Super Good]

A package, yeah, importing them would not get into conflict with existing names because it may and should open up a new scope. I am wondering how imported packages should be handled though. Are they primarily placed in a special "outsourced" folder? Public packages have to be able to reference each other, which is why you are either not allowed to change the path when you import them or they contain a global path/unique id or all links are updated to refer to the new path.

Obviously everything uses a unique identifyer. The cloud server handles that mostly to make sure there are no collisions.

Which global values might that be?

Update Period is an example. It might be shared with many Systems that use missiles.

Custom data should not be uploaded unless you specifically state so. We do not want to empower stealing others' work. Of course, downloading systems/packages from a public hub sounds benefitting.

You clearly do not understand the meaning of "cloud computing" do you? Obviously you can restrict the scope but the entire idea is to share stuff. Models for example could be imported at a touch of a button. Who cares if children try to steal stuff, as everything is on the cloud server people always know you are the actual author.

I think it might be good to list up all the required resources above the object/scope inspector, so the user can view them at a glance and replace long link names by a local abbreviation. Would be good for readability.

No need to even bother them with the requirements. Let the compilers handle those. Obviously there would be a view allowing you to see what resources are being used in your map and why (prequisit of...).

All systems expose consumables which are used when linking to a system. An example of a consumable is an interface which specifies offered functionality (a set of resources). Interfaces as a type may be defined with a default value (an implementation) so that singletons can be implicitly defined without the user having to choose one while still allowing the user to overwrite the default choice.

Terrain would be a different kind of resource. All maps have a basic field which they can then import terrain resources to generate. An example could be a fort and a city, both separate resources, used to make a full map. These resources can have filters applied to them such as rotation, scaling or even cropping.

The idea is to break maps appart into small units that can be easilly developed in parallel.

 

[WaterKnight]

Update Period is an example. It might be shared with many Systems that use missiles.

Those systems would still have to call the global by name directly. What is the difference to making them optionally require a package with constants you can configure? Simplicity in order to have the few globals combined in a structure?

You clearly do not understand the meaning of "cloud computing" do you? Obviously you can restrict the scope but the entire idea is to share stuff. Models for example could be imported at a touch of a button. Who cares if children try to steal stuff, as everything is on the cloud server people always know you are the actual author.

You have spoken of extracting information from DotA and other people. Even if you restrict it, the data can be seized by who tries hard enough. Knowing who is the actual author is only one aspect. On a lesser note, I do not think it's a serious business but uploading any private information should be made visible to the user and not mandatory.

No need to even bother them with the requirements. Let the compilers handle those. Obviously there would be a view allowing you to see what resources are being used in your map and why (prequisit of...).

? I meant when you edit an object "A" and want to reference like 10 fields of another object "ObjectWithASuperLongNameInASuperLongAndNestedScope", printing this name everywhere would kill the sight. So the user might optionally select it once in the header and assign a smaller identifier for use within the object, or scope. But yeah, I guess it would be enough to display the object name only without scope or auto-renaming, abbreviation with "..." etc., only distinguish collisions. You can see the long path if you hover with the mouse over the reference.

All systems expose consumables which are used when linking to a system. An example of a consumable is an interface which specifies offered functionality (a set of resources). Interfaces as a type may be defined with a default value (an implementation) so that singletons can be implicitly defined without the user having to choose one while still allowing the user to overwrite the default choice.

So you mean the user should not ruin the imported system but have a separate sheet he/she can type modifications in. Guess systems should be locked by default.

 

[Dr Super Good]

Those systems would still have to call the global by name directly. What is the difference to making them optionally require a package with constants you can configure? Simplicity in order to have the few globals combined in a structure?

That is what it is, a System required by another system but with the globals forwarded in a separate section for you to edit. It is similar to gameplay constants except more convenient.

Also globals... structures... these are all JASS terms. Where did I mention JASS at all? It would use an abstracted script language that the engine can then compile better into optimized jass. An example would be the compiler using arrays if a system has multiple instances or multiple levels on an instance for the level progression of an ability but only using a constant if the system is set to 1 single instance with 1 level *(removing all level related code). This all would happen transparently from the player. Just like all the produced jass code would be pre-optimized for shortest variable and function names.

You have spoken of extracting information from DotA and other people. Even if you restrict it, the data can be seized by who tries hard enough. Knowing who is the actual author is only one aspect. On a lesser note, I do not think it's a serious business but uploading any private information should be made visible to the user and not mandatory.

Only if your security is comprimised. However the idea would be to share as much as possible as you could then easilly have 20 people working on a map at the same time.

No personal information is required, only a login system. It is not like we are dealing with things with any value so if a few accounts to the cloud service do get stolen it would not be a big deal (developers could handle it personally).

? I meant when you edit an object "A" and want to reference like 10 fields of another object "ObjectWithASuperLongNameInASuperLongAndNestedScope", printing this name everywhere would kill the sight. So the user might optionally select it once in the header and assign a smaller identifier for use within the object, or scope. But yeah, I guess it would be enough to display the object name only without scope or auto-renaming, abbreviation with "..." etc., only distinguish collisions. You can see the long path if you hover with the mouse over the reference.

Other systems could only interact with consumeables provided by a system. Refereincing could be done as simply as instance.consumable or system.consumeable. When scripting the language would support referincing object editor types and instances to get a field value in a similar way (type.field or instance.field) and the compiler would then generate the nescescary code. The exception to this might be compiler configuration systems which are more difficult to make (probably done in another language that is more suitable for compiler design) that are used to generate the native systems from the code to allow for native system substitution (eg handling instance field data in another way).

So you mean the user should not ruin the imported system but have a separate sheet he/she can type modifications in. Guess systems should be locked by default.

No. it was to allow higher level system substitution. For example, changing from Person A's missile system to Person B's missile system with nothing more than improting Person B's system. Person A's might be the default for missile systems and so used automaticly by everyone who wants to use a missile system (they just reference the static interface and can make the calls) but in certain situations Person B's might be faster, or add additional functionality not part of Person A's and this would allow you to do the change without any modification to using systems.

Obviously this would not work for compiler required systems (such as for object type instances) and that would need a separate compiler system to handle.



An example of what the compiler could do is prevent all local leaks. It would automaticly null locals as nescescary.

 

[WaterKnight]

Okay, the terrain thing is possible. Every placement you do is stored under the parent type (working as an expandable node) on default. You can select the placed objects in the map view by choosing what types of objects you want to select first. The pick of the instances is then transfered to the object editor and if you want to separate your terrained fortress from the rest, you can drag the data into an own scope. Add another option to make new tiles replace the old one on the same spot within the default scope or similar. You could also choose the current home directory you are in.

 

[WaterKnight]

By now, I think it would be better to just have a browser similar to the OS and maybe pack an archive file. You can display a tree view by path as well as list all files of a type at once. You dedicate tools to the different types and run them when accessing a file. This allows greatest flexibility and is kind of what I am currently doing but am using the OS.

You select a map as base for your operation because it may provide terrain or placements that are too difficult to realize in an own fashion. When opening the map through this program, the latest created slk data could be transfered to a dedicated WE in its directory to be able to use it.

And finally there is a button that starts the various tools to process all the sources of data. The editor only exposes every file and supports with functions to determine paths and builds the wc3 format at the target location/captures information for doing so.

The three major tasks to account for are script code, objects and imports. First needs a proper editor suited for the language, second is most practical with tables, third can be directly inserted into the supposed directory, dunno if you need a special handler for them.

 

[PurgeandFire]

Opening by request.

 

[WaterKnight]

I am currently extending wc3libs to cover most of the wc3 files used in map creation, also slk files like lightning bolts or ubersplats. This allows easier development of tools and scripts, even if the proposed workflow is not the ultimate solution.

The recently introduced postproc permits to apply compiling scripts in a relatively flexible fashion on a map file, which is practicable because a map project has not to be too specifically laid out to make use of this. So I am not searching for a full integrated solution but rather one that bestows power yet gets along with conventional methods.

postproc is missing persistent data. While it possesses reflective abilities and is therefore suited for... well, independent post processing, there is only so much for specifications Wc3/the World Editor assigns to a map, which is why there still need to be ways to create and structure source data. I think that for most kinds object table sheets analogue to the WE's object editor are appropriate.

Externalized data bases and editors hold the advantage that you can more flexibly work in parallel on multiple files. The below diagram portrays the workflow I have in mind.

On the left side, you can see all what defines the map, except the postproc instruction file but may be there as well.

The 'data' is created using 3rd party tools, like the object editor I told about above. The 'specs' may be too but those are basically type definitions and configuration scripts for the 'objectBuilder' or other tools. The 'source map' is a wc3 map that serves as base and may contain the data you do not want to present externalized.

All that information is organized in a project folder. A config file is used to announce the paths.

Since the specs may be rather complex and newbies do not know yet how to write the postproc file, ofc there should be templates.

In the compiling process, both the source map and the externalized data is forwarded to postproc/the instruction script. The 'objectBuilder' unifies all object-related tasks, meaning the object tables are converted to wc3 objects (units, items, lightning bolts, weather, ...), import referenced files and/or create map script code. The precise behavior is determined in 'specs'.

Since it's language-dependent, there has to be another tool or a finalizing script with the war3map.j because the generated code still has to be imported with whatever rules.

edit: @next post: fixed

 

[Gismo359]

Sounds cool but the image isnt working

 

[WaterKnight]

object editor

The aforementioned object buider progressed rather okay until now. But scripting all of the object data is not viable. Static data should be presented friendlier. After all, mapmaking for a game should have its fun parts. The big question is about usability. Presenting you with a raw sheet editor won't cut it and even if templates for type definitions are provided, there are still a lot of properties to set. When you create a new unit in the classic object editor for example, you won't set all the fields initially yourself either but rather base it off an existing one.

So I am currently pondering about design concepts for this object editor and can at least tell a few features that I think would bestow great power to casual mapmaking and hitech-maps alike by its additive nature.

Left top is the project explorer and I really mean a view on your file system as I still think it's good to have the objects separate and you can see other files like the .j there too, which enables fast access across your project. You can then basically right click the file and open it in your favorite editor. The LineEdit above is for filtering. The tree structure is an important mechanism I want to facilitate on, which allows for the feature layout. If you do not want to use it, you can still easily make a root level folder for each file type.

Now why not use the system explorer? Because this tool is to parallelize browsing and editing. In the left bottom corner shall be a list of the standard object data sorted by type.

I thought it would be good to make it a stacked widget because there are many types (the pic only shows the classical ones) and often you would rather stick to one type at a time in order to compare them among each other. So you click one of those buttons and get to the list for this object type. The fold button is if you do not need the lower part, instead want to maximize the project explorer but may as well be done via a splitter I guess.

Now when you select an object from the standard objects list, it would display a data table on the right side like shown above but it is not editable. At least not without copying it to a new file which will then be selected in the project explorer.

In contrast to that, opening an object file from the project explorer (file types that are associated with the object editor) change the main part into multiple (tabs) tables. Not sure how it should be split up but at least there should be the predefined fields (via predefined object types), one part for type customizations like if you want to give all units a new state "stamina" and a "dynamic" tab where you can assign special properties to individual objects like ability setups. So you basically extend/mutate the predefined object types. If you need custom ones, you can still do that by inventing new extensions (deposited in config files).

Another important aspect is that you may want to work on multiple files simultaneously. I think it would be good to have the option between opening the file either as another header tab in the same window like e.g. Notepad++ does and spawning a new window. However, one file should never have multiple interfaces in order to keep integrity and avoid messy situations.

To further boost accessability, this object editor could be started from within JNGP. It does not directly affect the World Editor object data, therefore it is independent. The actual conversion to wc3 data is done via a processing tool that may be started via postproc on map save. Another tool merges all the outputs with the information in your map. The exact translation scripts, which may of course be user-written, are part of the configs as well but that has nothing to do with the portrayed editor and there need to be templates for standard types, respectively most would be automatized with the meta slks anyway.

 

[Retera]

This tool sounds amazing, when does it go publicly available?

 

[WaterKnight]

Before implementation time is allocated, I want to be fairly sure about the design. Sometimes I still get a bright idea or discover problems. I would appreciate it if you there are some other perspectives voiced about what would boost usability while maintaining flexibility.

One thing I have forgotten to write in the post is tag replacement. Like in the WE object editor you can write <A000:dur1> and it references the field dur1 of the object A000 in that spot. The object builder currently supports that in the form of <path:field{variation}> where path can be an absolute, a relative path or a by a special "refName" property. The {variation} is optional and defaults to the referencing property's variation/level, respectively the max variation/level of what is referenced. Now it would be nice if the insertion of these tags has some support like in an excel sheet you can hold control and click the cell to create one or auto-completion. A more serious problem is persistence, maybe the references should be updated when you reorganize the objects in the project folder or instead of paths it should be fixed identifiers after all.

 

[WaterKnight]

About 3d view placements:

As said before, this is a feature the canon WE is still good for, to be able to work live on the map layout, getting an impression of the result. Now if we do not use the WE's features to define objects, terrain, weather etc., we won't be capable of placing them. One solution is to change the map data that the editor uses, another to set local files in the wc3 directory. But those require reloading the map/reloading the editor. I do not see any other option at the moment without majorly extending the hacks.

 

[WaterKnight]

The user handling for such a customized editor would be rather particular and insecure but the only true way besides modifying the WE itself. If JNGP had at least a hook for opening a map to react to it. I guess the best way would be to have one morphable editor and have the user open the map via os context menu, so the editor can be prepared before its launched. The downside is that you cannot work on maps in parallel.

 

[WaterKnight]

I have now begun to implement the object editor. The language is java. Part of the wc3libs from postproc therefore has to be rewritten in java, which I wanted to do anyway. JMPQ-v3 is used for mpq work. The objects are serialized in the standard xml format, so it's simple to edit it.

 

[Zwiebelchen]

What else would have to be done before this is finished after the OE part is completed?

I'd love to give it a try as soon as all the critical features are implemented.

 

[WaterKnight]

After the OE is done and the standard definitions are written down, I have to connect it to the objectBuilder postproc tool, which transforms the XML data to wc3 data. Then the jngp Plugin and maybe an updater.