(Keep in mind I am copying and pasting this from a thread I created during beta, but from what I hear the editor has not changed much and I don't have a release copy yet. Feel free to let me know if something I've noted has been covered.)
GalaxyEdit's data editor interface should be rebuilt completely from the ground up in the image of previous editors. It's not that it's too complex, it's that its organized in the most haphazard and time-consuming manner possible. Even the most simple of tasks are drawn out to insane lengths by just trying to find basic elements.
The biggest gripe I have with the sc2 editor is the extremely disorganized and confusing manner in which the attributes for many of the menus are laid out.
In the above tileset editor, the name for the tileset should be on the top. Instead, since it's listing alphabetically, the name is in a very random location. http://img405.imageshack.us/img405/9047/ed5o.jpg
Far worse than this is the unit editor. The arrangements of values in this are completely random and cripple any hope of making an efficient, painless run through a new unit. I cannot possibly imagine making a large-scale project in this editor - wc3 was bad enough with several values, like Armor, requiring repeatedly scrolling through a big list to find.
The Unit Name and Unit Description fields are on opposing ends of the list and key values like health, shields and armor are separated by totally random and unrelated values.
Recommendations;
I feel that the data editor is in serious need of reworking layout-wise. With the editors the community created for Starcraft 1 having had their interfaces perfected over the course of many years of feedback it seems prudent to learn from our mistakes and our discoveries. While I would never expect an exact copy to be made the editors in question I feel that several important attributes of these editors need to be adopted in the Sc2 editor to help facilitate faster, easier, and more efficient production for users of all skill levels.
Attributes related to each other, like Vitals (Health, Shields, Armor - Cost, Tech Requirements, Build Time, ect.) should be grouped together for easy identification and access. The user should not have to scroll down a big list to find any of these attributes. Grouping and organizing these appropriately will go a very long way to helping new users break into the power of this editor as well as help advanced users produce their projects faster, more efficiently, and with less irritation.
Unnecessary dialogues like the above only serve to waste the user's time and instead annoy the user, especially when they are editing an exceptionally large amount of data at once.
In its current state the GUI editor for data is practically unusable. There is virtually no usage of horizontal space whatsoever.
Obscurity
It is clear that many of the help dialogues in the editor are simply not finished, and I do believe that there was going to be a documentation of some kind in the future. Regardless, I feel a lot of dialogues and entries in the data editor need to be clarified as to what they actually do.
I have no idea why the weapon cooldown is called Period, for example. It just seems natural to me that it would be called something that makes it easy and quick to identify. Additionally there are no classifications to ANY of these attributes, and thus not even the slightest bit of organization. Again, I think developers would need a considerable hand-holding process by other developers to become acquainted with the obscurity of the data editor and the confusing nature of its arrangement, while with many other games most individuals can jump in and make basic changes without much hand holding. Unfortunately, with sc2 even changing damage and cooldown values can be a bit confusing for first-timers, and these critical, basic things become no less time consuming to do as the user becomes experienced with the editor because of their scattered nature.
I understand that the editor is complex and powerful. When dealing with games like this I do not expect the editor to be easy or newbie-friendly. I have modded games like Supreme Commander and Homeworld 2 in which there are no editors, just half-assed user made tools that are horrendously inefficient and often extremely buggy. There are many features in sc2's editor that I thoroughly enjoy, and the ui's for water and lights are exceptional and straight to the point - I like them a lot. But the data editor itself feels very haphazard and not much thought was put into it.
My effort is to spread awareness of the need for having the interface improved in the nature of organization and ease of use. This will not "simplify" the editor, this will improve the editor for those already using it by accelerating their production times through intuitive layout and arrangement that presents the immense power of the editor to them in a way that makes editing the game enjoyable and timely. That is why so few large-scale projects were attempted with wc3.
Some things like the Game Attributes editor give me only minor clues as to what they are capable of doing, and no hope for understanding their capabilities without an extensive external documentation or potentially weeks if not months of simply doing random things until something happens.
Within Blizzard's opportunity is the capacity to fix Battle.net and, more importantly, make the editor all it can be. They need but put effort into it. The editor is best seen as a foundation right now, ready for supports and construction to create the tool developers will be able to use in the future to create custom content. The groundwork is laid out but it needs engineering and planning to begin building the real thing.
Actordata and Modeldata
The two most important aspects of custom units are those involving the graphics and the physical functions of the unit, being modeldata and actordata. These are two reasonably complicated files that, currently, are a complete and total pain in the ass to do even the most basic things with. This is in part because they are complex subjects and also in part because the interface for them compounds the complexity issue ten fold.
Luckily for us, and Blizzard, there's an easy way to get around this. The editor already contains a model viewer - this could easily be copied and modified into a real-time preview editor for actors and models, probably even Movers as well. By simulating game events with the viewer, the editor can provide a level of fine control previously only reserved for things like the RPGMaker series and Age of Wonders 2. This seems to be the natural course of evolution and it's a wonder few games have attempted this in the modern market. No, I know why - developers are lazy. But the hardest part is already out of the way for Blizzard.
Animation editing is a tricky business, but perhaps Blizzard might consider making a simple scripting language for actordata. Something like what they employed for the iscript in Starcraft 1.
(I was going to post some iscript code like I did with my original post but it seems that code tags don't work and the forum doesn't have spoiler tags, either... or they just aren't the same and I am too stupid to find them :( )
Making these two files accessible is key to improving the overall user experience in creating custom assets and applying them ingame. But if Blizzard truly does care about the editor they will go above and beyond to provide the means to really get into the thick of these files without having a clunky interface to complicate the process.
Key functions of the new graphical actor editor should be an easy way to determine new events with only 1-2 clicks. Being able to insert a preset event - such as a sound - without any typing or external dialogues. You don't need to dumb down an editor to make it easy to use and intuitive.
This editor is not very powerful, but it's very quick and easy to use, and gets you where you want to go quickly. This is what I'd like to see in sc2 - an organized, intuitive, and streamlined interface where functions are obvious and quick to learn.
The key to making an editor as powerful as the one necessary for Actordata but as easy to use as this one lays entirely in how you arrange and manage the interface, and how you present it to the end-user. Enormous clusters of unrelated options like what we see commonly throughout many editors, sc2's included, bombards new users with unknowns and overwhelms them, as well as making finding exactly what you want annoying and time-consuming for more advanced and experienced users. This plays back into the first part where I talk about tabs and categorization. Speaking of which, tabs were added in patch 13, though the organization remains non-existent. At least they're updating the editor! Hopefully they continue to improve it for many years and don't abandon it like they did wc3. This editor still has a very long ways to go to.
Although not as graceful as as the AoW2 editor, the RPGMaker XP animation editor for spell effects and the like is another good example of a functional and fairly clearly interface. It is not necessary to jump into an external dialogue for adding SFX files, though unlike AoW2 this editor doesn't support multiple animations per entry (aka not a unit editor).
Also worth showing is the RPGMaker XP monster editor, as another source of reference of a good, clean interface for editing units.
Doodads
Doodads need to have their own editor. Additionally, they need to have a way of telling the editor which doodads to randomize in the placement tool without having to copy all of their assets around and make new entries. I wanted to place trees without placing palm trees and then manually changing them but such is a pipedream without bending over backwards. I also had a fun time trying to find doodads until I discovered the actordata IS their editor... which seems a bit weird.
~
The terrain placement tool could bear to be more intuitive and water placement in general needs a significant amount of work. I'd recommend to look at something like the Titan Quest editor.
The circles in the placement tool tell you about the intensity of blending for stuff like hills and textures, as well as the tool telling you the relative position it is to lower ground and its current position. Additionally, note how water need not be placed in enormous, clunky squares and water height is not based on individual water types.
Other "minor" things that are ridiculous arbitrary limits and should be remedied asap;
- 8 texture limit
- 256x256 map size
- only 2 levels of cliff and 1 level of unpathable subcliff? Really? What happened to wc3?
Something I'd like to see but is a bit more complicated is for creep to be worked out of being hardcoded into terrain and instead worked into data in the form of abilities or somesuch. This renders making a second independent creep kind of insanely time-consuming and difficult if not impossible.
The game also is in dire need of an actual mod loader. Currently, the sc2 "mod" system is just the wc3 campaign system with a new name and is easier to use. The fact you have to make maps dependent on the "mod" completely excludes it from the definition of a mod. A mod completely changes the game and effects every map regardless of what the map says it loads from. In warcraft 3 and Brood War this entailed the use of Mpqdraft. In games like Sins of a Solar Empire and Supreme Commander, who natively support mods, you have a menu in-game that loads from either an archive or a directory. Sc2 will probably never have any mods unless support for it comes out due to Blizzard continually mixing up the definitions of maps/mods and sc2 monitoring RAM usage (aka you'll get banned for running mpqdraft).
Additionally, another key thing separating Blizzard's "mod" system from actual mods is the fact that their mod system is still arbitrarily limited by the absolutely insane restrictions of Battle.net 2.0. You can not make a mod with only 20 megs global of space. Not even close. Armageddon Onslaught, a gametype conversion for Brood War, is still 88 megs because it contains custom music, sounds, and graphics like all mods do. Any significant conversion in sc2 will easily outscale that because of the larger amount of texture data alone. But also because each unit will have more sound data than they did in brood war as well.
The solution is to not have Battle.net be responsible for transfers of mod archives. Mods can be externally downloaded like they always have been, loaded through the mod loader interface, and flag vanilla achievements as unable to be obtained, and exclude the ladder system from being accessed (it just desyncs and drops/crashes you anyway).
Currently you can just modify patch mpqs for modding but... again, this is not ideal and not "supported".
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
(Keep in mind I am copying and pasting this from a thread I created during beta, but from what I hear the editor has not changed much and I don't have a release copy yet. Feel free to let me know if something I've noted has been covered.)
GalaxyEdit's data editor interface should be rebuilt completely from the ground up in the image of previous editors. It's not that it's too complex, it's that its organized in the most haphazard and time-consuming manner possible. Even the most simple of tasks are drawn out to insane lengths by just trying to find basic elements.
The biggest gripe I have with the sc2 editor is the extremely disorganized and confusing manner in which the attributes for many of the menus are laid out.
In the above tileset editor, the name for the tileset should be on the top. Instead, since it's listing alphabetically, the name is in a very random location.
http://img405.imageshack.us/img405/9047/ed5o.jpg
Far worse than this is the unit editor. The arrangements of values in this are completely random and cripple any hope of making an efficient, painless run through a new unit. I cannot possibly imagine making a large-scale project in this editor - wc3 was bad enough with several values, like Armor, requiring repeatedly scrolling through a big list to find.
http://img708.imageshack.us/img708/5246/ea1g.jpg
http://img4.imageshack.us/img4/908/ea2r.jpg
The Unit Name and Unit Description fields are on opposing ends of the list and key values like health, shields and armor are separated by totally random and unrelated values.
Recommendations;
I feel that the data editor is in serious need of reworking layout-wise. With the editors the community created for Starcraft 1 having had their interfaces perfected over the course of many years of feedback it seems prudent to learn from our mistakes and our discoveries. While I would never expect an exact copy to be made the editors in question I feel that several important attributes of these editors need to be adopted in the Sc2 editor to help facilitate faster, easier, and more efficient production for users of all skill levels.
http://img571.imageshack.us/img571/8291/editor1.jpg
Attribute Relationships
Attributes related to each other, like Vitals (Health, Shields, Armor - Cost, Tech Requirements, Build Time, ect.) should be grouped together for easy identification and access. The user should not have to scroll down a big list to find any of these attributes. Grouping and organizing these appropriately will go a very long way to helping new users break into the power of this editor as well as help advanced users produce their projects faster, more efficiently, and with less irritation.
Elimination of Redundancy
http://img297.imageshack.us/img297/4229/ed6pg.jpg
Unnecessary dialogues like the above only serve to waste the user's time and instead annoy the user, especially when they are editing an exceptionally large amount of data at once.
GUI editor
http://img27.imageshack.us/img27/7088/ed7v.jpg
In its current state the GUI editor for data is practically unusable. There is virtually no usage of horizontal space whatsoever.
Obscurity
It is clear that many of the help dialogues in the editor are simply not finished, and I do believe that there was going to be a documentation of some kind in the future. Regardless, I feel a lot of dialogues and entries in the data editor need to be clarified as to what they actually do.
http://img9.imageshack.us/img9/3346/ed8z.jpg
I have no idea why the weapon cooldown is called Period, for example. It just seems natural to me that it would be called something that makes it easy and quick to identify. Additionally there are no classifications to ANY of these attributes, and thus not even the slightest bit of organization. Again, I think developers would need a considerable hand-holding process by other developers to become acquainted with the obscurity of the data editor and the confusing nature of its arrangement, while with many other games most individuals can jump in and make basic changes without much hand holding. Unfortunately, with sc2 even changing damage and cooldown values can be a bit confusing for first-timers, and these critical, basic things become no less time consuming to do as the user becomes experienced with the editor because of their scattered nature.
I understand that the editor is complex and powerful. When dealing with games like this I do not expect the editor to be easy or newbie-friendly. I have modded games like Supreme Commander and Homeworld 2 in which there are no editors, just half-assed user made tools that are horrendously inefficient and often extremely buggy. There are many features in sc2's editor that I thoroughly enjoy, and the ui's for water and lights are exceptional and straight to the point - I like them a lot. But the data editor itself feels very haphazard and not much thought was put into it.
My effort is to spread awareness of the need for having the interface improved in the nature of organization and ease of use. This will not "simplify" the editor, this will improve the editor for those already using it by accelerating their production times through intuitive layout and arrangement that presents the immense power of the editor to them in a way that makes editing the game enjoyable and timely. That is why so few large-scale projects were attempted with wc3.
Some things like the Game Attributes editor give me only minor clues as to what they are capable of doing, and no hope for understanding their capabilities without an extensive external documentation or potentially weeks if not months of simply doing random things until something happens.
Within Blizzard's opportunity is the capacity to fix Battle.net and, more importantly, make the editor all it can be. They need but put effort into it. The editor is best seen as a foundation right now, ready for supports and construction to create the tool developers will be able to use in the future to create custom content. The groundwork is laid out but it needs engineering and planning to begin building the real thing.
Actordata and Modeldata
The two most important aspects of custom units are those involving the graphics and the physical functions of the unit, being modeldata and actordata. These are two reasonably complicated files that, currently, are a complete and total pain in the ass to do even the most basic things with. This is in part because they are complex subjects and also in part because the interface for them compounds the complexity issue ten fold.
Luckily for us, and Blizzard, there's an easy way to get around this. The editor already contains a model viewer - this could easily be copied and modified into a real-time preview editor for actors and models, probably even Movers as well. By simulating game events with the viewer, the editor can provide a level of fine control previously only reserved for things like the RPGMaker series and Age of Wonders 2. This seems to be the natural course of evolution and it's a wonder few games have attempted this in the modern market. No, I know why - developers are lazy. But the hardest part is already out of the way for Blizzard.
Animation editing is a tricky business, but perhaps Blizzard might consider making a simple scripting language for actordata. Something like what they employed for the iscript in Starcraft 1.
(I was going to post some iscript code like I did with my original post but it seems that code tags don't work and the forum doesn't have spoiler tags, either... or they just aren't the same and I am too stupid to find them :( )
All of the source iscript code for Armageddon Onslaught is included in the mod's release package - http:www.campaigncreations.org/starcraft/armageddon_onslaught
Making these two files accessible is key to improving the overall user experience in creating custom assets and applying them ingame. But if Blizzard truly does care about the editor they will go above and beyond to provide the means to really get into the thick of these files without having a clunky interface to complicate the process.
Key functions of the new graphical actor editor should be an easy way to determine new events with only 1-2 clicks. Being able to insert a preset event - such as a sound - without any typing or external dialogues. You don't need to dumb down an editor to make it easy to use and intuitive.
http://img411.imageshack.us/img411/5532/edg1.jpg
The AoW2 unit body editor (effectively a modeldata-esque editor)
This editor is not very powerful, but it's very quick and easy to use, and gets you where you want to go quickly. This is what I'd like to see in sc2 - an organized, intuitive, and streamlined interface where functions are obvious and quick to learn.
The key to making an editor as powerful as the one necessary for Actordata but as easy to use as this one lays entirely in how you arrange and manage the interface, and how you present it to the end-user. Enormous clusters of unrelated options like what we see commonly throughout many editors, sc2's included, bombards new users with unknowns and overwhelms them, as well as making finding exactly what you want annoying and time-consuming for more advanced and experienced users. This plays back into the first part where I talk about tabs and categorization. Speaking of which, tabs were added in patch 13, though the organization remains non-existent. At least they're updating the editor! Hopefully they continue to improve it for many years and don't abandon it like they did wc3. This editor still has a very long ways to go to.
http://img257.imageshack.us/img257/2374/62769663.jpg
Although not as graceful as as the AoW2 editor, the RPGMaker XP animation editor for spell effects and the like is another good example of a functional and fairly clearly interface. It is not necessary to jump into an external dialogue for adding SFX files, though unlike AoW2 this editor doesn't support multiple animations per entry (aka not a unit editor).
http://img718.imageshack.us/img718/2718/39088999.jpg
Also worth showing is the RPGMaker XP monster editor, as another source of reference of a good, clean interface for editing units.
Doodads
Doodads need to have their own editor. Additionally, they need to have a way of telling the editor which doodads to randomize in the placement tool without having to copy all of their assets around and make new entries. I wanted to place trees without placing palm trees and then manually changing them but such is a pipedream without bending over backwards. I also had a fun time trying to find doodads until I discovered the actordata IS their editor... which seems a bit weird.
~
The terrain placement tool could bear to be more intuitive and water placement in general needs a significant amount of work. I'd recommend to look at something like the Titan Quest editor.
http://img441.imageshack.us/img441/24/waht3.jpg
The circles in the placement tool tell you about the intensity of blending for stuff like hills and textures, as well as the tool telling you the relative position it is to lower ground and its current position. Additionally, note how water need not be placed in enormous, clunky squares and water height is not based on individual water types.
Other "minor" things that are ridiculous arbitrary limits and should be remedied asap;
- 8 texture limit
- 256x256 map size
- only 2 levels of cliff and 1 level of unpathable subcliff? Really? What happened to wc3?
Something I'd like to see but is a bit more complicated is for creep to be worked out of being hardcoded into terrain and instead worked into data in the form of abilities or somesuch. This renders making a second independent creep kind of insanely time-consuming and difficult if not impossible.
The game also is in dire need of an actual mod loader. Currently, the sc2 "mod" system is just the wc3 campaign system with a new name and is easier to use. The fact you have to make maps dependent on the "mod" completely excludes it from the definition of a mod. A mod completely changes the game and effects every map regardless of what the map says it loads from. In warcraft 3 and Brood War this entailed the use of Mpqdraft. In games like Sins of a Solar Empire and Supreme Commander, who natively support mods, you have a menu in-game that loads from either an archive or a directory. Sc2 will probably never have any mods unless support for it comes out due to Blizzard continually mixing up the definitions of maps/mods and sc2 monitoring RAM usage (aka you'll get banned for running mpqdraft).
Additionally, another key thing separating Blizzard's "mod" system from actual mods is the fact that their mod system is still arbitrarily limited by the absolutely insane restrictions of Battle.net 2.0. You can not make a mod with only 20 megs global of space. Not even close. Armageddon Onslaught, a gametype conversion for Brood War, is still 88 megs because it contains custom music, sounds, and graphics like all mods do. Any significant conversion in sc2 will easily outscale that because of the larger amount of texture data alone. But also because each unit will have more sound data than they did in brood war as well.
The solution is to not have Battle.net be responsible for transfers of mod archives. Mods can be externally downloaded like they always have been, loaded through the mod loader interface, and flag vanilla achievements as unable to be obtained, and exclude the ladder system from being accessed (it just desyncs and drops/crashes you anyway).
Currently you can just modify patch mpqs for modding but... again, this is not ideal and not "supported".