Developing an AI externally in Java
Moderator: OpenTTD Developers
Developing an AI externally in Java
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?
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?
Re: Developing an AI externally in Java
They are actually in available in C++ too.borg83 wrote:And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS :!: and a lot more :cry:
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.
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++.VPN-User wrote:Urghs, that would use a _huge_ amount of resources...
On the other side, the AI would run in a different thread, and therefore better on a dual core machine.VPN-User wrote:Urghs, that would use a _huge_ amount of resources...
Bad idea IMHO
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
Re: Developing an AI externally in Java
The powerful collections-API, too?Rubidium wrote:They are actually in available in C++ too.borg83 wrote:And I really miss the concept of classes with inheritance, interfaces, java.util.Collection, STRINGS and a lot more
Having all this LinkedList, HashSet stuff etc, sorting (Collections.sort - it uses a merge sort) would reduce my development time by MONTHs...
That's right. And i would need some kind of a network protocol (at the application layer), too. And probably much more...Rubidium wrote: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 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.Rubidium wrote: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.
Of course not. But what is my goal anyway?VPN-User wrote:But coding an AI that is only really usable with dual-core machines should not be the goal I think.
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...
that was not in reaction of the capabilities of c++, but a pro on the AI as client idea.VPN-User wrote:Threads are possible in C and C++, too. Yes, they' re platform dependent.brupje wrote:On the other side, the AI would run in a different thread, and therefore better on a dual core machine.
But coding an AI that is only really usable with dual-core machines should not be the goal I think.
Re: Developing an AI externally in Java
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.borg83 wrote: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).
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.VPN-User wrote:Threads are possible in C and C++, too. Yes, they' re platform dependent.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
Re: Developing an AI externally in Java
Also Amiga, MorphOS and PSPs do not support threads (when I look at OTTD's thread abstraction layer).XeryusTC wrote:POSIX is the standard for threads, the only OS that doesn't support it natively is windows AFAIK.
Re: Developing an AI externally in Java
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.borg83 wrote: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...
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
-
- Traffic Manager
- Posts: 136
- Joined: 07 Jun 2002 08:43
- Location: Radolfzell at Lake of Constance in Germany
- Contact:
Re: Developing an AI externally in Java
Hehe, that one was really niceDaleStan wrote: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!!DaleStan wrote: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.
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)
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?phil88 wrote: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.
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.Rubidium wrote: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?phil88 wrote: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.
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.
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.
- Phil
Re: Developing an AI externally in Java
Pure C is the fastest compiled language around. Java is one of the slowest.borg83 wrote: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
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.
Re: Developing an AI externally in Java
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.iNVERTED wrote:Pure C is the fastest compiled language around. Java is one of the slowest.
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.iNVERTED wrote: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.
Re: Developing an AI externally in Java
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.iNVERTED wrote:Pure C is the fastest compiled language around.
[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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
And my opinion of this is, that the difficulty of this task is extremly affected by the programming language I useiNVERTED wrote: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.
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
And how about you get over your fear of new technologies and just use them, if appropriate?iNVERTED wrote:How about you get over your fear of GOOD programming languages which don't use stupidlyLongVariableAndFunctionNames and just program in C?
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.
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.Rubidium wrote:3) He asked whether it could work, not whether it would be fast enough to work on all computers.
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")
-
- OpenTTD Developer
- Posts: 351
- Joined: 03 Oct 2006 18:26
- Location: Prague, Czech Republic
- Contact:
Re: Developing an AI externally in Java
Not only because compilers are not smart enought, but because they have much less knowledge about the code.DaleStan wrote: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.
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.
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...borg83 wrote: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.
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
Last edited by SmatZ on 07 Mar 2007 19:35, edited 2 times in total.
Who is online
Users browsing this forum: No registered users and 7 guests