Skip to main content
added 1385 characters in body
Source Link
David Gouveia
  • 24.9k
  • 5
  • 87
  • 125

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?

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.

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?

Tweeted twitter.com/#!/StackGameDev/status/175092274726842368
Source Link
David Gouveia
  • 24.9k
  • 5
  • 87
  • 125

Is it possible to reuse the same window in multiple games?

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.