Server and C++ client skeleton code -- BETA

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,

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 :)

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 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:

Quote:

---

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.

Quote:

---

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

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.

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.

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.

Quote:

---

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.

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.

Quote:

---

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...

Quote:

---

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.

Quote:

---

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.

Quote:

---

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...

Quote:

---

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...

Any news or is the project lost under a pile of urgent things to do??

Marina :)