Java Program Uses Neural Networks To Monitor Games

tr0p writes "Java developers have used the open source Neuroph neural network framework to monitor video game players while they play and then provide helpful situational awareness, such as audio queues when a power-up is ready or on-the-fly macros for combo attacks. The developers have published an article describing many of the technical details of their implementation. 'There are two different types of neural networks used by DotA AutoScript. The first type is a simple binary image classifier. It uses Neuroph's "Multi-Layer Perceptron" class to model a neural network with an input neurons layer, one hidden neurons layer, and an output neurons layer. Exposing an image to the input layer neurons causes the output layer neurons to produce the probability of a match for each of the images it has been trained to identify; one trained image per output neuron.'"

Comments

Huh.

[Count Fenring]

Probably no one cares, but that's the wrong "queues" there. They mean "cues."

Re:Huh.

[jonaskoelker]

Probably no one cares, but thats the wrong "queues" their. They mean "cues."

Broke that for you.

Re:The '90-ties are over

[Anonymous Coward]

I prefer ties from the 1960s.

Hilarious Overkill

[phantomcircuit]

So they designed and wrote a neural network for the sole purpose of identifying a limited set of icons? Seriously?

They could have done this using conventional methods that would be significantly faster. Me thinks someone was just doing this for entertainment.

Re:Hilarious Overkill

[julesh]

multi resolution analysis perhaps? an example of this method is wavelet decomposition.

Which is even more processor-intensive than a moderately sized neural net.

Re:Hilarious Overkill

[mcvos]

IN JAVA. Speed was obviously not in the design criteria.

The '90s are over. Java is now one of the fastest languages around.

Re:Hilarious Overkill

[daid303]

Except on everything not x86. The speed you currently see on desktop/server java is only accomplished by very good JustInTime compilers. Which are tweaked for x86. So everything else runs java like crap.

http://en.wikipedia.org/wiki/ARM_architecture And that includes a few bilion ARM prosessors used in mobile phones. Sure they can run java, but it's nowhere near as fast as C.

Java is nice, but the 'runs everywhere' feature is the least interesting one of them all. I can run an emulated a full blown x86 on a 8bit microcontroller, but that does not make it useful.

Re:Hilarious Overkill

[mcvos]

Is your application CPU-limited?

No, it's developer-limited. For most applications, development time is a bigger issue than execution speed. Only for very heavily used low-level routines (OS stuff, graphics libraries, VMs, etc) is it really worthwhile spending extra effort on extreme optimisation.

If so, is it *the* fastest language?

I don't have any recent benchmarks, but I remember that back in the days of the Java 5 JVM, Java is about 10% slower than equivalent C++, which is pretty good. But since then, JVMs have gotten quite a bit faster. It would surprise me if Java was not on at least equal terms with C++ now, alhough highly optimised low-level C is still going to be faster. But that's also extremely tedious to code.

Those are the questions one should be asking when picking a programming language.

No, the main question you need to ask when picking a language is if your code is going to be maintainable, and how expensive you can afford your maintainance to be. That's still the main timesink in development.

If your application is limited by the CPU, only the fastest language, C, will do for some routines. You may even consider using assembly or machine-optimized code such as Atlas

You accidentally hit the nail right on the head there: C is not necessarily the fastest language, highly optimised custom assembly is. And any language is only as fast as it can be if the programmer knows what he's doing. Some language do more for you to make optimal code easy to write than others.

Java development, in my experience, is more laborious than Python or Ruby. Unless you have big teams of developers who must work close together, I wouldn't recommend Java for anything.

Oh, I agree, Java stopped being an easy development language quite some time ago, and moved to the side of the fast execution languages. This is also why I switched from Java to Ruby. However, I just might switch to Scala because recent JVMs are so incredibly cool. The power of Java these days is more in the awesomeness of the JVM than in the language itself.

Even so, there is an enormous amount of support for Java. It is by far the biggest language for enterprisey server stuff. I think there are as many webframeworks for Java as there are for all other programming languages put together. This is one of the big stengths of Java, but at the same time, this architectural overload is also one of the major hurdles for starting in Java.

However, my point was that Java is pretty fast, which it is. If speed is an issue, Java can be an excellent choice (unlike Ruby, for example). If speed is the only thing that matters, then highly optimised C or assembly is really the only option.

Neuroph look pretty cool

[physburn]

As a programmer, Neuroph looks like pretty good implement of Neural Networks, it handers most of the network types, Got built in graphic view of the output. Look nice, but which like as not, won't help, because you can rarely debug a neural network by looking at it.

I've use neural network and genetic programming a few time, in work. Its completely different to normal programming. Instead of understand a problem completely, and write a structured solution to the task. You get a network and try and train it until its output matches what you think the output should be, no programming involved.

Re:How about NO image recognition?

[happylight]

It's an external program that doesn't have access to the game's internal data structures. Basically it's a bot without hooks to the game and makes decisions solely by looking at the screen.

Re:How about NO image recognition?

[Moraelin]

As someone who's been writing external trainers for games for years (though admittedly it was some years ago), I can assure you first hand that accessing a game's internal data structures is indeed very possible.

And even if I couldn't find that boolean, I'd at least try to hook the point where it tries to draw that icon.

The idea of using image recognition on the screen is so horribly inefficient a method... I suppose it could be used if absolutely nothing else works, but really that's about it.