Hi, Nope, haven't given up on it, just have midterms and other things to worry about for a while.

And you are quite right Rhaken! Training the NN to specialize in one game mode would generally mean that it wouldn't do as well in other game modes.

I dont see that as a bad thing though; if anything, I think training the AIs for specific goals and tasks would mean you could get progress in a reasonable amount of time. It also means that your specialized AI would do a hell of a lot better in its specialty than a generalized one would do at anything.

You are also right that online replays would be doable, but I imagine it being even more fun (when its more developed) trying to train it by fighting against it yourself.

Right now I'm using an autohotkey script I've made which acts as a server between toribash and jneat. Since I couldn't seem to trick lua into reading from named pipes and shared memory/sockets are right out (and since hampa hasn't got back to me yet), what I'm doing for synchronization now is having Toribash prepare the various input values on every turn, and append them to a file located on a ramdisk. When this happens, autohotkey is notified and eats up the line, processing it and passing it to jneat via sockets. Jneat performs the activation function for whatever neural net it's evaluating, and then sends the server script the output values. The server script writes them to a seperate temporary file, after processing them to a format readable by my toribash lua script. Finally, Autohotkey sends a spacebar keypress to Toribash to signal the next turn and a hook in TB sets Tori's joints to the values it reads from the temporary file. This happens over and over and over again, based on some criteria for what a good solution is.

The idea is, do it enough with the right criteria, and a really intelligent A.I. will come out.

Right now the fitness criteria I'm using is how close it can get to a really far point in 12 turns (of 10 frames each), which it seems to be performing reasonably well at after a few generations.

I can think of hundreds of variations on this that might be cool; for example, instead of fitness being how far you are from a point, what if fitness was based on how far an enemy's head was from their body; the solution you would probably find is an ai that rips off the head and chucks it hard.

You could throw any mod in and use it in your environment. So that means you can throw in your own models (I model in lightwave and modo so I can think of a few cool things to make, like half pipes, or maybe a pole vaulting set up). The possibilities are pretty endless I guess; if you can imagine a situation with an acrobatic ragdoll dude and some fixed models, you could make an ai for it.


Running this on my home computer is too slow to get a reasonable result overnight, but I'm trying to study the documentation for "cajo", which should enable me to speed things up by a million.

Cajo will make this interesting, because it will allow me to distribute all the requests for input values to as many copies of Toribash as I can run. Cajo is a framework for allowing java applications to communicate seamlessly over networks or computers. It lets you split up work between multiple virtual machines, multiple physical computers or some combination thereof. Since I have access to a quite a few core2duo machines at the computer lab, my hope is I'll be able to do some real results by splitting the work up between a bunch of machines.

i just gotta tell you, you cant import your own 3D models for a mod.
just the basic shapes(cube,cylinder,sphere, thats all).

*brain explodes at the size of this complex debate*

*Same as above*

Has anyone hit the text limit yet?

Me, twice.

Also, please return to the topic at hand and stop posting off-topic stuff. I'll delete further such posts.

Ok then, what's the current progress? Has it learned to rip ukes head off yet?

The results were not pleasing (yet), for a couple of reasons. If I explained exactly why, I risk going over the text limit and I doubt many people will read it anyway, but the short version is:
1. I haven't formulated the problem in a clever enough way
2. Theres been mad frustration trying to get my code to play nice with Toribash remotely on a network right now, so I'm just using my own personal computer as the sole number cruncher.

One point one:
Jok was exactly right when he said that the amount of inputs I was using was too much to start with; this is MOSTLY because NEAT (especially the version I had adapted, which was quite old) isn't a very good algorithm when the dimensionality of your search space increases. In simpler terms, this means that the more information you give it, and the more complicated the problem, the slower progress will be (like REALLY slow). It's also called the curse of dimensionality; there are ways to get around it, more on that later

Technical reasons for it being slow:
By default, NEAT starts out with a feedforward perceptron where ALL of the inputs are connected; this means that its not left up to evolution which sensors are important, since by default they are all connected; when your inputs are from orthogonal coordinates (like x,y,z triplets for joint positions, which I was using as inputs), this is very counterproductive to making good nets.

Another frustration I had was the version of NEAT I was using was coded by some italian guy about 5 years ago, and his code is terrible and fragile; its not even written for controller problems like many of the other implementations. Every time I changed something everything surrounding it would break, so I was rewriting so much stuff that I thought it was a waste of time to go further in that direction; I was better off starting from scratch and making it really good. I thought it would be trivial and easy to patch these existing bits of software together, but it looks like if you want it done right you have to do it yourself.

What I'm doing now/Where things go from here:

First; reducing the amount of inputs. You may have seen the threads/posts I made recently about joint extension and balance. Look at the way biological neural nets handle walking/locomotion; for us bipedal humans, its a matter of leaning forward to put yourself off balance, and catching yourself; you repeat the cycle to walk, so long as you don't lose balance completely and fall over. We use our sense of vision, balance, and of the relative positions of our body parts. You can even walk with your eyes closed, so in other words, all your brain needs to walk is information about Equilibrioception, and Proprioception. Those are big words that mean your sense of balance, and your sense of where your bodyparts are in relation to each other (like how you can touch the back of your head in the dark). Part of our balance system is also detecting the horizontal acceleration and the vertical acceleration so a neural net that is learning to walk should have access to those as well.

Its obviously going to be a lot easier for an artifical neural net to use balance and a sense of where its body parts are to walk, than to use x y and z values for the position of a joint. Instead of giving it 20x3 inputs (60 inputs is going to be SLOW), I can just give the neural net 25 inputs; 20 inputs representing the extension level of each joint, 1 input representing forward/backward orientation of the head, 1 input representing left/right orientation of the head, one input representing magnitude of horizontal acceleration on the head, and one input representing magnitude of vertical acceleration on the head.

The last input is feedback on how good the AI is doing (if we want it to walk, we should provide feedback on how close/far it is from its goal destination). This is to simulate the visual feedback we have to determine how far/close we are from an object.

Thats all our brain needs to walk, so it should be enough for my ai. 24 inputs is also a lot more feasible than 6. Not only that but what I've been doing for the past couple of weeks is studying multidimensional optimization algorithms and evolution strategies; it seems like there is a MUCH better approach out there that can bypass all these difficulties I've had.

I'm going to be writing from scratch my own implementation of EANT2; this is a similar idea to NEAT but it guarantees much better performance and generality; for double pole balancing, CMA-ES (which is a sub-algorithm incorporated into EANT2) was over 8 times faster than NEAT. By reformulating this Toribash problem correctly I think I'll be able to make it a lot more feasible. On the super plus side, once I'm done I'll be able to take my system and plug it into any game with a "score" value, and it should be able to spit out a good AI.

I've recently come back to IRC, so when I get a chance, I'll ask hampa if he could get you a copy of a limiter-removed, no-render, toribash, for development.

Also, from my own research, I have seen that what our brain does, instead of simply ordering the muscles, is use a secondary 'feedback' muscle, to let us refine our movements. There is a drug administered to some people that blocks the activity of this feedback muscle. One of my friends was on it, and I visited him about a day after getting it. He could move his hands, however he couldn't control them properly. IE: breaking cups with his hand, overshooting a handshake by a mile. That basically means even for the very advanced neural net we have in our brains, it isn't exactly easy to do the most basic task on its own.

Lowering the number of inputs is essential, and to do so, you could think about how you yourself judge your sense of balance. I normally use the angle of my shoulders, the angle my head is tilted at, the angle my chest is bent, hips, and knees. That means 8 inputs for angles only, and next would be relative height to the ground, and some speeds (like, chest, head, feet and arms). Speeds can be omitted if you replace relative height to global position.

So that would be 16 inputs per player at best. However, you can omit some joints of the ones I said, with the risk of having it not work best.

I haven't seen EANT2 yet, so that may be a solution, however if not, you'll want to figure out a way to optimize neural nets at the cost of actual performance, or simply find a new algorythm to use.

So you just need a new algorithm and a remote controller for PC over the internet? I've seen a few but they're all slow as hell. But I can wirelessly control my PC with my DS .
Some body functions are controled subconciously, and last time I checked, computers dont have subconciousness, or even conciousness for that matter. (I hate grammer)

Also I wanted to note some things that could cause some issues. Theres some sort of tension holding joints togeather that can stretch or contract to a certain degree. Like in that one chicken replay thing, or like in the following replay.
Small things like that will cause a problem, right?

You have my full support on this AI project.