For it seems, programming into local languages script, this go out of style.
Script gives error behind the error.
From what understand, and is already used some 3d engines use VisualScript.
At least I say. I’ve tried using VisualScript (Blocks). It is easier, reduces errors, and perfect results, simply by connecting the blocks. as the 3DVIA Virtools 5.
Had this type of programming into Unity3D is perfect.
These “visual” programming systems have their advantages, and Google have just built a similar system for writing simple Android apps, based heavily on MIT’s work on “Scratch”. However, the key problem is that they’re still a poor interface for Finite State Machines.
It’s also a very mouse-heavy system, so RSI would be a problem for most non-trivial scripts. (It does, however, lend itself very well to touch-screen devices. A “Visual Script Builder” for the iPad or similar may have potential.)
However, I’d rather see the folks at UT work on something genuinely new rather than rehash a decades-old LEGO-block GUI for programming. Engineers have been visualising Finite State Machines for decades now—take a look at any railway signalling and control system to get an idea of what’s possible.
Agree, and other engine use Visual Scripting, is the new “Ready At Dawn Engine”.
Info Here: http://engine.readyatdawn.com/home/FAQ.html
Video Apresentation: http://area.autodesk.com/gdc/ondemand8
The Unity3D could use as another option, visual script.
In my opinion, the visual script, done in Unity3D, for example, “Plugins”, pathfinding, Waypoint script is heavy for Unity3D editor.
For various reasons, apply more memory, unstable etc …
I own I have done in several 3d engines. Eg: 3D GameStudio, I made my own using the pathfinding own script itself, it was heavy. In the oldest shiva3D also did, was too heavy. Now in the new Versions for the shiva3D, since the system includes inter pathfinding and AI, excellent result.
And the DX Studio, the system Waypoints, very good and easy, pathfinding Very low and heavy in scripting.
So do these kinds of things using Unity3D own script, it uses many resources.
The other engines functionaI well, because the systems and Waypoits Pathfinder is in own 3D engine in its entire interface redering.
Unity3D If I had to their respective editors for Pathfinding and waypoints would be more effective and more intuitive. Instead of doing so in the script.
It seems to me that you’re talking about having high-level game logic features built into the engine, which is what a system like “Visual Script” would require.
This would mean abstracting stuff like A* pathfinding away from the user on the basis that it’s already a known science, but there is a disadvantage: the pathfinder script would need to be quite generic to ensure it can cater for as many game genres and variants as possible. Even so, there are only so many types of game you can design it for. if you want to build a game that requires a more tailored—or more optimised—pathfinding algorithm, you’ll still have to write it yourself, because the “Pathfinder” script block would be a fixed, opaque, unchangeable element.
What’s needed is a way to provide the flexibility of a traditional scripting system, with the ease of use of a visual system.
One solution is to design the visual system such each block is itself built out of other blocks. As Unity has 3D graphics support already built-in, this means an editor could present a visual script where the user can still click ‘into’ each scripting block and have it zoom in while unfolding to reveal the more detailed logic within. Some blocks in this ‘sub-script’ would themselves have further blocks inside… and so on. In essence, you’d have a “3D Script” development environment.
Users could thus create their own blocks and provide them to fellow users for use in their own projects, rapidly building up a library of re-usable script blocks that increase the power of Unity itself out of the box.
(Similarly, the Unity Plug-in system would permit the building of new blocks too, albeit written directly in a compiled programming language rather than the 3D Script language itself. This would improve performance for those blocks where performance is important.
At the same time, the team responsible for maintaining Unity’s own script blocks would be able to keep an eye on which third-party functions are proving most popular, giving them the opportunity to rewrite them as built-in elements for the next release.
The hard part will be handling issues like dependencies.
All the same arguments always come up… But at the of the day a properly designed robust visual scripting can be better then traditional systems in a lot of ways and in some ways worse… Having both systems available though is nothing but a good thing…
It’s something that takes along time to develop properly and seeing unity was never designed with it in mind it may take a long time to see a good implementation…
If your desperate you could always try www.3dvia.com\studio which is the replacement for Virtools and has a strong visual system and traditional scripting approach.
I use 3dVia Virtools and the new studio version a long time.
And for the most of it, i use GameBryo Light speed and trinigy. Great programs, and not ilegal 100% pay of it. And the bad of 3Dvirtols and studio is control scene gizmos and objects manipulation, realy sucks:).
Unity3D have very good manipolation of objects.
Only the unity 3D need is Waypoits placement editor for rapid waypoints then call in script and call the object wht the object most do.
like DX Studio Waypoits editor. I think need especial fuction for the waypoints like: function Onwaypoints(), Onstartwaypoints(), OnFinishWaypoints(), waypoint.Object.Speed = 10;, Waypoint.Object.turnSpeed = 10;, Waypoint.Object.Damping = 5;, Waypoint.Object.startFollow = True;
function OnFinishwaypoint()
{
Waypoint.Object.startFollow = true; // object loop if get the last waypoint.
}
This is just an example:)
The real issue is that Unity is a VDE—a “Visual Development Environment”.
The trick is making the interactivity—the code—visible in some way, so that you’re not having to jump out of Unity to mess with scripts. This isn’t a trivial problem to solve. Finding a way to overlay Finite State Machine connections over an arbitrary entity in a 3D scene is difficult.
Take the 3D Platformer Tutorial (also known as “Lerpz Lives”. It’s in the Resources section.)
A GameObject can have multiple scripts attached, in any Mono-capable language. If I click on the Lerpz character in the scene, I don’t get any feedback about how that character interacts with the robots, with the platforms themselves, with the jetpack… with anything. The interactivity is completely opaque. It’s just another asset. I have to open up each attached script in turn and read it myself to work out what’s going on. This isn’t even slightly visual.
And yet, it’s that very interactivity which defines a game.
Note that this applies to all VDEs, not just Unity: all AAA-capable engines have the exact same problem. Yes, even those which use “Visual” scripting! All you’re doing there is removing the syntactic sugar; the scripting is still going on. And scripts are a poor representation of a Finite State Machine anyway. As long as you’re only showing one script at a time, and relying on the developer to parse each script in his head to work out what it’s interacting with, you’re doing it wrong.
A solution to this issue is going to be hard to come by. I have a few thoughts on the matter, but even my 3D Scripting system suggested earlier is only a partial solution at best.
Rather than stop here, I’ll describe a possible alternative:
My view is that a State-focused UI makes the most sense.
Each GameObject should have both built-in and Custom States. (All animatable Properties in the present UI would be States in my UI.)
The built-in States would be those related to the various engines—Physics, Lighting, Rendering, etc.—while the Custom States would be those which represent the GameObject in your game and are defined by you. E.g. “Character Health”, “Current Weapon”, “Ammo”, “Jetpack Active”, “Inventory”, etc.
In addition, you’d have Event States—“Scene Update”, “Controller State”, etc., which link the GameObject with system-wide States such as the status of the input controller(s), the renderer’s refresh cycle, application status, and so on.
Rather than attaching scripts to GameObjects, you would attach scripts to each of these States. The States would appear when you selected a GameObject in the Scene, either directly in the Scene in the form of interactive widgets, and / or somewhere in the Inspector. In the latter case, a button would be displayed alongside each State, which would change its appearance when a State Change script is attached.
Right-click on the “force field” part of the 3D Platformer Tutorial’s scenery and up pops a menu containing the built-in States, including those related to the texture’s UV coordinates. Click on it to add a 3D Script to animate that texture. Next time you right-click on that force field, the “Texture UV” State would be at the top of the menu—along with any other States that have scripts attached—making it clear that this State is now interactive, as well as making it easier to get to the visual script to make further changes.
At the very top of the pop-up menu is a “View All Scripts” entry, which switches to the 3D Script window showing all the States and Scripts, with lines linking those which talk to each other, and off-screen lines showing connections with States of other GameObjects. Zoom out and all those linked GameObject also appear. Zoom in on one of those and you get the same “All Scripts” view for that GameObject. With this, you’ll be able to follow all the interaction “wiring” in a visual 3D diagram, rather than having to pore over each script and interpret it yourself.
There are a lot more optimisations and details I could go into, but this post is already long enough, so I’ll shut up now.