I'm building a game that's really many games in one like the Neo Geo arcade machine. What I'd like to do is build my own game launcher/shell which is an OpenGL program that starts when my computer starts up. It's kind of like the dashboards you'd see on consoles nowadays, or like Steam's client app. How should I approach this?

I've thought about adding this is by scanning a specified folder for a list of folders where each folder represents an installed game. This would be similar to the "Program Files" folder you'd see on a Windows computer. Each of these folders will have a "Shell" folder that'd contain assets used by the launcher to represent that game, such as an icon, background music, localized text file, etc. Each game would be contained as separate stand-alone applications since I probably can't afford to have the launcher running at all times. Then, once the player selects a game from the launcher, it'll close the launcher, then launch the game. When the player leaves the game, the launcher will automatically run again after the game ends.

Another approach would be to suspend the launcher, but that would mean having to preserve my OpenGL context. I have plenty of shared memory to do this, but I'm concerned about the potential loss in processing performance due to the suspended launcher process.

I've thought about going with the DM approach for the launcher, but it'd take quite a bit of learning to get me where I want to be. Btw, I'm using Debian for my OS.

What is the question? You explain what you want but we have no idea what the problem is.

I think the best approach would be to game code in a dll. The app launcher could own the windows/frame buffers etc. and pass user input to code in the dll. On start up, you could parse the subfolders for things like icons and a textual descriptions to display in the launcher.

@ColinDuquesnoy: I modified my post above to be in question form. Sorry about that!

@mark ds: That was the initial approach I was thinking about going. It'd be a shared object (.so) instead of a DLL since it's Linux, though. I forgot to mention I was using Debian earlier, but I added that to my post above. There reason I decided against it was because I wasn't sure how I could dynamically load shared libraries from an executable unless it was included in the Makefile/build process. Each game is being treated like a plugin, however, so there's got to be a way. I started writing a game shell base class for these games when I initially intended on doing this. Most dynamic libraries I've seen in Linux are usually small (kilobytes), and have a static library counterpart that's much larger (megabytes).

As suggested by @mark ds, you need some kind of plugin system (i.e. you need to load shared objects dynamically).

Since you're on linux, you may use dlopen and dlsym to load a function from a shared object, see http://linux.die.net/man/3/dlopen (there is an example at the end of the man page)

I'm looking into the dynamic library APIs right now, and I'm really starting to like that approach. So, in my Eclipse workspace, I'd have a project for the launcher (executable), a project for my in-house engine (.so), and a project for each game in development. The launcher, and all games would use my engine as a dependency. So, would my engine's shared object be loaded multiple times?

I'm looking into the dynamic library APIs right now, and I'm really starting to like that approach. So, in my Eclipse workspace, I'd have a project for the launcher (executable), a project for my in-house engine (.so), and a project for each game in development.

Yes, foreach game in development, you will define a main function that your launcher will load and call.

So, would my engine's shared object be loaded multiple times?

As the name implies, shared libraries are shared and won't be loaded multiple times. More infos:

- http://stackoverflow.com/questions/8034579/shared-library-address-space

Ok, I thought shared libraries would "share" their calls, but I just wanted confirmation. I was able to get my launcher shell up and running last night, and calling functions from the game's shared objects. More importantly, those shared objects are able to make OpenGL calls off of the launcher's context! Things are definitely coming together now.

EDIT: After re-reading that link above, I did run into a question. Even though the engine's shared object will be shared between the launcher and the currently-loaded game, will the data in the engine be persistent across all processes using it? For example, if I make the following engine call in my Launcher:

GraphicsContext::EnableState(GL_DEPTH_TEST);

This should enable depth testing in OpenGL, and also add an 'int' flag to a static STL list in the engine. So, if I want to query my engine's list of OpenGL states I store in that list in the game process:

bool depthState = GraphicsContext::IsStateEnabled(GL_DEPTH_TEST);

Then, the method should return true since my Launcher already enabled depth testing. Is that correct?

I like the idea of a dynamic library, because I don't have to constantly load/unload my engine between game sessions, and it's all under 1 context. That being said, I have total control over fancier transitions into the game too, which will I'm pretty exciting to me! I also don't intend to have others develop for this platform. It's just me for now. All of the titles will be 1st party haha.