How many AI...?

I hadn't thought about that. Good point.

I suspect that the bandwidth requirements won't be that high. MMOs use a client server model and they don't use that much bandwidth despite having to keep track of a large number of things going on around a player. They do need pretty beefy servers though.

Bandwidth is most closely related to the number of dynamic objects that are controlled by the server, for MMOs that's usually a handful of creatures and players (maybe 100 or so), but in PA there's likely to be thousands, so I expect PA will require a heck of a lot more bandwidth. I'm expecting PA clients will require roughly 1mbit downstream for 4 player games and maybe up to 4mbit for the 40+ player ones, and probably about 1-4mbit upstream per player for the server, but that's just a rough guess we'll have to wait for them to get some games running before we get any real idea of how much bandwidth will be needed.

But that's dumb. Just host it on the server. AI is threaded easily enough, as it does not require perfect information to make decisions. It merely needs to interact with the host like any other player, delivering orders and trying to win.

Maybe, but Eve Online often has many hundreds of players all shooting at each other at the same time in the same small area for a single fleet engagement. This works out to thousands of server controlled dynamic objects once you take each player's combat drones, missiles, and fighters into account.

Yet the bandwidth usage is never all that much. However it does often bring the CPU on the server to its knees.

What I didn't really mention was that MMOs also kind of cheat to cut down on bandwidth, they lock you into targets, states and cool-downs that basically minimize what is actually dynamic, for instance IIRC in Eve Online you select your target and start shooting but all that's all the sever and clients really need to know, once the client and server know you started shooting they can both independently assume you are continuing to shoot until you stop, it doesn't need to send any data between the server and client for projectiles and other smaller details because the client's simulation will be so similar to the server as to not matter. That's kind of what I meant by "dynamic objects that are controlled by the server" there can be heaps of dynamic objects on the client but many are not controlled by the server and only approximate what is actually going on. The only stuff that really needs to be sent is the states of things and the states of things in MMOs only need to change vary rarely (basically only when you click a button or you/your target dies which when I last played took ages), but in an RTS the state changes can happen more frequently because units might only need to last a second or two for them to be fun whereas in an MMO the equivalent of unit is a player and a player needs to survive a lot longer for the game to be fun so there are a lot fewer deaths per second causing state changes.

Also (and more importantly) I'm probably way overestimating the bandwidth needed for a human player anyway , I'm sure Uber have a lot more experience with network code than I do and know some neat tricks to keep the bandwidth down .

I think you are correct. A RTS will need to update more stuff than an MMO. I hope you are correct in your second assumption as well and I think you probably are. It just doesn't take much data to tell a client "draw model number 5657 at location 34,754,234 on the grid".

It's a lot more than you'd think though, at 60fps, 3 floats for position, an integer for the model index, and usually 2-4+ floats for orientation you'd be looking at using at least 1.4 kilobytes per second per unit and would easily be well over my bandwidth estimations with just 100 units .

Fortunately that's not the sort of thing that would be sent over the network, for an RTS the server would typically send a spline or path for the unit when a move command is issued, which can be as little as 20-50 bytes per unit, and the client figures out all the rendering details for the unit by interpolating along the spline/path each frame instead saving a lot of bandwidth. And with flow fields you could potentially send the inputs to create the flow field (typically a single position, 12 bytes), and a list of units (~4 bytes per unit) and create the flow field locally and get that list of units to follow it saving a hell of a lot more bandwidth at the expense of increased workload for the client and higher degree of discrepancy between the server and client, both of which would probably be OK for something like PA. To put it into perspective you can move 357 units this way for the entire time it takes to follow the flow field using the same amount of network data (less data if you factor in packet overheads) than what you suggested would only render 1 unit for a second .

And it's possible that Uber can come up with even more efficient uses of bandwidth than that (pre-grouping units or sending selection information instead of a unit list) so yeah it's probably a safe bet that I was over-estimating, but you just never know what needs to be sent between client and server without actually working on it so I figured better to over-estimate than under so as to avoid people getting their hopes up too high and ending up disappointed .

I'm not sure I follow; per-unit pathing is done on the server, regardless of who is "controlling" that player. If I click on an engineer and say "go build a mass extractor on that mass point" the pathing is done by the engine, not me. The only units which require a little player forethought are the non-amphibious ground units, as they cannot cross deep water (I'm choosing to assume water depth will be similar to TA / SupCom with a shallow and deep distinction). Air units don't care at all, and amphibious ground units only care about plateaus with no access ramp.

A simple "unit cannot complete that request" response is all that is needed for an AI to reassign that order to a different unit type, and if you attach a noise to that response it also informs human players of their mistake as well.

I definitely agree that a player-replacement AI (which I'm choosing to define as one which works off the same information set that a human player would get, and no more) is more work than one which runs off a full gamestate. I would completely understand if Uber (read: Sorian) decides that a gamestate AI is the best option to get PA done in the most timely and cost-effective manner. They'd have to run all AIs on the server, but if it means PA gets made with extra features and more shiny because of it, I couldn't fault the logic

What I want is an AI that doesn't cheat (does not have access to more info than me), and acts purely as a player replacement. Such an AI could indeed be hosted purely on a client, sending commands to the server and receiving the same information back just like a human player (and therefore needing the same bandwidth, of course, and placing the same load on a server that an extra human player would).

One annoyance with gamestate AIs that I have had since their inception, is that it can (and does) work off more information than a human player gets presented with, with better reaction times than a human player, and therefore has to be artificially limited in what it actually reacts to. I know why they have always been run like that (it's the most efficient way to write them), but much like square maps and circular LoS, I'm hoping we're reaching a point where the computing grunt is available to re-assess the way they work, and provide some truly game-changing (lol) options. :mrgreen:

Technically you can probably run AI client side but it's a lot more challenging as a lot of the data structures inside the sim which are useful to AI don't exist on the client.

The topic was on running an AI player (so an AI running its own faction) on the client to save cycles on the server. The problem is that you cannot operate an actual AI without pathfinding on the same machine, because the AI will not know what orders to give units.

If the player is giving the orders, this is not an issue because the player can interpret the visual map instead, but an AI on your local machine would not have any kind of awareness of the battlefield without that pathfinding information.

Even with full player gamestate, the AI doesn't have enough knowledge to give orders, because the player gamestate only includes a visual map of the terrain and the units on it, but that's useless to an AI which cannot read visual maps.

I think they already said in a video Question answer session that AI won't cheat. Imo it is not that hard to achieve that feeling. You can limit actions (output) per minute, and also input per minute - e.g. the AI sees that one of its generators got destroyed - that is one input. At almost the same time a larger enemy force is in rage of its scanners. There could be a delay between processing/reacting between both events with a delay between input and action as well. And just because the server knows all your unit movements and ressources doesnt mean the AI is forced to use everything of that in its decision making. Server and AI are not the same thing

Kinda offtopic, but i hope the AI will base its army on the planets biomes setting /planet types. There is little use for a large army of non-amphibic ground units on a planet that consists of a couple of small isles and the rest water, alot of ground units that can't traverse mountains on a planet that mainly consists of canyons, or alot of surface navy if most of the planets water is covered with ice (i hope sub-surface navy can pass under the ice, that would be awesome. Oh and sub-surface buildings in water *keeps on dreaming* )

Absolutely true, which is why most (all?) games use an AI that has direct access to the gamestate. I also only have basic coding knowledge and no idea how you're implementing the server engine, or indeed the client rendering engine (which will in theory have info relevant to an AI, just not provided in a very friendly way). I'm just wishful thinking, really.

Although if the client (unit?) scripting engine ends up anywhere near as complicated as has been hinted at, I'd be up for trying to pre-script my entire game as a pseudo AI running client side. It'd be doomed to failure, but that's never stopped me before :lol:

You'd need to tie it into the rendering engine data instead of the server gamestate. As a human, all of the information I am presented with, as a client, is through the rendering engine, and this is expected to be perfectly adequate for me to perform all of my game related tasks. It already has a full map (including topography, whether it is actually visible from the start or not), locations of all units within my sight / radar ranges, and details of available banked resources / resource generation figures.

Writing an AI that can interpret that information is orders of magnitude harder (and more CPU intensive) than one which can just look at the gamestate, and from Neutrino's quote above is out of scope for the project, which is completely understandable. I don't, however, think it would be impossible. Just an expensive, time consuming, patience testing headache

And probably worthy of a nobel prize, or at the least a serious science grant An AI that can properly command an army based on nothing but basic coördinates would be an impressive feat I think. I've never heard of an AI able to interpret and order on a map without building a full path-finding system for that map first.

Agreed, that would be some seriously impressive coding. I'd also wager writing that alone would probably take several years, which I'm sure most of us would not appreciate since we are all hoping for a release some time late this year or more likely early next .

I am confident that the AI will be quite good even if its not as a good a human. Skirmish is a large part of TA style games after all.