Kind of a vague and hypothetical sort of a question this.
I'm making my first online game (see my post in digital arts section) and I'm having a few concerns.
It's going to be a driving game, so I'd guess it's going to require sending information quite often, as everything moves more quickly than in an RPG say. On the other hand, I think all I need to send/receive is X_position, Y_position, animation, direction, angle, speed, and mass (less than in an RPG I would assume). Based on this information, does anyone have any guesses at how many players a game could reasonably support without breaking/going slowly/whatever else happens? What's going to be the limiting factor here - the number of objects etc, internet connection, something with the MOO___ object?
The other possibility is non-player-controlled traffic. I think I could get away with sending less information about these vehicles (X_position, Y_position, Direction, Moving?) by using 32 direction movement, constant speed, no skidding etc. Does this sound do-able? I'm fully prepared to ditch traffic all together if it is going to be an issue. I was just looking at another post about handling monsters in a mmorpg, which has made me think. Running a server isn't an option for me, so I'm intending to have each player be responsible for some (or none) of the traffic, depending on the speed of their computer/connection. Any thoughts on this?
Basically, I think I've got the driving/economics part of the game covered (and will probably try to finish it before anything else), but if anyone has any general advice regarding the online part, I'd like to hear it. Thanks.
Edited by the Author.
n/a
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
8th June, 2007 at 19:12:47 -
It really depends all on your game and how it works. For example, if all of your traffic moved the same way, that is, it just drove in a straight line, then the only message you would need to send is when and where to create it. Because on both machines, once they were created they would be pretty much in sync, as they continue on the same paths.
As for the actual car movement, I assume you're doing a top down driving game with 32 directions or something? The only time you need to send data is when you change direction or speed. It depends if you have acceleration on your cars too, if so it means that a little more data will have to be sent. So can you tell us all the specifics of your game? It's hard to judge without that kind of information.
If you code it well enough you could support probably about 8 on a decent broadband connection. But I can't really say without some more info.
Edit:
I just viewed your other post in the digital works forum, I've got a better understanding of what you want to do. Those cars look awesome by the way . Okay basically to be brutally honest, what you're looking at is a really really difficult thing to code. Firstly, you want to make a traffic engine, which hasn't been done well (that I can recall) in click products. Secondly you want to take that traffic engine, and try to sync it with another computer (there's a reason why multi-theft-auto, an online gta mod doesn't have pedestrians or traffic.) Having said that though, GTA1 did have traffic in multiplayer, or so I've been told. So it's not impossible, but I think that game worked on the principle of making sure every frame between the games was in sync, not really achieveable in click products.
The problem with the syncing is that, its possible to get the traffic to move the same on both screens, with only sending a reasonable amount of data, however once you want to affect the ai traffic (eg. crashing into them) then it will be quite difficult.
Imagine this situation: Online game with 2 clients playing and a busy road of AI traffic. All the traffic is moving in the same direction (left) but has the capability to move in all directions when they need to turn or are crashed into.
Client 1 crashes into car number 5. Car 5 spins out of control and crashes into cars 6,7 and 8. Client 1 sent the message "I crashed into car 5 at [angle], [x pos], [y pos], with [speed]." (that's a lot of information to send already in one message.)
Client 2 recieves this crash message, however due to the nature of the internet, it recieves it 50ms later. This small delay has caused the game to move forward and when the message is recieved all the cars are in different positions. So when Client 2 executes the crash locally, it moves differently and doesn't collide with car number 8, only cars 6 & 7.
The games are now out of sync. And for this reason you would not code your game in that way. However to ensure the the games were in sync would cause a massive amount of data to be sent. You would have to ensure that you also sent data about car 5 colliding with 6, 7 & 8, including angles and speeds.
One of the most complicated online games I've made is a co-operative zombie shooter. Basically, players connect and they are in a house. They can choose a class and they get some weapons. AI zombies are created and they move around the map with a custom movement, similar to bouncy ball. It worked well, but it couldn't handle too many zombies without lagging a lot (maybe 15-20). Here's how the data sending worked:
I knew that I would have lots of zombies, so I had to think up a movement technique where the AI would be stupid and not have to send data much. I came up with a custom bouncy ball movement in 360 directions. The zombies constantly moved forward in their direction unless they hit a wall, or were randomly told to look at the player. This reduced the amount of data I needed to send.
I sent data for the zombies when:
They were created - (Zombie ID, X, Y Position)
When they hit a wall\changed direction (Zombie ID, X, Y Position, New Direction)
When they died (Zombie ID)
So it's not that much to send, it's really quite acceptable. However if you have 15 zombies colliding with walls constantly then the data flow becomes quite large. The problem with the mooapi is that it's crap . You can make some pretty decent stuff with it, with some good dead reckoning techniques, but it doesn't support UDP sending (it has blasting text, but it doesn't work properly). Action games don't work that well, but they can be done. Seek n Dread is a good example.
So final advice for your game? You're probably going to have to remove traffic, OR have minimal traffic (a few cars.) Cars have acceleration, which is a problem because there is usually a lot more data to be sent. With my zombie game they moved at constant speeds, so I only had to send the message whenever you let go of a button or pressed a button. For example, if you press left, then you just have to send the message "I moved left", and the other client keeps moving you left until you send the message "I stopped moving left." You should be able to do the same kind of thing with the racing game:
Press up > Send msg "[Current Speed] + I am speeding up."
Is not pressing up > Send msg "[Current Speed] + I am slowing down."
+only send once
Thanks so much for the extremely thorough reply! I think it should help me a lot.
Anyways, here's what I'm thinking...
A maximum of about 8 Players is a little disappointing, but I guess a click game is not likely to have that many players anyway (still, I'm being optimistic). It does make traffic more desirable though. Am I right in thinking that I could split the city into sectors (on different channels), and have about 8 players in each sector? It would be weird to be driving along being chased by cops or whatever and suddenly "warp" to another area, so I think I'd need to come up with some sort of devices - ferries, tollgates etc. to make it seem more appropriate (and stop everyone ending up in one zone). That's assuming I'm right about the channels of course.
You briefly mentioned pedestrians. I think there *will* be peds in my game, but I won't bother sending information about them to other players - I don't think there's any need, as cars won't be bouncing off them or anything. Each player just has their own peds. All you'd really notice is another player might keep swerving every now and then to avoid invisible peds. If another player hits one of "your" peds, they can still be killed, just the player won't know about it.
I think traffic could potentially be quite simple (I don't want each traffic car to count much towards the 8 player limit, so it needs to be). As long as the movement of the vehicles is determined by the road system (and occasional random number when making decisions at junctions), surely you should only need to send data when they're created, if they turn off at a junction, and if they collide. I could just allow for turning 90 degrees to left/right/none (though the actual turning would be smooth), and have a "target" speed for the cars to accelerate up to determined by the road (fast on freeways, slow on single lane roads).
The other idea I had was to do something like I planned with the peds. I could keep creating new cars just off the edge of each players screen (providing an endless stream of traffic), and destroy any cars that get a long way away. At least this way I wouldn't be tracking cars miles away from anyone. I also could send other players info about the cars only if they were getting close. It'd need some tweaking to work when several player cars are on screen though. GTA1 did something like this. It was a bit weird as you could follow a slow moving car for miles, but if you stopped and let it go on, it would have vanished when you'd caught up to where it should have been.
I mayby say something what has been said already, because the texts are long and i'm tired. But as I see how to make a car game with traffic is, that you have to do server and client. Client has only the map and your car, no traffic. And server has map and traffic only.
Now the client logs in --> on the server will be send data of the car and it will be added to the map.
Server sends data ---> Client gets the data from traffic and other clients.
I havn't tried this, and it can lag if you have much traffic, and then there is the delay of sending the data aka lag, an it is depending on servers network, amount of data which have to be sent, and player network. (I thing)
So how to make this lag smaller? Well greate an invisible active objects on server version, which is the cars position and little bit bigger as height. As in the client when cars are smaller so when in the server the cars are bigger in front of the car. The crash will happen sooner in the server so lag will be smaller.
This is only hinch how to do it and i'm mayby totally wrong, but that is how i see it to be done best.
Edited by the Author.
I have proven new mathematic formula to be true...
only 4 posts and it's already longer than it would be if it were an average topic of 2 pages!
Jaysus.
My signature is never too big!!!
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
9th June, 2007 at 23:45:20 -
Sketchy - Both those ideas were good ones. You've got the perfect mind to solve the lag problems, it normally takes a while for people to understand how to minimize lag but you've gotten it straight away. The pedestrian idea is a good one, as you already said that they don't affect gameplay so their data doesn't need to be transferred.
I particularly liked the idea of splitting the city into sectors, that's an effective way of sending less data. There's no point telling someone on the other side of the city where you are if you can't even see them. However wouldn't need to "warp" players either I don't think, just because you change channel, doesn't mean you need to change frame aswell. You could simply change channel and have the player keep driving, without them even realizing they reconnected - have the game on one big frame.
What kind of an online game are you planning to make this? A MMO or a game with lots of servers? Because you said MMO, and that implies a centralized server. If you have a central server then you should be able to hold many players, especially if you have that sector\diving up the city idea. It depends how fast the upload on your server is too. But it's a lot more possible. As for the traffic, those ideas to keep it simple were good. You could basically have them on a custom sort of path movement\waypoint system that kept them moving unless they were affected by a crash or something. So yeah it's quite possible. Just make sure you keep everything as simple as possible. You will be able to have much more than 8 players if it's a fast centralized server. There aren't too many click mmorpgs, and so there's no real data on the absolute max. But they get pretty high with 50 or so players - Again, it all depends on your engine
You've inspired me, I might have a crack at this engine
Both you and Mauri suggest having a central server, which would seem a sensible idea, but there's no way I can run one from my computer, and I'm not going to pay money for one - is there some way to get a server running your game for free? If not, I'm stuck with the players having to handle traffic etc, which would be much more complicated and probably slower.
Also, the reason I was thinking you might need to "warp" players, is this;
Suppose Player_A is being pursued by Player_B. If Player_A crosses into a different sector, they'll stop sending data to Player_B until Player_B is also in that sector, even if still in view. It will appear to Player_B that Player_A keeps going in a straight line, but they could actually be doing anything. Maybe if sectors could be made to overlap? It'll be pretty sweet if I don't have to use "warping".
I'm glad I inspired you Start now and I'm sure you'll have a finished game waaay before mine's done. I'm definitely starting to think this is do-able, if still very ambitious (I had my doubts to begin with).
>> I added a tank, humvee, and caterham 7 to my digital works post.
Advertisement
Post Reply
Edited by the Author.
. Okay basically to be brutally honest, what you're looking at is a really really difficult thing to code. Firstly, you want to make a traffic engine, which hasn't been done well (that I can recall) in click products. Secondly you want to take that traffic engine, and try to sync it with another computer (there's a reason why multi-theft-auto, an online gta mod doesn't have pedestrians or traffic.) Having said that though, GTA1 did have traffic in multiplayer, or so I've been told. So it's not impossible, but I think that game worked on the principle of making sure every frame between the games was in sync, not really achieveable in click products.
. You can make some pretty decent stuff with it, with some good dead reckoning techniques, but it doesn't support UDP sending (it has blasting text, but it doesn't work properly). Action games don't work that well, but they can be done. Seek n Dread is a good example.
