For the last few weeks I’ve been working on allowing bots to be programmed in-game through javascript. Right now, you can use javascript to create simple commands such as jumping and moving to a location. I’m thinking about using it to create some kind of base defense game.
https://.com/watch?v=Sbdo91HKjsA
Right now, the javascript is being run by V8 on a seperate thread per bot to prevent the game from freezing when coding an infinite loop. I’m planning on trying out one seperate thread to command all the bots together.
What you want to do with javascript is V8 on isolated thread and limited APIs? That is an interesting topic to off-load computation on extra threads just like web-workers.
Hey, thanks again for making the plugin! Those pre-built DLLs really saved me a lot of pain of getting it up and running and your code helped me figure out a thing or two about what to initialize/deinitialize where.
I mainly run a seperate isolate on a FRunnable for a bot so that one bot getting into an infinite loop doesn’t freeze the whole game for the player. There are a few c++ functions that I expose to javascript that basically add commands to a list that is polled from the game thread. There is a loop in the run function of FRunnable that runs the script once and then keeps executing that main function every 0.1 seconds. If new code is given to the bot, the script is terminated, and will be recompiled and run with the new code at the end of the loop so I can continue using the same thread. Most of the pain of getting threads up and running was figuring out when to clean up certain things.
I just submitted a jam entry based on the players providing javascript. I wanted to use python instead (actually I really wanted to use F# or Haskell, but that was never going to happen), tried for a hour, but I was getting bogged down integrating and had to abort and go to javascript.
Obviously lots of issues to resolve going down this path, debugging, handling script errors, handling insane code.
Worth looking at twitch. I’m not 100% sure what went wrong, but he did things I did not even try and that is my fault for not testing it more.
Definitely I would slap on a “scratch style interface”, it would remove heaps of the issues. I thinking I could create a unreal specific google blocky plugin.
Will check it out once I have the time. I think it’s very easy to overlook something with these kind of things, that’s also a part that makes it interesting.
A scratch style interface would definitely make the game accesible to more players. I’m thinking of doing something like that at some point while also allowing javascript for those who don’t really like visual programming. Then write that stuff to javascript so that the experience is more the same. It only seems that the UI part is going to be a lot of work. For now, I’m allowing scripts to be loaded from file so that you can use any external editor that you like. I might try something turn based as well so that it’s more part of the flow to program, validate, then try a match. It will also prevent some timing issues that I foresee popping up in the future. Though, for now, I’m continuing with this base defense idea and see where that goes.
Thanks! The trick would be to make it easy to get in to while still allowing a lot of depth once you are a bit more advanced. Probably providing a lot of helper functions that will take can take care of some of the complicated things will help a lot with that. Making it turn based would probably help as well since you don’t have these kind of issues such as: while the script is running the world is changing (since it runs on a seperate thread) and when a bot has executed his script he hasn’t necessarily performed his action yet (unhandy for when wanting to coordinate with another bot).
Yeah something like that, well done! It completely makes sense for your game since I think there the programming can have a nice touch somewhere on the background.
I think you can’t really solve that “halting problem” directly. You could restrict yourself to the scratch interface only but then it’s still hard to prevent some scripts that simply run very long. What I’m doing is putting the script for each bot on a seperate FRunnable but that will not scale for your case. You might put all the scripts on just one FRunnable but that will make all script stop if one runs forever. To fix that you could set a time limit on how long a script is allowed to run and terminate that script if it still runs after that time. Maybe notify the user that that script took too long to run (make the cannon point down for example) and just continue running all the other scripts except that one.
