I've been thinking about this a lot lately; I hate having two monitors and my second one goes to waist when I'm playing games. Oh, and I'm not talking about that hinky "render across two or more displays" idea; I'm talking about utilizing extra monitors for other tasks (similar to how the Nintendo DS works.)
For example, lets take an old-school RPG (like something made by RPG maker.) On the main screen you'd have the display and then the "camp screen" could be displayed on a second monitor. The player could move over and equip/un-equip an item, use a healing potion, etc.
Another good example might be Oblivion. The view screen, along with the HUD (health and what not), would reside on the main screen and then the second could, again, contain the "camp screen." The player could move to the camp screen, click somewhere on the world map, keep track of his quest log, etc.
An MMO isn't that great of an example, seeing as how you really want to keep your eye on the main screen, but I would have loved to have been able to have all of my chat windows on my second screen when I was playing WoW. I had separate chat-windows for whispers, guild-chat, and then one for the rest (I split the other two because I was constantly missing something or wanted to reread what someone had said, just to have it erased because of the ...lovely people in trade chat), so my window was really cluttered (It helped having a 1920x1200 resolution, but it still made it hard to with all of the windows in the way; plus I kept clicking on them accidentally.)
Another use for it could be local multi-player support. Using raw input you could detect sets of keyboards and mice (you'd need some sort of configuration menu to assure that keyboard B isn't setup to interact with Player A) and then two players could play on one system.
Obviously one of the issues is you'd have to detect whether or not it can be done or is enabled (if the player wants to play in windowed mode or they didn't have two adapters/a multi-head adapter, for example, you'd have to use a single monitor.) You'd also want to allow the user to force it off (some people don't seem too keen on the idea.)
Anyway, just an idea I've thought a lot about. IMHO, most games would benefit from it even if they just used it to display a map, radar, or quest log.
Any input is welcome, as always.
[Game Development Update]
Heh, my ToolBox is shit. It's useable, so I'm going to continue with it for now, but at some point it'll need to be rewritten (after I finish a project.) The main problems:
* It's a jumbled mess of copy-and-paste from other files
* It's not consistent in error handling
* The runtime log system needs to be redesigned
* I've defined a nice assert macro...that I don't use at all
* It's very, VERY unorganized
So, for now it will work, but it'll be trashed and rewritten in the future.
I've also done a self-assessment again; I do them randomly to try to figure out where to improve. Not much has changed since my last one really (it hasn't really changed since I started doing them to be honest.)
* I seem to be afraid to use character pointers instead of std::string. Yes, std::string rocks, but it doesn't fit all situations. I've run into instances where I think a character pointer would be a better choice, but I stick in a std::string anyway "just to be safe" (I guess.)
* Memory issues never seems to be on my mind; I just assume this and that and go on. As I stated quite a while back: I never learned about a lot of memory related issues (memory alignment, cache misses, etc.)
* I don't know how multi-threading works at all (code wise; I understand most of the concept.)
* I still haven't learned network programming or how to handle internet protocols (mainly HTTP GET requests.)
* I suck at code architecture.
* I seem to have this illusion that everyone in the world is going to use/see my code or something, because I'm constantly changing things because of "what if someone wants to do this or that".
* I have the urge to wrap everything because it could have a cleaner or simpler interface (IMO of course; Win32 is a good example.)
* I need to get over my perfectionist ways. Programming is an imperfect art and I need to deal with that. I also don't have lots of experience past tech-demos, so my products will probably be the furthest thing from perfect to start with.
* I never finish anything. Obviously, my biggest issue. I'm not really sure what to say on this one. I can't count how many times I've tried to assess this and think I've figured it out just to not finish anything. Most would say its because I'm stuck in that "game engine" phase, but that's not true at all; I've had two ~90% complete engines that I put aside (and of course, since I only recently started archiving things, I can't find them.) And I'm not talking "really only ~25%, but IT COULD be used to make a game", I've had two engines that worked completely, but one had scripting issues as well as some faulty collision detection and the other was having some major save/load issues as well as scripting issues and faulty collision detection.
As you've probably assumed, Invasion hasn't moved since about the 5th. I loaded up my copy of Zombies Ate My Neighbors (the game that inspired Invasion) and after only 16 levels I closed it because I was bored to tears. I realized one important fact: I never played the game by myself; I always played with my brother. I've spent pretty much this entire month trying to rework the idea; changing the genre, the perspective, the concept, etc. and I just can't seem to make the idea work (as in make it fun; I'm not going to make a game that doesn't seem fun to me.)
That's enough rambling for tonight. I'm off to bed.