Page 1 of 1
Server-client design ideas
Posted: Sat Dec 08, 2007 8:26 pm
by Johnny D
Hello everyone. Me and some friends are making a game for our high school final project and it's going to be played online. Our idea is something like this: the player starts the game and logins to a server (something like war3 battlenet only it's going to be a 3d city) there are going to be 2 city's for both faction's. In the city player's can buy item chat with other player and have some friendly duels and train. Now the idea is (just like war3) a player stars a war (creates a game 2vs2, 3vs3, 4vs4, 5vs5) by talking to an npc 5 player's from one faction vs 5 player's from the other (player's can join just like dota

) and then the game starts on a little separate map. Now my problem is in designing this server-client. Any advice, suggestions, ideas are welcomed

and if possible some libraries (i know of raknet and enet).
(forgot to mention the characters and city doesn't resemble war3, they're just like the one's in wow or morrowind)
Thank you.
Johnny
Posted: Sat Dec 08, 2007 11:13 pm
by xavier
Raknet is a reasonable choice for this -- it provides many of the high-level constructs you'll need, which Enet does not.
Basic design I would suggest is single server for lobby/matchmaking and then run each launched game instance peer-to-peer. It can be a simpler method than trying to implement a server-authoritative model for N concurrent game instances.
Posted: Mon Dec 10, 2007 9:58 am
by Johnny D
thanks xavier

Posted: Mon Dec 10, 2007 11:52 am
by Kristian
You can also have a look at zoidcom.de which providews a raknet like solution...
Posted: Mon Dec 10, 2007 8:44 pm
by KungFooMasta
The zoidcom link looks interesting! But they haven't decided on any kind of price for a commercial version, at least not that I saw. (discouraging

)
Is there any obvious reasons why its not a good decision to have a host do all the calculations, and just update peers visually? (under 15 players) I'm wanting to take the enet route, but I know it will take a lot of work, especially with NAT and figuring out how exactly to send the data to/from clients.
Posted: Mon Dec 10, 2007 9:48 pm
by xavier
No reason in particular, other than time constraints mentioned by the OP:
making a game for our high school final project
For the number of players they are talking about a P2P system is performant enough.
Posted: Tue Dec 11, 2007 9:43 am
by Kristian
KungFooMasta: In some middleware there is no direct price. You have to do a deal with the company.
Posted: Tue Dec 11, 2007 1:30 pm
by Johnny D
Every host will have a max of 10 players i think that can be handeld simple enough. The main server is my main worry because the city is a bit big and min 50 npc's + about 50 players and a total of 2 city's and our server is not very performant

Posted: Tue Dec 11, 2007 6:10 pm
by Quall
50 people per server should be fine. If you expect a desktop to handle 10 players and in the engine, then the server should be able to handle 50 players without the things that only the client needs.
Although, for what you are saying, this looks like a bit much for a high school project. I hope your final is 3+ months from now. Unless your course is a game-design class, i wouldn't even say that 3 months is enough time. But then again, I do not know your game design history or how many members are on your project.
Posted: Tue Dec 11, 2007 7:45 pm
by Johnny D
The project is due for end of may beginning of june 2008. The server doesn't
have to work only peer to peer but we just want to make it a little more challenging for us and we hope to finish the full game in are first year at college with all the features and stuff.

Posted: Wed Dec 12, 2007 3:21 pm
by Tubez
Depending on the time per week you can dedicate on this (you are not on it ful time are you?) the size of the team and your respective skills and motivation, you might have to try and limit the scope a bit. What you have planned out here is a truckload of work. You will have to work realy really really hard to do it in six months.
At least plan things so you get the essential things done first. If you do that you can cut features at the end if you have to.
Posted: Thu Dec 13, 2007 2:42 am
by kjs335
Tubez wrote:Depending on the time per week you can dedicate on this (you are not on it ful time are you?) the size of the team and your respective skills and motivation, you might have to try and limit the scope a bit. What you have planned out here is a truckload of work. You will have to work realy really really hard to do it in six months.
At least plan things so you get the essential things done first. If you do that you can cut features at the end if you have to.
Ditto, the amount of work for this to work seems to be on par with commercial games made by professional people. I've tried to make something similar to Counter Strike and realized that there is just so much work to make it work and polish it to high quality. Since Ogre is not even a game engine and does not have the necessary components to make a complete game by itself, it's way beyond the scope of an average joe from high school as you have to deal with 3D matrices, quaternions , class inheritance, physics (adjusting friction, torque, etc to make things move smooth and nicely), etc.
It's interesting that I'm probably the same age as the original poster as next year is my last year in high school.
Posted: Thu Dec 13, 2007 4:22 am
by cybereality
This sounds like an interesting project and I wish you the best of luck, but I would have to agree with others that this is quite an undertaking. The only advice I can give is to shorten down to the core gameplay and add features from there. For example, does it really have to be a 50-man server? Limiting it to say 8 players, might be more practical. Don't make 2 cities, make one city really good. Its about quality, not quantity. No one will be expecting 40 hours of gameplay or an MMO for a student project. By limiting the scope you and your team will be able to put more time into polishing what you have to higher levels.
Also, make sure you prototype early and often. Make sure the artists are in touch with the coders and testing assets constantly. You can run into problems very quickly with artists exporting assets with incorrect pivot points, scaling, incompatible animation, etc. The earlier you get a solid art pipeline, the earlier you will notice potential problems. Especially when you have to be the one to tell the animator that all the wonderful animation he did with a physique skin modifier won't work.
Posted: Fri Dec 14, 2007 9:08 am
by Tubez
it's way beyond the scope of an average joe from high school as you have to deal with 3D matrices, quaternions , class inheritance, physics
While I agree that this is probably beyond the average joe from high-school (and let's be honest, the average undergrad joe too probably, unless they major in something technical), I get the distinct feeling that the poster is not your average joe.
The simple fact that he's posting on this board means something.
That said, I found it helps to limit the scope *a lot* early on. I've been messing around with games and 3d graphics since I was a wee kid, but i never got anything finished until I decided to limit myself to a very very simple game concept (in my case, 3D pacman).
You will be surprised how much work even a simple game like that can be. If you have time left over, you can add embellishments till you are blue in the face (did anyone say rocket launchers?). If past performance if any indication though, there wont be much if any time left over.
Another small piece of advice:
Multiplayer sucks up time. It's prone to weird bugs and a nightmare to test. This is certainly one of the features I'd put on hold.
I'm not saying you are not smart enough or capable enough to pull it off. I'm certainly not saying you are not old enough or experienced enough to pull it off. I've seen very young people do pretty amazing things.
But, like everyone else, you have to try and bite off what you can chew. This just sounds way to ambitious for a small team to do in such a constrained timeframe.
Also, unless you go to a special kind of high school where everyone is supersmart and really into programming, I cant imagine that all the other guys in your team will be able to pull their weight. When crunch time comes, it will most likely be you doing the crunching.
EDIT: Oops, i forgot a 'not' in there somewhere, which twisted the whole thing around. Much better now.
Posted: Fri Dec 14, 2007 9:41 am
by syedhs
Yes I agree - you have to cut features so that initial scope is small - yes very small, but acceptable and playable. Once you have got that phase built up, you will be in much better position:-
1) to expand the scope whilst in the same thing, delivered within the timeline.
2) to judge which features that can be added in subsequent iteration - many many time, features you thought so cool to be added turned out to be 'ahh.. why I am wasting my time on this etc etc'. But of course, by that time it is too late because you have already used up your time to develop it.
Re:
Posted: Mon Jan 26, 2009 4:46 pm
by mickeyren
xavier wrote:Raknet is a reasonable choice for this -- it provides many of the high-level constructs you'll need, which Enet does not.
Basic design I would suggest is single server for lobby/matchmaking and then run each launched game instance peer-to-peer. It can be a simpler method than trying to implement a server-authoritative model for N concurrent game instances.
Hi,
I'm bringing this topic up because I'd like to have a little more elaborated explanation on what Xavier said here.
I want a auto match battle like those we found in Command and Conquer / Warcraft games - where in you click on a button and the game finds an opponent for you.
Is this what Xavier suggested? If so, can someone elaborate more on how to do that?
Re: Re:
Posted: Mon Jan 26, 2009 5:43 pm
by Penguin
mickeyren wrote:xavier wrote:Raknet is a reasonable choice for this -- it provides many of the high-level constructs you'll need, which Enet does not.
Basic design I would suggest is single server for lobby/matchmaking and then run each launched game instance peer-to-peer. It can be a simpler method than trying to implement a server-authoritative model for N concurrent game instances.
Hi,
I'm bringing this topic up because I'd like to have a little more elaborated explanation on what Xavier said here.
I want a auto match battle like those we found in Command and Conquer / Warcraft games - where in you click on a button and the game finds an opponent for you.
Is this what Xavier suggested? If so, can someone elaborate more on how to do that?
For match making, I would calculate a rank (created from win/losses) for each user and just take two people have a similar rank, put them in a game.
Re: Server-client design ideas
Posted: Tue Jan 27, 2009 3:07 am
by mickeyren
How do i put them in the game in the first place?
Lets say I use raknet (which I actually do), There's a separated server app, which I will use as a lobby I assume.
Then the client apps initially all connect to the server app right?
After that, do i detect if there are 2 client apps who would like to play a game? If so, do I send both client app each other's ip address and randomly have one of the client app act as a new server? That means, both the application now has 2 connections, one to the lobby server, and another to each other?
Re: Server-client design ideas
Posted: Tue Jan 27, 2009 10:06 am
by lonewolff
Sounds like a cool project. I could love to hear how it progresses.
As for networking I have always been a fan of pure Winsock
As you can probably tell from my sig

Re: Server-client design ideas
Posted: Fri Jan 30, 2009 10:47 pm
by DanielSefton
mickeyren wrote:Then the client apps initially all connect to the server app right? After that, do i detect if there are 2 client apps who would like to play a game? If so, do I send both client app each other's ip address and randomly have one of the client app act as a new server? That means, both the application now has 2 connections, one to the lobby server, and another to each other?
If you're referring to a peer-to-peer architecture, then I can't comment. But you don't connect clients to each other. Every client connects to a single game server, and the server sends each client information about what is going on. E.g. Player X moves to position Y, Player X's position is sent to the server; the server then broadcasts position Y to all clients, and in turn the clients update. And in the case of an FPS, you will need to implement some kind of interpolation to make for smooth gameplay.
I don't understand what you guys are saying about the fact that supporting more/less players affects the amount of work involved. That's just ridiculous. Providing you've designed it right, the number of players is absolutely not an issue. You can design it with 2 players, and it will still be the same amount of work as it would be to support 50 players. It's not like you need to reprogram the game to support more/less players. It's just a matter of replication, and what the
server can handle.
I'm not sure what your programming experience is, but it's absolutely possible to achieve what you are proposing in 6 months. RakNet+Ogre makes your life easy, relatively. But seriously, your direction has probably already way exceeded other people doing the same course -- do they really expect you to take on something this complex for
high school? That's more like University final standard where I'm from. Out of interest, what subject are you studying, and what are the
actual requirements? Over-complicating things can seriously affect your grade. Make sure you're only doing what they ask for. And DON'T think that because you are taking on something a million times complex than the requirements that you will get a better grade.
Re: Server-client design ideas
Posted: Fri Jan 30, 2009 10:58 pm
by jacmoe
Just wanted to direct your attention to the fact that the OP posted this over a year ago. Mickeyren brought the topic back up. AFAIK, he haven't said anything about time frame nor school project.

Re: Server-client design ideas
Posted: Fri Jan 30, 2009 11:01 pm
by DanielSefton
jacmoe wrote:Just wanted to direct your attention to the fact that the OP posted this over a year ago. Mickeyren brought the topic back up. AFAIK, he haven't said anything about time frame nor school project.

Ah. Whoops.
That's why gravedigging is evil.

Re: Server-client design ideas
Posted: Fri Jan 30, 2009 11:08 pm
by jacmoe
Actually, you can blame Lonewolff. He's looking forward to seeing how this project turns out.

Re: Server-client design ideas
Posted: Fri Jan 30, 2009 11:48 pm
by lonewolff
Funny, I didn't look back to see the post date.
But I forward Jacmoe's blame to mickeyren as he is the 'grave-digger'
I guess the big question is 'How did it turn out then?'
