Yep, that's a pretty decent model to use. Don't think the client even needs to subscribe actively - it would probably be possible for the server to work out the relevant areas since it would know the player's position(s).
My case is slightly more complicated in that I want to allow for pretty localised information hiding as a tactical element of the game.
For example, I want a player to be able to drop some smoke and create cover for a surprise attack. This means that your filtering has to be a little more fine-grained than an "area", and furthermore you have to calculate it all server-side to prevent the client from requesting info that it couldn't legally obtain.
That's a great idea. Since it's a strategy game I'm planning, the latency isn't too much of an issue, so while this would be a tricky thing to pull off in a FPS is could work well here.
I think it might combine quite neatly with the idea I had of "team servers" where an alliance of players can run a single server, which then connects onwards to the master server. I *think* this avoids the problem with security, since the team would be able to co-operate anyway and the team server would just contain the combined "world view" of all the allied players.
Think you could just nominate the team server in an ad-hoc way based on who has the best average ping times and available bandwidth - kinda like a P2P app. The only real issue is what to do when the team server goes down, but I think it should be possible to fallover to another connected client.
My solution to the client speed problem is to do the command dispatch/server updates pretty much independantly.
That way a client can send of as many commands as quickly as they like, without having to wait for a response. The guy with a slow connection gets a bit more lag before they see the result of their actions, but they can still work just as quickly, which is the main issue from the fairness point of view. Since it's strategy, reaction time won't be too critical I hope.....
Know what you mean about abandonware. Mostly the result of bad design IMHO, which is why I'm spending the time up-front to get the concept right before I spring something on the world.
Hmmmm... while I think Jabber is great I'm not too sure that XML is the right choice for data transfer. It requires a fair bit of processing at both ends, and tends to be considerably larger than an equivalent binary format. Good for config files and server management, less good for real-time communications.
Having said that, C# has a lot of built-in XML functionality so I expect I'll use this for a lot of data files etc.
Cool, thanks for the info. What you suggest is actually pretty much like my current design idea, although I haven't yet tackled the multiple map issue in too much depth.
One idea I did have was building a QuadTree of Maps, so they could be subdivided or extended pretty much arbitrarily. This solves a lot of the problems of having to worry about a fixed size of map, and means that you can transfer a localized map area just by picking the right branch or two of the quadtree.
I'm currently thinking of building all objects from a single "Thing" base class, which will handle a fair amount of the common networking functionality, e.g. having a unique id which can be referenced identically on the client and the server.
Yep, I've had a good read of this a couple of times - very impressive architecture.
Since I'm focussing on strategy rather than action, some of it isn't applicable, e.g. the client side simulation etc. isn't really needed. Which is lucky, because I don't think I could code something to match the Unreal Network engine in a hurry:-)
One thing I would *really* like to duplicate is the way that networking happens "behind the scenes" in UnrealScript. Ideally you should be able to code the bulk of your game logic without worrying too much about the networking platform underneath.
Not sure how easy this is to do in a langauage like C#. Ideally you would have objects which, when modified, would know to propagate their changes correctly. But this would appear to require writing networking code in *every* function that manipulates object state, which is hardly transparent.
Maybe you actually need the extra level of abstraction that scripting gives you in order to make this work.... unless anyone has a better idea?
Problem with all non-gc langauages is that they *really* suck at serialization/persistence because you basically have to roll your own code for every type of object you deal with. C can't traverse an object graph automatically because it has no idea where you have put your pointers.
Which is a right PITA for a network game..... not that it's impossible, but it's highly bug prone and very time consuming to update as you build your engine. And isn't laziness one of the three virtues of a great programmer?
C has it's good points, network programming unfortunately isn't one of them.
Thanks for the advice:-) I still reckon I'm OK to hit out with C# because it's basically a tweaked clone of Java, and my skills transfer pretty well. The main trouble I have is looking up the different names for the same functions in the Java libraries... and remembering that C# capitalizes method names etc.
Masively Multiplayer is an ambition, but I'm not sure whether I'll get there on the first iteration. I'll probably focus on getting the single player/team games/"deathmatch" games working well and then look at how well things could scale up.
I think there are three real challenges to going MM.
The first is that I would have to switch to the more complex but better scaling data structures, e.g. OctTrees and QuadTrees rather than Arrays. This would be neccessary to make sure that you can partition the server effectively and focus on localised changes.
The second is the persistence element, which is clearly a bigger issue when you have many players and a long-running game. I'm trying to design a "transaction log" into the game engine so that the server can automatically regenerate from the last known position, but this might not be enough if you have a horde of fans hammering your servers (I wish...:-)
The third, and certainly the hardest, is finding how to build your game design around the additional challenges that MM brings. That's the real test I guess - Is the concept right, and does the gameplay have what it takes to keep people coming back in a MM context?
I think it has to be push in this case - major/relevant events could be occuring at pretty much any time and when they do you would want to broadcast it to the client as soon as possible.
Pull could work, but I suspect it would just eat a *lot* of bandwidth polling the server all the time for events, and I don't see what it would buy you - you still have to transmit the event anyway. Guess it could be *slightly* simpler to code.
How badly can TCP get stuck? Enough to take a client out of the game?
Just curious, I was thinking it made sense for the kind of updates that absolutely have to get there. The other option would be to keep broadcasting on UDP until you get an confirmation/acknowledgement, but wouldn't that just be re-inventing the TCP wheel?
I was actually playing with C# recently trying to get DirectX to work and had some success. MS hasn't published the DirectX libraries for C# yet AFAIK, so I wrote some simple wrappers in C++ and linked them into C#. Not exactly elegant, but it worked and it was fast.....
You're right that C# probably isn't appropriate for the hardcore inner loops in a game. But I reckons it's broadly fast enough for most "management" jobs. I guess that I will take the approach of using C# generally and dropping into C++ when I really need the speed. Since this is very much a strategy game, I'm hoping that I won't need to do this too much.
Any open source gaming engines you think I should particularly check out BTW?
You raise some very good points - I actually hadn't really given that much thought to using a separate language for the server. Reason is that there is a certain advantage in using the same language for client and server in that you can get some *serious* code re-use.
I think the biggest issue is development speed. You only have to write all the object representations once, and you avoid all the bugs that could occur when you update the server but not the client and vice-versa. Less of an issue for a big commercial house, definitely an issue for a "Lone Wolf" coder like myself who needs to stay sane and motivated.
You can also use server code in the client to handle updates. My first draft at a networking protocol made heavy use of this - updates to the game are propagated where necessary and applied to both the client and server states of the world to guarantee synchronicity. The client and server representations of the game state are the same class, and it would be a real pain to develop two versions in two languages simultaneously.
You can even make the client and server the same program, to enable P2P style operation. Haven't thought it fully through yet, but If you had a muli-side battle with multiple players per side (lets say 50 players total?) it might make sense for some of the clients to become "servers" for their own side, taking the load off the master server.
Then there's always a whacky AI idea that I am planning to test out - Clone() the entire game state and let the AI try a genetic algorithm on possible command combinations. This could solve the classic "lack of collective intelligence" problem a lot of strategy game AIs tend to have. Admittedley you would probably want to do this on the server, but it seems like there could be a potential to offload some of this work to clients, e.g. letting a client process the moves for an "allied" AI so they would make no gain from trying to throw a spanner in the works.
Hey, it's a challenge - but I always think that's a good reason to do things.
It's not exactly like I'm inexperienced either - been coding for around fifteen years and I built a pretty impressive game previously in Java so the leap to C# isn't actually all that great.
My evaluation of C# is that while Microsoft are certainly going to layer on a great deal more advanced functionality and libraries, the core platform is pretty much there. Apart from the introduction of generics, I don't think they are going to do anything else significant that could require any re-engineering. The worst I'm expecting is a couple of naming tweaks.
I've actually found J2EE a little clunky for my tastes. Performance isn't good enough for a game server if you use Container Managed Persistance, and if you opt for Bean Managed Persitence you're effectively re-inventing the wheel anyway. Haven't really used the messaging beans though - I'll take a look into them to see if they would be useful/applicable.
Sounds interesting - didn't realise there was academic research into cheat-proofing! Might have to look at getting some grants to fund my endeavours:-)
I think that having the authoritative server with visible set event propagation solves *most* of the cheating problems.
As for the "time cheats" I have been less concerned because I have been trying to think of a way to actually make this a part of the game. I actually think that it's somewhat representative to strategy in the real world, where you wait for an opponent to commit themselves and then pounce.......
Well, I'm actually betting that either of both of Mono and dotGNU will succeed in making a decent C#/.NET clone that will be truly portable.
My assesment of this is that it's certainly possible - the.NET framework is very similar to Java in many ways, which has proved eminently portable in the past.
That's an interesting idea - I had thought about using multiple servers, but I had planned to only use them for P2P metadata sharing. This would allow discovery of game servers etc.
Guess the tree of servers would work best since I think it's necessary to keep a single authorative master, with multiple clients connecting to sub-servers.
This actually would solve one of my scalability concerns - number of client connections to a single server. This could become a problem because of the (relatively) large amount of processing required to work out the relevant set of objects for event propagation.
Well, I am a programmer who's made a reasonable amount of money from my software and I *still* think there is an important distiction between anauthorized copying and theft. Theft is the unlawful taking of property with the intent to deprive the rightful owner of it.
The loss suffered here is a financial one. But a software author has only suffered a loss if both of the following are true:
a) The person making and using the unauthorized copying would have bought the software otherwise. This usually isn't the case. People who have both the willingness and ability to pay will generally pay up.
b) The financial loss, if any, isn't offset by the advantages of publicity, getting people involved and skilled with your tool and developing your marketplace. Even students get jobs someday, and when they choose your software for their company you'll be glad you let them have it for free five years ago.
Of course, the *moral* argument regarding whether you should be allowed to make an unauthorized copy is entirely separate. The author could suffer no loss but copying could still be immoral, depending on your viewpoint. But that's a violation of someone's moral code, and specifically *not* theft.
Hmmm.... since using sqrt(i) chances the algorithm from O(n) to O(n^0.5) I'd say the speedup was a lot better than 50% in all but trivial cases.
Minor nitpick I know - but these things can make a real difference. I once saw some code-monkey write an O(n^4) sort algorithm..... writing code that bad actually takes some talent.
Hey, calm down. Was just playing the Devil's Advocate and all that. No need to go Ad Hominem on me.
The point was that illegal activities *can* be justified in a general sense. That may or may not apply in this particular case, and I wasn't making any particular judgment on that issue.
I was highlighting the fact that saying "illegal implies wrong" is a weak argument, and that you must take the wider context of the situation into account, and argue those issues rather than the legalities.
What about the obligations to oppose an unjust law? Slavery, for instance. Or are you convinced that whatever the courts/politicians decide must automatically be "right"? Should the US therefore still be a colony of the UK?
I'm not saying that everything should be "free and up for grabs". Just that sometimes opposition to laws, particularly oppressive ones, is justified. And that may sometimes have to involve breaking them.
I think that having announcements like this on Slashdot is effective. If I may draw a programming analogy:
It's an event driven notification system. These work because they deliver relevant information at the relevant time, allowing you to focus otherwise on all the the other activities you are interested in.
Going to kernel.org and the other 50 or so sites that *might* have an interesting release that day is a polling system, and far less efficient since 90% of the time you are checking for something that hasn't happened.
Slashdot Mirror
Yep, that's a pretty decent model to use. Don't think the client even needs to subscribe actively - it would probably be possible for the server to work out the relevant areas since it would know the player's position(s).
My case is slightly more complicated in that I want to allow for pretty localised information hiding as a tactical element of the game.
For example, I want a player to be able to drop some smoke and create cover for a surprise attack. This means that your filtering has to be a little more fine-grained than an "area", and furthermore you have to calculate it all server-side to prevent the client from requesting info that it couldn't legally obtain.
That's a great idea. Since it's a strategy game I'm planning, the latency isn't too much of an issue, so while this would be a tricky thing to pull off in a FPS is could work well here.
I think it might combine quite neatly with the idea I had of "team servers" where an alliance of players can run a single server, which then connects onwards to the master server. I *think* this avoids the problem with security, since the team would be able to co-operate anyway and the team server would just contain the combined "world view" of all the allied players.
Think you could just nominate the team server in an ad-hoc way based on who has the best average ping times and available bandwidth - kinda like a P2P app. The only real issue is what to do when the team server goes down, but I think it should be possible to fallover to another connected client.
My solution to the client speed problem is to do the command dispatch/server updates pretty much independantly.
That way a client can send of as many commands as quickly as they like, without having to wait for a response. The guy with a slow connection gets a bit more lag before they see the result of their actions, but they can still work just as quickly, which is the main issue from the fairness point of view. Since it's strategy, reaction time won't be too critical I hope.....
Know what you mean about abandonware. Mostly the result of bad design IMHO, which is why I'm spending the time up-front to get the concept right before I spring something on the world.
Hmmmm... while I think Jabber is great I'm not too sure that XML is the right choice for data transfer. It requires a fair bit of processing at both ends, and tends to be considerably larger than an equivalent binary format. Good for config files and server management, less good for real-time communications.
Having said that, C# has a lot of built-in XML functionality so I expect I'll use this for a lot of data files etc.
Cool, thanks for the info. What you suggest is actually pretty much like my current design idea, although I haven't yet tackled the multiple map issue in too much depth.
One idea I did have was building a QuadTree of Maps, so they could be subdivided or extended pretty much arbitrarily. This solves a lot of the problems of having to worry about a fixed size of map, and means that you can transfer a localized map area just by picking the right branch or two of the quadtree.
I'm currently thinking of building all objects from a single "Thing" base class, which will handle a fair amount of the common networking functionality, e.g. having a unique id which can be referenced identically on the client and the server.
Yep, I've had a good read of this a couple of times - very impressive architecture.
:-)
Since I'm focussing on strategy rather than action, some of it isn't applicable, e.g. the client side simulation etc. isn't really needed. Which is lucky, because I don't think I could code something to match the Unreal Network engine in a hurry
One thing I would *really* like to duplicate is the way that networking happens "behind the scenes" in UnrealScript. Ideally you should be able to code the bulk of your game logic without worrying too much about the networking platform underneath.
Not sure how easy this is to do in a langauage like C#. Ideally you would have objects which, when modified, would know to propagate their changes correctly. But this would appear to require writing networking code in *every* function that manipulates object state, which is hardly transparent.
Maybe you actually need the extra level of abstraction that scripting gives you in order to make this work.... unless anyone has a better idea?
Problem with all non-gc langauages is that they *really* suck at serialization/persistence because you basically have to roll your own code for every type of object you deal with. C can't traverse an object graph automatically because it has no idea where you have put your pointers.
Which is a right PITA for a network game..... not that it's impossible, but it's highly bug prone and very time consuming to update as you build your engine. And isn't laziness one of the three virtues of a great programmer?
C has it's good points, network programming unfortunately isn't one of them.
Thanks for the advice :-) I still reckon I'm OK to hit out with C# because it's basically a tweaked clone of Java, and my skills transfer pretty well. The main trouble I have is looking up the different names for the same functions in the Java libraries... and remembering that C# capitalizes method names etc.
Masively Multiplayer is an ambition, but I'm not sure whether I'll get there on the first iteration. I'll probably focus on getting the single player/team games/"deathmatch" games working well and then look at how well things could scale up.
I think there are three real challenges to going MM.
The first is that I would have to switch to the more complex but better scaling data structures, e.g. OctTrees and QuadTrees rather than Arrays. This would be neccessary to make sure that you can partition the server effectively and focus on localised changes.
The second is the persistence element, which is clearly a bigger issue when you have many players and a long-running game. I'm trying to design a "transaction log" into the game engine so that the server can automatically regenerate from the last known position, but this might not be enough if you have a horde of fans hammering your servers (I wish...:-)
The third, and certainly the hardest, is finding how to build your game design around the additional challenges that MM brings. That's the real test I guess - Is the concept right, and does the gameplay have what it takes to keep people coming back in a MM context?
Good distinction to make.
I think it has to be push in this case - major/relevant events could be occuring at pretty much any time and when they do you would want to broadcast it to the client as soon as possible.
Pull could work, but I suspect it would just eat a *lot* of bandwidth polling the server all the time for events, and I don't see what it would buy you - you still have to transmit the event anyway. Guess it could be *slightly* simpler to code.
How badly can TCP get stuck? Enough to take a client out of the game?
Just curious, I was thinking it made sense for the kind of updates that absolutely have to get there. The other option would be to keep broadcasting on UDP until you get an confirmation/acknowledgement, but wouldn't that just be re-inventing the TCP wheel?
Nope. I decided to pick up another language for my repertiore, and C# is actually quite fun to program.
:-)
Of course, I still had a certain amount of morbid curiousity to see what wouold happen if I mentioned it on Slashdot.....
I was actually playing with C# recently trying to get DirectX to work and had some success. MS hasn't published the DirectX libraries for C# yet AFAIK, so I wrote some simple wrappers in C++ and linked them into C#. Not exactly elegant, but it worked and it was fast.....
You're right that C# probably isn't appropriate for the hardcore inner loops in a game. But I reckons it's broadly fast enough for most "management" jobs. I guess that I will take the approach of using C# generally and dropping into C++ when I really need the speed. Since this is very much a strategy game, I'm hoping that I won't need to do this too much.
Any open source gaming engines you think I should particularly check out BTW?
You raise some very good points - I actually hadn't really given that much thought to using a separate language for the server. Reason is that there is a certain advantage in using the same language for client and server in that you can get some *serious* code re-use.
I think the biggest issue is development speed. You only have to write all the object representations once, and you avoid all the bugs that could occur when you update the server but not the client and vice-versa. Less of an issue for a big commercial house, definitely an issue for a "Lone Wolf" coder like myself who needs to stay sane and motivated.
You can also use server code in the client to handle updates. My first draft at a networking protocol made heavy use of this - updates to the game are propagated where necessary and applied to both the client and server states of the world to guarantee synchronicity. The client and server representations of the game state are the same class, and it would be a real pain to develop two versions in two languages simultaneously.
You can even make the client and server the same program, to enable P2P style operation. Haven't thought it fully through yet, but If you had a muli-side battle with multiple players per side (lets say 50 players total?) it might make sense for some of the clients to become "servers" for their own side, taking the load off the master server.
Then there's always a whacky AI idea that I am planning to test out - Clone() the entire game state and let the AI try a genetic algorithm on possible command combinations. This could solve the classic "lack of collective intelligence" problem a lot of strategy game AIs tend to have. Admittedley you would probably want to do this on the server, but it seems like there could be a potential to offload some of this work to clients, e.g. letting a client process the moves for an "allied" AI so they would make no gain from trying to throw a spanner in the works.
Hey, it's a challenge - but I always think that's a good reason to do things.
It's not exactly like I'm inexperienced either - been coding for around fifteen years and I built a pretty impressive game previously in Java so the leap to C# isn't actually all that great.
My evaluation of C# is that while Microsoft are certainly going to layer on a great deal more advanced functionality and libraries, the core platform is pretty much there. Apart from the introduction of generics, I don't think they are going to do anything else significant that could require any re-engineering. The worst I'm expecting is a couple of naming tweaks.
I've actually found J2EE a little clunky for my tastes. Performance isn't good enough for a game server if you use Container Managed Persistance, and if you opt for Bean Managed Persitence you're effectively re-inventing the wheel anyway. Haven't really used the messaging beans though - I'll take a look into them to see if they would be useful/applicable.
Sounds interesting - didn't realise there was academic research into cheat-proofing! Might have to look at getting some grants to fund my endeavours :-)
I think that having the authoritative server with visible set event propagation solves *most* of the cheating problems.
As for the "time cheats" I have been less concerned because I have been trying to think of a way to actually make this a part of the game. I actually think that it's somewhat representative to strategy in the real world, where you wait for an opponent to commit themselves and then pounce.......
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.....
Interesting idea - how do you define "object blocks"? I guess you have to find some kind of tree structure in your data to make this work.
I like the idea of the checksum to test for changes especially, sounds pretty efficient.
Well, I'm actually betting that either of both of Mono and dotGNU will succeed in making a decent C#/.NET clone that will be truly portable.
.NET framework is very similar to Java in many ways, which has proved eminently portable in the past.
My assesment of this is that it's certainly possible - the
That's an interesting idea - I had thought about using multiple servers, but I had planned to only use them for P2P metadata sharing. This would allow discovery of game servers etc.
Guess the tree of servers would work best since I think it's necessary to keep a single authorative master, with multiple clients connecting to sub-servers.
This actually would solve one of my scalability concerns - number of client connections to a single server. This could become a problem because of the (relatively) large amount of processing required to work out the relevant set of objects for event propagation.
Well, I am a programmer who's made a reasonable amount of money from my software and I *still* think there is an important distiction between anauthorized copying and theft. Theft is the unlawful taking of property with the intent to deprive the rightful owner of it.
The loss suffered here is a financial one. But a software author has only suffered a loss if both of the following are true:
a) The person making and using the unauthorized copying would have bought the software otherwise. This usually isn't the case. People who have both the willingness and ability to pay will generally pay up.
b) The financial loss, if any, isn't offset by the advantages of publicity, getting people involved and skilled with your tool and developing your marketplace. Even students get jobs someday, and when they choose your software for their company you'll be glad you let them have it for free five years ago.
Of course, the *moral* argument regarding whether you should be allowed to make an unauthorized copy is entirely separate. The author could suffer no loss but copying could still be immoral, depending on your viewpoint. But that's a violation of someone's moral code, and specifically *not* theft.
Hmmm.... since using sqrt(i) chances the algorithm from O(n) to O(n^0.5) I'd say the speedup was a lot better than 50% in all but trivial cases.
Minor nitpick I know - but these things can make a real difference. I once saw some code-monkey write an O(n^4) sort algorithm..... writing code that bad actually takes some talent.
Hey, calm down. Was just playing the Devil's Advocate and all that. No need to go Ad Hominem on me.
The point was that illegal activities *can* be justified in a general sense. That may or may not apply in this particular case, and I wasn't making any particular judgment on that issue.
I was highlighting the fact that saying "illegal implies wrong" is a weak argument, and that you must take the wider context of the situation into account, and argue those issues rather than the legalities.
But that's a little - er - negative?
Why not use ++ and talk about it "strengthening the shared knowledge of humanity" or some mumbo-jumbo like that?
Breaking the law is never right? Are you serious?
What about the obligations to oppose an unjust law? Slavery, for instance. Or are you convinced that whatever the courts/politicians decide must automatically be "right"? Should the US therefore still be a colony of the UK?
I'm not saying that everything should be "free and up for grabs". Just that sometimes opposition to laws, particularly oppressive ones, is justified. And that may sometimes have to involve breaking them.
I think that having announcements like this on Slashdot is effective. If I may draw a programming analogy:
It's an event driven notification system. These work because they deliver relevant information at the relevant time, allowing you to focus otherwise on all the the other activities you are interested in.
Going to kernel.org and the other 50 or so sites that *might* have an interesting release that day is a polling system, and far less efficient since 90% of the time you are checking for something that hasn't happened.