koobas.hobune.stream
Architectural Question: Managing Multiple Runtime Projects
I'm new to Unity, and I am still elaborating to figure out how to architect my game idea. The game is somewhat large, and for the moment, will only deployed it on Windows. Ultimately, the purpose of this question is to figure out how to manage the complexity of this game idea.
I understand that each project has a set of assets, and each scene takes advantage of some or all of the assets. For purposes of this question the term "view" refers to a single project and one or more scenes; and each "view", once built, will be a self contained "exe" (and possibly one or more DLL's).
The game idea I am investigating is space based, with surface/air, orbital/solar system and interstellar views. From an orbital perspective, I really do not care that there is any detail on the surface of a planet, and I certainly don't need to draw out buildings or low level detail representing that information. I might draw a "picture" that represents building on the surface, but that's it. This is why I think the orbital view is really a different view/exe. I don't think I will have many assets to share between views, which is why it feels like a convenient boundary between environments.
I'll use a SQLite database to store all of the "settings" and use the information in that database to support each view. This means I can represent, at least in data, the full game, but only pull the data I need within each view.
I will create a bootstrapper/launch mechanism, that essentially loads each "exe" as I transition from one view into another. For example, when the player leaves their surface industrial complex and gets into orbit, a new view/game/exe is launched for the user to manage the game from an orbital perspective.
So the question is ... is this strategy good for what I'm trying to do; acknowledging that the user will have to sit through a view/exe unload and load process each time they transition from one view to another? Or, is this thinking going to lead me to a whole new world of pain? ... because I'm new and don't know everything yet?
Is there a better way I cannot see?
I think the main problem is that it won't look good to the user. I'm not sure of what you are trying to achieve, but probably something that handles transitions smoothly would have a better impact.
Is there a particular reason for not doing it just using scenes ins$$anonymous$$d of separate exes?
Trying to figure out the best architecture for a game that, as it evolves, will get more and more complicated. I see this in my non-game commercial projects, that as we pack more and more stuff into the solution, the ability to manage the inter-dependencies gets to be more of a challenge. So if each view was essentially like an independent game, the complexity is mitigated by the fact that each part is "simpler".
Imagine you are playing something like Call of Duty. You see a house in the distance, you try to move there to find cover. As soon as you enter, the game "crashes" (that's what it will look like to the player), you go to the Desktop and suddenly the game restarts and shows you inside the house. If you leave the house, same thing happens.
$$anonymous$$aybe your game isn't so fast paced, but in any case I have a hard time imagining anyone enjoying this.
I understand the problem with complexity but immersion is crucial in any game. You break the immersion, you lose the player.
It breaks down to this: it is the development process that should be adapted to the game, and not the other way around.
I strongly advise you to try another approach.
In a game like SWTOR, there are "cuts" between one ship and another, or a ship down to a surface, or back up again. Each ship and each planet are technically independent views. That's kind of the level I'm referring to.
I get the point thought that you cannot break up the flow, and in SWTOR it would be cool to see even a cut scene that takes you from one place to another.
As for the the comment "development process that should be adapted to the game", that's okay if you have a clear vision for how the game should be architected and the environment it's architected in, but when you're new ... you seek desperately for answers to reduce rework.
