Guis vs Games, why one library is unlikely to do both well

Core D Development Statistics

• 15 bugs fixed
• 8 bugs and enhancement requests opened
• Bugs closed WONTFIX:
  • assert subverts the type system with the messages that it accepts
• Bugs closed INVALID:
  • ImportC: Enums contain wrong members
• 28 pull requests merged into the language: 25 into DMD and druntime and 3 into Phobos
• 7 pull requests merged into the website.

In the community

Community announcements

• none this week

See more at the announce forum.

Guis vs Games

I think the question is if you are doing games vs doing other applications. There's some overlap between game and gui, but not actually that much. Both draw things to the screen and accept user input... but even these two things they tend to do quite differently.

Guis tend to favor responsiveness. I know, there's people saying "games have to be even more responsive!!!!!" but let me finish: games tend to favor *predictability*. (Some exceptions of course.)

A gui will want to respond to input as soon as it can. If I can press a key and see a response on screen in one millisecond, great! Or, on the other hand, if it takes 200 ms... not so great, but I can maybe still live with it.

A game will want to respond to input *on a strict schedule*. Responding too fast might break its rules - the world physics aren't infinitely precise and are designed with certain limits in mind. It might also give an unfair advantage to some players over others. Responding too slowly means players will miss their jumps and other frustrating feelings of lack of control. But notice that if something is *predictably* slow, players will get used to it - a lot of things deliberately have some delay according to the rules of the game. Something is only ever "too slow" if it is inconsistently slow.

Thus it is common for games to poll input on a timer, whereas guis wait for input on events.

Both games and guis draw, but games tend to draw many active things at once, showing a game world that is changing with the passage of time, and guis tend to draw one difference at a time, in response to either a user input or some request finishing. Sure, some guis will do large animations that are similar to how a game works, but these are exceptional circumstances; most the time, a game is drawing to keep the screen in sync with the state of the game world and most the time a gui is idle, waiting for something to happen.

That's just the differences in functionality where they overlap. Other things are very different. Games often (but not always) value predictable latency audio, to maintain its a/v sync. Guis, being idle more often than not, can typically defer opening an audio device until they need it, then close it as soon as that effect is done. Most games contain themselves to one large, multi-role window. Guis often use several, with varying roles including temporary single-purpose windows (e.g. popup menus and toolips). Guis need to implement a variety of input patterns that games rarely care about - interprocess drag and drop, copy and paste, ui automation and accessibility apis; guis are more often part of a bigger cooperative whole than just on their own. Games just want to take whatever global input they get into their own self-contained game world, and games are more likely to care about joysticks and gamepads than guis.

One library can help with both games and guis but it is unlikely to be a complete solution for either, certainly not both.