Click to See Complete Forum and Search --> : Server and C++ client skeleton code -- BETA


Gabriel Fleseriu
January 21st, 2003, 10:38 AM
Hi all.

I wrote the code for a single threaded server and a C++ client. The code is very crude and needs to be refined a lot. I think that we probably will have to re-design large portions.

Both the server and the C++ client are MFC, because I use CSocket for the TCP/IP communication. The server does not implement any logic for computing the turn state and the client has no AI at all (it will have all creatures rest every turn). Yet they exchange all messages that they would in a real game. Have a look to the codewar.h file -- it's probably the most relevant.

I wanted to release the code ASAP, so I didn't take the time to polish it up. Many calls are not guarded and because the clients messages trigger the servers actions (without a timeout), the server will hang if the client fails.

Comments, ideas on how to improve both the design or the implementations are welcome :).

Enjoy,

mwilliamson
January 23rd, 2003, 11:32 AM
Why not change
const short turn90 = idle + 3;

To the actual directions, it makes programming simpler i think. You are giving directions in N,E,S,W, but the programmer must figure out which way he is facing and then ofset to go in the other direction. Example:

Food is to the north.
Action: turnN;

but as you have:
Food is to the north.
Action:
Which way am i facing?
How many degrees do i need to rotate to face north?
turnXX.

Or put both in :)

Gabriel Fleseriu
January 23rd, 2003, 01:28 PM
Actually I am not sure that transmitting the exact x, y position of the creatures (along with their facing direction) to the client is a good concept. This would allow the client to develop a "common inteligence" for its creatures. The creatures should have to explore their environment by themselves to find out where the margines lie and where their allies are. As a matter of fact, in nature, herd or pack animals don't receive their (and their "collegues") GPS co-ordinates... :)

Gabriel Fleseriu
January 27th, 2003, 04:23 AM
I see that the code was downloaded 21 times -- still I got only one feedback post. What's up, guys? Are you not interested any more? :confused:

Yves M
January 27th, 2003, 09:42 AM
Actually I am not sure that transmitting the exact x, y position of the creatures (along with their facing direction) to the client is a good concept. This would allow the client to develop a "common inteligence" for its creatures. The creatures should have to explore their environment by themselves to find out where the margines lie and where their allies are. As a matter of fact, in nature, herd or pack animals don't receive their (and their "collegues") GPS co-ordinates...
I definetly agree on this.

Gabriel, I'm sorry, but I'm really busy at work since the last week and probably this week as well. I'll try and think of some code for generating the 'playing field' and some of the rest of the logic that is still missing.

Gabriel Fleseriu
January 27th, 2003, 10:31 AM
Originally posted by Yves M

I definetly agree on this.

Gabriel, I'm sorry, but I'm really busy at work since the last week and probably this week as well. I'll try and think of some code for generating the 'playing field' and some of the rest of the logic that is still missing.

Oh, no problem :) I was joking in my last post -- I rather wanted to push the thread up in the list. I was also wondering whether I should make a sticky out of it ;)

As I have told you a few days ago, I am not very happy with the current code design. I think the code is too tightly coupled and the fact that the server is single threaded is a major flaw.

In the meanwhile, I will read the documentation about the correct use of MFC socket classes in a multithreaded context and write some code. I also am pretty busy, because I had the flu last week and now I have to catch up with a lot of things.

I am still curious what the other 20 guys who downloaded the code have to say... :D

Goodz13
January 27th, 2003, 11:02 AM
I'm sorry Gabriel, I downloaded it when you first put it up, but then things got very busy for me and I haven't even had time to look at it yet.

I had time this weekend, but with the way things were, I didn't want to even look at code.

Infact, I didn't even want to turn on the computer, but I couldn't help myself. It was calling me Derrick, Derrick, What's rong? You don't love me any more?:D

I'll try to look at it tonight.

galathaea
January 27th, 2003, 01:24 PM
I downloaded it as well, and similar to the others got stuck with a bunch of work that has delayed me from commenting. Some of your concerns about the server seem justified but not to the extent of stopping progress on a first session. My main delay on the project has been work and some rules confusions which are beginning to be cleared up looking at the server code and the subsequent posts. But I do have a basic AI designed (well, designed on paper with a little implemented and taken from older code of mine), and although I will be concentrating on my other non-work project over the next week, next weekend will afford me a great opportunity to finish up a preliminary creature. From the interest I have seen, I bet you anything that the first competition will only be a few weeks away.

Goodz13
January 27th, 2003, 08:04 PM
I have a question about the client/server programs that you posted.

Are they passing struct's back and forth?

If you are, it makes things a little more difficult for Java. But I can write a Native Library (DLL) using Java Native Interface.

Gabriel Fleseriu
January 28th, 2003, 02:41 AM
Originally posted by Goodz13
I have a question about the client/server programs that you posted.

Are they passing struct's back and forth?

If you are, it makes things a little more difficult for Java. But I can write a Native Library (DLL) using Java Native Interface.

Yes, the C++ code reads/writes structs onto the sockets, because it is the easyest way. But basically they are just a byte stream. Most of the structs have all data members declared as short (2 bytes) -- that means that you can also use an array.

The big pain in the neck will be the VB code, as the WinSock control can only read/write arrays of bytes. OTOH, the control can read one Integer at a time -- it may be more simple to use a row of Read() commands... We'll see.

Goodz13
January 28th, 2003, 09:59 AM
I think I should be able to do it one of 2 ways. Create a class(es) that mimic the struct's and pass them or read/write the bytes and convert them after they are read. I'll give it a try tonight.

If either works, I'll be very happy. I try to stay away from JNI. My C++ is a little (very :) ) rusty.

Andreas Masur
January 28th, 2003, 06:42 PM
Originally posted by Gabriel Fleseriu
As I have told you a few days ago, I am not very happy with the current code design. I think the code is too tightly coupled and the fact that the server is single threaded is a major flaw.

In the meanwhile, I will read the documentation about the correct use of MFC socket classes in a multithreaded context and write some code. I also am pretty busy, because I had the flu last week and now I have to catch up with a lot of things.

I am still curious what the other 20 guys who downloaded the code have to say... :D
Well...I did not download your code yet...but I am busy at work as well... :D

Anyway...may I ask a question? As you might have noticed I did not follow this project pretty much the past days and weeks...but...why basically decided we to use the MFC wrappers for sockets?

Adding multithreading to the server is pretty simple...I think I could help with this...although I did not do it for MFC wrappers yet...

Let me see whether I have time over the weekend to take a look...

Gabriel Fleseriu
January 29th, 2003, 02:24 AM
Originally posted by Andreas Masur

Well...I did not download your code yet...but I am busy at work as well... :D

Anyway...may I ask a question? As you might have noticed I did not follow this project pretty much the past days and weeks...but...why basically decided we to use the MFC wrappers for sockets?


Well, we actually didn't decide to use the MFC wrappers. I used them in this first implementation, because I am pretty familiar with MFC and it seemed to be the fastest solution. By no means is the use of the MFC socket wrappers (or the use of MFC at all) a definitive decision. I don't have experience with the raw socket API -- if we were to use that I'd need some help for the implementation.

Adding multithreading to the server is pretty simple...I think I could help with this...although I did not do it for MFC wrappers yet...

Let me see whether I have time over the weekend to take a look...

There are a few good articles in MSDN about the socket wrappers and multithreading. As I use a MSDN CD, I cannot post the links (yeah, I'm too lazy to search the net right now ;)).

However, I think that we need to refine the protocol first, e.g. see my comment about sending the x, y co-ordinates of the creatures to the client a few posts ago.

Andreas Masur
January 29th, 2003, 03:56 AM
Originally posted by Gabriel Fleseriu
Well, we actually didn't decide to use the MFC wrappers. I used them in this first implementation, because I am pretty familiar with MFC and it seemed to be the fastest solution. By no means is the use of the MFC socket wrappers (or the use of MFC at all) a definitive decision. I don't have experience with the raw socket API -- if we were to use that I'd need some help for the implementation.

Well...I see. As it is just the opposite on my side - I did very little with these MFC wrappers but did a lot with raw sockets - I am able to help you there...

Originally posted by Gabriel Fleseriu
However, I think that we need to refine the protocol first, e.g. see my comment about sending the x, y co-ordinates of the creatures to the client a few posts ago.
Ack...

Marina Vaillant
May 6th, 2003, 10:37 AM
Any news or is the project lost under a pile of urgent things to do??

Marina :)

Gabriel Fleseriu
May 6th, 2003, 11:42 AM
Originally posted by Marina Vaillant
Any news or is the project lost under a pile of urgent things to do??

Marina :)

The pile is very huge, I'm affraid...:rolleyes:

Marina Vaillant
May 12th, 2003, 10:00 AM
well, ok. So is mine anyway. :)

Marina Vaillant
July 2nd, 2003, 08:18 AM
I post here only to remind people of this project ... :)))

Kuruto
July 31st, 2003, 10:41 AM
Hi,

The last post was done on 07-02-2003. Long time ago...

My love for this kind of game started when M$ introduced that .NET terrarium. But since .NET was new (and thus difficult), I just read what the purpose was. :eek:
In the mean time, RobotWars (that TV show with REAL robots) has been introduced in The Netherlands too, so I'm apparently not the only one who loves this kind of game.

Well back to software, I have read a lot of posts, and I must say that the first step should indeed be creating a working framework. The game should be turn-based, and the framework should be client-server. The client being the robot, and the server being the game where a client can register. The communication should be based on TCP/IP sockets.

Well, enough talk about concepts. I have only seen one post with a proposal for the framework and I thought: lemme post one too. So I started writing some OO code (C++) for the framework starting with the server, and two days later and a lot of sleep less I have a working multithreaded server accepting registrations from clients (read robots or creatures or whatever you would like to call them). The messages that are sent are structs (cf. the framework that was posted). The client starts with a connection and sends a registration command/struct. The server responds with an acknowledge command/struct.
The principle is that a client can send a command to the server only if the server sends a command first (except for the first registration command). You can interprete it like this: the server asks the client if he has something to send. This way, each client gets one turn and the server controls it.

But now I'm thinking: is this thread still active? Are people still interested in this project? So I'm NOT going to post the code yet, but wait until there is some response. :D

Also it would be too easy to look at the code and copy it. So I suggest you all start writing some code. Dig into threads and sockets and enjoy the trouble that comes along with it.
[Hmmm, I sound evil]

regards
Kurt

Marina Vaillant
July 31st, 2003, 11:31 AM
I'm interested. But when I posted the "before-the-last" message, I've been told that the project is still on, but people have a lot to do outside, and are not working much on this project yet.
Neither am I.
But yes, I'm interested, as beginner as I feel among you gurus.

I have another personal project on my heap of todo things, that have not moved forward a lot since 6 months... But I'll keep them on. :)

Marina
PS: you see, subscribing to a thread is useful! ;)

Andreas Masur
July 31st, 2003, 11:46 AM
Originally posted by Kuruto
But now I'm thinking: is this thread still active? Are people still interested in this project? So I'm NOT going to post the code yet, but wait until there is some response. :D

Well...as Marina already said...basically the project is more or less ongoing...however, many of us are pretty busy these days and the project got somewhat fall asleep a little bit. I can only speak for myself...I do not see much chances that I will have much time the next days/weeks...

Kuruto
August 1st, 2003, 06:02 PM
Wassup developers,

My server is accepting client connections (socket based) together with client registrations (a struct that is sent). The client may only send when the server says so (turn based).
Now I'm trying to get a robot walk inside the arena (the arena is a vector of vectors; cf. the first framework). This is basicly sending a struct from the client to the server when the client gets a turn. So far so good. But now I'm kinda stuck.
The server keeps track of the state the robot is in; state is in this case just the position and the heading on the grid. Every time the robot sends a command, that state needs to change.
When the server gets a command from the client, that command is parsed and then a function is called which must change the state of the robot. That function should be pretty flexible, since more than walking in the arena will be allowed. I'm trying to find a way to make this easy and flexible. Perhaps an implementation of a state diagram might work. I don't know.
Fact is that a lot of different commands are/will be possible, and the state should be changed occording to the command.

In case of walking in the arena, it's not just changing the coordinates. It's also checking if a wall has been hit. Checking if you are being attacked by another robot. Checking if there is food where you are standing. Etc, ...
And this is just for walking around.

Anyone with an idea? :confused:

regards,
Kurt

PS: I will post my code as soon as I have a working version. "Working" means in this case walking in the arena.

Kuruto
August 5th, 2003, 06:46 AM
Hi,

Here's my first attempt.
I hope you will be able to read it. :eek:
It's the server-side of the game.
At the moment only moving forward is possible.
If the wall is hit, then the client is notified of this event.

If you want the client too, just let me know.
But I think it's better to write one for yourself.

May I ask to fill in this poll after you have look at the code?
http://www.santele.be/codeguru/index.php

If you are not able to connect to the website, then you are probably behind a firewall.
The webserver is running on port 8080.
And due to the extreme hot temperatures in Europe, the server is down at night.

regards
Kurt

fractus
November 5th, 2003, 06:21 PM
Hi, this project sounds interesting.

I have some ideas for a similar game.

have as few rules as possible (hardly any) but:

- load all of the competitors at one time at the start of the match and allow it to run on individual PC's, possibly by sending a file containing all the competitors for the current match.

give the "creatures" time-slices to run within - every creature gets an equal sized time slice to do processing in. Possibly control this by using an interpreted language. This is the basic rule of the game. - perhaps based on the size of the creature

allow the creatures to do almost anything. For instance, if you want your creature to be able to scan all surronding squares then it can. But that will take a lot more time than a creature that scans only a single square.

So a creature that scans only a single square will be able to move a lot faster than a creature that scans a whole bunch, but the latter creature will be a lot smarter....

have the creature move by replicating itself into the next square(s), and removing itself from the previous square(s)

the "squares" are equal sized containers for code - say 1000 lines. So a large creature takes more square than a small one.

the environment contains obstacles....

the basic resource is time slices. the creature can get more time slices by consuming other creatures and food items in the environment.

put markers (the heart) in the creatures. Once something has eaten the creatures marker, it's dead.

a creature has to be right next to another one in order to take a bite out of it.

(this might be too hard) when a creature take a bite out of the another one, it deletes some of the code of the creature it bit...

Kuruto
November 6th, 2003, 05:11 AM
Here's the server as promised a long time ago :p
Just copy it into some dir.
The client must be copied into the same dir, coz it shares the 'CodeWarCommon' directory.

have phun
Kurt

PS: The few ppl who did take a look at the code, may still fill in this poll.
http://www.santele.be/codeguru/index.php

Kuruto
November 6th, 2003, 05:13 AM
And here's the client as promised a long time ago also :p
Just copy it into the same directory as the server, coz it shares the 'CodeWarCommon' directory.

have phun
Kurt

Krishnaa
June 3rd, 2006, 11:30 AM
Hey Guys,

No one has posted anything since Nov. 2003 here, is nobody working on it now ?

I am sorry if I am asking this in wrong place. :)

thanks,
K

Kuruto
June 3rd, 2006, 02:16 PM
Correctomundo. I'm the last one who posted, and then nobody ever replied.
Are you interested?

K.

Krishnaa
June 5th, 2006, 06:51 AM
I would love to, but I don't think I am right guy for this type of project, I am not into game programming at all.

Kuruto
June 5th, 2006, 07:05 AM
I am not into game programming at all.
Me neither :)
But it's interesting to learn.

Krishnaa
June 5th, 2006, 08:02 AM
It sure is :thumb:

I have been watching this project since long time, and I was thinking of joining but when I started seeing problems reagrding managing time for this project. I think same will happen with me, so decided not to commit anything.

Nexeh
May 6th, 2007, 08:08 PM
This seemed like a really cool project. Where does it stand currently?

Kuruto
May 7th, 2007, 05:55 AM
This seemed like a really cool project. Where does it stand currently?
You are right about this: the project is cool indeed.
I have made a client and a server application implementing the basics (based on Gabriel's code). And that's about it. Nothing more has been done since then...

Krishnaa
May 7th, 2007, 06:16 AM
And what do this server and client do ?

Kuruto
May 7th, 2007, 07:30 AM
And what do this server and client do ?
As far as I remember correctly the client and the server exchange positions (of clients of corz) and some basic actions.
So you can connect with two clients to the same server and walk around. I think I even implemented eating and fighting as basic actions. Eating could be done when you (as a client) were walking into a square with food properties. And fighting could be done when another "robot" was nearby.

I had (lucky me) some time left afterwards and I have played around with Direct3D. On the server application I have added a 3D view of the "arena" and you could see the clients walking around.

Krishnaa
May 7th, 2007, 08:20 AM
Okay, I tried connecting 2 clients to server, I dont see them walking, where are they summoned after connecting ?

Kuruto
May 7th, 2007, 08:45 AM
Okay, I tried connecting 2 clients to server, I dont see them walking, where are they summoned after connecting ?
I thought I saw some compiling errors... :ehh:
I guess that was fixed easily and you have edited your post :thumb:

Anyway, the "see" part was done after I had posted the client and server. I had some time left afterwards and I added the Direct3D view. This "add-on" was never posted though (as far as I remember; and I can't check it right now). You can only see the clients connecting if you are debugging the server.

The posted client and server are a working framework with just basic functionality. For this point on, you can add more functionality. The biggest and most attractive part is always the graphical part. And this is non-existing at the moment...

Krishnaa
May 7th, 2007, 08:49 AM
I see some part of yellow grid in the right top on server, if I move mouse it moves and disapears.

Kuruto
May 7th, 2007, 09:37 AM
I see some part of yellow grid in the right top on server, if I move mouse it moves and disapears.
Serously? Then the 3D part was added. Forgive my brain, it's getting old :o

I wasn't able to get the start position of the camera right. So you will have to move around in 3D using the mouse until you get to see the "arena".
Try something like click-and-hold the left or the right mouse button and move left/right/forward/backward. This will change your position in 3D. You should be able to move in any direction in 3D.

Kuruto
May 7th, 2007, 09:48 AM
I see some part of yellow grid in the right top on server, ...
If I look at the downloaded server app, I can trace back what the colours mean:

switch( square->getType() )
{
case Square::Empty: box->setColor( 1.0f, 1.0f, 0.0f ); break; // Yellow
case Square::Border: box->setColor( 1.0f, 1.0f, 1.0f ); break; // White
case Square::Food: box->setColor( 0.0f, 1.0f, 0.0f ); break; // Green
case Square::Life: box->setColor( 0.0f, 0.0f, 1.0f ); break; // Blue
}

Krishnaa
May 7th, 2007, 10:31 AM
Thats ok, but why the grid is not laid in middle of the screen ? Is it by design that it apears in the top right ?

Kuruto
May 7th, 2007, 12:29 PM
Thats ok, but why the grid is not laid in middle of the screen ? Is it by design that it apears in the top right ?
The camera position needs to be adjusted but I never took the time to correct it.
If you would happen to know what needs to be changed, please let me know.

viperbyte
July 14th, 2010, 10:49 AM
Hello all. In the original post I read that the server and C++ client was done with MFC. What is or are the alternative approach or approaches in C++ besides MFC? Just curious.