1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still haven't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. The reforging of the races is complete. Come see the 14th Techtree Contest Results.
    Dismiss Notice
  4. It's time to choose your horse in the race - the 32nd Modeling Contest Poll is up!
    Dismiss Notice
  5. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

What is your preferred language for developing Warcraft III maps?

Discussion in 'Warcraft Discussion' started by MindWorX, May 30, 2018.

?

What is your preferred language for developing Warcraft III maps?

Poll closed Jun 13, 2018.
  1. Jass

    80 vote(s)
    27.4%
  2. vJass

    87 vote(s)
    29.8%
  3. cJass

    9 vote(s)
    3.1%
  4. Lua

    18 vote(s)
    6.2%
  5. Zinc

    13 vote(s)
    4.5%
  6. Wurst

    46 vote(s)
    15.8%
  7. vrJass/vrJass2

    2 vote(s)
    0.7%
  8. I don't program maps directly. I just use the trigger GUI.

    173 vote(s)
    59.2%
  9. Other

    10 vote(s)
    3.4%
Multiple votes are allowed.
Thread Status:
Not open for further replies.
  1. Chaosy

    Chaosy

    Joined:
    Jun 9, 2011
    Messages:
    10,813
    Resources:
    17
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    17
    Try Zinc, it has some aspects.
     
  2. ArOn

    ArOn

    Joined:
    Apr 1, 2011
    Messages:
    77
    Resources:
    4
    Maps:
    4
    Resources:
    4
    I vote for GUI and i like it a lot.
     
  3. -Manuel-

    -Manuel-

    Joined:
    Oct 4, 2016
    Messages:
    196
    Resources:
    1
    Maps:
    1
    Resources:
    1
    GUI is very tedius, the clicks sounds make me crazy, jass and vjass are my favorite options, the sound of keyboard keys is opera for me :).
     
  4. Bribe

    Bribe

    Joined:
    Sep 26, 2009
    Messages:
    8,190
    Resources:
    25
    Maps:
    3
    Spells:
    10
    Tutorials:
    3
    JASS:
    9
    Resources:
    25
    GUI in moderation is extremely good though. I much prefer being able to select unit and ability visually rather than through rawcodes. Same with accessing preplaced units - you can't make gg_unit_hfoo_0001 (gg == game generated, aka preplaced) without GUI.
     
  5. -Manuel-

    -Manuel-

    Joined:
    Oct 4, 2016
    Messages:
    196
    Resources:
    1
    Maps:
    1
    Resources:
    1
    Yes, GUI has these features that jass does not have, I think all the moders started with GUI and thought it is a creation of the Gods (including me), but GUI is not comfortable to work with. The arithmetic is a pain in the ass, obviously if you combine jass and gui through Custom Script it is a bit better.
     
  6. Bribe

    Bribe

    Joined:
    Sep 26, 2009
    Messages:
    8,190
    Resources:
    25
    Maps:
    3
    Spells:
    10
    Tutorials:
    3
    JASS:
    9
    Resources:
    25
    Yeah you won't find anyone talking about what a joy it is to concatenate strings or do arithmatic in GUI. It's so horrible.
     
  7. Glint

    Glint

    Joined:
    Dec 28, 2014
    Messages:
    68
    Resources:
    2
    Maps:
    1
    Spells:
    1
    Resources:
    2
    I think that problem could be solved with something like this:

    upload_2018-6-1_12-24-18.png
     
  8. Mirage1

    Mirage1

    Joined:
    Oct 31, 2015
    Messages:
    64
    Resources:
    0
    Resources:
    0
    I voted for GUI as it is my preferred way to trigger and vJass for all its potential and to allow projects and resources which use it to be up to date with the lastest game patch. Also for simplicity of using only vanilla WE (if vJass is integrated). I think that @Bribe's vision sounds pretty good with a hybrid between GUI and vJass. However as @Kyrbi0 mentioned before there is some things that could be done about the object editor. After about ten years lurking here in Hive (even before I registered an account) I've download almost all kinds of systems and codes people made. And I few a need to say that the interaction between Object Editor and Trigger Editor could be way better than it is now. So I'm going to leave here a few hints of what I've saw and if that is of your interest unhide the spoilers bellow:

    Unit Editor

    Every data field of a unit should be accessible by trigger from shadow model and shadow size to minimum attack range and gold/lumber cost. The majority of fields doesn't interact with Trigger Editor and some of them are very important such as: attack range, minimum attack range, attack/defense type, projectile (why can't I have bounce and lightning(missile/splash) as weapon type instead of being one or the other this doesn't makes any sense), also there could be a field where instead of a missile the unit would cast a spell as an attack (C'mon who never wanted that as a data field in object editor?), resource cost, repair cost, bounty granted, train time, repair time, projectile arc, attack AoE, targets allowed, turn rate (in this case allow it to go beyond 1 for sake of instant turn), also stock fields, regeneration and sight. All those (except by Turn Rate) can't be detected nor set by triggers without having crazy ideas about how to do it with triggered-systems. Creating thoses detection methods can be generally funny but think again: those things are the very basics. They should be available by default. Two other things you blizz guys could provide are: Cone-Shaped Sight (a lot of stealth lovers will hail you if you create that (use a boolean to turn it on in a data field) and second something a lot of ppl would like too: allow the user to customize Unit Classification as a String instead of checkboxes and allow the trigger editor to read it as Strings too instead of Booleans. That would allow unlimited Classifications.


    Item Editor

    Also here gold/lumber cost should be available for both set and read in Trigger Editor. Stacking should be a boolean checkbox with a max stack field right bellow. We could be able to edit Stock Fields by triggers as well and please consider inserting Valid Target for Transformation and Perishable inside Trigger Editor in the Items section. I'm pretty much sure people will find use for them as detectors of some characteristic of certain items. And last but not least: allow items to have more than 5 functional abilities.


    Trigger Editor

    A few hints and questions I made to myself:
    - Why we cannot detect when an attack is successful?(we can only detect when a unit begins to attack)
    - Why there are more Specific Unit Events than Generic Unit Events when almost the totality of triggers needs to use generic units? Also Generic Unit can easily become Specific Unit through conditions.
    - Why there is a damage detection system inside WE which is not available in Generic Unit Event? Allowing it to work in generic events and to detect not only spell and physical damage but also Attack, Damage and Armor Type would be a great addition to WE in general. Also detecting Healing without further conditions other than a single boolean would be nice.
    - Region/Range/Life&Mana events could also be Generic Unit Events. In the case of regions we could say which region has been entered/left in conditions. In the case of range we could use a specific unit to call in conditions (e.g.: Approached Unit) as the triggering unit will be the one which is approaching.
    - Allowing to more easily handle terrain type in Trigger Editor. We can change terrain type but we can't easily restore it to what it was before (e.g.: as the winter comes to an end we should see snow no more. Now it's lumpy grass, vines and leaves again) in a very similar way which Zerg Blight only covers the terrain in SC2.
    - Add functions allowing us to create and manipulate item tables and (why not?) random groups in Trigger Editor. Those options can only used under Advanced tab and cannot be manipulated later by triggers.
    - Consider adding some knockback actions. (There are hundreds of knockback systems here in hive. Ppl want it. Make it vanilla so we don't need to import anything. That's not a priority anyway if it's a bit too much.)
    - Why researched upgrades can't be downgraded by triggers?
    - Lastly but not least add more actions to Destructibles (e.g.:SetZheight) and Custom Value for them too. Also create Generic Destructible Events. Currently destructible events are kinda limited to use. (I ever wondered why we can't manipulate doodads with triggers)


    I've pointed here a lot of things which people tries to create with triggers. You may notice that I gave some neat ideas but most of them are simple stuff which should be already there such as gold cost and train time (read and set). If the interaction between Object and Trigger Editor improves in a similar way I've said not only GUI triggering (my favorite) will be improved, but other languages as well. GUI is clearly the most preferred way to trigger so its GUI what you guys should improve. But I'm my opinion you should integrate vJass to WE before that.
     
  9. Kyrbi0

    Kyrbi0

    Joined:
    Jul 29, 2008
    Messages:
    8,043
    Resources:
    1
    Models:
    1
    Resources:
    1
    I had no idea that GUI would be so overwhelmingly voted-for. I honestly thought I was in the minority as a GUIer. :O

    Also, I'm very gratified people agree with my horrifying "Object Editor Coding" suggestion. xD

    Oh my GOODNESS. This So Hard. I completely forgot about that, but it was be so supremely useful in so many ways; so many interesting & unique spells can only be made by abusing Classification categories.

    Heck, even if that is too hard, at least open them all up a bit more for use; stuff like "Giant" is otherwise just taking up space.

    Oh wow, all of these, too.
     
  10. Storm Knight

    Storm Knight

    Joined:
    Nov 12, 2016
    Messages:
    455
    Resources:
    0
    Resources:
    0
    voting for GUI :)

    Knowing everything in the object editor.
    Abilities
    And Buff's
    With triggers.

    It just Makes my day.

    Also I have to agree with everything Kyrbi0 said and quoted.
     
  11. chobibo

    chobibo

    Joined:
    Sep 24, 2005
    Messages:
    2,699
    Resources:
    0
    Resources:
    0
    "I had no idea that GUI would be so overwhelmingly voted-for. I honestly thought I was in the minority as a GUIer."

    I always thought that GUI was the mostly used method of map modding since it was easy to get into. Thing is, when you use GUI, you also use jass without knowing it.

    vrJass is new to me though, what is that?
     
  12. Chaosy

    Chaosy

    Joined:
    Jun 9, 2011
    Messages:
    10,813
    Resources:
    17
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    17
    WIP by Rufus I believe
     
  13. Loner-Magixxar

    Loner-Magixxar

    Joined:
    Oct 14, 2013
    Messages:
    260
    Resources:
    2
    Maps:
    2
    Resources:
    2
    I don't see the need for anything except GUI for even making the most complex systems and maps. I've never encountered any obstacles making whatever I imagine in my head using GUI. Although some custom scripts for leak prevention or unit indexing or other things can enhance it extraordinarily, but most of my coding happens in GUI.

    On the side note:
    Using GUI made me familiar with the concept of coding and then when I learned C# I found it very easy to grasp. It was like reviewing something from the past.
     
    Last edited: Jun 1, 2018
  14. Kadakash

    Kadakash

    Joined:
    Apr 3, 2011
    Messages:
    8
    Resources:
    0
    Resources:
    0
    Just update the GUI system.
    More options, dunno.
     
  15. Chaosy

    Chaosy

    Joined:
    Jun 9, 2011
    Messages:
    10,813
    Resources:
    17
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    17
    Just because it is possible does not mean it is good.
     
  16. emperor_d3st

    emperor_d3st

    Joined:
    Apr 13, 2008
    Messages:
    1,424
    Resources:
    0
    Resources:
    0
    True, true, but try to add a couple of numbers together in GUI, or godforbid a string. :S

    I think the JASS writer of the World Editor could use a lot of polish.
    For example, when I'm referencing an ability code in JASS, for example 'A001', it would be really nice if I was able to hover the mouse over it and confirm easily that it is indeed "My Special Critical Strike Ability". Same with unit types and whatever.
     
  17. pick-a-chew

    pick-a-chew

    Joined:
    Jul 15, 2007
    Messages:
    718
    Resources:
    4
    Icons:
    2
    Maps:
    2
    Resources:
    4
    I primarily use GUI with some JASS on the side.

    It is not surprising if you think about it. Most mappers are novices which means GUI is the thing they'll be using to code their maps. Only people who are serious or invested in the World Editor will go on to use/learn other languages for coding. The major advantage GUI has is how accessible and easy it is to use. A 10 year old with only a mild interest in computers could produce something from it. Yet, at the same time, GUI does have some depth, meaning those novice mapmakers can go on to create "sophisticated" scripts that run to produce a quality custom game. I say "sophisticated" as GUI sometimes involves hacky solutions which people in the real world would probably point and laugh at.

    Though it is curious that Blizzard are taking an interest in this topic. I hope they continue with 1.29's trend by adding to its functionality. More functionality means more options and potential solutions, which ultimately makes GUI better, simpler and easier to use (who knew such things were possible?!)
     
  18. mori

    mori

    Joined:
    Jun 13, 2016
    Messages:
    438
    Resources:
    2
    Tools:
    1
    Tutorials:
    1
    Resources:
    2
    Preface: My primary occupation is software engineering, not WC3 modding, so my view is a bit biased towards well-developed languages with good abstractions. Now, my choice:

    Wurst, hands down.

    Programming languages overall have a very long history, and this history shows that well-abstracted and well-designed languages prevail with time, because they allow you to focus on the problem and come up with beautiful, elegant solutions instead of having to work around the quirks of a language.

    A good scripting language has to:
    * Be easy to use
    * Be decently abstracted
    * Have minimal impedance when designing systems in it

    JASS is anything but well-abstracted or well-designed. In fact, it's awful. It is extremely clunky and awkward, especially if you have a programming background in other languages.
    * Unnecessary verbose, obnoxious syntax
    * Virtually no support for any kind of abstractions
    * No kind of macro/preprocessing/extension system natively
    * No kind of dynamic allocation
    * No kind of error handling
    * Extremely slow compared to any modern scripting language
    * And so on and so forth...

    vJASS and Zinc, which are almost the same thing, just with different syntax, are a step up but still both extremely awkward languages that often get in your way rather than help you do what you want to do. Historically, they both are also very poorly designed with features that often conflict one another and are seldom used.

    Most (not all) of the people I see responding here in favor of JASS/vJASS seem to be either part-time hobbyists or veterans who are just used to these languages and don't want to spend the time to learn Wurst. Others cite the presence of an established ecosystem of libraries and utilities which make it convenient to keep using those. This is perfectly fine, but objectively, this isn't due to the language, but rather just a side effect of how the WC3 community grew and matured over the years.

    Wurst perfectly addresses all of those issues.
    * Well-designed for its purpose
    * Each feature has its purpose, no feature bloat
    * Easy to learn and use, drawing inspiration from many modern programming languages
    * Open source
    * A proper compiler means that it is able to optimize the resulting JASS code much better than vJASS or Zinc could ever hope for
    * Well-rounded and comprehensive standard library which covers 95% of common modding use-cases
    * Support for programmatic object editing
    * Lambda and closure support (this is IMMENSELY useful if you know how to use them effectively)
    * Excellent, well thought-out toolchain which allows you to edit outside WorldEdit (which is a must if you want to store your source files in a git repository)

    All of this combines into the simple fact that Wurst just lets you focus on the logic of your map, rather than getting bogged down in the verboseness and quirks of JASS or vJASS.

    However, if Blizzard is considering adding support for a community language right in the editor, my personal opinion is that it's not such a great idea. Suggested alternatives:

    * Introduce Lua. Lua is an amazing, feature-rich language that is extremely well-suited for scripting games. It has excellent performance even without LuaJIT, and with LuaJIT the code is usually on par with C/C++ speeds. It also has excellent coroutine support, which would be useful in implementing natives that 'pause' the 'thread', like TriggerWaitAction (or however it was called) and some others. It is also easy to transpile into, so with some elbow grease, Wurst could probably be reworked to use Lua as a backend and greatly benefit from it.

    * Introduce some new, long-desired features directly in JASS, namely - dynamic allocation, structs, code references, etc. Focus on improving performance. That would greatly help transpiled languages like vJASS and Wurst, and is probably the easiest route.

    * Extend the capabilities of WE and help the community provide better tooling in other ways, such as:
    - Provide native command-line utilities for working with WC3 data formats, including BLP/MDX, Terrain, Object Data, Triggers, etc. GUI variants could be built on top of the command-line utilities, giving both regular users and toolmakers more options and more reliable tooling.
    - Post open specifications of WC3 data formats and/or a library to work with them. The community has made great progress with some of that, but a lot of is it incomplete, buggy, or abandoned. Documentation is scarce and often incorrect. This is, arguably, the biggest challenge for anyone who's trying to create new tools for WC3.
    - A plugin system for WE allowing to override/add new functionality to WE would greatly help everyone.

    WC3 has an amazing and an extremely dedicated community, and it is only because of those brave souls who created and supported better and better tools for WC3, that this game is still alive. For almost the entire duration of WC3's existence, Blizzard failed to leverage that fact, and the community had to manage on its own. I think it's time to finally allow the community help Blizzard in resurrecting this game.
     
  19. maxxxus

    maxxxus

    Joined:
    Aug 25, 2015
    Messages:
    140
    Resources:
    0
    Resources:
    0
    am i the only one who thinks each one of those languages are useful depending of what you're making in a wc3 map?

    GUI is really simple to understand and it's cool for beginners.
    JASS is very practical for those which want to develope a map more deeply.
    VJASS, CJASS, WURST and rest could be very useful what people use them for.

    i'd want to know why does every person here use some of those languages and tell me its benefits, and why don't use other languages to know why i should not use them.

    i only know about GUI and JASS, but i've never learnt another programming language. so this is why i could not vote only for one language if i don't know how are the rest of them.
     
  20. mori

    mori

    Joined:
    Jun 13, 2016
    Messages:
    438
    Resources:
    2
    Tools:
    1
    Tutorials:
    1
    Resources:
    2
    It depends entirely on your background.

    GUI is indeed an excellent tool for beginners, but people with background in programming will inevitably find it more clunky to use. Navigating UIs is always going to be slower than typing code in the comfort of your favourite IDE for any competent programmer. But, this discussions is mainly related to programming languages, and GUI is not a programming language per se. It's a visual programming tool.

    If you really want to understand the perspective of those who bash JASS or vJASS, learn a modern language that is actively developed. It can be anything - Java, Kotlin, Python, JS, Lua, etc. Spend some time working in those languages. When you come back to JASS or vJASS, chances are, you're going to find that they are incredibly archaic and inconvenient compared to other modern languages.

    I don't quite understand what you mean by "developing a map more deeply". If you're comparing JASS to GUI, then, yes, JASS gives you more options. vJASS goes one step further and gives you even more options which make writing code easier. By comparison, Wurst leaps miles ahead of anything else the WC3 community had before, and offers sleek, modern syntax, features, performance and more.

    Seriously, try it. There's nothing you can do in JASS that you can't in Wurst. The only difference is that you're probably going to spend 5x times more time writing something in JASS than in Wurst. Time is a valuable commodity.

    There's also another huge problem with JASS. A lot of the time, GUI users eventually hit some kind of wall or limitation in it (leaks, lack of some natives, etc. etc.), and ask for help. They get pointed to JASS.

    But JASS is horrible. It makes writing code tedious, painful and error-prone. I can't imagine how many people looked at JASS, shook their heads, and said, "No, this is too uncomfortable. Programming is painful, I'll just stick to my guns." And then never look back. vJASS is only slightly better in that regard. Writing in JASS is boring, awkward, inconvenient, and often painful, and it leaves a wrong impression of what programming really should be - elegant, beautiful and satisfying.

    Imagine if only we had a proper language like Lua instead of JASS? I can only begin to fathom how many more modders would've stayed, instead of leaving the scene out of frustration or boredom.

    This is why almost everyone who tries Wurst switches to it entirely. It's good. Like, really really good. It is still hampered by many of the limitations of JASS, but Frotty and co. did an incredible job with what they had, and apart from a few rough edges it really feels like a modern language. And best of all, it teaches you skills and patterns that are easily transferable to other languages, it teaches you that programming can and should be fun, beautiful and pleasant.

    That's why.
     
Thread Status:
Not open for further replies.