Question Integrations of multiple unity projects(games) into one single application

Hello All,

I have been doing quite some research on how to integrate unity multiple projects or games into a single application and have not found any suitable answers for that. Hoping to get one here in the forum or at least have a discussion about it.

To start with I will list down my approaches to integrating multiple unity projects.

1. Have a main scene as a lobby scene which would be a placeholder for different games from where the user can select and go to the game of choice.
2. Have multiple game scenes like Game1, Game2, Game3 ... GameN, on the selection of the game from the lobby window, download the assets for the required game and load the game.

Limitations of this approach :
1. if one game has issue, we would require to redeploy the entire application again
2. The main application would be heavy in size as the multiple games have heavy assets.


I am just wondering if there is some other way to do this stuff, as Play Store has so many games.

Hoping to have an open discussion about it.

 

So many ways to do this and nothing makes it easier than Unity. Get busy and get experimenting today because you have a LOT of moving parts to reason about.

Some tips:

- use scenes for separate games

- place each game into its own subfolder and try to share NOTHING between them

- use namespacing to deconflict your game code

- do the above BEFORE merging them

- look into git submodules if you want to inject parts of games into each other

Also, using scenes per game lets you deliver your content late with Addressables or Asset Bundles served down from your own server.

Get good at deploying and expect to do it a lot.

YES, you can deliver late content, with ZERO code updates

YES, you often need code updates, so don't make yourself miserable chasing an ideal.

Instead, just get good at releasing regularly, ideally at LEAST once a week when you're ramping up.

And obviously, use proper source control or you are one fatfinger away from complete disaster.

 

I tried to place the games in their own subfolder but the issue with that is all of the games shares the same multiple classes, some config files, and packages which become difficult for me to import those game into one.

Renaming the Classes again is a huge task as the codebase is huge and a lot of reference gets lost during the name change.

Is there some other way to do it?

As multiple games share the same classes, packages, and config files but are different projects.

 

As I wrote above,

Visual Studio tools are available to select entire groups of source files and place them into a namespace. Just google something like

visual studio add namespace to all files

.

Do these things in each individual game BEFORE combining them.

 

As I wrote here,

I tried to do that, the namespace conflict goes away but what remains is same multiple classes, config and packages

 

If this were true, Steam would've been made in Unity, not C++

 

Sounds like you did it wrong. Multiple duplicate classes WILL be fixed by namespace separation.

If Game1 has class Foo and Game2 has class Foo, after namespacing it will be Game1.Foo and Game2.Foo, completely-different classes.

For packages it will be necessary for you to choose a superset.

And what do you mean by "config?" You may need to implement your own separation at the filename or directory name level.

 

After that statement I can only conclude that you are unwilling to put in even the slightest effort to achieve what I have done over a dozen times successfully, and with MASSIVE projects spanning thousands of classes.

Good luck!

EDIT: FrankvHoof, I didn't realize that was you posting the drivel above! Steam and Unity are not even comparable in any way.

 

Steam is a video game digital distribution service whereas Unity is the game engine.

 

Oh no, I'm not saying it cannot be done. I've done it before as well.
I'm just saying it's not the easiest thing in the world.

Creating e.g. a C++ or .NET-application, and having that start a (variety of) Unity-process(es) is usually a lot easier.

Steam is also a client that allows you to start games that are in your library.
So an application that can start one of multiple other applications.

 

WHAT?!! Now I know you've never done that before either.

Unity lets you reorganize Game1 and Game2 into separate folders, namespace them, combine the folders, straighten out the scene and Resources flows and be done.

I even did it in front of a crowd of people at a Unity user group presentation: I mooshed my own little lunar lander game into the Unity Rogueline2D sample game: when you landed at a base, you would hop out of the spaceship, play a few levels of dungeon, then hop back in and fly to the next one.

Those are two games not even written by the same person. There's NO engine besides Unity that would make that so easily.

 

what do you mean by superset?

 

This comes with a whole heap of limitations.
For example: All of your Game#'s MUST use THE SAME VERSION of all Packages. There is no way to import multiple package-versions into 1 unity-project, since this would cause conflicts.

What you're describing can be done in pretty much any engine. I've done something similar in XNA about 9 years ago.
I'm just saying it might not be the first option you should reach for.

 

If Game1 needs packages A, B and D and Game2 needs A, B, C and E

Then...A , B, C, D, E is a superset.

https://en.wikipedia.org/wiki/Set_theory

 

I think the "Reaching for" already took place when the collection of games was made long before OP got them.

OP certainly speaks of the games as if they already exist:

But hey, if you think rewriting the games from scratch in a completely different engine and language and then making them work together once combined is easier, be my guest!

 

Again, namespacing. You can actually bake packages into your project, by removing them from

manifest.json

and copying their payload into your Assets folder and committing them to your source control, where you directly control and can edit the code.

Barring the packages accessing a common resource (such as Time.timeScale), there should be little to prevent you from namespacing the different versions of packages, then injecting

using

statements for each namespace into each project.

Or just fix your game to use the latest of all packages. You'll almost certainly need to do it at some point.

 

No, I meant reaching for Unity as a "Game Library Manager" or "Launcher".
There are many easier ways to go about that than Unity.
You can e.g. imply dump your built unity-games into subfolders, and have a WinForms-App start the .exe corresponding to a button in your UI.
This would not require any resolution of conflicts whatsoever, as each game would remain a completely separate application whilst one single launcher-app can launch any of them.

Never said any of these things.
I said that such a launcher can be done in pretty much any engine (not just Unity), including PyGame, XNA, Unreal, etc..
But a launcher is a 'Software-purpose'. So using a game-engine to implement this is kind of overkill.

 

You've now already jumped from
"All you need to do is dump your games into subfolders"
to
"You can resolve conflict X by doing Y"

That's not "There's NO engine besides Unity that would make that so easily."

There is an 'engine' that makes it easy(/easier) to implement a launcher. It's called .NET Framework.

 

Okay, fair enough, this makes your statements far more reasonable.

I was operating on the assumption that OP wanted all these games to live together like "Wario World" and such, with tight inter-game and intra-game integration, perhaps a shared currency or score or resource.

If OP just wants to combine them, you are absolutely correct: this would be by far the easiest:

Either way, I work almost exclusively in iOS and Android, so I expect a single large binary, perhaps with external late-loaded resources. It's not possible to make separate executable launchers in a trivial cross-platform way. Yes you can have multiple binaries and multiple activities, but you will be doing the work over and over between iOS and Android.