Advertisement Jump to content
  • Advertisement

Dark Rain

Member
  • Content Count

    416
  • Joined

  • Last visited

Community Reputation

157 Neutral

About Dark Rain

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What you want to do is lockstep networking. It works perfectly well when just replaying the input, i've used it in sport titles on console back when modem play was your target demographic. Basically each side send commands for a frame and wait for the other side to say they're ready to process the next one. Most bugs with this system occurs because a non deterministic event happened and it could cause a major divergence only 300 frames down the road. http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/
  2. I'll assume you've considered it but seeking data efficiently among a vast amount of data while using only the available amount of RAM sounds quite a lot like a database. You could "cook" your data by sending it into a DB as it comes in.
  3. Dark Rain

    MMOPRG database

    I don't know Samoth, we put our customers through a lot of shit and practically no one quit. I'm guessing it was worth the discomfort to feed their addiction? I'm talking constant reboots of the server for a week ( 3 times a day ), two days rollback etc. What can I say, shit happens. Sometimes it was the fault of the hosting services, once a player hacked the actual server box, sometimes it was a programmer error etc. (You can't exactly run super tight security when you're 5 guys and no one has unix administration experience previously. What can I say, we learnt by doing).
  4. Dark Rain

    MMOPRG database

    Yes, I do agree that MySQL should be good enough, that's what we used. You'll get performance issues I'd say when you start scaling up if you're not too familiar with DB's. Our first problems appeared toward 200 playing users and then 400 but I read a very good book on db performance optimization and that got us going again. Mainly like hplus said you have to accept a certain difference between the state of your DB and the state of the world on the server. Don't save unnecessary data, don't make too frequent update etc. You'll lose data in case of a server crash of course but our strategy was to have "full" world state backups every 15 minutes so it's not too bad. If it's an event that really, really matters you can make a write to the DB but that's it. Note: Most of the issues popped up because of that dump every 15 minutes, it was a pretty bad idea but we were stuck with it. As the number of player grew, the time to make that save grew and well... I guess you can see where this is going?
  5. Dark Rain

    packet parsing

    Well, it's always a question of the target application and up to a point of taste. That being said, this method wouldn't scale very well in my opinion. There's a lot of things the naive approach doesn't cover like packet integrity, quantization of the data for space saving, bit packing etc. You can do the validity check without a framework at the limit but doing bit packing and quantization without a framework is a pain. Of course there's also the problem of having to write the packing and unpacking code for each object the hard way each time. Each optimization needs to be inserted at the packing level by you and you have to make extra sure you don't mess up and have a difference in the packing/unpacking code, which can get tricky in extra large objects with branching conditions for the packing. That being said, I've worked on a real mmo that was using this method. There was a stream class that handled strings and casting double to floats but that's it for the stream level "optimizations", there was no quantization or bit packing and we had to do the packing/unpacking ourselves by hand for each object. So it can "work" but we had a lot of problems with malformed packets or an engineer forgetting to update the unpacking code of the client after having added a feature on the server. It was especially vulnerable to malformed packets lying about their size because we used a static size for the streams buffer going into the socket like was suggested above. You could cause a buffer overflow and then... well I'll leave that to the imagination. For a lot of reason you can imagine in old and complex systems refactoring this was a rather risky proposition. People make bad assumptions about the data etc. The few times we tried to fix it, it failed the production server test and we had to rollback. So we added checks and once in a while a new way to get the server to die would popup. We'd track it down and go "Aaaah, surely this is the last one, it was so obscure a way to trigger it.". Anyway I think you can see what I meant about scaling, if had to do it again I'd be willing to sacrifice some performance for safety.
  6. I agree with Washu, consider the fact that so many of the big MMO out there use TCP. That should tell you something. Anyway, my personal opinion is that if your messaging layer is well made, you should be able to switch to UDP if you ever need it.
  7. Yes, I've worked on a commercial MMO on my previous job and that's what they did. The client was 100% authoritative on the player position inside a zone. It took 2 years and half for a clever guy to use a program to change his system clock and go to 4x his normal speed. We then had to implement some counter measures but CPU was really tight so it only prevented the most glaring speed hacks. Tracking down and deleting all of the user accounts and characters for the perpetrators also provided a certain deterrent of course. I had a co worked who told me they did the same thing for Everquest inside zones and they had the exact same problem with a speed hack after a while. So I'm guessing it's a pretty common solution. Looking back to my very short EQ experience it did look like it was the case. I remember I had that image in my mind before I worked on a mmo of high security practices, very optimized code etc. How far I was from the truth... And yes hplus is right, CPU was usually the biggest problem, bandwith never got into it.
  8. It always depends on implementation but usually it's all done server side. In games like shooters, games that are "twitch" in nature you can allow the player to move on his own a bit and send his new current position to the server. The server then validates the new position by making sure it was possible to get there in the first place. You're not saving much CPU cycles there it's more about making very responsive.
  9. That's not really a fix. The attacker would then just have to disable your checksum.
  10. Well to answer the purely technical side (yes it's impossible on the "political side"). All these machines support TCP/IP so... It's just like any other networked game. You'd need to write a client for each type of machine, do some byte swapping depending on the processor type and you're golden. Of course, you'd never pass any certification if your software were to let xbox and ps3 players interact.
  11. I used to work on a commercial mmo and as Marineio suggested, the client would make the move based on your input. Then it would send the move command to the server. The server would then decide if that's a legit move. We used the goold old rubber band effect in case of suspected illegal move, kind of like Ultima Online did it. I should mention that high latency tended to trip this system. Of course, it's very dependent on the type of game you're going to be making. We needed such a system because it was a "twitch" mmo with arcade style controls. How you controlled your ship was as important as your stats. The position had to be accurate and the movement smooth. It was also pretty easy to determine if a move had a good chance of being legal, since like WOW we had basically no geometry you could collide with, just empty space (space mmo). I've been told Everquest also used a similar system when it came out and that they didn't even do validity checks. Which of course someone exploited after a while by simply making their windows clock go faster with a program. It made them go to supersonic speed. I'm always awed when I realize how shoddy the code behind some mmo is and how much is just make it up as we go. Frankly I thought it was a miracle some game always gave the appearance of smooth efficiency after having seen what's behind the scenes. Oh yeah and you shouldn't transmit xml as your packets! Retrofitting to binary format is probably going to suck for you and you'll *need* to do it if it ever becomes somewhat serious. Also, if it's a learning experience might as well do it right is my personal opinion. I'm not saying you should go overboard and go for bit packing etc but you should learn how reasonably efficient packet messaging work.
  12. Dark Rain

    Applying for a job - Demo advice

    Knight Templar: Well, most companies I've worked with rely extensively on libraries at all levels of development. Client, server, interface, file loading, thread etc. So I'd guess that showing that you can work with other peoples code is a good thing. As someone said above, each company as it's own methodology for the hiring process. Here they start by having you sit in front of a computer and do a practical test. If you don't have the C++ skills it shows pretty fast as most of the test is impossible if you don't really know C++ and the underlying principles of computer science. But that's just our studio, I know for a fact our other studio have their own thing.
  13. Dark Rain

    Real-time MMORPG Combat

    I used to work on for a company doing a mmorpg with twitch combat (it's been out for almost two years now I think). It works surprisingly well. You will have the occasional problem where the prediction algorithm goes a bit awry but it's usually pretty smooth when they don't have server wide problems with stability and lag. I mention it because it was a pretty small team and probably still is so global performance could sometimes be problematic when a new feature was introduced. Still, it was developed with a minuscule budget in terms of games and it was the first game for two out of the 3 original coders so it does prove that with some talent and dedication you can produce something interesting. There's a free unlimited time trial that doesn't require a credit card, so you can try it out and see how it works out and if it's applicable to your game. url: www.starsonata.com Oh yeah, I haven't checked it out in a looong time so I don't know if they have any lag problems right now that could compromise the real time combat experience.
  14. Dark Rain

    Anti-Aliasing

    You probably haven't seen it listed as one of your card extension because most opengl extension names aren't very intuitive. What you should be looking for is ARB_MULTISAMPLE if I remember correctly.
  15. Dark Rain

    Anti-Aliasing

    VanillaSnake, it could be that your card has the extensions to support it, which can easily be queried under OpenGL but they're not exposed under directX.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!