The basic setup for the game is similar to an RTS. A player will control multiple troops and by clicking a location and telling the troops to move there, they do so. While moving, they may perform various actions like shooting or something. How they get to that point and what they do during that time is up to the individual troop to decide. I'm planning on using some basic AI to achieve that feature, which is where my question comes in.
Would it be better to give the server the message to move the troops and have AI actions run on the server (they are likely to be shooting at targets as they move too) or do those calculations on the the client and send the server each troops action as a message.
At this point I am leaning towards having the server do the AI work, but would like some other peoples opinions as a sanity check. I've had no experience with large scale servers and have no idea how each of the methods would scale.
Scalability might be a concern there. It would definitely simplify things to offload all that to the server, but you'd end up with essentially a dumb client then. In networked game development one of the extremely difficult things to do is find the right place to run what code. One one hand you would prefer to have the client do as much as is possible to keep from making the server do all the work, but at the same time the only trust-worthy participant is the server, so security becomes an issue when you are depending on any calculations from a client.
I'm assuming you are talking about the AI that actually is doing the attacking and such for that client's player's unit whilst it is moving, correct? In that case I would lean towards providing the AI on the client, and send information down to the server for the actions it is trying to take. Yes, that significantly complicates things, but you run the risk otherwise of making the server overload with too much work. If you're not concerned about the work then by all means go with the server.
Yes, the AI would actually be doing the attacking and pathfinding and a client is pretty much just a user interface and graphics rendering system. And your response is pretty much the main worry I had.
Having each AI run on the client does complicate things a bit, but my concern was with network load and cheating. Each client would have to send an update for each troop. I guess I'll need to set up some network prototypes earlier than I had planned.
In order to keep the update rate reasonable, I'll have to have some sort of short term predictive behavior on the client, but I was planning on having the "official" server AI be somewhat more complicated than the clients'.
If I kept the total number of troops a player controls to a low number (less than ten) do you think it would still be too much of a server load?
How many players are we talking about?
Well, it really wouldn't be too bad as you could do more of a state-change message from the client to the server to say:
"Moving to x,y"
"Stopping and firing at enemy v"
"Resumed movement"
Check out these
http://www.gamasutra.com/features/19990129/implementing_01.htm
http://www.gamasutra.com/features/20010322/terrano_01.htm
the server needs to maintain positions. If the client is clever it can use a predictive movement. The player will adapt to any short corrections ( less half a second )
Absolutely the server needs to maintain positions…no system I've ever written doesn't. :) However, there's a big difference between maintaining positions and simple validations (to keep cheating from occurring) and full AI processing on the server. The work needs to be offloaded when possible to the client and the client, when possible needs to be synchronizing down to the server instead of vice-versa to keep the quality of the game flow high. The server can be choppy…we don't care about its appearance, but the client should be smooth. The most important objects that need to be smooth for a client is the ones they control. Second comes the ones the client is interacting with (enemies or allies), but this falls a little bit shorter off because they can still be slightly out-of-sync and it's not that big of a deal to the user. Sending information from server to client for locations of a player's associated objects seems to me to be a bad idea as a general rule.
However, take what I say with a grain of salt. I may have a lot of ideas and theories, but I probably know a lot less about practical network development than a lot of others here. However, I rely on my instincts when coding and that generally serves me well. 
darkfrog said:
How many players are we talking about?
As many players as I can manage.
http://www.gamasutra.com/features/19990129/implementing_01.htm
http://www.gamasutra.com/features/20010322/terrano_01.htm
the server needs to maintain positions. If the client is clever it can use a predictive movement. The player will adapt to any short corrections ( less half a second )
I'll take a look through those links, I think I've seen the second one before. I was planning on making some formation movement setups, so the first one will be pretty useful, thanks.
darkfrog said:
Absolutely the server needs to maintain positions...no system I've ever written doesn't. :) However, there's a big difference between maintaining positions and simple validations (to keep cheating from occurring) and full AI processing on the server. The work needs to be offloaded when possible to the client and the client, when possible needs to be synchronizing down to the server instead of vice-versa to keep the quality of the game flow high. The server can be choppy...we don't care about its appearance, but the client should be smooth. The most important objects that need to be smooth for a client is the ones they control. Second comes the ones the client is interacting with (enemies or allies), but this falls a little bit shorter off because they can still be slightly out-of-sync and it's not that big of a deal to the user. Sending information from server to client for locations of a player's associated objects seems to me to be a bad idea as a general rule.
So, the server would have no AI on it at all. Action Messages for every AI troop you own would need to be sent to the server, those messages would then validated. Based on the validation, a correction is sent back and a command is ignored, or the troop message is passed on. Basically each AI troop would be treated like a single player in a typical FPS network setup. I'll just have to make sure each AI has server messages delivered to it. That seems like a fairly elegant solution actually, thanks darkfrog
Let me know if you run into any other problems. Feel free to stop by the JGN forum as well.
Ah, I meant to ask you about that as well. Your forum wants me to have an activation code, but it hasn't sent me the activation email. I've tried having it resend a couple times and no luck.
Strange…well, let me know your username and I'll manually activate you.
username is thaspius
Account is activated.
thanks darkfrog (seems to be a pattern)
Since the AI is for troops controlled by the player, I don't see any reason you wouldn't keep the AI code on the client end. The only thing the player could really do to cheat (assuming you have a sanity check for map positions on server side) would be to write a better AI than you, and that isn't really a bad thing. If I were designing it I might even consider giving users the ability to create different AI personalities to plug into their troops. (beware - large scope creep possible with that suggestion :P )
I believe the consideration was simplicity in design. If AI is done entirely on the server then the server only needs to validate cheats on commands issued whereas if the AI is being done from the client the validation gets more complicated if a cracked client violates rules of what the troops are allowed to do (ex. fire and walk for a unit that must stand still when firing?).
darkfrog is spot on. Having a dumb client just makes life easy, except for speed. Unfortunately there are going to be other ways to cheat besides position and they will all need to be checked. The more complicated the set of allowable actions are, the more robust my validation routine has to be. When actions start becoming interdependent, strange exploits can crop up.
here is the basic overview of the network architecture
Even in terms of simplicity I think it would be a better choice to put it on the client end. It seems like you're going to double/triple your resource usage if you try to stick the AI on the server - especially if (as your diagram seems to indicate) you plan to make each AI a separate unit.
Really the only extra complexity difference is the extra validation code, which for steps in order would only require a flag indicating state, and changing to a new state would require you to check that. You'd probably want a flag for action in progress as well, to prevent the running/shooting at the same time type of situations where actions are mutually exclusive.
If you do put the AI on the server it seems like you'd have to make each thread handle all the AI for that particular logged on account. So basically you'd have an array of AI state objects, and the player thread that loops through them and executes actions/changes to new states depending on given logic.
If MessageManager is a facade around comms, i would add an extra layer inbetween the AI. Purpose would be to marshall all AI requests ( possibly lump the, up into one ). The MessageManager would then just be passed an AIUpdate Message. This would also adapt to collating AI moves every x milllisecs to bulk publish AI moves
theprism said:
If MessageManager is a facade around comms, i would add an extra layer inbetween the AI. Purpose would be to marshall all AI requests ( possibly lump the, up into one ). The MessageManager would then just be passed an AIUpdate Message. This would also adapt to collating AI moves every x milllisecs to bulk publish AI moves
That would work, I was planning on just letting the AI send message as they perform an action.
What specific advantages would your method have?