[Help] Virtual Circuitry/Program implementation

Hello everyone,

I have an interesting feature I wish to implement and was hoping for some input on the matter. The idea in question would be a virtual circuitry system similar to those Android App projects that for the life of me I cannot remember the name of. This would allow the players to literally program their players' functionality. Basically it looks a lot like this:


The problem in question is that I need a way for multiple players to put these code blocks together, compile the code, and run it on their own player all during runtime all over a network. The app would be server authoritative and only player inputs would be sent to the server, so it is not necessary that each client has each others' working compilation of code. Only the server. I have found a few ways that I can possibly implement this, but I hope for some input as to which route to take as this entire system would be called on each Update() call, so it cannot be a very expensive system and needs to be relatively fast.

Option 1: Runtime Compilation. I found out that you can compile code using the CodeDOM and run it during runtime. I have not done much research on the topic yet, but at the moment I dont know if it will offer me the level of dynamic code injection that I need for individual game objects.

• Issue: Dont have the faintest idea how to implement this
• Issue: Will it allow me to create DLLs in which I can run on individual classes, or will I be stuck trying to call some sort of method which will be the same for all calls? I need some way to differentiate the difference between Move() on player 1, and Move() on player 2.

Option 2: Individual Classes / Delagates / pure static methods. I could technically write the entire system and hold all of the code blocks within some form of a tree to pass in inputs and outputs of each block. I imagine it would be a headache to code and test the thing. I could either call static methods, or have a seperate class for each type of block which will do the logic of the block

• Issue: How to send to the server over the network - mainly, what links to what?
• Issue: If I use the Delagate / Class method, would things slow down trying to wrap things like a simple "If" statement to a noticeable level?

Option 3: Embedded Lua. I could have some function "Build" which would generate Lua code to run on the objects. Since Lua is not only my favorite language, but its also interpreted, so I can just send the code to the network via a WWW call to a server through plaintext and run it.

• Issue: Have no idea how well the embedded lua project works for Unity. Lua is pretty fast, but I don't know how well the interpreter is coded.

Thanks for any input on the matter in advance.

 

bump

 

I've started projects like this, but never found the time to actually finish it. In my experience, coding all that UI is significantly more time-consuming than coding the logic of the blocks themselves. A runtime interpreter is quite simple, especially when you're starting with a structure like this, that is basically an AST (abstract syntax tree) already — no need for parsing. But, enabling the dragging, snapping, and auto-resizing of those blocks is a pain in the neck.

 

Someone else was asking about this a while ago... it was here:
http://forum.unity3d.com/threads/scratch-mit-algorithm.355370/#post-2302908

Technically yes. But it will only work on PC/Mac/Linux first and foremost.

Also, any time the program changes you'll need to unload and reload the new compiled program. This can be very slow.

Furthermore, the compiling is done from either IL or any of the existing languages. These nodes would have to be parsed to that language and then compiled. And as a visual programming language, it's not exactly one to one.

Honestly, I would do this. You'd have to write all the nodes to represent the structures in the tree, and the code it relates to. Just in this case you interpret it at runtime rather than compile it and load it into the Application Domain. Changes can be reflected very easily.

This is just option 1 again, but instead you interpret Lua instead. You still have to parse the graphical nodes to Lua. This is going to be hell to do.




I agree with JoeStrout, the graphical portion is going to the bulk of your work. The nodes are easy to put together.

 

Noted. I didn't have a design for the UI similar to the picture in my original post, but was just a way of expressing the intent of the system. The actual UI in mind would be similar to putting integrated circuits "gates" on some sort of canvas and connect the "pins" to one another to simulate input/output. That should cut down on most of the complicated stuff. Basically the UI equivalent of a Flowchart with pre-defined nodes to link to. I will certainly look into AST's as during my thinking on this I'm currently trying to solve handling the possibility of infinite loops within the system. I figure there will be a single entry point to the "circuit" and any sort of loop "gate" would have some artificially imposed limitations on size of its elements it is allowed to loop through per tick.

Noted. I was planning on the code being sent to the client once they join the server, and any code/circuit changes must be done on the local client before joining. That would solve the problem mentioned about re-compilation, but seeing as I have no experience in this sort of thing it was more of a question of whether or not I should invest some time and research into the matter if it proved that this approach had a better standing over the other 2 options.

I will try Option 2 first then, as you have suggested. If it doesn't work out, or if the UI is too complicated, ill go with Joe's suggestion and just go with a runtime interpreter such as Lua and make some bindings to call from within a plain-text script file that is generated.

Thank you both for your input.