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