AI Development status

[_alan_]

Hi,

Is somebody working on the AI ?
I can see some little changes on SVN.


In NewAI ( OTTD 0.4.8 ), Buses and Trucks are not replaced when they are too old.
Does somebody work on it ?

Thanks,
Alan

[Darkvater]

AI is not being developed. Only serious bugs are fixed (eg crash, desync, etc.)

[Ailure]

I might take a look at the code over the holidays, but I don't think I would further devolop it, just want to fix some of it's shortcomings. (both the new AI and old AI seems to... gotten stupider somehow with the newer versions, and seems like they also causes slowdowns in certain cases.)

[Darkvater]

I might take a look at the code over the holidays, but I don't think I would further devolop it, just want to fix some of it's shortcomings. (both the new AI and old AI seems to... gotten stupider somehow with the newer versions, and seems like they also causes slowdowns in certain cases.)

If you want to look into the slowdowns, that'd be pretty good. I think the AI doesn't give up too easily when it cannot find a new route or station for example, or at least does too many iterations in one tick, thus slowing everything down.

[_alan_]

If Ailure and me are working on the AI, we should focus our effort on only one AI. Trolly, Default, a third one ?

I think we should start on the default AI.
Why ?
I was fixing the "replacement" problem of trolly (NewAI) and i realized i was reinventing the wheel. All that is already done in the default AI.

When you look at the code
Default ai code lines: ~4000
Trolly code lines: ~2600
Even tough default AI is more stupid than Trolly, it has more "common" tasks.

Truelight said :
By the time that system is finished, you can expect that this AI will dissapear, because it is pretty obselete and bad programmed.
(Top of trolly.c)

[Darkvater]

The Default AI is the old, original TTD AI. It includes the AI for RV, Train and Aircraft (the ship part has not been written). It is stupid, annoying and has existed for the better part of the last 10 years.

TrueLight started a newAI, which only supports RV (trolly.c).

You are welcome to choose to continue either one, or chuck both out and start anew. Although I've heard rumours from KUDr that he planned to make a scripted AI using LUA (much like the plans were in the past with GPMI), so you should probably sync with him if you are any serious

[_alan_]

I don't have KUDr's mail and he doesn't read his PMs.


I have made a Lua "sample" to know what it can bring (c.f. Attachment).
Lua's coroutines is a powerful tool. You can easily create a thread and suspend his execution.



How does it works ?

The lua code :

Code: Select all

function MainLoop()
	
	-- do one pending task
	local taskStatus = TaskManager.doTask()
	-- do some other tasks if needed
	while taskStatus == "DO_NEXT_TASK" do
		taskStatus = TaskManager.doTask()
	end
	if taskStatus == "EMPTY_TASK" then
		-- look for something to do
		AI_LookForATask()
	end

end -- function


-- Look for something to do
function AI_LookForATask()
	TaskManager.add(DoShortTask)
	TaskManager.add(DoLongTask)
end



---------------------------------------------------------------------------
-- Tasks
--

-- A LongTask 
function DoLongTask()
	-- that is a long task
	for i=1, 10, 1 do
		if i == 5 then
			TaskManager.sleep()
		end
		print("LongTask loop "..i)
	end
	
	return "TASK_DONE"
end -- function


-- A ShortTask
function DoShortTask()
	-- that is a very short task
	print("ShortTask: do printSomething(\"Hello!\")")
	printSomething("Hello!")
	print("ShortTask: do the next task")
	
	return "DO_NEXT_TASK"
end  -- function


---------------------------------------------------------------------------
-- functions called by tasks
--

function printSomething(message)
	print("   printSomething: "..message)
end

The result :

Code: Select all

alan@localhost:~/ai_sample$ ./ai_sample
=== Player Alice ===
AI script initialized
=== Player David ===
AI script initialized
*** Game Started ***
*** Game frame 0 ***
=== Player Alice ===
=== Player David ===
*** Game frame 1 ***
=== Player Alice ===
ShortTask: do printSomething("Hello!")
   printSomething: Hello!
ShortTask: do the next task
LongTask loop 1
LongTask loop 2
LongTask loop 3
LongTask loop 4
=== Player David ===
ShortTask: do printSomething("Hello!")
   printSomething: Hello!
ShortTask: do the next task
LongTask loop 1
LongTask loop 2
LongTask loop 3
LongTask loop 4
*** Game frame 2 ***
=== Player Alice ===
LongTask loop 5
LongTask loop 6
LongTask loop 7
LongTask loop 8
LongTask loop 9
LongTask loop 10
=== Player David ===
LongTask loop 5
LongTask loop 6
LongTask loop 7
LongTask loop 8
LongTask loop 9
LongTask loop 10
*** Game frame 3 ***
=== Player Alice ===
=== Player David ===
*** Game frame 4 ***
=== Player Alice ===
ShortTask: do printSomething("Hello!")
   printSomething: Hello!
ShortTask: do the next task
LongTask loop 1
LongTask loop 2
LongTask loop 3
LongTask loop 4
=== Player David ===
ShortTask: do printSomething("Hello!")
   printSomething: Hello!
ShortTask: do the next task
LongTask loop 1
LongTask loop 2
LongTask loop 3
LongTask loop 4
*** Game Stopped ***
=== Player Alice ===
AI script uninitialized
=== Player David ===
AI script uninitialized

[KUDr]

_alan_:

Sorry, i overlooked that i have new PM as it doesn't happen very offten. Now Bjarni told me on IRC that you are asking for me.

Yes, LUA is very powerful from the features POV. Its cooperative multitasking works similar way as "multitasking" in 16 bit Windows. There are two functions - yield() and resume(). Both can accept/return some arguments. It makes it extremely usefull for background tasks like AI:
1) create new execution context (LUA_state)
2) make new task by calling resume first time providing function as one of arguments.
3) function is executed until it reaches yield().
4) any arguments given to the yield() are returned from your resume() call as return values
5) now you can do whatever you want
6) when you want to continue execution you simply call resume() again.
7) task continues - returns from yield() with return value of your arguments you passed to resume() and can do something until it reaches yield() again or until it finishes (return) which you can recognize by checking the resume() return value..

If you make proper infrastructure, you can run several tasks on the background (i.e. by calling one or more resume() functions each frame tick). It really works fine. I tried to embed the LUA engine into ottd around rev.6000 and was surprised how well it behaves. It really does, what its authors claim.

I found such script usefull not only for the AI but also for the following areas:
- more complex landscape and infrastructure building commands (like copy/paste, signal autocompletion, etc.)
- "undo" command support
- GUI (Widgets, handling mouse/keyboard events)
- game/scenario scripting (game events, triggers, etc.)
- prototyping new features (newsignals, load balancers)
- user customizations
- any other areas?

Then i played with it a bit further and found also some issues:

- security seems to be the the biggest issue. Especially if scripting will be used in MP (general, not LUA specific)
- LUA has crazy syntax (pascal like) and some hard to understand features (functions returning tuples)
- it requires lot of code to be written in C/C++ and maintained to mirror all necessary OpenTTD functions/structures/values into LUA
- getting slower and slower with large scripts (many constants, variables and functions in the global namespace)
- hard (if not impossible) to fully save/restore its state(s) for the savegame/MP connect support
- if you want to make global namespace table as small as possible to improve performance and script readability you'll find out that there is very vague support for user defined types (lot of programming required to support new classes with properties, methods, etc.)

Then i found squirrel (better script engine) that looks like LUA fork/derivate. Featurewise it is the same as LUA, but the language itself looks much better.

I would like to choose the script engine carefully to cover as many areas as possible with the only one engine (it makes no sense to embed several scripts for several tasks). Also the issues above should be taken into consideration.

Now i am trying to find some even better script engine that would be easier to integrate into ottd.

Another way i am trying to investigate would be some C code generator that can generate script->C and C->script calling stubs (like SWIG).

If you are really seriously interested in writing AI scripts for openttd, we can create squirrel branch and start. Later it would be possible to replace the engine by another one (with similar language) and port the existing scripts (if any). I'll post you my email as PM.

[xyz]

What about making a plug-ins interface for the AI engine. like an winamp plug-ins for example.
I think this game uses that kind of AI's

[KUDr]

why? This is open source game. Everybody can make new AI much easier way. Such interface would need many man-days to create, and even more to document and maintain. Until we have at least 3 good AIs it makes no sense to bother with plugins.

Script engine would take around the same time to embed and seems to be much better and useful for other areas too.