Why would I give up fixed operational expense of distributing my game and instead pay Amazon computing resources everytime one of my users played? The more you use, the more you pay. The more users you have, the more revenue you will need to cover the cost of the computing resources needed to run the game for your players.
Not to mention if you ever need to get off of Appstream there is no migration path, because you used their SDK to build your game.
So there is a high level of lock-in, and its introducing a cost structure that is coupled to the usage of the app. If using Appstream helps your apps be more successful, then it also helps you give more of your profit margin to Amazon.
You want to introduce a higher, linear cost structure just so users who don't have the hardware can play the game? I can see the excitement of solving that as a technical problem.
What I can't see, however, is a huge hole in the marketplace that is underserved which would justify the additional risk. This is not a "service," because it fundamentally changes your business model.
It is actually quite easy to integrate your app/game into AppStream, with minimal changes to the code. EVE Online integrated their Character creator in 3 days, with a team of 5 people, and they had to add touch.
on the cost structures: my guess is this is primarily aimed at the type of game developers who build upon a MRR (monthly reoccurring revenue) model - from WoW through to XBox-Live type gaming. Being server based particularly lends itself to multiplayer gaming where network latency should be zero and MRR is most common.
It's basically OnLive for mobile but you bring your own distribution channels.
This isn't going to compete with casual games you would natively run on devices for a fixed deployment cost.
I don't see that as a problem. My guess is, even if you remove the barrier to entry by not requiring strong hardware to run the game, you still have to turn someone that has had no previous motivation to play hardcore games, to now play those games simply because they can.
Sure, those who would love to play these games without chasing hardware will, but I can't imagine that's worth the additional, continual cost of rendering the game in the cloud and piping it over the network.
Very similar to what was proposed by Firefox/OTOY/AutoDesk [1]. OTOY is using Amazon so there appears to be some overlap there [2].
Wonder if Amazon licensed any OTOY technologies.
Latency is still a limiting factor is all of these. For some apps it would be ok like Excel but anything requiring precision is going to be a horrible experience. This morning my TWC was delivering data from all sites at 3K/sec.
Agreed. Numecent is tackling delivering applications in the cloud from a different angle. They have a technology called CloudPaging[0] that breaks an application up into different pages which are requested from the cloud when needed. It loads the initial set of pages needed to start the application and the loads other pages as needed. It's definitely another interesting approach...
Just an anectote about app/game streaming: I've recently played Orcs Must Die 2 on OnLive, a game-streaming service, and was very much surprised by the responsiveness! I think that probably a lot of apps/games will work just fine.
Yeah I think this type of stuff will depend a lot on buffering/rendering technology. You can imagine that it would be a terrible experience if it literally sent your keypress to the server, registered it in a game & then sent back the screens display pixels.
But I imagine (as with online gaming systems) that the experience is much more like... server loads the necessary rendering resources into the devices RAM/storage and then gameplay occurs the same as if files were loaded from a CD/other media.
I'm sure you could learn more by digging deeper but I imagine it is something more along those lines -- advanced API for a rendering engine.
> You can imagine that it would be a terrible experience if it literally sent your keypress to the server, registered it in a game & then sent back the screens display pixels.
I doubt this is the case because in order to play a game on any platform you'd first have to account for the different architecture. Furthermore, one of the core reasons this tech was even created was so that people with low power hardware could play the latest and greatest. There's no way a tablet is rendering game instructions to begin with, let alone virtualized instructions.
The truth is I/O is much slower then networking. Many LCD displays do image processing which results in it being several frames behind the one the GPU is currently pushing out. So between your desktop and your monitor could be 70ms of latency. On top of that there's the delay in input devices.
If streamers could maintain 30ms of network latency then it's just a minor difference from the system baseline.
If the streamers are smart they could colocate with the game servers. Then that 30ms of network latency is there regardless, home system or streaming system. It effectively adds no lag for streaming.
Wow. These two announcements from Amazon today have been really interesting. I work at a community college and we're constantly investigating VDI and vApp solutions. With the heavy push towards a more cloud-ready infrastructure, it'll be interesting to see how our upper management approaches this platform. A lot of ya'll seem to be arguing about gaming -- but I see other highly demanding software being used -- CAD, Maya, Blender, AfterEffects, etc. All of which will be on-demand. We won't have to invest so heavily in up front hardware costs just to handle our typical overwhelming periods.
[anecdote] We've licensed our CAD software to have 100 "seats" available at any time. We also (try to) reserve that much hardware to be available. We only ever see maybe a 5-10% utilization throughout the semester with ~200% utilization in the last 3 weeks of the semester (When util >100%, users are queued). That's a lot of waste and still isn't acceptable to the majority of our professors and student body. While it'd be great if we could retask that hardware to justify its cost when not in use, we simply can't. We need that hardware to be available for these applications at a minute's notice.
I can see this being a huge win for education or independent studios who are just starting out.
The previews for this product are stunning: this is not the first company providing this king of service, but well.. it's Amazon. Even though the cost will be initially a little high, its very likely that's worth it. Amazon has an undeniably powerful infrastructure, and AppStream could give a boost to app development. I love especially the multi platform support features, which are a tremendous relief for developers.
If you come at the AWS booth, the Appstream team will show you a few cool things, such as the character creator for the MMORPG Eve Online: http://t.co/22FpUB1ot6 (screenshot)
I am surprised the server side is windows. If you stream your app to a device the server platform does not matter, and would have thought linux to be the first choice in that case.
That's not entirely the case - the application has to run in the environment, and for legacy apps (which most application virtualization is targeted at) Windows is a pretty decent bet.
On top of that the App-V/XenApp packaging suite are top notch and provide avenues for enterprise integrations. (I'm making a big leap assuming it's built on one of them, but it doesn't really make sense to build from scratch, as interoperability/portability would be a hassle)
I was initially excited, wondering how we could leverage this, but now I'm perplexed by: "currently supports streaming applications from Microsoft Windows Server 2008 R2."
I would have thought Linux would have been the optimal server environment too.
Sounds like what AppStream is going for is Windows applications hosting, with the user I/O being shuttled to a non-Windows device. In that case, Windows Server is the only logical choice.
Is the price of the g2.2xlarge instance included? I couldn't find that anywhere... that would be another .767 / hour.
They REALLY need a killer app here to demonstrate the use case where this is worth the price. You need an application that has very high computation needs that is being used on a platform with limited computation ability BUT has a solid internet connection (preferably low-latency, if you want it for "twitch" type gaming, but not necessary in all cases). The example in their video is a FPS. I don't think that's a good example, as it is way too expensive for that market.
I'm not saying this isn't a fair price given the technological constraints, but that basically means we're going back to the pay per hour model of gaming, a la AOL. That's going to be an expensive game.
As I understood it, the point was for games which should be always-on. That said, A heavy gamer on a WOW-like game could be 120 hours a month, which would be on the same order of magnitude.
What I mean by fair price is that this is not an easy thing that they're proposing -- enough bandwidth and hardware to play a game. It may cost more than you would expect to deliver a high quality experience. However, the value to consumer isn't there for 83 cents an hour.
Not to mention if you ever need to get off of Appstream there is no migration path, because you used their SDK to build your game.
So there is a high level of lock-in, and its introducing a cost structure that is coupled to the usage of the app. If using Appstream helps your apps be more successful, then it also helps you give more of your profit margin to Amazon.