Modding API for UI, AI, and everything else

I was reading a bit about scripting support for mods in an older thread, but most of the discussion there focused on language. I'd like to chat a bit about actual APIs, with a focus on security vs. convenience.

I'm a game programmer by trade, but I haven't done any script-based modding before, let alone designed a modding API. I used to play TA a lot with my friends, so I have some idea of what sorts of things I would want to be able to do. Please bear with me if I'm talking about problems that have been solved elsewhere. I'm just going to ramble a bit and hope that that kicks off discussion in a good direction.

I originally started thinking about this because of UI discussion, such as the ZK talk in this thread. I would really like to be able to write a custom UI for PA, with good support for abstract management concepts like sets of orders that don't necessarily have any units following them right now.

Without getting into the details of what I want to do (I only have some very vague ideas right now, and would need to prototype them before seriously discussing them), what sort of security model would allow a split between mechanic-changing mods and non-mechanic-changing ones?

I'm thinking right now of unit mods vs. UI mods. It seems to me that there should be a subset of the modding API which is inherently non-interfering with other people's mods. We might call it a "non-cheating" API, since presumably this would be the same API that you would use to make a non-cheating AI. Perhaps something like User or Player API makes sense, though.

Ideally you'd be able to have as many UI mods as you want, and they could all be different from other players' UI mods. Every player should be able to see the UI mods that others are using, and easily add them if they want to.

Then there's the matter of how powerful the Player API (I think I like this name the best so far) should be. I've seen what people do with WoW's modding API, and there are a lot of incredible wholesale replacements of the built-in one which somehow don't amount to cheating. However, WoW must have some limitations in place to prevent people using the API to make bots. Is it just that nothing can execute over time? Would it be a good idea to have the same limitations in the Player API, so that people aren't running bots in regular games? In that case, I guess you'd want at least three distinct API sections:

• 1. Player, which is just direct access to all the actions and information available to a real player
  2. Execution-over-time, and maybe event-listening
  3. Everything else

Then a UI mod would use just the first API. A non-cheating AI would use the first two, and a cheating AI would require all three. The separation of API 2 from 3 wouldn't be so much for player/cheating security, as it would be for helping modders restrict themselves to non-cheating AIs if they wanted.

I'll stop here. I'm really curious to hear what people think and know about this subject.

I think the way they did it in SupCom was pretty much spot on, with a solid distinction between UI and Sim mods. However, I would like it if they added a way of issuing orders to your own units from the UI and obtain information about units you've spotted.

I'd like to see this happen as well.

So my naïveté is exposed right away: I had assumed that any UI API worth anything would allow you to access all information available to the player, and issue all commands available to the player. Do you think this is a security concern (to prevent cheating and player-assisting AIs), or just was it omitted for other reasons?

Well that brings up an interesting question. In any sort of ranked game, or really any game where you care about cheating, does any UI modification count as cheating?

Take a look at the UI differences from Supreme Commander 1 and Forged Alliance. In SC you have a much smaller view window and it's just harder to find stuff in the menus. In FA you have a larger view window with some buttons on top of it, also the menus are a bit more intuitive, easier to get to, and I think the buttons are a bit bigger too.

In a match between two players, one with the SC interface and one with FA's, the person with the FA UI will have an easier time playing.

It really depends on the mod, because even a Player API-only mod could be considered an unfair advantage or a hindrance, depending on the mod and the individual user's preferences.

I would imagine ranked games would have a set of required mods (presumably all mechanic-changing ones), and optional mods (UI mods whose use comes down to player preference). For that matter, any multiplayer game should be able to enforce such restrictions.

Even games with no mod restrictions should still list each player's mods, and provide easy access to them for other players.

I assume this too and it is how the UI modding is implemented in Spring.

I hope PA's asynchronous model does not remove this possibility. As in the server may only send what the player can see but their UI should be able to affect anything they control.

By that, you mean "I trivially wrote a map hack that exposed all information from the Sim to the player whether he should have it or not.". Not very solid at all.

Was that with local UI mods? Security is really important because people have to be able to trust that custom extended UIs are not able to cheat like this.

Security was a problem because the accessible sim state held all the game data.

We've been told that the server-client has the potential to keep unknown data away from the client.

In fact it's a direct design goal because we are paying attention to cheat security from the beginning.

Of course due to the nature of the beast we can't eliminate every possible cheat.

For debug type commands we can have those turned off on the server so that people can't abuse the API.

What are your thoughts about splitting up the API to maximize flexibility without compromising security? In addition to game-changing mods, do you envision explicitly supporting (for instance) a total conversion UI that does not provide the player with more information or low-level commands, but simply presents them in a different way?

That is exactly what they tried to do in SupCom/FA. They will probably do something similar with PA.