Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Adding Games as "Packages" to an Executable


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Vincent_M   Members   -  Reputation: 848

Like
0Likes
Like

Posted 19 February 2014 - 02:01 AM

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.


Edited by Vincent_M, 19 February 2014 - 11:58 AM.


Sponsor:

#2 ColinDuquesnoy   Members   -  Reputation: 1162

Like
0Likes
Like

Posted 19 February 2014 - 07:16 AM

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



#3 mark ds   Members   -  Reputation: 1658

Like
0Likes
Like

Posted 19 February 2014 - 08:31 AM

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.



#4 Vincent_M   Members   -  Reputation: 848

Like
0Likes
Like

Posted 19 February 2014 - 12:10 PM

@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).



#5 ColinDuquesnoy   Members   -  Reputation: 1162

Like
0Likes
Like

Posted 19 February 2014 - 02:25 PM

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)



#6 Vincent_M   Members   -  Reputation: 848

Like
0Likes
Like

Posted 19 February 2014 - 03:56 PM

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?



#7 ColinDuquesnoy   Members   -  Reputation: 1162

Like
0Likes
Like

Posted 19 February 2014 - 04:30 PM

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


Edited by ColinDuquesnoy, 19 February 2014 - 04:31 PM.


#8 Vincent_M   Members   -  Reputation: 848

Like
0Likes
Like

Posted 20 February 2014 - 11:51 AM

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?


Edited by Vincent_M, 20 February 2014 - 12:00 PM.


#9 frob   Moderators   -  Reputation: 29901

Like
0Likes
Like

Posted 20 February 2014 - 12:58 PM

Often a game launcher is a separate app. Each game comes as its own app. You just launch the other process as a child of the launcher and have the launcher wait until the program is over.

If you really have your heart set on everybody making DLLs for your mega-app, they can do so. Just don't expect many people to come knocking on your door for prospective app developers.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#10 Vincent_M   Members   -  Reputation: 848

Like
0Likes
Like

Posted 21 February 2014 - 01:14 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS