• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About fredizzimo

  • Rank
  1. Multiplayer Physics

    I'm looking for information on this too for our next project. I have spent days searching and reading hundreds of academical papers indirectly or directly related to the subject. But unfortunately most of them doesn't transfer very well to the real world, or they don't provide any more info besides the basics. There were some round-table discussions on GDC 2006 called "Next Generation Multiplayer: Networking Highly Physical Game Worlds." But unfortunately I don't know what was discussed there, being in the middle of the crunch there was no way to attend, and as far as I know nothing has been provided. I guess there's no really magical tricks to make it work though. A decisssion has to be made about who are going to send the object. Some priorisation has to be made to prevent bandwidth overflow. The rest is just standard dead reckonning. The first two tasks can either be hard or easy depending on how complicated you want to make it. However there's a great chance that you can just do all the physics locally for the dynamics objects. The physics will still affect the gameplay, and you have to avoid hitting the objects, or can use them to your advantage. The remotes might see a slightly different view of the word, but in most cases that won't bother the players that much, as they don't know exactly how his world looks like. You can see the player avatar jump a bit when hitting an "invisible" object, or see him go through an object, but depending on the game theese things could be allowed. This was the way that we did it in FlatOut, and how we are doing it in FlatOut 2. The game has thousands of physics object.
  2. Lag issue with c++ and winsock

    Do you have program called netlimiter installed? The reason why I'm asking this is because it caused a lot of problems with our game. The biggest issue was that it broke WSASendTo, if you have more than one pending send at a given time. It always sent the packets to just one player, even if you gave the right ip as the parameter. What's even worse is that it just didn't drop the packets, but sent them to the wrong address. Needless to say it wasn't very nice, because the maximum numbers of players you could be in a given game was only two with that program installed. Fortunately someone from the community found the cause though, and it could be fixed in the patch. The second issue, is probably what you are seeing. It's not that bad thing, because the game still works. However it adds a lot of latency. The ingame ping utility that we have was showing ping times varying between 0 and 200! And they were varying all the time, the average was about 30. Without netlimiter installed the ping times are usually 0-1, on the same LAN. Finally it doesn't help to just disable the program, it needs to be completely uninstalled, as it installs it's own driver, probably replacing, or hooking into Ws2_32.dll in some way. I haven't looked at how it actually works, though, I just know that it needs to be uninstalled. Edit: Other things that it breaks. At least google desktop search didn't work when I used it. Previously there was problems with Eudora mail, but that is fixed now. NFS-U freezed in a previous version. E-mule ran at 100% cpu use and so on.
  3. Have computer speeds stalled?

    Quote:Original post by fractoid As you can see, I have added my own trend line. Mine (the superior red line) is better. Why? Well, for starters it fits the data more closely. Secondly, because I say so, which is more backup than the pathetic blue trend line has. Note that I could have decided to make CPU speeds suddenly become infinite, or decrease over the next two years... me, or anyone else, drawing a line on a graph doesn't make it so. It's not really any better, your line shows the average, the blue line shows the top speed. It's the top speed that the article is talking about. Never, except in the early years have the top speed been rising as slowly as it does currently. And I don't see how it could get another boost, unless a completely different technique for making processors is used.
  4. Testing

    There are also programs that let you do this, for example. -One that comes with one of the game programming gems(don't remember which at the moment) -NIST Net(for linux)
  5. storing character data in a (M)MORPG

    Localhost is also refered to as loopback. Which means it just a virtual network interface for accessing network ports on the same computer. The network data never goes to the network card, in fact a network card isn't even needed to send and receive data to/from localhost.
  6. storing character data in a (M)MORPG

    Running MySQL and the gameserver on the same host doesn't use any bandwidth at all.
  7. Real-time multiplayer race game

    I have programmed the multiplayer part of the commercial game FlatOut that was recently released in Europe, and will be released in Q1 next year in America. So here I'm speaking with the experince I got from programming that. It's not physically possible to get it as lag free as MMORPG games, due to the speed the cars move. Think about it for a second. A car travelling 200 km/h, travels 55 m/s. Assuming a ping time of 200ms(a very good Europe to USA connection). Let's also assume we send the packets directly, and not through a server. That means, that the car travels 5 meter in that time. That's a long distance if it travells in the wrong direction, say a sudden direction change. However if your prediction is good, that means that it uses the same or almost the same physics as the real game, you can greatly reduce the wrong predictions. Simple dead reckon is good, but the more advanced physics engine you have, the more it will go wrong. To get it as good as possible, you need to use all the info you possible can get, throttle/steering, acceleration, speed, rotation, rotation speed and so on. Collisions are very hard to predict, especially with two remote cars, because you don't have the real position for either of them. If you are doing it clientside, which I strongly recommend(I'll explain why later), then you also have the problem of processor usege and complexity to face. To reduce this you could predict what's really happening when colliding, only during the simulation between the actual predictions. So your system would work roughly like this. When you get a packet, you predict where the car would be at the current time, then it goes into simulation mode and runs full physics with all collisions, until the next packet is received, and then the cycle starts over again. What is important to remember here is that the simulated position might be more accurate than the one that you just predicted(as the prediction is simpler than the real physics), so a clever system for detecting when this is the case is needed. Ok, now back to the clientside thing that I mentioned earlier. A racing game needs to be responsive, there can't be any delay between the controller action, and the car reacting. In the same way you expect the other cars to react exactly at the same time as you collide into them. You also don't want to have correction of you own car position ever, as that would be REALLY annoying for the player, and in worst case could cause him to crash, when put in a situation he can't recover from. From all this comes that fully server based prediction is practically impossible to do. There would also be problems if you combine server and clientside prediction, as the server state could never be fully right(remember it can't move your local car). A dedicated server could still be used however, for example by having it detecting cheats and so on if wanted. So following from this there's almost no advantages with a server/client based topology, commonly used in other types of games. It only adds additionally latency, which is the major thing you really want to avoid. So I recommend a peer to peer based sollution, as you get the best possible latency you could that way. Internet connections are also getting faster all the time, so the additional upload bandwidth required should not be a major issue, unless you want to support modem users. NAT and firewall issues are the major problems with this. Another trick to reduce the latency is to use faster packet rates. With faster packet rates, you will also reduce the time the car is predicted wrong after an abrupt position change for example. However this should of course be balanced with your target bandwidth. You could even using some clever bandwidth throttling system. There's tons of more things I could write about this topic, but I think this is good for a start.
  8. storing character data in a (M)MORPG

    Make it configurable by some kind of ini file. That way you can change the value, depending on how well it scales in the real world. It's possible that you could update every second, without overloading the server, or that it's too slow updating every 10 minutes(allthough unlikely with only 30 players).
  9. TCP and UDP

    Quote:Original post by hplus0603 Building your own reliable stream on top of UDP, or using one that's already built, is probably a better bet in the long run. For example, you can do NAT punch-through with UDP, but not with TCP. Actually you can do TCP punch through, allthough it doesn't work quite as often as for UDP. http://www.brynosaurus.com/pub/os/nat.pdf. Or a more technical internet draft http://www.brynosaurus.com/pub/net/draft-ford-midcom-p2p-03.txt
  10. Quote:Original post by Agony Quote:Original post by fredizzimo My definition of sex would be: "To do an act that sexually stimulates at least one other person."You might be able to clarify a wee bit more that by adding one word: "To do an act that purposely sexually stimulates at least one other person. It'd get rid of the holding hands/hugging issues pretty well, I'd think. Yes, you are completely right, as those things certainly can cause sexual stimulation, at least if the two people love each other. But I wouldn't classify that as having sex, so my original definition is wrong and yours is correct IMO :)
  11. Not around much anymore, but...

    I have heard it so many times, that it doesn't affect me in any way anymore.
  12. I like to ask another question for those that says it isn't. Is anal sex the same as having sex(both for gay's and straights)? My definition of sex would be: "To do an act that sexually stimulates at least one other person." So oral sex would therefore be the same as having sex. Masturbation wouldn't be that, as that only involves one person. However if a woman, jerks you off, then according to my definition would be defined as having sex. However just hugging and kissing each other on the other hand wouldn't match my definition, as that doesn't sexually stimulate in the same way.
  13. Definately Mindwipe's game

    I tried a few more games, and got a 124, and no I didn't bother to take a screenshot, it proves nothing more than this text anyway. As the previous poster said, up to about 80 is easy, but after that you can't use the same technique anymore, all your motions have to be fast, react, and an immeadetly counter-reaction. It requires a bit luck too to get far after that, because you need to counter-react so that he is going completely straight, that will give you a few more meters before you need to react again. However my second best try wasn't even close to that, only 104. Edit Hm, suddently it started to feel very easy. I got 148 on the first try after this post, but then I got too nevous.
  14. Definately Mindwipe's game

    I got 80-something in the first try. Got interrupted in the second, and didn't bother any more.
  15. Bitter programmer..

    I really love people like that :) Wish we had one at the office too. It could prevent many stupid bugs, when someone makes something that breaks something that someone else has done. And I guess it would be a great guard against stupid bugs in general too. Basically I would love him, but not suck him.
  • Advertisement