Topic: AI enhancement suggestion - wood
|
SirVer
Joined:
2009-02-19, 15:18 UTC+1.0
Posts: 1442  One Elder of Players Location: Germany - Munich |
Posted at:
2014-01-29, 06:21 UTC+1.0
Ah, okay. So you meant concurrency. That is different than parallelism: http://blog.golang.org/concurrency-is-not-parallelism You get that for free when you program your AI in Lua, i.e. scripting it. The coroutines that lua provides offer exactly that: when you have nothing to do right now, you go to sleep in one coroutine and another coroutine gets the chance to start. We have something along those lines inside the engine too (using a CmdQueue) that could be used for the AI to schedule acting at specific times, but starting in Lua is probably the right way to go. 
Top
Quote
|
|
teppo
Joined:
2012-01-30, 09:42 UTC+1.0
Posts: 425  Tribe Member |
Posted at:
2014-01-29, 06:30 UTC+1.0
I think that it would be possible to make a new AI that would use less CPU cycles and still outperform the current one. The current AI it about 100kbytes of code. The new would probably be larger: The current AI has not kept up with seafaring.
Top
Quote
|
|
Tino
Joined:
2009-02-20, 17:05 UTC+1.0
Posts: 251 Tribe Member Location: Somewhere in Germany... |
Posted at:
2014-01-29, 09:10 UTC+1.0
I think i've already mentioned it in some older discussion or a bug thread: In my opinion the OpenTTD approach is very cool: http://wiki.openttd.org/AI:Main_Page They provide an pubic API to develop AIs with squirrel. This gives concurrency, the main code can limit cpu cycles for AIs, changing AI logic does not require recompiling the main binary... With LUA in place in widelands we could do the same approach. Of course this would require still some effort, i am not sure how "complete" the current LUA widelands API is regarding all needed functions for an AI. PS: I've found my old blueprint: https://blueprints.launchpad.net/widelands/+spec/ai-lua-framework
Top
Quote
|
|
teppo
Joined:
2012-01-30, 09:42 UTC+1.0
Posts: 425 Tribe Member |
Posted at:
2014-01-29, 14:57 UTC+1.0
Tino: Your suggestion could include things like
Possibility to limit AI CPU cycles sounds good. I run low-end hardware, and large maps with long plays choke my HW. Also this should make it rather sure that AI are separated from the rest of the game. Personally, I like the C++ approach more, but a solution like that has its benefits. I had not heard that before. Thanks for bringing up the old discussion.
Top
Quote
|
|
SirVer
Joined:
2009-02-19, 15:18 UTC+1.0
Posts: 1442 One Elder of Players Location: Germany - Munich |
Posted at:
2014-01-30, 15:00 UTC+1.0
Yes, and we already can - but only for specific maps. As mentioned if someone comes up with a great Lua AI we can consider adding this to the game. I am careful though for various reasons. One of the main ones is that scripting languages (i.e. non-compiled languages) are much harder to maintain. I would not want to have the main AI of Widelands implemented in Lua - changes to the code are much more dangerous. So I really prefer c++ for an AI, but prototyping can be done in Lua and an AI can be moved piecewise to c++.
We can already do this right now by helping out the AI via scripting, i.e. forbidding some places by ripping buildings or building better roads for it. The integration can be much deeper of course.
Top
Quote
|
einstein13
Joined:
2013-07-29, 00:01 UTC+2.0
Posts: 1116 One Elder of Players Location: Poland |
Posted at:
2014-01-30, 16:37 UTC+1.0
You're right! We shouldn't build main AI program in LUA. There is second reason: non-compiled languages are much more slower than compiled ones. Of course LUA programming is easier than C++ and it is very easy to modify (you don't have to compile whole game to check the AI strength and if the idea of AI works) einstein13
Top
Quote
|
|
SirVer
Joined:
2009-02-19, 15:18 UTC+1.0
Posts: 1442 One Elder of Players Location: Germany - Munich |
Posted at:
2014-01-30, 19:03 UTC+1.0
This is no concern of mine. First, the statement is not true (anymore): i.e. just in time compiling can optimize across the boundaries of library and for example string interpolation can be much faster in pypy or luajit compared to c++ (which cannot optimize the std libraries for special use). Second: premature optimization is the root of all evil.
Top
Quote
|