4 ms·

Gaming "toy user interfaces" like the one pictured lower in the article generally take so much code because, very often, art directed animation which drives tho

by ja2ke 15y ago

Gaming "toy user interfaces" like the one pictured lower in the article generally take so much code because, very often, art directed animation which drives those UIs is often actually assembled entirely in script. Comparing it to an early Unix kernel I guess paints a nice visual image, but is probably not a fair comparison. In game, in-world "toy UI" like that is intended to look like the sort of sci-fi UI you see in movies, but also be interactive. The stuff in movies is made by a motion graphics designer with a copy of Adobe After Effects. Replicating that movie like look, with all the animations and visual effects you see on the big screen, but ALSO making it work as a fully user-aware, state-aware computer interface, isn't cheap, either on an artist man-hours standpoint, or from a lines of code standpoint. I imagine its expense could be reduced if a lot of the stuff up on screen was boiled down to some kind of binary data - a lot of work is put into optimizing performance of engine-native animation files and effects which are played on the characters and environments of a video game world - but usually UI (including fictional in world "toy UI") isn't considered part of the main tool chain or process, so it ends up either being highly special cased by hand, or very highly interpreted (sometimes running interpreted code through middleware which reinterprets the code again) requiring quite a lot of bloat to look and behave in a way that is presentable and on par with the rest of the game. (Usually at this point in the games industry, people build their UIs in flash, and then run them through middleware like Scaleform, which reinterprets their flash based bitmap and vector artwork as polygonal art, and reinterprets their action script into an engine-savvy language... not efficient for the game, but efficient for a former marketing guy who now wants to do game graphic and UI design, I guess.) (For what its worth, I agree with Carmack's assessment. Making highly authorable and also highly efficient at runtime, "AAA visual quality" game UI is just a hard problem to solve, and it's a problem which few studios deem worth solving because after so many years of the current system, the benefits of a change have almost become an intangible.)

pagekalisedown 15y ago
UI is a solved-problem from my point of view with middleware like Scaleform.
- rdw 15y ago
  Carmack is specifically talking about Scaleform, though! And he's not alone -- I know a few game developers who hate that thing with a passion because it's so slow that it's introduced noticeable performance problems in AAA games. Because he's clearly talking about ScaleForm/Flash specifically, though, I don't think that his comments can be correctly generalized to all "script interpreters". It's kind of the equivalent of buying a Maylong Android Tablet and going around saying that Android sucks or the tablet market is dead. You just happen to have picked the worst possible representative.
  - barrettcolin 15y ago
    He may be referring to Scaleform (or another Flash GUI library; I don't think he specifies), but he's also talking about his experience with scripting in Doom 3- which I'm fairly sure didn't use Flash.
- malkia 15y ago
  You would also have to find flash-experienced people willing to work the way console game developers work. They actually might feel a little bit under appreciated for the stuff they do, and not feel very rewarding at work, especially when they have to constraint themselves with memory, cpu, gpu, i/o issues that might not be visible on the desktop. Also at some point certain integration between the engine and scaleform is needed, and you would have to lose a programmer there supporting it. We tried it, and the consensus was it's not of use to us. I wasn't the one evaluating it, so I can't tell for sure. But resource budgeting (memory, cpu, video memory (ps3)) is very debated thing in the console game development, and everyone wants more budget for his need (audio, animation, builders, ui, etc.) We also gave a try of an early flash middleware for Dreamcast for NHL2K2 (2000) - there were only 16mb of RAM, and flash was taking significant amount (no scaleform relation). We actually got some pretty good menus, and for a video sports game you need very detailed UI for rosters, trades, etc. We also got people to do it back then. But then the problem was during gameplay. While in the main menu we had the memory to pull it off with flash, during gameplay all memory was for vertex buffers, textures, game data, sound, animations, etc. We were thinking of swapping out game data (and reloading later) when the PAUSE button is hit (and the menu appears), so flash would have enough memory - but it turned out to have some bad latency - few to couple of seconds. Ideally PAUSE ON/OFF should take no time (otherwise it's annoying). Another thing was that we still had to render the rest of the HUD (scores, replays, etc.) not using flash - so we had to support TWO technologies for UI. Hence we turned our backs on it. It was nice, but not for our game.

by ja2ke 15y ago

pagekalisedown 15y ago

UI is a solved-problem from my point of view with middleware like Scaleform.

rdw 15y ago
Carmack is specifically talking about Scaleform, though! And he's not alone -- I know a few game developers who hate that thing with a passion because it's so slow that it's introduced noticeable performance problems in AAA games. Because he's clearly talking about ScaleForm/Flash specifically, though, I don't think that his comments can be correctly generalized to all "script interpreters". It's kind of the equivalent of buying a Maylong Android Tablet and going around saying that Android sucks or the tablet market is dead. You just happen to have picked the worst possible representative.
- barrettcolin 15y ago
  He may be referring to Scaleform (or another Flash GUI library; I don't think he specifies), but he's also talking about his experience with scripting in Doom 3- which I'm fairly sure didn't use Flash.
malkia 15y ago
You would also have to find flash-experienced people willing to work the way console game developers work. They actually might feel a little bit under appreciated for the stuff they do, and not feel very rewarding at work, especially when they have to constraint themselves with memory, cpu, gpu, i/o issues that might not be visible on the desktop. Also at some point certain integration between the engine and scaleform is needed, and you would have to lose a programmer there supporting it. We tried it, and the consensus was it's not of use to us. I wasn't the one evaluating it, so I can't tell for sure. But resource budgeting (memory, cpu, video memory (ps3)) is very debated thing in the console game development, and everyone wants more budget for his need (audio, animation, builders, ui, etc.) We also gave a try of an early flash middleware for Dreamcast for NHL2K2 (2000) - there were only 16mb of RAM, and flash was taking significant amount (no scaleform relation). We actually got some pretty good menus, and for a video sports game you need very detailed UI for rosters, trades, etc. We also got people to do it back then. But then the problem was during gameplay. While in the main menu we had the memory to pull it off with flash, during gameplay all memory was for vertex buffers, textures, game data, sound, animations, etc. We were thinking of swapping out game data (and reloading later) when the PAUSE button is hit (and the menu appears), so flash would have enough memory - but it turned out to have some bad latency - few to couple of seconds. Ideally PAUSE ON/OFF should take no time (otherwise it's annoying). Another thing was that we still had to render the rest of the HUD (scores, replays, etc.) not using flash - so we had to support TWO technologies for UI. Hence we turned our backs on it. It was nice, but not for our game.