WiseKind

This is the perfect opportunity for me to explain what I think this whole debate is really about. Yes, I absolutely think it's cringe if people built barracks in a line and used a macro to cause units to rapidly garrison-slide down them. But here's a quote from the 0 A.D. Vision: The concept of someone building rows of structures to abuse the garrison mechanics definitely fits the description of a "sneaky trick". The solution, therefore, is not to simply prevent players from exploting this game mechanic via moderation, but by improving the mechanic itself so that it cannot be abused in this way. The simplest way to do this is to introduce a delay after units enter a structure before they are able to leave again, and this delay must be at least the same amount of time that it would take for an infantry unit to cross the diagonal length of that structure. Getting more complex, what if there were animations for units entering structures? Here's an excerpt from a different part of the 0 A.D. Vision: (no, I won't stop quoting the Vision) This isn't currently implemented in the current Alpha version, but it can be in the future. Perhaps, instead of a unit simply walking up to a structure and then disappearing into it (the current behavior), there is an actual animation where the unit must enter from a specific side of the structure (i.e. the front), and the unit can be seen walking up the stairs, and climbing to the top of the structure, and this introduces a delay before the unit is actually considered to be "inside" the structure, and able to fire projectiles from within it. Then, when you order the unit to unload, the unit can be seen climbing down, or walking down, and this takes a few seconds, before you are once again able to order the unit to move somewhere else. I think that introducing a delay for garrisoning/ungarrisoning units from structures, especially with an animation tied to it, could really add to the depth of the gameplay, both for people with mods like ProGUI, and those without. Maybe we could go even further, by allowing enemy soldiers that want to capture a fortress able to block the entrance, so that your own units must fight their way in, and if they wanted to defend from the inside, it's kind of too late to do that. All of a sudden, garrisoning inside of a fortress is no longer a reactive behavior; suddenly, it must become a proactive behavior. You must decide quickly whether or not to order units to get inside, or take on a different defense strategy. All in all, it would eliminate the cringe strategy of using houses as roads. The main point I am trying to make here is that the kinds of gameplay design changes that eliminate the "sneaky tricks" that players can do, whether or not they can automate it, are also the same gameplay design changes that make the gameplay better, deeper, and more fun in general. The point I am trying to make is that instead of arguing over what mods should be allowed, or whether or not the GUI itself constitutes part of the game and part of the challenge, we should instead try to design the game in a way to ensure that it remains fun regardless of how players choose to interact with it. We can design our game well enough that it no longer matters whether or not someone installed ProGUI; the more fleshed-out we make our game, the less effective these mods become at enabling one player to frustrate another, and eliminating these "sneaky tricks" is a large part of that. It may be true that we cannot completely eliminate the advantage given by being able to react quicker. However, I do believe it is our stated goal to minimize this advantage as much as we can: Suppose there is a game where two players of otherwise equal skill are pitted against one another, and both are using the vanilla GUI, and while one has spent several hours looking into the various hotkeys that are provided by the vanilla GUI, and re-assigned many of them, the other player has yet to surpass the essential modifier keys, and does most things by clicking with the mouse. What this excerpt from the Vision is essentially saying is that in an ideal world, these two players should still have equal chances of winning. It does make the game easier to control once you have familiarized yourself with the more advanced hotkeys, and developed the muscle memory to use them optimally, but this is different from actually being a better player. The person stuck with basic keybinds and a mouse can still win if they have a better strategy that allows them to train a large army faster. Having a stronger economy should take more than being able to click the fastest. Now extend this to the player with advanced hotkeys paired with a different player who has a mod with even more advanced hotkeys. My point is that these hotkeys probably will provide a small advantage, but we should try to minimize this advantage as much as possible by designing the game better, to the point that more and more rated match wins are decided by something other than one person being better with the keyboard than the other person. And as I said in the last point, the changes we need to make to this end, are the same changes that will make our game more fun in general. Honestly, I find it hard to formulate an actual "counterargument" to this. My claim is that the GUI and the game are two different things, and you are essentially saying they are not, but I don't see a 'why' anywhere. -Also from the Vision. I guess what I am trying to say here is that yes, maybe you can consider the GUI "part of the game" by some metric. My point is that the GUI should not present a challenge by itself; it should not be challenging to try to control the game. Most of the challenge should come from the strategic elements of the game, from deciding what to do next, and these elements are defined completely by the simulation code. If the challenge of the game comes from trying to control it, then the game becomes frustrating and people won't find it fun. If the challenge comes from the simulation code, then by definition, that means swapping out the GUI component won't suddenly enable you to play better. These mods add features that are mostly equivalent to being able to activate multiple hotkeys at once, and while that may be useful for making the game easier to control, you still have to think about what the best strategy is, with or without the mods. If the GUI itself presents a challenge, by getting in the way of the player using it, then of course the game would seem easier and more trivial if you swapped it out, but it also means the game itself isn't really fun. If we achieve our goal of designing a vanilla GUI that is not complicated to use, then that also means the harm done by independently changing some of its behavior is also minimized. Hopefully that's not too hard to understand. You are working with the assumption that the new network model would require sending data about every game entity, on every tick. This doesn't have to be true. Let's say that player 2 is sending three cavalry units to capture the output of player 1. In your model, from the moment the units enter the range of the outpost, the host computer must start sending the position, orientation, health, current action, etc. of those cavalry units at least 5 times per second, but that's not true. All the host really needs to do is wait until the moment the cavalry units enter range to send player 1 a single packet containing the information about the three units: their status, the position they entered from, and their current velocity. After player 1 receives that packet, it has enough information to infer the status of those cavalry units for each tick. If player 1's computer knows the velocity of the units, then it can assume that the cavalry units continue on their course, and reach the outpost at a certain time, at which point the host will send another packet stating that the calvary units have begun attempting to capture the outpost. That's two packets, total, compared to the dozens of packets that would be sent under your system. If player 2 orders their cavalry to turn back and garrison inside of a temple that is outside of player 1's vision range, then the host will send a single packet at that moment, stating that the cavalry units have all turned around and are now heading in a new direction. My point is that it isn't a choice between "lockstep" networking, and sending an entire 0 A.D. map over the wire up to 40 times per second. As I said in the original post, there is no cosmic rule which states that the way we currently do networking is the only way that it is possible to do so. There isn't even a theoretical limit to the number of different ways we could implement 0 A.D. multiplayer, and I think we should focus on a networking model that puts security first, by not sending information to a player that shouldn't be visible on that player's screen. One time, I set up multiplayer 0 A.D. with myself, by launching Pyrogenesis mutiple times and connecting over localhost. I noticed that in multiplayer, there was always a noticeable delay every time I gave a command to a unit, which isn't present in singleplayer. I have yet to understand much of the technical nature behind the game in general (I wish I did), but I infer that what is happening is that once I give a command, the client process has to wait to receive confirmation from the host process before the action is actually carried out, which always introduces a noticeable input lag. Correct me if I'm wrong. Like I said, there is a possibility that we could implement the network protocol differently. Perhaps, once the user gives a command to a unit, the client does some local checks to verify that it's a valid command, and then, locally, makes the unit on screen start moving, and at the same time, a packet is sent to the host stating that a command was given and the time that it was given. The server gives confirmation back, that the unit started following the command at a certain tick, and the client updates the simulation accordingly (maybe there was a 1-tick difference due to lag; these are the microcorrections that I mentioned briefly at the top) Meanwhile, in the case that the unit that moved was visible on a different player's screen, that player recieves a packet stating that the unit changed orientation and is now moving in a different direction, and includes the exact simulation tick that the move order was given. The other player's client would update the simulation accordingly; if the server accepted the command for tick 1507, but the player 2 client was on tick 1509 when it heard of the move order, then player 2's computer would have to recalculate what happened over the course of those two ticks as a result of the move order. The user may see the unit jump a few meters in the other direction (a visible rubberbanding effect, or whatever it's called), but I don't think this is any worse than having to wait half a second for every command to register. I don't think one person having total control over the simulation is worse than every player being able to reveal the map completely. And, like I said, hosting from the computer of one of the players would probably only be done for casual games with ad-hoc networking, such as a group of guys getting together at a cafe. There is the theoretical possibility of a headless host, which makes the game totally secure by putting the trust in a neutral party, such as Wildfire Games itself. And I'm not the first person to propose this. This is adjacent to asking "who is going to pay the developers to make 0 A.D., or the artists or animators? What is the incentive for any of this?", and we all know the answer to this question. We are all volunteers who are doing this in our free time (and to be clear, I say "we" not to imply that I have any stake in the community personally, but to express the communal nature of the project itself; I could say "the devs", but that would make it feel like us casual players are the mere peasants bowing before the almighty developer gods, which just feels wrong). The actual hosting required to do this would probably be provided by someone just as passionate as I am for the project itself, and passionate and enthusiastic enough to not ask for anything in return, just like what is already the case with our developers, artists, and animators. I, for one, really wish I had the free time to actually start working on a solution to the problems I am bringing up here, in practice, but sadly, I do not. Believe me, if I had the means to personally revamp the networking code of the whole project from scratch, and provide my own servers to accomodate for the increased hosting costs, I would. But I have too many personal problems at the moment, so that's going to have to wait. It's also worth pointing out that yes, it would take a lot of work to make something like this happen, and it would definitely present some unique technical challenges along the way (what we are doing now is mere speculation in comparison), but the reward is permanentaly solving the problem of reveal-map cheating at the technical level, and I would say that's worth it. Nothing worthwhile is ever easy. I too, think I will stick to the vanilla GUI, because it is "good enough", and easy to wrap my head around (compared to dozens of custom macros and scripts). But in general, the goal of any user interface design is to minimize the amount of physical effort (clicks, taps, button pushes, keystrokes, pointing, etc.) that it takes to make the computer do what you want. That's what these mods are ultimately trying to do, and if it turns out that the use of these mods trivializes the whole game for the person using them, then I would consider that a problem with the 0 A.D. gameplay loop, not the mods themselves. I already said that I don't call the cheating problem "vacuous" to mean that there are no cheaters, which I obviously don't know (except, if I am to take The CJ's statement at face value, we may be going somewhere). That's not what I mean at all! What I mean by "vacuous" is that there's a technical solution which instantly eliminates the cheater problem, so there's no need to point fingers at each other, or worry if the game you were playing had a cheater in it. Maybe there is, for the time being, but I'm not worried about the whole community being dissolved because there are too many cheaters, because I think the community is pretty clear on what technical interventions can be done to turn the cheater problem into a complete non-issue. ProGUI's restart-autoqueue feature probably works by constantly checking if a recently-stopped autoqueue can be restarted, based on resource counts, and autonomously sends the commands to restart it if so. This doesn't need to touch the simulation directly in order to work as advertised. Maybe it could be helpful to think about the simulation/GUI distinction in philosophical terms rather than technical terms. The simulation contains the positions of units, individual players' resource counts, and stuff like that, as well as the logic that defines how these values are able to change over time based on outside input. The interface contains ways to interact with those values, and provide input to the simulation, by means of a keyboard and mouse, or other input method. In short, I don't think the auto-restart auto-queue feature is a cheat, and I don't think it should be considered a direct modification to the simulation code. Nothing about it makes it more significant than any other feature of these GUI mods that provides any sort of automation (i.e. unit/structure orders being given by the GUI itself, with no player input required).

I'm just not sure what the general community consensus is regarding the three important questions: I worry for the future of the project in a climate of confusion and discord surrounding such an important issue. How we protect the integrity of our game can have lasting consequences, and this is the perfect time to start thinking carefully about these issues. Maybe this conversation has already happened too many times before i showed up, but to my awareness, there still isn't a known solution either. We have yet to come to an agreement, and now that we're in the next phase of development, I think this is the perfect time to ask questions such as this. If anything, I just want to know what the general community consensus is, because this doesn't look like it. If there are indeed multiple threads asking this same question, then I would like you to share links to them here; I have a feeling that my insight into this issue is limited, so that may help answer my question.

Thanks for your fast reply. It is also true that nearly every single game studio in the world develops nonfree software, and either doesn't understand, or isn't sympathetic with, the case for software freedom. The vast majority of software programmers in general would agree that there is nothing wrong with a word processor displaying advertisements, but I certainly object! I am aware that my opinion is very rare, almost unique, even among free software supporters. But one million people can be wrong. They are expected to be different as a consequence of releasing their project's source code as open source (again, think of how many game studios don't do this). The only way to actually forbid players from secretly trying out certain third-party tools in ranked matches is to install an anticheat, which is a program whose job it is to verify that the game's code hasn't been modified. All anticheat programs are nonfree (their source code is private), and they have to be, since these tools rely on obfuscation to do their jobs. Therefore, in order to truly enforce any rules governing what mods are allowed and which mods aren't allowed would certainly require this project to become at least partially nonfree. Maybe the community is fine with that (I'm not; I would leave immediately if this happened, greatly disappointed), but it's true, and it's important to keep in mind. As of now, 0 A.D. is free software, and by definition, that means people can modify the game however they want. Whether we want to change that is a totally different question. Information cheats and GUI automation are still two different things I would also like to point out that, even if you disagree that GUI mods should be allowed, you could still understand that "cheating" by using automation tools that aren't present in vanilla, and "cheating" by breaking the game itself to reveal the map or spawn in units, are two different things. You may think that they are both cheating and should both be banned, but they are still different kinds of "cheating". One point I am trying to make here is that even if it is technologically impossible to truly mitigate the former kind of cheating, it IS possible to mitigate the latter. If we re-design the network protocol in 0 A.D. such that the whole simulation is no longer synced directly between peers, and instead only one peer has the full state and is responsible for computing each player's vision, then the other players would be unable to reveal the map on their end, even if they modified the game to their heart's content. Hopefully you can agree that, even if automation and macros are still to be considered unfair, it would still be very good if we implemented a change that could totally eliminate at least one class of cheating, even if we could not eliminate all of it. It certainly wouldn't be bad. Anyways, I think your argument here is constructive, and I'm looking forward to seeing more from you, and the rest of the 0 A.D. community.

Hello there. I am relatively new to 0 A.D., having played for a little more than a year in singleplayer, and I have yet to try multiplayer. I wanted to experiment by trying to get good at the game with as little outside help as possible, before integrating myself into the 0 A.D. community, and now I am good enough to consistently beat PetraBot on Medium difficulty. From what I've seen, this story is about the same as most other people playing 0 A.D. While I wanted to do my best to avoid outside advice and assistance for learning the game (because this is more of a psychological experiment on myself than a learning experience), I couldn't resist the urge to look up forum discussions in other areas of the community, that aren't focused on helping people learn the game, and I found something disturbing. I came across a forum thread here, essentially a debate about the security model of 0 A.D., asking the important question of what exactly does it mean to cheat in 0 A.D., and what mitigations are necessary to prevent cheating by random players in the online matching service, and in general. Importantly, these discussions were not productive at all, with people on both sides of the argument, including official members of the 0 A.D. development team, making personal attacks and missing the point entirely, and I got the sense that nobody really knew what they were talking about. The larger issue was never resolved, and eventually these threads became inactive between 2023 and 2024, which is the primary reason why I am creating a new thread instead of simply responding to those. The thread in question: seeh - tool or factor influences game wins (I make no attempt to call out anyone in particular by posting these links. Read them on your own, and use your best judgement.) This was the original link, but it might actually be a dead link. It seems that the forum thread was removed before I could comment on it. That's just too bad. I hope my case is still clear even if the context has vanished. Other threads that I will be taking quotes from. They are mostly unrelated to my point, but their arguments have some overlap with mine, which is why I'm bringing them up. Gitea web pages that I will be referencing as well: https://gitea.wildfiregames.com/0ad/0ad/wiki/0AD_The_Vision https://gitea.wildfiregames.com/0ad/0ad/wiki/SimulationRequirements MODDING IS NOT CHEATING As I have stated in the title, I am of the opinion that modifications for the game are cheating ONLY if they can be used to reveal the map unfairly. Mods that provide additional tools or automation in the GUI are not cheating, because they don't do anything to directly violate or bypass the rules of the game. My reasoning for my opinion is that I believe that the challenge from playing 0 A.D. does not (and should not) come from the ability to rapidly give commands to large numbers of units, or perform some sequence of actions faster than anyone else. RTS games are known for requiring lots of keyboard shortcuts and muscle memory, but taking this away does not take away the true challenge of the game. The true challenge of any RTS title comes from the acronym, "real-time strategy". The true challenge comes from being able to think ahead while also reacting quickly to new information. The 0 A.D. Vision states the design goals for the project pretty clearly. I'll quote a few of them here: Well, these are actually things that we don't want to do... you get the point. Modifications to the game that change how the GUI behaves, and may allow certain actions to be automated (restarting auto-queue automatically, for instance), cannot be considered cheating, because what it takes to be good at RTS comes from intelligence, strategy, and forethought, which cannot be enhanced by installing a mod that handles some actions automatically. Even if the use of these tools seems to make someone appear like a better player than they would otherwise be, that is not the same as saying the user has an unfair advantage. As I hope to explain here, over-relying on macros and scripts may actually be a disadvantage if you use them incorrectly. If someone can ruin the entire match by installing a mod that autonomously manages certain actions in the game, then this means the entire 0 A.D. project has failed completely; if the GUI itself should not present any sort of challenge to the player using it, then the challenge and fun of the game should not be ruined by installing a mod or patch that changes how the GUI behaves by adding new ways to interact with the game. The question of whether or not these so-called GUI mods constitute cheats is really the question of whether the gameplay loop we have created is deep and engaging enough that it would take more than a few changes to how the GUI behaves to undermine what truly makes 0 A.D. fun and challenging for all players. MODDER TRANSPARENCY This is probably an even more controversial take, but I further believe that online players should not be required to disclose all mods that they use when playing multiplayer. Players that vary in mod usage should be allowed to play together in one match without necessarily disclosing the mod usage of all players, and mod compatibility should be a question of whether a mod fundamentally changes the game itself or the network protocol in such a way that a modded client playing with a vanilla client cannot be relied on to stay in sync. A mod that only adds or changes GUI features does not fit this description. My main reason for taking this position is that a rule that requires modders to disclose the changes they implement is simply unenforceable, due to the nature of free software. Any tools that can be used to verify whether modifications were made would be easily circumvented by someone with access to the source code. The prospect of installing code in 0 A.D. that reports to the server what changes were implemented in the codebase of the client is fundamentally incompatible with the principles of free software. The only way to make this work is by making some parts of the project nonfree, by taking away the source code and using a proprietary software license. WHAT IS CHEATING? We cannot prevent players from changing how the user interface behaves, and we shouldn't have to as long as the gameplay loop is good enough that the fun and challenge of 0 A.D. is not ruined just because someone added a few new buttons to their screen. Therefore, I think we should focus our energy to a narrower definition of cheating which only includes cases where a player is able to materially violate the rules that define 0 A.D.. Here's what the Wildfire Games Gitea instance has to say about this: I know that this page says "two main ways", but I strongly believe that these are actually the ONLY two forms of cheating that exist, and one of them already has a robust mitigation in place. Directly tampering with the simulation in multiplayer is already impossible, since the network code is set up peer-to-peer, and clients must agree on an initial game state and only synchronize the game by sending commands on behalf of players. If a "cheater" wants to manipulate the simulation directly, this would require sending unauthorized commands over the network to all other players, and this would be easy to detect. The other kind of cheating is direct access to information, such as revealing the map and the statuses of other players. Currently, we have no mitigation in place, as our peer-to-peer networking protocol necessarily requires the synchronization of the entire simulation state to all players from the beginning of the match onward. I believe that this is a flaw in the protocol of 0 A.D., and there is no rule saying there isn't a better solution that addresses all of these concerns. WHAT ISN'T CHEATING I would also like to point out that you can make the case that certain interventions in gameplay, including GUI changes, can result in one player appearing to play better than they would otherwise, but this is not the same as saying they have an unfair advantage. Not every circumstantial difference is or can be accounted for in any online competitive game. The reality of the Internet is that you cannot know what is going on behind the other monitor. We all live in very different parts of the world and live very different lives. We have different luxuries, problems, and circumstances, and these differences very much can affect how we perform in an online video game. Yet we don't go out of our way to control and manage every little detail of everyone's lives just for the fairness of a video game. I think this is what seeh was trying to say with their list. They were trying to compare mods like ProGUI and AutoCiv to factors like being in a comfortable space while playing, and not having too much stress or fatigue that could impact your performance. We cannot control all of these factors, and for the most part, we don't even try to. We tacitly assume that it is an individual responsibility to do your best to prevent stress and exhaustion in your life from affecting your own performance, while not worrying about anyone else. If factors such as having a better monitor, a more comfortable chair, or a more consistent routine to avoid fatigue while playing are not considered unfair to the other players who can't or won't have those luxuries, then why is a difference in how someone else chooses to interact with the game suddenly a problem? What if someone else is handicapped in such a way that their ability to use their hands is severely reduced, and they have to use a special controller just to play video games at all? Should this person be banned from 0 A.D. because of their differences? What if someone comes out with a super cool new client with such powerful accessibility features that it makes it possible for a blind person to play 0 A.D. competitively? Should these people be segregated away from the players who have normal eyesight? It is my contention that GUI mods and changes are not just about giving one person the ability to act faster. Sometimes, it is about accessibility as well. If we expect everyone to use the same interface to play the game, and work with the assumption that the interface itself constitutes part of the game and part of the competitive challenge, please consider the possibility that we could be unintentionally disenfranchising the people who happen to find our preferred means of playing highly cumbersome to them. In order to make any action against cheating meaningful, we must clearly define what cheating is, and importantly, isn't. Not every circumstantial difference between players is equivalent to cheating. We certainly shouldn't expect the same experience from an online matching service than one would get from playing 0 A.D. with trusted friends in the same room. Cheating is actually a very narrow issue, yet it is being blown up to include all sorts of elements and factors that aren't equivalent to cheating, and I think we should instead think critically about what should be allowed in online matches. I strongly hold the opinion that cheating is only happening when a player is materially defying the rules of a game. Revealing the map through fog-of-war IS cheating. Artificially manipulating resource values for certain players IS cheating. Drinking coffee before a match so that your tiredness won't affect how you play is NOT cheating. Installing a mod that adds new ways to interact with the game without changing the game itself is NOT cheating. NETWORK PROTOCOL FLAWS Observe this quote from the Gitea site: I think this is wrong. It's not impossible to change the simulation code and network protocol to ensure that players of an online game aren't trusted with information that they shouldn't be able to see. From the very first time I picked up this game, I thought about how it would actually be relatively easy to design 0 A.D. multiplayer in a way to make it literally impossible to cheat in any meaningful way, by designing a simulation and network system that is secure by design. Currently, the entire game state, including positions and statuses of all units and structures across the entire map, regardless of player vision ranges, must be synced over the network so that all players and observers have an identical game state, which is incompatible with a game mechanic that causes differences in what each player should know about the game state. Synchronization must only take the form of players sending commands for units over the network, and there is currently no way for the host's computer to send data to a client stating that a unit just popped into existence at a certain place. This means that from the very beginning of a match, the entire match, including every micro-decision made by every player, must occur on all devices simultaneously, or the entire match goes off the rails. This is a problem because it means that even a modified host would not be able to prevent other players from seeing through the fog of war with a modified client. I believe that this is a flaw in the networking protocol of 0 A.D. multiplayer. There is no cosmic rule that states that directly synchronizing the entire game state so that the game happens simultaneously on all devices is the only way we can do multiplayer. It is possible for us to design the game in such a way that revealing the map with some code is just as difficult as creating units and resources from thin air already is. THE REAL SOLUTION To do this, we would need to change the entire network protocol, and probably rewrite large portions of the code base from scratch. This new protocol must be designed in such a way that the full game state only exists on one computer, the host. This game state would never be synced directly to any other client. Instead the host sends data to each client based on what that client is supposed to see at any given moment. So, for example, if player 2 is going to raid player 1, then data about the units of player 2 will only be transmitted to the computer of player 1 at the exact moment that player 2 enters their vision range. The logic that decides what each player can see happens on the host, and network packets are timed based on when certain game elements are to become visible. This would solve the problem of information cheating, because even if a supposed cheater tried to remove the GUI effects of the fog of war, and the shroud of darkness, they still wouldn't get any meaningful advantage over the other players, because the information they want to extract doesn't exist at all on their computer; it only exists on the host's computer. In the future, we could also introduce a headless server for hosting, thus taking the trusted game state completely out of the reach of all players. Okay, this sounds like much. It would definitely take a lot of work and redoing existing efforts on the project in order to make the game impervious to cheaters, without the need for any "anti-debugger tricks". It felt like I was being too fantastical or demanding, unwilling to do the work to verify that something like this could actually happen in reality. That is... until I realized I'm not even the first person to say this: alre: 0 calories: It is my contention that cheating in 0 A.D. is a technical problem, not a social problem. If 0 A.D. is to remain free software, then we must accept the reality that it will be impossible to enforce the rules of the game via code installed on the client, since this can always be bypassed by anyone with access to the source code. We must make our game secure by design, by designing the game in a way to make bypassing the rules of the game as difficult as possible, even with access to the client source code. Fortunately, we already know how to do this, and 0 A.D. has a unique advantage in this regard, given its strategic nature. We just have to sidestep the confusion and bias that prevents us from clearly seeing what the rules of our game are, how those rules present a meaningful challenge and puzzle to each player, and how to design our game to make it as difficult as possible to circumvent that challenge in any meaningful way. COUNTERARGUMENTS BreakfastBurrito_007: (could not find profile page, sorry) This cannot be true if 0 A.D. is designed to have separation between game and interface, which it does. These tools aim to make it easier to interact with the game, but the actual fun and challenge of 0 A.D. doesn't go away just because idle units are automatically moved to gather resources, or because auto-queue gets restarted for you automatically. If these tools are able to take away a core aspect of gameplay, then the project has failed, regardless of whether or not we can control the usage of these mods, because it is proof that the GUI itself presents a challenge, and it is clearly stated in the 0 A.D. Vision that we don't want this to happen. Further, auto-starting auto-queue or other automatic economic management done by these mods (I don't know exactly how these mods work, nor do I care since the specific details are not essential to my core argument) looks like it is not actually "losing the production management part of 0 A.D.", because the game is (and should be) designed with strategy and replayability in mind. Look once again to this quote from the Vision: The notion that simple automated scripts like what have been described are equivalent to completely removing a whole aspect of the game comes from the assumption that every match is the same match and there is no variation in the winning strategy between matches. If this is true, then the whole project was a failure. The first time I started getting really good at the game was when I realized that every click, and every choice, from the very beginning of the game to the very end, has a strategic impact, and the best decision to make at any given moment is highly situational. I might have my female citizens gather food from the nearby chickens instead of the berries, and this would mean that my one cavalry unit will be finished with the chickens faster, and can begin scouting very early. Or I could immediately start scouting with my cavalry, at the cost of reduced early-game food production. Or, I could have my female citizens gather wood first, and begin scouting to see if there is a nearby rich food source such as fishing, which would make early food production so strong that I can dedicate all of my other gatherers to wood anyway. As you can see, it's highly situational, and this logic is not going to be replaced by a tool that only provides simple automation that could easily be considered for upstream. Even if a noob installs the mod and has certain actions handled for them that they wouldn't know how to do otherwise, and their score increases drastically as a result of this, they are still no match against someone who actually knows how to play. BreakfastBurrito_007: Easier to control is different from actually making the game itself easier to play. The best players are able to think critically about the map and make every decision intentionally while thinking ahead. This is different from being able to carry out certain actions faster , like evenly spreading out units to garrison inside of ships. BreakfastBurrito_007: The ability to concentrate on everything going on in a match, and having enough working memory to have a grounded understanding of the game at hand that is strong and complete enough to make strategic decisions, is not replaced by installing a mod that makes certain actions less clicky. Those are two completely different things that should not be confused together. Even if it seems like the mod makes it possible to take your mind off of the economy for a while, that doesn't make it smart to do so. There may be different consequences for overlooking a crucial aspect of gameplay if you installed a mod, but every economic decision is still a strategic choice that is not going to be made for you by a mod that allows new keybindings to select only certain types of units and not others. Again, the 0 A.D. Vision: This is what these mods amount to. These tools might provide a small advantage over someone who does not have them, similar to how someone who uses every keyboard shortcut and has a custom layout for the game might have an advantage over someone who just clicks with the mouse all the time, but whatever "general procedure" these mods implement is going to make you more predictable of a player if you rely on it too much, which makes you a weaker player, even if your score appears to be going up. Maybe there are players who use ProGUI, and have a general strategy where their economy management is done mostly using the macros they have implemented, and they spend most of their time thinking about military tactics and defense. It may be true that such a strategy would not work if they player didn't have access to those macros. But it's still a valid strategy, and it also has a valid (and very obvious) weakness: if another player knows that this player has their economy done automatically by a publicly available script, they can predict in advance what kinds of economic decisions the enemy will make (where to gather resources from first, for example), and use this information to determine a weak spot that will allow the player to cut off the enemy's supply lines and cripple them. There may be ways to use these advanced tools to truly make the game smoother for one player by reducing the amount of effort spent controlling the game, but "focusing on overloading the multitasking ability of another player" by sending several raid groups at once certainly isn't it, as even I can think of a potential weakness to this strategy. real_tabasco_sauce: It might be possible to set up these mods so that you can spend several minutes just watching the game happen and still win, but that does not make it unnecessary to think of every economic decision in a strategic context. Do you mine the metal on the edge of your base, thus allowing you to respond quicker to an invasion and making it less punishing if you lose that territory later, or do you mine your starting metal first, so that you can build buildings next to your civic center earlier in the match? I bet ProGUI doesn't make those decisions for you. And if it does, it doesn't make the "best" choice every time by taking everything into account. Again I say, if the challenge of 0 A.D. can be removed by only changing how the GUI behaves, then this project was a failure. We should design the game to give players as many choices as possible, and ProGUI is not going to make all of those choices automatically. If there is only one winning strategy in 0 A.D., then of course it would be possible to write a script that makes you unstoppable in every match. It would also mean 0 A.D. wouldn't really be a strategy game if there was only one strategy to use, don't you think? Also, "other than build buildings"? Construction plans are actually a huge part of the economy. You have to actively think about what buildings to construct, where, and why, and where are you going to get the resources to build those buildings. It's arguably the most complex aspect of economy management. And even if you can use an automated script to make it effortless (you can't, since the best moves are obviously going to be situational and even PetraBot struggles to get it right most of the time), that doesn't make you an unstoppable player, because whatever strategy is chosen by this script is going to have obvious weaknesses. But a mod that doesn't even automate construction falls completely short of something I would define as "managing the economy above 0 A.D.". It seems to me that all this mod does is makes unit training into something you can set and forget, which isn't really a huge deal since I already find that part of the game easy enough to manage with the help of auto-queue and common sense. real_tabasco_sauce: I detect a self-contradiction here. The ability to multitask is difficult and only improved by practice; as in: it can't be replaced with a mod. A mod that adds new ways to interact with the game is no replacement for having enough working memory and being sober and awake enough to take in everything that is going on at once, and use that to make your next move. Again, the ability to concentrate and the use of scripts and macros are two totally different things. Someone who doesn't know the keyboard shortcuts in the vanilla GUI can still win if they have more intelligence and a better strategy, but they would find the GUI more frustrating because they need to expend a lot more effort into transforming their will into machine action. A mod might make it look like you can get away with brain-dumping certain aspects of the game going on, but you can't. If you do, someone will eventually recognize your weakness and exploit it. real_tabasco_sauce: You originally said this as a reply to someone who was saying that the purpose of any user interface, including the interface of 0 A.D., is to provide the most efficient way of translating user will into machine action. If you install a mod that allows you to set a default control group number for every unit that comes out of a barracks, so that you don't have to constantly monitor units that enter a certain area to add them to the right control group, then the game is better for it. I'd like to see you come up with a specific example of a scenario where someone has less fun or is more frustrated with a game because they didn't have to manually click on things in the same way as most people do. Of course, if 0 A.D. were made easier from a gameplay perspective, such as making the A.I. player much weaker, or reducing the skill ceiling by introducing a single path to victory, then the game would be worse. This has nothing to do with the game interface. My point is that the interface and the game are two separate things that should remain separate. 0 A.D. should be challenging and engaging, but this challenge should come from the game being an interesting puzzle with lots of potential choices and directions for the game to go. It should not come from forcing everyone to use the same interface where they have to click on every single tree that they want their units to harvest while also focusing on the raid that they are conducting. Anything that makes the interface easier to control and understand makes the game better, while anything that makes the game less challenging makes it worse. These are two separate things that keep getting confused to mean the same thing. Gurken Khan: It's only possible to hide real cheats (map reveal cheats) because of a flaw in the multiplayer protocol. In theory, it's possible to design our game in such a way that any meaningful cheating is technologically impossible, because the host computer would be solely responsible for controlling access to information and determining what other players are able to do. We aren't doing this yet, and that's why cheating has become trivial. But yeah, as long as our security model continues to be "making it harder with some anti-debugger tricks", then this will always be a problem. wowgetoffyourcellphone: No, it's not. Even if there is a measurable impact to someone's performance on paper if they use certain macros that aren't available in the vanilla game interface, this is not equivalent to cheating. As I said previously, a difference in interface used to play the game is more comparable to a difference in what kind of monitor you use, or how tired you are when you are playing, than it is to actually bypassing the very nature of the game itself. It could be described as an unlevel playing field if people use different interfaces that differ in how easy they are to control, or how proficient the player is in using that particular interface, but this is no less fair than someone else who drinks coffee and plays on their 75 inch 4K OLED monitor against someone who just started working the night shift and plays on a keyboard connected to a phone screen. We can't control either of these things, and we don't bother trying to control the latter, so why the former? wowgetoffyourcellphone: I do happen to know that putting the checks into place for this would be literally impossible, given the nature of free software. The only way to prevent changing how the GUI works on each client is to make a future release of 0 A.D. nonfree, and taking away the source code. As long as the project is to remain free, we must accept the reality that we can't control how people use it, nor the circumstances in which they play, and therefore must stick to a narrow definition of what is unfair and use principled solutions to mitigate this narrow definition of unfair gameplay. We simply don't have the option of using anti-cheat software, DRM, or "anti-debugger tricks", since these tools are fundamentally incompatible with the principles of free software. roscany: If controlling the vanilla GUI is an "essential" part of the 0 A.D. experience, then 0 A.D. is not living up to its stated design ideals. The challenge of 0 A.D. should not depend on how the GUI works, and should instead be clearly defined by the simulation code and enforced by the network code. We have no other options to protect the integrity of a free game. guerringerrin: If this is referencing the mentioned feature of ProGUI that automatically restarts the auto-queue when you once again have enough resources, then I think it's a stretch to describe that as "self-managing the barracks". Self-managing the barracks would mean more like the game automatically making decisions about what to train based on external game factors. Even with something like that on someone's computer, they do not become a formidable force just because they have those scripts installed, and they still have to pay attention to where all of their units are, and if unit production has stopped or is slowing down, why is that so? And that's not to say that the script always makes the "right" choice; as I said, you become more predictable of a player when you over-rely on these tools, and this actually makes you a worse player even if your score in the summary seems to be improving. wowgetoffyourcellphone: We can't control what monitors people use, AND we can't control what mods they install. That's the nature of free software: whatever DRM we put into the game can be easily circumvented with access to the source code, so if we want our game to remain free, then DRM is not an option for us. We must make our game secure by design, and that requires clearly defining what is cheating and what is not. We must design our gameplay with enough depth and variety that installing macros and scripts is never going to be enough to ruin the game for everyone else, and we must design our protocols and implementations in such a way that the actual rules that define 0 A.D. are enforced by the server alone, and can't be circumvented by someone with a modified client. I find this argument especially alarming because it seems to come with the assumption that all circumstantial differences between players are inherently unfair, and any attempts to control what software is running on people's computers is effectively harm reduction. Neither of these assumptions are true! Nobody loses a game against a friend and complains "No fair! You only won because you have a bigger monitor than me!". We all tacitly assume that controlling variables such as fatigue and comfort is an individual responsibility. A case where such a friend was actually breaking the rules of the game to give themselves extra units and resources is something else entirely, and we all agree that this would be cheating. The fundamental fact here is that not everything can be considered cheating. We have to draw a line somewhere, and I strongly hold the opinion that the rules of the game are defined by the simulation code and not the GUI code, so modifying the latter cannot equate to breaking the rules of the former. We also shouldn't hold an online matching service to the same standard as the experience of playing with trusted friends in the same room. You're going to have a bad experience every once in a while; so the most you can do is make sure that you are having fun regardless, by only worrying about how you play the game and not worrying about anyone else. If you only won because it turns out your enemy player had to answer the door and missed the first 5 minutes of the game, so be it. If you lost, and it turns out the other player had several macros and scripts that enabled them to play the game with a third as many key presses, and get a much better score than they would have otherwise, then I won't be offended, and will instead think about a different strategy I might try next time, which I know can work because this game is much deeper than a race to press keys the fastest. This stuff happens, and requiring DRM is not a solution to it. ufa: Well, it looks like you've found your match. That is exactly my point. This is not intended to be an exhaustive list of counterarguments that I have found in the wild, but merely a general overview of the current state of this discussion, which will help us move forward with our debate instead of repeating what we have already said. AN ASIDE: DETERMINISM Not syncing the game state directly with other players would also mean that a high-level simulation code with strictly deterministic behavior is no longer strictly necessary. Because there is now only one instance of the full game state, minor differences in certain unit positions between iterations of the simulation wouldn't matter anymore, since there's nobody to go out of sync with, and players can now accept micro-corrections of these differences over the network if need be. We would have to be careful with replays, though; currently, replay files are composed of two parts, a file containing the initial game state, and another file containing a list of commands that were given on each turn of the simulation, and each time you play a replay, the simulation is actually running in real time from a script that was written as you first played that game. Even the A.I. player actions are computed in real time each time you play the replay file. We could change how replays work so that instead, they contain "baked" values for actual unit velocities and resource counts and such things over time, and then we could abandon the need for total determinism, and use low-level simulation code to make the game a LOT faster and more efficient at the expense of some precision. However, I do think that deterministic gameplay is appealing, just from a gameplay perspective. This is a strategy game that benefits from the influence of random chance being minimized, so I'm sure the most competitive among you would appreciate the idea of eliminating the possibility that a barely noticeable computational anomaly can mean the difference between winning and losing. Just some food for thought. ANOTHER ASIDE: THE DEBUG MENU The debug menu is a sidebar that is hidden by default, but can be activated with a key press, and allows a variety of "debugging" features, such as unlocking the camera, showing unit pathfinding calculations, revealing the map, and promoting units. There is a client-side check to prevent this debug menu from being activated in multiplayer, but as with some other cheat prevention efforts, this is circumvented by recompiling the source code. The thing is, not every option shown by this tool can be considered cheating. We should be careful what we allow in multiplayer; pathfinding data is calculated using information potentially outside the player's range of vision, so showing it could allow players to infer data about the map outside of their range, for example. But I think we can do better if we want mutiplayer to be secure by design. I say the debug menu should be allowed in multiplayer, but not all of its options will work. Promoting units already won't work because the command to do so would be blocked by every other computer assuming cheat codes are disabled by the host. Revealing the map would be fixed by implementing the changes described in the above sections. An option called "reveal map" might be available in multiplayer, but it wouldn't be used to gain new information; instead, it will simply disable the GUI elements that darken the map in the fog of war, or paint black over the shroud of darkness, leaving the player with a bugged perspective that shows what would happen if the parts of the code that draw vision borders are disabled, but without disabling the vision borders themselves? Unlocking the camera should be allowed because this is more in line with tools like ProGUI and AutoCiv, in that this only provides a new way to interact with the game, and does not allow players to infer or extract information that they wouldn't already have assuming map reveal cheats are properly fixed. It's already possible to arbitrarily increase the maximum camera zoom by modifying the user.json file, and nobody seems to have a problem with that, so I'm interested to see if anyone objects to the idea of allowing unlocked camera in all multiplayer matches. As for showing path finding, I do think it's worth a broader discussion to consider exactly how the units of a player should calculate their path when ordered to move into an unexplored part of the map. Sometimes, I can already infer information about the map by ordering units to move to unexplored terrain. If I order them to move forward and they respond by turning around to go around a corner, then I can infer that there is no clear path ahead, even if I can't see the obstacle directly. Perhaps this should be changed so that if I click on an unexplored area, the units will attempt to move straight forward, but will stop if they encounter an obstacle along the way. This can obviously be discussed further. This will inevitably be something to think about when we properly address cheat prevention in a later release, so I thought I would bring it up. Other than revealing the map and promoting units (which are their own separate issues), I don't think anything else in the debug menu can realistically be used to bypass the actual rules that define 0 A.D., assuming there are appropriate interventions in place for actual cheating. YET ANOTHER ASIDE: VISION LOGIC AND THE GUI Another thing I think is worth mentioning is that I suspect that the actual logic that determines the vision range of different units and structures is actually done by the GUI itself, and the simulation sends the entire game state to the GUI all the time. If this is true, than that is truly disturbing. It's like trying to protect your email password in a document by placing a black box over it in the PDF. It's the laziest and least secure way to implement such a feature, just waiting to be broken even by a novice programmer. The reason why I suspect this is because I do notice from the graphics that even in the Shroud of Darkness (formal name for the black part of the map where you can't even see the terrain itself), I can still make out mountains and valleys when I view the map from the side. Sometimes, while playing, I even make decisions about where to scout next based on rotating my camera and trying to see where there is a valley or a mountain in the unexplored parts of the map. Another reason why I suspect this is that after exploring a certain area of the map, even if you no longer have vision range of that area, if an enemy player were to claim certain territory that you have previously explored, then the territory bubble would appear on the minimap from the very moment that the territory gets claimed. I frequently make strategic decisions based on this information, and I think it makes the game worse that I don't have to wonder if certain parts of the map are still neutral. This is the kind of bug that would only come to be if the parts of the code that handle actually drawing the minimap on the screen were also responsible for deciding where to draw the black parts, which would only be the case if the simulation lazily passed the entire game state to the GUI, and the GUI were responsible for the logic that determines what you're allowed to see. I'm not very familiar with the 0 A.D. code base, so I can't dive in to the code to verify exactly how the fog of war works on a technical level, but I very much suspect that it's done in the laziest way possible. In order to solve the 0 A.D. cheater problem, we need to fix that. Until then, just know that using an anticheat won't fix anything; it will only drive away more players who care about their freedom, such as myself. CONCLUSION As I said before, I am very new to 0 A.D., and relatively new to RTS in general. I can consistently defeat the Medium PetraBot difficulty, but I'm probably no match for most of the people who will be reading this. I haven't tried ProGUI, AutoCiv, or any of the other GUI modifications that have been brought up in the forum threads that I am quoting from. I wish I had the time and technical skill to demonstrate how a technical solution to the map reveal problem could actually work in practice. Frankly, I'm not qualified to say any of this, and I wish I didn't need to, but I am very passionate for this game, as it is the highest-quality free (as in freedom) RTS game that I know of, and has the potential to make gaming history and open up the world of free software gaming. The idea that prominent figures of the community are genuinely considering introducing DRM or nonfree code into the project to address the cheater concern which is both poorly defined and blown out of proportion (and if you know your history, you know that this is a recipe for disaster), just makes me angry. I don't want to see this project fall for the same fakery and lies that are the reason why the modern Internet sucks. To be clear, the lies I mention are the idea that people shouldn't own their technology, and if we don't install DRM and other controlling software into everyone's computers, and prevent them from installing the apps they want, or having any privacy, then our society will fall apart from rampant abuse and trolling. That simply isn't true. This game has so much potential, and I feel responsible for speaking out before the community takes this amazing project in the wrong direction in the name of fear and protecting the community against a frankly vacuous threat. I don't say 'vacuous' to imply that cheating isn't a real problem on the matching server, which I wouldn't know since I don't play multiplayer (yet), but I believe that this problem has a technical solution that doesn't require taking away people's rights, and I don't want us to get distracted from that answer because we can't even agree on what we're fighting against. I would have waited until I have dealt with my personal problems before complaining on the Internet, but then I saw this from wowgetoffyourcellphone in the thread about 0 A.D. being too small: This person is saying that once the first Beta version is released (which will be the very next release), then it will be too late for me to speak out, and whatever the community consensus on the definition of cheating and the required mitigations is will be set in stone. This presents a sense of urgency within me, as even though I am fully aware that there is a lot more work I could do to properly address my concerns, I feel it is important to at least come forward with what I have, so that the community is at least aware of my alternative opinions and their justifications. If it turns out that the developers are convinced that moving buttons around is unacceptable and we must take over people's computers to stop them from doing that, then at least I can say I tried. I hope it's not already too late... The purpose of this thread is to revive community discussion about these three important questions: What are the rules that define 0 A.D.? Where does cheating stop and benign interface enhancements/accessibility begin? I think that cheating only refers to breaking the actual simulation code of the game. How do those rules alone present all players with a reasonably fair and engaging challenge and puzzle that is fun to play at all levels? We should make sure to design our gameplay to be both fair and engaging to all players, regardless of how they choose to interact with it. What (ideally technical) means do we need to implement to prevent unauthorized circumvention of these basic game rules, while still upholding the values and principles of free software as defined by the GNU GPL? We need to design our network protocols to ensure that the host computer has everything it needs to protect the integrity of the match from both information cheating and unfair state modification. I, for one, believe that it is possible to make a video game that is both free and fair. It won't even be hard; we already know what we need to do to make our game secure by design. We just need to avoid the confusion, bias, and distraction that prevents us from seeing clearly. I hope this thread will serve as a reminder of what we are capable of when we work together. This project gives me hope for free software and the gaming world in general. When I first played this game, I honestly didn't believe that this was early access, as it looks polished, and has solid gameplay that keeps me coming back for more. Now that I have more experience both playing this game, and studying it on a technical level, I can say that there is so much more we can do to create a truly groundbreaking project, and I am excited to see what is to come. And perfect timing, too. Now that we're in Beta, and most of the game is fleshed out already, this is the perfect time to revisit our old solutions and improve upon them. If Alpha was about establishing the feature set of the game, then Beta should be about revising the existing work we have done to make it more stable, efficient, and secure. Beta 1 doesn't have to be perfect, but most of the changes should be in the direction of addressing the known issues from Alpha, including how easy it is to cheat in multiplayer. Who's with me?