Staredit Network > Forums > Portal News > Topic: StarCraft Developer Update: Latency, Matchmaking, and EUDs
StarCraft Developer Update: Latency, Matchmaking, and EUDs
Oct 16 2017, 4:05 am
By: Roy  

Oct 16 2017, 4:05 am Roy Post #1

An artist's depiction of an Extended Unit Death


Thanks to Alzarath for bringing the video to my attention! Rough transcription of the video for those who prefer to read or otherwise can't watch the video:
Quote
Hey guys, Grant here from Classic Games. Just wanna give you a real quick update on some of the features that we're working on right now on StarCraft: Remastered, but before I do that I wanna thank you guys for all the feedback that you've been giving us in the forums—telling us about the things that you like and what you don't like, and the issues we need to fix: that really helps us know what's going on in the community. So, please keep it up, and we're definitely listening to everything that you're saying.

So, matchmaking 1v1: it's awesome to see so many people that have jumped in and given matchmaking a go. We've had millions of matches made already in just over 6 weeks of StarCraft: Remastered being live. So it's awesome to see so many people playing the global matchmaker. The nature of the global matchmaker does mean we're seeing some issues of latency, and we've been doing a lot of work on that over the last few weeks to try and reduce that as much as possible. Just recently we doubled the number of proxy servers that we're using in Korea and we're already seeing some improvements based on that. We've made a number of other server-side improvements, and very recently you guys all participated in a turn rate experiment which we did which helped us nail down what was a pretty good happy medium turn rate of 10. That said, we want to run in the best—in the fastest—turn rate we can for the connection, so to that end we'll be rolling out a dynamic turn rate system (coming soon). And that will mean that the game will run in the highest possible turn rate that it can for a connection and if the connection has too much latency, it'll keep dropping down to a turn rate that makes sense for that connection. So that's something to look forward to coming soon, and we think that will alleviate a lot of the issues that we're seeing in the global matchmaker as far as latency is concerned.

One thing I want to talk about really quickly is the disconnecting that we saw happening, which it seems like it's no longer happening, or certainly a lot less. People were disconnecting before the end of the game when it looked like they were going to lose in order to not take the loss, and it was also unfortunately preventing the winner from getting a win. That's now been fixed about a week ago and the winner is getting their win, the guy who disconnects gets the loss AND the disconnect stat, so it's a pretty powerful disincentive for people to do this disconnect drop thing before they lose. So as I said, we've seen a lot less of that, and I would expect that to be the case in future.

So still on the topic of matchmaking, I wanna talk about 2v2 and group matchmaking, which is certainly something that a few of you guys are really interested in, and that is certainly been something that's been on our radar from the very beginning of Remastered. We do need to think a bit more about group matchmaking though for a couple of reasons, one of which is the pool size: do we have a large enough pool size to sustain a 2v2, 3v3, 4v4 matchmaking experience? Or is the small pool size going to devalue the experience a little bit? And probably more importantly are the latency issues that we're seeing in 1v1: they're only gonna be exacerbated in 2v2, 3v3, and 4v4 due to the nature of the turn-locked client-host networking infrastructure that StarCraft has. So I think we need to come up with a bit of a better solution for that before we start tackling matchmaking 2v2; so for that reason I would see 2v2/3v3/4v4 as more of a long-term feature rather than anything that we're going to get to in the short term.

Dynamic lighting (real-time lighting): one of the aspects of dynamic lighting is that it does take a lot of VRAM, and particularly when in a high-res 2D game like StarCraft: Remastered. That naturally requires a lot of VRAM, and dynamic lighting requires a whole bunch more VRAM. So one thing that we've been working really hard on is trying to bring that down as much as possible, and I don't make any promises here about what we can do, but that's something we're investigating and if we CAN do something, then I will hope to see that roll out in a patch very soon. Again, no promises, but we're trying to bring that down to 2 gigs so the people that have 2 gigs of VRAM will hopefully be able to experience the real-time lighting as well.

CCMU, sprite limit, bullet limit: I posted about this in the forums recently and I got a bunch of feedback. This is certainly something we want to do; we just wanted to make sure that you guys were okay with it, that you didn't think it was going to break anything in terms of gameplay, because we're certainly committed to not breaking gameplay. So I put that out there to see if you guys thought there were any problems with that, and it seems like overwhelmingly the feedback has been: look, it's fine to raise or eliminate the limits as far as the bullets and the sprites and the CCMU goes. So I see no reason why we shouldn't move forward with that probably in the mid-term future. But if anyone does have a problem with this in terms of gameplay, now's the time to jump in that thread and give us your feedback.

The final thing I want to talk about today is EUD. In 1.18 we kinda left EUD behind, and that's because we introduced some strong anti-cheat and tamper-proof measures to prevent people from cheating in games of StarCraft, and obviously this is the right thing to do: we want to protect the integrity of the game and make sure it's a fun experience for everyone. We don't want people cheating. But it did kinda leave behind EUD, and that made us a little sad because we like the idea that people can experience StarCraft in whatever way they want to, and if that's playing EUD maps, well, that's fine. Unfortunately we cannot release a game into the public with a security hole in it, so these are the reasons why we've continually patched out EUD over the years. Supporting every EUD offset would be a mountain of work and so it's probably not something that's ever going to be possible. But what we have been doing—we've had a very talented engineer here at Blzzard working on enabling SOME of the EUD offsets again—and right now in Remastered, we have a very popular tower defense map working, 100% complete. So that is kind of the start of EUD for us, and again in the mid-term future you can expect to see this map rolling out—this mapping being whitelisted and us saying it's now okay to play this map. And I would love to hear from you guys as to what maps you're playing and what maps are popular, and we'll see what we can do—once we make sure there's no security holes and seeing if we can actually emulate them successfully—we'll see if we can whitelist those maps going forward. So again, we'll never do every EUD offset and support every EUD map, but this is certainly the start of us bring back some measure of EUD, and I know there's gonna be a whole bunch of folks out there that are gonna be very excited about that.

So that's all I got time for today. Keep talking to us in the forums; we're definitely listening. We don't have time to respond to every comment or every question, but we are certainly listening to you guys, and we plan to do more of these video updates in the future. So, thanks for listening, and I'll see you soon!

Helpful links and references:


Post has been edited 3 time(s), last time on Oct 16 2017, 2:28 pm by Roy.




Oct 16 2017, 4:54 am Lanthanide Post #2



I wonder if "support EUD" literally means allow EUDs to work, or to actually do what mapmakers want and make proper triggers for those conditions / actions, so we don't have to hack memory in order to achieve our goals.

If they were sensible, they'd just implement support for both. Make official triggers for the various actions they want to support, and then implement translations from EUD offsets into those officially sanctioned triggers. That way existing EUD maps could work.

Post has been edited 1 time(s), last time on Oct 16 2017, 5:19 am by Lanthanide.



None.

Oct 16 2017, 12:30 pm Roy Post #3

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
I wonder if "support EUD" literally means allow EUDs to work, or to actually do what mapmakers want and make proper triggers for those conditions / actions, so we don't have to hack memory in order to achieve our goals.

If they were sensible, they'd just implement support for both. Make official triggers for the various actions they want to support, and then implement translations from EUD offsets into those officially sanctioned triggers. That way existing EUD maps could work.
It sounds like there's no consideration for keeping the overflow functionality, as it's officially considered a security vulnerability (I know the community can argue against this stance for EUD Conditions, but Blizzard doesn't make the distinction from EUDAs). I interpreted it to mean they have no plans to make EUDs work, but they want to bring back functionality found in the most commonly-played EUD maps in a proper way.

I like your idea of translating EUDs to newly supported triggers. If Blizzard was willing, it would be most ideal to have some system like you propose that would automatically fix 1.16.1 EUD maps without putting the burden on us.

Overall, it seems like Blizzard wants us to know that they aren't ignoring us, and they are letting the Classic Games team(s) do what the various communities of these older titles would like. We're a pretty quiet community ourselves, but most of the other major EUD-using communities are not English-speaking natively, so we have a pretty significant responsibility to be communicative with Blizzard if we want to encourage and help shape these developments.

I'll add some links to the news post for easy reference.

Post has been edited 5 time(s), last time on Oct 16 2017, 2:50 pm by Roy.




Oct 16 2017, 12:35 pm Oh_Man Post #4

Find Me On Discord (Brood War UMS Community & Staredit Network)

Well, they've said their approach is to simply whitelist certain EUD maps. This makes me think we're getting no official support of EUDs or new triggers - simply certain maps are gonna be blizz approved, probably via some arduous red tape filled Blizz process. What this means I imagine is only popular maps that receive enough support to be noticed by blizz will be whitelisted, while the vast majority of EUD maps will not be supported.

So, in summary, basically the worst approach they could have possibly taken, not to mention the laziest. Though I question how lazy it actually is as surely there will have to be some employee being paid to vet and whitelist EUD maps - who would of course be on a salary. Just how long is Blizz gonna support this whitelisting process, I wonder?? 5 years, 10, 50??




Oct 16 2017, 12:41 pm Roy Post #5

An artist's depiction of an Extended Unit Death

Quote from Oh_Man
Well, they've said their approach is to simply whitelist certain EUD maps. This makes me think we're getting no official support of EUDs or new triggers - simply certain maps are gonna be blizz approved, probably via some arduous red tape filled Blizz process. What this means I imagine is only popular maps that receive enough support to be noticed by blizz will be whitelisted, while the vast majority of EUD maps will not be supported.

So, in summary, basically the worst approach they could have possibly taken, not to mention the laziest. Though I question how lazy it actually is as surely there will have to be some employee being paid to vet and whitelist EUD maps - who would of course be on a salary. Just how long is Blizz gonna support this whitelisting process, I wonder?? 5 years, 10, 50??
This does indeed seem to be the terminology they're using on the forums.

Quote from Matt Sherman
EUD (Extended Unit Death) was another tough nut to crack. A composite armored Abrams' walnut. Very rare. They taste too good not to crack though. Similar to CCMU, we have created methods to support a handful of the most popular existing maps. Another independent post will be created to cover this rich topic.
If that is truly their current approach, it is an unusual and ultimately disappointing one. But it's still too early in the game to know exactly what their final plans are, and as I mentioned, we may have a chance to influence what those plans will eventually manifest into.

EDIT: Found clarification from Grant in the dev update post: https://us.battle.net/forums/en/starcraft/topic/20759307870#post-6
Quote from Grant Davies
EUD - we do not intend to rebuild maps. Rather, we basically have an EUD emulator to emulate hundreds of the offsets. That's why some EUD maps will be supported as we move forward, and not all.
So it looks like they're actually taking the ideal approach! I'm curious, however, what this means in regards to their use of the word "whitelisting": do they really mean they're whitelisting offsets, or that these offsets will only work on whitelisted maps?

Post has been edited 3 time(s), last time on Oct 16 2017, 2:19 pm by Roy.




Oct 16 2017, 3:02 pm Sand Wraith Post #6

she*

>CCMU, sprite limit, bullet limit

I'm really excited by this!! MOD EVERYTHING TO RIDICULOUS PROPORTIONS




Oct 16 2017, 9:01 pm Butch Post #7

PROFESSIONAL MAP MAKER

I said this in the discord. They gave an example of an EUD tower defense map that they made functional. I imagine they looked at what offsets were used in the map, removed the actual EUD condition triggers and replaced them with new conditions that read the same values. It seems unlikely that they'll "whitelist" certain maps and have these maps somehow hardcoded into the game to allow them to work? seems like more work/not as timeless as just creating new conditions that check the same places in memory as widely used EUD offsets. The way they've worded it supports this thought as well.

Tho I'm mostly jus tryna rationalize the best case scenario based off what they've said LMAO. GIVE US NEW CONDITIONS.



None.

Oct 16 2017, 9:37 pm Lanthanide Post #8



Quote from Roy
EDIT: Found clarification from Grant in the dev update post: https://us.battle.net/forums/en/starcraft/topic/20759307870#post-6
Quote from Grant Davies
EUD - we do not intend to rebuild maps. Rather, we basically have an EUD emulator to emulate hundreds of the offsets. That's why some EUD maps will be supported as we move forward, and not all.
So it looks like they're actually taking the ideal approach!
No, that's not that ideal approach.

That means if I want to make a new map today, I have to use EUD offsets, which are fiddly and annoying to use and change with each version of the game.

The ideal approach, as I stated, is to implement those functions as proper trigger conditions/actions, and then having their emulator translate classic EUDs offsets into those new trigger conditions/actions transparently.



None.

Oct 17 2017, 4:07 am Roy Post #9

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
No, that's not that ideal approach.

That means if I want to make a new map today, I have to use EUD offsets, which are fiddly and annoying to use and change with each version of the game.

The ideal approach, as I stated, is to implement those functions as proper trigger conditions/actions, and then having their emulator translate classic EUDs offsets into those new trigger conditions/actions transparently.
I understand the criticism, as these are the pros/cons we're looking at:

Pros:
  • Existing maps will begin working, other than those with obscure EUDs.
  • Emulating offsets from 1.16.1 means that EUD offsets will not change with each version of the game.
  • Existing tools like EUDGen will still work for making EUDs, and the stability of it means EUD integration into editors could make it as seamless as if Blizzard added the new conditions/actions themselves.
  • It makes it trivial for Blizzard to extend some capabilities of the editor natively (more on this below).
  • Mac compatibility.
Cons:
  • We're going to have a much smaller list of possibilities than we had with unrestricted EUDs.
  • EUDs will still be complicated to create and use (especially reading byte/short values on the wrong offsets).
  • Blizzard has no real incentive to extend capabilities for SC this way, just "bugfixing" existing popular maps that broke compatibility.

Now, your multi-part solution is certainly forward-thinking, but you're conflating two features as one and then attacking the idea of only implementing one part of it. In other words, you're taking this opportunity of Blizzard extending EUD support to push the agenda of getting a more powerful editor. Blizzard's goal here is to make EUD maps functional again, and while I'd enjoy new conditions/actions to become available (especially in a cleaner fashion than EUDs) as much as anyone else, this is tangential to the actual conversation.

As for why I believe your solution is actually two separate features: classic EUDs do not translate well into new trigger conditions/actions. Due to the limitations of EUDs, we had to do certain things—absurd things—to read values, and I would rather the new conditions/actions not be a 1:1 translation to what we did with EUDs. I don't want Blizzard to make conditions and actions that ask for a unit index ID, for example, but classic EUDs will never translate over to a system that works like, say, Set Doodad State, which grabs the first matching unit at a given location. There also begins to be nuance with the meaning behind classic EUDs: a complete set of triggers, possibly spanning a hundred or more, can comprise a single conditional check, but it's not as trivial as looking at the entire set and determining what the meaning behind it is and mapping it to a new condition, unless you want to be destructive to all maps that use a partial set. For example, you could look for triggers that check all 11 chat lines for a keyword and say "Oh, this maps to our new condition of 'Display Text Detection'", but... that's not going to be as compatible as actually emulating what the EUDs are doing. How would it work if it was checking only a subset of chat lines? Or if it was intentionally not matching a string anywhere, but at a specific position? Or if it was leveraging locality? Don't get me wrong: chat detection is the de facto worst experience to write with EUDs, but Blizzard emulating it vs creating native support for it are two entirely distinct tasks.




Oct 17 2017, 5:35 am Lanthanide Post #10



Roy, the ideal approach is for Blizzard to do more, not less. Not sure why you'd argue against that.

What's weird is that you even said what I proposed was ideal:
Quote from Roy
If Blizzard was willing, it would be most ideal to have some system like you propose
and then went on to say what they're doing is ideal, when they're (apparently) not doing what I proposed.



None.

Oct 17 2017, 6:32 am Sie_Sayoka Post #11



Raising of limits is great. A lot of old maps wont break due to unit/bullet limit and it leaves a lot of possibilities for new maps as well. A few niche things like purposefully reaching the sprite limit will be harder to achieve now.



None.

Oct 17 2017, 11:30 am Roy Post #12

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
Roy, the ideal approach is for Blizzard to do more, not less. Not sure why you'd argue against that.

What's weird is that you even said what I proposed was ideal:
Quote from Roy
If Blizzard was willing, it would be most ideal to have some system like you propose
and then went on to say what they're doing is ideal, when they're (apparently) not doing what I proposed.
Sorry, I misread what you originally wrote and didn't know you were suggesting to shoehorn EUDs into new conditions/actions. That would not be the ideal solution for backwards compatibility, for the reasons I mentioned: one of these features would suffer from the other.

I didn't argue against your suggestion. In fact, new conditions/actions aren't taking it far enough: we need variables to track units instead of our limited means that we use today like LIDs. These suggestions are separate from the task of repairing the functionality of EUDs, which is an unexpected task Blizzard has taken on.




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[05:47 pm]
Vrael -- an unopened 300 box
[05:37 pm]
lil-Inferno -- tru
[05:37 pm]
Dem0n -- What could possibly possess me to play when someone else already has a 120 box?
[04:58 pm]
Voyager7456 -- 120 box o____o
[03:57 pm]
lil-Inferno -- inb4 someone mad AF talmbout NO IT'S ACTUALLY 11.9047619048 DCS/SECOND O____________________________________________________________________O
[03:56 pm]
lil-Inferno -- Excalibur
Excalibur shouted: Sorry its 12 dcs per second* I always get confused on that.
just remember SC runs at 24 fps and triggers run every 2 frames
[12:20 pm]
Psychic_Genius -- sorry for bothering. I was just 2 desperate and tired.
[12:13 pm]
Psychic_Genius -- nvm, i was fucking it up. Wasn't using the right player lol. Just figure that out. Was getting desperate. Ty
[12:08 pm]
Psychic_Genius -- then i increased the number from 120, to 12000. Same thing happened
[12:07 pm]
Psychic_Genius -- when i tested that, the msg kept appearing without waiting
Please log in to shout.


Members Online: Roy