What is cheating?

I consider bugs fair game unless in the beginning of the match you explicitly ban their use, similar to other bans.

I put bugs in the same boat as unbalanced units. If it's bad enough, ban it. If not, deal with it. Units are not made to be intentionally better than one another, but sometimes they end up being so.

I just agree, really, on anything being "arbitrary" to the whole. Whatever everyone agrees, usually goes. This may remove things in the game, this may add things that weren't in the game already.

Some competitions would agree to allow some mods, citing that the "competition" isn't about being able to click left and right and still build a base (so it allows an automatic mod that clicks your bots left and right for you while you don't need to even watch) (god I hope that isn't a game feature, letting bots left-right-click to avoid shots), or even require them if they are specific unofficial yet widely agreed upon balance patches (TA tournaments probably don't use vanilla balance, they probably use the latest unofficial patch).

Some competitions would agree to disallow certain things (like walls right now would not be allowed as someone could build a field of them rather quick and just use air and turrets and completely negate half the game) (like intentionally using some commands to get access to player confident information, or using some bug that does it)

Some competitions would disallow some mods, mainly the ones that let you see enemy information you shouldn't have, possibly ones that let you automate depending on if that competition "merits the clicking speed as a form of in-game skill".

I would not personally validate or credit any competition that rewards the measure of one's ability to click quickly. By which I do infact mean I do not validate all of Starcraft's higher level play and only validate casual play of it done where one just slowly builds and attacks with things instead of doing both at blinding speeds while assisting units with clicking and junk.

That is just me. Some competitions might merit that.

This came up today during a discussion during Garat's playtest stream. I asked him if they would be adding engine calls that allow units to be given orders without the need to be selected. He said they definitely plan to give us a better api, but they haven't worked out exactly what that will be yet. Uber is aware of the benefits to that kind of engine hook, but they are also worried about the possibility for cheating.

In order for modders to add in more than the most basic automation, we really need a better api. This could allow for everything from an improved auto-factory mod to entire AIs written completely on the client side. Is it cheating to use automation helpers in the client? How far can you go with automation before it does become cheating? Even if there is a possibility for cheating, are the potential benefits we could see from mods worth the risk?

I think this is a good opportunity for the community to help come up with a solid definition of cheating so that the developers know exactly how much more api access to give to the client.

Hmmm, cover a moon completely in walls so enemies can't land or build teleporters...

I'm just gonna chime in to vote that Uber gives us 3 options regarding mods when connecting to a game on the server:

1. no mods allowed. do your own *@#&)( work.
2. any mods allowed (no checking or validation of system files at all). good luck.
3. players must have matching mods

Interplanetary nukes or kinetic bombardment weapons. hmm?..

Interesting idea. I would replace "mods" with "unit control API access" though. That way you can still have all your basic UI mods on any of the modes but the advanced control and unit access can only be done in modes 2 or 3. (A UI mod would be anything doable with the js access we have in the current setup. Look at the mods on PAMM for examples.)

Automization helpers and all these kind of things are cheating for me... absolutely... otherwise you just let AIs play the game, you lean back and watch the battle.

Automization helpers in an RTS is kind of the same for me like Aimbots in FPS.

These things should not work with official server/games...

In regards to automation and UI I want to see how deep the rabbit hole goes. If you script a complex AI that plays the game for you I'll gladly take on the challenge to beat it.
The only problem I see with higher levels of automation is that it increases the learning curve as players have to study the AI, customize their UI and chose which scripts they use before they can actually start making useful decisions instead of the AI.
Any other problem is a matter of game logic and game balance.

I want to second this. There is no reliable way for the server to detect mods and reject a player, but the server could be configured to disable the automation api as an option before the game. Automation mods would just have to know how to turn themselves off if automation is disabled, so that they don't break the client.

This solution let's us have all the tools we need to make the game awesome and to experiment with new ideas while keeping the game fair for competitive play.

Although it would be better to make it two options only: Automation API on, and Automation API off.
That way the player base isn't split amongst so many different "games". And I completely agree, mods that use the API should be able to seamlessly switch between modes so you can play both ways with the click of one button.

Great! We solved it! This is secure, because the server controls that API access. It is easy for modders, because mods can just do a simple check to see if the automation API is available. And it is easy for users, because all they would see is a "Disable automation mods" check box in the lobby.

If Uber really doesn't want to add it as a lobby option, we at the very least need it in a server json. This game engine has so much potential for automation and client-side AI helpers, and it would be very disappointing if we never get the chance to experiment.

What happens if a tournament requires X, Y, and Z mods or a server instance only allows A, B, and C mods?

If Uber did it this way it would be all or nothing for vanilia games but modded servers could check mods for tournaments. This makes it simple for everyone and doesn't make the player go through the confusion of having their mods change each time they play.

Servers should never try to guess what mods the client is using. There is too much potential for that being faked anyway.

That's why it should be left up to modded servers. If you really needed it you could "register" your mod with the checker system and get an id. Any mods with that id would be allowed to have access to the API calls you registered for. It wouldn't be prefect but it would provide an option for those who want it.

I think that's still just an honor system though, because you could fake the id. It is generally better in that situation to not even try to lock it down, because what you end up with is the illusion of security without any actual security. Plus, that's one less feature for the devs.

True.

So here's the basic overview of the system that @cptconundrum and I made from @wheeledgoat 's idea:

Two game "modes" that are set using a toggle when creating a game:

1. Unit control API on
2. Unit control API off

This is set per game and controlled by the server. It makes switching easy (the mods would detect the game mode) and clears up the issue of "cheating" with mods.​

I understand where you guys are coming from but it doesn't allow for flexibility and assumes bad faith. I believe any proposed solution should be designed with flexibility and good faith in mind. Flexibility will allow for any configuration in the future. The assumption of bad faith is unsportsmanlike.

Here is my proposal. It is a whitelist and blacklist system where the server operator can choose to either blacklist specific mods or whitelist mods then any other mod is assumed to be blacklisted (will not be usable). All modules contain modinfo.json which must be present in order for the mod to run. This file contains the following attributes identifier, display_name, author, version and some more. Using the previous mentioned attributes in the blacklist/whitelist system to verify what mods are allowed and required all four attributes to be present in order to run whitelisted mods. There is a different way it can be done by hashing the individual mod directories and using that instead of the attributes. I know that it is more complex but it allows for flexibility. If somebody forgot a blacklisted mod is still enabled a notification would be sent kindly asking them to disable the mod(s) for the duration of the game or automatically disable all blacklisted mods (with user intervention and notification). The system would be tied to the UberNet credentials and then there would be a mechanism in order to prove bad faith.

Dam, now i want this! CoreWars of XXI century. And i have feeling that one of TA sides were named after it.

I cannot yet post links here, so you guys should google for this article:
"Skynet meets the Swarm: how the Berkeley Overmind won the 2010 StarCraft AI competition"

I kind of always dreamed about game that I could code AI for without hacking or dll inject etc.