|
TLDR: The MIT Game Lab needs your help to test a new “Workers Killed” notification panel for GameHeart!
Last year, we ported our “Upgrade Notifications” to GameHeart with a ton of assistance from Ryan Schutter and Ahli. Taking advantage of the structure of the GameHeart Extension Mod, we’ve prototyped a new feature for community testing and feedback. If “Workers Killed” panels turn out to be desirable, the code itself can be easily integrated into GameHeart in the future.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/04/workerskilled.gif)
The “Workers Killed” notification is a little pop-up tab that appears on the left side of an SC2 observer screen that shows how many workers have been killed recently. Our goals for this feature are to make it easier for observers, casters, and spectators to identify and assess the amount of economic damage during attacks on the mineral line.
It’s pretty simple: Every time a worker is killed, our code waits 20 seconds. If another second worker dies in that period, we open up the panel and show how many workers have been killed. After 20 seconds pass with no workers being killed, the panel disappears and we reset the kill-count to zero.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/04/image04.png)
Here are a couple of possible situations in which the notifications can help:
- Hellions or Banelings kill multiple workers: Casters can tell exactly how many workers died during a single blast, eliminating the need for mid-game “caster math.”
- Periodic attacks by Medivacs, Oracles or Mutalisks over the course of a game: Casters can easily discuss the effectiveness of each separate attempt.
- Multi-pronged harass: Observers can track the total number of workers lost without opening the 1v1 Workers Killed panel open.
- Scouting worker deaths: This is very common and does not bring up the notification. 2 or more workers must be killed to bring up the notification window.
- Mineral line attacks in 2v2 games: Separate color-coded notifications appear for each player losing workers.
- Big battles occurring near bases and mineral lines: Viewers can watch the battle itself while casters can point out the long-term consequences of worker pulls and losses.
- Post-game analysis: Observers can hide notifications mid-game (Control-Shift-W for workers, Control-Shift-N for upgrades) or use a custom interface file to hide them by default. Their visibility can also be toggled by observers during replays.
As we add more features to GameHeart, we are constantly thinking about how much screen real estate we’re using. We want to make sure that our automatic notifications never stray into the annoying territory and are only open when helpful. We also want to ensure that our code doesn’t affect game or player performance.
In other words, we need your feedback and help! Since our work runs on top of GameHeart, it’s the same process as starting a GameHeart match. Go to “Custom Maps,” choose a 1v1 or 2v2 melee map, and click on “Create Map with Mod.” Search for and select “GHWorkerKilled,” an Extension Mod that includes our all our notifications and (as far as we can tell) all of the current features of GameHeart.
Kudos to Nick Mohr for implementing this new feature. Good luck and have fun!
|
I'll check this out with my maps, thank you for the work guys!
|
Great idea. I like it a lot.
|
|
|
Could not think of a more useful feature which we don't have already - really excited to see this implemented in the future!
|
I can't test it in game but here is my feedback based on description.
I think that it MAY be distracting to show number of worker killed when they are being killed, during the battle. It deter viewer's attention from game (eg Marine Oracle worker micro) to some changing numer.
Did you consider showing worker killed after the action (eg 10s since last worker was killed)?
Btw idea is great.
|
GameHeart getting better and better. Another very helpful feature. 
|
On April 17 2014 01:08 Anomek wrote:
I think that it MAY be distracting to show number of worker killed when they are being killed, during the battle. It deter viewer's attention from game (eg Marine Oracle worker micro) to some changing numer.
Did you consider showing worker killed after the action (eg 10s since last worker was killed)?
Thanks for your questions!
Yeah, casters currently use the 1v1 Workers Killed panel immediately after the harass ends, with all the challenges of "caster math". But it's much simpler for a caster or observer to identify the end of harass than it is to do in code, so my guess is that an "after-action" Workers Killed panel would be something that one could manually toggle instead of an automatic notification.
Once it's a manual toggle, though, there's a question of how big that window should be. The 1v1 panel is large and attention-grabbing for a reason -- the caster can use it to illustrate a point. Our current notifications are more like the "5 hits!" "6 hits!" "7 hits!" counters that you see in fighting games, which is intended to be information you can easily ignore, but it's immediately there if you need it.
So we're not sure whether to pursue "attention-grabbing info windows that casters can use to make a point" or "small info panels that provide peripheral information". Since this current version is easier for casters to use, we figured we'd try this first and ask the community if it's really too distracting.
There's no reason why we can't go manual and go big in the future. We've imagined there might be an interest for a "last engagement" summary to assess not only how many workers were killed, but also compare the costs of any attacking/harassing/defending units that were lost in the process. We tried a version of this last year, where you could compare the costs of engagements over the last three minutes, and drill down to details by mousing over the bar chart. Not exactly the same thing, but fulfilling similar goals.
So we might revisit that idea in a more streamlined way in the future, using what we've learnt from implementing the Workers Killed notification.
|
Much has happened since we demoed the "Workers Killed" notification panel for StarCraft 2! Thanks to the combined efforts of GameHeart and DreamHack, this past month has been the fastest turnaround from unveiling to production code on our MIT Overseer research project to date. Thanks to everybody who helped us test the code, find bugs, and especially to MiTNicketh (Nick Mohr) for implementing the feature in the first place!
We're not done yet, and we do need more help with testing and feedback. If you're in a hurry, this is all you need to know:
- Start up StarCraft 2 and invite a friend (or three) to a party
- Click on "Custom Maps"
- Select any 1v1 or 2v2 melee map
- Click on "Create Map with Mod."
- Search for and select "GHMITTest"
- Play a 1v1, 2v2 or FFA melee game
- Watch the replay
- Let us know if you see any bugs!
Here are the changes we are testing:
Dropship Alerts on the Minimap
If a full-health dropship (warp prism, overlord or medivac) picks up a full complement of healthy troops, observers will see a ping and exclamation mark on the minimap that tracks the dropship for five seconds, alerting viewers to incoming drop shenanigans!
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/05/NewDrop.gif)
Orbital Scans on the Minimap
Proleague introduced their own version of Upgrade Notifications, as well as a really nice minimap representation of orbital scans. It's a great idea, so we're trying that out with GameHeart, with a smaller ping and a little more transparency to the animation.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/05/NewScan.gif)
More colors for Workers Killed Notifications
The Workers Killed Notifications got a lot of testing in DreamHack. We noticed that observers (such as the talented FunKa) still continued to open the 1v1 Workers Killed panel at the end of skirmishes, which displays worker deaths in the colors of the aggressor. Prior to DreamHack, we knew that our notifications, which highlight the color of the player hurt by the attack, might clash with "more color = more advantage" design principle behind Blizzard's standard interface.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/05/NewWK.gif)
We didn't notice anyone seeming too upset by the clashing colors, but we certainly felt a little uncomfortable every time the 1v1 panel appeared on the stream. To address that, we have tinted the background in the color of the aggressor and made it slightly darker and translucent. We hope this still makes it completely clear which player's base is being attacked during worker harass, while establishing a visual connection to the attacker's colors in the 1v1 panel.
Our system can handle up to 4 panels, one for each player who could take damage in a 2v2 or 4-player free-for-all game. This means that if two players attack the same mineral line at once, the background color of a single panel may alternate between two colors. If one player attacks two opponents at once, you would see the same background color for two separate panels. We think the transparency will reduce the cognitive dissonance, but this is certainly a place where more feedback would help us tremendously.
The panels now automatically disappear 15 game seconds after the last worker death instead of the 20 seconds shown in DreamHack. And if you hate the Workers Killed Notifications, you can always hide them as an observer using Control-Shift-W. Even in replays!
Tweaks to Upgrade Notifications
Finally, we've made a few changes to Upgrade Notifications, which only appear in 1v1 games.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/05/upgradestweak.gif)
The countdown is now one decimal place and we've adjusted the fonts a little. It means it takes slightly less computation (our code runs once every 0.1 seconds instead of 0.01 seconds) and we fixed an elusive display bug in the process. As seen in Proleague and DreamHack, new notifications now push old notifications upwards instead of stacking above existing panels, so there's less "bouncing" up and down as multiple upgrades complete.
![[image loading]](http://gamelab.mit.edu/wp/wp-content/uploads/2014/05/NewDenied.gif)
We've also gotten a good response to the "Denied" notification when a research building is destroyed while an upgrade is in process. Previously, "Denied" would show up only in the last 15 seconds of research completion. Now they'll appear whenever an upgrade is destroyed.
What's Next?
We're planning to provide details on how Custom UI creators can customize the look of the Upgrade and Workers Killed Notifications, so if you really like the gradients of Proleague or the brushed metal aesthetic from Blizzard, or just want to reposition them on your observer screen, we'll have more news for you soon.
|
haha this stuff is ace.
I loved it when i first noticed this in games that were being casted.
shame we cant make blizz pay you for this shit 
|
United Kingdom1380 Posts
Hi, I had a quick go at the GHMITTest mod, here's my feedback.
General:- I like the new "Denied" condition, it's much more likely to appear now and the info is useful to the audience.
- Simplifying the upgrade countdown is definitely an improvement.
- The new orbital scans on the minimap look nicer.
- The drop minimap notification seems like a useful addition, however the minimap graphic gets slightly intrusive for large drops (e.g. loading up 10 overlords). It might be worth preventing additional notifications after a certain number of pickups.
![[image loading]](http://i.imgur.com/fT66VON.png)
- Im not really a fan of the translucency effect to show which player killed the workers. It's confusing for the audience, doesn't really fit with the rest of the interface and looks bad for non standard colours (e.g. + Show Spoiler +). Also it will merge into the background for low quality streams.
I'm not really sure why the audience needs to know which player killed the workers but what about just updating the tab with the colour of the player who killed the most recent worker? (e.g. + Show Spoiler +)
Questions:- Killing a single worker doesn't cause the Workers Killed Notification to appear, is this by design?
- Should the 'Denied' upgrade notification display the progress bar as it will always be empty?
- Why does the dropship/prism/overlord have to be full health to receive a minimap exclamation mark?
- Loading up a floating CC with workers causes the minimap exclamation mark, is this needed as it may not be useful to audience?
- Currently loading up a Nydus or building a worm has no special minimap effect in Gameheart, should this also have a minimap exclamation mark?
- When I killed my own workers, the translucency effect on the Workers Killed Notification was grey instead of yellow (my player colour), is this correct?
Bugs:
- When hallucinated probes expire they cause the Workers Killed Notification to increment.
- When the workers killed reaches double digits, the Workers Killed Notification displays "...". It's possible that a non standard screen resolution is the cause. The GHWorkerKilled mod worked correctly for double digit kills but displays "..." for 3 digit numbers. It's not impossible for situations where 100+ workers are killed (e.g. nuking multiple mineral lines vs a greedy zerg), especially in 2v2 games.
|
It might be worth preventing additional notifications after a certain number of pickups
Good idea. Although part of me feels the over-the-top notification would be appropriate for a giant doom drop, it'll probably get tiresome real quick. We'll see if we can easily do a single ping for multiple pickups.
What about just updating the tab with the colour of the player who killed the most recent worker?
We've tried this but some folks found it confusing in initial tests, but if more folks generally don't like the translucency, we can absolutely switch it to opaque & striped in a jiffy. Your opinion here is absolutely valuable; thanks for the feedback!
Killing a single worker doesn't cause the Workers Killed Notification to appear, is this by design?
Yes. It only shows up for 2 or more because we didn't want to show them for scouting worker kills.
Should the 'Denied' upgrade notification display the progress bar as it will always be empty?
The panel looks a little odd when we make the progress bar invisible, and if an upgrade is denied in the last 15 seconds, the bar won't be empty. But we are considering the value of the progress bar in general and are wondering whether it's outlived its purpose.
Why does the dropship/prism/overlord have to be full health to receive a minimap exclamation mark?
We didn't want to ping drop evacuations or mid-battle micro (e.g. picking up trapped units behind forcefields) since the camera will likely be looking at them anyway. We also really want to avoid false-positives, but even our current solution has holes.
Currently loading up a Nydus or building a worm has no special minimap effect in Gameheart, should this also have a minimap exclamation mark?
Hmm, you should normally see a Nydus ping when worms are built in default SC2 observer mode. We assumed that would also happen with GameHeart. So this might be a bug unrelated to our notifications, but we'll ask Ryan if he wants us to investigate/tackle this. It's certainly possible to adapt our code to ping Nydus worms.
Loading up a floating CC with workers causes the minimap exclamation mark, is this needed as it may not be useful to audience?
When hallucinated probes expire they cause the Workers Killed Notification to increment.
These are edge-cases we hadn't considered. Thanks for alerting us!
When I killed my own workers, the translucency effect on the Workers Killed Notification was grey instead of yellow (my player color)
This would be a bug, but I can't reproduce it. What color were you playing when you saw this?
When the workers killed reaches double digits, the Workers Killed Notification displays "...".
This is resolution-dependent, so we need to figure out a solution that works for at least 16x10 and 16x9 screen ratios.
Great testing iHirO, thank you so much!
|
Bug fixes and tweaks:
Structures no longer ping the minimap when loading units.
Dropships do not have to be at full health to ping the minimap, only fully loaded. All the units inside the dropship must be at full health at the time of boarding.
Workers Killed shows numbers instead of "..." when any single player loses 2 to 99 workers within 15 seconds at any screen aspect ratio. Note: if more than one player loses workers within overlapping 15-second time windows, the losses for each player will appear in separate panels, even if they are on the same team.
Hallucinated workers no longer count as Worker Kills.
Clarification: MULE kills do not count towards Workers Killed. Blizzard doesn't account for MULE kills in the 1v1 Workers Killed panel, so for consistency, neither do we.
|
Bug fixes and tweaks:
Dropship pings will only trigger if they are greater than 10 spaces apart or 5 game seconds apart. (i.e. You can have two simultaneous distant pings, or two pings in the same place 5 seconds after the other, but multiple dropships picking up from the same location at the same time won't usually set off multiple pings unless you're setting up one really giant doom drop.)
Nydus worm notifications have been added, they work pretty much the same way as unmodded StarCraft 2 observing.
All pings are now yellow in color to match the look of the standard Nydus notification.
Ping timers stay on the screen for less time, as they now run in "game seconds" instead of real-time seconds.
Dropship health is no longer relevant to create a ping, only the health & shields of the units inside must be full. This is what we had originally intended, but we had to figure out a bug.
|
I love all of it. I have 3 questions
1. Is there a way to bring back the panoramic map preview before each match?
2. Also why aren't they using Gameheart in any of the WCS matches?
3. Can we get any of these upgrades added to the Gameheart observer UI?
|
1. That would be Ryan Schutter's decision, but my guess is that it's not a priority right now.
GameHeart 1.0 needed an in-game lobby to sort players from observers. The countdown was then added to be a slick interstitial between the in-game lobby and actual gameplay, so that players could get ready to start playing.
GameHeart 2.0 uses the Blizzard lobby system instead, which has upsides (no way for observers to interfere with gameplay, better for the replay system) but there's already the standard 10-second countdown after the Blizzard lobby. Adding another 10-second delay after that seems a bit redundant. And tournaments now have their own custom map previews to distinguish their broadcasts from other productions (e.g. BaseTradeTV) so that niche is being filled.
2. See Cloaken's comment on this: http://www.reddit.com/r/starcraft/comments/1ygjmx/gameheart_overlay_banned_from_wcs/cfkm4wa
3. If you're not running a mod, the Custom UI system can only show what the unmodded game provides by default. You can move elements around and add extra images, but additional functionality really needs to be computed at the mod level. As far as we can tell, none of the MIT notifications will work solely at the Custom UI level, but you can use a Custom UI on top of our mod to customize how our notifications look. For instance, it's totally possible to remove the English words or progress bar from the upgrade notifications, change fonts around, make things bigger or smaller, etc. without editing our mod's code.
|
I tried it and I love it no complaints
|
|
|
|
|
|
Store
WCS
Heroes of the Storm![[image loading]](http://i.imgur.com/aqVvSEs.png)
![[image loading]](http://i.imgur.com/dcpknrb.png)
