a few years ago, you needed to replace your graphics card every other year to play new games.
This is both irrelevant and untrue.
Untrue, because any decent game at that point would be able to turn the settings down to where you could play on older hardware. You still had a quicker upgrade cycle, but it wasn't that bad, especially if you stay just behind the curve -- you could often buy at least a new video card for under $100, and when the PS3 came out, it was possible to build a new gaming PC for less.
Irrelevant, because there were at least 5 or 6 different sound card manufacturers when we had to check for that. There seem to be even more now, but I'm not sure, because it doesn't matter -- sound has "just worked" for awhile, because we use higher-level abstractions like DirectSound and OpenAL, so your game can just play sound and it just works.
So, even if I needed a new video card every few years, I can still play the original Half-Life with the same shiny new video card I used to play Portal 2.
I didn't say "corss-platform", you did. I said "somewhat portable across hardware," which is true -- you can develop a game for nVidia, ATI, and yes, even Intel, and if you stick to the API, you don't need code specific to any of those cards.
Too late. My current video card has many times more RAM than my first computer. It also has two GPUs, which can perform certain tasks ridiculously faster than my CPU despite "only" operating at a few hundred megahertz. Tons of stuff can be trivially offloaded to the point where the CPU is just coordinating things, and we hardly even need such a low-latency connection, at least for non-game-related task.
ARM chips are so small, cool, cheap, such a small power draw that they're insignificant next to everything else on that board, but there are still things that even a modest ARM chip could do much better than a GPU. Still, it's not a replacement for a good CPU -- it's more a console on a card, and still not really, you still almost certainly want a decent CPU doing some of it.
anyhow, graphics AND game logic(game physics) are very closely connected.
I didn't say physics, I said logic. Physics is traditionally part of it, but it's getting to the point where it could be as external as graphics. There's a lot of stuff which doesn't need to impact gameplay, and would be problematic if it did. For example:
...a game is full of let's say grass thats shaded, but while that grass has no meaning to gameplay or even ai's field of view).
Suppose the grass were treated as solid, so that it was difficult to walk through -- the player could easily be "stuck" between blades of grass. Obviously, you want to move past that to even more realistic physics, where the player simply tramples the grass. Still, as a player, I'm not in complete control of my avatar, so for a lot of situations, it makes sense to give me a relatively simple environment. Probably the cleanest solution is to treat the field of grass as a single surface with the special property of "has grass", so if we want it to have gameplay effects, do it from that perspective.
Affecting AI FOV is similar -- tricky to do right, probably much easier to just say "Hey, there's grass there," and treat it as a solid block with a fixed value of translucency, so you're less likely to be noticed/shot if you're hiding behind it.
Do that, and you avoid a bunch of hard problems, you hopefully avoid the NWN issue, but you can also have tons of individual blades of grass, so vivid you could smell them, waving in the wind. That's the kind of thing I would think you could do without the CPU, both to improve the eye candy and free the CPU up for more interesting things -- AI, maybe.
It's got a sandbox. ActiveX didn't. ActiveX is for writing plugins; this is for building faster webpages.
only without a dominating monopoly
Google doesn't dominate search?
and OS integration
Granted, it's not integration into a monopoly OS, but it's integrated into Chrome OS.
Now, on to the real points:
There are just too many architectures capable of browsing the web now,
Really?
I count three that anyone cares about anymore: ARM, x86, and x86_64. If you're feeling generous, PPC and PPC64. And if you compile one nacl binary for, say, x86, that'll run on Windows, Linux, and OS X. Only reason the x86_64 plugin doesn't do the same (yet) is that Chrome, like all browsers, has stuck with 32-bit only for Windows and OS X until various plugins (*cough* Flash) get proper 64-bit support.
There's also an LLVM variant in the works. You compile to LLVM bytecode, the client compiles it to native code when it's downloaded.
and some of the most important ones will never support a feature like this (read: iOS).
Somehow, I think Android is more important than iOS, and for that very reason.
But how do you know this would never be supported on iOS? It already allows alternative browsers, and that's assuming Apple doesn't adopt this idea. You could make a point that Apple has a vested interest in keeping web development limited on iOS, but so far, they seem to have done just the opposite -- Safari is generally recognized as a decently modern browser with decent standards support, and they often introduce new and interesting things of their own (CSS animations, some of them 3D IIRC).
Now, it may never fly for other reasons, like the fact that very few applications need this much of a performance boost over JavaScript without also needing more than NaCl offers yet (like fast 3D -- can I draw from my NaCl library to WebGL without going through the browser and JavaScript?)
Still, it's an interesting enough idea, and this seems to be the direction things are going. Suppose I can deliver a modern game to you in a browser -- with bandwidth getting faster, I bet I could get you into a demo of my game in under a minute, without you having to install it from some random download site. And even if it were Chrome-only, that's still more portable than Steam -- but there's no reason it has to be Chrome-only.
albeit in a custom executable format, and I couldn't find information about the ABI...
As I understand it, there are two formats. I remember the nexes being derived from ELF, but I can't find it now. There's also the Portable NaCl, which is some form of LLVM bytecode, so that it can be compiled on the client so as to natively support any architecture, without having to ship them C source.
So, Chrome already sandboxes JavaScript in some of the same ways that they'd sandbox NaCl, but it's not the parser. JavaScript is a relatively simple language, syntactically, and any decent implementation isn't going to be fucking around with it on that level.
My guess is that it's a choice of which APIs you expose and when they're allowed to be called. Since JavaScript can't generate code which ultimately does anything other than call methods or access properties, it entirely comes down to which methods or properties you expose.
I don't think this will be better than JavaScript. I do, however, think it will be better than ActiveX. At the very least, it's actually sandboxing stuff.
That's probably the most interesting thing he said all day. Throw an ARM core on the GPU, provide some sort of standard API for using it, and you eliminate all those pesky latency issues. Modern GPUs have enough RAM that one could potentially push the entire renderer onto the GPU, with the CPU and main memory only being responsible for game logic.
Of course, he also seems to be implying that this might go the other way, with integrated graphics winning out...
I mean, the main criticism for id games has been that they are less games and more tech demos. Practically every game engine id ever sold has been used for much more interesting games by other people, but id still gets license fees.
If they don't invest in R&D, why are they doing their own engine design at all, and more importantly, just what are they investing in?
And even if you're right about OpenGL and DirectX being "crappy", which I highly doubt, the fact is that they are at least somewhat portable across hardware. Suppose he's right, and Intel integrated graphics suddenly win. If they went directly to the hardware, as you suggest, they'd need to port their game to Intel cards, or that game wouldn't work with those cards. We'd be back to the bad old days when you actually had to check the system requirements for your sound card and video card manufacturer.
The "problem" is the experienced person might have forgotten how (or refuse) to write crap even though it's faster. Doing things right often takes longer.
That depends.
Writing crap can get you a mockup out the door faster. However, once you need that mockup to even be a prototype, doing things right (or close to right) can be faster. Take even a medium-size web app, maybe Facebook in its infancy, and compare adding a feature with and without decent test coverage -- with decent coverage, I can change just about anything and be confident that when the tests show green, I haven't broken anything.
...It takes time to learn how to do all that given a new framework and platform.
Certainly, but most of it can, in fact, be put off until we have time. For example, exception handling -- what you want, during development, is to fail fast and loudly. A decent framework should at least give you a stacktrace when you crash. Unless you're deliberately going against the grain of the framework, it should be trivially possible to capture those safely later on, and to add proper exception handling when you know what to do with it.
So they'll just go for "quick and cheap" and deal with the bugs/problems later after they get the $$$$$$ from the customers:).
I'm fine with that, so long as the design allows for them to be fixed. A lot of what you mentioned is hard to screw up through your own poor design, particularly if you're using a framework. An example of something which is easy to screw up is testing -- you won't necessarily know how you need to hook into your code to properly test it unless you're writing tests, and you won't know what tests to write when you're looking at the code months from now. More importantly, doing tests now is going to make development faster, while correct signal handling and multilingual support really isn't.
Hey it worked for Facebook didn't it? Start quick and dirty with PHP and MySQL, once you get money, hire lots of very smart people to fix/workaround PHP and MySQL;).
And this is where the experienced person would be useful. Start quick and dirty, yes, but don't start with PHP and MySQL -- anyone can see that'll be a bitch to scale. I hate to be a fanboy, but if they started with, say, Ruby on Rails, yes, they'd likely need more servers now, but they'd also likely find it much easier to migrate away from MySQL to another SQL engine -- and if they used DataMapper, it'd be even easier to switch to something entirely different. The focus on REST and HATEOAS means it's easy for your own apps to talk to each other, so if you need to switch to an entirely different project, you can sanely do it piecewise. The same is true if they'd used something like CakePHP or at least an ORM.
(Unfortunately, neither was realistically possible for Facebook -- Rails was released the same year Facebook was founded, and Cake was inspired by Rails.)
Yes, they have the money to do it right now, but it's also a much bigger project now. They're past the point where it makes any sense to scrap the project and start from scratch on another platform. Things like hiphop are expected, it's just kind of disappointing that they're doing this with PHP.
As an almost-25-year-old, I agree wholeheartedly. Partly because I've learned (hopefully) to not work 80-hour weeks and to look for the 200-line solution, but mostly because I've learned to value input from those who do have experience.
Of course, it's the 25-year-old who will also be able to put in an 80-hour week and learn a new language, platform, or framework. The 55-year-old, if he's good, is still likely to be slower at this, and if he's less good, is likely to grumble the whole time about why didn't we just stick to lanugage $x and tool $y which did the job just fine. Sometimes he's right, but he still needs to be flexible in that way.
Put another way, suppose that 55-year-old gets into (or is forced into) web development. If he has trouble switching from a mindset of, say, C or C++ to Ruby or PHP, he's going to be miserable, always complaining about how inefficient and type-unsafe everything is, instead of focusing on the real problems. Which is a shame, because he still could be more than twice as productive as those 25-year-olds, but a single 25-year-old, even hacking PHP, would easily be twice as productive as a 55-year-old C++ veteran trying to write a web app in C++.
"You can hire two 25 year old for your rate, but are you twice at productive?"
As an almost-25-year-old, I'm learning to appreciate what people can learn in decades of programming. Some of my professors are terrible, but some have a lot of depth of understanding of things like C and C++ which would be extremely valuable in a real project. You'll be many years beyond making a lot of the classic, simple mistakes, and you'll at least be at the point where you'll see flaws in a design (from experience seeing similar designs fail) that others won't.
You won't be twice as productive in the measurable ways, like SLOC or issues closed per day or whatever, but those were never really measuring anything useful anyway. The more meaningful things are hard to measure -- how often does your code produce obscure bugs which will be discovered months later and take days to fix? How often will you design something in a way which is so rigid you practically need a rewrite to make a needed change -- or so much the other way that you spend more time writing the "flexible" version than it'd take to write several versions of the hardcoded version? Finding that balance is tricky.
On top of all that, you also don't have the additional communication overhead of those two 25 year olds.
The problem is, how do you actually sell that? How many companies actually understand that? It seems like ageism goes the other way -- I'm more likely to get a job than you simply because of my age, even if we were asking the same price. And that sucks -- I've definitely been on teams where we needed experience.
So, if the choice is between "have no income at all" and "do web development at the rates of an inexperienced programmer", I'll take the second one... However, if the choice is between "have a well paid job which I don't really like but allows me to live life comfortably" and "do web development, which I like, but barely be able to pull my family through", I know what I choose. It won't be the web development.
I think the idea here is that web development is supposedly easy enough that anyone can pick it up, whereas, say, mainframe assembly or COBOL is obscure enough that you might be hired for having the skill alone. The idea is that if you have the experience with a particular legacy system, that's worth far more than trying to train a 25-year-old, and they'll all be looking for fun stuff like web development.
Then again, I don't know if those pay better, and I do find the attitude a bit frustrating -- old programmers are only useful for old (legacy) systems? I imagine the demand might be higher there, but we need you in web development, too.
Yes, web developers do need to support multiple browsers. It may be worse with HTML5, but when I was a full-time web developer, it wasn't bad at all -- I spent maybe an hour a week fixing crap so it'd work in IE7 (we dropped IE6, thankfully) and everything else Just Worked -- we'd develop in Firefox (since it had Firebug, since this was before Chrome was as cross-platform as it is now, and before its dev tools could really match Firebug), and maybe once or twice a month there'd be an issue where it'd work in Firefox, and fail in any browser except IE.
It may not have been a deliberate snub, but I can't imagine it being too much of a problem for these guys to do the same. Even IE is getting decent, to where they might've easily supported IE9, maybe 8, and drop 7 or below.
Then again, there is one new issue with HTML5, which makes things like this much more likely -- not all browsers support the same things. While there's a very large subset that works across all browsers, it does mean that we also have to think about multiple browsers in the design phase, not just in the testing phase. That's significant -- it means we need to research cross-browser issues, not just add a few more browsers to our test cycle and debug things as they crop up. And that is the fault of the browsers -- alright, if you insist on having two wildly different local storage APIs, fine, but every browser needs to have them.
I saw that in reality, too. Then I realized that TV Tropes has grown to be so absurdly all-encompassing that it is impossible to tell any story which does not have multiple tropes in it. See "Tropes Are Not Bad."
Generally, players won't complain when a game is not realistic in a way which benefits them -- for example, being able to survive more than a shot or two in most FPSes is a feature, not a bug. Additional realism helps if it provides a challenge, but not when it's so much of a challenge that the game isn't fun anymore.
But logical consistency doesn't exist in the game independent of reality. For instance:
"Hey this game isn't realistic! I can't swim, explore over this mountain, etc..."
I've been playing Mass Effect recently. My character can't jump. He can sort of walk down off a very small ledge, but most bigger ledges are effectively walls. However, I can still inadvertently drive a tank off a cliff and die.
My biggest complaint here isn't the lack of internal consistency -- why can I drive a tank off a cliff, but I can't jump off a three-foot drop unless the game decides it's an appropriate thing to drop into?
No, the biggest reason "it's unrealistic" is a problem here is that it limits my freedom and kills the immersion in a single stroke. Never mind that I can pause the game and change my armor mid-combat, or that I have unlimited ammo and can heal myself and my teammates in seconds while being shot at. Where "it's not realistic" hurts, where it actually hits my suspension of disbelief in the balls, is that I'm not nearly as in shape as my character, but damnit, I could vault that fence, or drop down those three feet, or jump back up those three feet, or...
To give an example of inconsistency which doesn't really bother me, Mass Effect also allows me some amount of control over conversations I find myself in -- a dialog tree. There are minor annoyances here -- I obviously am limited in what I can say, and quite often, the dialog options are a little misleading, and my character will say something quite different than what I thought I was choosing. It's also a little jarring how obvious it is when a character is switching between one chunk of dialog and another -- there's no noticeable gap in the audio, but their avatar almost always visually snaps from the end of one to the beginning of another. While they do have emotions, these don't really color other bits of dialog except when it's been programmed to do so -- when I ask the cute alien girl about her culture, her answer is exactly the same whether or not I've just thoroughly embarrassed her about how she'd like to "study" me.
But for all its flaws, the dialog tree isn't nearly as jarring as when I have to walk around some bit of scenery because it was one foot tall and I can't jump on it. I suspect part of the reason is that the dialog tree has so many choices to begin with, so that it's not terribly often I actually can't say something like what I want. If I could only climb a wall in a few scripted ways, even if it was incredibly awkward to step over a two-foot barrier, it'd still be better than having the two-foot barrier be impassable.
The point isn't so much that Counter-Strike is realistic, certainly not by modern standards, but that it's much more realistic than, say, Quake.
Quake 3 -- everyone runs ridiculously fast all the time while shooting fairly accurate rockets at each other, and it can often take multiple rockets to blow up someone who's wearing armor. Only the very best weapons have a chance of one-hitting someone, and most battles revolve around both players circle-strafing and generally running around each other while shooting madly. There are no clips, you just shoot until you're out of ammo, then switch to the next weapon and repeat. Everyone could respawn all the time, and one player could last the entire game (theoretically) by running into health and armor.
Counter-Strike -- everyone runs at speeds which are at least believable, if not sustainable (certainly not while pointing a gun in front of you), you're not going to be able to shoot at all accurately while running. Reloading is unrealistic, but at least you have a limited clip size and have to "reload" at all. Headshots -- especially in Source -- tend to kill people, unless the gun is incredibly weak and the person is wearing a helmet. There's no "health" pickups or respawning weapons and such, you just fight till its over. Once a player's dead, they're dead till the next round, so each round is a scenario to think about...
I mean, yes, you can still kill someone by shooting them in the foot, or if you don't kill them, they can still run on that foot and suffer no adverse effects till they're actually dead -- but then, doing it that way is hard (what, you're going to simulate the entire human body?) and not necessarily more fun. The same can be said for a lot of the other tradeoffs in Counter-Strike.
I like over-the-top games (I actually enjoyed Duke Nukem Forever, and I love Quake 3), but I also appreciate the attempt for some amount of realism within whatever world and constraints you've got. I loved that Halo had a damned good reason the Chief survived as much punishment as he did, and why he was so much better than anything else in the game (human or alien), but not every game should have to be sci-fi in order to have gameplay which doesn't involve dodging every single bullet.
Why not just patch Steam itself? To the extent that Valve has any control over this at all -- that is, to the extent games aren't also including crap like SecuROM -- the game is more or less asking Steam whether it's authorized, or whether the user is online, etc. Seems to me, Valve could simply patch Steam to allow perpetual offline mode without the initial registration -- problem solved.
Said patches would have to be tested and distributed. At a time Valve would be closing up shop that's a lot of additional expense they could not justify.
That's a bigger worry. While I don't think they'd be terribly difficult to create or distribute, any additional complication could spell death for the project.
Someone suggested creating the patches now and putting them in escrow. I'd rather see legal and financial resources in escrow such that a developer could be hired to finish the job.
Not to mention that at the same time, people who relied on "oh I can redownload any time I want" will start to hurriedly redownload ALL their games to back them up before Valve will be gone.
I can see this being a big problem, though not entirely insoluble. Here's a scenario:
Valve stops Steam from updating games.
Valve directs users to a torrent tracker they run -- or even to a third-party -- on which "backups" of each game are stored. You can create these today, so no code has to be written to support these.
Gamers who care about this and are currently panicking because of the updating issue go torrent those games. This is exactly the sort of traffic BitTorrent is designed for.
If DRM is still an issue at all, gamers are warned to install from those backups now.
Valve releases the final patch for Steam.
Steam auth servers are shut down.
If DRM is an issue at all, the final Steam patch would disable installing from those backups, and change the backup mechanism to produce different, incompatible backups. I have to imagine that they wouldn't care at this point, though, so maybe the final patch would allow installing from backups without verifying that it's a legitimate Steam account. This would effectively make the games DRM-free, but also massively pirated the moment that patch hits the Internet, since we now have legitimate torrents which can easily lead to installing a game you never owned.
However, this route requires a minimum of bandwidth (a torrent tracker would be bad, but nowhere near as bad as their CDN, and someone else would probably do it for free) and a minimum of development on their part (they're removing things from Steam, so no new features need be developed.) If they care about the DRM, it requires removing more features and a bit more coordination with the community, but it still seems possible.
Why wouldn't they be able to release a patch before it was sold or liquidated? I get that after the deal there'd be no choice...
But I agree it would mean a lot if the patches existed today. Only problem is, if so much of the HL2 source was "obtained" and released on the Internet, I have to imagine the same would happen to the patch -- and I also have to imagine the patch would be difficult to maintain and test while being kept in escrow.
Maybe it'd be better to put enough financial and legal resources in escrow such that a developer can be hired to create and release the patch if Steam's service ever dies. (Not just if Valve itself dies, but if the service does.)
They've actually started warning us (sometimes) as one of the little badges or stats about a game, when it has additional DRM, like SecuROM. This stopped me from buying Arkham Asylum.
With Steam itself, though, it's not up to the game. Steam decides whether or not you can play offline, what your account is, etc. I don't think they'd have to patch the game -- just patch Steam itself to function offline, or to pretend to be online (so LAN play still works), and no need to patch games at all.
Doesn't matter. If you care, publish debs and RPMs (especially if you have an apt or yum repository so we get updates that way too) and 99% of the Linux gaming community is ecstatic. If you don't, publish tarballs and 100% of the community is still happy.
IMO, the best yet model on Linux has been to distribute a demo, including the engine and almost all the content, under a license which lets Linux distros repackage and redistribute it themselves. Then, with that installed, you can provide an easy means for people to install the rest of the content once they purchase it.
What library versions do you have?
Don't be obtuse -- on Windows, almost everything ends up statically linked. Most games do that on Linux, too, or include copies of the libraries they care about. I'd much rather they link against system libraries and keep up to date, but that's not necessary.
What about the windowing system, since there is more than just one?
Not really. How many Linux gamers use anything but Xorg?
And WTF are you doing messing with the windowing system anyway? Even something as low-level as glut will let you flip to fullscreen at a desired resolution regardless of operating system, so why do you think that the choice of windowing system within the same OS will matter?
It really makes it difficult to release a product when Linux has so much variety based on what the system owner wants it to look like.
Ok, I'll bite.
How is this different on anything outside consoles and smartphones -- in other words, any open platform, where "open" includes Windows, OS X, Android...
Take Windows, since that seems to be the defacto standard. Ok, do we require Vista/Win7, or do we also support XP? If you support XP, you pretty much have to support DirectX 9, because 11 requires Vista -- doesn't matter that some hacker on the Internet backported, because if you're going to make people install hacked custom drivers from the Internet just to play your game, you've completely lost the "support" advantage. So now you're either stuck with DirectX 9, or you need to support multiple versions of DirectX. And what if the user has outdated drivers?
And then you DO have the issues of hardware support, where Blizzard would need to help troubleshoot why your fresh Debian install doesn't get sound on your machine but your friend who has a one year old Redhat machine can run it perfectly...think you would be happy to have support tell you they don't provide support and the problem is with your Linux install? Would you accept that if you were running Windows and had them tell you to contact Microsoft for anything that doesn't work?
If it's that sound doesn't work at all, then I think that's perfectly reasonable -- contact Microsoft, or your sound card manufacturer, or (more likely) something like Dell.
Other than that, how many times do you get a hardware issue specific to a game? The few I've had, I've been able to solve in a few minutes of Googling, and as a Linux user, I'd much rather have a port that refers me to the community when appropriate, than no port at all.
There are also support advantages here -- when something goes wrong, Blizzard has the entire Linux source, and likely the source for every component of your distro other than the video drivers, and that code is mostly going to be the same as on Windows. That isn't to say that it should be their job to fix the OS, but it does mean that when the problem is actually with the OS and not with their code, they at least have a chance of offering a patch.
Probably a much more practical advantage is that it is possible for Blizzard to produce a livecd (or dvd), probably not terribly hard to make the game disc itself bootable, which would allow people to verify whether the issue was with their hardware, or with Linux support for t
I think what happened here is that Blizzard noticed how well WoW works with an "always on" mode -- no one complains about being forced to be "always on" for a game in which single player (even against bots) makes no sense. They're trying to do what I've always suggested, which is to provide enough incentive for having a legitimate online copy so that people want to buy the game and welcome the DRM mechanism.
What they're trying to do is get back to the days where a legitimate copy of the game is better than a pirated copy, or at least equal, rather than worse, and they're trying to get there without throwing out the DRM entirely.
Problem is, it's difficult to do this with a single-player game, and as you say, forcing people to be online rather than enticing them to be online is a different matter.
Steam lets me play offline for extended periods of time, yet I almost always play online, and I actually want a Steam version when it's available. Ok, I don't care as much about their community, but the social stuff is cool -- one click to go from an IM conversation with a friend to launching and joining a game they're in, and still have the IM conversation within easy reach. More than that, I like that when I bought a new machine, I booted it up, installed Steam, downloaded Portal 2, and it was ready to go with all my settings (keymappings, etc) and savegames.
I think that's the better route here -- if it's truly a single-player game, use the carrot rather than the stick. If it's truly a multi-player game, you can afford to be a lot more restrictive, though it'd still be cool if Starcraft 2 had a LAN mode -- maybe some sort of relatively-cheap blanket license for a LAN party, something like $5 per person for the weekend.
But then, I'm still operating under the assumption that GP is right, and that this was an attempt at justifying the DRM, rather than a feature people actually want.
You're talking here about a world in theory where people can't do the things they might want unless a software developer makes it happen first.
That is by definition true, often more than one. Software developers wrote X, for one thing. I'm not sure what your point here is, though.
The design goal for infrastructure software should be (imho) to make things possible without extra coding. From this point of view, a special client/server design is not superior to a higher level of abstraction, it's just more efficient for that one case.
Your italics almost make that look like a dirty word...
A certain amount of efficiency is needed as a baseline, first of all. The use case you describe, where I'm running an app on a nameless box in a different city, is not something I can ever see scaling well with something like VNC or OnLive -- that is, with a truly generic model where we just capture the app's output and stream that as video over the network.
Yet from what I understand, that's how most modern apps work when X is used as a backend. They draw pixmaps and send them to the server. Works great locally, falls over completely in the "nameless server in another city" use case.
We could conceivably add enough to X so that things like Cairo will work efficiently over the network, but that only works so long as people actually use those libraries. Sooner or later, someone will try something interesting which isn't supported directly by our higher-level GUI abstractions, which means we're back to sending either pixmaps or GL triangles across the network, which doesn't scale.
Some apps use X efficiently enough now that they work well remotely, and that's fine. Most apps don't generate enough traffic or require enough performance for it to be a problem over a LAN, and that's fine, though these apps would work equally well under VNC -- all X buys them here is easy ssh-forwarding and rootlessness. I love ssh and rootless remote windows, but I can't see that being a make-or-break feature compared to, say, local video performance.
But the thing is, we can't really know how people might want to combine apps and hardware resources if given the chance. The LCD with an impatient person waiting for a screen refresh today might turn out to be a robot or script tomorrow. And if an app needs just a bit of rewrite to work efficiently over the network...
This is why I tend to suggest that most apps should be written for the Web. It enables everything we are talking about:
Enough local code that you can do new stuff efficiently -- if SVG isn't good enough, you can roll your own with Canvas.
Unless you go out of your way to be difficult, this pretty much implies a remote API, which means bots and scripts are easy.
Cross-platform and likely to work far into the future -- in 2020, barring websites developed for IE6+ActiveX, you'll probably be able to open websites from 1995 on whatever device you want.
Client/server, without any developer effort other than using the Web in the first place. I might develop a web UI to use locally and then trivially deploy it over a LAN.
Lets users combine stuff in unexpected ways. Userscripts (Greasemonkey), extensions, apps which connect to yours via its implicit API, bookmarks, tabs, a back button... Tons of stuff you get almost for free.
Downsides right now are that it's less convenient to use than, say, GTK+ or Qt -- but those have X11 backends, and I bet HTML is much more convenient than raw X11. Aside from the tooling issue, this is something you can use right now, without having to fix X11 first (or buy dedicated fiber lines to every presentation room).
In ten years or so, we've already gone from dialup speeds to fast pipes that allow streaming HD. That's equivalent to sending a fully drawn pixmap several times per second (with compression).
While it is nice to have the ability to do this without application support, the better approach when this is a design goal of that particular application is to implement client/server for that application.
Suppose, for example, that the application has some vector graphics to display. With the X model, either we need to teach the X server to deal with vector graphics, and support all the things our application needs, or the application is going to draw to a local buffer and send a raw image to the display. This is what most applications do, which works fine locally, but sucks over a network -- you're sending a raw bitmap with every update -- which is why I believe VNC has options for lossily compressing the video.
And then maybe you want to animate it a bit. Now we need to teach our application -- and, potentially, X -- to morph our vectors around in clever ways. And imagine if our app decided to draw its own bitmaps again, which means we now need the X protocol to support efficiently streaming live video just to run our application. Every app now has the same bandwidth requirements as, say, OnLive.
Support for things like OpenGL is hardly a solution. What, should we send raw triangles over the network? Video cards are what drove the upgrade from PCI to AGP to PCI Express because they need that much bandwidth!
But of course, vector graphics are tiny. Even the program to manipulate them isn't that big, and it can be cached, or installed locally.
It seems to me that the only way to do this right is to allow people to run local code. If you don't trust them, run it in a sandbox. We have a platform that's trying to do this, actually -- the Web -- though, of course, I'm sure a dozen people will immediately point out a dozen things a local app can do slightly better now.
And if you're going to run the Web, or just plain local code, you're going to need some sort of local display to run it on. You could use X for that, but then we're back to this silly situation where the network transparency of X is useless.
Of course, this requires apps to be developed either for the Web or for your particular tablet platform. Then again, if your application was written in 1995, chances are, you can run it in the tablet in 2020, or at least over a less-efficient protocol like RDP or VNC. It's also not clear that an app written in 1995 with the assumption of a keyboard and mouse is going to be useful in 2020 without at least some updates to support input devices.
I would love if network transparency could stay. If Wayland ends up with network transparency, or if Xorg wins (and eliminates the problems that inspired Wayland in the first place), I will be ecstatic. It just doesn't seem likely.
Slashdot Mirror
a few years ago, you needed to replace your graphics card every other year to play new games.
This is both irrelevant and untrue.
Untrue, because any decent game at that point would be able to turn the settings down to where you could play on older hardware. You still had a quicker upgrade cycle, but it wasn't that bad, especially if you stay just behind the curve -- you could often buy at least a new video card for under $100, and when the PS3 came out, it was possible to build a new gaming PC for less.
Irrelevant, because there were at least 5 or 6 different sound card manufacturers when we had to check for that. There seem to be even more now, but I'm not sure, because it doesn't matter -- sound has "just worked" for awhile, because we use higher-level abstractions like DirectSound and OpenAL, so your game can just play sound and it just works.
So, even if I needed a new video card every few years, I can still play the original Half-Life with the same shiny new video card I used to play Portal 2.
I didn't say "corss-platform", you did. I said "somewhat portable across hardware," which is true -- you can develop a game for nVidia, ATI, and yes, even Intel, and if you stick to the API, you don't need code specific to any of those cards.
shit idea, computer on a board. yo dawg..
Too late. My current video card has many times more RAM than my first computer. It also has two GPUs, which can perform certain tasks ridiculously faster than my CPU despite "only" operating at a few hundred megahertz. Tons of stuff can be trivially offloaded to the point where the CPU is just coordinating things, and we hardly even need such a low-latency connection, at least for non-game-related task.
ARM chips are so small, cool, cheap, such a small power draw that they're insignificant next to everything else on that board, but there are still things that even a modest ARM chip could do much better than a GPU. Still, it's not a replacement for a good CPU -- it's more a console on a card, and still not really, you still almost certainly want a decent CPU doing some of it.
anyhow, graphics AND game logic(game physics) are very closely connected.
I didn't say physics, I said logic. Physics is traditionally part of it, but it's getting to the point where it could be as external as graphics. There's a lot of stuff which doesn't need to impact gameplay, and would be problematic if it did. For example:
...a game is full of let's say grass thats shaded, but while that grass has no meaning to gameplay or even ai's field of view).
Suppose the grass were treated as solid, so that it was difficult to walk through -- the player could easily be "stuck" between blades of grass. Obviously, you want to move past that to even more realistic physics, where the player simply tramples the grass. Still, as a player, I'm not in complete control of my avatar, so for a lot of situations, it makes sense to give me a relatively simple environment. Probably the cleanest solution is to treat the field of grass as a single surface with the special property of "has grass", so if we want it to have gameplay effects, do it from that perspective.
Affecting AI FOV is similar -- tricky to do right, probably much easier to just say "Hey, there's grass there," and treat it as a solid block with a fixed value of translucency, so you're less likely to be noticed/shot if you're hiding behind it.
Do that, and you avoid a bunch of hard problems, you hopefully avoid the NWN issue, but you can also have tons of individual blades of grass, so vivid you could smell them, waving in the wind. That's the kind of thing I would think you could do without the CPU, both to improve the eye candy and free the CPU up for more interesting things -- AI, maybe.
This is the new ActiveX,
It's got a sandbox. ActiveX didn't. ActiveX is for writing plugins; this is for building faster webpages.
only without a dominating monopoly
Google doesn't dominate search?
and OS integration
Granted, it's not integration into a monopoly OS, but it's integrated into Chrome OS.
Now, on to the real points:
There are just too many architectures capable of browsing the web now,
Really?
I count three that anyone cares about anymore: ARM, x86, and x86_64. If you're feeling generous, PPC and PPC64. And if you compile one nacl binary for, say, x86, that'll run on Windows, Linux, and OS X. Only reason the x86_64 plugin doesn't do the same (yet) is that Chrome, like all browsers, has stuck with 32-bit only for Windows and OS X until various plugins (*cough* Flash) get proper 64-bit support.
There's also an LLVM variant in the works. You compile to LLVM bytecode, the client compiles it to native code when it's downloaded.
and some of the most important ones will never support a feature like this (read: iOS).
Somehow, I think Android is more important than iOS, and for that very reason.
But how do you know this would never be supported on iOS? It already allows alternative browsers, and that's assuming Apple doesn't adopt this idea. You could make a point that Apple has a vested interest in keeping web development limited on iOS, but so far, they seem to have done just the opposite -- Safari is generally recognized as a decently modern browser with decent standards support, and they often introduce new and interesting things of their own (CSS animations, some of them 3D IIRC).
Now, it may never fly for other reasons, like the fact that very few applications need this much of a performance boost over JavaScript without also needing more than NaCl offers yet (like fast 3D -- can I draw from my NaCl library to WebGL without going through the browser and JavaScript?)
Still, it's an interesting enough idea, and this seems to be the direction things are going. Suppose I can deliver a modern game to you in a browser -- with bandwidth getting faster, I bet I could get you into a demo of my game in under a minute, without you having to install it from some random download site. And even if it were Chrome-only, that's still more portable than Steam -- but there's no reason it has to be Chrome-only.
albeit in a custom executable format, and I couldn't find information about the ABI...
As I understand it, there are two formats. I remember the nexes being derived from ELF, but I can't find it now. There's also the Portable NaCl, which is some form of LLVM bytecode, so that it can be compiled on the client so as to natively support any architecture, without having to ship them C source.
So, Chrome already sandboxes JavaScript in some of the same ways that they'd sandbox NaCl, but it's not the parser. JavaScript is a relatively simple language, syntactically, and any decent implementation isn't going to be fucking around with it on that level.
My guess is that it's a choice of which APIs you expose and when they're allowed to be called. Since JavaScript can't generate code which ultimately does anything other than call methods or access properties, it entirely comes down to which methods or properties you expose.
I don't think this will be better than JavaScript. I do, however, think it will be better than ActiveX. At the very least, it's actually sandboxing stuff.
Chromium is open source.
And yes, it's cross-platform and actually sandboxed. Unlike ActiveX, this actually would be a reasonable alternative to JavaScript.
Did anyone else catch that?
That's probably the most interesting thing he said all day. Throw an ARM core on the GPU, provide some sort of standard API for using it, and you eliminate all those pesky latency issues. Modern GPUs have enough RAM that one could potentially push the entire renderer onto the GPU, with the CPU and main memory only being responsible for game logic.
Of course, he also seems to be implying that this might go the other way, with integrated graphics winning out...
Really?
I mean, the main criticism for id games has been that they are less games and more tech demos. Practically every game engine id ever sold has been used for much more interesting games by other people, but id still gets license fees.
If they don't invest in R&D, why are they doing their own engine design at all, and more importantly, just what are they investing in?
And even if you're right about OpenGL and DirectX being "crappy", which I highly doubt, the fact is that they are at least somewhat portable across hardware. Suppose he's right, and Intel integrated graphics suddenly win. If they went directly to the hardware, as you suggest, they'd need to port their game to Intel cards, or that game wouldn't work with those cards. We'd be back to the bad old days when you actually had to check the system requirements for your sound card and video card manufacturer.
The "problem" is the experienced person might have forgotten how (or refuse) to write crap even though it's faster. Doing things right often takes longer.
That depends.
Writing crap can get you a mockup out the door faster. However, once you need that mockup to even be a prototype, doing things right (or close to right) can be faster. Take even a medium-size web app, maybe Facebook in its infancy, and compare adding a feature with and without decent test coverage -- with decent coverage, I can change just about anything and be confident that when the tests show green, I haven't broken anything.
...It takes time to learn how to do all that given a new framework and platform.
Certainly, but most of it can, in fact, be put off until we have time. For example, exception handling -- what you want, during development, is to fail fast and loudly. A decent framework should at least give you a stacktrace when you crash. Unless you're deliberately going against the grain of the framework, it should be trivially possible to capture those safely later on, and to add proper exception handling when you know what to do with it.
So they'll just go for "quick and cheap" and deal with the bugs/problems later after they get the $$$$$$ from the customers :).
I'm fine with that, so long as the design allows for them to be fixed. A lot of what you mentioned is hard to screw up through your own poor design, particularly if you're using a framework. An example of something which is easy to screw up is testing -- you won't necessarily know how you need to hook into your code to properly test it unless you're writing tests, and you won't know what tests to write when you're looking at the code months from now. More importantly, doing tests now is going to make development faster, while correct signal handling and multilingual support really isn't.
Hey it worked for Facebook didn't it? Start quick and dirty with PHP and MySQL, once you get money, hire lots of very smart people to fix/workaround PHP and MySQL ;).
And this is where the experienced person would be useful. Start quick and dirty, yes, but don't start with PHP and MySQL -- anyone can see that'll be a bitch to scale. I hate to be a fanboy, but if they started with, say, Ruby on Rails, yes, they'd likely need more servers now, but they'd also likely find it much easier to migrate away from MySQL to another SQL engine -- and if they used DataMapper, it'd be even easier to switch to something entirely different. The focus on REST and HATEOAS means it's easy for your own apps to talk to each other, so if you need to switch to an entirely different project, you can sanely do it piecewise. The same is true if they'd used something like CakePHP or at least an ORM.
(Unfortunately, neither was realistically possible for Facebook -- Rails was released the same year Facebook was founded, and Cake was inspired by Rails.)
Yes, they have the money to do it right now, but it's also a much bigger project now. They're past the point where it makes any sense to scrap the project and start from scratch on another platform. Things like hiphop are expected, it's just kind of disappointing that they're doing this with PHP.
As an almost-25-year-old, I agree wholeheartedly. Partly because I've learned (hopefully) to not work 80-hour weeks and to look for the 200-line solution, but mostly because I've learned to value input from those who do have experience.
Of course, it's the 25-year-old who will also be able to put in an 80-hour week and learn a new language, platform, or framework. The 55-year-old, if he's good, is still likely to be slower at this, and if he's less good, is likely to grumble the whole time about why didn't we just stick to lanugage $x and tool $y which did the job just fine. Sometimes he's right, but he still needs to be flexible in that way.
Put another way, suppose that 55-year-old gets into (or is forced into) web development. If he has trouble switching from a mindset of, say, C or C++ to Ruby or PHP, he's going to be miserable, always complaining about how inefficient and type-unsafe everything is, instead of focusing on the real problems. Which is a shame, because he still could be more than twice as productive as those 25-year-olds, but a single 25-year-old, even hacking PHP, would easily be twice as productive as a 55-year-old C++ veteran trying to write a web app in C++.
Define "reasonable"? And how is this an advantage over polygons, other than being CPU-only?
"You can hire two 25 year old for your rate, but are you twice at productive?"
As an almost-25-year-old, I'm learning to appreciate what people can learn in decades of programming. Some of my professors are terrible, but some have a lot of depth of understanding of things like C and C++ which would be extremely valuable in a real project. You'll be many years beyond making a lot of the classic, simple mistakes, and you'll at least be at the point where you'll see flaws in a design (from experience seeing similar designs fail) that others won't.
You won't be twice as productive in the measurable ways, like SLOC or issues closed per day or whatever, but those were never really measuring anything useful anyway. The more meaningful things are hard to measure -- how often does your code produce obscure bugs which will be discovered months later and take days to fix? How often will you design something in a way which is so rigid you practically need a rewrite to make a needed change -- or so much the other way that you spend more time writing the "flexible" version than it'd take to write several versions of the hardcoded version? Finding that balance is tricky.
On top of all that, you also don't have the additional communication overhead of those two 25 year olds.
The problem is, how do you actually sell that? How many companies actually understand that? It seems like ageism goes the other way -- I'm more likely to get a job than you simply because of my age, even if we were asking the same price. And that sucks -- I've definitely been on teams where we needed experience.
So, if the choice is between "have no income at all" and "do web development at the rates of an inexperienced programmer", I'll take the second one... However, if the choice is between "have a well paid job which I don't really like but allows me to live life comfortably" and "do web development, which I like, but barely be able to pull my family through", I know what I choose. It won't be the web development.
I think the idea here is that web development is supposedly easy enough that anyone can pick it up, whereas, say, mainframe assembly or COBOL is obscure enough that you might be hired for having the skill alone. The idea is that if you have the experience with a particular legacy system, that's worth far more than trying to train a 25-year-old, and they'll all be looking for fun stuff like web development.
Then again, I don't know if those pay better, and I do find the attitude a bit frustrating -- old programmers are only useful for old (legacy) systems? I imagine the demand might be higher there, but we need you in web development, too.
It's not as bad as it sounds...
Yes, web developers do need to support multiple browsers. It may be worse with HTML5, but when I was a full-time web developer, it wasn't bad at all -- I spent maybe an hour a week fixing crap so it'd work in IE7 (we dropped IE6, thankfully) and everything else Just Worked -- we'd develop in Firefox (since it had Firebug, since this was before Chrome was as cross-platform as it is now, and before its dev tools could really match Firebug), and maybe once or twice a month there'd be an issue where it'd work in Firefox, and fail in any browser except IE.
It may not have been a deliberate snub, but I can't imagine it being too much of a problem for these guys to do the same. Even IE is getting decent, to where they might've easily supported IE9, maybe 8, and drop 7 or below.
Then again, there is one new issue with HTML5, which makes things like this much more likely -- not all browsers support the same things. While there's a very large subset that works across all browsers, it does mean that we also have to think about multiple browsers in the design phase, not just in the testing phase. That's significant -- it means we need to research cross-browser issues, not just add a few more browsers to our test cycle and debug things as they crop up. And that is the fault of the browsers -- alright, if you insist on having two wildly different local storage APIs, fine, but every browser needs to have them.
I saw that in reality, too. Then I realized that TV Tropes has grown to be so absurdly all-encompassing that it is impossible to tell any story which does not have multiple tropes in it. See "Tropes Are Not Bad."
Wait, what do voxels have to do with allowing you to snipe from several KM away?
Generally, players won't complain when a game is not realistic in a way which benefits them -- for example, being able to survive more than a shot or two in most FPSes is a feature, not a bug. Additional realism helps if it provides a challenge, but not when it's so much of a challenge that the game isn't fun anymore.
But logical consistency doesn't exist in the game independent of reality. For instance:
"Hey this game isn't realistic! I can't swim, explore over this mountain, etc..."
I've been playing Mass Effect recently. My character can't jump. He can sort of walk down off a very small ledge, but most bigger ledges are effectively walls. However, I can still inadvertently drive a tank off a cliff and die.
My biggest complaint here isn't the lack of internal consistency -- why can I drive a tank off a cliff, but I can't jump off a three-foot drop unless the game decides it's an appropriate thing to drop into?
No, the biggest reason "it's unrealistic" is a problem here is that it limits my freedom and kills the immersion in a single stroke. Never mind that I can pause the game and change my armor mid-combat, or that I have unlimited ammo and can heal myself and my teammates in seconds while being shot at. Where "it's not realistic" hurts, where it actually hits my suspension of disbelief in the balls, is that I'm not nearly as in shape as my character, but damnit, I could vault that fence, or drop down those three feet, or jump back up those three feet, or...
To give an example of inconsistency which doesn't really bother me, Mass Effect also allows me some amount of control over conversations I find myself in -- a dialog tree. There are minor annoyances here -- I obviously am limited in what I can say, and quite often, the dialog options are a little misleading, and my character will say something quite different than what I thought I was choosing. It's also a little jarring how obvious it is when a character is switching between one chunk of dialog and another -- there's no noticeable gap in the audio, but their avatar almost always visually snaps from the end of one to the beginning of another. While they do have emotions, these don't really color other bits of dialog except when it's been programmed to do so -- when I ask the cute alien girl about her culture, her answer is exactly the same whether or not I've just thoroughly embarrassed her about how she'd like to "study" me.
But for all its flaws, the dialog tree isn't nearly as jarring as when I have to walk around some bit of scenery because it was one foot tall and I can't jump on it. I suspect part of the reason is that the dialog tree has so many choices to begin with, so that it's not terribly often I actually can't say something like what I want. If I could only climb a wall in a few scripted ways, even if it was incredibly awkward to step over a two-foot barrier, it'd still be better than having the two-foot barrier be impassable.
The point isn't so much that Counter-Strike is realistic, certainly not by modern standards, but that it's much more realistic than, say, Quake.
Quake 3 -- everyone runs ridiculously fast all the time while shooting fairly accurate rockets at each other, and it can often take multiple rockets to blow up someone who's wearing armor. Only the very best weapons have a chance of one-hitting someone, and most battles revolve around both players circle-strafing and generally running around each other while shooting madly. There are no clips, you just shoot until you're out of ammo, then switch to the next weapon and repeat. Everyone could respawn all the time, and one player could last the entire game (theoretically) by running into health and armor.
Counter-Strike -- everyone runs at speeds which are at least believable, if not sustainable (certainly not while pointing a gun in front of you), you're not going to be able to shoot at all accurately while running. Reloading is unrealistic, but at least you have a limited clip size and have to "reload" at all. Headshots -- especially in Source -- tend to kill people, unless the gun is incredibly weak and the person is wearing a helmet. There's no "health" pickups or respawning weapons and such, you just fight till its over. Once a player's dead, they're dead till the next round, so each round is a scenario to think about...
I mean, yes, you can still kill someone by shooting them in the foot, or if you don't kill them, they can still run on that foot and suffer no adverse effects till they're actually dead -- but then, doing it that way is hard (what, you're going to simulate the entire human body?) and not necessarily more fun. The same can be said for a lot of the other tradeoffs in Counter-Strike.
I like over-the-top games (I actually enjoyed Duke Nukem Forever, and I love Quake 3), but I also appreciate the attempt for some amount of realism within whatever world and constraints you've got. I loved that Halo had a damned good reason the Chief survived as much punishment as he did, and why he was so much better than anything else in the game (human or alien), but not every game should have to be sci-fi in order to have gameplay which doesn't involve dodging every single bullet.
They would have to patch every single game.
Why not just patch Steam itself? To the extent that Valve has any control over this at all -- that is, to the extent games aren't also including crap like SecuROM -- the game is more or less asking Steam whether it's authorized, or whether the user is online, etc. Seems to me, Valve could simply patch Steam to allow perpetual offline mode without the initial registration -- problem solved.
Said patches would have to be tested and distributed. At a time Valve would be closing up shop that's a lot of additional expense they could not justify.
That's a bigger worry. While I don't think they'd be terribly difficult to create or distribute, any additional complication could spell death for the project.
Someone suggested creating the patches now and putting them in escrow. I'd rather see legal and financial resources in escrow such that a developer could be hired to finish the job.
Not to mention that at the same time, people who relied on "oh I can redownload any time I want" will start to hurriedly redownload ALL their games to back them up before Valve will be gone.
I can see this being a big problem, though not entirely insoluble. Here's a scenario:
If DRM is an issue at all, the final Steam patch would disable installing from those backups, and change the backup mechanism to produce different, incompatible backups. I have to imagine that they wouldn't care at this point, though, so maybe the final patch would allow installing from backups without verifying that it's a legitimate Steam account. This would effectively make the games DRM-free, but also massively pirated the moment that patch hits the Internet, since we now have legitimate torrents which can easily lead to installing a game you never owned.
However, this route requires a minimum of bandwidth (a torrent tracker would be bad, but nowhere near as bad as their CDN, and someone else would probably do it for free) and a minimum of development on their part (they're removing things from Steam, so no new features need be developed.) If they care about the DRM, it requires removing more features and a bit more coordination with the community, but it still seems possible.
Why wouldn't they be able to release a patch before it was sold or liquidated? I get that after the deal there'd be no choice...
But I agree it would mean a lot if the patches existed today. Only problem is, if so much of the HL2 source was "obtained" and released on the Internet, I have to imagine the same would happen to the patch -- and I also have to imagine the patch would be difficult to maintain and test while being kept in escrow.
Maybe it'd be better to put enough financial and legal resources in escrow such that a developer can be hired to create and release the patch if Steam's service ever dies. (Not just if Valve itself dies, but if the service does.)
They've actually started warning us (sometimes) as one of the little badges or stats about a game, when it has additional DRM, like SecuROM. This stopped me from buying Arkham Asylum.
With Steam itself, though, it's not up to the game. Steam decides whether or not you can play offline, what your account is, etc. I don't think they'd have to patch the game -- just patch Steam itself to function offline, or to pretend to be online (so LAN play still works), and no need to patch games at all.
Which distribution do you have,
Doesn't matter. If you care, publish debs and RPMs (especially if you have an apt or yum repository so we get updates that way too) and 99% of the Linux gaming community is ecstatic. If you don't, publish tarballs and 100% of the community is still happy.
IMO, the best yet model on Linux has been to distribute a demo, including the engine and almost all the content, under a license which lets Linux distros repackage and redistribute it themselves. Then, with that installed, you can provide an easy means for people to install the rest of the content once they purchase it.
What library versions do you have?
Don't be obtuse -- on Windows, almost everything ends up statically linked. Most games do that on Linux, too, or include copies of the libraries they care about. I'd much rather they link against system libraries and keep up to date, but that's not necessary.
What about the windowing system, since there is more than just one?
Not really. How many Linux gamers use anything but Xorg?
And WTF are you doing messing with the windowing system anyway? Even something as low-level as glut will let you flip to fullscreen at a desired resolution regardless of operating system, so why do you think that the choice of windowing system within the same OS will matter?
It really makes it difficult to release a product when Linux has so much variety based on what the system owner wants it to look like.
Ok, I'll bite.
How is this different on anything outside consoles and smartphones -- in other words, any open platform, where "open" includes Windows, OS X, Android...
Take Windows, since that seems to be the defacto standard. Ok, do we require Vista/Win7, or do we also support XP? If you support XP, you pretty much have to support DirectX 9, because 11 requires Vista -- doesn't matter that some hacker on the Internet backported, because if you're going to make people install hacked custom drivers from the Internet just to play your game, you've completely lost the "support" advantage. So now you're either stuck with DirectX 9, or you need to support multiple versions of DirectX. And what if the user has outdated drivers?
And then you DO have the issues of hardware support, where Blizzard would need to help troubleshoot why your fresh Debian install doesn't get sound on your machine but your friend who has a one year old Redhat machine can run it perfectly...think you would be happy to have support tell you they don't provide support and the problem is with your Linux install? Would you accept that if you were running Windows and had them tell you to contact Microsoft for anything that doesn't work?
If it's that sound doesn't work at all, then I think that's perfectly reasonable -- contact Microsoft, or your sound card manufacturer, or (more likely) something like Dell.
Other than that, how many times do you get a hardware issue specific to a game? The few I've had, I've been able to solve in a few minutes of Googling, and as a Linux user, I'd much rather have a port that refers me to the community when appropriate, than no port at all.
There are also support advantages here -- when something goes wrong, Blizzard has the entire Linux source, and likely the source for every component of your distro other than the video drivers, and that code is mostly going to be the same as on Windows. That isn't to say that it should be their job to fix the OS, but it does mean that when the problem is actually with the OS and not with their code, they at least have a chance of offering a patch.
Probably a much more practical advantage is that it is possible for Blizzard to produce a livecd (or dvd), probably not terribly hard to make the game disc itself bootable, which would allow people to verify whether the issue was with their hardware, or with Linux support for t
I think what happened here is that Blizzard noticed how well WoW works with an "always on" mode -- no one complains about being forced to be "always on" for a game in which single player (even against bots) makes no sense. They're trying to do what I've always suggested, which is to provide enough incentive for having a legitimate online copy so that people want to buy the game and welcome the DRM mechanism.
What they're trying to do is get back to the days where a legitimate copy of the game is better than a pirated copy, or at least equal, rather than worse, and they're trying to get there without throwing out the DRM entirely.
Problem is, it's difficult to do this with a single-player game, and as you say, forcing people to be online rather than enticing them to be online is a different matter.
Steam lets me play offline for extended periods of time, yet I almost always play online, and I actually want a Steam version when it's available. Ok, I don't care as much about their community, but the social stuff is cool -- one click to go from an IM conversation with a friend to launching and joining a game they're in, and still have the IM conversation within easy reach. More than that, I like that when I bought a new machine, I booted it up, installed Steam, downloaded Portal 2, and it was ready to go with all my settings (keymappings, etc) and savegames.
I think that's the better route here -- if it's truly a single-player game, use the carrot rather than the stick. If it's truly a multi-player game, you can afford to be a lot more restrictive, though it'd still be cool if Starcraft 2 had a LAN mode -- maybe some sort of relatively-cheap blanket license for a LAN party, something like $5 per person for the weekend.
But then, I'm still operating under the assumption that GP is right, and that this was an attempt at justifying the DRM, rather than a feature people actually want.
You're talking here about a world in theory where people can't do the things they might want unless a software developer makes it happen first.
That is by definition true, often more than one. Software developers wrote X, for one thing. I'm not sure what your point here is, though.
The design goal for infrastructure software should be (imho) to make things possible without extra coding. From this point of view, a special client/server design is not superior to a higher level of abstraction, it's just more efficient for that one case.
Your italics almost make that look like a dirty word...
A certain amount of efficiency is needed as a baseline, first of all. The use case you describe, where I'm running an app on a nameless box in a different city, is not something I can ever see scaling well with something like VNC or OnLive -- that is, with a truly generic model where we just capture the app's output and stream that as video over the network.
Yet from what I understand, that's how most modern apps work when X is used as a backend. They draw pixmaps and send them to the server. Works great locally, falls over completely in the "nameless server in another city" use case.
We could conceivably add enough to X so that things like Cairo will work efficiently over the network, but that only works so long as people actually use those libraries. Sooner or later, someone will try something interesting which isn't supported directly by our higher-level GUI abstractions, which means we're back to sending either pixmaps or GL triangles across the network, which doesn't scale.
Some apps use X efficiently enough now that they work well remotely, and that's fine. Most apps don't generate enough traffic or require enough performance for it to be a problem over a LAN, and that's fine, though these apps would work equally well under VNC -- all X buys them here is easy ssh-forwarding and rootlessness. I love ssh and rootless remote windows, but I can't see that being a make-or-break feature compared to, say, local video performance.
But the thing is, we can't really know how people might want to combine apps and hardware resources if given the chance. The LCD with an impatient person waiting for a screen refresh today might turn out to be a robot or script tomorrow. And if an app needs just a bit of rewrite to work efficiently over the network...
This is why I tend to suggest that most apps should be written for the Web. It enables everything we are talking about:
Downsides right now are that it's less convenient to use than, say, GTK+ or Qt -- but those have X11 backends, and I bet HTML is much more convenient than raw X11. Aside from the tooling issue, this is something you can use right now, without having to fix X11 first (or buy dedicated fiber lines to every presentation room).
In ten years or so, we've already gone from dialup speeds to fast pipes that allow streaming HD. That's equivalent to sending a fully drawn pixmap several times per second (with compression).
While it is nice to have the ability to do this without application support, the better approach when this is a design goal of that particular application is to implement client/server for that application.
Suppose, for example, that the application has some vector graphics to display. With the X model, either we need to teach the X server to deal with vector graphics, and support all the things our application needs, or the application is going to draw to a local buffer and send a raw image to the display. This is what most applications do, which works fine locally, but sucks over a network -- you're sending a raw bitmap with every update -- which is why I believe VNC has options for lossily compressing the video.
And then maybe you want to animate it a bit. Now we need to teach our application -- and, potentially, X -- to morph our vectors around in clever ways. And imagine if our app decided to draw its own bitmaps again, which means we now need the X protocol to support efficiently streaming live video just to run our application. Every app now has the same bandwidth requirements as, say, OnLive.
Support for things like OpenGL is hardly a solution. What, should we send raw triangles over the network? Video cards are what drove the upgrade from PCI to AGP to PCI Express because they need that much bandwidth!
But of course, vector graphics are tiny. Even the program to manipulate them isn't that big, and it can be cached, or installed locally.
It seems to me that the only way to do this right is to allow people to run local code. If you don't trust them, run it in a sandbox. We have a platform that's trying to do this, actually -- the Web -- though, of course, I'm sure a dozen people will immediately point out a dozen things a local app can do slightly better now.
And if you're going to run the Web, or just plain local code, you're going to need some sort of local display to run it on. You could use X for that, but then we're back to this silly situation where the network transparency of X is useless.
Of course, this requires apps to be developed either for the Web or for your particular tablet platform. Then again, if your application was written in 1995, chances are, you can run it in the tablet in 2020, or at least over a less-efficient protocol like RDP or VNC. It's also not clear that an app written in 1995 with the assumption of a keyboard and mouse is going to be useful in 2020 without at least some updates to support input devices.
I would love if network transparency could stay. If Wayland ends up with network transparency, or if Xorg wins (and eliminates the problems that inspired Wayland in the first place), I will be ecstatic. It just doesn't seem likely.