Developing an AI externally in Java

OpenTTD is a fully open-sourced reimplementation of TTD, written in C++, boasting improved gameplay and many new features.

Moderator: OpenTTD Developers

borg83
Engineer
Engineer
Posts: 27
Joined: 29 Jan 2007 22:28
Location: NRW, Germany
Contact:

Developing an AI externally in Java

Post by 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 :cry:

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
Traffic Manager
Traffic Manager
Posts: 136
Joined: 07 Jun 2002 08:43
Location: Radolfzell at Lake of Constance in Germany
Contact:

Post by VPN-User »

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

Bad idea IMHO :P
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Developing an AI externally in Java

Post by Rubidium »

borg83 wrote: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.
VPN-User wrote: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++.
User avatar
brupje
Transport Coordinator
Transport Coordinator
Posts: 288
Joined: 03 Oct 2006 07:17
Location: The hague, Netherlands

Post by brupje »

VPN-User wrote:Urghs, that would use a _huge_ amount of resources...

Bad idea IMHO :P
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 :P
VPN-User
Traffic Manager
Traffic Manager
Posts: 136
Joined: 07 Jun 2002 08:43
Location: Radolfzell at Lake of Constance in Germany
Contact:

Post by VPN-User »

brupje wrote: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
Engineer
Engineer
Posts: 27
Joined: 29 Jan 2007 22:28
Location: NRW, Germany
Contact:

Re: Developing an AI externally in Java

Post by borg83 »

Rubidium wrote:
borg83 wrote: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.
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...
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 right. And i would need some kind of a network protocol (at the application layer), too. And probably much more...
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.
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.
VPN-User wrote: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...
User avatar
brupje
Transport Coordinator
Transport Coordinator
Posts: 288
Joined: 03 Oct 2006 07:17
Location: The hague, Netherlands

Post by brupje »

VPN-User wrote:
brupje wrote: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.
User avatar
XeryusTC
Tycoon
Tycoon
Posts: 15415
Joined: 02 May 2005 11:05
Skype: XeryusTC
Location: localhost

Re: Developing an AI externally in Java

Post by XeryusTC »

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).
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.
VPN-User wrote: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.
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)
Image
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
Image Image Image Image Image Image Image
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Developing an AI externally in Java

Post by Rubidium »

XeryusTC wrote: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
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: Developing an AI externally in Java

Post by DaleStan »

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...
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.
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
VPN-User
Traffic Manager
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

Post by VPN-User »

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.
Hehe, that one was really nice :lol:
borg83
Engineer
Engineer
Posts: 27
Joined: 29 Jan 2007 22:28
Location: NRW, Germany
Contact:

Post by borg83 »

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.
ARGH!! :P

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
Transport Coordinator
Transport Coordinator
Posts: 267
Joined: 25 Jan 2007 23:26

Post by 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.
- Phil
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Post by Rubidium »

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.
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
Transport Coordinator
Transport Coordinator
Posts: 267
Joined: 25 Jan 2007 23:26

Post by phil88 »

Rubidium wrote:
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.
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.
- Phil
iNVERTED
Route Supervisor
Route Supervisor
Posts: 387
Joined: 24 Apr 2005 21:21
Location: Torquay, England
Contact:

Re: Developing an AI externally in Java

Post by iNVERTED »

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 :cry:
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
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Developing an AI externally in Java

Post by Rubidium »

iNVERTED wrote: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.
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.
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
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: Developing an AI externally in Java

Post by DaleStan »

iNVERTED wrote: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.
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
borg83
Engineer
Engineer
Posts: 27
Joined: 29 Jan 2007 22:28
Location: NRW, Germany
Contact:

Post by borg83 »

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.
And my opinion of this is, that the difficulty of this task is extremly affected by the programming language I use :roll:
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 ;)
iNVERTED wrote: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? :roll:
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.
Rubidium wrote: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") :D
SmatZ
OpenTTD Developer
OpenTTD Developer
Posts: 351
Joined: 03 Oct 2006 18:26
Location: Prague, Czech Republic
Contact:

Re: Developing an AI externally in Java

Post by SmatZ »

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.
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.
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.
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
Last edited by SmatZ on 07 Mar 2007 19:35, edited 2 times in total.
Post Reply

Return to “General OpenTTD”

Who is online

Users browsing this forum: No registered users and 7 guests