Developing an AI externally in Java

[borg83]

Hi @ all (particularly the developers )

I'd like to develop a "good" AI for the game. Therefore i managed to check out & compile the code with a very basic AI, which just builds bus-routes inside towns (you can see some screenshots here).
However, the last time i coded s.th. with C++ is about five years ago (3D games with DirectX), nowadays i develop enterprise applications with Java. And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS and a lot more

So my idea was the following: Let the game talk to an "AI Server" developed in Java via Sockets (loopback interface). The game would ask the server what to do, and the server either says "give me information on tile xy" or "build road parts NW and NE on tile xy". Or - if the AI server does some pathfinding stuff - it could say "nothing to do atm, i am busy".

What is your opinion of this? Could this work?

[VPN-User]

Urghs, that would use a _huge_ amount of resources...

Bad idea IMHO

[Rubidium]

And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS :!: and a lot more :cry:

They are actually in available in C++ too.

On the implementation point-of-view, you would need a fairly large amount of wrapper code for your sockets to be able to call all the functions you'd like to call.

Technically you idea would be possible, but the current AI system gets called every tick and when the AI is done, other parts of the game continue. When you are going to do this with sockets you need to look very carefully at the synchronisation issues it is going to give. Especially because you do not want to query the map when OpenTTD is calculating all the changes it needs to do in the map for the given tick.

Urghs, that would use a _huge_ amount of resources...

That depends on the way it is implemented. Yes, it would take a few MiB more than C++ only, but he can do rapid prototyping with Java and when his AI works as expected, he can port it to C++.

[brupje]

Urghs, that would use a _huge_ amount of resources...

Bad idea IMHO

On the other side, the AI would run in a different thread, and therefore better on a dual core machine.

But I wouldn't transfer each tile, but rather the entire map once and updates as all clients get.

If you know java c++ can't be that hard either, it has class inheritance too and some sort of strings, and look similair but a bit different

[VPN-User]

On the other side, the AI would run in a different thread, and therefore better on a dual core machine.

Threads are possible in C and C++, too. Yes, they' re platform dependent.

But coding an AI that is only really usable with dual-core machines should not be the goal I think.

[borg83]

And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS and a lot more

They are actually in available in C++ too.

The powerful collections-API, too?
Having all this LinkedList, HashSet stuff etc, sorting (Collections.sort - it uses a merge sort) would reduce my development time by MONTHs...

On the implementation point-of-view, you would need a fairly large amount of wrapper code for your sockets to be able to call all the functions you'd like to call.

That's right. And i would need some kind of a network protocol (at the application layer), too. And probably much more...

Technically you idea would be possible, but the current AI system gets called every tick and when the AI is done, other parts of the game continue. When you are going to do this with sockets you need to look very carefully at the synchronisation issues it is going to give. Especially because you do not want to query the map when OpenTTD is calculating all the changes it needs to do in the map for the given tick.

That's the point where i ask you, the veterans I was guessing, if i use blocking network calls within the AI loop, then the game will just stuck if the method calls don't return fast enough. But the game would not do any other calculations.

But coding an AI that is only really usable with dual-core machines should not be the goal I think.

Of course not. But what is my goal anyway?
Up to now i just checked out the source anonymously and made some changes, just for me. I don't think that a game which requires an AI server being started seperatly (plus: this AI server requiring a java runtime to be installed on the system) would not be accepted by many people...

[brupje]

On the other side, the AI would run in a different thread, and therefore better on a dual core machine.

Threads are possible in C and C++, too. Yes, they' re platform dependent.

But coding an AI that is only really usable with dual-core machines should not be the goal I think.

that was not in reaction of the capabilities of c++, but a pro on the AI as client idea.

[XeryusTC]

I'd like to develop a "good" AI for the game. Therefore i managed to check out & compile the code with a very basic AI, which just builds bus-routes inside towns (you can see some screenshots here).

I managed to do this once too with the help of OpenTTD.gpmi (do a quick google for libgpmi). My AI however was not very intelligent as it would first spend all it's money and then keep doing that until it was making money again. I however could never complete/advance my AI as there was a bug in OpenTTD.gpmi.

Threads are possible in C and C++, too. Yes, they' re platform dependent.

Not if you use POSIX threads for win32. POSIX is the standard for threads, the only OS that doesn't support it natively is windows AFAIK. If you use the library on the site I linked too you can use the same API on most OSs.

[Rubidium]

POSIX is the standard for threads, the only OS that doesn't support it natively is windows AFAIK.

Also Amiga, MorphOS and PSPs do not support threads (when I look at OTTD's thread abstraction layer).

[DaleStan]

The powerful collections-API, too?
Having all this LinkedList, HashSet stuff etc, sorting (Collections.sort - it uses a merge sort) would reduce my development time by MONTHs...

Yes. The STL is a beautiful thing. And you don't have to cast everything back from an Object every time you want to do anything useful with it.

And if you need months to write a merge sort, I think you have bigger problems than the lack of a standard library merge sort.

[VPN-User]

And if you need months to write a merge sort, I think you have bigger problems than the lack of a standard library merge sort.

Hehe, that one was really nice

[borg83]

And if you need months to write a merge sort, I think you have bigger problems than the lack of a standard library merge sort.

ARGH!!

not months for the merge sort, but for an ai without a mergesort (or anything else that helps when i need to rate towns, possible places for stations etc)

[phil88]

Surely the performance hit would be too substantial, I mean, requesting a java server for info of what the AI is going to do will just create un-necessary lag between the 2 systems (OTTD and the AI). Re-writing the current AI, in C++ would be a much more efficient solution.

[Rubidium]

Surely the performance hit would be too substantial, I mean, requesting a java server for info of what the AI is going to do will just create un-necessary lag between the 2 systems (OTTD and the AI). Re-writing the current AI, in C++ would be a much more efficient solution.

1) Why would the Java (Server) implementation be so much slower, especially when you use JNI? Why is everybody asking for script language inclusion for AI and other stuff when Java is one of the fastest 'interpreted' languages and you are claiming it is too slow?

2) Rewriting the current AI should not be done. A new AI should be written from scratch.

3) He asked whether it could work, not whether it would be fast enough to work on all computers. The (possible) slowness is not a major concern when starting to write the AI, it becomes a concern when the AI actually has much intelligence (i.e. the AI is nearly finished). At that stage one might consider rewriting it in a non-memory-managed/non-interpreted language.

[phil88]

Surely the performance hit would be too substantial, I mean, requesting a java server for info of what the AI is going to do will just create un-necessary lag between the 2 systems (OTTD and the AI). Re-writing the current AI, in C++ would be a much more efficient solution.

1) Why would the Java (Server) implementation be so much slower, especially when you use JNI? Why is everybody asking for script language inclusion for AI and other stuff when Java is one of the fastest 'interpreted' languages and you are claiming it is too slow?

2) Rewriting the current AI should not be done. A new AI should be written from scratch.

3) He asked whether it could work, not whether it would be fast enough to work on all computers. The (possible) slowness is not a major concern when starting to write the AI, it becomes a concern when the AI actually has much intelligence (i.e. the AI is nearly finished). At that stage one might consider rewriting it in a non-memory-managed/non-interpreted language.

1. My point wasn't that java is a slow language, it was that having 2 separate things (AI & the rest of the game) is unnecessary, complicates things and the communication between the two parts will slow down the game.
2. That's what I mean, rewriting from scratch.
3. I agree, I was merely stating that, to save development time, it might aswell be developed in C++ off the bat.

[iNVERTED]

However, the last time i coded s.th. with C++ is about five years ago (3D games with DirectX), nowadays i develop enterprise applications with Java. And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS and a lot more

Pure C is the fastest compiled language around. Java is one of the slowest.

How about you get over your fear of GOOD programming languages which don't use stupidlyLongVariableAndFunctionNames and just program in C?

Last I checked, programming AI is a case of problem solving, and the difficulty of problem solving is hardly affected by the programming language you use.

[Rubidium]

Pure C is the fastest compiled language around. Java is one of the slowest.

Do you have proof for the first statement and the second is not true; it is interpreted bytecode language which is (almost) by definition faster than any non-bytecode interpreted language. Especially because Java is compiled during runtime to machine code, something you do not see with most interpreted languages. So yes, it might be slow when bootstrapping, but after a while the speed difference between a C and Java implementation without GUI is not that significant as you claim it to be.

Last I checked, programming AI is a case of problem solving, and the difficulty of problem solving is hardly affected by the programming language you use.

I agree on that, so one must use a simpler (for the author of the AI) language when solving the problem. Once the problem is solved you think about making a nicely designed version in a possibly faster language; starting such a big piece of code with a nice design from the start is pretty difficult when you do not know exactly what problems you have to solve.

[DaleStan]

Pure C is the fastest compiled language around.

Oh? I would have guessed that a competent human could write assembly that works faster than the corresponding C code, regardless of optimization settings. If there's no other reason, the human knows exactly what aliasing is happening, and only has to allow for that. The human can also do interesting incantations involving self-modifying code[0][1], changing the return address, and other bits and bobs that most compilers aren't smart enough to pull off.

[0] Why use a variable to store the return from malloc? Keep track of the addresses where the value is used, and write the appropriate immediates in those locations when malloc returns. Sure, it's more code, but reading an immediate is faster than reading from memory, and doesn't consume a register.
[1] Why test the same runtime-constant value on every tick? Test it once, and then overwrite the test with the appropriate unconditional jump.

[borg83]

Last I checked, programming AI is a case of problem solving, and the difficulty of problem solving is hardly affected by the programming language you use.

And my opinion of this is, that the difficulty of this task is extremly affected by the programming language I use
You posted the reason for it yourself: Programming an AI is about problem solving, so I'd like to concentrate on the problem itself, not on problems caused by the programming language. And "stupidlyLongVariableAndFunctionNames" help me to understand what's going on

How about you get over your fear of GOOD programming languages which don't use stupidlyLongVariableAndFunctionNames and just program in C?

And how about you get over your fear of new technologies and just use them, if appropriate?
Not only am I going to develop an AI with Java, but finally I am going to design the AI in a model and then just generate the Java code... Frightening, isn't it? Generated code, brrr....
Imho some kind of a) a state diagram and b) activity diagrams would really be great to design an AI on a high level of abstraction.

3) He asked whether it could work, not whether it would be fast enough to work on all computers.

That's the point, and you said that it would be technically possible. So I'll give it a try and post the results in this thread.

Meanwhile you can discuss the pros and cons of C(++) vs Java. But always remember the saying: "Meine Meinung steht fest, bitte verwirren Sie mich nicht mit Tatsachen" ("My opinion is fixed, please do not confuse me with facts")

[SmatZ]

The human can also do interesting incantations involving self-modifying code[0][1], changing the return address, and other bits and bobs that most compilers aren't smart enough to pull off.

Not only because compilers are not smart enought, but because they have much less knowledge about the code.
As a developer, you know some variables are only in some range etc.
Also, you know where should you optimise by allocating register, unrolling, ... some of this can be done by using profiling for compilation.

Imho some kind of a) a state diagram and b) activity diagrams would really be great to design an AI on a high level of abstraction.

Yes, some people spend time drawing those things (and are paid for that), while others have it in their head and just type the code...

edit: yes, some diagrams may be useful when more people need to look over some code in a short time
(personally, I dislike overusing of terms like 'abstraction', 'object oriented attitude' etc - as it comes with drawbacks because the code is more complex and harder to optimise)
btw, is there anything that cannot be done in standard C ? There have been use 'virtual functions' - they are hidden in *_procs arrays.

edit 2: actually, I was considering writing some guide how OTTD code is organised... some diagrams would be part of it for sure