• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Vincent_M

Adding Games as "Packages" to an Executable

9 posts in this topic

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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)

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0