   My own multithread server
  I finish my second year in computer science in 2 weeks and I want to start a project for this summer. First of all, I wanted to create my own game, but each time I was thinking about a cool idea, this game was multiplayer and I know it is really hard to do for a beginner. Then, I want to learn about multiplayer and network programming. So there is my idea, this summer I want to programe a little chat working woth socket.Step 1 - Peer to peer connection with someone who host and someone who just write his IP to connect one himStep 2 - Peer to peer connection using a server just as a bridge between them. (Ex : someone connect to pokemon.com and create a game, the other one connect on pokemon.com and join the conversation)Step 3 - Make this server multithread and create a little loby, where more than one person will be able to create a conversation)I know, visual basic, c++ and Java. I choosed c++ for this. My skill in c++ are so-so. I had 2 session about this language. For exemple, I know how to program my own object List, I did a object like <string>, etc. I never really worked with socket, this is why I want to start with a single connection between 2 poeple.I want to know what you think about my project.If you think my idea is bad (Like you think multithread with socket isnt, the best or something) Tell me what I should do instead.Or maybe just tell my where I should start if you think I am wrong.I am a total noob about network programming, I will accept all help.P.S If you don't understand some sentence in my text because my english is bad, just ask me to repeat it a different way.Thanks!   
  You know what might be a fun project for you and not too difficult?You could program a MUD!A MUD is a text based game where people log in using a telnet client and type commands to the server.The server sends them text back when people enter their room, or when they want to walk to another room the server will send a description of the next room.It'd be a nice project because you could use any telnet client to connect to your server, so you wouldnt have to code both client and server, you could just code server and test with a client that you alread know works.Also whats great about this is all communication between the server and client are just text, no crazy binary data structures or anything.   ;  Well, this is not really the kind of things I like to do... Ill not find the motivation to do a MUD..   ;  Well, you should start learning about:- Sockets- TCP/UDP- IP-adresses- Servers- Clients(I just saw somebody post this link, it's very usefull)and you're pretty much set for a very simple chatting program. If you want to chat with more than one person, add 'multithreading' to the list.I suggest you start of with a simple google search for 'Winsock tutorials', because WinSock is the easiest way (in my opinion) to start programming networked applications on windows.Good luck!   ;  I think those are good steps at the high level. You probably want to plan out smaller steps within each bigger step. For example, start by having one guy host and the other guy connect, without any data. Make sure that the connection going away at some point is handled correctly. Then add verification of the connection (that both sides are running the same version of the protocol). Make sure that version mismatch is handled correctly. Then add a mostly empty periodic message from each side, which contains "current frame number" and perhaps "current timestamp." Verify that you can keep the simulation clocks in sync. Then add text chat. Then add the ability to introduce "levels" -- the server says "now, clear everything, and load level X," and the client does that. Then add the ability to introduce entities -- "here's a player/NPC/bullet/pickup/whatever," and see them on the other side. Then add the ability to update state about those entities (movement, actions, death, etc). Once you're there, you're doing pretty well!If you don't already have a game, then another problem is going to be keeping entities, levels, display and GUI in sync with the networking. If you don't already know how to write a 3D GUI in C++, for example, you'll be learning that in parallel with learning networking, which will make things go slower. If you only have ten weeks for the summer, and you've not done a full game before, just completing step 1 in a robust and reliable manner, with a 3D game behind it, would be a pretty good result for the summer.;  I too have been working on a similar project for university. Here are the requirements:->A TCP lobby so players can chat whilst they wait for a game->Once all gamers have joined the server must tell the clients to load their games and switch to UDPI have found this project very challenging and have been pestering a lot of people on this forum. The two books I have found amazingly helpful have been:Programming Multiplayer Games by Andrew Mulholland and Teijo HakalaMUD Game Programming by Ron PentonThe first book is very good for explaining the WinSock library functions. The second book has very good explanations on how to make your own libraries for both sockets and multi threading. Don't be put off by the fact its for MUD games as it has very large sections on the basics, also Ron Penton has a very good way of explaining things which I found helped me a lot throughout this project.   ;  wrong post[Edited by - RenderMe on May 17, 2009 9:49:21 AM];  I would recommend writing a simple chat program first, to get a feel for how data is transferred real-time between client and server. When I first started learning about networking, I was trying to make a game. It was really difficult, because I had no idea how the structure of the game would need to be to allow efficient data transfer.Then I wrote a simple chat program. That made it a lot easier to understand the networking concepts, because it really focuses on the networking aspect. That allows you to really learn the concepts of networking, instead of trying to learn the concepts while also learning how to relate networking to other stuff.   ;  this is exactly what i was thinking of but with a game. Not a chat serverServer:2) Create Instances of land and buildings ( not meshes, the server doesnt need to see meshes, just numbers, i'll explain this idea later)1) Create instances of player objects and assign them to regions in your level (your server doesnt need to waste time sending packets to tell you that a player is 10000.0f distance from you, only recieve "incoming entity" packets to things within one or two regions of you.On the client side, Have a 3x3 grid and assign each "sqaure" to a region, and as you move into the next region, get the nearby regions. This lets you know what to draw in advance when the adjacent region becomes your current region. (your character is in the middle square if that makes more sense, its hard without a picture explaining my idea.The server will loop through each unit and when it finds two players near eachother, it informs those players of their presence. i use the word players and NPC's interchangeably. we could refer to them all as mobiles.anyways this is my theory and it is what i am going to work around. The idea of the grid is to just say "okay, i dont need to waste processor time rendering this now, but i know its there and if it moves in viewing distance (the middle grid square) i will draw it then.since i am not artist. i was going to retrieve locations and just draw bitmap images (small circles) on a square (representing a playing field.   