koobas.hobune.stream
How do you connect different Unity projects into one seamless experience (e.g. collection of minigames)?
Hi, a bit of background first. I'm the (greenhorn) lead developer for a prototype of a new game console for physical therapy (So, helping us will improve your karma! ;-). We use innovative input devices, similar to Wii or Kinect, and the whole system runs on a touchscreen computer with Windows 8 (Windows is a must due to third party driver support). All games and menus are implemented in Unity Pro.
Now, a bit more general, let's say you have a collection of mini games, made in Unity e.g.
GameA
GameB
These should be selected by the user from a menu (UI), possibly also made in Unity, e.g.
Menu
and, to make it harder, as in our case, (soft) real time algorithms for computing user inputs with sensors, which should run permanently, e.g.
GameControllerInput
Our current solution is, to implement everything in a separate Unity project and compile one executables (exe) each. Then, one executable (e.g. Menu) launches another (e.g. GameA). The whole system is running on a touch screen computer and should feel like a video game console. Currently, GameControllerInput is a script which is implemented in all other projects (GameA, GameB, Menu). Transitions are handled by saving the current state of the real time algorithm into a file (XML) and then loading it in the newly opened exe, ignoring user input during transition.
Problems with this approach:
P1) When closing one exe and opening the next, the desktop (Windows 8) briefly appears. This is ugly. What's more, if the user clicks on the touch screen at that moment, the desktop is activated and the new exe is not in focus and full screen any more. This happens almost never (once in dozens of hours of testing!) but when it happens its a major problem.
P2) User inputs during transition are ignored. This is a problem for us, as every user movement, even if unintended, should be taken into account.
The advantages are:
A1) Its easy to separate development and add games later as this only requires changes to Menu. E.g. Developer B can develop GameB and only needs to pull the latest GameControllerInput code from the central repository (we use GIT). If all games were part of one big project, developer A could e.g. not use a script called Enemey.cs if GameB ues this already.
A2) The Unity projects stay relatively small. Combining all projects would cause massive Unity projects (double digit GB sizes).
For P2) I'm currently planning to separate the GameControllerInput into a separate executable which is always running in the background and use UDP as the interface. This would cause a lack in development flexibility (things are still changing a lot) but user inputs would never be lost and the game developers would not have to worry about fetching the latest GameControllerInput code changes.
I don't have a better solution for P1) yet. Any suggestions for both problems? Feel free to ask for more details. I'm curious if anyone here has similar problems and what your solution looks like!
Not sure if this is relevant, but the Copenhagen Game Collective recently held their first Chain Jam event, in which they collected user-made games into a larger party game, which switches automatically from game to game and saves the player scores from game to game. It is, however, running using the Unity Web Player. They created an API you just had to follow, and they made the test bed for the entire system available for download, too. $$anonymous$$aybe that will contain some relevant inspiration for you: http://chainjam.com/resources/
I might have misunderstood the problem, but can't you just use separate scenes for each $$anonymous$$igame?
@mattssonon: Thanks for the pointer. @tanoshimi: Not really, because you would lose the advantages noted under A1) and A2)
I don't really follow your A1 argument- if you're using GIT it should be straightforward to synchronize multiple developers working on diferrent parts of the project. If you literally mean that you can't have two scripts called "enemy.cs" - well, you just need a better script-na$$anonymous$$g convention :) As for A2, The overall size of one jumbo project, I agree, is less attractive, but I'd personally prefer that over the inevitable code duplication you'll get from multiple isolated projects
@tanoshimi: Thanks for your feedback! $$anonymous$$anaging code conventions and exchanging code over GIT is fine but code is only a very small part of the games. Assets are massive in size, nothing you can quickly pull over the network. Another problem with Unity is that a lot of the settings are saved in the scenes (e.g. which object is connected with which) and version control breaks down here. How would you handle two developers developing two different games without synchronization? If they both work on the same Unity project how do you merge them later? Compress the whole game into a unity package? $$anonymous$$aybe this is the right way, but it sounds like a lot of trouble which could bite as at the worst time, later in the development process.
