Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split code into separate sub packages? #6

Open
ElliotB256 opened this issue Aug 27, 2021 · 1 comment
Open

Split code into separate sub packages? #6

ElliotB256 opened this issue Aug 27, 2021 · 1 comment

Comments

@ElliotB256
Copy link
Owner

@andrew-raphael-lukasik

Thanks for the recent changes, it's nice to see someone taking a look! Perhaps I can get your opinions on some thoughts.

I'm thinking of splitting the repo up into separate packages; it would help enforce decoupling of the logic between different core parts of the game to promote reusability in other projects. e.g. in https://github.com/ElliotB256/ECSCombat_Spawning I've added behaviours for spawning ships through a 'Spawn' entity, which can be coupled with modifiers and refits to swap out components on the ships (so, eg you can create an entity to spawn a number of fighters and swap their small weapons hookpoints for lasers, for instance). It's used in this prototype:
https://elliotb256.itch.io/command-deck

Personally I'm not sure what the best way to handle this in unity is. For now I've set it up using git submodules, so each module is pulled in as a separate sub repo to the main project Assets folder. It could probably also be done using UPM (probably the more technically 'correct' way in unity ecosystem?), but I've had bad experiences with UPM in the past. Very open to suggestions.

@andrew-raphael-lukasik
Copy link
Contributor

andrew-raphael-lukasik commented Aug 29, 2021

I don't have very well informed opinion on this. I know upm can become catastrophic mess sometimes, but idk I find it's workflow manageable so far. But it might be just my naivety or insistence to keep dependencies and packages simple, not sure which.

I created PR #8 as an example, you can check it out. It adds my tiny package as an dependency to solve very specific need in the project. You can make vertical features, for example, like this https://github.com/ElliotB256/ECSCombat_Spawning repo you mentioned into an upm package and add it here the same way I think.


my humble advice on upm:

  • keep packages relatively simple, single & specific functionality
  • create dedicated upm branch that will host package.json etc. files
  • push to develop branch any wip code, consider upm a "production" branch
  • always exclude upm-specific files (package.json, etc) on the master branch when merging (master hosting package.json will confuse people)

small protip:
.../Project_Name/Packages/ directory can contain folders with whole upm packages there. It's very useful sometimes.
For example, you can nest a submodule there to co-edit a upm package alongside your entire project.

Or sometimes it's just useful (or simply necessary) to move packages from .../Project_Name/Library/PackageCache/ there to test or fix something temporarily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants