Slashdot Mirror


Designing Multiplayer Game Engines?

mikera asks: "I'm a pretty experienced programmer but I've just embarked on my first (massively?) multiplayer strategy game. To make things even more interesting, I've decided to write it in C# and pick up a new language at the same time. I've chosen a client-server architecture where the server holds the one 'true' state of the world. The only communication from clients would be commands to units, which is simple enough, but the server will have to propagate game state changes (events) to all clients. I would like to ask Slashdot readers if they have solved a problem like this before or can offer some opinions on the best way to implement a solution."

"Lag is not really critical, but I still want things to be responsive and it must scale up well with the number of clients. The size of the map data, the complexity of the objects and bandwidth constraints rule out sending the complete game state, so only incremental updates will work. The situation is further complicated by the need to limit updates to just the areas of the map that are visible to a given player/team - this is clearly necessary to prevent client-side hacks such as gaining full map knowledge.

I understand the theory well enough, but I'm interested in practical advice on how to implement a solid architecture. What should the object model look like? How do I propagate events that are only partly within a client's field of view? Are there any novel features in C# that might make my life easier? How can I make the networking code as transparent as possible so I don't have to write SendUpdate() after every assignment?"

Your comments, insights, hints and flames are eagerly awaited."

5 of 397 comments (clear)

  1. Yes I Have by Anonymous Coward · · Score: 3, Funny

    Back in '97 I did the exact same thing in Perl. It was actually a multiuser accounting package, but the principals are the same.

    By blasting debits, the accountants could increase the net value of the company. If they missed, the debit's could rip through the balance sheet of the company...rendering it's offshore shields useless. If that happened a few two many time, it could spin the whole company into bankrupcy and court-ordered liquidation.

    I found that the biggest problem was latency. I worked on some time compensation algo's, but I didn't get a chance before I was right-sized by the company.

  2. Re:Follow the Rules of New Software Projects: by Lumpy · · Score: 3, Funny

    the scary part is that the parent post is modded +5 because of this line....
    Fifth: Cut yourself off from all human contact and work on it.
    Stop showering, stop feeding the cat, forget the wife/kids/work. Finish it as soon as possible because I want to see what you're working on :)


    come on you all know it's true!

    --
    Do not look at laser with remaining good eye.
  3. Use Ada 95. by Black+Parrot · · Score: 3, Funny


    I know that suggesting a different programming language usually gets the same kind of reception that suggesting swapping underwear would, but why not consider writing it in Ada 95?

    The learning slope will be very steep at first, but once you get the hang of it it will pay off in spades. Ada is a software engineering language, and it makes you do a good bit more thinking before you start spilling code, but over the long haul you end up spending most of your time in the think-program cycle rather than in the more popular but IMO less satisfying program-debug cycle.

    Pros:

    • Ada is designed for large software projects.
    • Bullet-proof against buffer overflows and such.
    • Supported by GVD (the visual version of gdb).
    • Very strong portability properties.
    • Supports both high-level and low-level programming. (OO, generics, etc. all the way down to in-line machine code. But all are optional; you can write simple code when that's what the problem calls for.)
    • Built-in support for multitasking and distributed computing, if you want it. (And distributed might be the way to go for a big-game server.)
    • If you need a GUI there are thick bindings for GTK+, portable between UNIX and Windows. These bindings are OO, so you can create custom widgets by inheritance.
    • Everything mentioned above is available for free.
    Cons:
    • The aforementioned learning curve.
    • Probably fewer volunteers on the project once it gets big.
    --
    Sheesh, evil *and* a jerk. -- Jade
  4. A little vague by Casca · · Score: 2, Funny

    I want to build a car using (insert new untested material here) because its new. I know I'll need some windows, and wheels, and some sort of engine. I don't really want any suggestions about what materials would work the best because I want to learn how to use the new (untested material). What I really want to know is has anyone else ever done this before, and what should I look out for? I'm pretty sure I'll need to make sure it gets good gas mileage, but it will have to be really heavy, acceleration isn't important, but I want it to be responsive in the turns...

    Why would anyone ask a slashdot group about a C# project?

    --
    Casca
  5. Re:Other languages to consider by mikera · · Score: 3, Funny

    Cool. I will be sure to check them all out.

    Perhaps I should develop my own re-targetable meta-language so that I can defer the language decision until later?

    Also, you heard of unlambda? I think it might be a worthy addition to your list.....