WiseKind

I get the feeling that you didn't even read or consider my full argument. Yes, you were focusing on in-game tools. I understood that much. I was making the point that these tools should not be regulated, and I tied this to two statements that I have already made more than once throughout this thread: The effect of these tools can be somewhat compared to the effect of life factors such as fatigue or stress, something we already generally don't try to regulate just for an online match. There are two different aspects of the gameplay experience: the mental challenge of keeping track of everything, and the mechanical challenge of implementing the strategy that one has chosen. I claim that mods mostly only help with the latter, which is already not relevant to skill because the game does a good job at keeping the required keystrokes to a manageable level, at least in my opinion. Nor should it be relevant to skill, because a game where skill is capped by a player's typing speed doesn't sound like fun at all. I'd like you to tackle these statements individually in order to claim that these mods can be described as a cheat (which, in this context, can be understood as a way to replace the needed skills to play the game competitively). And they say I'm the one making all the assumptions... I was just repeating something that @Atrik said in the old thread that got deleted. Perhaps I should have been more clear that this isn't my original idea, so I apologize for that. Maybe ask Atrik what made them say that, but in the meantime, here's the rest of my case. Illustrating my point with an example Let's bring into focus the imaginary scenario that everyone has probably already thought about, but don't want to put it into words for some reason or another. Suppose a player is VERY new to the game, either on about my skill level (Hard Petra Bot is my limit), or even weaker. I can go back to my old replays, and I almost always am able to describe the mistakes I made in strategic terms (spending too much time finding a food source in the early game, or focusing too much on early-game research and not enough on training units, etc.). Now suppose that player installs ProGUI, and uses the feature that everyone has been describing, which allows the player to set-and-forget their unit training routine, and if I remember correctly, resource gathering as well. A new player sets their rally point on the starting resources and hits "go", and they can passively watch the same early-game progression that other (good) players are used to manually performing. Problem #1: I have developed the belief that what makes a player "good" or "bad" can almost always be described in strategic terms. If you need more evidence for this claim, maybe I can pull out some of my old replays, compare them with more recent replays, and add commentary on what I really think was going wrong there. In this hypothetical example, what is making the player bad is that they don't know how to implement this strategy manually. The mod knows more about how to play the game than they do, which isn't true for even probably me. When spoken like this, it may seem like ProGUI or other tools can be used effectively as a teaching tool for VERY new players, helping them to grasp the concepts that seasoned players take for granted. Features like this may even be considered for the vanilla tutorial; something like a trigger that automatically controls the player's units to show them what semi-decent gameplay might look like. Combined with the tutorial panel, this could be a way to illustrate how a good player thinks. However, this wouldn't go very far, because... Problem #2: This game is (should be) sufficiently diverse and sophisticated that, in this hypothetical example, the VERY new player who is using ProGUI to watch their economy passively grow in ways that don't work in vanilla, would still lack the sufficient strategic understanding of the game to, you know, actually play good. The game starts, and the first thing I do is set my civic center rally point on the starting resources. As a VERY new player, I genuinely see nothing wrong with this! Oh, my population limit was reached? Time to select all of my units and order them to build houses in a row. Every single unit is no longer building resources, and is now walking across my base to build a bunch of houses, which takes a while. Now I can get back to gathering. My berries run out, so I do what the tutorial suggested and build farms next to my civic center. My wood runs out, so I build a storehouse beside the next closest source of wood. I don't build a barracks early-on, or defense towers, or anything else, because I'm a new player and I don't understand any of that. Other players have stated in the past that ProGUI doesn't automate decisions about building construction, which is what I'm going with for this example. But even if it did, it would still be a similar story. It may be true that a new player would benefit greatly from the mod in terms of raw scores, but it doesn't serve as a replacement for knowing how to play. Someone who does know how to play still has to pay attention to everything in order to get the best possible use of the mod. In conclusion: So, I just made this example knowing that there is a whole lot of room for me to have to fill in details that I wouldn't know definitively, so it's worth stating again that I still haven't tried ProGUI, and I know that there's a high chance that a lot of what I just said is inconsistent with the actual mod. I would like to say that this is besides my point. It's just an example, and you can comment on every little thing that I misunderstood, and say that I'm a bigot (I will probably do just that, once I have actually tried it), but these are all minor nitpicks, and my point still stands. My point is that even if a GUI mod is capable of making strategic decisions on the player's behalf, this cannot be considered cheating, because such mechanisms still depend on the player's ability to concentrate and understand what is happening, which will always be necessary. If I am understanding this correctly, your claim is that the lag in the game affects your ability to keep track of everything. I feel like I must put a pin in this and discuss it later, because I obviously don't know what the lag is like, since I've never tried multiplayer. I have tested the multiplayer by running multiple clients on the same computer, and the result is that every command I send has a noticeable delay, but this doesn't make it harder for me to concentrate on what I am doing (not that I was ever trying to, since those tests were mostly an attempt to explore for myself how multiplayer works in 0 A.D.). In the meantime, maybe be more specific about what you mean? Again, I have yet to experience 0 A.D. at a high level, so I can't really make a claim here, but I think it would be helpful for you to be more specific about how this works, if that is possible. The scenario that this makes me think of is one where you input your commands on the keyboard (and don't struggle to do so), but must wait for those commands to be enacted before you can begin thinking ahead. I don't see where a GUI mod fits into the picture here. A GUI mod might reduce the number of required keystrokes, but it wouldn't make the lag go away. If this is your experience, then I don't see how a mod like ProGUI would make it better. And if it is the case that you are struggling to input the key commands fast enough, then I would say that this is the Confusing UI problem like I mentioned above. Being limited by my typing speed doesn't sound like fun at all, and if that happens frequently in a typical rated match, then I would say that 0 A.D. is falling for the Confusing UI snare that they mentioned in the Vision. I think this comment is unfair. I wouldn't say that this is a troll topic that doesn't deserve sincerity. I, for one, have had a lot of fun in this one discussion, and a lot of productive and mature argumentation has already been observed, which I enjoyed a lot. I am feeling the frustration that some forum users don't seem to see my argument eye-to-eye, and make comments that seem to ignore things that I have already said. But neither @Atrik nor @TheCJ are guilty of this, to my knowledge. And it doesn't ruin the whole thread for me. Also keep in mind that this thread is actually several threads in one. There are the following arguments occuring simultaneously here: Are mods like ProGUI and AutoCiv unfair to players who aren't using them? How should we address the flaw in multiplayer that allows any player to reveal the map unfairly? (a completely different question than the one above it) How much of the community is SP-only, and therefore much harder to measure? Emphasis on singleplayer in future Beta versions? About the notorious lag in multiplayer due to poorly-optimized code As you can see, these are completely different topics that have all been brought up at least once in this singular thread. To confuse these disparate questions into one would be a mistake. I would also like to say that every opinion I have stated about "what MP should be" has been on the basis of 0 A.D. being a free software project, and I feel I do have a stake in how certain networking and social structures are implemented, because I don't want to see this great project get ruined because people don't understand my vision of what free software is supposed to be about. But I understand now that I am not going to change the opinion of other people, and I would be better off seeking out a portion of the community who is more welcoming to mod users, letting everyone else do their thing. Hearing this makes me want to try the multiplayer lobby sooner. I did register on the lobby, mostly as a defensive reservation of my username, and when I looked at the list of active games, I saw two people playing a 2v2 versus the Very Easy Petra Bot. If that is what people are using the lobby for, then I might just give it a try, maybe even today. I do plan to try that and ProGUI, mostly because it has been brought up so much, and because understanding what these tools actually are, and how they work, will allow my to better illustrate the opinion I have. But, as I have also already said, my base claim does not depend on specific facts about these specific tools. In this very post, I may have gotten a ton of stuff wrong about ProGUI, and this will probably make me cringe and want to go back and edit my mistakes later, but please understand that my base claim is that there can be no such thing as a GUI cheat mod. Therefore, no fact about these specific tools will ever change my mind. Hopefully you can understand this. I understand the frustration of seeing people make foolish assumptions about your own work, without putting any effort to understand the very thing they are arguing about. But please understand that I am not arguing about ProGUI at all; it's just a useful example that I use to illustrate my base claim that actually has nothing to do with ProGUI, and I am only working with the information that I have gathered from other forum users. If I have misunderstood one of these things that other people have described (and I have misunderstood at least one thing, I'm sure of it), then feel free to correct me, but please don't call me a bigot and say that this entire thread is just a big joke, because it's not. As I have said before, please look past the misunderstandings and see the broader argument being had.

Thank you so much for this excellent demonstration showing another angle on the claim that making the game fair-by-design isn't hard. I would say that I don't think video-streaming the game to clients is the right answer, though. Lag would be much more consequential, even if it doesn't result in OOS errors. However, I want to place emphasis on this line: This is the point that I am trying to make. It is possible to design the network protocol to fix the holes that I am describing, while allowing it to use even less bandwidth than it already does. Though I don't have the time or experience to create a technical demonstration of how this could work, I do have quite an imagination. I imagine that the simcode would work just like it already does, but with only one simple change: make it possible for the host to send packets ordering units or structures to "pop-in" or "pop-out" of existence. Then, the host would have all of the tools it needs to control what players can see at any given time. The simplest implementation on the host end would be to check on each tick if a unit is entering or leaving a player's vision range, and send the pop-in/pop-out packets for that tick. Each player command should only be synced with clients that have the affected units in their vision range at that moment. Of course, any implementation would work as long as the basic tools are available, so we can separately discuss whether running these calculations on every tick would be too costly for hosts. The host would also no longer need to send data for units that aren't visible for the client, which directly reduces the bandwidth requirements. There are two potential problems with this model, which I think are also easy to solve in principle: The map itself is also a source of valuable information when the Shroud of Darkness is enabled ("Explored Map" setting is turned off). There would need to be a way to stream the actual terrain and resource data to clients as they explore the map, otherwise players could still bypass the shroud of darkness. As I have described before, I can already somewhat bypass the Shroud of Darknesss simply by viewing the black parts of the map from an angle, and observing humps and dips in what is really a silhouette of hills and valleys that I shouldn't be able to see. Then there are replay files. If the client cannot see the whole game state (and they shouldn't), then it's worth reconsidering how replays should work. Perhaps the "pop-in" and "pop-out" commands could be recorded on the replay file directly, creating a "partial" replay, that only shows one perspective of the match. If we want players to be able to see the whole match replay at the end of the match, then this would require the dedicated server to download the replay file to each client once the winner has been determined. Alternatively, there could be a website associated with that provider, allowing players to search for their match (or possibly any match) and download the full replay file on their own time. As I said, they wouldn't need to. Nobody is actually suggesting that we do it this way; this is just a hypothetical example to demonstrate that the real bandwidth requirements to secure the network protocol aren't as you described previously. Look above to see my proposal for the simplest change that would need to be made to make the game fair-by-design. Another great example of a tool that enables a player to play faster is Adderall or caffeine, or other stimulant. I made the point above that when playing online games, it's a fact of life that we can't control factors like fatigue and comfort for all players, and we generally accept this fact. The mood of a player is likely to affect their performance much more than the usage of computer macros or other tools to implement the same behaviors they already have, but with less keystrokes. My case is that this general acceptance should also apply to client-side modifications. It's also worth pointing out that the ability to concentrate (enhanced by stimulants) is completely different from the ability to type or click faster (enhanced by mods). The former of the two is relevant to gameplay, because the inability to concentrate manifests in the lack of awareness of game elements, which leads to flawed strategies being used. The latter, however, is not relevant to gameplay. The inability to type fast manifests in the furious typing or clicking to implement the strategy that one has already formulated and decided on, resulting in direct frustration as the player is unable to mechanically implement their desired behaviors. This is a problem that I have never had when playing in singleplayer, and if it is a frequent problem in multiplayer, then this deserves its own discussion; not about whether GUI mods should be banned, but whether we should make changes in the game to avoid the Confusing UI that results in this frustration: This plays in to a point I made before: some of these tools are not meant as performance tools as much as accessibility tools. A mod that transforms the tree and berry models into red and green cubes would be very helpful to a player who, for whatever reason, has difficulty making out the patterns of these different game objects. It would also be helpful to a player who doesn't have a GPU powerful enough to render the models for the game. If you are arguing that these tools are cheats, you are essentially saying that vision problems, as well as certain neurological differences, constitute flaws in that person's skill in the game, and therefore these people should not be able to play 0 A.D. with us, because of their differences. I think that's absurd and not cool at all.

Hi, I'm not dead! I guess it could be described as an anti-cheat system by some definitions, but I would refrain from calling it an anti-cheat because such a system would be easily thwarted by recompiling the game. Someone who really wanted to hide the use of mods would easily do so; this system would be a convenience feature to ensure that casual players don't accidentally break the rules. A real anti-cheat system would necessarily be a nonfree component bolted onto 0 A.D., because it would rely on obscurity to do its job effectively, which is to make it more challenging for players to hide modifications to their game client. I wouldn't support such an anti-cheat, because it goes against the values of free software. The system I am proposing is just a simple client-side check, done at the engine level, to ensure that the player does not join games with mod settings that are incompatible with the client (such as using ProGUI in a non-ProGUI game, or even using a mod that adds new game mechanics in a lobby that doesn't use the mod, to prevent OOS). As a security feature, this would be a joke. That's why I'm not calling it a security feature, but rather a convenience feature, because it makes it easier for those using the vanilla engine to comply with mod rules. It prevents accidental violation by someone who may be new to the lobby or unfamiliar with the different rules, but it does not prevent intentional violation, since this would always require nothing more than downloading a different EXE off the Internet. Great! Then don't change anything. One of the greatest aspects about free software is that people have the freedom to form their own communities around software. I've had a tone of urgency, as if the whole project will be wasted if we don't fix this one issue, but that actually isn't really true. Even if 0 A.D. started releasing every Beta version and beyond with a nonfree license (and to be clear, I don't think this is likely to happen), Wildfire Games will never have the power to take away Alpha 27 from those who already have it. If this community came to the conclusion that we can't afford to release the soruce code, or else cheaters will be unstoppable, that won't stop me (or anyone) from taking the work that's already done, and spin it in a different direction. If the whole lobby were oppressed by rules telling you what mods you are allowed to use, I can start my own lobby where such rules don't apply. What I'm trying to say is that we don't have to argue about whether or not GUI mods should be allowed, or what exactly constitutes cheating, as long as people are empowered to make that call for themselves, regardless of what other people think. As much as I value software freedom, and reject nonfree software, I will say that one of the best things about technological freedom is that it enables a more diverse and inclusive Internet. Nonfree social media has a habit of forcing everyone into one box, one way of using their technology. But in a free software world, anything goes, and people with the most disparate means of interacting with technology and the Internet can more easily coexist with each other. Part of this is understanding that people are going to vary in their undertanding of the very concept of freedom, and not letting this affect how you exercise your freedom. This means that a free-as-in-freedom lobby may very well have some players who don't want other players to use any mods when playing with them. I can't change the ways of these people, nor should I have to, and they also can't force me to adopt their rules in my own matches. We can all coexist peacefully, despite our very different viewpoints, and I think this is technological freedom at its best. So, if this is the current state of the multiplayer lobby, then no changes are necessary. But if the lobby does force all players in one particular direction, this still won't stop players from starting their own lobby with their own rules. This is because freedom is not something that is given to us; it is something inherent in our being, and Wildfire games cannot take it away from us, even if they never wrote another line of free code again. 0 A.D. as more than the multiplayer mode It looks like the thread verges off from there, and now everyone is discussing the size of our community: player retention rates, proportions of lobby regulars to the (possibly) thousands of players who play privately and never interacted with the community, and a few others. I want to make it clear that this is a totally different discussion than before, but I don't want to shut it down; I do think this is worth discussing here. I think it's important to note that 0 A.D. is definitely more than a multiplayer RTS experience. Even if the network code is never fixed, and every match has at least one cheater, the game, as a whole, would not be a complete failure. People who are dissatisfied with the multiplayer experience will still find ways to have fun in 0 A.D., whether that means playing singleplayer campaings, or setting up LAN parties with trusted friends. I wholeheartedly agree that Beta 1 should definitely have most of the work done in the area of singleplayer, as this is where we are lacking the most. Practically the only thing there is to do in singleplayer is bash my head against a very dumb A.I., which is fun for a while, for a new player, but lacks replayability once a player has mastered the basic mechanics of the game. I agree with all of this. I really think we should address the information leak problem by designing the network code so that the game doesn't have to sync with all players. This is a gaping hole in the network protocol, and should be treated as such. I believe that this is possible, and it would totally fix all information cheating, leaving only ProGUI and similar mod users to complain about. I don't see how this wouldn't be a massive win for the multiplayer side of 0 A.D.. But at the same time, we also need to keep in mind that the lobby, and the multiplayer modes, are just one part of our great game, and we shouldn't get so hyper-focused on a flaw there, that we miss out on opportunities to improve the project more broadly.

Thought I wasn't going to be back until the end of the week, but I can't sleep so I guess I'll say a few more things. I don't think the measures for preventing scripted automation would be much different from the measures for preventing any other GUI change on the client side. I know about the specific examples that have been brought up as for how people were found to be using automation, but as a general principle, it's impossible to be completely sure that someone didn't use automation during a rated game, for the same reason that it's impossible to enforce a modder transparency requirement. My main thing to say about scripted automation is that I think that there is a certain point in which a mod literally becomes capable of playing the game for you. At that point, it is no longer a GUI mod, and instead becomes a new A.I. player for the game. Then it becomes the discussion of "should a robot be allowed to compete in the lobby service?". Personally, I do think that robots should be able to participate in anything that humans can, provided that they are competent enough, and that's a completely different extreme opinion that I hold, which is also based on freedom absolutism. I disagree with all captcha systems, and other anti-robot technology because I believe that at the end of the day, there are plenty of reasons to automate nearly anything one would do on the Internet. Anti-robot tech is mainly used to prevent overwhelming a network server with bogus requests, but I think that we should rely on other technologies to do this. I'm not going to go into much more detail here, because this is mainly for context. But, when it comes to automation like ProGUI's auto-trainer, I see that this blurs the line between a simple GUI mod that doesn't automate any part of the game, and a full-blown A.I. client that can play the game competitively, without any user input whatsoever (you literally click the join button and then check back in an hour to see if you won). If we suppose, for the sake of argument, that the latter technology is problematic, then there should obviously be a limit to how much automation can be done. I disagree with this, but only because I believe that even an entire lobby account that's run by an A.I. wouldn't be an issue with me. This context should help clarify my stance on automation, since I know that is the primary controversy surrounding GUI mods. But (and here's where I say once again that I haven't tried ProGUI yet), as you all have been describing, ProGUI's autotrainer works by taking as input the desired army composition, distributes the required training across all available structures, and starts each batch with a different value based on resource counts. If that is a fair assessment of ProGUI's autotrainer, then I would say that this isn't too far into the realm of automation, as it would still require significant strategic thinking and planning by the human player, in order to get the best use out of it. This is just a more in-depth analysis of an argument that I have already made more than once. I just think we need to be careful. Under that definition, it's easy to make the case that having a bigger monitor or something can be a cheat. This is why we need to draw the line somewhere, and acknowledge that not every circumstantial difference between players should be banned. I would really like a more in-depth definition of the word "micro" in order to truly understand this derivation. Previously I thought of "micro" as the smaller, more detailed choices that you make, which are not as noticeable when getting an overview of what is happening in a game. When I am constructing a stone wall, I try to keep all of my builders on one side of the wall, so I don't have some of them trapped outside of my base when the wall is complete. I do this by issuing a "push order in front" action to move the units to one side of the wall while they are building, so that they will walk around and then continue. When capturing an enemy civic center, I will use the line-drawing movement mechanic to draw a circle around the structure, and then queue the order to capture, so that the units will more quickly wrap around the structure (depending on the size of my army, I may be able to prevent garrisoning inside by covering the entire perimiter). These are the kinds of decisions that I would consider "micro", and I do think they matter. However, I don't think automating them would be considered cheating, because of a point I made earlier. I notice that even when playing in vanilla, I am not really limited by my input speed. I am limited by my ability to concentrate and think ahead, but this is different. Whether I am using a mod or not, I will still be able to draw the circle around the civic center, and this will not take away precious time for clicking on something else. The mod just makes it easier and less annoying, but I still have to think about it. Again, maybe the examples I have given are not what anyone else thinks of when they hear "micro", so I think an in-depth explanation of what that means will be helpful. I do think that this game should have more of an emphasis on tactics and strategy, and should not be based on where exactly on the ground you click, or how fast you are able to click it, based on the paragraphs of the 0 A.D. vision saying that "First click wins" is a snare that will make 0 A.D. a worse game. "Every other RTS" may be designed in such a way that the first click wins, or has much more of an advantage, but 0 A.D. treats this as a flaw and tries to avoid it by designing the game to be deeper than that. So far, I think they are succeeding. @TheCJ, I would like to say that your previous post was very enlightening. I think you have a stellar understanding of my position and the current status of this thread. I don't mean to sound dismissive by addressing your counterarguments. It's just that if someone agrees with me, then what do I have to say to that? A compromise Even I am starting to feel the frustration in this thread. It seems that some people really strongly hold the position that the individual key presses on someone else's keyboard is part of the game, and insist that we should limit how other people are allowed to play our game. I think the community would benefit from a compromise, where both viewpoints are equally respected. I don't think we are ever going to come to a complete agreement, so here's what I think we should do As far as the lobby TOS goes, the rule of no cheating should be clarified to say that cheating only happens when a player uses tools to break a game mechanic, such as fog of war. A.K.A. my definition of cheating. However: Individual hosts should be empowered to write their own rules for what should be allowed in their games, even in rated games. This could include 'no mods', or it could include 'no turtling' (i.e. never attacking the enemy and basically waiting the game out, which I think is fun but others may think is boring). It should be accepted that hosts who include their own rules should generally be responsible for enforcing their own rules. If an individual host finds out that another player broke their 'no mods' rule, they can ban that individual player from future games, but they will not be banned from the lobby. This is like saying that if you start spamming offensive memes on this forum, you get banned from the forum, but not the whole Internet. A convenience feature may be implemented in the lobby where hosts can list out what mods they allow, or even require, and clients will automatically honor those policies. Clients should not always disclose what mods are currently enabled for every host, but some hosts can require that mods be disclosed in order to connect to them, and the client can be programmed to automatically honor this. This should not be considered a security feature, as this would go against the principles of free software, but it should be a convenience feature so that the "what mods are allowed" conversation doesn't need to happen on every single match start. I don't think the no-mods policy should be the global default, enforceable with a global ban, because that would present a tricky situation for hosts who want to welcome individual mod preferences. If the other side insists that the no-mods policy should be global, then there could possibly be a further compromise where there are differnet game categories (don't use rated/unrated for this) for the different groups and whether or not they allow mods, and using mods in the wrong group could result in a ban (though, as described above, this would require using a modified engine, as the vanilla engine would have safeguards in place to prevent accidental violation). There may be a different option where different lobby services are used for the different groups and their policies, if it turns out that we're such savages that these two opinions can't coexist at all. You would need to edit your user.cfg to switch lobbies, which it is possible to do, by the way. I believe in freedom, first in foremost. I think that with this belief comes the acceptance that I cannot control what code is running on other people's computers, just like they shouldn't be able to control what code is running on my computer. But, just like all other free software supporters out there, I also accept that the vast majority of the Internet is irredeemably nonfree, and we must relegate ourselves to a small corner of the Internet in order to retain that perfect standard of freedom that we place on ourselves. But to me, the alternative, which is to accept a partially nonfree setup, is worse. So I wouldn't mind if the 0 A.D. community is fragmented even further for the people who have different standards that they hold their games to. Personally, I don't even see fragmentation as a bad thing; it's good to allow the Internet to be diverse and decentralized, precisely because that way, we don't have to all agree on the same thing. Let's just acknowledge that there is still what I would consider to be a severe critical vulnerability in 0 A.D. that allows anyone to bypass the fog of war and see the entire game state in a rated match, if they are so inclined. Can we at least all agree on that much? Please? It doesn't mean you need fiber internet just to play a 1v1, trust me.

Perhaps I have not been concise enough for you. Let me make it up to you by writing a short (ok, not really short) summary of everything that has happened in this thread so far: I open the thread with my main idea, which states that modding is not cheating, because the challenge of 0 A.D. is based on strategy, which is not easily replaced by a mod. Even if there is a measureable advantage, that is not the same as cheating. I also bring up the separate problem of revealing the map unfairly, and I think this has a technical solution. The first reply is from @wowgetoffyourcellphone, who says that the idea that mods are cheats is ubiquitous, and there is no reason for 0 A.D. to be the outliar. I said that 0 A.D. is already an outliar by being a free software project, and my original claims are tied primarily to free software idealism. I clarify one of my previous points by saying that this thread is actually about two arguments, one being about mods like ProGUI, the other being about the ability to reveal the map unfairly. Even if you believe that mods should be regulated, you can still agree with me on the point that we can do better to make the network protocol of 0 A.D. more secure. Then, @real_tabasco_sauce comes into play, saying that ProGUI makes it easier to exploit a known gameplay vulnerability where people expliot the garrison mechanics to transport units much faster than walking. I said that this is a flaw in the game design itself, and should be treated as such. @TheCJ brings up several points: The first one is that the GUI is part of the game (I still don't quite understand the logic behind this one, but that's okay). The second point is that even a small increase in input speed (a few seconds, or even milliseconds) provided by these mods is an advantage, therefore cheating. I counter this by saying that the gameplay should be designed with enough depth that it's not about who clicks the fastest by a few milliseconds, but rather who is the smartest at thinking ahead. The third point is that it's not necessary to have "checks" in place, just a general consensus of what is allowed. I say that this will become increasingly insufficient as our community grows. The fourth point is that TheCJ does personally find fast clicking to be enjoyable in gameplay. I say that while some might find this enjoyable, it is generally better, from a UX design perspective, to minimize the amount of input needed to play the game. @Boudica barges in with a highly personal insult implying that I'm just sore about not being able to cheat in video games and used Machine Learning tools to assist in writing my article, and also grossly misquotes some of the things I said. Rightfully ignored by literally everyone. @bb_ makes a comment that while changing the network protocol to be more secure may work in theory, the performance requirements of such a model would be forbiddingly costly. I clarify that the network protocol doesn't have to be implemented in the way that they are describing, in order to gain the security benefits that I described. @Seleucids makes the claim that the vulnerabilities in 0 A.D. game design are not easy to exploit and therefore low-risk, and also claims that the features provided by ProGUI are not merely GUI mods, but do change the behavior of the simulation code. I counter the latter claim by saying that, while I can't make any statements about how ProGUI actually works technically, the mod does not need to modify the simulation code in order to work as advertised. @TheCJ once again tries to claim that the best practices of general UX design should not apply to game design, and @real_tabasco_sauce affirms this notion. I reply by making the statement that the "mechanical challenge" of 0 A.D. is a necessary evil, and needing to click faster does not make the game better. I clarify one of my previous points by saying that there is a distinction between input speed and actual mental concentration capacity. Mods can help with the former by automating certain actions, but the latter cannot be helped by anything short of artificial intelligence, which becomes a totally different discssion (should robots be allowed to play video games?). @TheCJ calls out a supposed self-contradiction in my argument, which was actually a writing mistake that I later corrected. @TheCJ claims that we don't need to argue about the definition of real-time when a dictionary definition exists, and I reply by saying that a dictionary definition is not helpful because dictionaries are meant to provide the general use of a word, while this is a highly specific case. @TheCJ claims that even if concentration and input are two different things, they are both part of the challenge. I insist that the latter is not part of the challenge, and that was my original point for making that distinction. @Atrik makes a comment on the feature set of ProGUI, and claims that it was about UX improvement from the very beginning. @TheCJ affirms that this is precisely what makes it a cheat mod. @Seleucids later steps in by saying that under this metric, any circumstantial difference can be considered cheating. This is consistent with an argument I have also made previously. @Atrik then replies that there are so many GUI mods out there, and there are so many different opinions about what mods are cheating and which aren't, that it's better to stick with my more narrow and concrete definition of cheating, while also affirming that individual hosts should have the right to develop and enforce their own policies. Atrik also claims that it's important to consider intent (correct me if I misunderstood this part, because I likely did) when judging what mods should be allowed. @TheCJ states that these mods should be regarded as cheats, even if some hosts allow it. @Atrik makes a comment that the notion that these mods are "cheats" can have the lasting consequence of turning people away from using these tools, even if they would otherwise find them useful, and this is another good reason to be careful when calling these mods "cheat mods". This point proves effective against @TheCJ. @TheCJ claims that the sheer popularity of AutoCiv disqualifies it from being called a cheat, and uses yet another dictionary definition to support this argument. I covered this already, in my original claim that dictionary definitions aren't helpful in specific cases like this (I don't believe that AutoCiv is, or can be, a cheat; just for a different reason). @guerringuerrin comes in hot, with a variety of claims: The first point is that I misrepresented one key aspect of ProGUI: a feature that is much more sophisticated than I ever gave it credit for. I conceded and even apologized for this, but also claimed that it doesn't affect the actual core of my argument, which is that a GUI cheat mod cannot exist, even with automation. The second point is referencing my original claim that these mods have a small impact on performance, because what it takes to be good at this game is not input speed, but rather strategy. The second point is that the same can be said about revealing the map. I counter this by saying that revealing the map has its own reasons for being considered cheating, not necessarily tied to how it affects gameplay in practice. The third point is referenceing a previous point I made that these mods make you more predictable, therefore weaker, if you over-rely on them. The third point is that a player doesn't have to limit their unique style in order to gain an unfair advantage from these mods. Actually, I don't think I ever replied to this one, but I did say at one point that even when using these mods, a player must still keep track of everything going on in a match, to the same degree as other players, and if they fail to do so, then they are leaving themselves vulnerable, just like another player would, even if that is not as obviously apparent. The fourth point references my previous clarification of the two different kinds of "cheating" that exist". The fourth point is that other communities have come to the consensus that modding is cheating. I, once again, clarify that this doesn't mean we have to, and in fact, it would go against our stated design goals if we restricted the use of these mods. The fifth point mentions the habit of these types of threads for being unproductive and too personal, and affirms that we need tools (the kind of tools that, as I have argued, cannot exist) in order to promote fairness by regulating the use of these mods, and also something about a bug in the vanilla game. @real_tabasco_sauce claims that APM inevitably becomes part of the challenge in any RTS. @Atrik claims that the very opposite is true. I make another example claim by referencing the ability to change the simulation speed of a match in real-time, with the design of this feature implying that it has an effect on the difficulty. I claim that this effect, when used in moderation, only affects the need to concentrate, and think fast; it does not affect the need to type fast. @Atrik claims that I misquoted something from @guerringuerrin. I reply by clarifing the point I was trying to make. @Atrik doubles down by being the first to accuse me of making baseless assumptions. I address this by clarifying that my argument does not have anything to do with ProGUI, and I only ever used it as an example, and I have done my due dilligence to avoid sounding like an expert on ProGUI when I am not. @TheCJ steps in and says that other people should not be expected to thouroughly research ProGUI, given they may not have the time to. @TheCJ counters my original claim that modder transparency is impossible to enforce, based on a specific example of how ProGUI works, which is easy to detect based on the replay. I make the statement that I see this specific example clearly, but other mods may not work the same way, and generally, any attempts to control what software can run on a player's computer will be an uphill battle. @TheCJ forwards some other claims that were already sufficiently mentioned in this list, and mentions that @Seleucids thinks the game is already so fast that click rate begins to matter. I make the claim that this is a flaw in the gameplay and should be treated as such, therefore it is not a valid counterargument. I also think this is not what @Seleucids actually meant. @Atrik express a concern that too many misunderstandings can also repel someone from trying out mods such as ProGUI, if they get confused themselves. @guerringuerrin make the claim that this game is already so fast that APM matters. I counter this by giving a specific example that illustrates my point that I have never (personally) been restricted by APM, whereas I feel constantly restricted by my mental capacity at my current level. @guerringuerrin also becomes the second person to accuse me of making unfair assumptions and bigotry, and I address this promptly. @guerringuerrin also mentioned at this point that the definition of cheating is determined by the majority (can't really argue with that), and correctly repeats back my personal definition of cheating (something that breaks a game mechanic directly). I don't think that last part really needs to be said, but it's just for those who are going to try and say I'm cherry-picking my case here by ignoring the real arguments (I'll get to that soon). @MetaPhyZic complains about the unproductivity of this thread. I, personally, think that this thread has been very productive so far, but there are a few things that I need to address before we can move on, which is part of the reason why I'm writing this list. @guerringuerrin says that I have only been making assumptions so far, and nothing of substance has been said, and also says that I do not have the authority to discuss any of this until I have tried "real" competitive multiplayer. @wowgetoffyourcellphone makes a comment that kind of makes it sound like I'm only using this thread to rationalize my usage of ProGUI, which makes no sense because I don't even use it, and don't plan to use it for anything other than out of curiosity (because it's been brought up so much already), and because I have already stated why I am writing this thread, which is because I believe that this project is promising, but I am worried that too many people are working on a free software game design project despite not understanding the true values of free software, which has me worried about the future of the project. So, there you have it. Not really short at all, but better than nothing. This is a decently-sized thread, after all, and I think it has been productive. Now, @guerringuerrin, I personally dare you to write your own list of every assumption I have made in this thread, followed by the truth that I am missing. Don't just say that I am making baseless assumptions and walk away. I have said this multiple times before: if I am misunderstanding something, I want people to correct me, and not just call out my assumptions without any real opportunity for clarification. This way, we can move past the misunderstandings, and move on productively. Admittedly, even I am starting to get frustrated with the circular arguments and personal attacks, but I believe that my thread doesn't have to end this way. And if a subset of people are not being productive in the debate, the other productive members can just block them out and carry on. I'm going to be away for the computer for a week, so I won't be available to continue to participate in this discussion until about April. We'll just have to see what happens. All I'm saying is that I do think that this thread has been everything I wanted it to be, and I'm not ready to give up yet.

After some additional thought, I think I can say more about this one point. This is an example to help illustrate my point. Let's imagine the specific scenario of you conducting a raid, and you have no trouble keeping track of everything you need to. You hear the sound cue that your soldiers have come out of the barracks and are now gathering resources back at your base (or are heading to assist in the raid, whatever strategy you chose...). You didn't enable auto-queue because your food count fluctuates wildly based on hunting and fishing gains, rather than the steady flow of resources provided by a farm or whatever. But you do have enough resources to train another batch. Your raid units do not need constant input. They may be on an attack move to the enemy civic center, or they are trying to capture a fortress, or whatever. It's not hard to get the 3 seconds you need to press 9, press F3 (if that's appropriate), then use the scroll wheel or whatever input to select the batch size you think is best, and shift click to train the next batch. If you are constantly clicking on your raid units, that's a bad habit. I started beating the Hard Petra Bot when I realized that I could have a raid going while still focusing on my base and growing my economy, and I often win fights without even paying attention to them anymore. The fighting mechanics of 0 A.D. are simple enough to allow a more balanced distribution of your input and attention between attack, defense, and economy. Like I said, in all of my gameplay, I have never been limited by input speed. When my input is limited, it's because I can't keep track of everything. A mod like ProGUI, with its auto-trainer, might seem to help remedy that, but I am relying on a tool that only does simple logic based on pre-determined preferences, while the mechanics of 0 A.D. economy management are so complex that there will inevitably be cases where this is insufficient, especially in pro games where seconds matter more. EDIT: I know someone might say that I only assumed that the auto-trainer mechanics are too simple for the complex mechanics of the game, but that's not the point. My point is that it is (should be) so difficult to program a mod that always makes the "best" decision, that such a tool could be described as intelligent. Other people have said in this thread that the auto-trainer takes into account your current resource counts, a desired army composition (how many spears, swords, slingers, etc), and number of structures. But when a human decides on what batch size to train, they must take everything into account. Do you have reason to believe that a large army is headed your way? Better pick smaller batch sizes to make sure they aren't still training when the enemy arrives, just in case. Or maybe larger batch sizes, if you know more precisely how much time you have. Or maybe you have two split territories, and you only want units training on one of those bases. Or maybe you want unit training to be tied to your corrals, so that after each batch of livestock is slaughtered, a certain fraction of the proceeds go to training soldiers, and the rest goes to more livestock? That's a strategy that I have tried before, and I must admit it's actually not very good, especially in the early game, and is best used as a supplement to another food source. You can make the case that ProGUI can actually be set up to handle all of these cases with its automation, but I doubt it is so complex and sophisticated that it can automatically decide what is best to do, based on all of these external factors, without any coaching or configuration from the user. And I should be careful for @Atrik ; I don't mean to insult your mod, especially if I haven't even tried it. I don't think anyone was expecting ProGUI to literally be an A.I. that plays for you, and I don't think that's what you wanted either. I'm just trying to illustrate the point that I don't think these tools were meant to be used as a way to bypass the actual macro-strategy elements of the game, which are what ideally make the most impact in a solid RTS, and @Atrik has said this as well.

Not speaking from my own experience here (because I don't have any), but just going based on what other people say, about the heuristics used to determine if ProGUI is used. Yes, I do see now how it can be pretty easy to detect the usage of ProGUI based on replays. However, in general, my argument has nothing to do with ProGUI. My argument is that from a general, technical standpoint, it is impossible to be completely sure that a given player's in-game actions weren't automated, due to the nature of free software and the Internet. There may be another mod out there which works differently and has a different feature set, which is coded in such a way that it is much harder to tell the difference between that mod's behavior and human behavior using the vanilla client. That is what I mean when I say that it is impossible to prevent other people from modifying their client. I have said this once, and I will say it again: I am not making any claim based on a specific fact about ProGUI. I mention it often because everyone else is using those terms, and it's a neat example to help illustrate my point without actually making a claim based on it. I think I have made it very clear that I'm not an expert, and don't claim to be. And if you think I misunderstand something, please correct me by telling me exactly what was wrong with my claim. I admit that not everything I say will make sense, and this can lead to confusion. But making the claim that I am basing my argument on assumptions is a stretch. If it seems that way, let me know because I might have made a writing mistake and made it seem like I am making a logical derivation directly from a feature of ProGUI or other mod, but I am not. My core argument is based only on general technical details and free software ideals. The actual core of my argument is simply that I believe all mods should be allowed, because the skill curve of this game is based on strategy instead of click rate, and while some mods may try to emulate a good strategy, they will inevitably come up short, unless those tools are so complex that they can be described as artificial intelligence, and then that's a different story. Like I said, it's not that I don't use ProGUI, it's that whatever ProGUI can or can't do is not essential to my case. In truth, I am considering taking a look at it, just to see what all the fuss is about. But I still strongly believe that this game is about strategies more than click rate, so nothing I can possibly find out about ProGUI will convince me that I am playing a completely different game whenever I turn it on. In all of the time I have played in singleplayer, I have never once been limited by my ability to issue commands with my keyboard. But there have been plenty of times that I was limited by my ability to keep track of everything that was on screen. These are two different things. You can make the case that I just have yet to see pro gameplay, but even if there will come a point in which my strategies become so finely tuned and intense that I start wishing I could type faster, I believe that this is a flaw in the gameplay itself that could use improvement. I already explained in some detail what I mean by this, but in general, it's never fun to be limited by your typing speed, and while I believe that this game should be challenging, I think that this challenge should not come from how long it takes to issue commands to the computer. Yes, it can be part of the challenge to forget to check certain aspects of the game, which can make you a weaker player. What I have already said is that this is different from being unable to type in commands fast enough to do what you want. I can see, however, the scenario of using a mod that auto-manages the barracks (and by the way, I thought you were exaggerating when you first said this, but after you described it in more detail, I actually do think this is the right word now), which enables the player to focus more attention on another area of the map, is not something I am ignoring. This can, in fact, change how someone plays the game. In some cases, it can make you seem like a better player. But I will say that this doesn't make you a better player if you over-rely on it. You still have to think about the barracks, taking up valuable mental space (which is different from time spent clicking on stuff). If you don't, then you're completely relying on the tool to decide a crucial element of the game for you. Before I proceed, I will once again say that I do think that any decisions about what to train, and where, and what batch sizes, are all strategic decisions. This is because there is no "best" batch size for any given scenario, and different batch sizes will have different consequences. A larger batch size will take hold of your resources for a long time, which can cause you to stall in some cases, but in the long term this provides more efficient use of the barracks. A smaller batch size will provide faster short-term results, which can help your economy accelerate faster in the short term, but your population generally won't grow as fast in the long term. An automatic decision that always picks the "optimal" batch size based on resources isn't really taking everything into account. So, as I said, you can choose to use ProGUI, while still thinking about your training, even if you aren't actively clicking on it to make anything change. This would defeat the supposed advantage of having more concentration for something else, because even if you don't have to actively click on it, just thinking about it is different. To be good at the game, you still have to have the mental capacity to keep track of everything, even if you have a mod running that will make some of those choices for you. If you don't actively think about everything, then you risk making a suboptimal choice, or failing to realize where your base is most vulnerable. Just to be clear, this is all meant to be a single example to illustrate my point. If ProGUI had more or less capabilities than I am describing here, that wouldn't matter; I would just write a different example of the impacts of that different functionality. I shouldn't have to explain why we should all be able to agree that revealing the map in a competitive scenario is cheating. But you are probably making the point that the impact of revealing the map is about the same as using ProGUI, therefore ProGUI is no less of a cheat. I must say that this is a case that is yet to be determined. Now that I think about it, I really should try ProGUI, and measure my performance against a bot with and without ProGUI, just to see what kind of a difference it makes. I think there's enough reason to assume that a pro player will be affected less by such tools than a total noob (like probably me), so the effect on me will be greatly exaggerated, and might say something. But I must remain clear that my case has nothing to do with any specific mod or any specific example. I believe that there can be no such thing as a cheat mod, because 0 A.D. is a strategy game, and the only way to imitate the strategic thinking in an algorithm is by creating artificial intelligence, which is a totally different discussion. This isn't a mutually exclusive statement. Strategic decisions can have consequences which can lead to further strategy. So you can make a strategic decision (training a batch of 3 before a batch of 10), which can lead to another strategic decision (this means you get some wood faster so you can build more fishing boats earlier on). They are both strategic decisions. Yes, I do believe that the decision on what batch size to train is just as strategic as every other micro-decision you make in a normal match. A mod could be written with some simple logic to make a decision for you, but this game should be deep enough (and I believe that it is deep enough) that such simple logic won't be enough to truly replace human thinking and ingenuity. Thus, in order to make the most of these mods, you must still think about the decisions your mod is making for you, and their potential consequences. You save a few clicks, but as I described above, clicks don't matter; concentration does. And you must still use concentration to think about what your mod is doing, if you want to make the best possible use of it.

I'm not trying to make this personal, but I must say that I don't think I was making any assumptions or spreading misinformation. First of all, I have been extremely transparent from the beginning that I am not an expert on ProGUI, and that everything I have said is simply repeating what other people have said, and I have also stated multiple times that I am not arguing based on any particular fact about ProGUI, and I am only making the case that all mods should be allowed as long as they don't break the fog of war, which is a case that does not depend on any particular example. The only reason why I mention ProGUI so often is because it's a neat example that helps me to illustate my point, but my case actually has nothing to do with ProGUI specifically. I think it it safe to assume that a reasonable person would not take home any flawed information about ProGUI because of what I said, or use such information to help them decide whether they want to try ProGUI. I do think that some of my writing has been sloppy, as I am tired and busy these days, and frankly wouldn't even be here if I didn't feel the need to make my voice heard right now. I think that this has led to some confusion, and that's my bad. If you think I misinterpreted something or made a mistake, please let me know, and I'll correct it. Then we can resolve any misunderstandings and move on. I do think that this thread can be productive, and I do think it has been very productive so far. Don't give up just because someone got offended once. Personally, I use the Cambridge English Dictionary when need to quickly look up a word, and this is what that website has to say for the word "cheating": And here's the same for "real-time": But at the end of the day, words can change and have multiple meanings, and the meaning can be dependent on context as well. That's how language works. We need to establish a clear definition of what is cheating and what is not, and I personally don't think looking it up in a dictionary will be helpful, because these resources are oriented around very general definitions that can help someone who has never used the word "cheating" in natural language before and only recently heard about it. The argument of what should be allowed in a ranked 0 A.D. match has nothing to do with that. My point is that this can be improved by making the gameplay better. I'm not going to try to come up with an example on any situation in which I wish I could type faster in order to win, but I'll give a few examples for things that I think could be changed to make the game easier. And obviously, I wouldn't know whether or not these features are already implemented in ProGUI, just to be clear. Add a default control group number for a particular barracks, so that any units that come out of the barracks will automatically be assigned to that control group and can be selected by pressing that number on your keyboard Make it possible to set a rally point on a soldier or hero or other unit, so that units that come out will automatically come to guard/escort that unit, even if the unit has moved since the rally point was first set. I know that it's already possible to set a rally point on a boat, and units will automatically garrison in that boat even if the boat has moved, so I am saying we should extend this functionality to all units. Make it possible to set a rally point on a formation, and units that come out will automatically get in formation. This would allow frontline tactics to be so much easier to manage in some cases. Generally make it possible to assign any command (garrison, repair, capture, attack, gather, move, guard, etc.) to any unit or structure for a rally point, assuming the command makes sense. I know that it's already possible to choose between setting a rally point to garrison inside that structure, or repair that same structure depending on whether you use G or J (default keys) to assign it. Sometimes, I feel limited by having to rally my units manually in certain cases, which would require a lot of APM whereas this change would eliminate the need for all of that. This is just a handful of examples that I have come up with while playing at my current level. You may have more examples, and my point is that if there are any APM restrictions at 1x speed, then this is a problem with the gameplay that needs to be fixed. The better we make the gameplay, the less impactful these mods become, because the game is designed to have a greater emphasis on strategy as opposed to APM. The person who wins should be the person who can keep track of everything to implement an effective strategy, not the person who isn't limited by their click speed. If it is true that a GUI mod can provide a significant advantage by reducing the need for clicks, then I would consider this a flaw in the gameplay that needs to be addressed. And yes, I do think that 0 A.D. has done a decent job so far at keeping alignment with its stated goals. There's some way to go, and I believe that arguments like this should be about how we can change the gameplay to make mods less of a problem, not how we can ban the mods so that everyone must suffer the need for fast clicking. It might require more work, but it will make the game so much better in the long term.

I would be against implementing a summary statistic that shows the input rate of all players over time. I personally hold the opinion that this input rate is not a crucial part of a player's performance. Concentration and multitasking are important in any RTS, but this is different from how fast you can input commands, and is not something one can easily measure with a number. The reason I think this is because of the 0 A.D. Vision page that discusses potential "snares" that can make the game worse, and one of them is "Fastest click wins". It says the winner should be determined by strategy and intelligence, not APM. I think adding this statistic would make it seem like an official idea that clicking faster makes you a better player, which is contrary to the stated design goals of the project. In reality it's being able to keep track of everything, which is completely different and can't be easily measured in the same way. I think this would give new players a wrong idea of what it really takes to be good at the game. Please don't add this feature. It would be okay as a mod, but I wouldn't use it.

I think that it would be helpful to allow mod policies to be determed by each host for themselves, rather than forcing a single policy on everyone, since we all know that isn't going to make everyone happy. Here's how I think this should work: Using ProGUI or other tools should not be against the TOS, and should not result in a ban from the entire Wildfire Games Lobby, even if a player lied about using it but... Hosts should be empowered to implement and enforce their own policies for mod usage. For example, if @real_tabasco_sauce hosts a game and finds out that someone was trying to hide the usage of ProGUI, @real_tabasco_sauce can block that player from future games, but the offending player will still be able to play with other people, such as myself. I think that the Internet, in general, is best when people are allowed to form their separate communities with their own rules, rather than everyone being forced to agree on one policy. I think community fragmentation is a good thing, as players should be free to pursue fair and enjoyable gameplay, whatever that means for them. The Terms of Use should be primarily about regulating offensive behavior that is unambiguously harmful, such as posting links to pornography, or harassing individuals, or trying to hack the lobby or other players. Anything further than that should be the responsibility and authority of individual hosts to determine what is allowed in their games. I think we should stay true to the values of free software, and not include any kind of obfuscation to prevent people from modifying the game if they really want to. What I have seen above is that there are ways for people to confidently detect the usage of ProGUI or similar tools. That's great, and we should leave those players to use whatever means to see fit to enforce their rules, while people like Atrik and myself can choose not to enforce any mod policy, and focus on having a fun game regardless. I hope that this will allow us to stop fighting over this issue and move forward with the real problems, such as revealing the map.

@guerringuerrin was describing a system that automatically chooses what barracks to train from, and the batch sizes, and I think someone else mentioned that ProGUI will automatically send units to gather resources at certain proportions depending on the needed resources for the units you want to train, but please correct me if I'm wrong. I do think that these amount to strategic decisions. Batch sizes are a strategic choice because bigger isn't always better. If you are interested in growing your economy, then smaller batch sizes will give you more short-term gains, but larger batch sizes will result in more overall efficiency of your structures. Always choosing the largest batch size that you can isn't always the best strategic choice. This is what I mean when I say that these tools make strategic choices on your behalf. Please don't allow the temporary miscommunications to discourage you. Know that my main purpose for starting this thread is simply to make my voice known, and provide a space for meaningful argumentation. So far, I think I have been mostly successful, and I am very glad I was available to start this thread, and participate in the debate. If anyone thinks I mis-interpreted something, then please correct me. I am not perfect, and just because I didn't understand you the first time doesn't mean I am intentionally spreading misinformation.

Wow, I'm sorry. I created my own thread about a similar topic before I realized that this thread existed. But to be fair, both threads have been meaningful, and their purposes aren't exactly the same... I must say that anyone who is actually suggesting that an anticheat program be included with 0 A.D. is arguing that 0 A.D. should cease to be a free software project. You can say what you want about what kinds of mod checks should be implemented, but that's the facts. You can't stop people from writing code on their own computers, due to the nature of free software. Anticheat solutions inherently require obscurity to work, so there cannot be a free-as-in-freedom anticheat. And I find the idea of using Machine Learning to help cringeworthy, but I digress... After reading this thread in full, I am starting to think that we could use a compromise. I strongly believe that the use of ProGUI, AutoCiv, and similar mods is NOT cheating, and I have my own reasons that I won't dive into here (it's mostly free-software absolutism), but I understand that some people disagree with me, so I would be open to allowing game hosts to decide for themselves what mods to allow, and perhaps a way to see what mods are active on each client, just for the sake of convenience. Nothing super invasive, since it's truly impossible to stop the secret use of mods, but it would mainly serve as a convenience option to make sure people are on the same page, and so those who don't understand the dilemma will have their clients figure it out from them, assuming they haven't modified it for themselves. I, for one, would never discriminate based on mod usage in my games, but I am finally coming to terms with the realization that I can't convince those who take the opposite extreme. However, I do think that there is a separate problem that the full game state is necessarily stored on every client, which makes fog-of-war cheating much easier than it should be. I do believe that it is possible to fully eliminate the risk of this kind of cheating, by redesigning the network protocol so that the game state is stored away from untrusted players, and only partially synced with the clients (again, won't go into too much detail since I have my own thread for this). I think this should be discussed separately from the argument as to the long argument of whether changing the input/output system of the game constitutes changing the game itself (I believe it doesn't). That may allow us to actually accomplish something here.

I think I wasn't clear the first time, and I apologize. I think I was wrong to say this: I tried to clarify throughout the rest of the post, but ultimately I created an unnecessary contradiction, which was confusing, and I am sorry. I think it was just sloppy writing that caused my original post to be unclear. I'll edit the post so nobody else gets confused. Let me make myself extra clear as to what I was originally trying to say, as to the definiton of "real-time". Real-time strategy means that there is non-stop action, according to the 0 A.D. vision. This means you must be constantly thinking ahead while reacting quickly, and this does indeed require the ability to concentrate. If you cannot focus for an extended duration of time, this will put you at a disadvantage. What I was trying to say last time, was that this ability to concentrate is not the same thing as being able to do multiple things with one click. You can install a mod that auto-manages the barracks, but still be too tired to actually think about it, and then such a feature becomes useless to you. I believe that a large part of the game's skill curve is the ability to mentally multitask, and focus on multiple things at once. This is something different from being able to click faster. You can click faster, but be unable to concentrate. I would also like to claim that in all of the time that I have been learning to play 0 A.D., I have never once been overwhelmed by needing to click on multiple things at once. My lack of concentration manifests in the form of being unable to click on anything because I don't know what to do. There has never been a point in which my performance was reduced because I could not type fast enough to do everything that I wanted to do. So, you are making the point that these mods actually do make the attempt to make strategic choices on your behalf. This is different from a mod that merely makes it easier to do what you want. Now we are going somewhere. I have already said, in previous posts, that this game has so many diverse choices, and there is not (and should not) be "one right way" to play the game. There are so many strategies to try out, and every single action you take has a strategic meaning, from what proportions of resources to gather at any one time, to where exactly to gather those resources from (you have to think about vulnerable supply lines, and how the enemy could cut you off), and how many storehouses to build, that even if a mod attempts to make a somewhat viable choice on your behalf, there will always be an effective counter-strategy. I would also like to say that it is relatively easy to accomplish simultaneous use of all unit trainers in the vanilla GUI, while not taking your eyes of the front lines even briefly. Just put all of those structures in one control group (I usually do '9'), and then press that number quickly, hit F3, and then if you want 50% spears and 50% slingers, that only takes two clicks. The optimal batch size based on your resource counts isn't that hard either: just scroll up until the box becomes red, and you know the largest batch size that you can train (which isn't always the best strategic choice, by the way). That is a routine part of my muscle memory, and it only takes me a second or two, so someone whose computer does this for them wouldn't have a significant advantage over me, and I'm not even good player by any metric. I know you said to avoid subjective arguments such as this one, because someone else may play differently, but I'm just trying to give a real-world example to put some of the ProGUI tools into perspective. That may be true, but this game has such a depth of strategy, that any tool that automatically determines what units to train, and what resources they should gather, is not going to be able to make the "best" choice in every circumstance, unless that tool has such complex logic that it could be described as artificial intelligence. If a programmer wants to put in that much effort to design such tools "just to enable players to cheat", then let them; we need a better A.I. player than Petra Bot. Obviously, these mods will not actively stop you from playing the game how you want using the existing vanilla tools, but if you allow them to pick your economic strategy for you, they will not always pick the same strategy that you would have chosen if you had done it yourself. And if you choose to take all of your attention span off of the autonomously-managed economy, then you won't be aware of the potential tactical vulnerabilities of your supply lines, in the same way that you would be if you had carefully planned out and built them yourself. That definition from Wikipedia doesn't really help either side. And just because it was on Wikipedia doesn't mean we have to abide by it. Again, I was unclear the first time due to sloppy writing, and I apologize, but what I am really saying is that mental overload, and mechanical overload, are two totally different things. Personally, I have never experienced the latter. You said that someone who can do more things simultaneously will have an advantage. But I said that how many things I can do simultaneously isn't actually the problem, it's my ability to keep track of everything so I can make the next move based on the optimal strategy. If you install a mod that handles one or more of the components of the game, it doesn't make you a better player, or even seem like a better player beyond summary numbers. The mod will choose the simplest solution, which won't always be the best solution. Maybe a super noob who doesn't even know how to play would seem to be greatly aided by the tools that you are all describing, but that's because they don't know how to play. But the people who use these tools aren't super noobs who desperately want to feel good about themselves; they are good players who use these tools to allow them to use the same strategies they always would, but with fewer keystrokes. They will still think about where their resources are coming from, which will always take the same amount of attention, but once they have made their informed choice, they don't have to tediously implement their action. I will go ahead and say that I haven't tried ProGUI, and I don't think that matters. What ProGUI can or can't do is not essential to my argument, and I hope I am making it clear that I believe that there can be no such thing as a GUI mod that I would consider cheating, and cheating only happens when someone actually defeats a core game mechanic, like fog-of-war. However, I might actually try ProGUI sometime and share my thoughts, just for fun. But let me stress that my opinion will be unchanged by it, because I believe that good players are good not because they can click faster, but because they can think fast and see the potential strategic consequences of every decision they make, better than any mod can. Admittedly, I don't know a whole lot about Age of Empires, but I do know that the stated design goal in the 0 A.D. vision is that a good player should be good because they can think strategically, not because they can click faster than everyone else by repeatedly going back to the barracks. I believe that this necessarily means that we should allow these "cheat" mods, because if we have succeeded at our stated design goal, then the secret use of these mods should not matter any more than the secret use of better equipment, or coffee, or other metrics. The point is that we are allowed to be different. Actually, I should be careful. I, myself, said that these mods are comparable to drinking coffee, but what I really want to say is even that isn't really true. Again, I don't feel actually limited by my click rate, only my ability to keep track of everything. These tools do automate some actions, and they can make strategic choices on your behalf, but I wouldn't see that as bypassing the need for me to actually think strategically, since the choices that the computer makes for me won't always be the best choice, unless the mod is so complex that it can be compared to A.I. more than any UX mod. I believe that it is impossible to enforce such a rule without making 0 A.D. at least partially nonfree, something I gather we are not going to do any time soon. Even with our small, tight-knit community where cheaters aren't a real problem (at least according to @TheCJ), it would be a bad decision to claim that these tools should be banned, because we can't enforce that, and as the community grows, any holes in our security should become a problem. I think it would be better to at least consider reworking our networking model to fix the problem with reveal-map cheating, as I described above. Then we can think about whether we want to have a section of our community dedicated to people who actually care about the setup that other players are using. Simulation speed and reaction time One thing that I recently thought about was the fact that, when setting up a game (and even during a singleplayer game), you can change the simulation speed to be a factor of the normal speed. There are different choices, with different names such as "Relaxed (0.5x)", or "Insane (2x)". This implies that there is an additional difficulty curve to playing the game at a faster speed. I agree with this, but as I said, the difficulty curve comes from being able to think fast, not being able to type fast. I don't think I really have to explain this further than I already have above; just know for now that I do agree that real-time implies a challenge that is not shared with turn-based strategy games, and this is generally not essential to my point. Of course, there will be a point in which the game is so fast that an entire army can get defeated in the time it takes for you to reach for your mouse. This is probably why the game doesn't let you go faster than 2x for real-time play. If you were playing at 16x, then the game is so fast that most of the difficulty curve comes from being able to click fast enough, and I don't think that would be a fun or engaging experience at all. Think about if you were competing with someone in a rated 0 A.D. game at 32x game speed. What strategy would you use to get an advantage? Your strategy would probably have more to do with how you use the keyboard than how you actually play the game, at that point. Does that sound like fun to you? Just some food for though.

The 0 A.D. Vision: RTS stand for "real-time strategy". I think there are two components to this genre, the "real-time" aspect, and the "strategy" aspect. Modifying one or both of these aspects leads to a very different game: Take away the "real-time" aspect, and you get a turn-based strategy game like what you described above. Take away the "strategy" aspect, and you get a game that places more emphasis on things that aren't strategy, such as mechanics or even luck. 0 A.D. gets its identity by staying true to both aspects. If 0 A.D. were not a real-time game, then it would not be 0 A.D. at all; it would be something else entirely. This, I agree with. You are making the point that this "real-time" aspect necessarily means that there must be some mechanical challenge. You believe that this is what "real-time" always meant. I disagree with this. Real-time means that there is non-stop action. I've seen turn-based mobile games where you are paired with a friend, or even a stranger via matchmaking, in a card game, or other similar strategy game that is turn based. You input your turn (what card to draw, etc.), and then you put your phone away. A few hours later, your phone dings, and you get a notification that your partner has submitted their move, and you can move again. This is what it means when a game is not played "in real time". I believe that a game can be real-time without introducing a mechanical challenge for the players. I believe that real-time simply means that (as opposed to the former example) in a multiplayer match, all players must be continuously present for the entire duration of the match; it means nothing more than that. I didn't mean to say that. What I was really trying to say was that the non-stop action of RTS means that reaction time and attention span become important, but this is different from input speed, which should not be part of the game. I'm sorry for making this confusing; read below for an attempted clarification. Real-time makes the game more engaging by making it into something that, by definition, cannot stall. When you are playing chess, the other player may take a long time trying to determine the optimal next move, and in the worst case, this can make the game of chess feel sluggish, and therefore less exciting. This cannot happen in a real-time strategy game like 0 A.D.. Real-time makes 0 A.D. more fun by keeping you constantly engaged and on-edge, which cannot happen in a turn-based game. This is completely different from being overwhelmed by information overload. Real-time doesn't have to mean that the physical act of pressing keys or clicking with the mouse becomes part of the game itself, and the mandation of these physical actions certainly don't make 0 A.D. a better game. Being able to type faster is not the same thing as being able to think faster I would like to make the additional point that these two things are frequently getting confused to mean the same thing (I am guilty of this myself): Limited input rate, i.e. being unable to tap the correct keys quickly enough to result in the output you want Limited concetration, i.e. struggling to optically keep track of everything that is going on, and being overwhelmed by needing to consider research, population, resource counts, buildings, and tactics all at the same time. These are not the same thing. This debate is about whether using tools to make the GUI easier to use by adding new ways to interact with the game, or automating certain routine behaviors, should be considered an unfair advantage. But it is important to think about the possibility that someone uses tools to automate the training of units, or other aspects of the game, but still struggles to actually focus on everything. Auto-queue is great, but you can still forget to turn it on, or forget to turn it off. This game has so many strategic elements and choices that, I will admit, it can be challenging to focus on everything at once, and almost every recent game I have played, I had totally overlooked a crucial part of my original strategy, such as Forge research, training champions, expanding into new territory, or building stone walls for defense. Often times, I only won because I was able to pick off the computer player's army one by one, giving me a tactical advantage even if I have a much weaker economy (which I usually do). This is another part of what makes real-time strategy more engaging than if it were turn based. You must react to new information quickly, but also intelligently. You must always expect the unexpected, and think ahead while also addressing your current needs. You must be ready to change your plans on the fly. ProGUI can't do any of this for you. You have all been mentioning the classic example of ProGUI "managing your ecnonomy for you" so you are able to only think about forward tactics, while a vanilla player cannot do this, and is thus at a disadvantage. I think this is being blown out of proportion. Let me remind you of something that was in the old thread: "Other than build buildings" seems to be brushing aside what is actually a giant gap in what would otherwise be "managing the economy totally autonomously". I've seen pro players briefly mention something like a "proper build order", which I would assume means what buildings you should build, and in what order, to be able to boom the fastest. So, the fact that Petra Bot almost always builds a house first, and then a storehouse next, and then a barracks, then a field, and so on. This is their "build order". This concept is part of the strategy aspect of 0 A.D., and like all strategic elements, of the game, the correct build order is not going to be always the same, and will differ depending on the map. I'm advanced enough to know that if I find fishing spots nearby, then I need to build a dock super early, because fishing is a powerful food source that will make my early game much stronger than farming could. Same thing with hunting. A third-party mod such as ProGUI might introduce a feature that allows the mod to autonomously give out build orders to your units, which in principle, would enable players to take their mind completely off of building. But building alone is such a complex and strategic aspect of 0 A.D. gameplay, that in order to make a mod that always knows what buildings to build, where exactly to build them, and the correct order, would be so complex it borders artificial intelligence in and of itself. Also: If the mod always takes in all map information, and precisely calculates the exact best building plans for any match, then there would be no variety in its gameplay. To program such a tool would be an incredibly difficult task, as it is akin to programming an entire A.I. player for the game, and even if you succeed (as I have heard, ProGUI currently doesn't do anything like this), implementing it in rated matches would only make you a more predictable player, which makes you weaker, even if your economic score goes up in the short term. In conclusion: 0 A.D. gets its engaging challenge and competitive nature from strategy, and it gets strategy from being a complex game with rules that ensure that there is no single path to victory, and thinking ahead matters more than clicking first. If we can accomplish that, then nothing short of a machine-learning program would be able to replace the necessary analytical mindset that it takes to be successful at this game, and if such a tool started being used in the wild, wouldn't that be a completely different discussion? But for now, being able to restart your auto-queue automatically, or bind a key that allows you to select only your cavalry units with a selection box, or whatever simple functional tweaks are provided by these tools, means nothing if you aren't smart enough to understand what is going on, and think ahead, and be ready for anything. If 0 A.D. is successful, then the winner is the person with the most intelligence, not the person with the best monitor and keyboard. If the person with the most intelligence always wins, then these tools cannot be considered a way to bypass what it takes to be good at the game. And if they can't bypass the challenge of the game, then we are not doing any good by deciding for other people what mods they are allowed to use in ranked multiplayer. And if it turns out that these tools CAN be used to bypass critical aspects of the game, then I believe that is indicative of a flaw in the gameplay of 0 A.D., and should be addressed as such. Using houses as roads is a prime example of this, so please fix that, and any other bugs like it. But know that banning mods isn't going to fix stuff like that.

Personally, I see the mechanical challenge of real-time strategy games as a necessary evil. To help illustrate what I mean by this, I will share a snippet from my story in getting good at this game. When I look at my old replays to find out just how stupid I used to be when playing against the Very Easy Petra Bot (I've come a long way since then), I could make the correlation that my APM (I'm assuming this stands for "actions per minute") was lower back then (which was in large part because I spent large portions of time sitting there like I didn't know how to play, because I didn't), but I also see myself doing super cringe stuff that any decent player would immediately call out, like trying to destroy an enemy building with projectiles, or capturing a fully-garrisoned tower with only 6 units (It didn't work, and all of the units just stood there, trying to capture, until they all died, having accomplished nothing). When you play 0 A.D., you are responsible for controlling hundreds of in-game characters simultaneously, compared to the one character you control in most genres of video game. It's unavoidable that such gameplay can feel "cluttered", with many things going on at once. But, as I said, this is a necessary evil, and the game wouldn't necessarily be worse if someone made an overhaul of the GUI that suddenly reduced the need for fast typing, even if such fast typing has grown to characterize the RTS genre as a whole. Many features that have been added to the vanilla GUI have been in the direction of reducing the number of clicks required to make something happen. And that makes sense; why on earth would you introduce a new feature to the GUI that makes it harder to control? If, for the sake of argument, we say that any given feature of this kind were implemented in vanilla, making it available to all players at once, it would necessarily make the game better; that is what I mean when I say that the mechanical challenge of 0 A.D. is a necessary evil. Another example of a change that has made the game better for everyone is something I have noticed occasionally: when you order a unit to garrison inside a ship, the unit will move toward that ship, but the ship will also move close to the units to help save time, and once all units are picked up, the boat will automatically move to its original position. I think the game would just be more frustrating to control if this didn't exist. If the game didn't move the boats for me by default, but someone else decided to add in the extra time and keystrokes to manually move the boat back and forth as the units were attempting to garrison (or used a mod to do it for them), then they would have an advantage; you can say that this amounts to an increase in the learning curve and skill ceiling of 0 A.D., and it very much is in some sense, but the game is worse for it. I would still like to make the claim that this feature that you are all bringing up, the auto-restarting auto-queue, IS in fact a GUI level change. All that the mod would need to do is keep tabs on any auto-queues that were recently stopped due to insufficient resources, and then constantly check the resource counts to see if those queues can be restarted. The only precedent set is that the mod is issuing a command to the simulation all on its own, which is something that the vanilla GUI doesn't do. However, I would also like to point out that I think 0 A.D. generally keeps a poor separation between the game itself and the interaction with the game, on a technical level. I suspect (though haven't confirmed yet), that the logic that causes the boat to move back and forth to pick up units, is done entirely in the simulation code; the vanilla GUI doesn't automatically calculate the optimal piece of shoreline where the units should meet, issuing a move order in advance. But to me, whether or not this feature exists/should exist is a matter of interface usability and convenience. I think the current separation between GUI and simcode is currently based on each click done by the GUI representing one command sent to the simulation, which then does the rest of the work. In other words, the click to action ratio is 1:1 in vanilla, but mods can skew this by adding macros and automation. This is why I said before that it can be helpful to think about the interface/simulation distinction in more philosophical terms, rather than going based on the current technical implementation (which, as we should all keep in mind, is subject to change).

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: 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: (couldn't find profile page, sorry) 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?