Edit: Since most responses indicate very overzealous “reading between the lines” I will make this clear: this post is an analysis, it is not a suggestion. It is a framework within which meaningful discussions of an autoqueue can be had. I couldnt care less if autoqueue is implemented or not implemented. The preference expressed is extremely mild, more like an intellectual curiosity.
There is fundamentally very little difference between forcing players to have the resources up front to queue a unit vs allowing the building to automatically generate the next unit in the queue.
Put another way auto unit production is almost identical to allowing unit queueing where the cost is paid at the time a unit’s production starts rather than when the unit is entered into the queue. All that changes is when the player can encode their decision within the game: prior to being able to afford it, or after.
In fact they both have their value and drawbacks. One (payment upon queue) commits resources so the player doesn’t accidentally override themselves but is more costly. The other (payment upon production) commits to the decision at a lower priority and allows it to be overriden by lowering the resource stockpile such that the payment can’t be made, meaning production doesn’t start. But this latter option is less costly.
Allowing the player to have both options isn’t going to somehow break the game. Acting like one is inherently a better design over the other such that the game can only have one but not the other is incredibly myopic. Why?
Because you can also have any combination in between where all units up to the nth object in queue must be paid in full and after that it costs nothing to queue. Set n = 0 and that’s pay upon production, set n = max queue length-1 and that’s pay upon queue.
Personally I’d like to have n=1 as an option for auto queue. That is auto queue would force 2 units to be paid in full per building, the one being produced and the unit in queue position 1. But otherwise it automatically adds units to the queue, paying for them as they are added to the 1 place in queue. This has some problems with really expensive units like elephants vs cheap units like karambits but it’s still an improvement. It’s also mostly for curiosity. It’s the n I’d like to see start at because I think it would be very strong and thus would give a good indication of where it could be reduced to if desired.
If you’re afraid auto queue is going to break the game there almost certain exists some n where it won’t break the game. So feel free to give your own n value in the poll.
If auto queue were implemented, how much of the queue should be paid in full? N = X is equivalent to automatically maintaining the queue at length X + 1. Keep in mind the disparity for queuing expensive vs cheap units.
Too bad auto-queue is more about the considerable decrease in skill it would cause rather than ressources. Even if you make auto-queue more expensive so that it doesn’t instantly become the best option it then becomes a crutch. It would be like making a “bad aimbot” in a shooter game, it might not be OP but it would completely miss the point of the game.
You do realize that the skill required in unit production is directly proportional to the minimum length of the queue right?
It’s not hard to ensure 6 stables are producing with 5 units each. Click the hotkey for your 6 stables, spam shift q 6 times. Repeat every 2 minutes.
It’s much harder to ensure 6 stables are producing with 1 unit in queue each. That has to be done every 22 seconds, maybe more frequently.
This is why the n setting does matter. It sets the minimum queue length such that if you need to micro below this level due to budget constraints the auto queue is not a substitute.
I wasn’t playing the game anymore at that time (I stopped a year after The Conquerors was out and I resumed only a few months ago), but what were the reactions when they implemented the auto-reseed for farms/fish traps?
In the days of The Conquerors you had to put each farm in the queue manually, for fish traps I honestly don’t remember, maybe it was the same.
It doesn’t seem so different from the auto village thing. Not that I’d need that, mind you, but just talking about things in perspective.
You’re still missing the point, it’s pretty easy to forget requeuing (everyone does it at all levels). Auto-reuqueue would just remove this possibility.
It is. Seeding farms is a pretty minor aspect of the game, while creating units is among the most important things you have to do in order to play.
well, i made a thread about auto reset and how i dislike it and auto scout. it got multi hundres replies so topic was quite heated. better not open that box of pandora again
For the poll - any N that isn’t 0 makes inconsistency between this and auto seed / auto fish, which is weird and bad for players (extra stuff to learn)
Not sure if I like the auto production - I don’t see any use case before very late imp for RM games, but can be alright idk
Nope. With autoqueue you press a button and the game will always build the units for you, when you queue them you have to selcet the buildings and then produce units
It’s literally going to break the late game. By adding autoqueue you fill the gap between a player who’s able to produce units, use them, counter raids, rebuild his eco and, generally speaking, macro behind it.
It’s also going to remove the difference with people able to keep their production continued in other points of the game, like, let’s say, 3 tcs booming in castle while fighting.
It’s an rts, learn to macro and stop asking for auto-features who’d literally break the game. What’s next, villagers seeding the farms on their own because “i already decided to do it, i just can’t keep it with the pace”?
You want to macro better? Learn how to do it instead of asking for a feature that is doing it for you
Pretty minor you say?
When you have like 40-50 farmers? Maybe you say so because since The Conquerors there is some sort of farm queue (first manual, then automatic), but what happens if during a castle age push 20 farmers become idle? How much time would it take to manually reselect each farm, compared to just press a couple of hotkeys to queue vills or whatever other unit you like?
Also, auto vill is something, auto-every unit is something different. To me auto-vills is just going to help noobs, it wouldn’t change a thing in competitive games where players already have super-fast crazy APM and game awareness.
But I’m not here pushing for it, honestly, just trying to understand why a lot of people seem to be against it.
To each his own I guess.
And the shorter the queue the easier it is to forget because it occurs more often.
You seem to be viewing things categorically rather than along a spectrum. Needless to say doing so will prevent you from estimating how damaging autoque is to the game. You’ll only be able to determine a vague direction.
And this is different than queueing up a ton of e.g. villagers at a TC for no cost how exactly?
The difference is negligible. In one you click a button and the queue is automatically filled, in the other you manually fill the queue to last several minutes.
You seem to be engaged in categorical thinking rather than thinking along a spectrum. Yeah it makes the game easier. Predicting just how much it makes the game easier requires building a model which identifies the exact dimension along which the game becomes easier. That was the point of this post.
Even if everything you said was true it doesn’t negate the point that there exists an N for which the game would almost certainly not change. N =20 would basically be unusable, and the game would not change. Thus there exists some point between 0 and 20 where the effect is minimal.
One is far more optimal rhen the other.
First of all if you queued up say 7 villagers each at 3 tc that means you essentially have 600 food per tc doing nothing for you.
Meanwhile with auto queue it only takes the food as you need it. Furthermore one is you actively making a decision on how much and the other you can just brain dump and the other actively requires your involvement and if you forget about it for a minute you’re losing out on workers.
Basically one is automating rhe game in a bad way. Unless auto- queue had some drawback to it, it would be a huge upside for pretty much everyone, but at rhe expense of actively playing the game
You should have read the OP. This is a very myopic view of the parameter space available to designing an autoqueue. You can have an autoqueue such that it forces payment when a unit enters position 0 in the queue, enters position 1, enters position 2, etc.
That is instead of an autoqueue populating the production only when the building has finished production the autoqueue can populate the queue if it dips below N and N can be anywhere from 0 (the autoqueue you’re thinking of) to max -1.
As I replied to someone else earlier the usefulness of the autoqueue is directly proportional to the setting for N. With N=2 then your 3 autoqueue TCs are forcing you to float 300 food at all times minimum. For something like 6 stables making hussar that’s floating 1000 food. Since it takes a while for 1000 food to build up that could put the siege ram upgrade behind several minutes. Other interaction effects are also easy to see.
The skill necessary to emulate an autoqueue is directly proportional to N because the frequency (and thus error rate) with which production decisions have to be made is directly proportional to N.
Like I’ve said twice already this is why it’s not advised to view design decisions purely categorically. There is almost always a parameter space or spectrum along which the design can be adjusted.
I didn’t mean “minor” as in “not important at all” but as in “you don’t play the game for that”. Auto-reseed makes sense because AoE2 isn’t a farming simulator, just like you don’t have to re-task villagers after each tree because it’s not a lumberjack simulator. Meanwhile choosing to produce or not produce units, what type ect… is much more important to the gameplay, so it shouldn’t be automated with an auto-queue.
What if I think no point of the spectrum is desirable because they all miss the point of having no autoqueue?
I think the reasoning from the OP is going along the lines of “early on, you won’t use it, later on, you need to be careful about using it.”
Production buildings go literally everywhere as the game gets deep, and sometimes production at a location is more hassle than it’s worth if it’s too far away. So you’ll need to manage which buildings you want queuing and which you don’t.
That being said, the golden rule for balance and design is “don’t make change for change’s sake.” I do not see the argument for where this is not simply change for change’s sake. It’s going to require a different approach for players, it’ll be easier, largely, but there’ll be a few annoying quirks that people will have to adapt to… for what? The game doesn’t need this change.
And for the record. Change for change’s sake is always bad for the game.
I would say you miss the point of game design entirely. Game design is about balancing the desires of players to have a fun game with a game which can be balanced. Sometimes these things conflict like when you design an OP unit which is fun to use but broken to the point the balance is broken and in the long term players become disinterested. By ignoring the parameter space in anything you cut yourself off from avenues by which to reconcile the sometimes conflicting desires of a game which enjoyable (over the competition) but also balanced.
I am not so self-centered that I would attempt to cut off discussions of a parameter space just because I don’t like them. Even if I don’t like it as long as it opens up the door for making tough decisions easier that’s good design. I would respond “Well I dont like the idea, but if enough people want it you could definitely balance it that way” or something to that effect.
The bottom line is there exists an autoqueue implementation that satisfies even people who hate autoqueue, and that is the implementation that makes it useless. N= 19 would effectively be useless, locking up like 1000+ resources per autoqueued building into a full queue.
I’m not saying autoqueue should be implemented. I’m only pointing out that it is silly to claim that the idea is automatically bad. Autoqueue isn’t some boogeyman that automatically ruins the game. It has a parameter space for its design and that parameter space determines how good or bad it is.
I’m not saying the game needs the change. I’m only pointing out that most of the conversations revolving around the system couldn’t discern between an unbalanced autoqueue implementation from a balanced autoqueue implementation. Balance here being balancing skill and freeing up player time, not like game balance.
That’s why I said it’s not bad for the game in the title. The parameter space allows it to literally be useless, ergo it is not universally damaging.
I think the problem comes from calling the game a real-time strategy game, when it’s really a real-time micro-management game. Issuing an order for your town centre to continually make villagers from now on, whenever food is available, is absolutely fine as a strategic command to issue. Having to manually wait till food is available, then issue a command to make an individual villager, is micro-management, not strategy.
It’s absolutely fine to have a micro-management game where the differentiator is the speed of being able to repeatedly perform all the micro-management tasks. I think calling it a strategy game gives people an expectation that the differentiator should be something else. I have recently been playing another Mark Terrano game, Defense Grid: The Awakening (free on Epic this week), and it’s very good, much more about strategy and less about APM compared to AoE, BUT the problem is when it’s so easy to perfectly execute, anyone can look on YouTube for the best way to do it and copy it, so a leaderboard becomes a bit meaningless as you don’t know who has worked it out for themselves vs just copying someone else’s solution. To have a meaningful competitive multiplayer game, execution MUST become the differentiator, it MUST be hard to execute the strategy, as the best strategies will be known by everyone and can’t be the differentiator.
So, you can only automate more things in the game if there is still enough to do manually that the best players in the world still cannot perfectly execute, so execution can remain the differentiator.
Look at the Kohan series if you want an example of an RTS with little micro and lots of strategy. Highly questionable if that game ever’d be competitive but it’s clever mechanics makes me think it might have, even with very low skill ceiling. Still AoE 2 is more than fine as is, changing these kind of fundamental mechanics is exactly what Ensemble Studios did: AoE III (terrible solution to a non-problem).
I still manually check my grain stores to ensure that my farms/farmers have sofficient seed supply, I never use auto scout, nor would I ever want this suggestion to be added to the game. If you add it as a costly / expensive civ bonus /eco tech then perhaps it could work, but to take away a core action/aspect of the base game would be horrendous.
Why not ask for a skripted AI that trains counter units , creates ecconomy and wins the game by drushing the enemy for you?