[kin]

You make a good point but all the best streamers absolutely need good hardware to be able to a stream high quality video feeds at a good frame rate. In addition, they get sponsored by hardware companies to mention what hardware they're using. There is no doubt eSports is selling hardware. Counter Strike is really not as popular in eSports nowadays as moba.

[eterm]

Counter-strike global offensive is actually one of the fastest growing esports. It gets more monthly viewer hours than DOTA (outside of The International, DOTA doesn't get many viewers), although is still some way behind LoL.

However, CSGO majors viewing figures went from ~150k to ~300k to ~1mil to ~1.2m for the last few majors, so it's growing really fast.

[ddorian43]

I think you get (random?) items in the game when you view these events in CSGO, so many people are viewing with multiple accounts.

[danielvinson]

There is a small chance that a case drops for you which is worth $5-$40 depending on which map you are watching that contains "Souvenir" items for the event signed by the players.

You only get drops if your Steam account that owns the game is linked to a twitch account that is watching, and is IP restricted (you won't get more drops unless you watch from different IPs at the same time). View botting exists, but it requires a lot of time/money to do, and the Twitch viewership numbers are actually more accurate than you would think.

[moistgorilla]

I'm pulling numbers out of my ass but I would really be surprised if more than 100,000 of those viewers are duplicate accounts. To do the duplicate viewer thing you need to own multiple accounts with a copy of the game on each one.

[duiker101]

You too make a good point but again, not all streamers are in eSport, take PewDiePie or any minecraft streamer. Streamers(and sponsors on teams/players) I would say are more of a medium of advertising space more than something that you see and think "I want it because it's going to make my life better". The only case in which the "product placement" makes sense is for peripherals, a good keyboard/mouse and other accessories can make a difference.

Obviously not everything is black an white but I think that the reasons why "the PC industry is being saved" are way more that just eSports.

[serge2k]

Selling hardware, sure. How many orders of magnitude less than the availability of steam?

I do think that twitch and the lets play community have done a lot though.

[daheza]

Sometimes these streamers are even buying a second box and using a capture card to send the video to their streaming PC.

[spacecowboy_lon]

Which is how Podcasters do it have a slave pc to run skype

[derefr]

I find it really weird that in inherently "networked" games (where there is a concept of a shared deterministic game-session physics-frame counter), the PC playing the game has to be the same PC rendering the game. You can recreate exactly the same view each player has from that player's outgoing network traffic! Thus, some alternatives to rendering on the user's own GPU come to mind:

1. instead of those HDMI-path recorder middleboxes, you could have an Ethernet-path renderer+recorder box and put all the heavy GPUs there. (Note that, if you don't care about streaming precisely "live", the rendering and recording no longer need to be dataflow-synchronous; you could play the whole game, buffer the network data into the rendering pipeline, and then it would sit there rendering the results for however long you wanted to give to achieve a desired "quality" bound. Effectively, you're doing the same thing as people who stream their commentary of a finished match by rendering off the replay-file the match; but in this case, the "replay file" is streaming to the renderer as it's being created.)

2. You could have an in-game option to asynchronously stream the session data to a cloud GPU instance and render the game there. (Or, y'know, if any of the game infrastructure providers really knew what they were doing with the Internet, they could offer those instances themselves, for a profit.)

3. Or, with the game studios' cooperation, just throw the whole edifice of local rendering away, capture the "replay" data for every match to the studio's data-centers, and then provide a service for cacheable just-in-time rendering of any replay data. Effectively, the game studio would say "whenever you play a match, we render a video from each player's perspective and post it immediately"—but without the need to actually do that (or keep said videos around long-term), because the video is entirely "computed state" that can be recreated from the replay files at any time.

4. One step more: a sudio could even provide an HTML5 "enhanced viewer" interacting with such a render-farm-backed CDN, that let people change perspective of the action themselves, to switch between the perspectives of the players and other views, sort of making such a viewer into an HTML5 thin-client for the game engine on the renderer instance (but without game-state-manipulation logic.) Imagine such a viewer as an embeddable iframe, like a YouTube video. A replay commentator could walk through a session as they would in-client to store a camera-movement-record on the server, get a permalink to the embeddable "video" for that, and then feed it to MashupTwitch along with commentary audio. Presuming the thing that gets embedded is an iframe of the same rendering service, though, any given player could "break out of" the commentated-on view to look around at what else is happening in the game at any time (pausing the commentary mash-up and starting up an extra renderer), and then, when they're done, restart the commentary (terminating the renderer instance and resuming the parent session from where it was.) All the control of being a spectator for a physical sport; all the convenience of a DVR.

---

Mind you, with such a shift, you no longer get "for free" the compositing of the game session video-feed with other things going on on your PC, like voice/webcam recording. But it's simple enough to create a "mash-up" site that plays a raw video-stream from a game-renderer service, and then syncs and overlays a much-more-diminutive 96kbps audio stream from the user's own computer. Twitch would likely grow to serve that market that if the components were in place.

The important thing about this change, though, is that with remote async game-session rendering, you could actually stream games on a less-than-stellar internet connection (you'd still need low latency to play at all, but high bandwidth would no longer be a concern.) So many of my friends living in rural, under-served-by-ISPs areas wish they could stream, but can't.

[pjc50]

Lots of games used to offer "demo record" modes that did this - saving the data layer rather than the video. Or a "spectator mode". However, rendering it requires the exact same version of the game (including all mods) and typically there's no facility for high-fanout "spectator mode".

[derefr]

> rendering it requires the exact same version of the game (including all mods)

It feels like (most) studios are really dropping the ball on this one. Event-sourcing through "rules engines" isn't that hard; you can have a client that "remembers how to be" every past version of the client, network-sync/replay-sync wise. You just need to go into the game architecture phase knowing you're building a networked game.

As a free bonus, when you build a game engine this way, you can also "audit" ladder/tournament matches by (asynchronously!) running through the game physics on the server after the match, before letting the match determination influence each player's ranking. (And doing your cheat-detection post-match really eases the requirements on the client sync protocol!)

It's harder with mods, unless your mods are also cleanly separable into "presenter-level" and "rules engine" parts. Not that I've seen this particular innovation before, but if the "rules engine" parts of mods are all in some common bytecode, the particular "house rules" required to run a replay could be embedded in the replay itself, along with package URLs for fat clients (and renderer instances) to pull down the presenter bits as well.

[eterm]

HLTV does precisely that kind of proxying of demo data. You can view games en-masse in-client.

The data is usually 32tick which isn't as good as the live game (64tick or 128tick) but watchable.

[kqr]

Demos were also rarely recorded with the same precision as the live rendering.