Erm, read the Uke-bot threads. It's already done. (Albeit a bit simpler due to not having proper inputs on Uke's part)
Problem is, to use Neural Nets you need I/O. Once you get I/O, it'll be pretty easy.
Also, look for NERO the game. It's a game based around Neural Nets and training them. Just playing it and understanding the mechanics made NN's simple for me. : )
for i = 0,19 do
for x,y in pairs(get_joint_info(enemy,i)) do
Although, maybe you can train it from your own actions?Ok well I have a little experience with NN but not so much with Tori and the lua system so maybe people can answer some of my questions and we can get something done.
The SDK provides the ability to get information about the world state (such as joint position for either player, damage), so I dont know what SSJokker is talking about when he says there is no I/O: use LUASOCKET!!!!!!!
Luasocket is a lua library which will enable you to send UDP packets back and forth to JNEAT (a very nice and modular java neat implementation) which is what does the heavy lifting for you.
Heres the bottlenecks to getting this thing working as I see it:
NEAT is very hungry for fitness tests. To get a reasonable solution it needs many generations of fitness tests; each generation will have a population ranging from 100s to tens of thousands.
That means with an initial pop. of 1000 controllers, 20 generations in we require over 20000 matches of Toribash to take place.
Getting the information from Toribash to JNEAT isn't the problem here, its getting a reasonable amount of tests done in a very limited timespan.
Another thing occurs to me: NN fail when they are applied to finding a complex solution right off the bat.
To make this work well, the best bet is first teaching the NN something relatively simple, like not falling over, then moving up to walking, then moving up to hurting the enemy. That means we need our fitness tests to become progressively harder once one of the neural nets stumbles upon an optimal solution.
You can't use separate libraries with TB Lua. It's restricted. Or at least used to be when I wrote that post saying there's no I/O. At that time you couldn't write any files at all.
Also, JNEAT isn't exactly the best solution. Making your own, specifically for TB, would be better.
I was under the impression that you could import libraries in Lua but I didnt know this was restricted in TB (obviously I am a beginner at TB which is why I'm trying to get some help). Still, sockets are only one way of interprocess communication.
??
Making my own what?
Do you even know what exactly NEAT is? It's just an algorithm for evolving neural nets which happens to be fast and very general purpose. Theres newer iterations on that theme (for example CPPN/HyperNEAT which uses arbitrary activation functions and models neural nets along multidimensional substrates) but those are not necessary to make a good Tori AI.
JNneat is already made, it works and its proven.
Whats more, it only requires the code for the fitness test to be plugged in.
That means all I need to get this working is some way of communicating lua function values to JNEAT.
You said theres file handling in TB now, right? Well I can easily write some java code to communicate to TB through a file.
Can you tell me how to/point me to a link explaining file handling in TB's implementation of LUA?
Making your own neural net handling script. Made entirely in Lua. Trying to basically integrate Java into Lua will NOT work. It will simply bug to hell.
File handling in TB Lua is like in any kind of Lua, however restricted to the data/scripts directory.
Lua is too slow to be of any use to JNEAT, and would take AGES, especially seeing as how you'd have to actually play thousands of games to train even the most basic thing.
Also, you'd have over a hundred inputs to the neural net, the hidden layer would go over a thousand, and the output would be 21, being the joint states. It's not plausible to make something like this. It's been tried. By me. You won't be able to do any better until some restrictions placed in Lua have been removed.
Wait, theres more! What's that you say?? Over a hundred inputs is too much?? How did these guys use 280 inputs then? Not only that, but they did all of their fitness tests in real life using a physical robot!!! It took them roughly 2 minutes of real life time for a succesful fitness test and yet using NEAT they were able to evolve a controller which can succesfully drive a car
http://nn.cs.utexas.edu/project-view.php?ProjID=128