|
Let's assume we had the power to change anything in the game.
Now, I'm not going to ask what you would change. Rather, I am interested in what changes you would classify as a "bug fix" and what changes you would classify as a "new/changed feature". The third category is "balance change". We're not interested in the third category here, so please do not propose to buff ghost or similar.
In order to classify, you need to know the definitions of the categories:
A "bug" is a behavior that:
- gives an unfair disadvantage to one player (easiest to see in mirror matchups)
- works against the original intention
- makes the game worse (yes, this is vague..)
- is not desired (yes, this is subjective...)
A "feature" is a behavior that:
- characterizes Brood War as a game
- may or may not work as originally intended
- may or may not be desired
- influences game play, potentially influences balance
Here are some examples:
Bug:
- units get stuck on ramps only on certain maps and certain positions
- valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game)
- 80 bullet sprites limit for valkyries
- 100 bullet sprites limit for all units
- burrow/unburrow drone to get infinite money (anyone got a replay for this one?)
- sometimes units freeze when chasing units that go out of vision and can only be restored by issuing the stop command
- observer over a turret will make the turret stop attacking
- shift-move worker to geyser multiple times to slide through blocked ramp even without vision
- mouse clicks are sometimes not registered while pressing buttons on the keyboard
- tank-long sunken range, where sunken gets attacked in its animation and changes target (because of priorities) without checking range. More generally: not checking range when changing attack target
Feature:
- fixed hotkeys
- bind an overlord to a lurker group and press hold to make lurkers hold their attack
- vultures can be pushed through minerals
- larva move
- reaver scarab dud
- vulture mine dud
- tank turret movement (positional imbalance)
- tank range up vs. down (positional imbalance)
- dark archon energy starting at 50 with or without the energy upgrade
One way to approach this is to classify "legal bugs" as features and "illegal bugs" as bugs according to competitive rulings. Some references to get started:
http://wiki.teamliquid.net/starcraft/Bugs#Game_Bugs
http://wiki.teamliquid.net/starcraft/Competitive_Rules#Explanation_of_Game_Bugs
http://www.teamliquid.net/forum/brood-war/514740-brood-war-exploits-tricks-glitches-please-help
But there are other bugs that cannot be actively provoked by a player (see the Valkyrie bullet sprite bug).
Can we assemble a comprehensive list of bugs versus features?
Edit: updated feature and bug list based on the input so far.
Edit2: discussing 1.16.1 patch only!
|
United States367 Posts
I think i would consider dud mines a bug, but reaver duds a feature.
I think dud mines are so infrequent (in my experience) that it doesn't affect play consistently enough to be considered a feature.
Scarab's dudding on the other hand makes reaver damage inconsistent, but their damage output is so high i think its okay, because more often than not the scarab will hit, and duds dont end games (again in my experience, of course there are some cases where a dud scarab could end a game)
|
there was a bug where you burrow and unburrow a drone and it gives you infinite money. I've seen it once on stream and once in a game vs. me
|
United Kingdom12022 Posts
valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game)
Wow I did not know this.
|
On January 18 2017 15:37 shall_burn wrote:
there was a bug where you burrow and unburrow a drone and it gives you infinite money. I've seen it once on stream and once in a game vs. me
its a hack not a bug isnt it ?
|
On January 18 2017 16:04 Qikz wrote:Show nested quote + valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game) Wow I did not know this.
You have to use your ammunition conservatively!
|
The bug that causes a unit to freeze up while microing is infuriating.
|
On January 18 2017 16:04 Qikz wrote:Show nested quote + valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game) Wow I did not know this.
Then you didn't play vs 7 AI or friends in LAN where everyone went 200/200. The valkyries just didn't shoot at all.
|
On January 18 2017 17:50 valaki wrote:Show nested quote +On January 18 2017 16:04 Qikz wrote: valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game) Wow I did not know this. Then you didn't play vs 7 AI or friends in LAN where everyone went 200/200. The valkyries just didn't shoot at all.
this same can happen with reaver scarabs
|
On January 18 2017 16:11 toriak wrote:Show nested quote +On January 18 2017 15:37 shall_burn wrote:
there was a bug where you burrow and unburrow a drone and it gives you infinite money. I've seen it once on stream and once in a game vs. me its a hack not a bug isnt it ?
The game on stream was played at Fish, and vs me at iCCup so both with anti-hack, I guess.
|
On January 18 2017 19:03 shall_burn wrote:Show nested quote +On January 18 2017 16:11 toriak wrote:On January 18 2017 15:37 shall_burn wrote:
there was a bug where you burrow and unburrow a drone and it gives you infinite money. I've seen it once on stream and once in a game vs. me its a hack not a bug isnt it ? The game on stream was played at Fish, and vs me at iCCup so both with anti-hack, I guess.
There are hacks that work even with anti-hacks 
|
Fix the sprite cap, it's what prevents Valks from being a game changer in late game TvT battles.
|
Aside from the obvious Valkyrie sprite limitation what I would consider a bug is the freezing of a unit when you give a direct attack command for a specific enemy unit and that unit gets out of range at the wrong moment. You can only free those units by pressing stop before they accept any other order. A similar bug behavior is that sometimes units just stop chasing the target but they don't get stuck. Example are marines attacking a retreating floating building or zerglings chasing an SCV.
|
I also remember stacked scvs that kill nexus, is this a bug? IIRC it's prohibited on iCCup, as well as an observer shutting a turret down
|
Bisutopia19229 Posts
On January 18 2017 13:54 ruypture wrote:
I think i would consider dud mines a bug, but reaver duds a feature.
I think dud mines are so infrequent (in my experience) that it doesn't affect play consistently enough to be considered a feature.
Scarab's dudding on the other hand makes reaver damage inconsistent, but their damage output is so high i think its okay, because more often than not the scarab will hit, and duds dont end games (again in my experience, of course there are some cases where a dud scarab could end a game)
Spider mine duds are definitely in the feature column. If you out run a mine long enough for it to dud out then you deserve the credit same as reaver scarabs. I think it's nitpicky to put them in separate categories.
Observer on a turret is a bug as that is not legal in most tournaments.
|
France1919 Posts
Me reading the title, "Oh, who are these 2 players I never heard about?!"
;;
|
On January 18 2017 22:07 HaN- wrote:
Me reading the title, "Oh, who are these 2 players I never heard about?!"
;;
same lol 
|
Valkiries sprite bug is a bug but fixing it would have completely shift tvt meta as mass wraith would not be viable anymore. Mb would also make them viable vs mass carier at some point. :p
|
What about the lightning fast sprints some units do when they repeatedly bump into each other due to less than optimal pathing.
I've once lost 2 lurkers like this because they ran into the enemies troops when I didn't want them to. I consider this a bug, albeit it's a funny one.
|
On January 19 2017 00:26 kogeT wrote:
Valkiries sprite bug is a bug but fixing it would have completely shift tvt meta as mass wraith would not be viable anymore. Mb would also make them viable vs mass carier at some point. :p
the problem with this one is a very low cap on total bullets in the game (100). This actually holds for all units. IMO it makes no sense to keep such a rule because it adds a lot of complexity to the game without adding value in terms of higher skill required from the players.
the Valkyrie is a special case and more notable because the sprite cap is even lower at 80.
source: source (haha). tscmoo's source.
|
On January 18 2017 22:16 Zera wrote:Show nested quote +On January 18 2017 22:07 HaN- wrote:
Me reading the title, "Oh, who are these 2 players I never heard about?!"
;; same lol
sorry about that  maybe a moderator could change the topic title into "bug or feature?"
|
United States367 Posts
On January 18 2017 22:01 BisuDagger wrote:Show nested quote +On January 18 2017 13:54 ruypture wrote:
I think i would consider dud mines a bug, but reaver duds a feature.
I think dud mines are so infrequent (in my experience) that it doesn't affect play consistently enough to be considered a feature.
Scarab's dudding on the other hand makes reaver damage inconsistent, but their damage output is so high i think its okay, because more often than not the scarab will hit, and duds dont end games (again in my experience, of course there are some cases where a dud scarab could end a game) If you out run a mine long enough for it to dud out Observer on a turret is a bug as that is not legal in most tournaments.
Ah, I didn't know that out running the mine can cause it to dud, I assumed it was relatively random.
|
I don't know if it's based on distance or time though, BisuDagger please clarify.
But I CAN confirm that he's right.
|
I think it's distance, if you consider the mine in that koget-dienmax game on mist kept going forever lol
|
Reaver scarab duds are certainly not bugs, they are pretty consistent. Scarabs have timed life and ground collision. If they can not reach their target in time (because they are blocked by other units, minerals, etc) then they simply disappear. Thats a very simple concept.
|
Bisutopia19229 Posts
|
On January 18 2017 17:47 ZeroChrome wrote:
The bug that causes a unit to freeze up while microing is infuriating.
Change nothing but this. Dumb goons being stuck for no reason when microing against 2 fact made me rage quit so many times ;;
|
Netherlands4985 Posts
On January 19 2017 03:40 endy wrote:Show nested quote +On January 18 2017 17:47 ZeroChrome wrote:
The bug that causes a unit to freeze up while microing is infuriating. Change nothing but this. Dumb goons being stuck for no reason when microing against 2 fact made me rage quit so many times ;;
Yes! However I really like the feature where you can attack an enemy unit from behind a wall (and move out of range if necessary) to make them stop attacking your wall.
Also please fix the super dumb reaver walking into range of static defense ALL the fucking time, that is as infuriating and has been more game changing than I can count.
|
It's the same thing with guardians, they always move in turret range.
|
Netherlands4985 Posts
Make adding units to an existing hotkey group with shift instant. I don't wanna double tap my ctrl group every god damn time to verify my earlier command.
|
Netherlands4985 Posts
On January 19 2017 04:01 B-royal wrote:
It's the same thing with guardians, they always move in turret range.
True, but I reckon not as bad as the reaver.
|
Bisutopia19229 Posts
You can stack guardians without an overlord if you A-click on one of your guardians in the selected group. They will move stacked too at this point.
edit: You could probably do this with other air units, but guardians are the one unit that can't actually damage air which is why this trick only applies to them.
|
But that's the thing, these would all change the game... The silly unit freezing thing would render the wall micro less viable, a-moving stuff without them suiciding would make you need to baby sit them less, etc... But yeah, that goons freezing thing is super silly vs. fd and stuff. I also recall some ramps sucking in units like a black hole, althought that is probably less game engine and more map feature?
|
problem is, the issues listed there don't all apply to 1.16.1 and I'm also interested in the "bug or feature" question of the glitches that still do apply.
|
On January 18 2017 17:50 valaki wrote:Show nested quote +On January 18 2017 16:04 Qikz wrote: valkyrie does not deal damage once the maximum number of bullets in the game has been reached (e.g. due to several carriers in the game) Wow I did not know this. Then you didn't play vs 7 AI or friends in LAN where everyone went 200/200. The valkyries just didn't shoot at all.
Most of my friends that I played with never really built Valkyries anyways.
|
United States11390 Posts
Stork used to do the obs over turret thing a lot as it wasnt banned in Korean leagues.
There was a wcg game where he did it and got in trouble for it but he was really confused as it had always been legal for him elsewhere.
|
My vote is on not changing anything.
|
On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything.
why keep the "unit stuck on ramp, but only for one player on one side of the map" bug?
or a bug where the lurker isn't able to burrow anymore?
I realize there is a thin line and there might be border cases. This thread is to explore them.
|
On January 23 2017 03:10 imp42 wrote:why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them.
Because that is a map-specific bug; it would be better just to change the map than change the game, no? I have nothing against changing that ramp on FS at 12, for example. Maps are flexible, the game should remain static imo.
Lurker not being able to burrow anymore - I haven't seen that one, but I'm willing to bet the Lurker doesn't burrow anymore because of something the human player did with the Lurker?
|
oh god, not another balance thread ^^
|
On January 23 2017 03:13 Jealous wrote:Show nested quote +On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Because that is a map-specific bug; it would be better just to change the map than change the game, no? I have nothing against changing that ramp on FS at 12, for example. Maps are flexible, the game should remain static imo. Lurker not being able to burrow anymore - I haven't seen that one, but I'm willing to bet the Lurker doesn't burrow anymore because of something the human player did with the Lurker?
Yes, you're right about fixing map rather than game.
Probably the lurker issue is caused by previous commands too, as you suggest.
What's your take on the Valkyrie bullet sprite limit?
|
I would try the option of raising the spire limit. Doing away with it all together may change the game too much (destroy carrier play)?
|
in a weird way i kinda think the valk sprite bug is a good thing, i mean if u had 10+ valks without freezing, wouldnt they just completely dominate the air in tvz and tvt?
|
On January 23 2017 08:53 imp42 wrote:Show nested quote +On January 23 2017 03:13 Jealous wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Because that is a map-specific bug; it would be better just to change the map than change the game, no? I have nothing against changing that ramp on FS at 12, for example. Maps are flexible, the game should remain static imo. Lurker not being able to burrow anymore - I haven't seen that one, but I'm willing to bet the Lurker doesn't burrow anymore because of something the human player did with the Lurker? Yes, you're right about fixing map rather than game. Probably the lurker issue is caused by previous commands too, as you suggest. What's your take on the Valkyrie bullet sprite limit?
I think that changing it would affect balance, so I am against it.
|
1. Reaver attack bug
We all know that reavers have a tendency to walk into the attacking direction if you just use the attack command. I have been told that this tends to happen at certain directions/angles. Is anyone able to explain/confirm that. If it is directional then I think it should be classified as a bug whereas if it just happens generally then I guess you can consider that as a feature.
2. Siege tanks directions
I have read a post by scan that there are some directional advantages in the ranges of siege tank (can't find the thread on top of my head). I am not sure if that applies to other units but obviously this would impact siege tanks the most. I am neither a high level player nor a terran player myself so I am not sure how much implication it has in pro-level TVT. Again if the above is true that I would classify it as a bug. (maybe a minor one but still..)
|
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC.
|
Croatia9497 Posts
On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC.
That was most definitely an intended feature in BW.
Its effects on the evolution of BW's strategy, however, were probably unintended.
|
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5.
|
On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5.
But that's essential feature in PvT when you are doing shuttle reaver plays.
|
On January 23 2017 22:20 Zera wrote:Show nested quote +On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5. But that's essential feature in PvT when you are doing shuttle reaver plays.
Still unfair though, especially in regard to starting positions. They could make it so that tanks that are facing the right way have a tiny hidden delay before firing that corresponds to tanks that are facing the wrong way. Would barely be noticeable and it would make it fair. And allow for reaver shuttle in PvT.
|
On January 23 2017 23:02 Jae Zedong wrote:Show nested quote +On January 23 2017 22:20 Zera wrote:On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5. But that's essential feature in PvT when you are doing shuttle reaver plays. Still unfair though, especially in regard to starting positions. They could make it so that tanks that are facing the right way have a tiny hidden delay before firing that corresponds to tanks that are facing the wrong way. Would barely be noticeable and it would make it fair. And allow for reaver shuttle in PvT.
Or maybe we can accept that sometimes positional play is a part of the game and players should adapt their play accordingly? Protoss already can't take their natural 3rd on FS with a clockwise Terran, and now you want the Tank turrets to be more balanced? Come on fam.
|
On January 24 2017 14:13 Jealous wrote:Show nested quote +On January 23 2017 23:02 Jae Zedong wrote:On January 23 2017 22:20 Zera wrote:On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5. But that's essential feature in PvT when you are doing shuttle reaver plays. Still unfair though, especially in regard to starting positions. They could make it so that tanks that are facing the right way have a tiny hidden delay before firing that corresponds to tanks that are facing the wrong way. Would barely be noticeable and it would make it fair. And allow for reaver shuttle in PvT. Or maybe we can accept that sometimes positional play is a part of the game and players should adapt their play accordingly? Protoss already can't take their natural 3rd on FS with a clockwise Terran, and now you want the Tank turrets to be more balanced? Come on fam.
Or maybe we can accept that random starting positions shouldn't have a large impact on unit behaviour? A terran who spawns at 5 on FS will have an unfair advantage as his tanks will face the right direction the entire game. If we combine all the added turn delays for a terran who spawned at 11 during a long match, I'm sure they could be counted in seconds. My change wouldn't reduce positional play at all. And I'm not sure why you're martyring for Protoss, as my change would effectively be a tiny nerf to siege tanks.
|
On January 24 2017 17:33 Jae Zedong wrote:Show nested quote +On January 24 2017 14:13 Jealous wrote:On January 23 2017 23:02 Jae Zedong wrote:On January 23 2017 22:20 Zera wrote:On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5. But that's essential feature in PvT when you are doing shuttle reaver plays. Still unfair though, especially in regard to starting positions. They could make it so that tanks that are facing the right way have a tiny hidden delay before firing that corresponds to tanks that are facing the wrong way. Would barely be noticeable and it would make it fair. And allow for reaver shuttle in PvT. Or maybe we can accept that sometimes positional play is a part of the game and players should adapt their play accordingly? Protoss already can't take their natural 3rd on FS with a clockwise Terran, and now you want the Tank turrets to be more balanced? Come on fam. Or maybe we can accept that random starting positions shouldn't have a large impact on unit behaviour? A terran who spawns at 5 on FS will have an unfair advantage as his tanks will face the right direction the entire game. If we combine all the added turn delays for a terran who spawned at 11 during a long match, I'm sure they could be counted in seconds. My change wouldn't reduce positional play at all. And I'm not sure why you're martyring for Protoss, as my change would effectively be a tiny nerf to siege tanks.
Because it does not matter in a larger picture. TvTs are not lost or won because tanks turrets took 0.1s to turn. This is just nitpicking.
|
Are you for real right now? Check the OP:
Let's assume we had the power to change anything in the game.
A "feature" is a behavior that:
- characterizes Brood War as a game
- may or may not work as originally intended
- may or may not be desired
- influences game play, potentially influences balance
The point of this thread is literally to list minor bugs and features that may or may not influence balance. And turret delay clearly has the potential to affect balance. If this thread had been titled LIST MAJOR FLAWS IN BROOD WAR, I wouldn't have posted it (and I don't believe there are any major flaws). I simply adhered to the rules of the thread.
Turret delay is clearly something that affects the game slightly and pros are aware of it. Will it decide a TvT? Maybe, maybe not. But we cannot be sure either way. And it does affect TvP as well.
|
On January 24 2017 19:03 Jae Zedong wrote:Are you for real right now? Check the OP: Show nested quote +Let's assume we had the power to change anything in the game.
A "feature" is a behavior that:
- characterizes Brood War as a game
- may or may not work as originally intended
- may or may not be desired
- influences game play, potentially influences balance The point of this thread is literally to list minor bugs and features that may or may not influence balance. And turret delay clearly has the potential to affect balance. If this thread had been titled LIST MAJOR FLAWS IN BROOD WAR, I wouldn't have posted it (and I don't believe there are any major flaws). I simply adhered to the rules of the thread. Turret delay is clearly something that affects the game slightly and pros are aware of it. Will it decide a TvT? Maybe, maybe not. But we cannot be sure either way. And it does affect TvP as well.
I still can not see the point, why would you want to change it but let it be
|
On January 23 2017 20:23 2Pacalypse- wrote:Show nested quote +On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC. [Air-unit-stacking] was most definitely an intended feature in BW.
How do we know that, though? Didn't air-unit-stacking not even become a thing until several years after BW came out? Liquipedia has it being discovered by Shark around 2006, with JulyZerg perfecting it soon afterwards.
Seems more like an unintended feature that just happened to work out well.
|
I doubt the air stacking was intended, and personally like I said some times I don't like it and I suspect that it led to fixating the early-midgame in Z matchups around it being used with mutas. It's a reason why archons are ineffective against mutalisks as an early counter, and I suspect it is one reason why 1 base openings in PvZ give a disadvantage to P : the switch to "only-FE" plays in PvZ did happen after discovering this exploit, and in my own experience it is true that needing to go corsair and then being so pressured to make more corsairs even not knowing the number of mutas because you can't counter effectively with archon or goons is an important weakness of 1base openings. It does weaken canons as well. Basically when you open 1 base as P, the early tech options and your accuracy with them are what can produce an advantage, but you are pulled into making dangerous gambles if you can't afford to defend mutas with an archon or goons so that you end up making corsairs if you are blind at all for a while about what Z produced ; now these are useless against hydras or lurks and you can lose your opening. So you play FE. Before I think you'd see Ps going strats such as zealot+archon or goons or a reaver on one base in variations allowing you to take your nat in different ways. And the repetition of muta openings vs T.
However I'm not really sure what "just removing it" would do to the game since I have been reading Z say that it is hard to beat terrans who micro well even with this. But I would sure like to see it. For the sake of strategic options in the early game, it is pretty important that the corsair is not your only option early on as P against Z, and making more corsairs the (almost) only followup if Z makes more mutalisks. And in ZvT, it was more fun to watch (or play..? I have played few) when mutalisks openings were not done most games.
|
^ But air-unit stacking has become part of the game over the past decade.
I think there'd be quite an uproar if it got taken out.
|
Croatia9497 Posts
On January 24 2017 21:17 [[Starlight]] wrote:Show nested quote +On January 23 2017 20:23 2Pacalypse- wrote:On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC. [Air-unit-stacking] was most definitely an intended feature in BW. How do we know that, though? Didn't air-unit-stacking not even become a thing until several years after BW came out? Liquipedia has it being discovered by Shark around 2006, with JulyZerg perfecting it soon afterwards. Seems more like an unintended feature that just happened to work out well.
We know that by reading the BW's code. Air-unit-stacking is the same thing as ground-unit stacking. BW's units keep the formation as long as they're closer to each other than some set distance, and when they get further apart than that distance, they converge to one location. Also known as  Magic Boxes. This is a very intended feature in BW's engine since the developers even went to trouble of making that distance different for ground and air units.
But as I said, the effect that these features had on BW's strategy were probably unforeseen by developers, and indeed, by players themselves for quite some time. This doesn't make the initial decision to put these mechanics into the game any less intended though. This is the beauty of BW after all.
|
I had this so much as of late and it's so annoying.
When an scv stands somewhere and you order him to build a depot, and you place this depot on top of that scv, it won't move a bit. You have to move that scv and then re-order him to build the depot, otherwise it's "stuck" and won't do a thing.
It's definitely a bug
|
On January 24 2017 17:33 Jae Zedong wrote:Show nested quote +On January 24 2017 14:13 Jealous wrote:On January 23 2017 23:02 Jae Zedong wrote:On January 23 2017 22:20 Zera wrote:On January 23 2017 21:49 Jae Zedong wrote:
Unfair feature:
Siege Tanks take different amounts of time to start firing depending on which direction they're facing. If an enemy moves into the range of a siege tank that's facing the "wrong" direction, the turret must turn around before firing. This is the only unit I know of that has a noticable turn delay.
This could potentially be game deciding, especially in TvT with starting positions 11 and 5. But that's essential feature in PvT when you are doing shuttle reaver plays. Still unfair though, especially in regard to starting positions. They could make it so that tanks that are facing the right way have a tiny hidden delay before firing that corresponds to tanks that are facing the wrong way. Would barely be noticeable and it would make it fair. And allow for reaver shuttle in PvT. Or maybe we can accept that sometimes positional play is a part of the game and players should adapt their play accordingly? Protoss already can't take their natural 3rd on FS with a clockwise Terran, and now you want the Tank turrets to be more balanced? Come on fam. Or maybe we can accept that random starting positions shouldn't have a large impact on unit behaviour? A terran who spawns at 5 on FS will have an unfair advantage as his tanks will face the right direction the entire game. If we combine all the added turn delays for a terran who spawned at 11 during a long match, I'm sure they could be counted in seconds. My change wouldn't reduce positional play at all. And I'm not sure why you're martyring for Protoss, as my change would effectively be a tiny nerf to siege tanks.
No. Positional play is part of what makes BW have such an incredible replay factor.
Trust me, I 100% know where you're coming from. I actually made the same argument about seconds gained or lost based on turret rotation while watching Sea vs. Best with my friend when we were discussing Demian spawns and which set of spawns would favor Protoss and which would favor Terran. But just because it exists doesn't mean that it is necessarily a bad thing. It's a feature of the game, in my book. You eliminate that, and you eliminate the need for such a discussion in the first place among fans, you eliminate an element of depth from the players' standpoint. It's another thing that the good player considers which the noob may ignore. It's something to consider when constructing your game plan, whether you are the Terran or the opponent.
Almost all units have turning animations, which is why a good Protoss will wall their ramp with a Zealot facing outwards and not inwards (the last move you have to send to the Zealot before hold position has to be outwards), or why Zergling walls in ZvZ on ramp or in natural should follow the same rule. If you're going to eliminate tank rotation, argue to eliminate all of it. I'd still not agree with you, though.
If you're going to complain about tank turret rotation, why not complain about the fact that tanks have a longer range upwards than downwards? That for sure impacts TvT pushing and line-breaking. However, I've yet to hear or see a single good player bitch about that.
|
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug"
|
On January 23 2017 03:10 imp42 wrote:why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them.
Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs.
Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out).
Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own.
So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed.
And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay).
So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues.
My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion:
- any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways).
|
On January 25 2017 03:54 imp42 wrote:
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug"
I personally don't see why anybody should accept these things as part of the game. Why is it desirable to have it?
|
Conceptually, the difference between a bug and feature is enjoyment. Basically, does it make the game more fun, as thats the only thing that ultimately matters -- even balance is only to serve enjoyment. That said, I cant actually think of any explicit bugs in broodwar besides graphical glitches, theres funky tricks like muta stacking or permanently invisible drones, but they dont actually detract from the game at all. In that sense, Broodwar is bugless.
edit; Hell I would even take the 'buggy' ai pathing over one thats better, as I think the impact of having to micro manage your units is a net boon to my experience as a player, even if I have honestly experienced blood curdling rage just from trying to get dragoons down or up a ramp.
|
On January 25 2017 04:53 The_Red_Viper wrote:Show nested quote +On January 25 2017 03:54 imp42 wrote:
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug" I personally don't see why anybody should accept these things as part of the game. Why is it desirable to have it?
Simply because we cannot attach add-ons at different sides of the main building. The unit spawning location could probably be implemented to follow the rally point similar to sc2, but changing the add-on behavior would be a major redesign. You would have to be able to choose on which side you want it to be constructed and you would have to be able to attach an add-on from both sides. It would require new graphics, etc.
|
On January 25 2017 05:19 imp42 wrote:Show nested quote +On January 25 2017 04:53 The_Red_Viper wrote:On January 25 2017 03:54 imp42 wrote:
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug" I personally don't see why anybody should accept these things as part of the game. Why is it desirable to have it? Simply because we cannot attach add-ons at different sides of the main building. The unit spawning location could probably be implemented to follow the rally point similar to sc2, but changing the add-on behavior would be a major redesign. You would have to be able to choose on which side you want it to be constructed and you would have to be able to attach an add-on from both sides. It would require new graphics, etc.
Oh sure it's probably not worth it for you guys, i was mostly thinking about it in general. I feel like these things don't add anything desirable to the game, at least nothing i am aware of right now.
|
On January 25 2017 04:34 Freakling wrote:Show nested quote +On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways).
When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp.
regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually.
|
On January 25 2017 05:00 Dazed_Spy wrote:
Conceptually, the difference between a bug and feature is enjoyment. Basically, does it make the game more fun, as thats the only thing that ultimately matters -- even balance is only to serve enjoyment. That said, I cant actually think of any explicit bugs in broodwar besides graphical glitches, theres funky tricks like muta stacking or permanently invisible drones, but they dont actually detract from the game at all. In that sense, Broodwar is bugless.
edit; Hell I would even take the 'buggy' ai pathing over one thats better, as I think the impact of having to micro manage your units is a net boon to my experience as a player, even if I have honestly experienced blood curdling rage just from trying to get dragoons down or up a ramp.
Another conceptual difference is predictability.
If you have the means to control a specific behavior it's easier to accept it as a feature. Even the random misses from low to high ground are predictable in a way (even though I'm not a fan of such random elements - I would prefer every x-th shot to fail consistently).
But what if every now and then your lurker fails to burrow even though you gave the command to do so? or the behavior of your unit depends on how many other units happen to be on the map?
IIRC there's also a bug wrongly defining the order in which interceptors leave the carrier because it reads some value from an invalid pointer. This one probably has close to 0 impact on game play and therefore enjoyment, yet easily classifies as a bug.
Also your dragoon example contradicts the enjoyment argument a bit 
|
On January 25 2017 05:22 The_Red_Viper wrote:Show nested quote +On January 25 2017 05:19 imp42 wrote:On January 25 2017 04:53 The_Red_Viper wrote:On January 25 2017 03:54 imp42 wrote:
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug" I personally don't see why anybody should accept these things as part of the game. Why is it desirable to have it? Simply because we cannot attach add-ons at different sides of the main building. The unit spawning location could probably be implemented to follow the rally point similar to sc2, but changing the add-on behavior would be a major redesign. You would have to be able to choose on which side you want it to be constructed and you would have to be able to attach an add-on from both sides. It would require new graphics, etc. Oh sure it's probably not worth it for you guys, i was mostly thinking about it in general. I feel like these things don't add anything desirable to the game, at least nothing i am aware of right now.
I think these little "imbalances" are really small too, so even if they may translate into a slight advantage/disadvantage in some games it is small enough and rare enough that it is totally fine the way it is, besides for ex tank turret turn time is not unimportant to give them a slight reduce in effectiveness if they need to turn and you can predict it and avoid their fire sometimes.. this is one of the strongest unit in the game already
oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say
The black hole thing is crazy bad if it happens but it is so rare! I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^
|
Oh I got one bug I would like fixed, is when someone use the exploit/bug where you can shift+move a worker using a empty geiser click many times or smtg and then move through units @enemy ramp even when you have no vision of their minerals. That's a scouting cheat can be pretty game changer and it's annoying when it happens and you have to report etc^^
yeah and the goon stuck
|
On January 25 2017 06:02 ProMeTheus112 wrote:Show nested quote +On January 25 2017 05:22 The_Red_Viper wrote:On January 25 2017 05:19 imp42 wrote:On January 25 2017 04:53 The_Red_Viper wrote:On January 25 2017 03:54 imp42 wrote:
the problem I see with discussions about starting positions is that positional imbalance is inherent to the game.
Even if we fixed things like tank turrets or tank range (fixes that 1. I have a neutral opinion about 2. I don't feel entitled to voice an opinion about in case we considered such a fix) there is still the add-on imbalance and the unit spawn imbalance.
add-on imbalance:
add-on placement to the right of the building determines how exposed add-ons are and whether e.g. the Comsat station interferes with mining SCVs or not.
unit spawn imbalance: units always spawning bottom left affects distance to minerals for workers or whether a unit spawns inside or outside a wall.
We probably all agree that these two imbalances are not going to be fixed and are just part of the game.
To me it's also clear that we can assign positional imbalances like "tank turret" to the "feature" section rather than "bug" I personally don't see why anybody should accept these things as part of the game. Why is it desirable to have it? Simply because we cannot attach add-ons at different sides of the main building. The unit spawning location could probably be implemented to follow the rally point similar to sc2, but changing the add-on behavior would be a major redesign. You would have to be able to choose on which side you want it to be constructed and you would have to be able to attach an add-on from both sides. It would require new graphics, etc. Oh sure it's probably not worth it for you guys, i was mostly thinking about it in general. I feel like these things don't add anything desirable to the game, at least nothing i am aware of right now. I think these little "imbalances" are really small too, so even if they may translate into a slight advantage/disadvantage in some games it is small enough and rare enough that it is totally fine the way it is, besides for ex tank turret turn time is not unimportant to give them a slight reduce in effectiveness if they need to turn and you can predict it.. this is one of the strongest unit in the game already oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say The black hole thing is crazy bad if it happens but it is so rare! I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^
Nah i am only talking about units always spawning below and addon issues here.
|
remember when T could crush interceptors by landing buildings? -____-
|
On January 24 2017 23:06 2Pacalypse- wrote:Show nested quote +On January 24 2017 21:17 [[Starlight]] wrote:On January 23 2017 20:23 2Pacalypse- wrote:On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC. [Air-unit-stacking] was most definitely an intended feature in BW. How do we know that, though? Didn't air-unit-stacking not even become a thing until several years after BW came out? Liquipedia has it being discovered by Shark around 2006, with JulyZerg perfecting it soon afterwards. Seems more like an unintended feature that just happened to work out well. We know that by reading the BW's code. Air-unit-stacking is the same thing as ground-unit stacking.
No, it kinda isn't, not strategically. Because ground units can't stack on top of one another... air units can. And there are obvious/significant gameplay implications for air units being able to occupy more-or-less the same space, it's inherently why air-unit-stacking is strong/an advantage.
BW's units keep the formation as long as they're closer to each other than some set distance, and when they get further apart than that distance, they converge to one location. Also known as Magic Boxes. This is a very intended feature in BW's engine since the developers even went to trouble of making that distance different for ground and air units. But as I said, the effect that these features had on BW's strategy were probably unforeseen by developers, and indeed, by players themselves for quite some time. This doesn't make the initial decision to put these mechanics into the game any less intended though. This is the beauty of BW after all.
You seem to be agreeing that air-unit-stacking was indeed an unforeseen feature. Which, whether or not it was, certainly has worked out to be that in practice. No one was really using it until eight years after BW's release.
We seem to be on the same page, some nitpicking aside.
|
I think it would be reasonable if a sieged tank's cannon pointed the same way as when it was in tank mode. Letting the turret instantly turn around or introducing some convoluted mechanic to make it "fair" is the wrong way to go.
|
On January 25 2017 05:55 imp42 wrote:Show nested quote +On January 25 2017 05:00 Dazed_Spy wrote:
Conceptually, the difference between a bug and feature is enjoyment. Basically, does it make the game more fun, as thats the only thing that ultimately matters -- even balance is only to serve enjoyment. That said, I cant actually think of any explicit bugs in broodwar besides graphical glitches, theres funky tricks like muta stacking or permanently invisible drones, but they dont actually detract from the game at all. In that sense, Broodwar is bugless.
edit; Hell I would even take the 'buggy' ai pathing over one thats better, as I think the impact of having to micro manage your units is a net boon to my experience as a player, even if I have honestly experienced blood curdling rage just from trying to get dragoons down or up a ramp. Another conceptual difference is predictability. If you have the means to control a specific behavior it's easier to accept it as a feature. Even the random misses from low to high ground are predictable in a way (even though I'm not a fan of such random elements - I would prefer every x-th shot to fail consistently). But what if every now and then your lurker fails to burrow even though you gave the command to do so? or the behavior of your unit depends on how many other units happen to be on the map? IIRC there's also a bug wrongly defining the order in which interceptors leave the carrier because it reads some value from an invalid pointer. This one probably has close to 0 impact on game play and therefore enjoyment, yet easily classifies as a bug. Also your dragoon example contradicts the enjoyment argument a bit Actually, you know what, you are right. There are a few unit glitches that do nothing for the game, like hydras just refusing to move for no reason, until you stop command and move again. But overall bad ui makes broodwar better, as it makes it harder to pull things off. The difficulty of even moving your army = allows for harassment, come backs from behind yada yada. Thats why I said its worth it in the end. You are right that predictability is an important factor, and so for the instances where a unit literally just stops working, and there are a few, those are bugs. But shitty UI brings something to the game.
|
On January 25 2017 05:35 imp42 wrote:Show nested quote +On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties.
On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0.
The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug).
Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran.
On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it...
|
Croatia9497 Posts
On January 25 2017 07:34 [[Starlight]] wrote:Show nested quote +On January 24 2017 23:06 2Pacalypse- wrote:On January 24 2017 21:17 [[Starlight]] wrote:On January 23 2017 20:23 2Pacalypse- wrote:On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC. [Air-unit-stacking] was most definitely an intended feature in BW. How do we know that, though? Didn't air-unit-stacking not even become a thing until several years after BW came out? Liquipedia has it being discovered by Shark around 2006, with JulyZerg perfecting it soon afterwards. Seems more like an unintended feature that just happened to work out well. We know that by reading the BW's code. Air-unit-stacking is the same thing as ground-unit stacking. No, it kinda isn't, not strategically. Because ground units can't stack on top of one another... air units can. And there are obvious/significant gameplay implications for air units being able to occupy more-or-less the same space, it's inherently why air-unit-stacking is strong/an advantage. Show nested quote +BW's units keep the formation as long as they're closer to each other than some set distance, and when they get further apart than that distance, they converge to one location. Also known as Magic Boxes. This is a very intended feature in BW's engine since the developers even went to trouble of making that distance different for ground and air units. But as I said, the effect that these features had on BW's strategy were probably unforeseen by developers, and indeed, by players themselves for quite some time. This doesn't make the initial decision to put these mechanics into the game any less intended though. This is the beauty of BW after all. You seem to be agreeing that air-unit-stacking was indeed an unforeseen feature. Which, whether or not it was, certainly has worked out to be that in practice. No one was really using it until eight years after BW's release. We seem to be on the same page, some nitpicking aside.
I'm not really sure how else to say it to make it more clear, but air-unit-stacking was *not* unforeseen feature. It was most definitely made possible on purpose by developers by adding magic boxes mechanics and removing collision boxes of air units. They could've just as easily make the air-unit-stacking impossible by, for example, removing magic boxes mechanics for air units. Instead they increased the size of the magic box for air units.
Sure, the effects of these mechanics and how were they used strategically in game by players was unforeseen by developers, but that doesn't mean it was any less intended by developers to make it possible. Seriously, I just hate it when people act like everything in BW is the consequence of some happy accident. Developers added a lot of little things into the game engine on *purpose*, even if they couldn't predict on how each of those features would be used by players.
|
There are very few instances from the OP that I would consider bug fixes. Really just the units stuck on ramp bug. I consider everything else a feature that can and should be adapted to by the player, even if it causes positional imbalance. Most of these perceived bugs or quirks are part of what make Brood War the beautiful game that it is.
|
On January 25 2017 08:04 2Pacalypse- wrote:Show nested quote +On January 25 2017 07:34 [[Starlight]] wrote:On January 24 2017 23:06 2Pacalypse- wrote:On January 24 2017 21:17 [[Starlight]] wrote:On January 23 2017 20:23 2Pacalypse- wrote:On January 23 2017 20:16 sabas123 wrote:
* Air unit stacking
When you group air units with another unit that is far away, they will stack on 1 position.
This is probably the most important unintended feature in all of SC. [Air-unit-stacking] was most definitely an intended feature in BW. How do we know that, though? Didn't air-unit-stacking not even become a thing until several years after BW came out? Liquipedia has it being discovered by Shark around 2006, with JulyZerg perfecting it soon afterwards. Seems more like an unintended feature that just happened to work out well. We know that by reading the BW's code. Air-unit-stacking is the same thing as ground-unit stacking. No, it kinda isn't, not strategically. Because ground units can't stack on top of one another... air units can. And there are obvious/significant gameplay implications for air units being able to occupy more-or-less the same space, it's inherently why air-unit-stacking is strong/an advantage. BW's units keep the formation as long as they're closer to each other than some set distance, and when they get further apart than that distance, they converge to one location. Also known as Magic Boxes. This is a very intended feature in BW's engine since the developers even went to trouble of making that distance different for ground and air units. But as I said, the effect that these features had on BW's strategy were probably unforeseen by developers, and indeed, by players themselves for quite some time. This doesn't make the initial decision to put these mechanics into the game any less intended though. This is the beauty of BW after all. You seem to be agreeing that air-unit-stacking was indeed an unforeseen feature. Which, whether or not it was, certainly has worked out to be that in practice. No one was really using it until eight years after BW's release. We seem to be on the same page, some nitpicking aside. I'm not really sure how else to say it to make it more clear, but air-unit-stacking was *not* unforeseen feature. It was most definitely made possible on purpose by developers by adding magic boxes mechanics and removing collision boxes of air units. They could've just as easily make the air-unit-stacking impossible by, for example, removing magic boxes mechanics for air units. Instead they increased the size of the magic box for air units. Sure, the effects of these mechanics and how were they used strategically in game by players was unforeseen by developers, but that doesn't mean it was any less intended by developers to make it possible. Seriously, I just hate it when people act like everything in BW is the consequence of some happy accident. Developers added a lot of little things into the game engine on *purpose*, even if they couldn't predict on how each of those features would be used by players.
Sigh. I fully understand your argument, in fact you seem to repeating much of what I'm already saying.
The feature of magic boxes was intended, the strategic implications of using said magic boxes and grouping in a way that was definitely NOT foreseen resulted in gameplay/strategic usage that was NOT foreseen by the game developers.
And if you like the unforeseen gameplay/strategic changes that resulted from it, then it was indeed a 'happy accident', despite your dislike of the term. Just because something is *possible* in the code and design does not mean it was foreseen by the coders and designers. I've worked in the gaming industry, and I think anyone there would bust a gut laughing if you made that argument to them. Games get released with wholly unintended features and bugs all the time, despite a considerable QA process.
The larger magic box size and lack of collision for air units could be due to any number of possible things, such as air unit groups not having to thread through terrain and the lack of air collision adding to the realism, rather than someone on the team saying, "Hey, let's make it possible for air units to stack, because something interesting and strategic will come of it... What specifically? Oh, I have NO idea, but let's just throw it in there anyway"... when NO ONE really used air unit stacking until eight years after release, i.e. longer than the lifetime of most games.
You'd have an excellent point if some players were using stacking to good effect during the beta (which'd likely mean the devs saw it, liked it, and left it in, or put it in in response to player requests), but I haven't heard of such gameplay happening then (and if it had, you'd think we would've seen it immediately following release too, since it'd be a big advantage and word would've spread).
Happy now? Yeesh.
|
On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it...
I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making.
|
I believe the magic box behavior was put in to allow differenciating behavior for units between keeping formation or effectively all moving to a location instead if they are spread out (and it seems for casting spells with few units @same time), but I really doubt it was foreseen people would use it to make attacks with stacked air units on top of each other like this by using another slow/stuck far away unit. If it was intended I think some blizzard guys would have been using this trick on bnet and it would have been known since the start.
I agree a lot of bw is not a happy accident at all like some people say sometimes. The game is just rly smartly designed down to pretty much all its details. But it has a few rough corners and some unintended things and I think the air stack attacks is unintended. The way to use it is quite anti-ergonomic. And then it's so strong it becomes kind of the one best way to attack with air units, feels weird the relationship between muta and archon, turrets&canons next to workers (ease of killing workers while avoiding damage), and to lesser extent marines and goons (I'm not gonna say marines are too weak vs mutas lol but goons don't get that much opportunity to shoot at them since the mutas can all move & attack together, sustained dmg is what goons need to fight mutas goons which don't have that much mobility mutas being small 50% damage received..), and ofc hydras but I guess that was never rly played vs mutas even before?..
its not rly trivial removing this exploit I guess (?) so I think mutas => medium ^^^^ hydras deal more dmg, goliath&turrets, and goons&scouts ;; but thats not bug fix and unfair for ZvT by itself so disregard^^
PS: this doesn't make me want to play Z in 1v1
|
On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:
When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp.
regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually.
Whoever tscmoo is made claims without any knowledge of the matter.
tscmoo is probably the person that knows most about how Brood War works on this planet
He (re)wrote the entire game engine after all (see the OpenBW thread). But there is a slight chance I misunderstood him.
Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0.
Yupp, I happen to have pretty exact numbers on this. On a standard map a 5% difference yields an additional worker after around 126 seconds (around the 3000 frame mark), assuming you build workers constantly. After that the difference grows faster obviously, until max saturation is reached.
|
On January 25 2017 09:34 Jealous wrote:+ Show Spoiler +On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it... I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making.
agree completely,quirks like units spawning outside of a wall adds to the depth of the game
|
So in conclusion of the discussion so far, we have found that everything is a feature, as it adds to the depth and diversity of the game, except for the black-whole-ramp, which in turn is nigh unfixable because map makers would need to invest unreasonable amounts of time to do so (and rewriting unit-pathing would fundamentally change / break the game).
|
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
|
On January 25 2017 19:25 shall_burn wrote:
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
I imagine that replays from older versions would work if the game just reloaded some logic&values from the correct version when a replay is launched. But it would require that the game code is organized in a way that makes it easy.
|
On January 25 2017 19:13 fazek42 wrote:
So in conclusion of the discussion so far, we have found that everything is a feature, as it adds to the depth and diversity of the game, except for the black-whole-ramp, which in turn is nigh unfixable because map makers would need to invest unreasonable amounts of time to do so (and rewriting unit-pathing would fundamentally change / break the game).
haha
I did update the OP, categorizing some issues that have been mentioned so far. There is no way everyone will ever agree on every issue. But if most people people agree on most issues we have something to work with.
Also, one of the inputs was to give map makers real-time pathing predictions. A very good idea. I'm getting a lot out of this thread and it has been a exceptionally civilized discussion for far
On January 25 2017 19:25 shall_burn wrote:
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
yes it will completely desync. This is way a well-thought out versioning system will be required. And only clients with the exact same bug fixes enabled will be able to play against each other.
|
On January 25 2017 11:29 fearthequeen wrote:Show nested quote +On January 25 2017 09:34 Jealous wrote:+ Show Spoiler +On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it... I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making. agree completely,quirks like units spawning outside of a wall adds to the depth of the game
Oh, I dunno... some ppl definitely might see it that way, but others probably think, "Geez, why can't I just make my units just spawn INSIDE OF my wall-in? That should be a given, I have other things to worry about than something that basic."
A poll on something like that would be interesting.
|
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
|
On January 28 2017 18:18 Biolunar wrote:
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
ROFLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
i f*cking bought 3 keyboards cuz i thought they were bugging
|
On January 28 2017 18:18 Biolunar wrote:
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
ok this one is potentially hard to track down, because you can't just reproduce it in a replay.
On the other hand there's a chance it will just be solved automatically ^^
Anyways, I added it to the bug list in the OP.
|
Dark Archon's 50 starting energy, is it intended or not? I mean, when the energy upgrade is reseached, it's still 50 at start. Other casters get like... 67? or something, after the upgrade is researched.
|
|
|
|
|
|
EPT
