ZeroK-RTS
Spectator Panel Redesign
This is a working demo of a new design for the spectator panels. This is a work-in-progress, presented for early feedback.
Features:
- Everything (mostly) that's in the current spec panels
- Single unified panel layout, no separately-enabled individual panels
- Symmetric layout, with the two sides mirroring each other
- Economy stats: Total income, extraction / generation, reclaim, OD, and storage bars
- Unit stats: Total metal value for all units, offense, defense, and generators
- Unitpics showing:
- Commanders remaining on the field and their level
- Top four fielded unittypes as measured by total metal value, and their unit counts
- Number of mobile constructors
- Balance bars, showing graphically the relative advantages between sides in:
- Metal income
- Metal extraction (as a proxy for territory control)
- Military (metal value of offense plus defense)
- Attrition
- Pretty background pictures:
- For 1v1 they indicate each player's initial factory
- For team games they show something relevant based on teamsize
Limitations:
- No selectable font size options
- No selectable opacity options
- No selectable size limit for long vs. short playernames
- No resbar delta arrows
Notes:
- The stats display is updated every two seconds so the numbers don't jump around as badly while you're trying to read them
- The stats are smoothed over a three-second moving average to better show prevailing trends instead of momentary spikes
To Do:
- Fix energy stats. I copied code from other widgets but I don't understand it, and the results are wrong.
- Add resbar flashing on e-stall / metal excess / energy waste
- Layout and skinning tweaks
- Tooltips for everything
- Finish collecting background screenshots
- Interesting graphical effect underneath win counter to designate winner of the previous game
- Selectable alternate layouts:
- Small: takes up less space but uses smaller fonts
- Compact: fits better in small screens but sacrifices some aesthetics
- Colorblind colors
- Context menu
- Fancy skinning (?)
- General clean-up
- A gazillion bugfixes
Invitation for feedback: @GoogleFrog @sprunk @KingRaptor @Licho1 @dvr333 @Anarchid @Aquanim and anyone else who cares to comment.
Please note that I'm aware the code is very messy in places and that I already have plans to clean it up. Much of what's there is scaffolding left over from my experiments with layouts. Regardless, suggestions for improvement are welcome.
I have not tested this in live games, only local games and replays.
Looks fancy. Some feedback:
- I don't think you need the text "Wins:", just have a large number. Perhaps disable the numbers if they are both zero unless a setting is set. Most games spectated will not be rematches so this would only be relevant for casts and tourneys.
- The panels take up some of the most important space on the UI. I've been working on making the top of the screen thin and I think the current spectator panels are about the limit of what should be placed in the top center of the screen. The large panels at the top of the screen give a bit of an irregular pillbox effect and reduce the useful game visual area by too much. If you removed the unit icons and bottom two advantage bars it may be thin enough.
- I've decided that the minimum supported screen size for ZK is 1280x768 and your panels are only just fitting on a 1920 wide screen. The top left and top right thin UI panels that hold the menu and little buttons should be the same size and the menu does not get much smaller than it is now.
- The list of unit icons contains very little information in the teamgame and probably quickly loses meaning in 1v1. There are often more than 5 unit types in use. Perhaps group them by role and then display image of the type that is most common. This only really works for units with well defined roles like constructors or AA.
- I made the windows of the basic spectator panel separate so people could have some always enabled and toggle others. For example they may want to always see the economy and only sometimes want to see a force comparison.
@sprunk, @GoogleFrog - Thanks for the code review. I'll incorporate your suggestions as I clean up the code. Understanding how the energy stats work will be a challenge; any further pointers would be appreciated.
@GoogleFrog:
Good idea re not enabling the Wins by default, and auto-detecting when there's a rematch.
I'm very sensitive to how much space this layout takes up. I'll be making it thinner, but even so, I think we'll need multiple layouts to support a range of screen sizes. I'm thinking: compact for less than 1080p, standard for 1080p, and large for larger than that. Smaller versions can show less information and have a less interesting design. The presets widget can autodetect the screensize and choose which version to display; users can then override it with an option if they wish.
Standard can drop the unit icons, and probably the clock (I think the advantage bars are the most important part of the spec display). Compact can drop the unit icons and clock, drop the background image, drop the names and the top bar, and arrange the advantage bars horizontally in a thin bar across the bottom, plus make the fontsize smaller.
@sprunk:
I'm unsure about background screenshots. I think I'd prefer if this was something simple, for example a render of the factory or its most iconic unit (with llt/hlt/annihilator or whatever for small/medium/large teams). I generally dislike depicting a specific game scenario with parts of an unrelated map etc (even if it's just a beauty shot). More importantly, this allows the picture to have dynamic teamcolors (to look way more coherent).
That's more-or-less what I was going for, with each bg image showcasing two iconic units from the factory - one small, one large. Only the top quarter of the image is really visible, and the rest just provides a textural background for the rest of the frame to help distinguish the two sides (I intend to have multiple images for each teamsize and choose them so that each side is always different).
But I think I understand what you're suggesting, and I'll try some mockups in that direction and see how it looks.
- if you're averaging then they might not be jumping around that much?
- all other displays refresh at 1s so people might assume this one is lagging
- 2 does not divide 3 so there's a minor skew (only really relevant for spikes but still)
Even with averaging, a one-second refresh makes it hard to read a large display with lots of stats. The three seconds is a rolling average, i.e. it's always the last three seconds averaged no matter when the update happens, so there's no skew.
Thanks for the feedback! I probably won't be able to do any updates for a couple of weeks, but will keep working on it as I'm able.
NB: To check whether there are wins check WG.WinCounter_currentWinTable.hasWins.
I'm going to PR an update to the internal documentation of win_counter.lua to include that info (which needs a rename to api_win_counter.lua)
As for aesthetics, while I feel like you took everything I mentioned wanting in a spectator display and mashed it into one, I agree with Googlefrog that it's really tall and should be more modular. Also, what does "G" and "E" mean? I'm not even looking for an answer so much as the realization that these panels are almost more for the audience than the caster, so there should be as much clarity as possible. The current panels showing "Reclaim" is clear, this one showing "R" is not. (within the assumptions that the audience is English-speaking, but that's a localization question, and my casts are in English anyway)
@CrazyEddieTK
it's always the last three seconds averaged no matter when the update happens, so there's no skew
Let's say update happens on even seconds.
Let's say some stat has a constant 0 value except a one-second spike of value 3X happens at some point.
If the spike is on second 5: the update on second 6 will take seconds 4, 5 and 6 -> (0 + 3X + 0) / 3 -> a value of X is shown for the next 2 seconds and that's it.
If the spike happens on second 6: the update on second 6 takes 4,5,6 -> shows X for the next 2 seconds, then the update at 8 takes 6,7,8 and again shows X for the next 2 seconds (since both these periods include second 6).
In the first case you get shown 2 seconds of X, in the second 4 seconds of X, while in reality there were (the equivalent of) 3 seconds of X.
This is a nitpick but it's also trivial to fix (preferably by making the update period 1s, but if you want to stick to 2s you can make the moving average take 4s).
@dvr333
The current panels showing "Reclaim" is clear, this one showing "R" is not.
Current panels say Re, at least in your own casts: https://www.youtube.com/watch?v=MjoO4G-sMm8&t=0m30s
@sprunk: Thanks, I see now what you're getting at. I don't think it's an issue; the display isn't intended to be an accurate gauge of metal accumulated ("last interval it showed X, this interval it showed X, intervals are two seconds, therefore there's been 4X accumulation"). It's intended to be a reasonable estimate of current rate of income with the spikes smoothed out, so you can tell who's doing well and who's falling behind.
My intuition is that two seconds of averaging would be too spiky, and four seconds would be too laggy (if updates are on even seconds, and a mex was destroyed at t=0.5, the mex's contribution to income would still be partially included in the t=4 update, not disappearing entirely until the t=6 update). But it's easily adjustable in the code; we can do trials and see what people like. We can even make the update and averaging intervals options so people can override the defaults if they really want to. But of course we should make the defaults whatever we think will be best for most people.
@dvr333: Thanks, I'll use that API when I make more fixes.
Perhaps the scheme for alternate layouts will provide both the space savings and modularity that you and GF are looking for. I'll work on it.
Maybe we can find or make icons for generation/extraction, reclaim, and OD. That way they'll at least be equally difficult to understand for everyone. :) Either way, I think having tooltips showing the details and using the spelled-out words will help. People might be briefly confused, but will quickly learn what they mean if they hover over the bar. Icons would make a nicer-looking presentation, too.
Base generation can be the ibeam with the plus or perhaps the stylized mex. Overdrive can be the ibeam with the energy icon overlayed, this may have been deleted from the repository. Reclaim can be the reclaim cursor.
Perhaps remove the current unit types display and replace it with a collapsible display on the left and right sides of the screen. This display could show many rows of units arranged down each side. This collapsible display could be toggled by clicking on the Unit Value panel and that panel could be its own floating UI component. This would allows the central display to be thinner and fit on smaller screens.
I like the four comparison bars and it is good to stack them vertically but they extend too low. Perhaps stack them in a 2x2 grid with income/extraction as one group and military/attrition as another?
The attrition rate calculation here seems to do a duplicate of what Attrition Counter does. Current state of the Endgame Stats widget is that it also collects the information relevant for calculating attrition rate separately and while respecting visibility.
This data is thus now being collected in triplicate. A good idea would be to make both Attrition Counter and Spectator Panel use data provided by Endgame Stats instead of doing their own collection.
That said,
P.S i really dig the balance bars for attrition and income ratio stats.
One of the open tasks here is to move much of the stats collecting out of the spec panel widget and into the stats collector gadget, as much as it makes sense to do (which may be all of it). I'll do that when I get back to working on this panel (Sprunk has done a lot of that work on the stats gadget already).
Don't let the unimportantness discourage you too much. The return on investment here seems low (an improvement in the quality of spectating/casts) but it is positive and worth working on at some point. If this is what you want to do then do it. Quite a bit has been improved by people working on projects like this, it all builds up. Ideally the spectator panels would reach a state where they can be enabled by default and automatically toggled on in the appropriate situation. The current panels are not quite at that point, mostly due to placement issues with the floating economy panels.
I've thought a bit about what could be more helpful, since it has come up. You write like a native English speaker and seem to have some common sense regarding PR the most efficient work for you is probably in preparing the text and screenshots for a media pack (I hear it is a good idea to have one). However, if you have preexisting video creation skills then creating an updated trailer is probably the way to go.
The panel seems to have an error:
[f=0011714] [cawidgets.lua] Error: Error in UnitReverseBuilt(): [string "LuaUI\Widgets\gui_chili_specpanel_ng.lua"]:585: attempt to index local 'ud' (a nil value)
[f=0011714] [cawidgets.lua] Error: Removed widget: Chili SpecPanel - Next Gen
https://github.com/ZeroK-RTS/CrashReports/issues/1940