Visual Logic Editor WIP

Please please take a look at MITs efforts at 'intuitive' programming. Scratch and its grown up bro StarLogo TNG are in a league of their own.

U can actually do a hell of a lot with just simple blocks in Scrach. Basic triggers, movement etc.

The lego block mentality is really amazing and make you feel like there is no distance between you and the software.

Please could you make the visual editor for Unity look BEAUTIFUL rather than just functional.

Ideally you'd want to look forward to getting you're hands dirty and playing with possibilities and leaving room for exploration, rather than just building yet another spralling network.

Just a thought. Seriously.. Scratch is a genius of simplicty. I'm sure you can develop the same mentality to encompass higher level of interactivity.

Peace and creativity!

 

Subscribed. Looks super promising!

 

Awe, visual scripting ability would be... beautiful.

 

Am I the only one who thinks Unity's scripting to be actually easier than Virtool's building blocks?

 

Nope you aren't.

Anyone with some programming capabilities and enough logical thinking to design larger scale stuff will likely agree as the visual scripting creates a massive overhead and a total flood of redundancy, making it really inefficient for "real usage and real users". Its an artist toy to compensate for the lack of programming knowledge and/or logic by offering enough redundancy to make it simpler to create simple stuff (more complex one is a trip to hell basically as you can keep in mind 200 lines but not 10'000x10'000 of node data and node hierarchies with zooming into nodes doesn't make it any simpler)


People favoring this still of coding just miss the point that this graphical stuff is basically nothing but mimicing OO programming "on a shallow trivial surface"

 

While you have a very strong point dreamora, and for the most part I agree with you 99.9%, I think that node logic does have its place and could help speed certain things up.

I'm going to derail the topic for the sake of argument here. I work at a special effects studio, and we use a piece of software called Massive. If you have seen Lord of the Rings, then you have seen what this software can do. It is basically a crowd simulator, and it's completely node based. It's AI characters, or agents as it calls them, run off a quasi fuzzy logic system.

Basically you connect logic nodes together to form an agents "brain" and it runs through and decides what to do depending on how you wire it up. While this CAN get complex, and have massive hierarchies, most of the time it never gets to that level to get what you want.

Now don't get me wrong, I am a coder / scripter myself and fully appreciate the level of control that it offers, but I can make an entire agent brain from scratch in under 5 min using the node system. Do you think it would be possible to write one from scratch in that amount of time? I highly doubt it.

I'm all for coding, it gives you the highest level of control possible, I just think that a node system could be useful in some way, either to prototype an idea or for use in simpler operations where you don't need absolute control.

 

It seems to prove one approach 'better' than another, people are using best/worst case descriptions of what they prefer or don't prefer. Massive, for instance, is not just a generic program builder that makes it's animations easier because visual scripting is that much better. You also do not need to represent small amounts of code with confusing trees of nodes, a well developed system would allow the developer to create just as organized logic as it could be done in purely written form.

In the end, I think it's like normal communication, some things are best communicated in pictures, some in written form. Both are often most effective when used in tandem, which is how I feel about visual logic editors and pure text based code.

I would say modern code editors highly integrated with modern languages are quite effective at allowing you to get what you want into the code quickly, and most modern practices produce APIs that are fairly easy to learn and use. I would say that more people seem to have an aversion to 'coding' than they should, using something like VS with C# is nowhere near as hard as general programming a decade ago. This is likely the same thing dreamora was saying, but perhaps I, and likely he, have been doing this for long enough it's hard to recall not being comfortable with it.

 

Of course it's easier for you to do in script - you're likely a programmer or at least a competent scripter. The reason high-end engines use these types of systems isn't to replace hand-coding, but to offload menial simple tasks to designers and artists enabling the programmers to focus on more important things. Not so remarkably programmers are much more productive when they're not burning their time making doors unlock in a certain sequence for some designer..

The designer's goal is to create a graph with the fewest nodes possible - and if they get overly complicated its up to the programmers to create new nodes that provide the desired functionality while keeping it simple.. specifically so you never get into the position of having huge unwieldy graphs.

 

Bael
let me guess your a programer
i though the reason was the other way around :roll:

 

You are taking this to the very extreme.
For one thing visual logic system is not designed to replace coding, it is to help it in places where it lacks.
People that can't code would tend to overuse it (i mean use it even when it would be better done in coding), but on the other hand if coding is something they can't do at all, why not give them the ability?
You should read this thread from the start, this already has been discussed a lot.

 

I know that it has been discussed and I know the Pro and Cons of it from personal experience as someone forced to code with such stuff but as well as to backup designers working with them and hitting the wall the personal overestimate was struck deadly by reality.

But like other black white topics it will likely never die and as such some balance is required I think to keep realism, not just daydreaming which clearly speak out in some postings.
With only "pro feature" users, people with little to no knowledge forget the drawbacks and problems and start to believe that you can really code whole nontrivial games with it, like some people on this as well as the wishlist thread already do.

 

I agree with rytis.
Sometimes, you can easily do the stuff on a visual way.
Specially for small triggering or events, game logic, etc. That's were visual programming kicks ass. But when things start to complex up. You better do it on code.
However, mixing both of them is pretty powerful.
For example, hiding complex or larges portions of code, behind one single node.
Programmers works on the complex functions, artists and designers link theses stuff in a visual way.
Visual programming is pretty good when combined with code the right way.
Cheers,

 

I gave it my 3 votes

I'd love to work with it.

about " Code VS Node "
come on guys, it's not a competition.
Diversity is always good.

And to combine coding and noding can be really powerful.
As it is very powerful to combine hard coded animations, animations from the curve editor, and imported trad. animations.

Big up! and keep up the good work !!

 

So is this going to be in Unity 3?

 

Mentioned earlier that it will probably be ready for 3.x!

 

Can't wait for this, hope this will make it easier to quickly prototype gameplay ideas without having to write a lot of code.

 

you write just as much of code, just that you drag and drop it around instead of typing 50 letters

 

true, but it would make it easier to check for issues and bugs afterwards

 

Debatable. By Unity 3 my code will be debuggable and breakpointable, yours won't.
So you have to rely on the same kind of "hope it works given the output we get" as right now

 

Not really all that debatable actually. If you have done any engineering modelling, then you would quite obviously understand that you would be laughed out of the room if you demanded to use any lower level language over something like Matlab, MatrixX or NI Toolsets. Time, Stability, Debugging facilities, Flow design, Reuse.. far outweighs "Oh but I like C++!". And please do not claim you can build it as fast, thats plain silly bs. Thats the old asm vs c story..

And the sorts of engineering problems being solved in these tools, make anything in the game business look like toy programming I have experienced both games and simulation world development, and this toolkit looks like its the ideal move forward.

The best thing about these visual systems, is that true black box testing, and true component development can occur and create robust, high quality software with small time investments. Once you build a simple working visual unit - tag it, then use it everywhere. Also unlike most coding languages, visual systems are extremely easy to modify and expand upon. In OO projects this is almost impossible to revisit core components and modify them without the whole thing imploding. If we built brake and aerodynamic systems in OO, as a company we would be dead. The time to market would just kill us and the quality also would simply make our customers evaporate. You just cant do the same things in code, and expect reliable outcomes.

Give it a few years of development and this tool will become a conerstone of creating unity apps (if given the development time). Its funny how its taken so long for even things like Unity3D to appear (visual 3D development) the tool suggested here is just a sensible extension that has been well prooven in so many other places.. dont know why people fight with good ideas.

Good stuff unity developers.. for treading a path to expose your capability to more people and developing features that make sense with large complex problems. This bodes very well for the growing desktop sim market - In fact a binder to MatLab would be an awesome idea

 

I've got a question and forgive me if it's a silly one but why can't a visual coding system/editor work as well as traditional programming? I don't mean specifically with the Visual Logic Editor for Unity but just overall? Like is there something specific that prevents it from being as effective or is it that traditional programmers just don't like it or something? Like what's wrong with having a node chart with thousands of nodes, it's no different having thousands of lines of code is it?

I don't mean to start a flamewar or offend anyone or anything I'm just genuinely curious. Most of the people here who seem to be against node-based scripting/programming seem to be programmers saying that it's inefficient or something (well I assume they're programmers anyways). Again, I'm not talking about specifically the Visual Logic Editor for Unity, I mean in general.

I don't think doing things visually means that it has to be inefficient or would create large overhead or whatever. Playing around with UDKs shader editor, it's pretty easy to make some cool materials. When I look at the actual code for the material I just made I pale at the hundreds/thousands of lines that were generated from it. Does that mean that I didn't program it or that it's somehow inferior to someone writing the exact same thing by hand? It seems to me that the only difference between doing things visually or actual coding is the interface, both result in the same actual script/program don't they (or close enough)?

 

omfg.


I want to work for Unity sooo bad...



btw, it looks like Kismet from UDK.

 

Ok I've been programming for over 30 years. I know all about how efficient code can be (and not!) and debugging and all that. I'm a coding geek.
That said, I'm a big fan of visual programming. Because my job is to help artists who are not so technical. They have a visual sense that can't easily be explained to most programmers and frankly don't have the time for it. It's like speaking a completely different language. Artists are not going to code (in general), and coders are crappy artists (in general), and it is a rare and wonderful thing to find people that can do both to any functional degree.
Visual programming can compile good tight code, why not? It's up to the tool-maker to get that right. And it can not only debug, but prevent bugs in the first place, why not? Again, a good tool would do this, and that's up to a coder to get it right. The hardest part is coming up with a visual system that is easy for the artists to understand and master, the rest is algorithms and good coding practice. This is a coding challenge. Coders: are you up to it?
I think the best solution is one which allows for both styles: text-based for those that like it, and visual-based for those that prefer that. It would be very cool if it could convert between the two, I've seem some attempts at that.

 

Hello good people,

Would you like to participate in creating this thing and help making it good?
What I need from you is use cases. I'm a programmer and work mostly with programmers. They tend to think differently than artists. The tool is more for artists, so I'd love to hear from artists as well.

What we have:
- System with nodes, that have input and output slots that you can connect. Can be like the thing in first post of this thread, like Kismet, Virtools, or nothing like those. It can have variable slots and connections (or not, you choose), can have special kinds of nodes etc. You don't need to limit your imagination much, it's just for a concept.

What I want:
- Think of some practical thing you'd like to make with such tool. Can be of any complexity and achieve any kind of goal.
- Draw up a sketch of a graph with all nodes and connections that would achieve that goal. Don't think of implementation details or anything else. Just how you'd like to have it.
- There would probably be some generic standard nodes in the graph ("TriggerWasHit"), and can be none or many custom nodes made just for your use case (e.g. "DoesThisEnemyWantToFight" node)

What I don't want:
- Low level stuff, calculating prime numbers is not a kind of thing I'd want to see implemented with this tool.

If you can come up with one use case it's great, ten is also totally fine. There will never be too many (I think

 

I made a case for a door, that opens when the Player enters the trigger, and closes when the player leaves the trigger. Opening and closing the door plays an animation and a sound. I tried to leave out some possible implementation problems, because it's kind of hard to draw all of these nodes without a real editor. I hope this helps with your project. Bold text is the name of the node, while non-bold text is the input the user enters into the node. EDIT: I didn't exactly use the nodes you showed in the picture either, but it's pretty easy to translate it into the nodes that you actually have.

 

I actually made a tool along these lines at one point.

Anyhow, here's a use case:

A player moves towards a door and is told that they need to collect 5 keys. These keys then spawn, and once the player collects the keys and returns to the door it opens.

In the diagram below, Cutscene Event was a custom event that displayed a portrait and some text on the screen. The others nodes were fairly generic. The Generic Object Pool represents a collection of GameObjects, and can either be populated in the editor, or by the other nodes - in this case by the spawn event.

A lot of the settings are in component properties (each node has a GameObject) -> things like the Proximity node have a collider and are placed where they are needed).

 

People, how do you draw these diagrams so they are also interactive?

I tried several times and eventually gave up.

 

Thank you! Keep it coming.

gnoblin>
you could e.g. use http://www.gliffy.com/

 

Here's how I (as an artist) would do it for getting the player to interface with something like a ladder. Game Object Player collides with GO Ladder trigger. If the player presses "e", On collision Stay, Activate the "ladder controls script" of the Player GO and deactivate the "player controls script" of the Player GO. On collision exit, deactivate the ladder controls script and activate the player controls script.
(the "Other Script" Node could be a "Component" node instead too, affecting the selected component of the player not, just the script)

 

His talking about draw inside Unity.

 

Take a print screen of Unity, paste it in whatever you use and paint over it. Given that the UI is made up of mostly flat colors makes the job much easier.

P.S: I am in love with the ideea. A nice starting point would be Max's material editor or the Particle Flow visual editor (this one is really artist-friendly and easy to use)

As in this one:

 

Well Done!

Keep Working!

Best Wish！

 

I find all the bickering in this thread amusing (much like many polarized "arguments" on teh interwebz), but feel the need to speak up, since I don't want anyone getting discouraged from pursing the development of this tool.

I spend every day in Unreal3's Kismet and it's invaluable for rapid iteration, setting up of scenarios (you know, those things that aren't just procedural-driven toy-like games) and refinement. At first, I really wanted the ability to "code" in Unreal but after realizing the flexibility I had and the ability to code my own functions, I was sold.

I also wish that I had something like Kismet for Unity, so I could rapidly try out ideas, without having to worry about syntax. Again, rapid iteration. I found myself wanting this, even while wanting to code or script at work.

Even though I'm a Designer (Creative Director, technically), by trade, I used to program a lot, starting 25 years ago in 6502 assembly, so I'm not "afraid" of code, "too stupid" or just looking for "a magic make game for me button". People should realize that there should be choices and tools to aid in getting to the creative, versus fighting the machinery.

If everyone here wanted to be "real game makers" by coding everything, they'd be coding everything, instead of utilizing the amazing engine of Unity.

(BTW, I don't use the terrain and think anyone that does is never going to be as efficient as me, so they should probably take it out of the engine. :wink: )

 

We call it debating.

First of all, UnrealScript is really badly documented and hard to use, but Unity and C# are not. You can't really design your whole game in UE3's Kismet, because it simply doesn't provide the functions you need, like the ability to create new guns or vehicles.

A tool like this should just be used to try out features, not to design the entire framework for your game.

You can't really build a complete game with graphs. It'll get very unmanageable very quickly.

First of all, many professional game designers still use game engines like Unreal Engine 3, and those who don't are most likely in an AAA company (exception: Wolfire, who have been making Overgrowth for years), which isn't necessarily the only "real game maker". Making your own game engine is a waste of time. Unity is highly extensible, making it extremely good for adding in the features your game needs, and not having to use generic tools for everything.

 

Obviously you don't get what I'm saying and/or sarcasm.

I *DO* work for a AAA company, making AAA games (have been making games for the past 25 years). We *DO* have all of our levels scripted using "graphs", as have many top-selling games.

Of course the logic for how an AI's state-machine, controller input, weapon behaviour, etc. are coded either in C++ or UnrealScript, but all of the logic that runs what goes on in a level (ie: the game), is done through this thing you say can't possibly do such. Also, parameters for many objects are modified through Kismet. Why? Because it's tedious to set up scenarios otherwise.

Saying a tool like this should not be made/used, is like saying cars should not have power-steering or there shouldn't be pixel editors (art programs) because you could do it with data statements (which I did back in the 8-bit days), or Unity shouldn't allow you to expose parameters to be edited and you should just go back into script and change the values there.

Any tool that helps, helps. Don't like it? Don't use it, but don't stop progress.

 

Thank you for sharing your thoughts.

And while such discussions are useful, I think by now we had enough of them about IF this kind of tool would be useful

Now let's concentrate on making one for Unity. As good or better than those "other" ones

twitchfactor> maybe you could share here or send me directly some graphs from your production games, with your notes on what you like about them and what you think could be better?

 

In the interest of ending this conversation as rytis has suggested, let me just say that 1- I still think this tool is, in fact, useful, and that 2- That's exactly what I was saying- you can't use it to structure the whole game, but it should be used for level design purposes. I never intended or communicated in any way that I wanted to end the development of this tool, just that it the tool isn't a godsend that will save all non-programmers wanting to single-handedly make a game and lead them to safety.

 

I was really good at Game Maker, since everything had a visual representation, and things could be placed in a nice orderly manner. Easier to keep track of things, since you always knew where they'd be at.

This will be great also, whenever its finished.

When you have something we can download, please edit your first post on the first page, since no one is going to read through a dozen pages of stuff to find it.

 

GUI part aside how would you actualy get it to spit out the code?

Was trying to build some tools like a state machine editer gui and so forth, but I am stuck on how to get it to interface with a bunch of classes/behaviors that I put togeather.

 

as far as i can see there are two sensible approaches. easy one is to use reflection. it is slower (if you care about that) but more flexible. other one is to generate code. what to generate is up to you, but it's not much different from that if you'd write the code yourself to do what your graph does.

 

each block would write out the code for itself and the editor would spit out the code that binds those class instances against each other.


Every block you see in such a node map is an own instance of a specific class actually, so the code generation for most parts should be pretty simple and straight forward.

The complex thing is how to represent more complex things in such an editor.

Most screenies you see are for art node editors which are much more logical and straight forward than scripting, cause those procedural art generation only rarely needs if - switch - while loops - for loops and the representation of them can lead to a hell an ugly mess visually pretty easily.

 

that's why it's been said in this thread like 100 times that you should not do low level coding with this tool.

 

I think the point is not so much a matter of low vs. high level coding, but that it shouldn't break at high complexity levels. The animation event selection in Unity 2.6 (hopefully fixed in 3.0), for instance, 'breaks' very quickly just due to dealing with more stuff. I think, though, it's just a matter of more organizational/browsing/collapsing tools that we take for granted with code, but I imagine you're thinking the same thing.

From me, and it might sound odd, but I do not like the idea of the flowchart mimicking that is often done with 'logic editors'. Perhaps it's just not achievable, but I always find having to deal with positioning the nodes and repositioning when adding stuff to be cumbersome and annoying, and they seem to waste so much space. I like the way code works in that respect, logic flows from left to right, then top to bottom, no exceptions (well, don't get too technical on me ). I don't think I should manage 'whitespace' in any way, and by not managing it, it seems to allow for more dynamic/adaptive display. And, frankly, I do not think anyone here has any problem with that part of reading code, if they did, then they'd have a hard time reading anything .

Anyways, what I think would be nice is not so much changing the structure of what works in 'code' to achieve the desired goals. For instance, pseudo code for handling a door opening, where a door can be opened by a player with a key, or by an enemy, might look something like...

Code (csharp):

1. object = trigger.NewThingInside()
2. if object is player
3.       and player.HasInInventory(key)
4.    or object is monster
5. then door.Open()
6.    and object.DestroyFromInventory(key)
7.  

Now, this could clearly be done with brackets, which I don't think are bad, but since what I'm describing could enforce whitespace/tabs, they wouldn't be needed. It's code that is likely just as easy to comprehend as node based, if not more so with display improvements. Now, this code would be God awful to write as a pure text language, but that's not the point, you'd still 'write' it similarly to node based and deal with it behind the scenes that way. The idea is just to be able to display it as language in an entirely structured way, with rules that hopefully eliminate the problems that non-programmers have with 'reading code'. Things like the conditional elements that would normally be bracketed, like (object is player has key) could instead be properly indented, have colorization and boxes drawn around the elements indicating their combination, or whatever is most comfortable for viewer. I'm imagining that each variable and/or function could have an icon in front of it, default created from class, but changeable, which would allow the display to collapse to icon form when desired. In short, it only looks like code in the respect that it enforces the left to right, top to bottom flow rules, doesn't allow for user positioning of nodes (which has no influence on it's functionality), and uses an obvious shorthand compared to a flowchart. Setting up collapse regions also seems it'd be easier.

This seems especially attractive if an acceptable method of automatic node positioning is doable (not my area of expertise), cause if so, you can display with both this and traditional flowchartish methods.

Here's a fun example using the the code based setup (could likely be done with other display methods). If you've defined a GameObject and an AudioClip, you could select both at the same time in the variables section and in that order, drag to the logic section, then click between them and it could produce a list of relevant functions much like an autocomplete (GameObject functions that take an AudioClip), but with parameter checking. With that approach, you could dramatically cut down on memorization and selection time if completely abstracting GameObject and it's components. Unlike regular code, you could also have functions that have multiple parameters and still collapse them well, like, if you had Play(AudioClip,volume=1,pitch=1) that would be resolved correctly with just an AudioClip parameter, and if you supplied a float value, it'd ask you if you wanted it as volume or pitch. However, when displayed, it could either look like Play(clip,value) with icons for each parameter, or perhaps Play(clip,pitch=value) for display disambiguation. You could go nuts with optional parameters, something that sucks hard in many pure code languages.

I don't know, I just think this sounds much more manageable than what I've seen in logic editor screenshots in 'real' projects, but perhaps that's just me.

 

None the less thats exactly what all designers taking part in this thread are hoping to get, a tool that removes the need for them to touch script sources.

They aren't looking for a "cutscene editor" that allows them to issue a sequence of commands to happen upon a triggered event, otherwise they would likely already use the animation editor from Unity 2.6 which offers exactly that, issueing a sequence of commands without much work, through a single line of code.

But I think we see it the same way: for some stuff it would be pretty efficient, but its no holy grail

 

I still think its completely reasonable request and there are other products which you can download right now that handle it in a very elegant manner.

The real issue is if Unity can commit the R&D resources to build something equally useful.

 

Here's a quick and dirty video demonstrating the simple visual editor I created: http://www.youtube.com/watch?v=hYNnUw1ry-Y

 

which is the tool that handles that in elegant manner?

 

I still think there needs to be less talking and more coding!

Rytis knows I'm on board with this since the beginning and although I don't post much. I read these threads very carefully.

This is an invaluable tool for Unity and imho will not only aid developers but boost the numbers of people willing to give unity a try. That imho is a very good thing for the future of Unity.

Oh.... and maybe look at the 2D tools out there for tips?
i.e Look at how Scirra Construct / Game maker / Multimedia Fusion 2 does it.
I'm not saying do it like that but there are no doubt ideas to be had.

Hopefully I can use this tool by the time our second game comes around.

All the best Rytis!

 

Coders just won't ever get this - Artists often just want to hop in and use kismet or flowgraph or something like this tool here to put together simple logic for the game in a very quick fashion.

Maybe it's more cumbersome to you, it's not more cumbersome to them and pretty much every artist / non programmer would applaud a tool like this in Unity.

 

I think artists want to run away scared from anything that looks like code
I really do like the idea of auto-positioning nodes, not sure if it's possible to make it work in practice, nevertheless it's food for thought. Could probably be just a button to "auto arrange selected nodes".
Making this look like code is something i need time to wrap my head around I've seen something like this ~8 years ago on one of AAA game editors of that time. Coding by dragging stuff into something that looks like programming language code with icons. Right now i feel it's more for the low level coding.

Dragging stuff in place where parameters are expected sure is a want-to-have feature.

Thank you for bringing up these ideas.