This question is going to be half curiousity, and half start of a discussion.

I've always found it interesting that PC games often go full-screen, and immediately present GUI-like features that are closely similar to the OS that just got hidden away. Things like buttons, drop-down windows, check boxes, even sub-windows. Why do game authors do this? Everyone starts with a heavily tested, optimized, and feature rich GUI suite, and use it primarily to hide the original GUI and implement a new one, that is less tested, has fewer features, and is generall all-around shittier and less stable.

Springing off of that, I was hoping to have a discussion about embracing the native GUI, and actually using windows. Windows for inventory screens, windows for the main game screen, maybe windows for dialog with characters, windows for the minimap. You have this super strong tool that allows the player to customize their experience (draggable windows, minimize buttons, close buttons, UI alerts, etc), why not take it?

So, as game designers, have you considered dropping the full-screen paradigm? Are you considering it now? What's some cool user-experience stuff you can do easily with native GUI's that are otherwise painful?

I've always found it interesting that PC games often go full-screen, and immediately present GUI-like features that are closely similar to the OS that just got hidden away. Things like buttons, drop-down windows, check boxes, even sub-windows. Why do game authors do this? Everyone starts with a heavily tested, optimized, and feature rich GUI suite, and use it primarily to hide the original GUI and implement a new one, that is less tested, has fewer features, and is generall all-around shittier and less stable.

Games often use pimped GUIs on steriods, that is, they add effects. Integrating a Windows-Gui (what about cross-platform?), most likely heavily utilizing OS calls (aka bad for performance) with limited (?) support of alpha blending, light effect, shadow effects, custom shaders, GPU rendering etc. is most likely the main reason. There are for sure some usecases, but if you want to have a GUI on steriods, custom GUIs are still up-to-date.

You have this super strong tool that allows

Yep, a powerful tool, but a tool not primary designed for hi-performance realtime applications like games.

So, as game designers, have you considered dropping the full-screen paradigm?

Sure, many games support window and fullscreen-window (that is, a maxed, borderless window) modes instead of exclusive fullscreen, it is just not always obviously.

Games are more asthetic than regular software: it's about the experience, so artists want to control it. Indie strategy games in particular sometimes use the default menu bar at the top, and it works well (especially with lots of report type screens), but because most games don't and most 'tools' do, it gives it a utilitarian vibe. For things like map editors, it suddenly makes more sense, because it's no longer about immersion, it's just about presenting a useful tool.

As for multiple windows, I've played the occasional game like that, some angband variants go that route, and I personally dislike the paradigm. A spreadsheet or image editor or whatever is one part in a unique process I'm participating in. Maybe I'm making notes in one program on a presentation in a second one, while referencing an email. So I find an efficient layout and roll with it. But in a game, my experience is constrained. Do I need to know my inventory right now? Then show it to me, don't make me pull down a dropdown and then find real estate for the screen. In most games players aren't going to have wildly different interaction and information needs, so they don't need fine grained customization. And if they do, it seems easier to give them choices (or mods) that present the information efficiently, rather than expecting me to find the right layout.

That said, I do think you could design a game around using default UI elements. Maybe a hacking game, where you have a folder of tools you open separately to use. Maybe something like "papers, please" that simulates a bureaucrat in an interesting setting. Or an rpg where you're explicitly some sort of outside force helping these adventurers indirectly through the use of the game/tool. Since we've already got specific associations with default OS elements, that could be a fun set of expectations to play with. But if the goal is suspension of disbelief, I think hiding away everything but the game is productive to those ends.

Everyone starts with a heavily tested, optimized, and feature rich GUI suite...

What GUI suite are you talking about?

Is this GUI suite available on all platforms (Windows, OSX, various flavors of Linux, PS4, PS3, XBOne, 360, Vita, PSP, Android, iOS, Windows Phone, Windows Store)?

Does the GUI suite support 3D user interfaces that would look good on 3D HMDs such as the Oculus Rift?

Does it allow one to clip 3D objects inside 2D scrolling containers?

Does it have controller, touch, mouse, and keyboard input support?

Can the UI be rendered with OpenGL or Direct3D?

Does it support hit detection for 3D objects that are clicked/tapped on?

Does it include MVVM-style data bindings?

Does it have support for animated UI elements?

Can it be controlled by an automation testing framework?

Why do game authors do this?

Because their needs are more complex than you can imagine.

The biggest things are that that A) the native controls simply feel out of place in games, and therefore a game using native controls would feel less polished, and B) using native controls in a multimedia (e.g. using, say, Direct3D) app means you've got then allow for your renderer to cooperate with the operating systems' own drawing of controls, which has a performance/latency impact, and sometimes also limits what you can do.

You can generally alleviate A) if you can put in the work to skin the controls, but then you're just about writing your own UI anyways. Its not that typical UIs are bad at what they do, they just do something different than most games want, and so they're often more of a hindrance to work around than they are help.

Everyone starts with a heavily tested [...] GUI.

Any previous user testing does not apply to new software. Ever. The user experience of every software is unique, and must be uniquely tested. That something worked well for one software does not guarantee it works well for another. It follows that all UI options for a new game have never been tested before, including standard Windows UI options. Others have already pointed out that many standard Windows UI features are obsolete in context, or would negatively affect the performance of most games. You don't want to add obsolete features to your UI, nor drag down performance if you can avoid it—that's bad design.

So in the '90s, using native Windows controls in games wasn't rare, especially in the shareware scene (e.g. Dare to Dream, Gazillionaire, Castle of the Winds), but even established studios like Maxis or LucasArts did it sometimes.

So it's not like no one ever thought of it before, it's just that studios abandoned it for good reasons: it never looked good, it's bad for immersion, your game would be stuck on a particular platform, and it wouldn't support alternative input (e.g. joysticks, controllers, etc.).