Slashdot Mirror
Designing Multiplayer Game Engines?
"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."
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.
Microsoft massacres you to small fragments with its EULA.
Microsoft massacres you to small fragments with its Memory Exception error.
Microsoft massacres you to small fragments with its BSOD.
Your server is DEAD!!
<
A feeling of having made the same mistake before: Deja Foobar
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.
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:Sheesh, evil *and* a jerk. -- Jade
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
As so many people have made clear C# is completely the wrong tool for the job. How could it possibly be the right tool? After all, it's a new language from Microsoft!
Some other advice on languages: how well this will perform will be completely dependent upon the language you choose. I cannot overemphasize this fact. The language you choose will be the difference between this game of yours being the next Starcraft and this game being the next Civilization: Call To Power.
First off, I would recommend NOT using languages like C, C++, or Objective C. C is especially bad because not only is it not garbage collected, but because it is a structured language it makes working on large projects with it virtually impossible. Every large project which has been written in C instead of C++ has failed completely. C++ is not an object oriented language either. Both C an C++ have a horrible potential for memory leaks because they arent garbage collected. Also, C and C++ have language features which can be abused such as global variables and pointers. The sockets support in these languages is a bit iffy and they don't let you use all the latest language features like POSIX asynchronous I/O. Only a moron would even think of using C or C++ in this day and age, when there are so many better garbage collected languages out there.
I have a number of recommendations to you for language choice. The first is of course Java! Java is an easy language and does an extremely efficient job of garbage collection, more so than what you could ever possibly acheive manually in languages like C or C++. Java is also dynamically recompiled which means it is optomized for your CPU on the fly, making it faster than C or C++. It's also easy to program in, and is a better object oriented language than C++ (Bjarne Stroustrup has admitted that C++ wasn't designed to be an object oriented language, and we all know that if a language isn't truly object oriented it's just no good)
Might I also suggest Pascal as a language of implementation? Pascal has a very nice sockets interface which will let you use the absolute latest kernel features such as POSIX.2 asynchronous I/O which is, believe me, what you want to be using. glibc doesn't document the functions like aio_read() but you can find them on any BSD. Linux does implement asynchronous I/O, right in the kernel which is better than any BSD. And of course I know you want to be using Linux because it's the greatest operating system ever.
Another language to consider is COBOL. COBOL has a great deal of support because it's been around so long. In fact, the COBOL compilers will optomize better than any other compilers on Earth, just because they've been developed so well because COBOL is so old. You should look into COBOL if you feel like writing it in Java isn't your cup of tea.
Smalltalk is the world's greatest object oriented language. There are a great deal of tools for Smalltalk development, plus your program would run faster and be less buggy because it's written in a true object oriented language like Java instead of those fake object oriented languages like C++.
Eiffel is another good object oriented language which you might look into. I haven't used Eiffel much but I hear it's very good.
PHP is a language geared towards portability and rapid development. Use PHP if you want to code the server with ease and run it on a variety of platforms. I think PHP even supports POSIX.2 asynchronous I/O!
LISP and ML are functional languages which are often ignored but very good. Use these if you want to guarantee your server is bug free.
Color Forth is a language which gives you very low level access to the system while still being garbage collected. In fact Java stole its garbage collector from Color Forth. Color Forth also has the world's coolest syntax ever because it's color dependent. Color Forth will give you the best use of Posix Asynchronous I/O out of any of the languages I've mentioned, but watch out for memory leaks! Color Forth does not let you guarantee your program is bug free either.
FORTRAN 95 is another way to go. FORTRAN makes it really easy to parallel process anything which uses the FOREACH command, and there are many great FORTRAN compilers for Linux made by Intel and the Portland Group. And we know if it doesn't run under Linux, your game will be completely worthless.
Visual Basic makes it very easy to program network servers, and will guarantee you easy use of sockets and POSIX.2 Asynchronous I/O. Use Visual Basic if you want a very efficient language that lets you manage memory manually and use a small footprint while being very efficient in your use of CPU algorithms.
For the client I recommend using Direct3D. You are writing a 3D game, right? A 2D game, especially a 2D strategy game, is completely worthless! Every single successful strategy game ever written has used Direct3D. It is for this reason that I recommend you use and learn Direct3D. I recommend you also write the client in Visual Basic as it reduces development time and allows for efficient memory management.