United Bot philosophy and roadmap

[botman]

"can we at least make external code communicate with QuakeC code or UnrealScript?"

You can with UnrealScript. There is a TCP/IP networking package called 'IpDrv' that allows you to create network connections that could be used to transfer movement commands and other bot input from an external application to the bot UnrealScript code in the game. This external app could be running on the server, or it could be running on some external client that has been configured to connect to the host running the game (security might be an issue here, also network bandwidth needed to constantly send commands back and forth could be an issue). Even with an external C++ application controlling the bots in UT2k3/2k4, there is no way to get polygon geometry information from the engine. The Unreal "compiled" map format isn't publicly available and the only information you can get at run-time through Unreal Script is Traceline() info (determining where a line or box collided with the world when ray tracing from one point to another point). Can you imagine the overhead needed to send commands and results back and forth over a network to do a dozen or so tracelines per bot per frame?

I'm not sure what Quake III has to offer as far as external network connections. Somebody would have to do some research on this.

I know that UnrealScript doesn't have any other mechanism for sending data back and forth between processes on the same machine (like shared memory), unless you want to start hacking the engine executable to make something like this possible (i.e. hacked DLLs and whatnot), which I doubt anyone here wants to go that route.

botman

[botmeister]

Looks grim for at least the games botman mentions. Are they any other games worth researching?

It may still be worth building the UB, but IMO not for commercial games.

There was some talk of building our own game template which would provide 3rd party bot support by design, and provide many other services by design which are not seen in commercial games (and probably never will be seen). Some of the concepts disucssed for the UB would apply directly to the game template idea.

I would not consider building our own game engine, but instead make use of existing open source, or "free" commercial, game engines.

The same idea of game drivers would provide an interface between the game template and the engine. The same idea of plugins could then be constructed to provide all the essential services which make up a full featured FPS game. A UB would seemlessly plug into the game template providing "by design" 3rd party bot support (for the first time ever). Imagine what you could do with such an interface?

The plugin concept will allow anyone to develop components for the game, with collaboration among developers. The template will enforce standards on the developers, and provide a form of "automated collaboration" (so to speak).

I may be crazy to even suggest such a thing, but if we don't do something radically different, we'll be stuck with the same old worn out problems and limitations forever.

[stefanhendriks]

in fact its not crazy, its a challange. Just do what nobody (dares) to do..

[Pierre-Marie Baty]

@botmeister: the fact is that, I think, if we can't do that for commercial games, our project will generate little interest.

@botman:

Originally Posted by botman

Can you imagine the overhead needed to send commands and results back and forth over a network

Not over a network... over the loopback interface

... to do a dozen or so tracelines per bot per frame?

In HL, I fire around 80 tracelines per bot per frame, it works quite well when you do it cleverly...
*edit* wait, right, not "per bot"... hmm, well... 80 tracelines per frame at least. That's what my counter tells me

[Terran]

Originally Posted by Pierre-Marie Baty

@botman:
Not over a network... over the loopback interface

You always have a lot of overhead if you use a general purpose network stack to transfer data, especially with TCP/IP. It doesn't matter which interface you use! All your data will be wrapped into packets which need headers and checksums. And there is not only one header with TCP/IP, there are at least two of them, one for IP and one for TCP/UDP. And both require checksums which need to be calculated. That's one of the reasons why you never get the expected bandwidth that you expect when you transfer data using TCP/IP. Modern server clusters e.g. use specialized network hardware and stacks which are optimized for speed and bandwidth and only need minimal overhead. But I doubt that UT supports that .

[botman]

Agreed. It would be most efficient if you could have some sort of shared memory segment to send things back and forth between a game engine and an external application running on the same server. But since UT2k3/2k4 doesn't support this, that's not an option.

The other problem with a loopback IP stack is even it will have a limited Operating System buffer space. So if you send too much data, the sender will be forced to suspend until the receiver has emptied some data from the channel. I have no idea what the size of the buffer is for Windows or Linux OS, but I'm pretty sure that this buffer isn't dynamic. It should be easy enough to test by creating a simple IP application with a sender and receiver that opens a port and have the sender keep sending 1K blocks of random data, while the receiver just sleeps and never reads anything. If you have the sender keep spitting out some output every second or so, you'll probably see a point when the sender stops sending output (because it's suspended).

botman

[Pierre-Marie Baty]

from http://unreal.epicgames.com/UnrealScript.htm:

[...] This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.

so it MUST be possible somehow.

Still investigating...

*edit*
In "UnrealScript variables" section

native: Advanced. Declares that the variable is loaded and saved by C++ code, rather than by UnrealScript.

it's a variable specifier (like "const"). looks interesting...

[Pierre-Marie Baty]

I was certain to have seen that somewhere already, now here it is !

http://www.planetunreal.com/gamebots/

read the 2nd paragraph...

[botmeister]

In theory, native functions can be used to pass information back and forth between a custom C/C++ DLL and Unreal Script - there may be no need for a network interface at all.

native (classes / variables / structs)
nativereplication

http://wiki.beyondunreal.com/wiki/UnrealScript_Keywords

http://www.esconline.org/Resources/native.html

[botman]

"so it MUST be possible somehow"

Yes, it's quite trivial for Unreal Tournament licensees. Native code is C++ code.

Unreal Tournament (from, what 1997?) included the header files necessary to use native C++ code in your MODs. Starting with UT2k3, Epic stopped including the header files (probably to help prevent cheating in the game). UT2k3/2k4 don't support any kind of native C++ code unless you have licensed the Unreal engine from Epic.

botman