Ahli here! Thanks for the great video summing up the situation. I want to give a few more insights: The difficulty with the Shield Battery button issue is that the bug did not happen in editor tests. It only appeared online! This is a behavior that I have not seen before in my 13 years of SC2 editor experience and has only happened to the Shield Battery (so far). The data of the Shield Battery's button layout is not difficult to understand when you look at it. It is a list with coordinates, an ability with a subcommand (since some abilities have multiple) and a reference to a button that holds hotkey, text and icon. The game's data is modified by the different game mod layers: Core, Liberty, Swarm, Void, VoidMulti! The Shield Battery defines 3 buttons in Liberty and in VoidMulti they are edited. For some reason this data triggers a strange engine bug making the editor, the local tests via the editor, the online buttons on the unit and the online hotkey menu not behave identical. That usually is the case for every other unit I ever modified or created in the Arcade. My working hotfix was to add 3 new buttons and that worked out. Essentially, there are two buttons stacked and only the topmost will be shown. In editor tests, it is probably the first one and online the second one because something breaks the first entries. The scary root bug that causes this dilemma is likely lurking in the engine. But that won't be touched unless absolutely necessary (=> arcade review crashes) because that can break things hard in WoL, HotS, LotV, Arcade, all campaign and coop. There is no way existing that everything can be tested in this insanely huge game! Between the PTR and the release, there was a fix attempt. But unfortunately that fix attempt did not work out. I do not know how Blizzard's QA operates, but maybe Blizzard only tested it locally and the fix worked there. As I said before, usually, that is sufficient and I believe that is why the patch was released like this. And we have to remember that the real experts left Blizzard, so we are left with staff that has a big variety of tasks. I cannot blame them as I expect most other companies to put the game to the side entirely. Maybe I could have prevented it. Now, with more knowledge, maybe. As you said, you can only blame the process. Another source of bugs is transforming changes from an extension mod into the internal mod layer like VoidMulti. Unfortunately, that is not a copy paste operation! That's why I think everything should always appear on the PTR server before anything is released. Else, the balance changes with the reworks are likely to break something... And that is exactly my takeaway: every game update should appear on the PTR server first, so more eyes are on the changes and functionality. That way, everything can be properly tested in its final form before release. Only when nothing substantial was found on the PTR and the changes were tested again to verify that they do what they were intended to do, that exact PTR version should be released. This serious bug shows us that it is absolutely necessary to test everything in a real online environment before release. That is a standard in software development. Fixes for issues on the PTR should be pushed to the PTR before production. Else, the balance changes with the reworks are likely to break something
Thanks so much for the context, and really happy to hear about that takeaway! Really unfortunate the bug only appeared online and understandable no prior behavior gave you reason to expect a difference in editor testing versus online. And I didn't know there was additional non-simplistic work in transporting changes from the extension mod to the internal mod layer. I think my final point of intrigue is how can we as a community create better incentives for people to actually go test PTR changes, especially if it's smaller or no real balance changes and just bug fixes. I'm very curious if Blizzard had some internal automated sanity check testing because it really is impressive how low their bug count was over the years or if it really was just dedicated QA manpower with better context on the engine with internal documentation and such.
I think one good thing about making a lot of changes discussed in 21:19 is that our community devs will get even more familiar with the codebase. Keep it up fellas!
I think? that Blizzard's lack of pushing a ton of gamebreaking bugs themselves over SC2's lifespan is a testament to how robust their editor is. I think the reason we saw the shield battery bug was because the shield battery was one of the last units touched before Blizzard cut support, meaning the last intern or whoever was responsible was probably cutting corners and did not implement the unit using the editor properly. Generally, the older the unit, I think the safer for touching it is (which sounds incredibly unintuitive because most development the older the codebase the more unpredictably it beahves)
> the older the unit, I think the safer for touching it is That makes sense to me. I find it amusing to stretch the implications way past their breaking point -> probably the oldest units are the workers -> so to reduce the risk, we only change the workers from now on -> -> a couple of decades pass -> probes replace motherships, SCVs - Battlecruisers, and drones ... drones shoot broodlords now. ;-)
Now after watching your video. I don't totally agree with you. 1.) I think we *need* high risk changes, as they are what take the game fresh, otherwise the game will die sooner than later. 2.) I'm working as a Scrum Master in agile Hard- and Software Projects myself. There are processes how things are done. To simplyfy: You create something, you test something yourself, you have a test from other people before you release it. Personal suggestions: More usage of the test server we have. Yes, they are not used a lot, but they are better than nothing. People even create tournaments to showcase those new changes. How about we give additional money for bugs that are found (and proven) on the test tournament?
Very fair take. I think I actually fall in the middle. I'd like to see bold changes from a balance perspective but low risk from a bug perspective. I would feel more comfortable with higher risk changes if we had a better testing pipeline for changes. Hopefully the balance test tournament will provide improvements in bug finding.
How testing is done differs for every organisation, team, project, and it is catered to the needs for that specific project. There is no size fits all approach to testing, and any attempt to oversimplify like you are doing will just result in worse code being delivered because people either waste too much time testing trivial things or dont spend enough time testing complex things. Also, how much you need to test depends on the experience of a developer and on the quality of the code. If code is very modular, and easy to read, functions are small and simple, and the codebase is structured properly, according to design principles that are used broadly in the organisation, you barely need to write any tests. If you have classes with thousands of lines of code and no design principles you need to test a lot more. Making developers test their own code is also generally a risk, it violates 4 eyes principle, and developers who already spent a lot of time on something will either get bored or overlook stuff. In my opinion, its always better to have someone else on the team test your code. If they cant read and understand your code with the documentation you have provided, then you know you need to improve that. If they dont know what the scope is of the class that they should be testing, thats another problem you can solve that would go undetected if you test your own work. Etc.
Of course it differs from organisation to organisation, to team and project. But the basic principles stay the same. You create, you test and then you deploy. Problem is that it seems like this didn't happen enough in the sc2 development community@@TheSuperappelflap So the question should be how can you ensure a better quality.
@@Granas1988 no. youre a scrum master. go schedule some meetings. dont pretend you're a developer. stay in your lane. you have no idea what blizzard did or didnt do when it comes to testing their game, and as far as video games go, it is extremely stable. it never crashes and when there is a tiny bug, its big news. most video games are buggy messes that crash all the time and you have the audacity to lecture blizzard on testing. lmao bro. here, hold this L.
Thanks for opening my eyes on how currently changes are introduced into SC2. Previously I thought that Blizz is actually still developing or creating them but based on community suggestions. But I was insanely wrong as those changes as I understand are developed outside of Blizz entirely by community volunteers. I assume that from Blizz side there is only a "commit" / "upload to server" person that just puts developed changes live and that is it. I'm myself a dev and I do have quite a bit of (unpleasant) experience of working with legacy code that has its smells and years of modifications, workarounds etc. So I'm to some extend aware how difficult and also scary it is to make any modifications in that kind environment. Many thanks and big credit for those people that work on it and as it appears they also do all of that for free.
Coming from a QA management background it does pain me to see these little issues going out live but it's the reality of a game not being supported anymore and not having a safety net in place to catch these unforeseeable adjustments. Though I could see myself echoing many of the same sentiments shared in the video during internal meetings at my work had this happened, time is against StarCraft II due to neglect and needs some immediate changes to keep it from stalling out. I'd probably pose a recommendation to break these changes up into 2-3 smaller updates after doing a quick risk assessment of change implementation, since some of the changes work in conjunction with each other and have to go out together, and have a little bit of dedicated testing but I know this doesn't sound feasible since I think it's mostly volunteer work getting things done at this point. Really wish I could help cause this is a real rock and a hard place situation for the game to be in :(
I'm glad you made this video. It reflects my thoughts exactly. When I went through implementing the balance patch changes in the editor, it is already apparent that the changes aren't all done as cleanly as one would hope (not to put blame on the volunteers putting in such hard work to improve the game). The main thing that was immediately apparent was that the data used for the new upgrades is recycled from existing upgrades. These things all have many links to other parts of the data and can get quite complicated on their own, let alone when it's something nobody has touched for years and is sort of being "reawakened" along with hundreds of other changes. Thankfully there is a PTR branch, but hopefully there is a lot more testing time and something like this doesn't get pushed to live in a hurry. I'm curious how the agreement with Blizzard is on these community patches. Do they only give the volunteers a certain window of time to make changes? Do they need to make a deadline before Blizzard cuts them off? How rapidly can we get back in there and revert a game breaking change if needed?
This is a common problem in software dev with complex critical systems. You need to be able to fix things quickly, but quickness lacks thoroughness. So a system that enables quick fixes also opens the door to quick breaks. In a critical system, there can be no concept of “just fix that line of code and then patch it tonight”, because every code change can have a fractal butterfly effect throughout large portions of the system, and something that seems like an obvious fix can break other things that were unintentionally relying on the broken state of the code. In some cases, you can definitely say “yes, this one small change needs to be made because of the oversight of a corner case”, and just immediately patch it, or whatever. But the problem is that the system you must put in place to make that hot fix possible creates a giant security threat to the rest of the system, because next time, maybe that small change will have a catastrophic butterfly effect. So for complex critical systems, you really do need to put every single change through a giant test machine that tests everything before you can confidently release it. There are many ways to try to deal with this and mitigate the risks, but you can’t just say “let’s make a way where you can just make a change and patch it right away”. 30 days for that particular change does seem way too excessive, though, since their are ways to analyze the risk of changes to general stability.
Maybe we should separate low risk changes and the higher risk ones where for things like unit reworks the patch will be delayed for more extensive testing and only go live after that. the high risk patches should be able to include low risk things though. they don't need to be in an entirely separate patch.
If you really want to make sure every patch is extensively tested, set up a community funded bug bounty program. There ya go. Problem solved. It doesnt have to be a lot of money. Just a small incentive. Maybe some merch.
@@lukex1337 people actually do that for a lot of old games. sc2 is 13 years old. theres plenty of games less old that the devs pulled the plug on years ago.
Ideally there'd be at least three production branches: PTR, live ladder and live stable (for when there's money on the line etc.). Of course, we neither have the player base nor the infrastructure to make that happen, so... Aside from that, I think it's important to at least consistently and diligently flag fixes that aren't fully understood so that they can be revisited later if/when we have the manpower. But yeah, sometimes the only thing you can do with a legacy codebase is laugh.
Here’s my concern - they are trying to push through this giant patch and huge rework right now. But they can’t even avoid breaking the shield battery in a trivial update. There is no offline LAN play in SC2. Breaking the game will break the community. If blizzard was focused on the game and we had confidence they would react quickly, then yeah, make aggressive changes. But I don’t think they can be quick - the resources aren’t there. If we have a giant patch, there won’t be resources to fix things quickly. If it breaks the game, it will stay broken for a while. Look at how long broken things have remained broken. I work in software as well. The void ray fix is the sign of doom. You shouldn’t roll a tiny overdue fix into a giant patch - it should have been rolled out quickly and immediately, independent of the major change. Delaying it for the major change means there aren’t resources to fix things quickly. If the game gets broken, it will stay broken for a while. And the game will then well and truly die. At this point in sc2, it’s in maintenance mode. There should only be tiny changes to balance. Make them small, and make them incremental. The time to rework units or races is over. Brood war doesn’t get major balance changes anymore. The balance is mostly adjusted via maps. I think sc2 can get small balance changes, but they have to be very low risk. Major changes are just too dangerous with how unstable the game is, and the inability to fix things exactly like the colossus problem you discuss here.
Wait a minute... I knew that the balance suggestions are coming from the community. But you're telling me that blizzard is not paying the people who are working on their product a single dollar? Don't they have a legacy team for stuff like that? Wow... just wow blizzard reached a low point for me.
The classic games department rotates maintenance between all Blizzard titles, so even though ESL or the community or whoever may have a fix ready, that fix can't be implemented until the classic games department gets back around to Starcraft 2. This is also a problem because it means the Classic game department aren't experts on the SC2 editor and therefore testing basically falls to whoever creates the patch
Ahli here: Blizzard's employees are obviously payed and they have a classic team that maintain the older titles. People like me that document bugs, try to understand them and try to make a suitable fix, are not payed. Nobody is payed for what are essentially bug reports. You do that because you love the game, just like other people play. I like the editor, have a lot with experience with it and worked on things like GameHeart a decade ago and keep maintaining UI and my own extension mod. So, I have a personal legacy in this game. Due to that legacy, I started looking for bugs after noticing them on the PTR that was up last December. I documented all potential bugs that I expect after looking at the xml changes and afterwards tried to confirm my suspicions. I tried to reason every change based on the changelog and explained what I would have expected instead or what bugs I expect to appear based on that change. That's how I assisted in avoiding a lot of new bugs being added to production. While doing that, I found a lot of old bugs as well and try to fix them for the past 8 months in my spare time until I stop finding things (or other people finding things and asking me to look into it). Well, today I found out that the Warp Prisms remove the slow on Disruptors that all other transports (that you can in theory build via Neural Parasiting a worker in a ladder match/team game/custom game). So, yeah, there are still lots of bugs waiting to be discovered or engine oddities to be documented... or did you know that in rare situations weapons have more range than intended allowing Zealots to attack an SCV building a depot over a distance of maybe 1.5? TLDR: What people like me do is essentially bug reporting + fix suggestions for free. I was granted a slightly more direct communication channel than posting things in the bug report forum, though
Much as I hate defending Blizzard... As far as I can tell, the money people don't particularly *want* people working on Starcraft 2 in the first place. They certainly don't care enough any more to invest money in updating it. As we can see, they don't even care enough to pay for proper bug fixing. The legacy team is a small team handling several very large games (SC2 is probably the biggest, but they also handle WC3, Diablo, Diablo 2, and several others... I can't find a list but I think they might handle WoW Classic too) with... I'm guessing not much budget. They aren't buffing toss on their own any time soon. From Blizzard's perspective, SC2 is a dead game. But the *community* still cares enough to want balance patches, and Blizzard is agreeing to publish them (because doing so costs them almost nothing). If that turns into a PR issue, they'll probably stop. If it starts costing money, they'll *definitely* stop.
I feel low risk ideas are not really needed. Because it doesnt change the games dynamic, wich means the current status quo is upheld (protoss being underperforming ie.). I think high risk ideas are required to change the game for the better, otherwise you keep getting these meaningless buffs and nerfs to stuff that really dont have that much of an impact at all. I personally think for example, PvP is on the cusp of being ruined by the new voidray prismatic allignment. Because think about it. How are you supposed to micro stalkers vs it now? You cannot kite them with the speed buff. Stalkers just.. die. Blink wont be fast enough either. This was done by buffing an underutilized unit, but the unit is underutilized for good (balancing) reasons. Either they are OP or they are useless if they stick to the current status quo. Many units that are rarely used straight up need a design change (like they did with the cyclone) Because of this very nature of units either being too usefull or too useless. The reall challenge is however how often can people actually 'hotfix' or 'balance'. Because introducing revamped units requires allot of attention to all levels, and playstyles, and requires to be tweaked over time aswell as in a shorter timespan.(ie overperforming in the close future, wich is ussually pretty obvious, or completely new builds that are made with said new units that evolve over time wich might showcase it actually was too powerfull after all). the reall question is not will it break the game (because yes that will happen eventually) The question is, is it able to be fixed in a short timespan. are we "allowed" to do that.
It is not at all out of the ordinary for a piece of software that is effectively EOL to only get minimal support, meaning if there are patches they will be more likely to contain bugs, the deploy cycle will be slow, and if any bugs are found they wont be fixed until the next deploy cycle. In fact, with EOL software, you should be thankful for getting any support on it at all because thats just a net loss for the company. Its a bit of customer service. This is not indicative of any problems in processes in Blizzard or in the community, its just a consequence of the game being EOL. Also, looking at those commits, it seems both the bugs you talk about were caused by lines of code being removed from the units. So, there is someone new trying to clean up old code that should have been deprecated but wasnt. Obviously, thats a very error sensitive process so there is no need to panic about a few bugs. You should be grateful someone is trying to clean up this 13 year old codebase.
Ahli here! Thanks for the great video summing up the situation. I want to give a few more insights:
The difficulty with the Shield Battery button issue is that the bug did not happen in editor tests. It only appeared online!
This is a behavior that I have not seen before in my 13 years of SC2 editor experience and has only happened to the Shield Battery (so far).
The data of the Shield Battery's button layout is not difficult to understand when you look at it. It is a list with coordinates, an ability with a subcommand (since some abilities have multiple) and a reference to a button that holds hotkey, text and icon.
The game's data is modified by the different game mod layers: Core, Liberty, Swarm, Void, VoidMulti! The Shield Battery defines 3 buttons in Liberty and in VoidMulti they are edited.
For some reason this data triggers a strange engine bug making the editor, the local tests via the editor, the online buttons on the unit and the online hotkey menu not behave identical. That usually is the case for every other unit I ever modified or created in the Arcade.
My working hotfix was to add 3 new buttons and that worked out. Essentially, there are two buttons stacked and only the topmost will be shown. In editor tests, it is probably the first one and online the second one because something breaks the first entries.
The scary root bug that causes this dilemma is likely lurking in the engine. But that won't be touched unless absolutely necessary (=> arcade review crashes) because that can break things hard in WoL, HotS, LotV, Arcade, all campaign and coop. There is no way existing that everything can be tested in this insanely huge game!
Between the PTR and the release, there was a fix attempt. But unfortunately that fix attempt did not work out.
I do not know how Blizzard's QA operates, but maybe Blizzard only tested it locally and the fix worked there. As I said before, usually, that is sufficient and I believe that is why the patch was released like this. And we have to remember that the real experts left Blizzard, so we are left with staff that has a big variety of tasks. I cannot blame them as I expect most other companies to put the game to the side entirely. Maybe I could have prevented it. Now, with more knowledge, maybe. As you said, you can only blame the process.
Another source of bugs is transforming changes from an extension mod into the internal mod layer like VoidMulti. Unfortunately, that is not a copy paste operation! That's why I think everything should always appear on the PTR server before anything is released. Else, the balance changes with the reworks are likely to break something...
And that is exactly my takeaway: every game update should appear on the PTR server first, so more eyes are on the changes and functionality. That way, everything can be properly tested in its final form before release. Only when nothing substantial was found on the PTR and the changes were tested again to verify that they do what they were intended to do, that exact PTR version should be released.
This serious bug shows us that it is absolutely necessary to test everything in a real online environment before release. That is a standard in software development. Fixes for issues on the PTR should be pushed to the PTR before production. Else, the balance changes with the reworks are likely to break something
Thanks so much for the context, and really happy to hear about that takeaway! Really unfortunate the bug only appeared online and understandable no prior behavior gave you reason to expect a difference in editor testing versus online. And I didn't know there was additional non-simplistic work in transporting changes from the extension mod to the internal mod layer. I think my final point of intrigue is how can we as a community create better incentives for people to actually go test PTR changes, especially if it's smaller or no real balance changes and just bug fixes. I'm very curious if Blizzard had some internal automated sanity check testing because it really is impressive how low their bug count was over the years or if it really was just dedicated QA manpower with better context on the engine with internal documentation and such.
Thank you for you hard work Ahli!
I think one good thing about making a lot of changes discussed in 21:19 is that our community devs will get even more familiar with the codebase. Keep it up fellas!
Description of hardcoded in-game values in a cryptic xml format with no unit testing... Is there really a process issue? 🤔
"This video has gone on longer than it needed to" *immediately ends video*
Yep, that's definitely a programmer alright.
I think? that Blizzard's lack of pushing a ton of gamebreaking bugs themselves over SC2's lifespan is a testament to how robust their editor is. I think the reason we saw the shield battery bug was because the shield battery was one of the last units touched before Blizzard cut support, meaning the last intern or whoever was responsible was probably cutting corners and did not implement the unit using the editor properly. Generally, the older the unit, I think the safer for touching it is (which sounds incredibly unintuitive because most development the older the codebase the more unpredictably it beahves)
> the older the unit, I think the safer for touching it is
That makes sense to me. I find it amusing to stretch the implications way past their breaking point -> probably the oldest units are the workers -> so to reduce the risk, we only change the workers from now on -> -> a couple of decades pass -> probes replace motherships, SCVs - Battlecruisers, and drones ... drones shoot broodlords now. ;-)
I don't play anymore due to health, so I'm just supporting your video by watching 😊
Now after watching your video. I don't totally agree with you.
1.) I think we *need* high risk changes, as they are what take the game fresh, otherwise the game will die sooner than later.
2.) I'm working as a Scrum Master in agile Hard- and Software Projects myself. There are processes how things are done. To simplyfy: You create something, you test something yourself, you have a test from other people before you release it.
Personal suggestions: More usage of the test server we have. Yes, they are not used a lot, but they are better than nothing. People even create tournaments to showcase those new changes. How about we give additional money for bugs that are found (and proven) on the test tournament?
Very fair take. I think I actually fall in the middle. I'd like to see bold changes from a balance perspective but low risk from a bug perspective. I would feel more comfortable with higher risk changes if we had a better testing pipeline for changes. Hopefully the balance test tournament will provide improvements in bug finding.
How testing is done differs for every organisation, team, project, and it is catered to the needs for that specific project. There is no size fits all approach to testing, and any attempt to oversimplify like you are doing will just result in worse code being delivered because people either waste too much time testing trivial things or dont spend enough time testing complex things.
Also, how much you need to test depends on the experience of a developer and on the quality of the code. If code is very modular, and easy to read, functions are small and simple, and the codebase is structured properly, according to design principles that are used broadly in the organisation, you barely need to write any tests. If you have classes with thousands of lines of code and no design principles you need to test a lot more.
Making developers test their own code is also generally a risk, it violates 4 eyes principle, and developers who already spent a lot of time on something will either get bored or overlook stuff. In my opinion, its always better to have someone else on the team test your code. If they cant read and understand your code with the documentation you have provided, then you know you need to improve that. If they dont know what the scope is of the class that they should be testing, thats another problem you can solve that would go undetected if you test your own work. Etc.
Of course it differs from organisation to organisation, to team and project. But the basic principles stay the same. You create, you test and then you deploy. Problem is that it seems like this didn't happen enough in the sc2 development community@@TheSuperappelflap
So the question should be how can you ensure a better quality.
@@Granas1988 no. youre a scrum master. go schedule some meetings. dont pretend you're a developer. stay in your lane. you have no idea what blizzard did or didnt do when it comes to testing their game, and as far as video games go, it is extremely stable. it never crashes and when there is a tiny bug, its big news. most video games are buggy messes that crash all the time
and you have the audacity to lecture blizzard on testing. lmao bro. here, hold this L.
Thanks for opening my eyes on how currently changes are introduced into SC2. Previously I thought that Blizz is actually still developing or creating them but based on community suggestions. But I was insanely wrong as those changes as I understand are developed outside of Blizz entirely by community volunteers. I assume that from Blizz side there is only a "commit" / "upload to server" person that just puts developed changes live and that is it. I'm myself a dev and I do have quite a bit of (unpleasant) experience of working with legacy code that has its smells and years of modifications, workarounds etc. So I'm to some extend aware how difficult and also scary it is to make any modifications in that kind environment. Many thanks and big credit for those people that work on it and as it appears they also do all of that for free.
there is a bug in online play currently where constucting terran buildings no longer shows an outline and it is really bothersome
Holding down Stop on shield batteries to make them recharge shields faster was an active bug for several months if I remember correctly?
Coming from a QA management background it does pain me to see these little issues going out live but it's the reality of a game not being supported anymore and not having a safety net in place to catch these unforeseeable adjustments. Though I could see myself echoing many of the same sentiments shared in the video during internal meetings at my work had this happened, time is against StarCraft II due to neglect and needs some immediate changes to keep it from stalling out. I'd probably pose a recommendation to break these changes up into 2-3 smaller updates after doing a quick risk assessment of change implementation, since some of the changes work in conjunction with each other and have to go out together, and have a little bit of dedicated testing but I know this doesn't sound feasible since I think it's mostly volunteer work getting things done at this point. Really wish I could help cause this is a real rock and a hard place situation for the game to be in :(
I'm glad you made this video. It reflects my thoughts exactly. When I went through implementing the balance patch changes in the editor, it is already apparent that the changes aren't all done as cleanly as one would hope (not to put blame on the volunteers putting in such hard work to improve the game). The main thing that was immediately apparent was that the data used for the new upgrades is recycled from existing upgrades. These things all have many links to other parts of the data and can get quite complicated on their own, let alone when it's something nobody has touched for years and is sort of being "reawakened" along with hundreds of other changes.
Thankfully there is a PTR branch, but hopefully there is a lot more testing time and something like this doesn't get pushed to live in a hurry.
I'm curious how the agreement with Blizzard is on these community patches. Do they only give the volunteers a certain window of time to make changes? Do they need to make a deadline before Blizzard cuts them off? How rapidly can we get back in there and revert a game breaking change if needed?
Your upload appears to be subject to the Kaizen philosophy \m/
Would it be possible to keep the previous version around as a mod? So that tournaments have the option of going back if a serious bug is discovered.
This is a common problem in software dev with complex critical systems. You need to be able to fix things quickly, but quickness lacks thoroughness. So a system that enables quick fixes also opens the door to quick breaks.
In a critical system, there can be no concept of “just fix that line of code and then patch it tonight”, because every code change can have a fractal butterfly effect throughout large portions of the system, and something that seems like an obvious fix can break other things that were unintentionally relying on the broken state of the code.
In some cases, you can definitely say “yes, this one small change needs to be made because of the oversight of a corner case”, and just immediately patch it, or whatever. But the problem is that the system you must put in place to make that hot fix possible creates a giant security threat to the rest of the system, because next time, maybe that small change will have a catastrophic butterfly effect.
So for complex critical systems, you really do need to put every single change through a giant test machine that tests everything before you can confidently release it. There are many ways to try to deal with this and mitigate the risks, but you can’t just say “let’s make a way where you can just make a change and patch it right away”. 30 days for that particular change does seem way too excessive, though, since their are ways to analyze the risk of changes to general stability.
Maybe we should separate low risk changes and the higher risk ones where for things like unit reworks the patch will be delayed for more extensive testing and only go live after that.
the high risk patches should be able to include low risk things though. they don't need to be in an entirely separate patch.
If you really want to make sure every patch is extensively tested, set up a community funded bug bounty program. There ya go. Problem solved. It doesnt have to be a lot of money. Just a small incentive. Maybe some merch.
Lol
Yea let’s all volunteer and pay our own money to keep servers online while we’re at it 😃.
@@lukex1337 people actually do that for a lot of old games. sc2 is 13 years old. theres plenty of games less old that the devs pulled the plug on years ago.
Ideally there'd be at least three production branches: PTR, live ladder and live stable (for when there's money on the line etc.).
Of course, we neither have the player base nor the infrastructure to make that happen, so...
Aside from that, I think it's important to at least consistently and diligently flag fixes that aren't fully understood so that they can be revisited later if/when we have the manpower.
But yeah, sometimes the only thing you can do with a legacy codebase is laugh.
Here’s my concern - they are trying to push through this giant patch and huge rework right now. But they can’t even avoid breaking the shield battery in a trivial update. There is no offline LAN play in SC2. Breaking the game will break the community. If blizzard was focused on the game and we had confidence they would react quickly, then yeah, make aggressive changes. But I don’t think they can be quick - the resources aren’t there. If we have a giant patch, there won’t be resources to fix things quickly. If it breaks the game, it will stay broken for a while. Look at how long broken things have remained broken. I work in software as well. The void ray fix is the sign of doom. You shouldn’t roll a tiny overdue fix into a giant patch - it should have been rolled out quickly and immediately, independent of the major change. Delaying it for the major change means there aren’t resources to fix things quickly. If the game gets broken, it will stay broken for a while. And the game will then well and truly die.
At this point in sc2, it’s in maintenance mode. There should only be tiny changes to balance. Make them small, and make them incremental. The time to rework units or races is over.
Brood war doesn’t get major balance changes anymore. The balance is mostly adjusted via maps. I think sc2 can get small balance changes, but they have to be very low risk. Major changes are just too dangerous with how unstable the game is, and the inability to fix things exactly like the colossus problem you discuss here.
Aren't colossus too weak anyway? 10 range looks fine for me :)
Wait a minute...
I knew that the balance suggestions are coming from the community.
But you're telling me that blizzard is not paying the people who are working on their product a single dollar? Don't they have a legacy team for stuff like that?
Wow... just wow blizzard reached a low point for me.
The classic games department rotates maintenance between all Blizzard titles, so even though ESL or the community or whoever may have a fix ready, that fix can't be implemented until the classic games department gets back around to Starcraft 2. This is also a problem because it means the Classic game department aren't experts on the SC2 editor and therefore testing basically falls to whoever creates the patch
Ahli here: Blizzard's employees are obviously payed and they have a classic team that maintain the older titles.
People like me that document bugs, try to understand them and try to make a suitable fix, are not payed. Nobody is payed for what are essentially bug reports. You do that because you love the game, just like other people play.
I like the editor, have a lot with experience with it and worked on things like GameHeart a decade ago and keep maintaining UI and my own extension mod. So, I have a personal legacy in this game.
Due to that legacy, I started looking for bugs after noticing them on the PTR that was up last December. I documented all potential bugs that I expect after looking at the xml changes and afterwards tried to confirm my suspicions. I tried to reason every change based on the changelog and explained what I would have expected instead or what bugs I expect to appear based on that change. That's how I assisted in avoiding a lot of new bugs being added to production. While doing that, I found a lot of old bugs as well and try to fix them for the past 8 months in my spare time until I stop finding things (or other people finding things and asking me to look into it). Well, today I found out that the Warp Prisms remove the slow on Disruptors that all other transports (that you can in theory build via Neural Parasiting a worker in a ladder match/team game/custom game). So, yeah, there are still lots of bugs waiting to be discovered or engine oddities to be documented... or did you know that in rare situations weapons have more range than intended allowing Zealots to attack an SCV building a depot over a distance of maybe 1.5?
TLDR: What people like me do is essentially bug reporting + fix suggestions for free. I was granted a slightly more direct communication channel than posting things in the bug report forum, though
Blizzard doesn’t exist anymore. It’s just a label on the corporate megastructure now.
@@Lagpriest Thank you from the heart for your work and passion.
Much as I hate defending Blizzard...
As far as I can tell, the money people don't particularly *want* people working on Starcraft 2 in the first place. They certainly don't care enough any more to invest money in updating it. As we can see, they don't even care enough to pay for proper bug fixing. The legacy team is a small team handling several very large games (SC2 is probably the biggest, but they also handle WC3, Diablo, Diablo 2, and several others... I can't find a list but I think they might handle WoW Classic too) with... I'm guessing not much budget. They aren't buffing toss on their own any time soon. From Blizzard's perspective, SC2 is a dead game. But the *community* still cares enough to want balance patches, and Blizzard is agreeing to publish them (because doing so costs them almost nothing). If that turns into a PR issue, they'll probably stop. If it starts costing money, they'll *definitely* stop.
The final death rattle of sc2. Its clear to me that its been abandoned.
Shitzard fugs it up who knew
I feel low risk ideas are not really needed. Because it doesnt change the games dynamic, wich means the current status quo is upheld (protoss being underperforming ie.).
I think high risk ideas are required to change the game for the better, otherwise you keep getting these meaningless buffs and nerfs to stuff that really dont have that much of an impact at all.
I personally think for example, PvP is on the cusp of being ruined by the new voidray prismatic allignment. Because think about it. How are you supposed to micro stalkers vs it now? You cannot kite them with the speed buff. Stalkers just.. die. Blink wont be fast enough either.
This was done by buffing an underutilized unit, but the unit is underutilized for good (balancing) reasons. Either they are OP or they are useless if they stick to the current status quo.
Many units that are rarely used straight up need a design change (like they did with the cyclone) Because of this very nature of units either being too usefull or too useless.
The reall challenge is however how often can people actually 'hotfix' or 'balance'. Because introducing revamped units requires allot of attention to all levels, and playstyles, and requires to be tweaked over time aswell as in a shorter timespan.(ie overperforming in the close future, wich is ussually pretty obvious, or completely new builds that are made with said new units that evolve over time wich might showcase it actually was too powerfull after all).
the reall question is not will it break the game (because yes that will happen eventually) The question is, is it able to be fixed in a short timespan. are we "allowed" to do that.
I'm pretty sure kotick is at fault here
It is not at all out of the ordinary for a piece of software that is effectively EOL to only get minimal support, meaning if there are patches they will be more likely to contain bugs, the deploy cycle will be slow, and if any bugs are found they wont be fixed until the next deploy cycle. In fact, with EOL software, you should be thankful for getting any support on it at all because thats just a net loss for the company. Its a bit of customer service.
This is not indicative of any problems in processes in Blizzard or in the community, its just a consequence of the game being EOL.
Also, looking at those commits, it seems both the bugs you talk about were caused by lines of code being removed from the units. So, there is someone new trying to clean up old code that should have been deprecated but wasnt. Obviously, thats a very error sensitive process so there is no need to panic about a few bugs. You should be grateful someone is trying to clean up this 13 year old codebase.
I will not be shocked when Blizzard loses it's starcraft community. It has a 72 BILLION dollar mcap and can't work on it's own code, FFS.
Raynorfanboy