Deus Ex: Human Revolution – Graphics Study
adriancourreges.com
adriancourreges.com
If your first play through involved killing people, try completing the game non lethally (except for the boss fights) for an achievement.
Also: Ceilings of Deus Ex http://imgur.com/a/FDAbV
Also: Michael McCann's soundtrack: https://open.spotify.com/album/4LuVQCHTgUZjuWgUQ7lQbl
The internet joke about the original Deus Ex is that every time it’s mentioned, someone reinstalls it, but I think this just convinced me it’s time to replay Human Revolution.
It looks like in the sequel they're using that even more to indicate the golden age renaissance of augmentation is fading away.
https://www.youtube.com/watch?v=q2kd7F3YFz8
Also McCann is coming back for the score which makes me happy. I still have this soundtrack and listen to it often.
Finally, off the new trailer, anyone see the Megan Reed parallels with the leg augmented guy?
I was also recently listening to that soundtrack. Kind of excited to see this thread, sometimes I think I'm the only person that loves this game.
There were several places during my initial run-through where I found myself having to grab a pen and paper in order to keep track of things like small AI conversations in passing which lead to new side objectives.
I am really looking forward to the next one!
I'm hoping that they address one of the main letdowns of Human Revolution, that the hub environments were a bit sparse and lacking more NPCs to make them feel like real locations. I listened to the game commentary and apparently that was simple a limitation of the engine they used.
My biggest complaint was that the central high-brow concept they pushed--"is augmented man not man", "are we playing god", et al.--was just woefully underexecuted. I felt more empathy for poor Gunther in the first Deus Ex worried about being phased out than I did for anyone with or without augs in DX:HR.
As presented, for example, augs were strictly the better option if you could afford them. There wasn't any downside to piling them on, nobody in the game gave two shits whether or not you were man or machine. No quests really changed if you were really chopped up. It just felt phoned in and handwaved.
Even the gameplay and combat itself didn't support this--there was no real "Oh no, they've got augs, ruh roh" to speak of, except maybe the boss fights. In the first game, for example, you go up against a fellow with augs as blinged out as yours, and it really really shows. The somewhat augmented humans are a bit harder to fight.
However, in this one, augmented humans or not can all be effectively one-shotted during stealth. There's no real feeling of "Oh, watch out, some of these troops are notably better"--contrast with, say, how in Dishonored or Bioshock you could run into enemies with similar abilities to yours.
And the ending...oy vey.
I agree with the rest of your post, but this was pretty much explained by saying that ALL the augs Jensen has are already installed in him at the beginning of the game. Them being unlocked as the game goes on had more to do with Jensen getting used to controlling them (as opposed to having them installed and being able to use them then and there).
When so much is being made of that difference, it's sad that the player is given so little agency in the matter. There's not even much being done in the way of reactions from NPCs about the augs.
Also, I did feel there was a bit of an enemy progression throughout the game (cloaking troops, bigger bots), but it was mostly just more complex level design, which in a way I prefer to just "tougher" enemies. I think this was kind of necessary for supporting a pacifist play style.
But then IIRC I think I read somewhere that the A.I. was just scripted, and I probably lost some interest in it.
But does anyone know a bit more on that? Is it really just a scripted I.A. ?
I quickly learnt that most players want a gratifying and somewhat predictable experience. If you can predict and "out-think" the enemy you feel good and and you can handle the incredible odds that the game pits against you. Intelligent AI is actually at odds with this goal.
An AI also needs to be very controllable to meet story-line needs or just so that you can tweak it to fix over any issues. Many approaches to AI are very "black box" and so would fall down here.
If you've played F.E.A.R, you can see how very good / strong AI makes the game extremely hard on the player. And that AI is actually rather simple from a programming standpoint, not like a simulated brain or anything.
The debug/developer menu of DX1: https://tcrf.net/images/2/2b/Deusex-legendmenu.png
More info: https://tcrf.net/Deus_Ex
Far Cry 1 had a great and very extensive game AI, all done in Lua script. On the other hand the AI in Call of Duty is basic and a lot of scripts make it look like a Hollywood movie (almost rail shooter).
Almost no combat game has true IA.
Hero enters room doorway > Trigger 4 guards who walk down a path towards him > If hero appears within x amount of pixels then attack. (take no cover, do nothing dynamic, and just wait to be killed)
Hero enters middle of room > Trigger 4 guards who walk down...etc
I believe F.E.A.R. has regarded as having excellent AI that dynamically worked against the hero. If he had a shotgun they'd stay back. If he made noise they'd rush him. If he was quiet, they'd wait. Decent writeup here:
http://aigamedev.com/open/review/fear-ai/
A lot of players really want that level of AI in their games. I can't say I blame them. Its a completely different experience. Of course, cheap/free multiplayer and co-op kinda solves that problem or at least makes a big investment in AI a disincentive.
2. Deus Ex: Human Revolution titles - http://www.artofthetitle.com/title/deus-ex-human-revolution/
http://www.bbc.com/news/science-environment-17769529
http://www.artofthetitle.com/title/deus-ex-human-revolution/
The wardrobes were great in Deus Ex 3. But overall Deus Ex 3 was a huge let down for many who played Deus Ex 1 back in 2000.
Deus Ex 1:
Many things that made Deus Ex 1 so special and made it an all time classic, a game that is one of the best five games ever made. The awesome story plot, the many different walk-trough paths (thousands), the inventor, the health system, the hacking, the interactive environment (breaking things, moving things ...all saved to the save file), the music, the huge levels (for 2000), ... the game is just superb (just the Unreal 1 graphics hasn't aged that well).
Random gameplay video: https://www.youtube.com/watch?v=41GmwHq6sGY
http://en.wikipedia.org/wiki/Deus_Ex
90 of 100 on metacritic: http://www.metacritic.com/game/pc/deus-ex
Deus Ex 2 was already a let down as it was geared towards the XBox1 which meant incredible small levels (there was a loading screen between every other room) and the whole roleplaying system was extremely simplified - e.g. there was only one ammunition for all weapons. Beside that it was a good game with great physics system for 2004.
http://www.metacritic.com/game/pc/deus-ex-invisible-war (80 of 100)
Deus Ex Clan Wars (renamed to "Project Snowblind" at release) was an off-spin with a different story but similar game play (a bit more action oriented but still with augmentations and stealth). http://en.wikipedia.org/wiki/Project_Snowblind
Deus Ex 3 had tiny levels (Detroid was like two blocks with multiple loading screens), there were only two hub-cities and a lot of fake background to make the tiny levels look like it played in a city (Part 1 had larger levels 11 years before), the graphics was already dated on release date, the graphics were very orange in the original edition later the turned down the shader effect in the directors cut edition, the story was boring and simple in comparison to Part 1, boss fights that were implemented by an outsourcing company and felt very weird, sudden camera changes to third-person-view with one button stealth-kills and other weird design decisions that some console gamers may have liked.
http://www.metacritic.com/game/pc/deus-ex-human-revolution (90 of 100, but apparently many never heard or played the first two games to have a real comparison, the game with another name attached isn't bad for itself at all)
Deus Ex 4 that was first released only for Wii and later also for PC was just bad (metacritic score 45 of 100): http://www.metacritic.com/game/pc/deus-ex-the-fall
For the upcoming Deus Ex 5 I hope that Warren Spector from Deus Ex 1 comes back and shares his game design vision with the team. He is literally a game design god and fame and he is currently a professor at a game design university: http://en.wikipedia.org/wiki/Warren_Spector
Warren Spector recently did an AMA on Reddit: https://www.reddit.com/r/IAmA/comments/34fdjb/hi_i_am_warren...
Warren Spector discusses a post mortem of Deus Ex 1 and 2 in video: https://www.youtube.com/watch?v=GTWvsGA77T4 (Part of Warren Spector's Master Class at the University of Texas)
Deus Ex 1 used the Unreal 1 (Unreal Tournament) engine, Deus Ex 2 used Unreal 2 engine, Deus Ex Clan Wars used the Crystal engine (based on Tomb Raider Legends), Deus Ex 3 used the Crystal engine (based on Tomb Raider Underworld), Deus Ex 4 used Unity and Deus Ex 5 will use an improved Glacier engine (based on Hitman Absolution): http://en.wikipedia.org/wiki/Deus_Ex:_Mankind_Divided
For example the game was supposed to have 4 hub levels (with 5 being considered once). It was going to be Detroit (that they seemly wanted bigger), Lower Hengsha (in-game as intended) Upper Hengsha (they built the city, but could not put content in it, so you see it as background art when you are inside a building that is located in Upper Hengsha), Montreal (they had to cut it off completely and in a so unexpected way that they had to do some storyline mucking-up to explain how the character get in the newspaper office in Montreal)
They considered once adding a Indian city, but that was only consideration (different from Montreal, that was written but not made in 3D, and Upper Hengsha, that was made in 3D but had no content)
They also cut lots of other random stuff, and the game kinda shows, there are lots of places that is unclear why you can't go there, or why there are some plot holes here or there, also the boss fights are obvious (and broken... since I was doing a stealth playthrough I could only win by using bugs, except the first boss, where my klepto tendencies led me to having a crazy amount of explosives...
the server-room boss I only won after the boss collision had a bug and the boss got stuck in a wall, allowing me to shoot it without retaliation, mind you, it still took 2 and a half minutes and almost all ammo in the room to kill the boss, not nice... there was that boss you can win with a knockout move, and the final boss that you could skip the entire fight by abusing a certain weapon (although probably not intended by the devs, that one they should NOT fix, because it makes perfect sense)
Isn't that true for ever game?
Deus Ex 1 also was planned to be a lot bigger. The Design documents of Deus Ex 1 and all the parts that were never in the game (like the White House level): http://www.nanoaugur.net/dx/bible/
What's so sad is that the game design team of Deus Ex 3-5 has forgotten or never read the game design documents of the first two games.
"As it turns out, those boss battles weren't designed at Eidos Montreal, they were outsourced to a studio called Grip Entertainment" -- http://kotaku.com/5841910/those-horribad-deus-ex-human-revol...
http://www.rockpapershotgun.com/2011/09/19/deus-ex-hrs-boss-...
http://www.pcgamer.com/deus-ex-human-revolution-boss-fights-...
I always felt the boss fights were so out of place in DX3 and one cannot solve the game without killing unlike Deus Ex 1 were it is possible to play through without killing a single person!
The Grip Entertainment game AI company has been dissolved to Autodesk as it seems: http://gameware.autodesk.com/news/press/autodesk-acquires-te...
As far as I remember you had to kill Anna Navarre, no?
I would never call the Detroit and Hengsha maps "small". There's a huge amount of nooks and crannies to explore and plenty of optional side missions to undertake.
I would actually recommend that players new to the series check out HR (director's cut) first as it's a great Deus Ex experience and its graphics are holding up pretty well. I would also recommend playing HR with developer commentary on as it reveals a lot of details that you might otherwise miss. The original game, while still awesome, is really looking dated at this point.
FWIW, I don't think anyone is called Deus Ex: The Fall "Deus Ex 4". It was initially a mobile-only spinoff of HR (same aesthetics) that was later released on PC as well. It feels like a quick cash grab.
The Detroit and Hengsha/Shanghai maps were each about 5 maps stitched together, similar to part 1 and 2. But gaming has changed since 2000, there are action roleplaying games that are huge like Elder Scrolls (Morrowind, Skyrim, etc), Gothic/Risen, Witcher, etc that have all huge maps with usually seamless worlds packed with a lot of hand placed quests and side plots. So yes, DX1 was dense and had big maps but DX 2 and later had tiny maps with even lower density plot and stuff placed in there. In DX:HR/3 there were just a handful of NPC persons wandering around each map in cities like Detroit and Shanghai. Come on in we know better with games like the above mentioned and Grand Theft Auto, Assassin Creed or Watch_Dogs. A new Deus Ex needs bigger seamless maps with more interactive items (DX3 felt very static in comparison to its predecessors). A DX game based on e.g. the Watch_Dogs engine would be a great start.
Unfortunately many players played the first two games later when the graphics already looked dated.
It just smacks of pedantry, which diminishes your entire point.
So few games ever hit a 90, deus ex HR was amazing. Sorry it didn't take the direction you wanted.
[0]: http://www.eurogamer.net/articles/2012-03-15-obsidian-fallou...
I agree that the levels are small in comparison to the original DE or something like Fallout 3, and it's certainly not a perfect game (especially the boss fights), but what DE:HR had going on was density. With a few exceptions, the game's areas are jam packed with multiple routes and options and interesting stuff to see and do. Virtually every attempt to explore is rewarded with something fun.
I recall one small-ish 3-4 floor apartment building in DE:HR that has interesting stuff on every single floor - not just a "treasure chest" or two to open, but multiple entrances, scripted events, optional NPCs and quests (some of which had multiple goals/endings and could even be permanently "failed"), traps, hidden stuff to find, plot material, enemies that you could ambush or vice-versa, concealed routes to other buildings and more, all of it conditionally accessible based on your skills. You can visit multiple times throughout the game and things will change. Certain actions could have effects on future events. Every unit had a personality and breaking into one felt like walking in on someone else's life (the memorable one for me - breaking into the drug dealer's apartment as part of an optional quest and having him come home while you're there!)
A lot of other games that tout their square mileage are empty by comparison. They give you the joy of running freely across the countryside, but the only reward is the journey and maybe something to shoot at.
Unfortunately many players haven't played the first two games or played them later when the graphics already looked dated.
What are the other 4?
What would "develop for the web in a low-level language" even mean? An assembler interface to the DOM isn't going to help.
The problem is the computational complexity of the task. Every CSS rule has potentially to be re-applied to every DOM object every time you change anything. Especially the sizing and layout ones. Because they're all interdependent, paralellism won't save you here. By comparison, games are so fast because pixels can be parallelised.
You could build an alt-web if you had a suitably sealed VM running code in any language with access to the rendering portal and a security-enforcing network abstraction. This was what Java applets were supposed to be, and Flash is somewhat, but they had three problems:
- fixed size: ability to cope with resize or different devices not built in
- not as secure as hoped (javascript-to-local-user exploits have been very rare by comparison)
- too slow to start up and too willing to hog resources when they did.
And this is not only about the beginner developers. I'm a game developer myself, and I use garbage-collected C# with Unity engine instead of pure C++. This means that my games won't have performance or graphics of Human Revolution, but I'm able to prototype and change game logic much faster.
Modern web apps "deploy" nicely and play well with modern OSs, but at the end of the day you're downloading a bunch of code and running it. Nothing says you couldn't have an OS that downloads compiled binaries and executes them for your web app. A browser just makes it easier to design a page with clicky buttons and text boxes.
It uses powerful rendering for mundane widgets (plus uses physics lo layout objects) so your JavaScrip programmed web apps and smartphone apps can do +60fps.
Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.
Seriously, just stop for a second and use your head.
First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing.
Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably.
Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified.
Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script.
It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents.
EDIT:
Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.
That said, I really can't agree with you.
Browsers can re-compile their input into whatever intermediary format they desire subject to the usual space/speed trade-offs. By the looks of it (judging by the space they need) they use that trade-off rather liberally in the 'speed' direction and they still run quite slow. I just can't imagine that laying out some text and images in 2d (which I've done for limited contexts) is that much harder than rendering a 3D scene (in software, not using a bunch of GPU power to do the heavy lifting) (which I've done, but not recently and definitely not with this kind of detail, roughly at the level of the original 'Doom' with a slightly better lighting model and right around the time it came out).
Games may not have security issues in the input data that they consume when it comes to graphics and such, so that's a valid point but games do have to run on a wide variety of hardware and they typically adjust really gracefully.
The one thing I think that really differentiates game rendering engines from browsers is that game engines tend to model some physical process whereas browsers attempt to implement a massive spec to allow any server it chooses to contact to send it a bunch of bytes the rendering result of which is not known ahead of time so arguably the games people have a relatively limited possible space of outputs they can generate whereas browsers theoretically can display anything including that game.
That still doesn't excuse them for the crappy performance they deliver, that simply means we've moved too fast in adding layers before getting lower layers to perform adequately. The original web did not seem sluggish to me, it seemed about as fast as what you could expect from the hardware of the day, whereas the 'modern' web seems to be (to me) terribly slow and inefficient.
The ratio of content:markup+eye candy has deteriorated and I suspect that that is part of the answer here (and of course that would not be the browsers fault per-se).
The complaints about the abstractions and everything honestly remind me of the complaints about Java, and look how that turned out over the same time period.
As for the engine vs. browser thing--you can totally render a DOM super efficiently if you are sure that it remains relatively static. That's very much, in fact, how the game engines do so well. They have the task of "throw as much as we can in triangle buffers onto the card, and occasionally draw with uniforms set to our desired transform matrices, and let the Z-buffer and pixel shaders sort it out."
By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow.
There is a cost to such flexibility, to be sure, but it's not inefficient for no good reason--the tradeoff was made to lower the entry to program it and to allow maximum malleability.
So the problem is that DOM is a bad abstraction for building GUIs, as it is necessarily inefficient.
Desktop apps have been more efficient than web apps forever. The reason is that desktop GUI toolkits were, y'know, actually designed to be GUI toolkits.
Frankly, I think that the design tools and document model for the web knocks the stuffing out of any native apps, especially if you are trying to make something work quickly or on multiple platforms. I'd take CSS over Qt any day.
I'd love to have the dynamism of the web and the performance of native all on one platform. We're not there yet.
I also disagree that app development was harder back then. Back then we had IDEs that included online help and APIs that were actually _designed_. It wasn't a perfect world but it was at least coherent.
Also, I don't really get what you're complaining about in terms of IDEs or API design here--go spend some time on the Mozilla Developer Network and come back and tell me it's just slapdash and thoughtless work.
What I'm saying is that if you sat down to design a nice cross-platform, distributed environment for building applications it would not look like the web.
How many multiple-megabyte images could you display in 24-bit color at 1080p on that Pentium while scrolling? How good was the support for Unicode and non-English languages? How many streaming videos and ads could you see at one time? When you downloaded kilobytes of markup, and in turn request a dozen more things from a server on the other side of the planet, how long exactly did it take to parse and load? How many times did you chat with people and embed pictures in your conversation, while listening to streaming internet radio?
Hint: computers are actually doing quite a bit more in apps these days than they used to, and its only through the good luck of hiding this fact most of the time that you can make such silly complaints.
But it's a silly complaint that some web apps can't keep up with my typing? Please.
I don't think that supports your argument that poor performance is the developers' fault.
Java got fast as its VM improved and it got JIT compilation.
The difference isn't in the technical details, the difference is that a chat app with a 1 second redraw can succeed in the marketplace, whereas a game with a 1 second redraw will never be played. The bloat and inefficient abstractions grow to the limit of our tolerance.
If CPUs had hit the wall at 66mhz single core, that chat app would somehow still take the same 1s to redraw. Of course, it would probably be written in something like NaCL and have significantly more engineering effort put into optimization, with a browser stack engineered for high performance.
Which is tragic in some ways IMO. It means every system is always optimized to the level of misery where you are just barely not willing to do something about it. Which when you think about it sounds kind of like what you would expect from a lesser circle of hell.
When BBC HD was a channel, its quanily was black and white to everything else, now even they are in on the reduced bandwidth game :(
The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too.
Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves.
The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine.
The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity?
Too quote you, "seriously, just stop for a second and use your head."
I think you underestimate how much work web browsers are doing. The browser rendering engine lays out and renders thousands of character glyphs out of arbitrary vector typefaces (they might even have been downloaded over the network at runtime) at subpixel resolution, compositing over arbitrary backgrounds, keeping track of their precise location on the screen so you can, for example, select a chunk of text and copy it.
That's the equivalent level to the pixel-level shenanigans in a game engine. HTML and CSS descriptions of a webpage, with all its embedded images, are the equivalent of a complete description of a level's geometry and textures being loaded into a game. And most games, let's be honest, spend a lot of time displaying a 'Loading please wait' graphic while they pull all of that content into RAM and prepare it for rendering.
The loading is sometimes more than just pulling stuff from RAM. Decompression, shader compilation, and more. Maybe textures are created dynamically or the level is randomly generated (terrain, creatures, and all). Usually, loading is full threaded and all reading happens asynchronously. Depending on whether you're on a console or not, different optimizations happen since the disk drives have different buffered reading characteristics.
I've read plenty of stuff on web browser tech and architecture, particularly because I've been following the Servo project with some interest. I'm not saying it isn't a lot of work (it's a lot of work, like anything worth doing), but I do think it's easier than you're making it out to be.
This is the crux of why you're wrong. You get to /choose/ which formats you use and support. You can completely avoid any and all of those, if you like, just by limited your asset support. The web? It has to support all of it's cruft, at all times. It's not optional.
Also, for your benefit, the formats listed all have different usages, and encode the different channels with varying precisions. They also have different compression artifacts and perform better or worse using different samplers.
As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't.
The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft).
"The web is absolutely 100% less efficient than a commercial game engine and does far far less."
See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense.
You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does.
"Come on, is there even a comparison?"
Look at the spec:
http://www.w3.org/TR/html5/rendering.html#rendering
You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified!
Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress.
At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS:
http://www.w3.org/TR/css-2010/
I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.
Every single game that lets you use Lua to write game logic? AIUI, every Elder Scrolls game since Morrowind? The Crash Bandicoot games? The Jax and Daxter games? (The Jax and Daxter games use http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp and the Crash Bandicoot games use its predecessor.)
> At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox?
Every single game that permits custom levels that can include scripted elements fits this bill. See, though, this is a strawman. Almost every competently designed website is just like a AAA game in that all of the code that that site runs and all of the assets that it loads were explicitly selected by the dev team and tested by its QA team. Moreover, any user-supplied data is carefully handled and constrained so that processing of said data is low-impact and non-disruptive; just like in a AAA game.
I also note that you're refusing to engage with folks who call you out on the fact that your argument that "Having to handle a wide array of obscure image formats and potentially invalid XML makes page renders and reflows slow!" is bunk.
The XML/HTML stuff I mentioned elsewhere is still the same: it's not just simple missing character stuff, it's dealing with old pages that are semantically (not syntactically) malformed and still rendering them properly. See also quirks mode.
By contrast, game engines have level and script formats that they support, with simpler document models, and they get to deprecate things whenever it suits the developers.
As for scripting, just look at some docs for the Morrowing stuff you bring up: http://www.quicenter.com/morrowind/files/Morrowind_Scripting.... That's hardly on the same class of utility as Javascript--it's basically a procedural wrapper for stepping through basic scripted sequences. And that's fine--it's built to do that and only that.
Every single game that permits custom levels that can include scripted elements fits this bill.
"Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser: http://repl.it/languages
On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.
Yeah, you haven't. The comment which spawned your first statement was one that complained about rendering speed. Many people in this thread have noted that by the time an image or document (XML or otherwise) gets to the do-layout-and-render-pixels-on-the-screen stage of the process, it DOESN'T MATTER how malformed that document was or what format that image was when it came over the wire.
Why? Because when we're at this stage of the process, that data has been converted into whatever representation is most convenient for the web browser to use while rendering its screen. Just like in a video game, support for a new image type or document type is as "simple" as adding on a converter from $NEW_FORMAT to $BROWSER_INTERNAL_FORMAT.
> "Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser
No. It's a difference of size, not of complexity. The interpretation and validation tasks are the same in both examples.
> On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.
Heh. Nice of you to ignore my Crash Bandicoot, Jax & Daxter, and every-game-which-supports-lua-scripting examples. Lisp, Scheme, and Lua are every bit as complex as Ruby, Python, JavaScript and -to some degree- Erlang.
I've read your other replies in this thread. Your initial arguments are weak, and you continually choose to ignore evidence and assertions that contradict your initial argument. This is a real pity, because you're pretty well-written. If your behavior matched your tagline "Strong opinions, weakly held", you'd be far better off. :)
Again, no. "Scripted elements" is waaaay too broad, and includes elements for purely procedural work (move here, say these lines, move here, etc.).
Your example of Crash Bandicoot, by the way, isn't great--GOOL was compiled down into a form that shipped with the game. It wasn't dynamically compiled from external sources by the engine during runtime, unlike what we have to deal with with Javascript. Same criticism applies to Jak and Daxter with GOAL.
"Lisp, Scheme, and Lua are every bit as complex as Ruby, Python, JavaScript"
Scheme and Lua, certainly not--just compare their BNF grammars, much less their actual use. If by Lisp you mean Common Lisp, well, you have a point, but otherwise nope.
As for the rest, I don't ignore the assertions; it's just that the fine difference between "can support" and "must support" is apparently lost on most folks. Additionally, points on loading are all sidestepped by you folks ignoring that, as part of the browser, that flexible loading must happen, whereas in the engine you can assume the tools pipeline (you know, the 3DS plugins or whatever) have already done the work.
And then, for all that, people are still complaining about the platform of the browsers when all of there examples are of shitty and slow web apps running on it. It's like they've never seen badly-performing maps in a game engine, or a shitty Unity game which isn't optimized properly.
I'm trying to help educate folks here by clearing up misconceptions, but it's rather uphill.
I'm not sure your last point makes sense to me. I can't run Ruby, Python, or Erlang in a web browser either.
s/last/lack
So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines".
To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS:
http://www.repl.it/languages/Ruby
http://www.repl.it/languages/Python3
Erlang has also been implemented in Javscript:
http://svahne.github.io/browserl/
The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc.
If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.
Or Windows 95 running in DOSBox compiled for web with empscripten http://win95.ajf.me/
Before I discuss rendering with you, can you first disclose your experience with game engines or rendering? It's sort of pointless to go into that discussion unless you understand how things have changed in the last 5-10 years or so.
edit:
Forgot to mention that shipping with a scripting engine is sort of easy. It's just a matter of whether it's exposed to the customer or not. Tons of games (even decade old ones) have shipped with turing complete editors for modding or making custom levels or what have you. I've written a custom VM for a homebrew project that can do precisely this.
Upgraded to thread-safe rendering in OpenGL, one thread handling rendering and windowing tasks, other threads game logic and submitting draw requests, and ultimately other threads handling resource loading onto the GPU (though that came later towards the end).
Upgraded that to actually use the programmable pipeline, and finally added support for FBOs and uniforms and buffers and everything so we could actually start on deferred rendering as outlined in Engel's blog and other places. Never did transparency, but if I remember correctly the goal was to probably do something like screen-door+deferred. For the life of me I can't remember the paper we were looking at.
Eventual goal was to do full deferred lighting and PBR, but by that point I'd moved over to web development. Every time I went back to that codebase, clean and organized as it was, it was just such a pain in the ass to do anything compared to splatting some JS and Three onto the screen and being done with it.
Concurrent with that, I was doing 3D CAD software development in Java with Ardor3D. So, big annoying retained-mode scenegraph with all the BVH nonsense you could ever want, and a bunch of legacy files for things that, when one rendered a building all at once, would kill the graphics card. And don't even get me started on trying to sort out order-independent transparency for that...one of my great failures.
By contrast, nowadays I do multiple web workers with websockets to provide 30-60 fps display of waveform data on just bare 2D canvases, with Angular wrapping the components.
EDIT:
I'm aware of the scripting thing. Note that, until perhaps FarCry, it was pretty well held that scripting languages were "too slow" for most games, nevermind the success of such things as JIT Quake 1 bytecode, or the stuff in Out Of This World, or what have you. Even UnrealScript was considered godawful dog slow and to be avoided if possible, and was finally shown the door. But, in the end, scripting was discovered not to be the super worst thing ever.
I think Eve finally hammered that point home to everyone.
The scripting languages we have now have come a long way in terms of ease of embedding, with a possible exception for Lua, which has been easy as hell for a while now.
Then again, I don't think that many scripting languages have the sheer size of interface with native code that, say, JS in the browser does.
The web feels clunky but if you think about it, it's the ultimate sandbox. Hey, it even supports scriptable accelerated 3d graphics :)
So yeah, two different things for two different purpose. They are both state of the art and pushing limits.
And also because web developers made their own bed. It was web developers who decided it was a good idea to cram everything into the browser and make web pages into "web apps." They could have said, "Hey, this is dumb, doing this will be slow and inefficient, and here are the other technical reasons why it's a bad idea," but they never did that. Instead it's always, "Hey, look how I can make a low quality Doom clone in a browser that runs slower than original Doom did 22 years ago!" and hack after hack to get things running at a speed comparable to regular applications.
That's what caused the envelope to be pushed as far and as fast as it did, and we all both enjoy the fruits of that and suffer because of it. It's like forcing a kid to grow from age 3 to age 30 in a few weeks time, it's bound to give trouble, no matter how impressive the feat may be technologically speaking.
Sure, it's 'worth it' because nobody cares if a web app takes 1/2 second to render, but as soon as you trade speed for anything else you quickly end up with code that's as slow as your willing to live with.
Having said that there are a few modern web-apps that really got 10x faster while sticking with HTML, CSS, and java-script so it's possible. The trick is stick with competent people and reasonable designs.
That argument doesn't work because that was already possible with TCP, and it doesn't explain the rise of "apps".
The reality is, corporate decision makers saw cheesy demos of web stuff, and said, "Hey, lets use that in production," and instead of saying, "Hey, that's a bad idea let's just use TCP for this application!" the web devs said, "Okay, I guess we can make it work." It's clever and maybe technologically impressive, but that still doesn't make it a great idea, IMO.
TCP: low level network protocol, HTTP: high level network protocol, HTML: high level layout description (ok, maybe not that high ;) ).
> and it doesn't explain the rise of "apps".
Actually, you can explain apps (and silos) as a way to undo all that open goodness and to bring control back to the large companies that are (rightly) frightened out of their wits by what an open internet and a peer-to-peer world actually means.
Now if we could get providers to play ball and to allow servers to co-exist with residential services on ports 80 and 25 (somebody think of the spam...) and hand out symmetric bandwidth by default we might be able to undo some of the damage.
Those who don't learn from history, etc. etc.
There's a reason the web won.
How do you explain WebSockets and HTTP2?
And instead of creating a GUI in Gtk or Qt, we have IE, Chrome, Firefox, Opera, Amaya, and myriad mobile browsers, all of which behave differently, especially on more advanced JS/CSS/HTML.
The people not learning from history are the web developers. It's pretty clear they're the ones reinventing the wheels...
Browsers are super-performant these days: JS and CSS engines are highly optimised, internet connections are very fast, server-side caching makes for an instant response, and yet web apps are slower and less compatible than they've ever been.
You mention Angular, which is a big, slow, complex, and horrible framework. It's a fine example of the nonsense that is perpetuated all the time in the web dev world (I'd call it an extreme example if it wasn't used everywhere).
I often say on here that all you need for most applications (that are currently adopting Angular) is a bit of jQuery, and I get pointed and laughed at every single time, but my jQuery app would be smaller, simpler, faster, and easier to maintain than its Angular equivalent for just about every use-case going.
P.S. It makes me angry that you got down-voted for having an opinion - it seems that we've all got to think the same these days. Thanks for making a valuable contribution to this discussion.
"...re-drawing when resizing the Slack chat window can take up to a second."
0) I agree that working with the DOM can get very complicated, and that layout can also be a hard problem[0]. Keep this in mind while you read the rest of my response.
1) When a browser goes to render a page, it does so from assets that have already been loaded and validated. All the fiddling with goofy image formats and malformed inputs is over and done with. All of those resources should have been processed by the browser into a format that's specifically made for the browser. So, when you resize the browser window, all[1] you're asking the browser to do is to reflow the page using the resources that some other code has specially prepared for rendering.
2) I bet you ten dollars that -if it had been compiled for a 64-bit machine- Deus Ex: HR would run on a machine manufactured in August, 2021. (Indeed, look at how well Starcraft 1 runs on machines built in 2008 and later. :) ) (Oh, BTW. Deus Ex: HR runs on the XBox 360; a machine that was released in November 2005... just about ten years ago. :) )
3) Have you used Mobile Chrome or Mobile Firefox on a Nexus S (a phone released in December 2010)? I have and -when I have no other choice- do. They are slow as balls for web pages of any appreciable complexity. Hell, for rather complicated pages, they consistently get reaped by the Android OOM killer.
4) I assume that by "That game is never going to have to scale .. down ... to a ... shell script" you mean something like "The web is browsable through lynx. You will never have a text-mode version of Deus Ex: HR.". If the game dev was willing to let folks make Deus Ex: HR look like a game from the early 2000's (and run on machines from the mid-to-late 2000's), they could have inserted a checkbox that switched to pre-computed lighting and turned off (or greatly reduced the complexity of) all shaders. However, I bet you fifty dollars that a wide section of The Web is completely unusable on lynx (or even links, for that matter).
Edit: Know that I've built soft-realtime networked GUI software with both OpenGL (using FLTK as the base) and a modern browser (with JQuery as the base). :)
[0] However, TeX has been doing complicated page layout since the late 1970's. :)
[1] Yes, I'm quite aware that browsers can do all sorts of things -including loading and processing new resources- when the viewport size changes. If you've written a web page that does so much work on viewport size change that redraw takes 1000ms or more, guess what? You've written a slow web page. :) If you build a game that requires 1000ms to render a single frame, guess what? You've built a slow game. :)
The visible stuff a web browser does should not take exhaustive resources to get running nice and smooth. Also, since web is now most of all a UI tech in a sane world it should have the explicit design constraint of helping developers write fluid interfaces.
I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself.
From purely user facing side, and estimating intuitively the intrinsic complexity of the stuff a browser does, I would compare the experience just to the experience one gets on a modern desktop.
That level of pathological douchebaggery is rare (well, sorta, kinda) and yet browser vendors still have to write code that supports it as well as it can.
I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself.
Quite right! The problem with "slowness in web tech" is that there are just so many things that can be going wrong--slow CDNs, bad Angular code, whatever--that simply aren't the fault of the web, just the fault of sloppy developers. If the game engine bro who I've been going back-and-forth with wanted to claim that web developers were, in general, rather shit, I wouldn't disagree at all.
I think that having design constraints might help with this, but honestly we've all gotten so much from the sheer flexibility of these janky sandboxes that every time I see people pining for native apps I die a little inside.
Thanks.
The section on the audio settings says: "Adjust the game’s music, dialogs and SFX volume levels"
Typically those sort of settings gives you a slider for different categories of sound. It seems like that is probably what this game does as well.
So I guess my answer is, "I think so".