views:

56

answers:

1

I've got a game (a roguelike to be specific) in C# that I'm in the process of cleaning up to open source. One step I'd like to take is splitting it into three distinct pieces:

  1. A simple package of utility classes, things like 2D arrays, vectors, etc.
  2. A terminal UI package that gives you a curses-like display. It depends on 1.
  3. The actual game, which uses 1 and 2.

Right now, these are all separate projects in the same solution, but I'd kind of like to make them completely separate projects (in the "open source project" sense, not the "visual studio project" use of the term) with their own names and repos. I think, at the very least, #1 is generally useful even if you aren't building game, and I don't want someone to have to build an entire game just to get some handy functions.

What I'm not sure about is how to handle the dependencies if I split up the solution. If someone decides they want to sync the game, how should I ensure they also get 1 and 2?

  1. Include the built dependent .dlls in the games repo?
  2. Just document, "you need these other projects and they must be in a path relative to the game like this".
  3. Just leave it all one giant solution and a single repo.
  4. Something I'm not thinking of?
+1  A: 

I would go with your option 1. If I as a user want to work on the game project, I do not care about the other two projects, but the game needs it, so include the dll.

If I want to make changes to the utility classes, well I then make changes to the utility project.

It is like me using another party's open source project in my own. When the other party's lib needs changes I go and make it there and then just get the latest .dll for this project as a dependency.

Marthinus
This is what I'm leaning towards too. Thanks for the second opinion!
munificent