Spring RTS Engine

Tobi wrote:For C# I think making a small C++ AI that allows interproces communication (ie. TCP over loopback) and has a way to start a process is way easier then integrating either mono or the CLR directly into an AI DLL.

EDIT:
Some advantages:

• AI can just use WinForms or WPF or whatever for realtime debugging windows
• Debugging the C# code with express edition of VS and/or MinGW compiled Spring would actually work
• Spring memory corruption can not crash the AI
• AIs compiled for different .NET runtimes can be combined in a single game (it's impossible to load different .NET runtime versions in same native application; that's also the reason windows shell extensions need to be written in C++)
• AI would run in different thread (process) automagically, no need to think about threading issues etc.

Some disadvantage:

• Getting unitdef etc. will be somewhat slower because data actually has to be copied a few times.
• AI may lag a bit behind engine.
• Everything AI does is asynchronous, makes certain things a bit harder.

But instead of TCP a D-Bus interface.

Question from my side:
Are there better alternatives than D-Bus?
Using D-Bus or something similar for Mono or for all none C/C++ languages?
Or implementing for each language a wrapper?

@hughperkins:
You have experience with the .Net and the Mono wrapper for the AI interface.
Would you prefer a D-Bus like way or a Mono wrapper (embedding mono) way?
And would you help me by creating one of this.

Notice: I lag on C++ experience and embedding mono. So I need to learn both.

dbus has overhead and requires dbus to be installed

aegis wrote:dbus has overhead and requires dbus to be installed

Can you tell me a lighter alternative which works under Linux, Windows and MacOS?

i had a short look at IPC-Frameworks in Wiki, and none of them seemed promising, suitable for this project :/
i think there are other approaches wich often use an XML interchange format, but i guess that could get too slow.

well.. what are the requirements?
what i can think of (+: must have, *: nice to have):
+ fast (at runtime)
+ easy to install (eg, nothing has to be installed)
+ supports C++ and C#
* supports other languages
* easy to use for the programmer
* light-weight

Left (best)->right(worst)
+ fast (at runtime)
Mono wrapper, IPC, TCP (binary), XML/JSON/SOAP
+ easy to install (eg, nothing has to be installed)
TCP (binary), XML/JSON/SOAP, D-Bus, Mono wrapper
+ supports C++ and C#
Actually all.
* supports other languages
TCP (binary), XML/JSON/SOAP, D-Bus, Mono wrapper
* easy to use for the programmer
Mono wrapper, D-Bus, XML/JSON/SOAP, TCP (binary)
* light-weight
TCP (binary), D-Bus and XML/JSON/SOAP depends on the language and framework which is used, Mono wrapper

Note: TCP (binary) would require an protocol and this would take a long development period.

And I would not suggest to use XML/JSON/SOAP because they are slow.

So only IPC and Mono wrapper is left.

Or did I miss something?

@hoijui:
Do you plan to implement the Java wrapper for the AI interface again for the new AI interface. Or would you prefer a D-Bus like way?

i will use the C interface for JAI, except it will turn out to be very unpractical for Java (which i assume it wont), in whichs case i would use the C++ interface. i would not like a D-Bus like way for JAI. i just though, your work may also make life easier for other language interfaces.

in your evaluation, what is ICP? do you mean just the general idea, and no concrete implementation?

your evaluation seems fine to me (may only be changed when other candidates are found, i don't know any). so what would you prefer, Mono or an IPC implementation? what other criteria are there to decide between the two?

hoijui wrote:in your evaluation, what is ICP? do you mean just the general idea, and no concrete implementation?

Yeah, general idea.

hoijui wrote: your evaluation seems fine to me (may only be changed when other candidates are found, i don't know any). so what would you prefer, Mono or an IPC implementation? what other criteria are there to decide between the two?

I would prefer Mono because it is faster.

Another criteria is it possible to embed mono into the AI interface.
But currently I can't answer this

Well all these options can be implemented as different interface libs.

I think the real question is which would be most convenient to implement first?

AF wrote:Well all these options can be implemented as different interface libs.

I think the real question is which would be most convenient to implement first?

Exactly. This is the big question.
I think for me both would require ca the same time amount.
For hughperkins I think a wrapper would be less work because he did it for the last interface.
So a Mono wrapper is more convenient as a IPC (D-Bus) implementation.
Besides I can use swig to generate some basic bindings.

What are the advantages of D-BUS over TCP (or even .NET remoting implemented in C++?)

Remember that it's for localhost<->localhost communication only, just as a means to make sure debugger is usable quite well with the AI, and the CLR doesn't have the be loaded in the spring executable.

D-Bus is a higher level interface, if i got it right. for TCP, more low level coding; a dedicated protocol is needed. right?