What is your preferred language for developing Warcraft III maps?

[MindWorX]

We are trying to gather a bit of survey data about the different languages in use by the community today.

Please poke everyone you know, so we can get as much information as possible.

 

[Abovegame]

As of recently i started using JASS so there goes my vote. I may sometime take a shot at Wurst. It seems promising.

 

[BloodSoul]

I chose JASS, because of compatibility in general, and that for a long time I refused myself to use anything that depends on a third-party software (good old vanilla WE). However, unfortunately, there are some things lacking in JASS, as many users are already aware of, such as:

• Not being capable of using globals/englobals anywhere, not even in the map header;
• Having to null local variables;
• It doesn't have features like structures, nor classes (One of the reasons why vJass exists).

So, sometimes my code ends up being quite weird and unreadable in order to accomplish some things.


However, I recently started using Wurst for its features such as anonymous functions, closures, extension functions, the amount of libraries that come out of the box, cascade operator, its OOP style which facilitates my code a lot, specially when implementing libraries to my map. Wurst also significantly reduces the amount of time I take to make something - No need to type needless keywords. Besides, it also introduces the compiletime preprocessor for object editing, which is quite nice and better organized if compared to ObjectMerger.

 

[ScrewTheTrees]

As you know sweetheart, i like produce in pure jass.
But i would love to have native vJass syntax and some extended functionality, as long as it doesnt compile to weird shit x)
Also add support for multiple globals blocks!

 

[deepstrasz]

We are trying to gather a bit of survey data about the different languages in use by the community today.

Please poke everyone you know, so we can get as much information as possible.

Why? How would this influence the trigger editor?

 

[Mechanical Man]

When not using GUI, I use pure JASS, mostly to keep compatibility with original editor in case something goes wrong with 3rd party tools.

 

[Bannar]

I use both, Wurst and vJass.
Willy, if you want I can create multiple accounts to vote for the language you want to win, hehs.

Sure, I'll poke all my andrews and pleb friends to vote!
Thanks for doing the poll, appreciated!

Some notes:
- cJass is buggy, cannot be really used for public resources
- vrJass, Ruke never finished it really
- Zinc has some internal issues, though knowing the limitations, it's fine to use it. However, vJass, his brother in arms, is superior in every aspect

- GUI/ plain Jass is what most new ppl use because despite living in 2018, downloading 3rd party tools scares them (honest, sad truth)
- vJass has easier learning curve compared to Wurst (for new coders coming from plain Jass)
- Wurst offers modern features such as unit tests and compiletime functions

Thus, the decision comes down to:
- keep/ merge GUI/ plain Jass
- not breaking compatibility with vJass and Wurst

 

[A]mun]

Mostly GUI, sprinkled with some JASSy functions and custom scripts.

I would probably use a lot more JASS, but i am still drawn towards the visual appeal of the GUI - somehow text only code is still hard for me to grasp.

 

[Kaijyuu]

I use JASS but solely because of forward compatibility. Many, many maps became unmaintainable due to using old worldedit hacks that didn't work with the new version. Were I to vote for which one I felt does the job best aside from that, it'd be either vJASS or Wurst.

EDIT: Switched vote to vJASS because I imagine that's closer to the answer you're looking for, actually.

 

[The_Silent]

Jass/vJass, but only because that is what I'm familiar with. Jass/vJass is by no means great, it is bulky as heck. Turning it more c++ or c# like would be great. Aka, making it more object-oriented would be great. I need those classes man.

 

[Aniki]

cJass is buggy, cannot be really used for public resources

What bugs do you have in mind?

I find cJass quite nice actually:

define {
    void = nothing
    int = integer
}

// for loop
for (int i = 0; i < 10; i++) {

}

// lexical scoping of local variables / local variable declaration freedom
// this feature alone is worth a lot in "my book"
void foo() {
    vblock {
        int x = 4
        BJDebugMsg(I2S(x))
    }

    vblock {
        int x = 5
        BJDebugMsg(I2S(x))
    }
}

Macros do come in-handy when one wants to generate repetitive code.
Of course you gotta be careful with macros that are used in an expression context:

define Mul(a, b) = a * b
int x = Mul(1 + 1, 2)
// =>
int x = 1 + 1 * 2 // probably not what we wanted

// we need to wrap the macro's arguments in parenthesis
define Mul(a, b) = ((a) * (b))
int x = Mul(1 + 1, 2)
// =>
int x = ((1 + 1) * (2))

But, as someone's uncle once said, with great macro power comes great 'typeunsafetability' =)

 

[Wareditor]

vJass using the Cohadar's Jasshelper for faster compile time and additional features.

 

[Kyrbi0]

I voted for GUI and Other.

GUI: because that's basically all I do. Is nice & simple, comes stock with every version of the game, ultimate compatibility, and I essentially never make anything that needs a more complex solution. Occasional use of Custom Script, whatever that is.

OTHER: because the only thing I use more than GUI is the Object Editor. Yes. Boo, hiss.
But let's be honest here; even as it currently exists, the OE is chock-full of interesting even unused abilities which, properly modified, provide a wide range of possible functionalities. If it were possible to "fix" some primary issues with the OE:
- Buff Stacking (aside from Auras & 1-2 other abilities, no standard 'buffed' ability can stack with the buff of a custom ability based off of itself)
- Minimize/remove 'hard-coded' ability data fields (e.g. Targets Allowed, Durations, un-dispellable Doom, un-level-able Runed Bracers, Incinerate only working in the original, etc etc)
- Enable modification of buffs' positive or negative nature (i.e. a buff -> debuff or vice versa without a miscolored Buff icon tooltip, and with proper AI interaction (i.e. would seek to get rid of buffs-turned-into-debuffs, etc))
- Fix Spell Steal to work properly with custom buffs
- and more...

I tell you that would be an unprecedented boon to modding & an amazing step forward in World Editor functionality.

 

[Kam]

Please voice your opinion on this. We are basing some decisions off the feedback we receive.

 

[Kyrbi0]

Please voice your opinion on this. We are basing some decisions off the feedback we receive.

And here I thought that was obvious... ^_^

Good stuff! I've done my part.

 

[moyackx]

I've put jass and vJASS because it's the base code system and Lua because it was good enough for a macro/static language system. By suspecting that the purpose of this survey is to define which language will be implemented NATIVELY in WE, then it would be logical to extend to vJASS for the sake of compatibility in older maps.

My question is: in the imaginary case of having a tendency with languages like zinc or wurst (or vrJASS), Blizzard will endorse the usage of Java in the WE itself??

 

[Retera]

It's hard for me to vote since GUI is not an option, but rather "I don't program maps" is an option. And, ideally, I would multi-vote all of JASS/vJASS/GUI.
As a kid, I learned first the GUI, then JASS programming, then Java programming, then vJASS, and more recently I have returned to using the GUI when possible, sometimes with a customized TriggerData.txt and TriggerStrings.txt to add new functions -- in combination with JASS and vJASS. I like the drafting power of the GUI, but it would be terrible and limited without the utility of JASS.
The ideal solution would be a programming IDE, where you have a context-sensitive GUI suggestion when typing something. Just like how I choose "Unit" in the GUI, then move on to choose, "Create Unit Facing Angle" it is convenient when an IDE provides the ability for me to type the letter "u", it suggests "unit", then I type the ".c", and it suggests "create", so that I result in coding:

unit.create(

...Without doing more effort than it would have taken to leverage the suggestion utility of GUI, since I only typed 3 characters, "u.c".

Maybe I could live in a world where I only coded purely in JASS/vJASS if there was a function in the advanced JASS editor that allowed me to click on a unit in the Terrain Editor and insert

gg_unt_Hpal_0003

as necessary. As it stands currently, I am not going to type something like that in JASS, but instead write some GUI system that references that character by clicking on it, because this feels more convenient. Then, perhaps I might convert it to JASS if I need increased utility.

Edit: I voted for JASS/vJASS because my biggest project was originally a game mod, so I code by modifying an external "Scripts\Blizzard.j" override and then importing it into the vanilla world editor. I just don't do this for my big project because it wouldn't be compatible with a general-case Blizzard.j override. The override has to be pure JASS to function, but when possible for spurious mapping I download vJASS systems to allow myself to use structs and the library/scope keywords, to overcome the obvious lack thereof in the original world editor. The ability to wrap plain JASS code in the "library" or "scope" keyword to simply say "this block is in phase 2" or "this block is in phase 1" to determine the ordering of function definitions, instead of the vanilla world editor being locked to Trigger creation order, is incredibly powerful. But, ultimately you can accomplish the same with the map header script, it's just less visually appealing and more time consuming to copy between maps.

 

[00110000]

I largely use GUI with some imported jass systems because you honestly don't need much to make a fun map. A lot of people tend to over complicate things by having wicked systems and stats but still tend to fall short on actually having a fun map that many would want to play.

 

[pOke]

I mainly use vanilla JASS but often use vJass because of some nice features that make life easier.

 

[karlek]

Map making with Wurst has simplified the collaboration process a lot. Mainly, since it enables version control for our project. Both for triggers and object definitions by codifying the units, spells and buff objects. Also, many of the very unintuitve memory leaks are fixed automatically. No longer do I need to null all the variables in every code path before returning.

 

[DwarfBoy]

As someone who can code about as well as... well, non-porgrammers, I naturally prefer the GUI in the trigger editor. It's simple, straight-forward, and I can look at the pictures and simple texts and go "hey, I know how that works!"

 

[Dr Super Good]

vJASS

This is because it allows access to features otherwise impossible to access such as global variables. It also can make certain common programming tasks easier such as grouping parallel arrays together and managing instance allocation via structs.

That said instead of natively supporting the language, it would be better if the editor natively supported post build scripts. Such scripts could run command line arguments to JassHelper or other JASS build systems. The WorldEdit JASS syntax checker ultimately runs just before assembling the map MPQ, hence meaning it does not require being disabled.

 

[Bribe]

As someone who's worked extensively in GUI, JASS, vJass, Zinc and failed in an endeavour to make a custom syntax "Luck" (which had some similarities to Wurst) I can say the following:

GUI is by far the best interface for configuration of in-game constants. It is extremely useful to identify to a new user of my resources "hey this is where you can set the special effect art, the speed the unit travels, and the number of dummy units created".

JASS is a great resource for creating a backbone for systems, where the user has full access to all functions and access to more variables. It has the advantage over vJass that it does not require a 3rd party tool (JassHelper) to parse.

vJass is the "ideal" language for WarCraft 3 because you can declare variables (globals blocks), automatically prefix function and/or variable names by putting them in scope (private functions/variables), or force the placement of script in the output war3map.j file (library/requires).

Wurst I've never used, but the other languages included in your post are buggy/deprecated.

Syntax Highlighting would be amazing. It would drop the need for TESH. By default, HiveWorkshop syntax highlighting looks the best.

In summary vJass is the ideal language for building core systems, but if GUI could interact with vJass in some way I feel WarCraft 3 could go in an awesome new direction.

My vision would be to have all triggers be GUI/vJass hybrids by default, where when one adds a "Custom script" line the editor allows as many lines of script as desired. Each of these triggers has its own namespace and GUI variable lists (optionally) exclusive to itself (private).

 

[Adorm]

Hey, just figured I'd give some input on this matter. The GUI is a wonderful tool but can easily be enhanced via the use of Jass when someone has knowledge in programming concepts. Blizzard should provide an accessible Jass API from which map developers can learn from - as opposed to reverse engineering triggers in text format from the GUI.

 

[SpasMaster]

Hidden

I voted for GUI and Other.

GUI: because that's basically all I do. Is nice & simple, comes stock with every version of the game, ultimate compatibility, and I essentially never make anything that needs a more complex solution. Occasional use of Custom Script, whatever that is.

OTHER: because the only thing I use more than GUI is the Object Editor. Yes. Boo, hiss.
But let's be honest here; even as it currently exists, the OE is chock-full of interesting even unused abilities which, properly modified, provide a wide range of possible functionalities. If it were possible to "fix" some primary issues with the OE:
- Buff Stacking (aside from Auras & 1-2 other abilities, no standard 'buffed' ability can stack with the buff of a custom ability based off of itself)
- Minimize/remove 'hard-coded' ability data fields (e.g. Targets Allowed, Durations, un-dispellable Doom, un-level-able Runed Bracers, Incinerate only working in the original, etc etc)
- Enable modification of buffs' positive or negative nature (i.e. a buff -> debuff or vice versa without a miscolored Buff icon tooltip, and with proper AI interaction (i.e. would seek to get rid of buffs-turned-into-debuffs, etc))
- Fix Spell Steal to work properly with custom buffs
- and more...

I tell you that would be an unprecedented boon to modding & an amazing step forward in World Editor functionality.

I was about to write down my opinion and then @Kyrbi0 seems to have already said it.
I basically use GUI only, which can have its limitations, which is why I always wanted to get into Jass coding, but never managed to find the time and will for it. From what I've read over the years, GUI is sub-optimal and you can pretty much be more efficient with your code when writing it yourself in Jass. But what if the Jass code behind all the GUI functions simply gets more optimized so that there wouldn't be much difference between the two methods? Sorry if I am talking nonsense here, just thinking out loud.

P.S: Oh yes, Object Editor improvements, specifically to how the Editor handles buffs/debuffs would be just great. Stacking & Positive/Negative buffs have been a thorn in the butt for ages.

 

[Velmarshal]

Only GUI pretty much.
It is an excellent tool for new mappers, people unfamiliar with coding and people who don't want to bother with coding (me).
Aside from some specific functions, like detecting and keeping track of damage, I have never needed any scripts or code in my maps.

But certainly wouldn't mind an expansion of GUI capabilities. xD

 

[Empirean]

i like using triggers cause you dont really need to study the language too much just code and test.

 

[Chaosy]

Wurst by miles, there is no competition.
Zinc comes second

 

[Donach]

For those who never tried WURST: Guys, this is "the thing". It offers so much functionality... No reason to repeat, just head over to their website.
For project where there is more than 1 guy involved, there is nothing better. We are 3 coders using Git and it works totally amazing (not only the versioning, but the scripting as well ).
What can be not liked on "features" like this?
Now more than ever with 24 player support! (we are not using it... yet)

init
    let t = CreateTrigger()
    for int i = 0 to 9
        t.registerPlayerChatEvent(players[i], "-", false)
    t.addAction(function commands)

Wurst all the way!

 

[Deleted member 219079]

I voted for these three: Zinc syntax is the most comfortable. Wurst is the most feature-rich. JASS can be inlined to GUI triggers and gives you most control over resulting bytecode.

 

[StoPCampinGn00b]

For those who never tried WURST: Guys, this is "the thing".

Wurst all the way!

I kind of like how this thread is turning out. Programming language nationalism patriotism is on the rise!

Also I've attached the promo image used to promote this poll in other places; hopefully we'll see some more outside perspective. In short, yes, please spread the news in whatever appropriate way possible.

Anyway, great work MindWorX and thanks everyone for participating in this thread with votes and posts.

 

[Napoqe]

You from Blizzard invented I think, a creator of game that is easy-to-understand, powerful and a few moments fun to use for me. One of the motives I bought Warcraft 3 and its expansion, is back to make games and play custom maps. I used my brother's game. I met Warcraft 3 because of the Dota.

I admit that I encouraged Valve to create a similar tool, but to this day, they not did.

One of the cons of Warcraft 3 is still game you need to buy digitally, since Dota 2 and Stacraft 2 Arcade are free. You can make free play Warcraft 3 custom maps, but to create and edit maps would require have the game purchased.

I voted only for GUI, never needed to learn Jass. But Jass I think good to avoid having to click too much. Because of the World Editor, I wish to be a creator and developer of games. I had a good sensation to be when I was developing the Noob Map in 2009 to 2012, receiving feedbacks from friends. And having fun with own games I made.

I wish you expanded the GUI and Jass.

And do not make the same problem that Stacraft 2 data editor. I bought game I got disappointed, had little alternative to custom games, the data editor of Starcraft 2 I did not get to learn and I think hard to learn.

 

[pusha1999]

i use turbo pascal with qbasic

 

[Sedistra]

Zinc 'cause syntax.
Wurst 'cause features.

 

[Chaosy]

i use turbo pascal with qbasic

Nani?!

 

[deepstrasz]

Please voice your opinion on this. We are basing some decisions off the feedback we receive.

Which are?

 

[Glint]

I voted for Jass, vJass, Wurst, and GUI.

I don't know if it is a bad idea but it would be awesome if there is an object-oriented feature in GUI. Adding the option to create local variables within triggers. Optimizations with the generated Jass code in GUI. Anything you could do in Jass should be added in GUI. Then an online feature within the World Editor in which you could browse and download resources like custom triggers, object data, and imports. Map-makers do not need to copy-paste triggers from one map to another anymore.

It will blow my mind if Blizzard is able to pull off something like that.

 

[Lord_Earthfire]

Even though i got a good knowledge of jass, sonehow i find myself using some weird conglomerate of gui with many custom scripts and jass functions that i wrote in my map header to optimize the whole mess a bit (things like orbital coordinate transformation or easy system index creation, destruction and allocation... Yeah, my code looks messy, thx for asking). But the reason is that im far more confortable with gui. When i would get my arse up and trigger more jass systems i would switch to that conpletely, i think.


Above that, i think i could overall agree with what bribe said. To add to this, jass highlighting is just so much needed to get overview upon your coding, because else i always have problems finding things or debugging.

Edit: Above that, i would really like to see an easiely accesable database of the jass functions. I know we got multiple tools and tables that contain them, but what lead me for a long time to stick to gui instead of jass was that i just don't know the natives and fiddling them out of tables was just tedious.

 

[Rui]

Stability is prized above all else for Protoss and Night Elves alike. So, for me, vanilla JASS is the way to go.

Occasionally I felt the need for OOP-oriented features, and since vJASS is finished and has remained stable, I eventually explored it. I had been using global blocks a lot prior to that, anyway.

I confess to being a little lazy on wanting to learn new syntaxes, so I've been postponing indefinitely getting to know Wurst.

 

[Jampion]

I vote for Wurst.
I went from GUI to Jass to vJass to Wurst and it was steady improvement.
Wurst speeds up coding a lot: a powerful standard library that covers all things you often need, support for version control systems, less verbose syntax

Aside from being a better language overall, it also adds completely new possibilities with compiletime functions and object editing.
My map uses an item recipe system. I only have to specifiy shop, item name, whether it is an recipe, icon, description, gold cost and required items. The rest is handled by the system.
Recipe's gold cost is reduced by the gold cost if its requirements and the items will be sorted by gold cost in the shop.

public constant ITEM_ID_EMERALD_PENDANT = compiletime(newItem("Emerald Pendant", SHOP_MAGICAL_3, true, "BTNAmulet"))

function itemEmeraldPendant(int itemId)
    if compiletime
        itemId.getTypeDef()
        ..setDescription("item descirption...")
        ..setGoldCost(3500)
        ..addRequirement(ITEM_ID_SKULL_PENDANT)
        ..addRequirement(ITEM_ID_GEM_OF_HEALTH)
        ..addRequirement(ITEM_ID_GEM_OF_MANA)[/INDENT]

I can't even imagine how long it would take to create them in the objects editor. And if I wanted to change an item's gold cost, I would have to change the gold cost of items, you can build from it and update the button positions of the items in this shop, so they are sorted by gold cost again.

In the end I think you need to try wurst by yourself to see how good it is. I was sceptical at first, doubting it would be as good as the people said that were using it.

 

[A Void]

Definitely GUI, sometimes I convert it to text (JASS), but that's uncommon. GUI should be your primary concern, as it always was.

 

[The_Silent]

Definitely GUI, sometimes I convert it to text (JASS), but that's uncommon. GUI should be your primary concern, as it always was.

But Gui is terrible

 

[Chaosy]

Garbage*

 

[MyPad]

Definitely GUI, sometimes I convert it to text (JASS), but that's uncommon. GUI should be your primary concern, as it always was.

@The_Silent

I'll do you one better...
Why is GUI?

Back to the thread:

Why vJASS? It is, as I will claim it to be, one of the renowned scripting languages for the Warcraft 3 modding community, mainly because of how it was built to feel similar to JASS2, while adding new features to it. Over time, its' ease of use led to people considering it over vanilla JASS2, making it a mod-driven successor to the original compiler.

But why did I choose Wurst as well? Well, progress in developing vJASS suddenly halted back in 2011?, with somewhat newer iterations of the language not being as impactful as the original to the community. In a stagnant state, it would be deprecated in time by another resource that is superior to it, and I'm not referring to anything in particular.

With that in place, Wurst was and is a scripting language developed by those who are willing to go beyond the natural limitations of vJASS, those who envisioned a more modern version of the language that is JASS2. Wurst strives for readability and maintainability, which resonates very well with dedicated map making.

 

[A Void]

Look, guys. It's nothing personal but my opinion is that GUI is more accessible to everyone, easier to use and much, much more organized. I won't argue here, I'm sorry. I'm here just to provide my vote.

 

[Chaosy]

It is easier, that is the only advantage with it.

vjass is a clunky language which possibly makes it slower to use.
But with wurst, I think GUI is slower to work with in comparison, that is a huge deal for me.

Reasonably speaking, only reason to use GUI if you cannot commit time to learn better options.

Funny thing is, most wurst users have gone through most languages which gives us perspective
GUI => JASS => vJASS => Wurst

No one goes back.

 

[IcemanBo]

Of course one might use Wurst to write structured OOP, algorithms, etc, but that's not the only goal of code usage.
I have no active map project, so I mostly used what Hive uses the most, GUI + (v)JASS. I tried Wurst and liked it more actually from possibilites than vJASS, though there's no need for me to use it.

GUI lets you easily interfare with pre-placed objects on map, it provides default trigger-structure, categorized functionality which may also include brief description. Going fully away from GUI would be definitly a bad step, also in means of being beginner friendly. Even usually I write systems in vJASS, I still think GUI is still very legit being used for maps.

 

[Gottfried]

I agree with Icemanbo's comment as I only used GUI, when I was made map triggers.

 

[Chaosy]

I am not saying "remove GUI" I am just saying that objectively speaking it is inferior in almost every objective metric.

Saying "GUI is good because it works" is.. yeah..
We would still be washing our clothes in the rivers because that worked, who needs washing machines.

I modded for quite a few years before I left GUI, I know that is has good sides.
But as I said, people move from GUI to other languages, never the other way around.

 

[Donach]

It is easier, that is the only advantage with it.

vjass is a clunky language which possibly makes it slower to use.
But with wurst, I think GUI is slower to work with in comparison, that is a huge deal for me.

Reasonably speaking, only reason to use GUI if you cannot commit time to learn better options.

Funny thing is, most wurst users have gone through most languages which gives us perspective
GUI => JASS => vJASS => Wurst

No one goes back.

I can only second this. Went the same "one-way of no return". Glad I did.