Forums

I do not think this applies to games. There's a reason games like "Cookie Clicker" exist. It's actually fun to put in "physical effort" (in the form of clicks) and get rewarded for it (in the form of a funny number going up, or winning the game).   But why? Hannibal did not decimate the Romans at Cannae merely by coming up with a superb strategy. He defeated them by coming up with a great strategy and having the commanding skills to execute this strategy to its best effectiveness.

For formation banners given the size the polycount would be okay. Yeah some of Alexandermb's models have a way too high polycount. I mean the game supports setting three different meshes depending on the quality options. You can check the barrel actor for an example.  

For the faction to be in a future Release, match the art-style of official factions? brush-work, that is. They do appear similar to certain Rise of the East factions...

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).

GUI mods which do not change simulation are little more than tweaking graphics options in the settings panel. 0AD's exposed customisation options are rather limited, but most features of the GUI mods e.g. ModernGUI would be provided by default in other games.    ProGUI's automation features are no longer GUI mods. It makes changes to simulation. ProGUI is a combined package of a GUI mod and an autoqueue mod. People debate about the autoqueue part and not the panels.    Note that all mod-level information reveal cheats have been patched since A27. It is no longer possible to make a cheat mod (pure js level) that reveals information, because the engine commands have been insulated. If you want to cheat, you would have to edit the engine and hopefully don't get a fatal OOS.    Cheats are not as OP as you think. They are too distracting to use as your screen gets cluttered by too much information. It distracts you from your micro. Reveal map hack in A26 required you to constantly switch back and forth - less apm available for actual playing. Reveal chat baited its users into sending resources to the enemy. Seeing the trash talk in spec chat is really distracting. That's why nobody consistently used cheat methods in spite of them being so easily accessible, in A26.    In conclusion, Pure GUI mods are fine but packing in some simulation changes will be questionable. 

Update: Autociv 27.0.3 has been released: https://github.com/nanihadesuka/autociv/releases Features: Additional counters for total mobilisable military, melee, range, KD ratio A page in options to adjust update frequency and the counters that you want to see

np, thanks for your answer. Primarily use I designed it for was as formation banner like in this picture, so once for every formation. Secondary use could be for a standard bearer. There are two carnyx (the trumpets) for the gaul trumpeter, which both have around 1.500 tris, so I figured to aim for a similar polycount. Don't get what you mean with the last sentence?