Unreal driver discussion summary
 

[Edited by a moderator: this thread has been closed as it contains a summary of the discussion that has been held about the best way to communicate with the Unreal engine, for further reference. This discussion is now followed up in the "Unreal engine driver communication" thread.]
-------------------


Crazy idea #1

Create an interface between game engine and the external C++ driver using a shared file. This may be slow, but it could work provided the game engine provides the means to write code that allows files to be read/written to.

Re: United Bot philosophy and roadmap.
 

Are you nuts ??? 8o
Disk I/O access times absolutely prohibit this method.

although..... Extension to Crazy idea #1: what about setting up a tiny RAM drive just for this ? :D

*edit* sounds barbaric, though... the system will still need to allocate/deallocate millions of file descriptors per second... O joy...

@botman and botmeister: I agree, we should take this to a dedicated forum. Already 2 Council members agreeing here. One more and the idea is validated.

Re: United Bot philosophy and roadmap.
 

What's with the disk I/O?
Just use ReadProcessMemory and WriteProcessMemory on an address you allocate inside the game.

Just use file i/o once to define where the memory is located.

Actually, I'm not sure now. I really need to get more sleep.

Re: United Bot philosophy and roadmap.
 

Absolutely! Next question please. :D

RAM disk? This is great, some more lunacy!

Perhaps such a thing is too OS dependant and complex for people to set up. The large amount of RAM allocated for disk caching these days probably makes it redundant anyway.

Yes, using disk I/O is *very* inefficient, but who cares so long as it is fast enough for what we need it to do. The current method we use to make our plugins is also silly and ineffiecient, but it still works.

You are right and I did think of this, but the problem is that most of the game scripts probably cannot allocate memory and return an address for us to pass on. I'm not 100% sure about what a typical game scripting language is capable of, but someone like botman may be able to answer this one for us.

More ideas ...

Re: United Bot philosophy and roadmap.
 

I think not. I've read a little bit about UnrealScript and arbitrarily allocating memory isn't in the list of features.

If you REALLY want to go with the disk I/O method then I urge you to consider that the expense in solving portability issues with a RAM disk (which is THE fastest way to do disk I/O) will become a mandatory step anyway, as soon as you'll figure out that no matter how fast your hard drive spins, it will still be extraordinarily slow for a process who wants to make 200 engine calls and more per second and communicate them through a file access.

Re: United Bot philosophy and roadmap.
 

this disk I/O stuff was a joke, wasn't it ? OK, for this scripting crippled engines, it's ok, but that can then maybe be a disk io plugin. arent there more engines with a nicer interface to talk about than Unreal ?

but we should really get some structure to thsi topic soon. if you are not reading especially this thread every day, it's pretty hard to keep track :) first we need some general idea to be able to create some structure, but then we should say good bye to such threads :)

just my 2 cents

Re: United Bot philosophy and roadmap.
 

No I was not entirely joking about the disk I/O communications idea.

On a relatively slow 850 Mhz machine running Win2K I can read from a text file 649,520 bytes in .02 seconds,and I can write the same amount to a text file in about 0.14 seconds.

You have to remember that the reaction times of a bot are in the 1/100 (0.01) of a second at best, which is *very* slow for a modern day desktop computer. We can probably get away with many reaction functions in 1/10 of a second range, or even longer. Only a few tasks, such as aiming and firing weapons will require the lowest reaction times.

How much data needs to be transfered per frame at 100 farmes per second is the big question, from there we can calculate if the concept is feasible or not. If it is, then we'll have a relatively universal communications method between the game and the bot. Of course enough games must allow efficient disk I/O from their scripting language. If basic disk I/O is not available then it is hard to imagine that scripting languages will provide us with anything that is more sophisticated.

edit:

We may also be able to perfom compression/decompression on the data that is exchanged to further reduce disk I/O times.

edit again:

Also, how fast (or slow) is communications through TCP/IP over 100 MB LAN? I can tell you it is a lot slower than local disk I/O.

Re: United Bot philosophy and roadmap.
 

Ok, this might sound a bit stupid, but surely we want bots to be as fast as possible, i understand that using I/O may be the only solution, but maybe we should find a way to let a plugin decide what the best way to do it is..

The engine would have all the avaliable options avalaible, then the plugin decide which one to use? Making it more 'game specific'. and unless you want to hinder bot performance over all games, this is the only solution that i can think of which will happily work for all.

Re: United Bot philosophy and roadmap.
 

Agreed, but it would not be the plugin to decide, it would be the driver that sits between the UB and the game engine that decides what method to use (normally the best method that is available).

"faster than necessary" is not only unnecessary but may create redundant overhead which translates into more lag. You have to realize what I mean by "reaction times" vs processing time. These are two separate things. You will want the lowest possible processing time in most situations, but reaction times need only be as fast as required to get a bot to perform adequately against human players.

The disk I/O concept would be the lowest common denomonator across game engines assuming it can even work, and assuming no one can come up with anything better. For example, games that use the HL engine will have far better options due to the availablity of the SDK.