Designing Multiplayer Game Engines? 431
"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."
SendUpdate() Solutions (Score:3, Informative)
Re:+1 Wholey Sh$t : (Score:3, Insightful)
C/C++ currently have (besides the performance benefit) a far, far larger library set than C#. Heck, *Java* has a big networking library set.
Let other people live on the bleeding edge and do the bleeding. C# is proven to be solid for little pet projects -- I wouldn't currently try it for big stuff yet.
Have you looked at world forge? (Score:3, Informative)
Not doing two things at once (Score:5, Insightful)
Thanks
Re:Not doing two things at once (Score:5, Informative)
Using Python would allow this fellow to achieve his goal of learning a new language, fast. He can then properly focus on the important things: program structure and gameplay.
Re:Not doing two things at once (Score:5, Interesting)
Greetings,
I'm a professional game developer who has committed a large portion of his adult life working on virtual worlds of one sort of another. Recently, I worked on Ultima Online 2, which some of you may have been looking forward to playing. I know I was!
I'd like to talk to you a bit about my current project, 'Netsu', which is the culmination of many years of background work. "Netsu", Japanese for "heat" and "fever", is an anime-inspired world which incorporates multiple perspectives of play and a reputation network for players to self-organize. It's going to be fun.
Currently, I'm working on combining a number of existing open source technologies to build the new virtual world system. These include the 'Nebula Device' 3D engine from Radon Labs on the client side, the Twisted framework for server-side and client-server communication, and (as the project moves forward) the OpenCyc knowledge base as server-side archetype repository and artificial intelligence server.
As I develop use cases and other design documentation for Netsu, I intend to keep them as portable as possible between gaming systems, so that they can benefit the most people. I anticipate this work feeding back into Twisted, expanding it to be a more general simulation framework, and into Nebula, adding network support and in-game world editing tools.
So where did this project come from?
The genesis of the project began with my work on virtual reality systems in the early 90's. I developed virtual building walkthroughs for architects, VR games, and created the first hardware accelerated PC-based virtual actor system for Compaq.
This work was all done with C and C++, and it was during this period that I ran up against the need for a dynamic and interactive way to "reach inside" the simulation and manipulate the code and data directly. And that's how I first became acquainted with the language Python.
The next major phase was to build a 3D client engine with Python embedded as a control language. The fruits of that effort are described in the paper I presented at Python 7, "Beyond: A Portable Virtual World Simulation Framework". (This was also the first mention of 'Netsu'.)
In 1998, the path of development took a turn when I was recruited into Origin Systems to work on developing the Python foundation for the Ultima Online 2 project. The focus during the period was on innovation on the server side and on client-server communication. The results of that labor are described in another paper presented at Python 9, "Python for Massively Multiplayer Virtual Worlds".
Both papers are here [asbahr.com].
However, to this point, all the software developed for these projects was closed source. The desire for an open source virtual world system was lurking in my head, but it wasn't until the O'Reilly Open Source conference in 2000 that my plan for the open source virtual world crystallized.
At the 2001 O'Reilly conference, while presenting on the UO2 design work, I took the opportunity to discuss my plans for the future open source virtual world system. The response was extremely positive.
So what are next steps to realizing this goal?
Glyph (the originator of the Twisted project and a fellow ex-Origin colleague) and I have been meeting periodically over the last few months to discuss these issues, which intersect nicely with his long term plans for gaming in Twisted. I've also been meeting with the Cycorp folks (who happen to office just down the road from me) to discuss integrating Cyc and driving Python class generation from Cyc.
I recently integrated Python into the Nebula Device, which allowed me to easily integrate the PB remote object communication protocol and made Nebula the first 3D clients for Twisted. Over the next six months, several major components will come online, including character creation, character motion, the GUI system, basic terrain management, character inventory, and combat.
As I wrap up my current consulting project (porting Python to the Playstation 2 and developing a GUI for designers to build Python logic), I'm devoting 100% of my time to Netsu and open source development.
It is my hope that this collaborative approach for virtual world development grows, spreading outward and providing a foundation to help other developers build their own virtual worlds and enable the sharing of code and art resources between worlds..
If you are interesting in finding out more about the project, drop me a line via email and tell me a bit about your interests and background.
Cheers,
Jason Asbahr
jason@asbahr.com
If he WANTS the bleeding edge, of course... (Score:2)
Oh, and you can run it in a JVM (did I mention portability?) and spit it out as C if you like.
Counting spaces? (Score:3, Informative)
It's a fine point to try to debate with, until you try to actually use the thing and realize it never comes out at all (as opposed to counting curly braces in other languages, which really has happened to me).
Further, Python too can be run in a JVM or converted to C.
Re:Not doing two things at once (Score:2, Interesting)
Use the BEST tools available for the project you are designing. Anyone who tries to tell you otherwise has no concept of proper development.
Re:Not doing two things at once (Score:3)
That's not the reason he's using C# though. He appears to be going with it because it's the latest buzzword.
- A.P.
Re:Not doing two things at once (Score:3, Insightful)
I would definitely advice against using anything Win32 specific on the server side. It's just plain common sense to avoid limiting yourself to Wintel servers.
Re:.NET will soon be the dominant GUI for Linux (Score:4, Interesting)
we did find one interesting factor that could actually make make the windows-based platform not viable anymore.
The fact is that up to now, hardware, the OS software and, for the most part, games have been a pay-once/play forever deal.
With XP, this model is trying to be changed, so not only do you have to keep paying to use XP, but you can think of it as an additional cost to playing your games.
If you dont beleive, think about the Xbox. Now where does MS suggest that you will need to pay to continue to use the Xbox(for now), and that is their games development platform, thus they wisely avoided trying to charge gamers for the OS they are playing on, thus I do think that Linux does have a chance of being a gameing platform, but this is not an advantage that linux only shares, because right now, we dont pay for OS's for any gaming platform ( I mean, PS2, gamexube, etc...) we just pay for the games,
So what I am trying to say is the C# really isnt a good choce because the OS it is to written, now comes with more Costs than any other OS.
Thanks!
Re:.NET will soon be the dominant GUI for Linux (Score:3, Informative)
Obviously you haven't been paying attention over the past several years.
Ultima Online
Everquest
Asheron's Call
Many many numerous others, I know I paid $10/month for a bit to play Allegiance. Going back in history we have examples at Compuserve and so forth.
Ongoing charges has been a factor of life for multiplayer gaming since almost it's beginning some 20 years ago.
Take your FUD elsewhere, troll. If people find enjoyment with the game and the value of paying per month exists they will do so. Otherwise the game will fail.
In the case of the XBox what I see as viable is for them to have a one time charge to access a large farm of hosted servers that grants access to many different multiplayer games. As things stand right now each different game asks for a seperate $10/month fee. Most people I know do not get addicted to just one game, they may play several, or go months at a time without ever touching one particular game.
Re:.NET will soon be the dominant GUI for Linux (Score:3, Interesting)
Windows service packs are released for free
So no need to upgrade just to play
1. Ms has made it quite clear that they wanted people to pay for XP as a subscription model.
2. There is no early reason why they would make the claim that the "value" you get for your subscription money is an up-to-date system which includes bug! The point is that they dont feel that they should continue to their software for free.
3. That means, that You will no longer get service packs for free as these can be viewed as Service Pack upgrade or even a NEW VERSION, the point being that you will need to pay
4. The other point, that MS has back off from, for the time being, is that they want software to be time-limited, which is to say that if you dont pay a subscription fee, then you no longer have the right to use the software, ie, in another words MS has clearly stated they want to change the way people view software from being views as a buy once commidity to something like Cable Tv in which you pay every month, and if you dont pay, you dont Watch, ie you cant play your games on their OS.
Sorry for being so long
WorldForge (Score:4, Redundant)
Re:WorldForge (Score:5, Insightful)
I remember reading it a while ago before you had to register, it had alot of insights as to saving game states, lag, updates, and "late joiners" to a game.
Anti-WebWasher (Score:2)
What an annoying site. Won't display anything if you're using WebWasher [webwasher.com] to block banner ads, it just says "WebWasher not allowed".
Just FYI if you're using WebWasher, in the "Proxy Engine" section of the options, turn on "No identification as WebWasher with server", and you'll be let straight in.
What's the sense in blocking WebWasher? If you block people, people aren't going to see your ads anyway, the people blocking them are exactly the people who aren't going to click on them anyway. And especially as WebWasher has an option to hide itself!
Re:Anti-WebWasher (Score:2)
*shrug*.
You do know, don't you, that in the long run a lot of services will probably go over to micropayments, right? Bandwidth costs _money_. Someone has to _pay_. If it's not consumers via advertising influence, it will just be someone else.
C//
Re:Anti-WebWasher (Score:2)
The logic is that you don't get the content that those ads are paying for. Sure, it has the option of hiding itself, but this is better than nothing. It seems that this option isn't turned on by default, or I would think that you wouldn't have run into the problem.
Re:WorldForge (Score:4, Insightful)
Looking at code is tricky buisness. You can do it in some ways, and you're probably safe as long as you're not creating a direct competitor with a commercial product, or a work-alike of something. If you do a clean-room implementation of something there cannot be even a chance that you've seen the competitors code. If you're doing your own thing, and just glance at the code to get a basic feel for how they've done things, then write your own, different code, you can probably consider it fair use. Maybe. But it's tricky territory.
Re:WorldForge (Score:5, Informative)
The important thing is that I really like the The WorldForge Project [worldforge.org] (in fact, it's one of my favourite projects (if not the favourite project), promoting the idea of free software [gnu.org] to broader audience.
They're doing amazing work and I simply can't imagine what will they achieve in few years, but I'm sure all of current proprietary games won't even compare with those developed as a part of The WorldForge Project [worldforge.org]
So yes, I think promoring WorldForge [worldforge.org] is worth losing all of my karma.
Now back on topic...
You may want to announce your plans on the cpptraining at worldforge.org [worldforge.org] mailing list. It's originally meant to learn C++, not C#, but it's read by people who want to learn how to write MMORPGs, and those who want to and really can learn, like Bryce Harrington, so it's a good place to find people who can help with your project.
Also check out the other WorldForge mailing lists [worldforge.org], especially Protocols [worldforge.org], Server [worldforge.org], Client [worldforge.org] and General [worldforge.org].
Read the Development Area [worldforge.org] on WWW. Read about servers [worldforge.org] and clients [worldforge.org]. Use WorldForge protocols [worldforge.org] and libraries [worldforge.org]. Download games [worldforge.org] and read the source. You'll find there everything you need.
Re:WorldForge (Score:3, Informative)
Follow the Rules of New Software Projects: (Score:4, Insightful)
An argument over the language it's programmed in will only make you lose time on what is truly important, the project itself.
Second: Ignore the nay-sayers who say it's too big of a project.
By the time they give you a full, thought-out reason why you can't do it, you'll be half-done.
Third: Do listen to people who have done it before.
Browse programming newsgroups, MMORPG newsgroups, hopefully one of the coders will connect and you'll be able to pick their brains.
Fourth: Don't get dragged into the open source/closed source fiasco.
You should be programming for just yourself, unless you have a team, then it's a free-for-all
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
Re:Follow the Rules of New Software Projects: (Score:3, Funny)
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!
Re:Follow the Rules of New Software Projects: (Score:4, Insightful)
You must break a project like this into smaller pieces. You must have a forseeable point when you can release something. You can't forsee the end of a project as big as this, so you have to design intermediate points into it where you have something that is at least interesting to other developers, but much preferably is of some interest to gamers (even if only forgiving gamers).
Open Source ideals aside, it's very hard to maintain dedicated to something that only you have ever seen. Also, incremental development is just more likely to be successful.
Re:Follow the Rules of New Software Projects: (Score:2)
MSFT: Market capitalization: $337B
SUNW: Market capitalization: $33B
That's a factor of 10.
C//
Re:Follow the Rules of New Software Projects: (Score:4, Insightful)
If you program in C# you're limiting yourself to an untested, almost unportable language and to the Microsoft platform. I would think that if you were serious enough to waste all of Slashdot's time with this question, you would be serious enough to choose a real programming language, not some Microsoft marketing scheme.
I don't think this is particularly true. For one thing, Ximian/Mono are developing their own C# compiler [go-mono.com]. They're also developing their own runtime [go-mono.com].
Another point is that Microsoft's operating systems own 90%+ (probably more than 95%) of the home computer game market, so it hardly seems to be a limiting choice, even if the Mono project fails. And no matter how much you dislike Microsoft, I think you have to admit that their notion of a "common language runtime," which makes it rather trivial to integrate components from all the supported programming languages, is a brilliant concept. It may take Microsoft to a whole new level of domination, but that hardly makes the idea some sort of evil.
For the record, before you label me as some sort of Microsoft shill, I'd like to point out that I'm composing this response using Galeon running under Mandrake 8.1, and my company bases all its software development and web hosting on Linux, Apache, Tomcat, and Java. I'm one who believes that the main reason that Microsoft is where they are today is because they actually respond to their customers and most of their competitors behave like morons. Ever try to use Solaris without installing all the GNU versions of the standard utilities? The Sun versions are generally inferior and an outright PITA to use. Microsoft doesn't force that on Sun -- hell, they could just use the GNU versions.
Mud-DEV mailing List (Score:4, Informative)
FreeCiv (Score:5, Insightful)
Yes I Have (Score:3, Funny)
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.
freeciv! (Score:3, Interesting)
Yes, it's been done before, by freeciv [freeciv.org]
I never miss a chance to plug freeciv, because it's my favorite game, and a prime example of what good can come from programming free software.
freeciv takes the same client/server approach you're advocating, and, as near as I can tell, scales somewhat. Now, if you've got a lot of graphics going from client to server, it might not work the same. So I recommend freeciv just as a starting point.
Have fun!
Some Advice (Score:5, Interesting)
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
Hope that helps,
ben.c
Re:Some Advice (Score:2)
This is very good insight. However, I think C# is a great choice and an exception for this situation. If you have a C++ or Java background, learning C# is extremely trivial. Plus, the networking libraries of the
Try AOP (Aspect Oriented Programming) (Score:5, Interesting)
AOP might be a great way to handle the problem of dealing with the update issue. You can program as though they are on the same box and code your aspects to deal with what to send and when. It's not an easy thing to learn (think when you went from procedural to OOP) but it can pay huge dividends.
I use AspectJ (www.aspectj.org) but that's for Java...I don't know of any AOP toolkits available for C# since it's such a new language.
Good luck.
Re:Try AOP. Sort of like... (Score:2)
...this [faeriemud.org]?
Some advice... (Score:3, Insightful)
DON'T LISTEN (Score:3, Insightful)
Try supporting a large java app, with folks who may have to install JRE's, open up security settings in their browser sometimes talking to an admin before being permitted to do so, who will find ENDLESS incompatabilities between various versions, and will discover that that java does NOT look "like what they are accustomed too" and you have yourself a gargantuan support, installation and education headache the like of which you probably have only had nightmares about.
Mix that with the fact that you WILL be taking a performance hit by going to java, and the difference in performance between Java and C# is only likely to INCREASE and the technical arguement becomes even simpler. Remember that Microsoft will be droping Java support as fast as they can, do you think future IE/Windows is going to have a JVM? No chance.
Mix with the face that C# at least so far appears to be an HONEST open standard, unlike Java's endless standardize promises, which have been repeatedly broken so that the only ones who continue to defend their promises of open standards are the insane java zealots, and you have a solid business (open standards are better, safer, and do not put you on the hook to a commercial company) and even moral decision that is clear cut.
Re:DON'T LISTEN (Score:3, Interesting)
Try supporting a large java app, with folks who may have to install JRE's, open up security settings in their browser sometimes talking to an admin before being permitted to do so, who will find ENDLESS incompatabilities between various versions, and will discover that that java does NOT look "like what they are accustomed too" and you have yourself a gargantuan support, installation and education headache the like of which you probably have only had nightmares about.
If you need a JRE, include one with the game installer.
If you do not know how to change security settings in the browser, then use the regular version. If you have an 'admin', you should probably not be playing a game (at work? at school?).
If you include a version of the Sun JRE that your product works with, then your product will work.
I do not see how java can be 'what they are accustomed to' or not. 99.99% of games have a custom UI anyway. Java apps can be double-clicked on. What is the issue here?
You will be taking a performance hit going to java. Most of a game's speed depends on the video card. It is hard to max out a modern CPU. With a JIT compiler (or a native compiler, if you so desire), you can eliminate most of the speed hit.
C# appears to be an honest open standard created by a company that has historically proven that they have no interest in keeping interoperability any longer than it takes to lock in developers. They will undoubtedly come up with 'extensions' that will make life, if not impossible, then at least difficult for any non-MS users/developers.
I would go with Sun's stupidity over MS's malice any day of the week. At least I know Sun isn't -trying- to screw me over.
--Dan
Re:Some advice... (Score:2)
Linux is for suits. Or sell-out geeks. Or geeks which really want a language like Smalltalk or Common Lisp, but either are ignorant of their existence and maturity, or are programmed to immediately dismiss all languages with a non-BCPL-derived syntax.
Re:Some advice... (Score:4, Interesting)
It runs just fine on my Windows.
It always looks and feels awkward, and never 'fits in' the platform it runs on.
Eh? What are you talking about?
* It doesn't seem to really be that 'portable' in the sense that Java programs often seem to work in unexpected ways on different platforms
Having written server software in Java for the past 3 years can't say I've really seen this. I'm still amazed by the fact that I can drop my binaries on the occasional Linux or Solaris box and it just works. It's definately more portable than anything else I've worked with. Most often portability comes down to the experience of the programmer. Java doesn't prevent a newbie from being stupid and screw up portability.
* He can probably compile C# down to any platform he wants to, as Linux seems to have C# compilation support, and other platforms will probably have this soon.
It's not the language thats important, its the libraries. Java has them, C# doesn't have them outside the Win32 platform.
Re:Some advice... (Score:3, Interesting)
What you are talking about 'Looks and Feels' is the auto-rearrangement of GUI widgets with some 'Layout' supports. The 'Layout' support is designed from the ground up for cross-platform, such that the GUI widget adjust themselves for different constraints like windows and screen sizes.
Few other language offers such a cross-platform convenient. You can place the widgets pixel-by-pixel in java if you like, but it hurts the portability.
I studied C# a great deal before giving comments on the comparison. My observation is that C# almost has one-to-one mapping of the syntax of Java, some are so un-innovative that adding an 'i' before the keywords. It seems to me another 'embrace and extend' practice.
Of course, I didn't mean C# is a bad language. Doing something based on existing successes would at least yield something good, so I always keep an eye on C#.
Re:Some advice... (Score:5, Informative)
Java has a lot of overhead. But that overhead is there for a reason. Java code gets faster over time as it runs (both due to optimizations done at run-time and the fact that class loading is still an expensive operation). However, in the case of a massively multiplayer environment, Java may be (and probably is) the best choice for the server environment. In a controlled environment where the application is expected to run for a significant amount of time, Java can actually perform as well or better than natively compiled code.
The "Java is slow" argument is soooo tired. Sure, there are many instances where Java is slower than other languages (even C#). But if you're going to knock Java's performance, explain why or shut the f@#* up.
Re:Some advice... (Score:2)
There are real performance issues here, to the point (if you want to do it right) you need to think of it as systems programming. You'll have non-systems programming as well, which doesn't have to be in straight C, but I think there would be wisdom in a C-based foundation.
The typical place where Java is used as a server would be web pages, but there really isn't a big need to perform well there. Obviously, since people even use Tcl for that. A multiplayer game can't be batched in the way web requests are, so it's a very different performance situation.
Map/Update idea... (Score:3, Interesting)
Re:Map/Update idea... (Score:2)
Or how is he supposed to 'broadcast' to multiple addresses?
I believe IPv6 may have something for this, but nothing I know of in IPv4
Besides, are the clients supposed to ack this information to the server? If so, you have per-client overhead, and at best saving around half of the overhead of sending it to all clients separately.
-- Flamebaits in sigs: The best way to spread stupidity
Re:Map/Update idea... (Score:2, Informative)
Thoughts (Score:5, Interesting)
None of those solve the major problems you're really asking about though: how to decide who gets to know about what. Worldforge [worldforge.org] is the only open source project I can think of to point you to in that area. Perhaps some MUDs might be useful as well, but they tend to be based on rooms, not areas, which doesn't translate well at all to most other games.
Probably the biggest problem is avoiding N^2 operations as much as possible. At some level, there's no way around it: N players in an area generate events that have to be propagated back out to N (or at least N-1) players. This obiously makes scaling to arbitrarily large populations difficult. On the other hand, if you can guarantee a set maximum number of players in an area/server/whatever, you can target that maximum and not worry about it a whole lot.
A slashdot post isn't really the right medium to answer this question. There aren't any quick and easy answers, you need to figure out what makes sense for your game on your own. I've spent a large portion of the last year thinking about these problems myself, and I wish you the best of luck on it. I'm having a blast myself, but it's also the most challenging work I've ever done.
I am interested in hearing your reasons for using C#. That's actually somewhat shocking, but maybe it's just ignorance on my part. I can't imagine why you'd want to bet the farm on such an immature system, regardless of the strengths you've perceived in it. What does it do for you that C++ doesn't, and is it really worth it?
Re:Thoughts (Score:2)
I agree that Netrek certainly has example aspects of what this guy is trying to do. State is held entirely on the server, and only a subset of information important to the player based on their tactical perspective is transmitted.
Now as to why C#. I don't understand what this guy is exactly trying to do. A massive multiplayer strategy game sounds like a rather large undertaking.
I have been throwing around the idea in the back of my head of writing a version of the Netrek server and client using C#. As far as worth, I see it purely as an educational undertaking. If it works, then the result may be more maintainable and extensible than the existing C code.
In the case of netrek, I doubt performance is an issue considering the game used to run on minimal hardware by todays standards. But in a massive multiplayer strategy game, I could see that as an issue.
I probably won't go forward with this because I have little interest in games these days. But it is interesting to think about.
Re:Thoughts (Score:2)
Ok, that's fair enough, but I think something that isn't always clear outside the gaming industry is that most of the people who work in it (especially those who are successful at it) are the ones who like being plumbers. If you think about it, it makes sense: a large portion of the history of game development centers around coding increasinly complex games for the same platform that ran last year's games. The playstation 1 was a "current" platform until a year ago, and it only has 2MB of RAM! TWO MEGATBYTES. The PS2 still only has 32MB, way behind PCs, where you need more than that just to load Windows. There's a lot of baggage to get rid of before most game programmers will start considering things like C#. (I've mostly done PC programming, just using the PS as a graphic example, because it does still apply to some extent)
When I say C# is shocking, it's partly because I'm trying to imagine myself going into work and suggesting it to a bunch of programmers who are used to programming "impossible" things on minimum spec systems. Even moving to C++ has been mighty slow for a lot of studios. No one would even take me seriously if I tried to push C# on them. "Let's code it in Java!" is already guaranteed to get a laugh from any game developer I know of. C# has the same sort of negative connotations.
I generally try to stay out of these language discussions, because I've come to realize that being in game development has skewed my perceptions a bit over the last few years. "Let's code it in Java!" isn't automatically funny in other industries, I know that. And I suppose it's the same with C#, but being newer, it's even higher up the joke-language-for-games scale.
Re:Thoughts (Score:2)
In any case, this kind of game doesn't seem to be as speed-dependent, as for example, is a FPS. For this type of game, I think the focus would be more on cool features, a more engrossing world, interesting AIs, interesting networking methods. Something a higher-level language should be able to handle with ease.
Re:Thoughts (Score:2)
But there's nothing new in those features. Sure, they're things outside of the domain of C/C++, but languages like Common Lisp and Smalltalk have had those for 20 years. C# doesn't have anything that they dont' really, other than a huge amount of marketing dollars. The .NET VM/CLR system however, is quite interesting, and could also present an advantage for a project, perhaps allowing different developers to work on their own components in the system, but without having to settle for C#.
wow, don't even know where to start (Score:5, Insightful)
The only communication from clients would be commands to units, which is simple enough
Generally the way this is handled is setting up a TCP communication for critical information, such as the stats of the player, text communication etc.. then send small UDP (connectionless) messages for non-critical data, such as player and monster movments. Be warry of using TCP for everything, this is something Anarchy Online did, which caused some pretty massive problems on the server side.
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.
There are two approches for this, one is a moving 'buble' of information, where you update the client with all data within a certain radius, another is the zone approach (i.e. everquest) where you send the an entire zone worth of information. Note that you are not sending everything, only monster,player movment and state (are they fighting).
What should the object model look like?
I have no idea, i imagine it would be far too large and complex to even describe in a slashdot post. However i recommend you look at it from a top down view, then try implementing from the bottom up. For example, you know that you have a 'world' and the 'world has players, monsters and items', 'players and monsters' could be concedered 'actors' with certain command antributes. 'actors interact with items' etc.. you should start seeing how to construct a object model. also don't worry about what this looks like at first and you will no doubt be revising it as you go a long, make things the work and compile so you have some possitive feedback for you hard work. When things seem out of hand, step back, make some coffee and draw out what you have and try to thing of a way to break it apart into managable sections.
ok that is all, good luck.
-Jon
Re:wow, don't even know where to start (Score:2)
-Jon
Re:wow, don't even know where to start (Score:2, Insightful)
That is why most MM games use UDP largely and have gaming models that support the shortcomings of UDP. UDP for data where reliability and order is unimportant ( just impliment your own protocol on top of it to solve the problem of dropped / out of order packets), TCP/IP for reliability.
The last MMORPG to use TCP/IP primarily was AO. Very successfull implimentation Im sure youll agree.....
Don't forget Client-side Prediction (Score:5, Interesting)
Heck, players can be pretty predictable objects themselves, if you want to get fancy. Most games have pretty simple algorithms predicting the future state of a player character (if player X is moving in a straight line, he'll probably continue to do so.) But I think you can get fancier than that. What about curves? (circle strafing) Or if the player is repeatedly hitting a button every half-second. (chopping wood?)
It'd take a lot of coding, but the master server could conceivably take note of each player's input characteristics and compile some sort of "personality" profile for each one, which it could transmit to clients every time they start up, to help with their local prediction.
Please note that I have no idea how much CPU time this would take up,
make it as parallel as possible (Score:3, Interesting)
Obviously, until things ramp up, you should be able to do all this with one server, but making these parallel states will make scaling much easier when the need arises.
Two strikes ... (Score:5, Interesting)
In all seriousness, in my opinion (unless you're doing this solely as a personal learning experience), you are starting with two critical strikes:
1. You're trying to do a major project in a language you don't know (and an immature one at that).
2. You're trying to do a major project in a genre with which you have no experience.
Either one could cripple the project. Put them both together and you're doomed before you start. You may eventually make it work - sort of - but it will never work well, and it will be riddled with bugs.
I encourage you to start by developing a small multi-player game in a language in which you are already proficient. This will let you focus on the design and structure without fighting the language. Keep it simple, manage the scale, but incorporate the kinds of capabilities you want in the final version.
When you've got that working, throw it awy and develop it again in C#. Since you're starting with a working design , you're now free to focus on the mechanics of the language. You need time to learn its limitations and idiosyncracies, and to become proficient. (I will let others debate the wisdom of C# - I'm skeptical of all proprietary languages, especially until they're field-proven.)
Once you have succesfully finished a small project in C#, you can begin planning your real game. Based on your experiences, you may decide to scrap C# entirely. If you choose to stick with C#, then throw away ALL of your original code and start over. No matter how good you think your first code was, by the time you finish the big project you will know that it's crap. Might as well get it out of the way up front to reduce re-work and improve the overall quality.
Of course, if this is a project you've been assigned as a commercial effort, you won't be given the luxury of doing it well. You probably already have a deadline pulled out of thin air, and you're probably already behind schedule. Speaking as a pointy-haired boss who actually has significant coding experience (a long time ago, in a galaxy ... etc.), most PHB's have no clue when it comes to software development. They work with the suits to draw up pretty little Gantt charts, and haven't the foggiest notion as to why they are complete fantasies. You can see some of the results in the bargain bin of your local Best Buy, or in the "still delayed" list of your favorite gaming magazine.
In any case, good luck.
Strike 3 (Score:3)
So to sum up, you have no clue what you are doing (the very fact that you asked it on slashdot, of all things, is an evidence of that); you don't know the language you want to use; and, instead of evaluating your options, you decided to ride the hype, perhaps to make your CV buzzword-compliant. Therefore, this project is doomed before it is even started.
Oh, and just to throw in some more buzzwords, I suggest you make it a Web service using the
Re:Two strikes ... (Score:2)
If we tried to learn bridge-building by starting with the Golden Gate, we'd be at the bottom of San Francisco Bay.
Who said anything about giving up? Just start with something manageable and build on the experience. Programming is an art form. "Software Engineering" is an oxymoron unless your project is staffed with developers who are already proficient in building very similar systems.
Is it this easy? (Score:2, Insightful)
Just thinking out loud, but it sounds like the client subscribes to updates from units in a particular "area" (defined however you like) and will automatically be subscribed [sun.com] to the "partial" or "distant" updates for adjacent areas. A client's key allows it to subscribe to exactly one area at a time.
Server side you keep a list of client subscriptions and something like the PropertyChangeListener [sun.com] approach from Java to simplify the updates from your units. I think any solution has these or similar elements, your implementation will depend on what C# can do for you. I don't know anything about that. I used Java links as examples , since I didn't find any C# API links out there.
Please let me know how things go, and I'm interested in feedback on my ideas from more experienced MMPG builders out there.
An idea I'm kicking around... (Score:4, Interesting)
Rather than the server handling 100 clients, when it needs to push out identical data to all 100, you push out data to 10 of those clients and rely on those 10 clients to push out data to another 9 clients.
You can also push in the other direction. When client 1/100 says 'Hi!', rather than pushing it to the server to push it to 100 clients, the client pushes it to the client he's attached to, who pushes it out to the other 8 people, as well as to the server. The server then pushes the 'Hi' out to the other 9 clients it's connected to, who pushes out to their respective 9 clients.
It's akin to treating the connection to the server as some sort of nested tree; you introduce latency but reduce the amount of server lag.
Re:An idea I'm kicking around... (Score:2)
I think there is also the problem of peer-to-peer connections from a security point of view. Hacking a naive player's machine would be quite easy for a directly-connected, semi-sophisticated player.
Re:An idea I'm kicking around... (Score:2)
Server getting too many requests for resources.
Client getting pushed too much information.
Client getting pushed too little information.
Planned, intentional, latency is much more workable than a classic DoS. As a workaround, for example, you introduce locality.
IE, people get clustered around deputized local servers, so that you can bypass spanning the network.
If I broadcast 'Hi', it only needs to go up to the server and back down, but it's only spread around the local group. That way people in the virtual geographic space don't get spammed with my packets and lag is much reduced.
Anyway, that's just an idea.
Wrong approach if you wan't to succeed .. (Score:2, Redundant)
If you were te write your first novel, would you consider writing it in a new language just to learn it ?
If you just want to learn or fool around with some code, go ahead. If you want something decently done, use everything you already know... there will be more than enough challenges and things to learn down the road without looking for them.
just my 2 cents.
--red
www.gamedev.net and more (Score:3, Informative)
Next, C# is not the way to go. Its a new language, both in the programming world and to yourself. You'll only dig yourself into a pit with it. I would suggest C/C++ for a 3D engine.
Finally, assuming this is a 3D engine (which, if it wasn't, would have no chance of making it in todays world), pick what 3D API you are going to use. Since you are chosing C# as the language, I assume that you have to pick DirectX (am I right in my assumption). However, if you were to pick C/C++, you could use OpenGL, not only the better of the two API's, but then its instantly portable to other operating systems.
Hope this helps.
-Vic
P.S. See sig for the game engine I am writing.
A threaded suggestion (Score:4, Informative)
One thing that I've had quite a bit of success with (because others did it long before me), is a clean mapping from a thread-model to flat-earth style geographies.
You can divide your "world" into square-miles, acres, hectares, sq. km, or whatever else is fitting. Heavily-objected areas (heros/boss regions, domain entrances, towns, etc.) have a finer resolution thaan open gaming spaces. Then, each region has a controlling thread to track it's stationary objects/events, transient objects (like characters), and drops.
Clients represent a simple intersection of threads, in terms of FOV, and you rarely run into the "four corners" issues (when a client is at the vertex of 4 thread-spaces. But even so, this 4-threads-feeding-one-client is a very light worst-case.
Now, I don't do C#. I do Java, C++, and LISP. I can only imagine that C# has robust language-level thread libraries and if so, you're good to go in the flat-earth. If not, you'll really have your work cut out for you. A single-threaded world can't really scale to "massively multiplayer." If you have any more questions, drop me a line. (I wrote a decent paper on how to partition a flat-earth world-space.) =)
Re-inventing the wheel? ;) (Score:3, Insightful)
The powerful server is released under GPL. It is quite neatly written in ansi C and is ported to numerous platforms. Clients for it exist both in command-line form - in C and Perl, and in GUI - VB and PythonTK.
The most difficult thing in such a game is not the programming one, that one is in fact relatively easy. Inventing the rules and the possible scenarios is the challenge!
If you just want to practice Client-Server programming, you better write a server for a game with simple rules, aforementioned chess for example.
Client/Server model... (Score:3, Insightful)
Re:Client/Server model... (Score:2)
Re:Client/Server model... (Score:2)
Re:Client/Server model... (Score:3, Insightful)
No, the viewable state of the world has to be calculated on the server, or on a Grid environment if things are getting hefty in the calculation side of things. It is a downer, yes...
If the client has the map, even a local map, then that player has an advantage if they have a modified client that erases the LOS algorithm.
And that is just one of thousands of security holes the product would have. Scary eh, how client-server is harder to do when you have real people in the equation...
Some ideas... (Score:3, Informative)
Stuff like "How can I make the networking code as transparent as possible so I don't have to write SendUpdate() after every assignment?" we can't answer. I mean, it's all events, and there are hundreds of ways to write this. There are countless examples. GUIs are event driven, for example.
A long time ago I wrote a multi-user game. It wasn't anything fancy, but it did the basics of what you are trying to do. It turned out that calling SendUpdate() wasn't the problem -- that's easily done with proper design (inheritance, etc). Heck, you can encapsulate the whole message in a class and let the constructor/destructor take care of it, if you want... The main problem was scheduling time to clients, especially when one client was slower than another. For example, it would be unfair for a fast client to send 10 move messages in the same time that a slow client would send one.
Another distinction you need to figure out is what needs to be real-time and what doesn't. For example, if the program supports inter-user messaging, you can implement "soon-enough" delivery rather than "just-in-time" delivery. It all depends what it is used for. That can be done with a MQ type setup rather than a real-time connection, and it can be sent from client directly to another client.
I wish I could work on such a project again.. open sourced, closed source, I don't care, just not commercial. But the internet is littered with the graves of abandoned open sourced programs, which tells me a little about how much commitment people are willing to put into these things.
Use Jabber! (Score:2)
beware floating point! (Score:5, Informative)
Using emulation or fixed point is either too slow or too inaccurate, so I ended up just doing all the work on the server and doing continual sychronization.
To be more precise, in order to smooth out 'lag' time, the clients would do their own emulation, but would resychronize all decisions on the 'heartbeat'. Using interpolation, this worked out to have great apparent lag response, even lag times of 3 seconds were smoothed out. The only problem then was when a client's lag was unstable, fluctuating a lot. I smoothed this out by emulating a 1 second lag in all circumstance, so everyone has a smoothed out lag response which isn't too bad to play. Only unstable lag of 2 seconds or more caused a problem, where that client would see his character jump around everytime synchronization kicked in.
My Experiences (Score:3, Informative)
Basically, I've broken it down into 5 objects: Game, Map, Sector, Player and Item. The ownership relationships are as follows: Game owns one or more Maps, and zero or more Players. Map owns one or more Sectors. Player owns zero or more Items.
There are three subclasses of items so far: Trivial (like swords and onions), Units (like tanks and horses), and Charactors [sic] (like Mario or Frodo). There are also interfaces for the items such as Movable and Jumpable.
Check out Metagame-Sector [sourceforge.net] if this model interests you.
Here's the basics (Score:4, Informative)
The only remaining issue is what we call "who is right?" If one game claims that a ship blew up because it was hit by shot, and another game claims that the ship dodged at the last minute, who is right? If the game is client-server, the answer is easy: the server is always right. In fact, clients shouldn't even display "big" events like a ship blowing up until it has confirmation from the server that that is what really happened. (Sometimes it's a good idea to use "hint" animations - if the client expects that a ship has been hit and is going to explode, but hasn't received confirmation from the server yet, you might want to show a shower of sparks. Then, if the confirmation is received a moment later, the explosition doesn't seem to be delayed quite so much.)
In peer-to-peer, things get much tougher. In some cases one of the peers simply declares itself a server, in which case you have the situation above. In true peer-to-peer, it's simply up to the game designers. The most obvious choice is to make each machine responisble for its own position as well as the position of the objects its has created. So the player controlling a given ship has the last say on where that ship was at any given moment.
In some cases, you may find that certain game elements (especially if it is an action game) don't work very well when you have to deal with 100ms or more of delay on network traffic. In that case you may want to remove or change those elements. You should pick a number where represents your "maximum" allowable delay, based on whether your target audience is modem users or not.
Unreal networking architecture (Score:2, Informative)
One failure ingredient: experimental new language. (Score:2)
You could succeed anyway, but then you could be a successful pianist with three missing fingers too. That doesn't mean you want to deliberately chop off three fingers.
Use Ada 95. (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 [act-europe.fr] (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+ [act-europe.fr], 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:Sounds a lot like our project... (Score:4, Interesting)
...except you can substitute Ruby for C#.
Our Documentation Index [faeriemud.org] page gives a basic list of the areas we have documented. The General Philosophy [faeriemud.org] describes our philosophical outlook, while Core Concepts [faeriemud.org] describe the main ideas which are needed to understand coding FaerieMUD [faeriemud.org]. Our engine [faeriemud.org] is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.
The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.
The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)
Good luck, and let us know if any of your ideas look like they'd help us.
All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.
This is a lot harder than you think. (Score:5, Insightful)
I can already see the debate about C# heating up over this -- but that's tangential to the real problem. It's not that C# will doom your project, it's that you wouldn't choose C# if you knew what you were doing (and your project weren't already doomed).
First, my personal suggestion (and I say this as a developer with 2 years commercial MMP development experience at this point): EITHER you want to write an infrastructure, OR you want to write a game. Writing both by yourself will take you the better part of 10 years. Having another programmer around who is doing the other part is handy -- but making sure that they are separate tasks is important. I recommend ditching C# to use Python, and my personal infrastructure project, the Twisted network framework (http://twistedmatrix.com), but if you're not going to use that, then find another high-level language with good asynchronous networking support and the ability to load code at runtime. Other good possibilities are Common Lisp and Scheme.
If you don't have any experience in the area, and this is for an Open Source project, join an existing project and learn some things from there. I can also highly recommend getting involved with a failed project in the game industry to see how difficult the whole thing really is
Be prepared to fail at least once. The number of failure points in an MMP project is astronomical: client code, server code, internet latency, even the community itself is a potential "bug". If your technology is great and your game is fun, but it attracts really mean-spirited people for some reason, you might see your servers empty out over the course of a few months, or never even get to a real "massively" multiplayer state.
Common Lisp? (Score:2)
Re:This is a lot harder than you think. (Score:2)
python.
A good majority of python coders are win32 platform based.
so what are you saying?
Consider 3rd party middleware (Score:2, Interesting)
Take a look at Terrarium (Score:2)
Terrarium is a multiplayer ecosystem game developed using the
It will probably give you some ideas on how to implement this kind of thing.
Learn from experience... use LINUX or UNIX equi. (Score:3, Flamebait)
They used NT and C (Asm too?) to develop Everquest and they are paying for it dearly.
Everquest has had up to 80,000 simultaneos users which were distributed over 200 NT servers.
These servers are in two locations and they have two FULL TIME employees who walk around all day -- their sole job
In addition, they've had nightmare situations with patching and keeping these systems up to date.
And another thing I know is that their next game (forget the name) they have started nearly from scratch and are developing on a UNIX derivative (may be linux... not sure) mainly because the costs of running the game on NT are too great...
learn from experience...
Cheating - some older Slashot articles (Score:3)
Combating cheating in online games [slashdot.org] (16 November 2000)
Multiplayer Game Cheating [slashdot.org] (16 July 2000)
C# (Score:2)
My 2 cents (Score:2)
2) Don't use C# for everything*
3) Break the project down into parts that are actually accomplishable (i.e. network layer, world engine, actual game). Choose one of these layers and actually get it to work.
4) Read lots of books because it's gonna take a lot more than a couple of comments from
I don't really know of a great networking book, but you would really need to brush up on newtonian physics. There is an aweful lot of physics involved and 3d hardware will for the most part, not calculate this for you.
5) Pay your dues on some open source gaming engines. Get your feet wet before diving head first.
* C# is bad only because your gonna need big time speed for the 3d engine. The server is likely to require a bit of speed in handling client requests efficently too.
For these areas, I would recommend C, or C++ if you know C++ _really_ well. C++ can be just as efficent as C but you have to know _exactly_ how C++ works and you must know the spec inside and out.
C# is really fine for the frills of the engine, but any VM based language would not do well for the heart of the engine.
Key is to use languages where they are appropriate.
GarageGames and Tribes networking model (Score:2, Interesting)
You might also want to check out GarageGames [garagegames.com] for some other game development resources.
A little vague (Score:2, Funny)
Why would anyone ask a slashdot group about a C# project?
Try doing it the easy way first... (Score:3, Insightful)
If you have no prior experience writing this kind of application, I'd recommend using somekind of a framework to provide you the basics. This will save you the roughly 1 billion design mistakes you are likely to make. If you were experienced with this kind of thing, I'd give you different advice. But for your first run it'd be a smart idea to learn a decent design that someone else has already done.
You could look at a few open source projects which are doing this thing. If you don't like any of them, the other thing I'd suggest is using a J2EE solution. What you're describing sounds like a good fit for a JMS-based solution, particularly using message-driven beans. The nice thing with a J2EE solution is you have a proven framework to work within that can provide you with the scalability, availability, and reliability that you need.
I'm not against reinventing the wheel, but it's best if you have some experience before you do that, otherwise you'll end up with a triangular shaped rock.
MMPORG Servers (Score:2, Informative)
Spatial Data Structures (Hanan Samet) describes a set of aglorithms such as quadtrees (2 - 2.5D), and octrees (3D) which can be used to solve the proximity problem in log time in multidimensions, i.e. you can find the N players within a reasonable distance in a pretty short period of time. In fact, you only have to traverse down once, then traverse back up until you're out of range. Insertions are log N as well, so the server should be limited on network bandwidth, not processing power. You can also give priority (send this packet first) to the player that you're looking directly at (or who's looking at you), with diminishing interest in other players (if his back's to me, and mine to him, I don't care quite as much as if I'm looking directly at him),
The second part is "what happens if I don't get a packet for an assigned player in time", a typical UDP problem. In a flight/driving sim game, you can "guesstimate" with an area of probability where the player's going to be, and if you're shooting at him, give the probability of a hit. Sometimes you'll miss when you should have hit, and vice versa, but you have to do something.
Do the canonical system first, with objects in 3-D space which can manueuver and shoot to tune your algorithms on the server, then you can refine the game. Doing a simple "space shooter" should be relatively easy. You can make robo-clients with scripts to test out your weights and probabilities. Once you have the empty space shooter, you can add a world with static objects, which should be replicated on each client. Dynamic worlds (walls falling down, etc.) are much more complicated, where you have to set the before and after on each client, and kick it off with a trigger. Dynamic interactions get a tad too complicated even in single player games.
If you're doing a game with animated players, it's easiest to have pre-programmed positions (running, shooting, slashing with the sword, kicking), so only a code for the target of the action has to be sent down. You can't ship down full animation information, it's too expensive. Unfortunately, it makes fighting unrealistic, because there's no reaction to the pre-programmed code. Doing interactions between figures is an N^2 problem (I block his kick), which while doable, requires a lot of hand-animation work. Full inverse kinematics is computationally prohibitive (AFAIK), but there are approximations that are quite realistic.
Keep your hopes up. There's a lot of stuff out there that's not very good because it was put together in a hurry.
For the networking stuff, try some tuning of packet sizes and rates for different scenarios (modem, DSL, high ping times) to figure out what's most efficient in terms of accuracy and percentage of arrived packets. You should be able to figure out your optimal packet size and rate for each scenario.
Re:one-to-many (Score:4, Interesting)
For example
1) If the maps are client side, I can look at them and see things my opponent and the server don't think i can see.
2) If the rules are client side, I can subvert them. "Hello server, I'm now moving at 100mph and I have 3,000,000 ammo."
Security Reasons (Score:4, Interesting)
In Java, I have played Dusk (dusk.wesowin.org) which is a basic graphical MUD style environment but seems to be okay and contain a reasonable amount of the basics. And Java is like C# in many areas except supporting reflection and other good ideas, unlike C#. I should mention WorldForge as well.
Re:Security Reasons (Score:2, Informative)
And Java is like C# in many areas except supporting reflection and other good ideas, unlike C#.
I don't quite understand your sentence, but if you're implying that C# doesn't support reflection then you're wrong. C# has FULL reflection support and goes beyond java (like C# attributes).
Look for the reflection classes under the System.Reflection namespace.
Re:one-to-many (Score:3, Interesting)
You could basically write a game that put a display up on multiple X terminals. This would have multiple views into the same world and allow multiple keyboard and mouse inputs to that world. The server system and network would have to be very fast to support this game. It is practically impossible to cheat with this setup too.
The other end of the spectrum would have the game distributed onto each machine, with all updates from every machine being multicast to every other client at the same time. This would allow each client system to distribute part of the load of the game and its display across the network. You would need a very fast network for this.
In between these two extremes is a central server that has clients connect to the server. The best way to distribute the work on this system is to look at what needs to be done. The local system will render the view and play the sounds. It will need to send it's mouse and control movements to the central server. The central server will look at all the inputs and send back update information to all the clients.
It can also be slowly uploading the information it will need for the next level while you are playing the current level. You may also have an encrypted CD at each client that can only read the information when the server gives it a valid key. The key is not cached. You may also want to authenticate that the client is valid by performing a checksum on some portion of the system in memory and returning that to the server.
This way the rules are all on the server, so cheating will be at a minimum. But they will have all the map data, so a hacked client may give them more info than the other players have.
The next step is to also download the rules to the clients at game time and let the clients decide what is happening for themselves, then send an update to the main server which just distributes the info to the other clients on a need to know basis. This would eliminate all mouse and keyboard data uploads.
But having modified clients that allow cheating could be bad. You can minimize this by providing stripped binaries that authenticate to the server, but a determined cracker can get around that.
Re:I hope you just plan to code... (Score:2, Informative)
Re: (Score:2)
Re:Other languages to consider (Score:3, Funny)
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.....