Communication

[Yves M]

As some people have previously said, I'm also interested in participating in the challenge. I'd like to help writing thee server part as well. I'm still unsure about the best way that we could use. We want to makee it compatible with the most programming languages, so we have to select a technology that works with everything. The languages I have in mind are C / C++, C#, Visual Basic, Java (maybe Delphi, if anyone prefers to code in that).

Basically there are three options for the design. I'd like your input with the compatibility issues, as I'm not hugely familiar with the other languages.

DLL
C/C++: easy
C#: no idea, but I guess easy as well
VB: a bit more complicated
Java: I guess incompatible
COM
C/C++: a bit hard, but easy if we provide a skeleton
C#: probably the same
VB: easy
Java: I guess compatible, but don't know what this would involve
Internal TCP/IP
C/C++: hard, unless someone writes the server & client code
C#: hard as well
VB: hard as well
Java: a little bit easier

The "Internal TCP/IP" is meant that the server and all the clients still run on the same computer but communicate through TCP/IP rather than one of the other techniques.

So, I'd like your input on these things. Personally I would prefer COM, but I'll wait to see what someone who actually knows Java will say about these things.

[Yves M]

Since we are going to support more than just C++, we have to decide on a client/server architecture that will allow creature programs written in Java, C++, C# and VB. There are two main options, namely COM and local TCP/IP. I'm currently looking into what would be needed with COM and Gabriel is trying out the local TCP/IP.

I would like some feedback from you guys about which one you would prefer, why and maybe most importantly which one is easy/hard/impossible in your favourite programming language.

[Gabriel Fleseriu]

I needed 15 minutes write an MFC dialog based app and a VB app that use sockets and can communicate via local TCP/IP with each other (I send one integer from MFC to VB :) ). I will dig further into the possibilities that local TCP/IP offers.

[Yves M]

Great, if it's that easy, then let's use that :)

[Elrond]

This is the original thread where we (Gabriel) just started talking about the idea of doing such a project. It started only yesterday I think, so it's obvious there is not even a proper beginning of design. ;)

Now that a certain number of people seem interested, a few more ideas about what should be contained in the first version will probably discussed and a design started.

The question about the DLL is a very good one. Most of the people who wrote in this thread are more "Windows development" oriented. We need to have people using other languages (Java) involved at least to tell us what can and what can't (easily) be done. :)

The DLL thing was just an idea, but if it's not possible, then the COM (or CORBA) and TCP_IP solution are looked at as well.

[Gabriel Fleseriu]

If I'm not very mistaken, local TCP/IP would lead to a very simplistic protocol between the host and the clients. At least between C++ (MFC) and VB the communication needs to be pretty simplistic if we don't want an overkill.

As I have no Java or C# knowledge, I'd like to know whether it is possible to use sockets from these languages (probably yes) and whether it is complicated or not.

Local TCP/IP has the advantage that clients hardly can crash the host (as DLLs easily can do). If wrapped by a good framework, it also might be simple to use.

[Goodz13]

I like the "custom TCP/IP thingy", but we would still need to decide how the information is to be processed.

I have no experience with COM, but from my understanding, it's simular to CORBA, which wouldn't be a problem to communicate with Java.

It is possible for Java programs to use DLL's with JNI (Java Native Interface), but not sure if a DLL would be the answer in this case.

[Yves M]

Judging from Gabriel's tries with VB and VC, the TCP/IP solution is not hard and is surely the most portable one. The only drawback I have is that I have no experience with this at all, so I hope someone else knows how to do this stuff (at least for VC and VB). Could you handle writing a sample Java client, Goodz ? Before that, of course, we'll have to decide what the environment looks like. c.f. the other post.

[galathaea]

How are the creature modules to be run? Even if tcp/ip is the protocol for communications, I am still unclear if the individual creatures will be run in separate processes or attached as DLL's (COM or otherwise -- which makes it hard for Java)...

Also, is it too early to discuss interface? There is a good discussion on rules and state already, but maybe an iterface (message format, etc.) can be standardized soon for construction of the server and the creatures?

[Gabriel Fleseriu]

Originally posted by galathaea
How are the creature modules to be run? Even if tcp/ip is the protocol for communications, I am still unclear if the individual creatures will be run in separate processes or attached as DLL's (COM or otherwise -- which makes it hard for Java)...


This insormation cristalized in one evening, so don't take me by word: the clients are going to run as stand alone processes on the same machine as the host (server). There will be no COM, but a simple TCP/IP protocol.

Also, is it too early to discuss interface? There is a good discussion on rules and state already, but maybe an iterface (message format, etc.) can be standardized soon for construction of the server and the creatures?

We are working hard at this part. At the time speaking, we try to outline the rules for the world and the creatures, so we can draft a protocol. We will post more information soon.

[Andreas Masur]

Originally posted by Yves M
Basically there are three options for the design. I'd like your input with the compatibility issues, as I'm not hugely familiar with the other languages.

DLL
C/C++: easy
C#: no idea, but I guess easy as well
VB: a bit more complicated
Java: I guess incompatible
COM
C/C++: a bit hard, but easy if we provide a skeleton
C#: probably the same
VB: easy
Java: I guess compatible, but don't know what this would involve
Internal TCP/IP
C/C++: hard, unless someone writes the server & client code
C#: hard as well
VB: hard as well
Java: a little bit easier


Okay...

- Dll

Well...this would need some more detailed description since I do not understand what you are meaning with it (in regard to the host/client communication)...

- COM

Seems a little bit too much overhead to me. And I am also not sure whether Java actually can work with COM objects (which I doubt at the moment)...

- TCP/IP

As I already said yesterday...this would be my favourite one since this is a defined standard which is supported by every operating system and programming language...

I will discuss further in the appropriate thread...

[Goodz13]

Yves M,

I've posted a little demonstration on how Java and VB can communicate. They just communicate with stright Strings.

I have the VB program acting as the server, if you want to run the Java program and you have the JRE (Java Runtime Environment) 1.3 or qreator installed, all you have to do is double click on the JAR file.

I've also included all the source files. The source files for the Java program are included in the JAR. If you want to see them, you can open the Jar with WinZip, the source is the the src directory.

The VB stuff is a little crude, but I only wanted to show a demo.

[Andreas Masur]

Originally posted by Goodz13
Has anyone mentioned CORBA?

Well...that is basically also too much overhead like COM...at least for the first version...

[Andreas Masur]

Okay...to finally add my worthless 2 cents... :cool:

I am assuming that the server (host) and the clients (individual creature applications) are running on the same PC.

This would basically lead to several things that can be used like pipes, TCP/IP etc. Since I have stated earlier since TCP/IP is a pretty well defined protocol which is supported by at least all the mentioned programming languages I would suggest to stick with it.

As I also have mentioned I can throw in some experience with TCP/IP and sockets. I have written a TCP/IP dll for my company which basically handles all the server and client communication and provides a simple interface to the calling application (right now C++ only). Nevertheless this I would suggest for this project as well.

Instead of having everybody to program the TCP/IP connection part from the client to the server and most-likely have to deal with communication problems between the different clients' implementation I would rather suggest the following:

We build a dll which provides the internal TCP/IP communication between the client and the server. This dll will expose it's functionality via a simple interface. Through this interface every server (I know there is only one right now but who knows :cool: ) and client can easily access the functionality. This can be made as easy for the client as needed - up to just calling a send function to send data and a receive function to receive data without taking care about the underlying layers. This should satisfy every client disregarding in which language it is written. On the server side I assume that we are going to use a decent C++ way therefore the dll could provide an interface which allows the server (and maybe more than one if needed) to define the needed processing on its own. That would mean if we want to extend the features of the game and therefore also the server you just provide a new process function for the server and everything is working without problems.

The only question would be which languages are able to deal with dll's in general and in detail with C++ dll's.

I know for sure that C++ will, Visual Basic will as well (eventhough it might not be that easy), I assume C# should handle it as well. This would leave Java where I am completely unsure at the moment...

[Yves M]

Great, then it is TCP/IP. Gabriel has done a small sample app that does TCP/IP with MFC's sockets and he said he would code that part of the server (i.e. the handling of networking). His sample communicates with a VB program. Start the VB program first, then the C++ one and it will send an integer from one to the other :)

[mwilliamson]

I don't think it matters which method we choose, since we will develop a template for other users. I think the users would only have to write thier algorithm. I don't like TCP/IP, because it gives the users the ability to cheat. If we go with COM or DLL then we can recompile and view thier code.

[Yves M]

I moved the client/server replies off the main thread into here, so everything is in one place.
Andreas, from the looks of it we wouldn't need to use a custom DLL like the one you were going to be so kind as to write. With MFC's socket class, the problem is solved for C++. In VB there are ActiveX controls to handle this. And Java has been solved by Goodz :)

I'll start working on a TCP/IP interface proposal and submit it here. Brad has suggested using SOAP / XML, but I guess that's a bit over the top for our needs. I guess the basic layout would be something like:
1 word : session ID for the creature.
1 word : message ID (e.g. 1 = move, 2 = turn etc.)
1 word : sequence number (in case we would have to send packets that would have to be split)
x words : message contents

For the basic client actions this would be something like:

move : x = 1 word that is ignored (since you can only move forward one square)
turn : x = 1 word that specifies the angle (0 = 90, 1 = 180, 2 = 270 degrees)
rest : x = 1 word that is ignored.
harvest : x = 1 word that is ignored
attack : x = 1 word that is ignored (attacks are always to the creature that is in the square that the robot is facing)
scan : x = 1 word that is ignored


The server messages would be:
1 word : session ID for the creature
1 word message ID
1 word sequence number
y words message content

The basic server responses are:

move completed, nothing unexpected happened, y = 1 WTII (word that is ignored)
move completed unsucessfully, y = 1 word that indicates the reason. Possible reasons could be:
* bump into a wall
* bump into another creature
* die (as caused by an attack or lack of food)
* unable to harvest on a non-food square
* attacked creature has moved away (or there was no creature to attack in the first place)
move completed successfully, with status information. Possible status information includes:
* the move was an attack > respond with how much damage was done to the opponent and the health percentage of the opponent.
* the move was a scan, respond with a squence of words, each indicating what is visible in the 8 squares in the vision range. This should be flexible enough to allow for bigger vision ranges.
The status of a grid-cell could be indicated as
0 = empty
1 = wall
2 = food
3 = blocked from view
256 - 65535 = creature with ID z / 256 (so we would have a maximum of 256 creatures, this could maybe all be dwords so that we can allow for more creatures)

In addition to these basic responses, the server sends back status information after each move. This inccludes:

The current location and facing of the creature
The current health and food characteristics
Whether any other creature attacked you this turn and if yes its ID (1 - 256), from which direction and how much damage was done.


What I'm uncertain about is how to handle multiple clients. I'm thinking of this, but it might be wrong:
When the server is started, it sends a broadcast call on a certain port. Each client responds by generating a random number and sending a message back. The server sends an acknowledgment for each client along with a session ID and a specific port number that only that client will use. If a client doesn't get a response, it times out and sends another request with a different random number, so as to avoid conflicts.

Once the connection between server and clients is established, the server asks the creatures to send it their four characteristics. Once this is done, the server sends them basic information about the world. It sends the world's size along with information about where the creature will start. As a free bonus I guess we could include information about the 9 squares sourrounding the creature as well (including the square occupied by it).

What are your thoughts on this ?

[Yves M]

Originally posted by mwilliamson
I don't think it matters which method we choose, since we will develop a template for other users. I think the users would only have to write thier algorithm. I don't like TCP/IP, because it gives the users the ability to cheat. If we go with COM or DLL then we can recompile and view thier code.
No, users still have to give us the full source code and the judge will compile it on their machine and everything is run locally (with the IP 127.0.0.1). The decision to use TCP/IP is just so that the different programming languages can communicate easily.

[Goodz13]

1 word : session ID for the creature.
1 word : message ID (e.g. 1 = move, 2 = turn etc.)
1 word : sequence number (in case we would have to send packets that would have to be split)
x words : message contents


So the prefix (1 word : , attack : , etc. ) will tell the server how to handle it?

How does the MFC Socket work. With Java the simplest way it to read one line at a time (Reads until it hits the "\n" char). I've worked with one Language (Theos Basic) that you have to know how many characters to grab before you grab the string, which makes things a little more difficult. Or does it work like VB's socket where it reads the entire contents.

There are ways that I can read each byte at a time then convert it to a string if you didn't want to add the "\n" to the end of each string that is send, but that would add to the overhead.

What I'm guessing is that there will be a Java class that will do all the communication with the server and provide methods like:

getHealth
getLocation
setLocation or moveLeft, moveRight, etc.
attack
etc...

Then the "Creature" will make an object of this class to call these methods?

[Yves M]

I guess I was not clear what I meant by 'word' ;) I meant a word of memory, so 16 bits. Is the easiest way to handle TCP/IP with Java to send strings each way ?

[Gabriel Fleseriu]

For VB, the simplest way is to write an ActiveX control that wraps the communication with the server. This ActiveX control would use the WinSock ActiveX -- we need to think about redistributing details. It would have methods, like move, turn, attack etc. and a few events, like "connected" or so.

All what a VB creature (client) needed to do is place the control on its main form and call its methods.

The same can be done by a C++ client that uses MFC (dialog based). (Project->Add to project->Components and controls...). Non-MFC C++ clients also can instantiate an ActiveX, but it's hadrer.

Question: how easy is it to use an ActiveX control from Java and C#?

The ActiveX solution has the advantages that
- no client has to deal with TCP/IP or sockets code
- all clients would by default have a uniform interface to the server.
- it is actually pretty simple to code such an ActiveX - I know how to do it

[dimm_coder]

So much post only for 1 day. It seems that it's not best way for discussion.
So about client/server.
I agree with Gabriel that may be the best way to use local TCP. Because every creature (or even all population) can live in the own process and they cannot crush main host. This way we can get good scalebality, safety and practicaly crossplatform-independent code.
Like Andreas, I can help in developing network part.
I don't agree with ActiveX, because it's M$ way and platform depended.
_________________________
I have my own realization of COM(local and remote) via TCP. It made for Linux, but it is platform independed mostly. It provide same things like DCOM realization. U can create object in a remote process and work with it remotely. Also it's allowed to provide callback interfaces on client side for remote object.
Some portline:
host creates remote creature, get from it some interfaces and provides for it another interfaces like INatureAround, IFoodGet... (it's only example).
If we will use the same concepts we can get more easy way to create a creature. All that need user is to write code for his creature (wich inherits some interfaces are known for host program and provide some internal variables for remote interfaces from host) but he don't need to write any network code.

So it will be appropriate I can provide my source code for someone analization.

[Gabriel Fleseriu]

Briefly, this is how local TCP/IP works:

The host (server) creates a socket that connects to a free port (say 1234) and listens to that port.

Each client, once started, attempts to connect to "127.0.0.1", port 1234. The server accepts the connection and creates a new socket for that client.

The result is that the server will have an array of sockets, each one corresponding to a client. There is no need for a client to identify itself when sending to the server, because the server will know that by looking at the socket the message came in. Simmilarily, the server doesn't need to put in its messages a piece of info that identifies the client. It just has to use the right socket.

One client cannot peek into the communication between server and another client (without a major hack).

Attached, a simple MFC server and a simple VB client. Start the server under the debugger (it uses TRACE() to output messages) and any number of clients and you'll see. If you run the client under the VB IDE, it also outputs debug messages. The server also attempts a hack drawing a map -- ignore that.

[Yves M]

I meant that we could send back the ID of the creature so that each client can in the future handle multiple creatures. I'll try your example program and let you know.

[Goodz13]

Question: how easy is it to use an ActiveX control from Java ...

It's not easy. From my understanding, it is in J++ (MS's version), but I don't know anyone who uses J++ and you wouldn't have the classes available that you would in Sun's Java. Java's solution to ActiveX is a bean.

If you can provide actically what the ActiveX control does, I should be able to make a class that does basically the samething.


Is the easiest way to handle TCP/IP with Java to send strings each way ?


It's the easiest way, but not the only way. For instance, If I was communicating with a Java server, I could send any object of any class that Implements Serializable. Unfortunatly that isn't the case when communicating with other Languages. Java also has Remote Method Invocation, then again that would be communicating with Java -> Java.

[Yves M]

Nice work, Gabriel :) That works like a charm.

Goodz, so would it be hard to send machine words and structures in the way that Gabriel is sending them right now ?

[Gabriel Fleseriu]

One small thing:

In C++, sending data isCSocket::Send(void* data, int size);so sending a structure is no problem. In Basic, both the Send and the GetData methods of the WinSock control take a data parameter that can be one of integer, long, string, blabla.... and array of bytes. No user defined data types -- nope, niet, nada. Not even an array of integers works.

So, if we want to make our lifes easyer, we should design the messages to be sequencies of bytes.

[Yves M]

Ok, an array of bytes seems like an OK solution. Goodz, would that be hard to deal with in Java ? It would look something like this:
header:
----------------
1 char : number of remaining bytes in the message
1 char : message ID
1 char : creature ID
1 char : turn number
----------------
Content:
----------------
x chars[] : remaining data
----------------

[DHillard]

I've been following this thread for a few days now and thinking...

If the clients and server are to be run on the same machine, ie. not connecting via TCPIP over the internet like Quake and such, then why all the complication by using TCPIP on the same PC? Also, if this is supposed to be "turn-based", what would constitute a turn? Processing time? Server requests a "move" from each client in turn?

Why not consider the "server" processing the client scripts and have the server an "interpreter" of sorts. Thereby being able to define your codewar "language" that the clients are written in. That way, the competetors would submit ascii text files to be "played" by the server. Since nobody else would see the results anyway, why the trouble writing a graphical visualization?

This approach would definately eliminate any chance of hacking the environment as has been mentioned previously.

/rambling

David

[Goodz13]

Ok, an array of bytes seems like an OK solution. Goodz, would that be hard to deal with in Java ? It would look something like this:
header:
----------------
1 char : number of remaining bytes in the message
1 char : message ID
1 char : creature ID
1 char : turn number
----------------
Content:
----------------
x chars[] : remaining data
----------------


No that shouldn't be a problem.

I haven't looked at Gabriel's test, but I'll look at it tonight to see if it would be a problem communicating with it, then post my results here.

[Goodz13]

If the clients and server are to be run on the same machine, ie. not connecting via TCPIP over the internet like Quake and such, then why all the complication by using TCPIP on the same PC?

It's the easiest way to get multiple languages to communicate. Then (if we decide) it would be easier to make it possible to play the game over the Internet or Local Network.

[Gabriel Fleseriu]

Originally posted by DHillard
I've been following this thread for a few days now and thinking...

If the clients and server are to be run on the same machine, ie. not connecting via TCPIP over the internet like Quake and such, then why all the complication by using TCPIP on the same PC? Also, if this is supposed to be "turn-based", what would constitute a turn? Processing time? Server requests a "move" from each client in turn?

Why not consider the "server" processing the client scripts and have the server an "interpreter" of sorts. Thereby being able to define your codewar "language" that the clients are written in. That way, the competetors would submit ascii text files to be "played" by the server. Since nobody else would see the results anyway, why the trouble writing a graphical visualization?

This approach would definately eliminate any chance of hacking the environment as has been mentioned previously.

/rambling

David
Basicly, we need a method of inter-process communication that is applicable to C++, VB, Java and C#. Local TCP/IP was chosen because it is simple to use from each language we aim at.

A turn has two parts:
(1) Server tells each creature some basic info - what the creature "sees" and what the result of the last turn was.
(2) Server asks each creature what it wants to do next. With this info, it computes the turn result, and proceeds with (1).

I see two problems with the approach of a server running scripts:
(1) It is very hard to "invent" (and implement!) a language powerfull enough to permit writing an AI
(2) Most participants (me included) prefere to use their favorite programming language.

We could have restricted the game to C++ only (we want to avoid such a limitation by all means), and each participant had to check in a source code file, which, compiled along with the core of the game would result in "a fight". This is equivalent to what you say, with C++ instead of a script language.

[Goodz13]

Why not consider the "server" processing the client scripts and have the server an "interpreter" of sorts. Thereby being able to define your codewar "language" that the clients are written in. That way, the competetors would submit ascii text files to be "played" by the server.


I beleve the purpose to this project is to test programming abilities in a language that they're most confortable, not to make a whole new scripting language.


Since nobody else would see the results anyway, why the trouble writing a graphical visualization?

Nothing is written in stone yet, but I beleve we want to keep the possibility open for a game that people can see whats going on. This is a project that will probally get expanded, and who knows, one day you could play it from your own computer (where you would want to see what's happening) against another member via the internet.

[mwilliamson]

What if we change the active x control to a .dll. Will that make things easier for vb/java?

[Gabriel Fleseriu]

Originally posted by mwilliamson
What if we change the active x control to a .dll. Will that make things easier for vb/java?

An ActiveX control actually IS a dll -- or is contained by a dll (one dll can contain more than one control). And an .ocx file also is just a dll, you know.

[Goodz13]

I think I have it communicating properly.

I just edited my first program to communicate with the C++ program that Gabriel wrote.

[Goodz13]

Forgot to upload it.

The jar is within the zip. Double click it and it should work.

PS. Please ignore the sloppy code in this one. I just wanted to get it communicating.

[Yves M]

Is it just me, or did you forget to put the .jar inside the zip file ?

[Goodz13]

Shoot... Uploaded the rong one.

[Yves M]

Great, that works like a charm :)

[Gabriel Fleseriu]

Sorry for the ignorance, but I have no idea how to test the Java client. What do I need to do?

[Yves M]

Go to java.sun.com and download the J2SDK.

here is a link (http://java.sun.com/j2se/1.4.1/download.html)
Then you can double-click on a .jar file and it will execute like a windows program.

[Gabriel Fleseriu]

Huh? I was able to open the JAR file with WinRar?! AND to extract files from it. Isn't that an archive?????

[Yves M]

Yes, a .jar file is just a packed archive with all the necessary classes to execute a whole program.

[Gabriel Fleseriu]

Thanx, works like a charm.

[dimm_coder]

The first thing I want to ask, is my English so bad that it doesn't allow for another
user to understand me right and even it beats all wishes to read my posts here? :(

If no, I want to place here some of my thoughts.
As I've read above, server simply asks every creature(in another process via TCP) step-by-step without any time restriction, then some creature can seize the process time longly. This means server must preserv such situation or judge will control creature sources for this.
So the game will be turn-based, right? I understand, that server by-queue asks cretures for the next step.
Is any creature gets all information about around situation (what it sees, hear,...) and then only need to send info about the next step to the server? So, a creature doesn't need to get any advanced info from the server, before the next step?
Another, who will write code for the host? How we will orginise work for it?

[Gabriel Fleseriu]

I wrote a bit of pseudocode that drafts the main concepts:

/*This is pseuodo-C++*/

struct creature_stats
{
char attack;
char defense;
char food_consumption;
char max_life;
};


/* a creature can face one of these directions: */
enum directions
{
north;
west;
south;
east;
}

/* this is roughly the data the server holds for each creature: */
struct creature
{
char id_lo;
char id_hi; /*low and high byte for id -- so we can have more than 256 creatures */
directions facing;
char x;
char y;
char life;
char food;
/*....*/
};

/* this is the data the server holds about each client (roughly)*/
struct client:public socket_derived_class
{
char species; /* identifies the client*/
creature_stats stats;
std::container<creature *> creatures;
/*.........*/
};

/* a cell can contain one of these things: */
enum vision_what
{
off_bounds; /* outside of the arena */
occluded;
nothing;
wall;
food;
creature;
};


/* if another creature is sighted, this is the info the creature gets: */
struct vision_creature
{
char species;
char id_lo;
char id_hi;
char life; /*in % */
directions facing;
};


/* this is what a creature can decide to do: */
enum next_move
{
move; /* if there is a creature in the target cell move == attack */
turn90;
turn180;
turn270;
harvest;
rest;
/*...further enhancements, like breed*/
};

[MPRoberts]

I would like to help with the writing of the application, I know both VB and C++ so I will be able to bridge the gap well and I also am in the process of learning JAVA. It would be a great experience so just send me a message if you want my help, I would be glad to give it in any way possible.

[BertW]

Hi,

why you dont use simple strings over TCP/IP for your communication?
Using bytes or other internal datatypes causes always difficulties with different languages on diff. operating systems (byte ordering, ...). Text strings and TCP/IP is available on all systems.
Ok, parsing is a little bit more difficult but at the other side can easily be extented.

Example:

MOVE NORTH
ATTACK
SLEEP

Bert

[sonix]

A word about protocol to use :

Some time ago, I need to interconnect different piece of software writen in C++, PHP and Java.

The best canditate I found was XML-RPC.

There are client and server lib available for many language and learning is very easy.

Have a look at http://www.xmlrpc.com/

[alex0]

as u said this project is not about a specific programming language...... so u must make it accesible!!!

the best thing to (how to implement the communication in this) do is to define a protocol like (irc ,ftp, smtp)

i worked in MFC with those and it was easy to emulate a client for those protocols (with the basic operations) for the others languages is allmost the same thing because the socket implementation are quite the same or similar.

The structure is the same the TCP\IP is the same.
If u decide to use this a hole bunch of other programmers will be able to design new cilents in different languages (from VB Java even PHP and even Flash MX that has some sockets implemetations) for this costum rules.

The rules of the game become protocol commands an nobody can cheat this way.

The client could be home made from base because we are programmer and we don't need special effects an opengl or directX (the quest is to design the best AI for this rules). We have the rules and the RCF for the game we right our cilent in what ever language we like

COM is good to but is unreachable for some languages an mediu skill programmers :(

A TCP/IP design protocol will ease your work also in the design of the Server.
Keep the MFC in the design of the server and use inherit classes from CSocket (the old fashion way) because they are multithreading if u implement the protocol in them instead of simple CSocket or CFileSocket.

[Marina Vaillant]

Hi,
A lot of different things are discussed in this only thread... wow.

I begin to see better the interface for the creature. :)
But this may be moved to another thread, though ;) So I will not discuss it here. But I have ideas too.

For communication, it's ok for TCP/IP for me. I would like to have Java users opinion. As Java and Corba are made for being used on any platform, and communicate with anything, maybe it can be glued to the VB/C++/C# beginning using a specific Corba interface, can't it?

I have not downloaded any example yet.

Marina