Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

To Code or Not to Code?

Discussion in 'General Discussion' started by 3dgreg, Jan 17, 2017.

  1. 3dgreg

    3dgreg

    Joined:
    Dec 31, 2014
    Posts:
    68
    I just completed the Developers Course. As a 3d Model/Asset Designer I wanted a better understanding of what works for people creating the actual games as far as assets and how they get integrated and what makes a better model/asset. I can't help but wonder how people are creating games without being able to code, I see that a lot. Seems like you could spend months just trying to find code that would work for you. Guess it's time to move on to coding.
     
  2. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Those developers who don't know how to code start off with a visual scriptiing tool like PlayMaker. Unfortunately, while these visual tools are great for an introduction to getting game mechanics working, you eventually realize that visual scripting is more of a crutch, or training wheels, to actual text-based scripting.
     
  3. Tusk_

    Tusk_

    Joined:
    Jan 1, 2017
    Posts:
    205
    $65 for something that is free in UE4?

    Also I have heard of huge projects being made in blueprints from what I understand there is no limits.
     
  4. DrewMelton

    DrewMelton

    Joined:
    Sep 24, 2015
    Posts:
    89
    I started out using visual scripting. I tried Playmaker, and in my time with UE4 I used blueprints.

    Honestly, I find them confusing, and this is coming from an artist. Some things are very easy, but as your game gets more complex or you need to do something a bit more involved, I think visual scripting can be just as hard if not more confusing than just coding.

    So, I spent some time to learn c#. I'm no master, but I've made a lot more progress with my game since I made the switch.

    One thing that helps is that there are so many tutorials in c#, not to mention sample code. Plus, some assets use code.

    In some ways, well organized code is easier to maintain. Also, it's easy to edit and add to. With the ability to add comments and organize things how you want, I think it is easier to read than a mess of visual scripting nodes which can get complex after a while.
     
    wccrawford, neginfinity and aer0ace like this.
  5. I_Am_DreReid

    I_Am_DreReid

    Joined:
    Dec 13, 2015
    Posts:
    361
    Its better to use both in my opinion. Learn the strengths and weaknesses of the two and figure out how you would like to implement either of the two in your project.
     
    BrandyStarbrite and Not_Sure like this.
  6. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Id recommend learning to code; it is not only an incredibly valuable & useful skill when making games, but it will be relatively transferable across other digital mediums (to an extent; each language varies but core themes (variables, methods, etc) exist in some form).

    IMO, Visual Scripting has its uses (for quite basic 'click on door and it opens' situations) but you'll very quickly begin to suffer 'node spaghetti' when you start to actually make a game with various systems, complexities and structures in play.
     
    Last edited: Jan 17, 2017
  7. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Ding ding ding!
     
  8. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    This is definitely a subject of much controversy as far as the Unity roadmap is concerned. While I can understand why a subset of Unity users would like a native visual scripting language, there is another subset of Unity users, including myself, that would rather not have UT resources spent on something which adds no value other than to those who cannot write code with a text editor/IDE. As @Andy-Touch mentioned,
    Visual Scripting is like Duplo. How many years are you going to play with Duplo before you move on to Lego?

    Also, blueprints may be great in UE4, but you still have to write the game-specific code for it, if no such specialized code exists for your own purposes.
     
  9. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    I'm currently experimenting with blueprints and Unreal. I'm not sure I like giving up so much control. All of my 'this is going to come back later and bite you' alarm bells are ringing.

    To the OP: Just learn to code. It's not that hard.
     
    Ony, Martin_H, Not_Sure and 2 others like this.
  10. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Well, we are working on Visual Scripting for Unity but its not ready yet. :D
     
  11. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Meh. Well, I'm still on 5.3.x. :) I'll wait till the dust settles.
     
  12. Tusk_

    Tusk_

    Joined:
    Jan 1, 2017
    Posts:
    205
    What are your thoughts so far on it being the next big thing? I have read the unreal forums and I have seen nothing but positive reviews of blueprint, I hear there are massive projects being built strictly with blueprints now and EPIC is pushing it hard, it turned out to be a run away hit. Do you think it is as great as people say it is?
     
  13. passerbycmc

    passerbycmc

    Joined:
    Feb 12, 2015
    Posts:
    1,741
    if you look at BP it isnt a either or thing, yes you can make a game in unreal with no C++, but the BP system is setup to actually work nicely with code. BP classes can inherit from C++ classes and extend them really nicely and can also work with interfaces.
     
    aer0ace likes this.
  14. Tusk_

    Tusk_

    Joined:
    Jan 1, 2017
    Posts:
    205
    Ooh I see, any chance Unity having a blueprint feature exactly like this? or will C# prevent it?

    I have read that the reason visual scripting does not exist in Unity is because it will be a gimmick due to C#. So was wondering if any truth to that?
     
  15. passerbycmc

    passerbycmc

    Joined:
    Feb 12, 2015
    Posts:
    1,741
    well if c# prevents it, it is only because c# is a faster to build and easier language to work with than C++. When working with unreal i tended to always build my main systems in C++ as components just like i would in unity. Than mostly used BP to either make modifications to these or to act as the glue between multiple components on one UActor. Also scenes have their own bp's as well so they are nice for doing scripted game events.
     
  16. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Not true about it being a gimmick! Users already have C#, so Visual Scripting didn't seem as high a priority as other features we have been working on in recent times (Progressive Lightmapper, 2D Tilemapper, Scriptable Render Pipeline, New NavMesh Workflows). But we do have a team working on that system now. :)
     
    theANMATOR2b and Not_Sure like this.
  17. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    584
    I think learning to code gives you the most power and flexibility. This is coming as an artist who started with node-based programming but now I cringe when I have to look at old projects.

    There are a few use cases where node-based code works better:
    • simple 'open the door' events
    • shaders
    • parametric modeling ( talking about Rhino's Grasshopper or the upcoming Unity Archimatix asset under development )
    I think it's borderline if the node graph is useful in Mecamin. Kinda, but also seems to get overly complex for simple animation tasks.

    Everything else just seems easier and visually clear as code. I can see what method is called under what conditions without it feeling like a visual puzzle. And, anything really interesting requires some math, conditions, loops, etc. that need to be done as text anyway.
     
    Kiwasi and aer0ace like this.
  18. Tusk_

    Tusk_

    Joined:
    Jan 1, 2017
    Posts:
    205
    Would be awesome if Unity has it built in and supported directly by Unity especially compared to new users having to risk paying $64 for something they may not end up liking.

    Hopefully the Unity Blueprint comes before the end of the year.
     
  19. ikazrima

    ikazrima

    Joined:
    Feb 11, 2014
    Posts:
    320
    Personally it's easier to mix and match both native C# and visual scripting (Playmaker specifically).
    I use pure code for technical stuff, and visual acting as an overview for the game flow.
    Linking function calls via VS also reduces compile time, greatly improving prototyping time.
     
    theANMATOR2b likes this.
  20. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Honestly its to early for me to call it. I've literally only spent a few hours playing with the system. Many of my problems may solve themselves simply by understanding the system better.

    I just like being in control.
     
    GarBenjamin, Ony and Martin_H like this.
  21. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    The noodle spaghetti come'th soon!1..

    is this for shaders with preview nodes and other more interesting applications or just playmaker type stuff?
     
  22. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,965
    You're comparing apples to oranges. Visual scripting - or at least how it is represented in Unreal 4 which has the only good implementation in my opinion - is not intended for programmers. It's intended to be used by artists. A far better example of Duplo would be UnityScript.

    UnityScript in my opinion is one of those hilarious examples where people like to believe they're having an easier time than if they used C# but they fail to realize that the hardest parts of programming are still required to make use of it. You still need to understand the logic behind programming. You still have to be good at problem solving.
     
    Kiwasi likes this.
  23. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    I admit I threw out that example only to finish my post.:)

    I certainly can't speak for UE4's blueprints since I haven't played with them yet, but yeah, I understand that it's supposed to abstract away details for designers and artists for a division of labor process.

    But the visual scripting that I'm referring to is more along the lines of Scratch, Stencyl, and Game Editor. Back at the game company I worked for, I was on a team that built a game creator along the same vein.. visual scripting, and we were "competing" against said editors. The project and result was very exciting, but it never caught on. After our one year working on the "behavior designer", the nodes essentially boiled down to containing get/set variables and parameters, and the blocks themselves slowly taking the form of rectangles that were indented to indicate scope and order of operations. It's like essentially, through repeated iterations, we started with this node-based editor, trying to give it more power, only to find out that it started taking a formation like lines of text code, surrounded by fancy-looking boxes. So I deduced from this, that the more features and power you throw into these types of visual scripting languages, the more it turns into looking like a text-based language, only with the added overhead of fancy graphics.

    Now, going back to PlayMaker, it's true that it can be treated similarly to UE4 blueprints, in that you can package away functionality and hook up the scripting nodes like a state machine, and that's it. This, I'm actually okay with. It's when you start treating the visual nodes like they were basic code blocks, doing conditional comparisons and loops on primitive data types. That will become a mess so damn quickly.

    So I guess, as far as PlayMaker and Blueprints are concerned, it really does come down to staying smart with where you draw the line between giving as much power/functionality as possible, and encapsulating functionality that shouldn't be exposed.

    EDIT:
    One other thought I remember about those basic visual scripting languages. I just saw this screenshot of Game Editor:

    Advanced scripting? A node that holds text-based script? WTF is that? Just learn the damn text-based language and be done with it! I think GameMaker might also be guilty of this, with GML. What a f*cking identity crisis!
     
    Last edited: Jan 18, 2017
    theANMATOR2b likes this.
  24. Not_Sure

    Not_Sure

    Joined:
    Dec 13, 2011
    Posts:
    3,546
    Personally, I find that visual scripting (specifially Playmaker) is the ONLY way to go for FSM's and menus.

    FSM's get complicated VERY fast and if you screw up you're going to be poking around in code a LONG time to fix it. But with visual scripting you can set one up in minutes and edit it at any point with very few issues.

    And seeing as menus are pretty much an FSM, why not do that as well?

    Just have the state turn on a game object with the stuff you need on it and place a code that sets it up on awake.

    But as far as setting up global variables, events, collisions, and all that mess? Yeah, scripting for sure.
     
    Billy4184 likes this.
  25. MrBinks

    MrBinks

    Joined:
    Jan 18, 2017
    Posts:
    2
    It's great for simple stuff. Wanna a portal to transport you to another level/map? Make a single Blueprint add 3 nodes, and just copy and paste changing the level it loads for each different level. In a way you'll learn how to code if you don't already, and code will make more sense to you once you start learning. I'm just messing around with both Unity and Unreal right now, and right now my needle is leaning more towards Unreal. A lot of that has to do with the tool set they provide. Find it a bit easier to use as well.
     
  26. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    That's the type of attitude that scares me. I really hope blueprints have more power then that. But I can see them driving a lot of sketchy programming practices across a game.

    Sure it's nice to let artists get into the lifting work of programming. But not if they are going to leave a mess like that around to be cleaned up later.

    Edit: Not saying that text based programming does any better with keeping practices good. But it does scare some people off who aren't willing to learn.
     
    Last edited: Jan 18, 2017
  27. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,010
    That's because the ideal representation of an FSM is pretty much a flowchart, given its sequential nature.

    The problem is, what if you have to do something in this level before going to the other level, that depends on where you're going, or something like that? Suddenly you have to throw in some more nodes to check where you're going, getting properties, setting properties, chains of if/else nodes and suddenly the elegance of the node editor is destroyed. Depending on the type of thing you're doing, you can have multiple nodes per equivalent line of code, which is pretty horrific if you think about it.
     
  28. steego

    steego

    Joined:
    Jul 15, 2010
    Posts:
    969
    I just use mecanim for this. Animations can turn on and off gameobjects etc., and with StateMachineBehaviour you can do pretty much whatever you want with the states.
     
    Ryiah likes this.
  29. gian-reto-alig

    gian-reto-alig

    Joined:
    Apr 30, 2013
    Posts:
    756
    Eh... I think this is personal opinion more than everything. From personal expierience Blueprint is just as much bound to limits as any other visual scripting "language" out there, because it is kind of a even "higher language" than the current high languages like Java, C# or C++. Less granularity and more abstraction, good for beginners, bad for pros trying to optimize and in need of that granularity.


    As to Unity not bringing a visual scripting option out of the box. Yeah, that would be great. IF not done the UE4 way, which at many places FORCES you to either do things the blueprint way, or go scraping the internet and picking the brains of longtime Unreal C++ pros to get an idea on how to get around the blueprint mania. Documentation overly caters to Blueprint, C++ seems to be the unloved step child in this iteration of the engine.

    So if many big projects make use of blueprints, it might also be BECAUSE it was kinda shoved in their face and forced upon them by UE4. Which, given you don't mind blueprint and get into, might be a "meh, then we do it the UE4 Blueprint way" decision for these big projects rather than a wholehartly "Yeah, this visual scripting system rocks" statement of approval.
     
    DrewMelton and theANMATOR2b like this.
  30. OCASM

    OCASM

    Joined:
    Jan 12, 2011
    Posts:
    328
  31. Not_Sure

    Not_Sure

    Joined:
    Dec 13, 2011
    Posts:
    3,546
    I just use Playmaker. It's really stable, well supported, and thoroughly documented. I think $65 is a fair price for what it does.

    And if it's good enough to make Harthstone, I'm sure it's good enough for whatever rinky-dink game I'm making.

    Right now I'm teaching Unity to 3 different boys at the shelter I work at and we were able to throw together 3 different games in about an hour each because it made things that much easier.
     
    theANMATOR2b and Ryiah like this.
  32. LMan

    LMan

    Joined:
    Jun 1, 2013
    Posts:
    493
    The strength of visual scripting lies in its visual nature- you can see the logic flow from block to block and draw connections from the output of one node to the input of another. You can also preclude any errors from trying to give a node the wrong input.

    Far and away the best value of visual scripting is in live feedback- seeing what is being executed and when is really valuable when debugging.

    The ideal VS language in my mind would have the capability to convert back and forth between text and visual form.

    Back on topic though, you're always going to get more flexibility out of knowing how to code. You can better leverage different design patterns, you can invent new functionality, you can make tools to make your specific common tasks a cinch, and if you are using a VS in conjunction with code, you can overcome the limitations of the VS language.

    There are specific features of C# that i'm having trouble envisioning in a VS form- it could be that some aspects of code simply don't lend themselves to a visual format as well as through the normal text. This would reduce the main value of making things easier to understand by making them visual elements.
     
    theANMATOR2b likes this.