This is an abstraction error. In this example, the server doesn't need to know specifics because its given the specifics from the translation layer. But how does the translation layer know what they are?
Lets back up a step. Imagine you're running the CoH client and you walk into a mission door. That mission spawns a three critter spawn at a location thirty feet in front of you. How does it know to do that? There is no such information in the client files anywhere. That information was in the server. When you make the server, where does that information come from? If you are recreating actual CoH missions, it ultimately comes from sources derived from the game itself; either someone documented that fact somewhere at some point in time, or someone has that data that was originally in the servers. Either way, that's copyright material: the design on the mission.
Yes and no. Really all you need for a mission is an array of xyz coords, and the ids of the mobs. Maybe some custom triggers on some maps. I'd imagine some sort of tool for either creating this or importing it from somewhere would be needed. As that data is serverside, it's likely lost. But on the other hand, it gives you the ability to procedurally generate maps with random mob placements, etc. It's implied all this data would be stored on the server.
But let's say we throw the mission content away. Lets say we're running all new missions created by someone else. But we still want to use CoH critters. The mapserver has to spawn, say, three freak minions at that spot, because that's what the original, new mission data says to do. The client doesn't know how to do that. The client only knows how to spawn three entities that visually use freak minion graphical models. They will *look* like freak minions, but strictly speaking they are just puppets. The server knows about things like hit points and endurance and attributes and buff debuff stacks and powers. The client's *files* have that information, but the client itself is completely ignorant of them. So when the server spawns those three minions in its own data structures, how will it know what those critters hit points are, what their smashing resistances are, what powers are running on them? It has to know, because its the thing that actually does the work of making things happen.
Moving the map file critter placements to the server would be necessary here, likely in some other format as detailed above. The client doesn't need to know really what's on the map. It should be told by the server. In fact, if you could patch in critter placements into the maps based on the server's data, that would be ideal. Again, I have no idea what limitations the engine had.
The meta data on the mobs can either be hard coded in (on the server). I think I hinted at that in the post. I.E. mob 321 has 1223 hp, gives 231 xp, has 534 end, and has power abilities 2,3,4,5, and uses critter ai 2 (in some xml/json file somewhere). That or passed in from the translation service in a generic form. The latter isn't optimal as it opens gateways of cheating. Farming mobs of 1hp 99999 xp bosses, anyone?
The role of the server in this case is just to take the generic form of a mob by id, mathematically having the bare meta data necessary for mapserver information, and to relay this back to the translation layers which presents this along with other local data in a format we know and love.
The only way I can see this working is if the "translation layers" are really full-fledged mapservers in their own right, capable of doing everything mapservers used to do. Then, the only thing you'd need to pass around, in theory, are controls and synchronization data. When a player does something on his or her client, that action information itself is sent to all other "translation layers" and executed in the same way using nothing but local data. But while this might arguably dodge copyright issues, it does so at the expense of invoking hypothetical technology that to the best of my knowledge doesn't exist. City of Heroes itself just didn't work in a way that would make this easy to do, as Codewalker has discovered in trying to make Paragon Chat. In effect, your idea could be paraphrased into something like "make Paragon Chat local servers into full map servers, invent distributed synchronization technology, and presume no one ever tries to cheat the system."
The translation layers aren't responsible for battle logic. If you incorporate that into those layers, they could possibly be different for each and every player, which leads to sync issues, and all kinds of terrible things.
The critical gloss-over is the "and synchronization data" part. Its what I call a non-trivial problem to make that work given the way City of Heroes works. City relied on a lot of things happening in very specific ways, within very specific latency windows, and presumed central synchronization. There's no obvious way to simply synchronize a bunch of individual map servers to work in a reasonable manner that I'm aware of. I've thought about what such a game architecture would require, and I don't think City was compatible with those requirements.
In no way did I mean to imply any of this is trivial or easy to implement. We're taking an already hard piece of code and making it harder by abstracting out copyrighted and trademarked items. Performance goals, and other things associated with this would be major roadblocks. I recall CoH always having a 200ms+ latency even on cable internet. I wondered why for years, but assumed it was sync latencies, processing times, etc.
The reason why we normally presume central servers for combat is that if you really want to replicate how City used to work, its extremely difficult to do that without a central server arbitrating everything. Its *possible* to envision distributed combat, and in fact I've directly speculated about that very thing in connection with Paragon Chat, but only in the sense of returning a shallow substitute for machinima or role play purposes. Without a central arbiter of action, some copyright problems are lessened and the expense of having to invent technology that I don't think even exists in the form needed in this context. You'd create a more difficult problem for yourself than literally recreating the City servers from scratch. You'd be building something radically more advanced than that.
A central server (or group of them!) really should be responsible for its map instance, or predefined section of one. I don't know exactly which all pieces were on the client, server, or where so it's hard to give you precise details, but it should be possible. I mean what do you really need to implement combat logic? Timing (syncs.. thinking of hami raid where it had to slow down to calc everything), meta data (current hp, buffs, debuffs) , hard coded data (max hp, xp rewards, critter type, powers), critter ai, combat functions (power-damage calculation), location information (range information, movement updates) , and finally the local presentation layer of current data.
When you think of the data involved in this, most of it is pure numbers. Only the final portion contains copyrighted pieces. As we don't have the server side files to begin with, most of what would have to happen to implement this would be basically creating it from scratch. I mean at this level you could plausibly turn CoH into a fast paced MUD. That might be a stretch but I hope you get what I mean.
IMO the best way to play with this would be in paragon chat with the AE missions. They're small enough that it would make implementing anything there with custom mobs pretty much guaranteed not to infringe on copyrights. It wouldn't shock me if CW was already doing this, actually. If I didn't have a 9-6 job I would be all over this.
Edit: I will admit one thing I don't have an answer for. In order to create mob placements you need to be able to parse maps. Specifically boundaries which are accessible. The maps are copyrighted, I'd imagine. Parsing those serverside would probably be infringement. The only thing I can think of is extracting bounds information from map files and leaving them hard coded in a xml file. There probably is a better solution for this. I just don't have it.
