In particular, I'm thinking about C# and XNA, and obviously on Windows. Let's say I have the main game which is a normal XNA game, but at some point I would like to momentarily switch to a mini-game that was also implemented in XNA but is completely independent of my game.
Is there any way I can switch to and back between the two games, while reusing the same windows handle? And preferably keeping the old state in memory, although I could also implement this persistence writing to a file.
And when going back to the initial game, is there any way I could access the value returned by the mini-game's main method? For instance, 1 or 0 depending on whether the player cleared the mini-game or not.
Andrew Russell wrote:
You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).
Thanks for the answer. Your suggestion is what I'd do in a normal game situation - one where I'd be the one creating all of the mini games and their content.
But this is not a game, but rather a game maker tool for creating graphic adventures, and it is the end user that might feel the need to plug in external mini-games in response to certain game events.
The older internal engine that I'm trying to replace was done in Flash, and solved this problem simply by loading an SWF inside of the main SWF. It worked okay for most cases. I'm trying to do something similar but with XNA now.
But following your train or thought, perhaps I could create a separate assembly containing a base class or common interface for all mini games, and compile it as a dll. Then the user would reference that library, implement the interface and compile into his own library which could be loaded by the engine at runtime and executed as a separate state inside the main game. Am I missing some hidden implications?
Answer
No. There's no official way to do this in the API.
If you were insane, you could perhaps use reflection to get at the underlying DirectX objects, and then trick them into reusing a window and triggering a content reload at the right time. (Only one device context can be attached to a window at a time, basically)
You could let them have separate windows. Although that could introduce issues, especially if they both need to be full-screen.
You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).
You can use separate content managers for each game/mini-game, allowing you to unload the content for each of them once they're done.
Consider looking at the Game State Management sample.
To answer your edit:
Yes. A kind of plugin system like this should work just fine.
Be aware that, once loaded into a process, you won't be able to unload the plugin DLL without unloading the whole process - although you can unload its resources in the usual way. (Note for anyone else coming across this: You can unload when using AppDomains, but I am reasonably sure that this won't play nicely with XNA.)
No comments:
Post a Comment