Discussion in 'Assets and Asset Store' started by uScript, Apr 6, 2011.
uScript wil work just fine with both Unity and Unity Pro.
EZ GUI also.
Have two questions regarding your awesome uScript:
- Can we create custom FSM nodes in C# and use it on your graphical editor? I mean, be able to use uScript as a FSM editor for complex AI states and animation blending of characters?
- Can we create custom node categories to better organized custom nodes?
After watching the video on uScript, I have a question. The demonstration shows one canvas being used to make two scripts - one to print "hello world" to the console and another to toggle a light on and off. Does it all have to be done on one canvas? Can you have several canvases in the scene - perhaps one for each gameObject in the scene?
I know it's a basic question - I've never used kismet before or any kind of node based programming - so just kind of feeling this out.
Hi there.. purely personal, of course...
Great start, keep the list coming!
I'll compile all the new questions and post later today.
Being I am a level designer I would love something like this and this looks more artist friendly to me.
So my question is this... Can this produce a game from start to finish and by this I mean on start screen GUI for options go thru that then go to the game. Advance in the levels. The levels go thru each other as they are passed depending on what needed to happen in that particular level to advance to the next one. Be able to die in the game. Once you are dead restart back to the start screen menu and so forth. A typical simple game from start to finish. Not just be able to script in your level as needed. I want to prototype some simple games for my ideas I have and since I can produce all the art assets I need to know if this tool can take me from start to finish on what it takes to make a typical game.
Also it would be great if when you do release either have tutorials showcasing that it can do this from start to finish. Also we need plenty of examples. Only ones that know your product are YOU so when you make tutorials, documentation all that keep in mind guys like me that want to buy this product and are not programmers know absolutely nothing or very little. So put your self in our shoes when creating these types of things for your product and many questions you WOULD get are going to get solved thru having proper documention and video tutorials already setup. Can't wait for the Beta to try this out. Thanks for making such a cool fun product.
Looks fantastic! Can't wait for the beta...
So, here's the $Million question... when can we get our hands on that beta!!!??? I'm itching to try it out!
yes the beta release date please....
as personal opinion , i don't really care about what other tool could be linked with..but i do care on how easy and painfulness you can easily extend such kind of tool with your own specific needs , this is really what matter me much, rather to end up with a bloated list of node / block to link other thousand things.. I mean if extension is easy to get in , you can then do that on your own per needs and specific project..
to summarize , when you need to use only 10 items you don't want have in your sight 1000 that just sit there for super generic tool handling..
I just feel it keep things clean and less distracting
as i say personal opinion, good things could be ability to import other node that link over other tool as package , so you have choice to get them in or not..maybe something you do already in someway..anyway I wait for the BETA !!
PS : I love teh modo color scheme you used ( at least this is what i am think about when i see your tool , modo viewport ;like hehe )
Agree with giyomu, rather than developing your uScript to support many specific tools. It's better to create standard interface which can be used to extend the usability or integrate/import other tool/script seamlessly.
Hey guys, I compiled answers to some of your questions. We will be releasing some more uScript information more prominently through screenshots and videos over time, so we apologize if a question you have can't be addressed right now!
Q: Can we create custom FSM nodes in C# and use it on your graphical editor? I mean, be able to use uScript as a FSM editor for complex AI states and animation blending of characters?
A: Yes, that is possible. Let's take the example of animation blending. I'm assuming you'd like to create animation blending trees with uScript? This could be done by creating your own nodes (if you need something more custom than uScript will provide) which listen for animation events, start animations, blend animations, tick animations, collisions, etc. Then you could leverage those nodes however you desire-- creating simple to complex animation blending trees based around any number of other nodes and conditions. uScript also supports nested uScripts (Kismet users can think of them as Subsequences) so you could create a single complex animation tree and reuse it in multiple scripts (more on the nested uScripts later!).
Q: Can we create custom node categories to better organized custom nodes?
Q: The demonstration shows one canvas being used to make two scripts - one to print "hello world" to the console and another to toggle a light on and off. Does it all have to be done on one canvas? Can you have several canvases in the scene - perhaps one for each gameObject in the scene?
A: Yes, you can have as many canvases as you like, though you may find you will want a bunch of uScript logic in one canvas as they various things you are doing may want to hook into other logic. As also hinted at, you will be able to nest uScripts within other uScripts as another way to simplify the readability and reusability of your visual scripts.
Q: Can this produce a game from start to finish and by this I mean on start screen GUI for options go thru that then go to the game. Advance in the levels. The levels go thru each other as they are passed depending on what needed to happen in that particular level to advance to the next one. Be able to die in the game. Once you are dead restart back to the start screen menu and so forth. A typical simple game from start to finish. Not just be able to script in your level as needed. I want to prototype some simple games for my ideas I have and since I can produce all the art assets I need to know if this tool can take me from start to finish on what it takes to make a typical game.
A: Yes, that will be possible. uScript is perfect for prototyping. However, for more complex games you there will almost always be some programming "glue" that has to happen for a 100% playable full game. In the case of uScript, you could prototype a game mechanic using the build in action/logic nodes, though if you planned to create a shipping product with a team of people, you may want someone more technical to right game-specific nodes for designers and artists to use in production. We also hope that through the uScript.net community however that there will be both technical and creative people sharing information, how-to's, tutorials and uScript nodes (along with our own post-ship enhancements) for people to utilize.
Q: Also it would be great if when you do release either have tutorials showcasing that it can do this from start to finish. Also we need plenty of examples.
A: Agreed and fully planned for! I hope the uScript introduction video gave you a glimpse of how serious we are in providing such information and quality production values -- and as mentioned above, we plan to give the uScript community the tools and support (via uScript.net) to compliment our training and documentation by offer their own contributions as well.
Q: I do care on how easy and painfulness you can easily extend such kind of tool with your own specific needs , this is really what matter me much, rather to end up with a bloated list of node / block to link other thousand things.. I mean if extension is easy to get in , you can then do that on your own per needs and specific project.
A: uScript will absolutely deliver in this regard.
Q: Agree with giyomu, rather than developing your uScript to support many specific tools. It's better to create standard interface which can be used to extend the usability or integrate/import other tool/script seamlessly.
A: We also agree. To be clear on us asking about tools/scripts people would like to see supported-- our stance is that whenever we can add support to improve or accommodate someone's existing workflow we will do so- but never at the expense of uScript's core vision and goals. uScript already "just works" with many Unity add-ons, but if there are ways to automate or present something to our users in an easy manor we will always take the opportunity to do so. In the short term however, it is all about being able to answer today's last question...
Q: WHEN IS THE BETA?!?!?
A: We don't have a target date just yet, but believe me when I say we want it out and in your hands just as much as you do! We have been having internal discussions about what tasks are left to do before we release uScript into the wild. We want to ensure that the beta is effective and useful for both you and us in order to make uScript v1.0 a success. In order to do that there are both some uScript features to be finished, tutorials to record and documentation to write, and a few other things to get everyone started. We are also working out the logistics of coordinating feedback, bug reports, and feature requests so we capture meaningful information to better provide what is important to our future customers.
Thanks giyomu! We tried to pick a look that would compliment both Unity version's color palettes. I can see the similarities between what we ended up with and modo (I'm a big modo and Luxology fan actually).
hehe well i am using modo too ( not that much tho as I am more doing "old TEXT code ^^" right now..) so this is why I did the link with your UI.
anyway I am waiting for the beta too to see how this behave
Oooo, this looks extremely promising. I currently use Playmaker and just picked up Universe, although I'm not impressed with Universe's scant documentation!
Playmaker rocks. as a designer first, these tools have been a world changer for me.
I've signed up on twitter. Count me in for the beta! Please!
I wrote this in another thread, but with permission I will repeat it here.
Perhaps it is appropriate, and we still have time to influence in certain degree in uScrip design, based on our own vision and experience with graphic-visual programming.
My opinion as ex-user of Quest3D and user of Unity from a year ago:
I have no problem by programming in text. Simply find it very inefficient, especially after my very positive experience with Quest3D (may years, doing quite big projects).
For those who prefer text-based programming, the discussion of these tools does not concern them so much. Simply, do not use them, but let us make our mistake.
Instead, those who, like me, we prefer them, we may debate on possible approaches, and hope that the authors of these new tools take account of these opinions.
From this point of view, here are my preferences (in order of importance):
I do not want to write the code and then press play.
I want to have the result running continuously in the Game view, and the code changes are reflected instantly.
This is a critical point, often neglected (as well as impossible with text-based programming, by the way).
Absolutely no need text code anymore. This is not just a whim.
Failure to do so, and they have not addressed the visual programing issue at its root.
Visually designed thinking about the structure of the whole, not the individual nodes and their links.
I disliked the look, a bit austere, of Quest3D, but in the light of these new tools for Unity, I prefer Quest's. The new tools, and in particular Universe, are becoming confusing.
Perhaps the strong structure of Unity (a kind GameObjects oriented programming) may mislead the designers of visual programing tools for Unity.
A key advantage of visual programming is to take a look at the code and recognize it. Your new tools (with the exception perhaps of Playmaker) put too much emphasis on the decoration, which, when the graph is large, subtract presence to the structure as a whole.
Universe: Except for the documentation, they are the doing it right. Best support I ever seen for any tool. They offer a fluid and direct communication with authors, and have an impressive capability to respond to any question or request, almost immediately. One could almost say they are doing Universe on demand.
The model to follow is not Kismet. It is Quest3D.
I do not want a tool to write scripts visually. I want a comprehensive programming environment, not only for artists, nor for clumsy or high level programmers (no offense), but assuming it is a professional tool for better productivity.
I found the similarities of uScript to Kismet pretty nice. Kismet is a proven visual language used in all A-AAA games create with Unreal Engine.
Ask anyone ho work with Kismet how nice it is.
Quest3D graphical programming on the other side was never proved to be efficient for large projects such A-AAA games (even one of their developers told it to the community).
Regarding the clarity of uScript: I found the colored nodes pretty awesome, nothing more visually than different colors to different nodes. Makes you spot different nodes right in the way without even know any of its properties (or what it does).
You will make the beta available to us now pretty please..
With Quest3D has been made large and complex projects, although by not being oriented to games, has not been seen in major titles.
Besides that, what I want to highlight is that Quest3D is a pure graphical programming environment, not a complement to another set of tools. This gives a significantly different nature.
Personally, if I do not find this degree of autonomy and comprehensiveness, is likely to choose to continue using scripts + Playmaker.
Then unity is the wrong engine as unity bases on .NET code, so the end result is always code and with some 5 figure number of classes you will never be able to use visual coding only without severly limiting yourself which you likely don't seem to want otherwise you would have used Quest3D right from the start
Pure visual programming only works within very limited and restrictive environments (Quest3D, Shiva, to a good degree UDK) not with open technologies like unity which through Mono DLLImport is infinitely expandable .
However, I express what I whould like, and we can see how Universe team is going pretty near to this goal.
Juan.jo, it sounds like you will prefer Universe then. uScript is also a comprehensive programming environment-- but our target audience and product goals are very different.
uScript's goal is to create an environment that puts the power of creation in the hands of game designers and artists-- in an extremely iterative environment. In our experiences of developing games over the years, empowering non-technical, creative people to directly be able to create game logic is very powerful and leads to higher quality products. "Hard core" programmers want to program-- and personally I want them innovating new features, core technologies, and building project-specific iterative tool pipelines to increase quality and productivity rather than needing to spend their time supporting a game designer for days on end as he just wants to try a few ideas to find out what is fun.
In a tool such as uScript, this is exactly what happens. Now when a designer or artist needs new functionality, the programmer can spend the time writing a new (and perhaps complicated) node for them and then move on to more important things. Now with this node added to the uScript user's tool box, the functionality of uScript is exponentially enhanced for the designer/artist because not only will it be used for the original problem and iterated on-- the design/artist will ALWAYS find new ways to use that node that the programmer didn't even expect. We have had many cases on past products where a programmer has come over to a designer and asked "How are you doing that in level X!?!? - the engine doesn't do that!" and the designer replies "I just hooked this up to this and track a variable and then use this node like this and this... (etc)".
I also think though that many programmers will also want to use uScript as it allows them to experiment with ideas quickly as well-- not to mention create new nodes and actions to hook into things such as complicated inventory systems, AI systems, etc. There is also a unique aspect to uScript that we haven't announced yet that I think a lot of programmers are going to like...
Looking forward to that mystery feature I'm potentially going to like
Ok, now I'm really watching this.
But I hope the top-secret special feature is something really cool
Automatically converting MonoBehaviours to graphs, like mentioned in some other topic, would be super interesting. Not really useful, but people who really know nothing about scripting would love to have that.
I'm already happy with the fact that we can create custom nodes and being able to use it as a state machine editor is killer...
Looking forward to that mystery feature.
Thank you very much for your sincere and clear answer.
On the other hand my expectations are not as extensive as Dreamora suggests, since a priori I have not much interest in making use of extra features of .NET, and I find that Quest3D is not at all restrictive.
Eventually, although it may not meet all my expectations, uScript, if not Universe, may be enough for me. I'll be willing to see the beta, if you like.
I think your product looks great, and I also like the boxes with rounded corners and soft shadows
Sure, whatever. We want to stop caring about the bloody computer and start caring about the people who play our games instead. Please stop thinking of visual programming as some dumbed down version of code, and start thinking of it as the next level in abstraction, a step up from code-based programming, as C++ was a step up from making holes in punch cards. In other words: visual programming will allow us to achieve greater complexity and sophistication. Just give us the tools we need and see what comes out! Thanks!
Give us tools that we can use, and we'll amaze the world!
I'm tired of this debate.
You know, like me, that visual programming involves neither higher level nor limitations. Just another way to write the code.
By its nature, is evident it's application to facilitate the work of the artists or less technical people, and therefore have a proliferation of products with a light approach to visual programming.
We know the Quest3D example, as a tool without restrictions (in the field related to programming for real-time 3D graphics) and great depth and power.
As is normal that somebody is wondering why, the reason of JohnyZuper and I are working with Unity is mainly because Quest3D is just to work and produce for Windows platform.
It has nothing to do with "thinking"
Lists with 15k nodes in just to cover the classes + another 10-50k to facilitate functionalities with them do not only run like bloddy crap but also the graphs become totally unreadable and with a large number of users already incapable to read the MSDN without graphs, we don't need to talk about their behavior if its nodes where the relationship to MSDN would be clear even less
With limited I meant task focused, you will no longer be able to unleash what is theoretically possible but if its focused at a specific thing you can do a lot
With its capability to add own nodes you can achieve exactly that though, task focused full sets of nodes allowing basically 1 programmer on a team to feed 2-x designers with all they ever dreamt off without a problem, creating a base of functionality you can even reuse later
But without a programmer I don't see it happening as even a team of 5 devs on uScript would have years to create it and even worse: they wouldn't know what one on a specific project might need (cause if you go down to "1 command = 1 node" then visual programming because extremely painfull, otherwise you end on multiscreen graphs for something taking half a page of code. its much more efficient to have a new node created out of this.
Aside of the costs it would cause to develop it and the resulting required license and support fees which would totally kill its chance against Universe + PlayMaker
Naturally if uScript supports hierarchical nodes, the world looks a bit different, then you can create a lot of reusability yourself, if it allows you to store them for reuse then even more, if it allows you to do so to a specified place on LAN / WWW to auto share with the team, then epic
But even then you will need programmers for various tasks as being able to do visual programmers does not imply any technical background knowledge and there are just things you can't pull off without it. But it lightens the load on the programmer if the designers can drag out less complex wars on their own
As for "Quest is not limited": Not sure how you measure limited, but limited to me means that they offer a fixed set of functions, point. Isolated world with exactly those things they decided to have in and let you work with. That was one of my major problems with it, especially cause the things offered are not remotely as fully featured as Unity, its more like Shiva with a bit of this, a bit of that, kind of like they added what they think they would need.
Unless I missed something there is no global expandable framework like Unitys mono which is unlimited in its functionality and which out of the box pushes up several thousand classes and hundreds of thousands of functions.
Thats what I consider limited as fulltime developer.
Thats a limitation all VP systems I've seen so far have unless they require coders to create task specific nodes (like Virtools) with them offering the framework to do so etc, why I consider pure VP on its own is limited.
If you naturally are basing that comment on the fact that only UnityEngine classes would be present, then you are right, then it wouldn't be "limited" by your definition (but that would be limited by mine as I work regularly with System.Collections, Generics, XML and File which you all no longer have)
I personally consider Visual Programming as a great tool to enable designers to do much more to let the programmers focus on the complex and low level stuff. That enables both sides to do the best work they can as good programmers are not needfully good designers and good designers are not needfully good programmers but if both work on their own sides with a tool inbetween that allows the programmer to "hide" complex workloads with simple things like 1 or a handfull of nodes that hte designer can experiment with and create interactivity it leads to great end results
EZGUI, iTween, PlayMaker, sprite manager 2
I just started playing with Universe trial and I actually like how it works. I wonder how uScript will set itself apart, I'm interested in this too. Gimme a comparison table!
That's the plan!
We added a "Forum Thread Updates" section to the bottom of our original uScript post. We will update that to point to specific replies within this thread that you may find interesting regarding uScript.
Now back to the video making for me!
Wow what a God send! I was just getting frustrated because I couldn't get some triggers to work. (Not the best at coding) and I've had COUNTLESS times when I've wanted to put my head through my monitor because I couldn't do something simple like "playsoundoncollision" or some other silly thing that should be really simple to do. I was seriously thinking of switching engines.
I haven't gotten the chance to play with Universe yet, but I just discovered, that and playmaker today. I went to google to find out comparisons between the two and BAM, first link on the page is uScript. WOW. I can't wait to see what comes of this. Hey, I might actually be able to make something that actually DOES something now. yay.
Oh, this may sound silly, but will this work in the Standard version of Unity as well?
Thanks Dreamcube. Yes, uScript will work just fine in Standard as well. We make sure to use a mix of Unity Pro and Indie/Standard on both Mac and PC in development to ensure everything works just fine.
That's wonderful. Thanks. I look forward to seeing where this goes.
Enough talk already!!!!! Please let us play with it!!!?????
I will add Nikko's questions from another thread to here as well.
Didn't pay much attention to this image before.........are you integrating a cover system like the GOW one in uScript ?
uScript (as Unreal Kismet) are visual scripting editors, not game specific features (as the GOW covert system) , however nothing stop you from implementing such system in your game using Unity (coding or visually scripting).
Btw, the GOW covert system was done in both UnrealScript (Kismet custom nodes made with UnrealScript) and the states/switch nodes logic flow on Kismet.
Not currently SamSam! We were just doing a visual comparison with that image for people familiar with Kismet. Right now we are too busy getting the beta ready!
tatoforever is also correct in that you could implement such a system into uScript if your game has need of one (or possibly someone else may want to make such a system that works with Unity and uScript and provide it to others).
We have just put up a new video showing some of the basics of the uScript Visual Scripting Tool in action. This is part one of a two part video called "uScript Fast Gameplay Setup".
As always, we love feedback, so please post on this thread with any thoughts, suggestions, or questions you might have. We'll do our best to answer what we can!
UPDATE: You can now also see Part 2 on YouTube or Screencast.
This is too hard.
Man I can't wait for the beta for this to come out.
When will the part two of the video come out?
And can we get the beta this week?
That 10 minutes was a nice teaser >..>
It's easy to understand. But I think the problem is that it can easily become a huge maze for a more complex logic. Is it possible to create a reference node from current node? For example, if I want to separate each event trigger to light trigger, sound trigger and door trigger. Rather than duplicating trigger event and toggle component node, I would prefer to create reference to toggle component node and attach it with another logic. For visualization, a reference node may link with its origin node with dashed line or something else to easily indicate that it is a reference node.
I will simply ask this question again
Is it possible to see the program flow in uScript, like in Virtools or Vizio Universe?
If you don't answer this question, I will take that answer is sadly NO