browser to unity communication and eval() command? for 1.5?

Could you give me an update on these two features for the new web players and 1.5?

Browser to unity communication and back...

Javascript eval() command, such that someone can enter a string command from the browser, and then it will be evaluated by the compiled script on the fly.

Lots of uses for this...
both flash and shockwave have it.

Thanks,
Dan

 

Flash and shockwave can because their Javascript implementation is interpreted, which means that everything for running javascript is included in the player already.

This is quite a bit harder for Unity Javascript because it is a compiled language. The code is compiled into .Net bytecode and the player only needs to be able to execute the bytecode and knows nothing about the original language. Supporting eval would mean that the entire JS compiler has to be included in the player.

A solution would be to create a custom intepreter for your application. That way you have better control of what the user code can do based on the features you add. If writing an interpreter from scratch sound daunting, or if you have better things to do with your life, you could use an intepreter written by someone else... Like this one I found written in C#: http://www.paxscript.net/

 

eval() makes it really easy to use the browser as an interface to unity. Let's say netflix wanted to build a 3d store, or a stadium wanted to show you the seating arrangements from any point of view...
Or you wanted to have a game where people could write in their own function or commands to control characters or objects.

eval() allows code from the user written as strings to be evaluated in the program for on-the-fly changes without handlers. All the user has to do is send a string from a drop down menu to Unity and unity will eval() the string into real code.

So let's say a person wants to load up a car name it "Bob" and then adjust the physics for "Bob".

All the person has to do is write.

sendToPlugIn(eval(Bob).torque=10) without having to write a handler to handle every command the user can think of to change.

Or if a person wanted to write an expression to be evaluated to control the motion of an object -- let's say the expression is Bob.position.x=Math.sqrt(sin(x)). The user can write this in a textbox in the browser then send it to the program which will adjust the position of bob to the equation.

In all cases it allows the user and the program to write commands into itself without pre-defined handlers.

I think this would be really useful for web applications that use the browser as an interface and then interact with unity.

It also allows internal code to write more code. Which is ultra-cool for a game.

A user could choose how to fight an enemy with their own behavior by typing in a series of commands from the browser. These would be placed into a loop and evaluated during runtime.

I don't know unity code, but something like this could be sent from the browser and interpreted by the eval() statement as a real command during runtime.

sendToPlugIN("user.position.x=10;user.animation=attack.start;user.delay(100);user.animation=rest.start")

Anyway there are lots of things to do with the eval() command. But I think the person above is right that it may not work with pre-compiled code unless it can see new code?

Unless the code is sent through a fast compiler or something and is aware of previously compiled code and global variables.

Dan

 

I found a simple eval library written in C# that can interpret c# and vb expressions without using the .net compilers.

http://www.gotdotnet.com/workspaces/workspace.aspx?id=3af68b43-8dba-41ca-8080-0390bb58cff1

 

I previously used a 3D web-plug-in called Anark. They Javascript communication with the plug-in did exist, it was somewhat simple, but was still powerful and was used for many reasons.

Basically instead of an eval() approach, it had a simple method and a simple event.

The method could be called on the plug-in by javascript in the browser and it looked like this:

plugin.internalCommand(command, param);

Both arguments are strings. This would invoke an event inside the scripting environment with both string arguments as parameters of the event object.

Also there was an event that it could invoke that the browser and javascript could capture:

player.onExternalCommand(command, param);

Again both arguments are strings. This event could be invoked inside the scripting engine by calling a method and passing two strings two it.

I agree that string values are quite simple, but they are also quite open and in that sense are quite powerful. Not ideal for every situation, but very broad for many situations. This contract is also not entirely difficult to implement. Basically you can be notified of the command inside the scripting engine when javascript passes two string values, and you can write your own interperter of those string values and what they mean to your in-game scripts.

And again this was a critical feature to allow people to create 3D content that interacted with the web and its elements as a single unified application.

Just another slightly different approach to the same thing.

Also for clarification, the .NET runtime contains the full .NET language compilers. In other words the runtime is also the compiler. As far as I know Mono should be the same as the MS implementation. You can pass source code to classes in the System.CodeDom namespace and compile source code on the fly in any of the .NET languages. It is also possible to create language-agnostic code out of CodeDom classes and then tell the code structure to produce text source code in any of the .NET languages automatically for you - so the reverse direction. I am assuming this is actually how Unity does its script compilation.

In that sense as long as you could direct string values into the plug-in, you could write your own script compiler similar to Unity's implementation, but interfacing with your script objects. Of course you would have to define your own contract, but it would be quite powerful - as well as dangerous heh.

In all fairness I should also not try to give the impression that implementing something like that for a plug-in is trivial, because it is a fair amount of effort. In terms of the many other features that are waiting to be added to Unity, it seems to me like it would be a lot lower in priority.

 

Unity does not embed the entire .NET runtime with built games in order to reduce the size of the games. Thus non-essential libraries and tools such as the compilers are not included.

No. Unity simply invokes the command line compilers with the script files as arguments.

 

Ok well that is good to know. I was inquiring a while ago about the Mono implementation with Unity because I was curious to embedd the runtime in my own projects, and also did some research through Mono resources.

At the time on the Mono site on their pages about embedding the runtime, they were basically saying only a few people had successfully discluded certain libraries/namespaces and that there was no clear cut way to do it. And the impression I got from the Unity responses was that the full runtime was embedded. So I apologize I've been very behind in tracking the progress.

But also just wanted to say I am aware of people compressing the entire Mono runtime down to ~3mb. And I have also worked with the Microsoft side of .NET quite extensively, and they have a particular installation package you can include with your installer projects that installs the entire .NET runtine im 2.3 mb. I know the normal download is 20+mb so you are right, but it is also possible to compress the same binary of that size to a matter of a few megabytes. Not that it necessarily means anything to this thread, but I just wanted to share that it was possible.